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

§PatternTagScope & Exports
Cluster C.I – Core CALs / LOGs / CHRs
C.1Sys‑CAL (planned)CALPlanned consolidation of physical-system composition, conservation, and resource-flow guidance currently governed by A.1, A.14, A.22, A.3.4, B.1.6, and C.16.

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-characteristicsFormality 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, compute R_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), use R(Γ) = 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 to CL_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 is min 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

  1. C2-1 (Episteme constitution and neighbors). Every U.Episteme MUST satisfy C.2.1 constitution through exact claim content, one exact EntityOfConcern, and one effective U.ReferenceScheme. Empirical grounding and edition are stated through their separate C.2.1 relations. Viewpoint selection and U.View conformance 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.
  2. C2‑2 (Coordinates). Each episteme SHALL declare [F,G,R] with a brief rationale; F is U.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.
  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, take R(Γ) = max_P R_eff(P) (never exceeding the highest-R support line). Compute F(Γ) = min along 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 to R.
  4. C2‑4 (NotationBridge). Multi‑notation representation components SHOULD register NotationBridge edges with CL and loss note; any cross‑notation reasoning MUST cite the bridge’s CL.
  5. 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 Relations for episteme identity, the constitution relation, and the separate grounding and edition relations; E.17.0 for viewpoint selection and U.View conformance; C.29 and A.6.3.RT for representation; and E.17/E.24.PUB for 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 use A.1, A.14, A.22, A.3.4, B.1.6, and C.16 as 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 NotationBridge with 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:

  1. the U.Episteme knowledge holon;
  2. direct relation occurrences that constitute, ground, or connect editions of that holon;
  3. declaration epistemes whose C.2.1 identity is fixed independently, whose same individual has U.Signature membership under A.6.0, and whose relation-facing RelationSignature use declares reusable participant SlotSpecs for one exact relation kind;
  4. assertion epistemes that claim a direct relation predicate obtains and description epistemes whose EntityOfConcern is one explicitly individuated occurrence;
  5. publication occurrences that make one selected episteme edition available for a bounded audience and use;
  6. publication forms that express the selected edition for that publication use;
  7. U.PresentationCarrier entities that bear those forms;
  8. 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.

  1. 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.
  2. 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.
  3. Interpretation drift. The same tokens or graph are read under different designation, measurement, or evaluation rules while users assume one unchanged episteme.
  4. 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.
  5. 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.
  6. 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.
  7. 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

ForceTension
Readability vs precisionOrdinary use needs a short statement of what an episteme says and concerns; load-bearing use needs exact identity and direct relations.
Holon identity vs relation-occurrence identityThe same three participant identities reidentify both the episteme and its constitution-relation occurrence, but the episteme is the knowledge holon and the relation occurrence is the obtaining organization among those participants.
Shared episteme identity vs dependent-kind membershipThe C.2.1 identity triple identifies every U.Episteme. Direct patterns may recognize the same individual as a U.MethodDescription, U.View, or another admitted dependent episteme kind by a stable membership condition; they do not add a second identity. Grounding, viewpoint, scope, and publication stay in their neighboring relations.
Recursion vs circular justificationEpistemes may describe epistemes, including themselves, while an assurance path terminates in separately governed evidence and evaluation relations.
Representation variety vs ontology stabilityText, diagrams, formal calculi, learned representations, and interactive tools differ operationally, while representation identity remains distinct from the governed-object identities.
Explicit relation distinctions vs usabilityThe complete set of direct relations, declaration epistemes, assertions, publications, and representations remains recoverable without forcing every engineer to publish a signature, card, or occurrence description for an ordinary claim.

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.

Always askExact object recovered
What is being claimed?the exact claim content carried by one U.ClaimGraph
What exact entity do those claims concern?one identified U.Entity participating as the EntityOfConcern
Under which designation and interpretation rules are the claims read, and, where the claims use them, which measurement, comparison, or evaluation rules apply?the effective U.ReferenceScheme

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.

Open this row when the next sentence or action is...RecoverSubject pattern
A claim or relation must cite the exact constitution occurrence, not merely say that the episteme exists.one exact obtaining EpistemeConstitutionRelation occurrence, reidentified by the participant triple; designate it when an epistemic receiver needs a reference, or use the occurrence itself as a participant when another direct relation is the receiverC.2.1:4.2.3 and A.6.REL
A reader must cite one exact claim inside one exact episteme edition, rather than the whole episteme.one ClaimAddress: an exact episteme-edition reference plus an intrinsic claim identity declared by that edition's exact ClaimGraph; if no such identity resolves uniquely, cite the whole episteme or identify the claim as a separate epistemeC.2.1:4.2.5
An observer must inspect designated empirical claims against current observation, intervention, measurement, or test relations involving one exact holon.one exact EpistemeEmpiricalGroundingRelation occurrence, its covered claim subgraph, claim-to-world mappings, and grounding holon; recover supporting evaluation or evidence use separatelyC.2.1:4.3 and the direct observation, intervention, measurement, test, evaluation, or evidence pattern
A description must state the concern from which this episteme is read.one exact U.Viewpoint episteme P and the named describing use that selects P; keep the episteme, its EntityOfConcern, the use, and P distinctE.10.D2 and E.17.0
A team will validate a Description as a specification before relying on it.the exact Description episteme, checkable claims, and named harness or validation relation; preserve or update the named describing-use viewpoint only when that selection affects relianceE.10.D2 and C.2.1:6
A classification assertion must say that this episteme conforms to a viewpoint and is a U.View.one exact obtaining EpistemeViewpointConformanceRelation between this episteme and at least one exact U.Viewpoint epistemeE.17.0
A reader must trace how this episteme was constructed from an earlier source episteme.the exact source and receiving epistemes plus the governed viewing relation; view membership remains a separate conformance judgmentA.6.3 for construction and E.17.0 for membership
A claim must be restricted to one declared part of the situation under study.one exact U.ClaimScope and its membership relation over U.ContextSliceA.2.6
A calculation or interpretation must use one selected organization of model use.one exact BoundedModelUseStructure and the relation through which the receiving assertion or use selects itA.1.1 and the direct receiving-use pattern
A reader proposes to compare, substitute, translate, publish, or otherwise use an obtaining cross-context Bridge.one ordinary C.2.1 assertion episteme whose EntityOfConcern is that exact Bridge and whose ClaimGraph states the proposed use, direction, correspondence rule, loss tolerance, and polarity; recover reliance and any use that actually happened separatelyC.2.1:4.2.3 for claim identity; F.9 for the Bridge; A.10 for ordinary evidence reliance; B.3 only when an actual named assurance claim is current; the direct receiver pattern for any actual use
A decision or inference must cite support links among the claims.the exact JustificationGraph content that carries those dependenciesC.2.1:4.4; use A.10 only when ordinary evidence reliance is current, and B.3 only when an actual named assurance claim is current
A decision or evaluation will accept, reject, or withhold reliance because of evidence.the exact evidence-use relation; evidence storage alone is insufficientA.10 for ordinary evidence reliance; B.3 only for an actual named assurance claim
Reviewers must inspect or revise a classification judgment as an independent claim-bearing object.one classification assertion episteme about the exact candidate, plus the exact governing criterionC.2.1:4.2.3 with A.1 or C.3.2; E.24.UK only for public U-kind admission
A reader must assert that a later episteme revises, refines, or supersedes an earlier one.one exact EpistemeEditionRelation occurrenceC.2.1:4.5
A publisher must make one selected episteme edition available to a declared audience for a bounded use.the publication occurrence, publication form, and U.PresentationCarrier as distinct objectsE.17 and E.24.PUB
A user will calculate, infer, navigate, or inspect through a notation, diagram, mathematical structure, or tool representation whose available operations matter.the exact C.29 representation, correspondence, representation scheme, and any current transition relationC.29 and the selected representation-transition pattern
One receiving System must select, decline, or co-use candidate results of different kinds as representations for the same exact action or decision.one C.37 use-bounded representation-selection account; keep each direct subject result, optional A.2.4 first-use classification, A.10 reliance path when material, and receiving result separately governedC.37; the direct subject and receiving-result patterns remain authoritative

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, exact EntityOfConcern, effective ReferenceScheme>

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:

SlotKindRelation-participant meaningValueKindrefMode
ClaimGraphSlotconstitutive claim contentU.ClaimGraphByValue
EntityOfConcernSlotexact entity the claims concernU.EntityU.EntityRef
ReferenceSchemeSloteffective designation and interpretation schemeU.ReferenceSchemeByValue

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:

C.2.1 ClaimAddress ::= <
  exactEpistemeEditionRef: U.EpistemeRef,
  intrinsicClaimIdentity: identity declared by that exact 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:

SlotKindRelation-participant meaningValueKindrefMode
GroundedEpistemeSlotepisteme containing the exact covered claim subgraphU.EpistemeU.EpistemeRef
GroundingHolonSlotexact holon involved in the mapped observation, intervention, measurement, or test relationsU.HolonU.HolonRef

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

Current distinctionRelation or object to useWhy it stays outside the core constitution relation
classification judgment or separately current classification assertionthe A.1 recognition judgment for an admitted holon kind or the C.3.2 membership judgment for a local kind; one C.2.1 episteme when a receiving review treats the judgment as a separate claim-bearing objectthe governing criterion states the membership condition; the classification judgment evaluates the candidate under it; the assertion carries that judgment but neither creates the candidate nor admits the kind
claim scopeexact U.ClaimScope and its A.2.6 membership semanticsscope delimits where claims hold; it does not identify every episteme
concern-bearing viewpoint useone exact U.Viewpoint episteme P selected for one named describing useselection states the concern under which the description is used; it neither establishes conformance nor enters episteme identity
viewthe same episteme individual recognized as U.View when an exact EpistemeViewpointConformanceRelation to at least one exact viewpoint episteme obtainsconformance, source-to-receiving construction, current-use selection, publication, form, and carrier remain different relations or objects
bounded model useoptional relation to one BoundedModelUseStructure : U.Structure under A.1.1model-use organization can qualify interpretation without becoming a universal identity component
justification structureexact JustificationGraph contenta justification structure organizes inferential dependencies without becoming claim content
evidence use or assurance for a claimfor ordinary bounded reliance, the exact A.10 evidence-provenance relation and local RelianceDisposition; when an actual named assurance claim is current, the exact B.3 AssuranceResult or its non-positive dispositionevidence and assurance can support, narrow, or stop use without changing episteme identity or making the EntityOfConcern obtain; consequence alone creates no B.3 claim
publicationexact publication occurrence and publication form under E.17 and E.24.PUBmaking an edition available does not constitute or reidentify it
presentation carrierany exact U.PresentationCarrier under E.17 and E.24.PUBbearing a publication form or rendered expression does not constitute or reidentify the episteme
representation and admissible operationsrepresentation scheme currently used for the exact represented episteme, its selected elements, and the C.29 correspondence or transition relationsa change of scheme or admitted operations can change the available work without becoming the represented ontology

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:

SlotKindRelation-participant meaningValueKindrefMode
EarlierEpistemeSlotexact episteme continued by the later editionU.EpistemeU.EpistemeRef
LaterEpistemeSlotexact episteme that continues the earlier editionU.EpistemeU.EpistemeRef

The relation obtains only when all of these conditions hold:

  1. the two epistemes have different C.2.1 identities;
  2. the later episteme actually uses the earlier episteme as the source for the claimed revision, refinement, or supersession;
  3. 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;
  4. the exact preserved and deliberately changed features satisfy that rule;
  5. 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

Observed changeDisposition
claim content, EntityOfConcern, or effective reference scheme changesidentify another episteme; use EpistemeEditionRelation only for revision, refinement, or supersession when its historical-continuation predicate obtains, and use A.6.4 separately only for an exact retargeting that satisfies its own predicate; otherwise stop at the new identity without inferring continuity
the explicit empirical-claim coverage predicate begins to obtain, ceases to obtain, or is restoredevaluate EpistemeEmpiricalGroundingRelation continuity for the exact covered claim subgraph and grounding holon; do not change episteme identity unless a core discriminator also changed
an evidence item, evaluation report, evidence store, or work log becomes available or unavailable without an established change in the complete claim-coverage predicaterevise only the separately governed support, warrant, confidence, evidence-use relation, or receiving-use reliance posture that changed; the mapped direct relations still determine world-side grounding and occurrence continuity: known complete coverage continues, known coverage failure remains nonobtaining, and uncertainty about coverage gives an affirmative grounding assertion unresolved reliance rather than a third world-side state
candidate episteme E or viewpoint episteme P changesidentify the changed episteme under C.2.1, then test the new exact E/P pair under E.17.0; for fixed E and P, conformance cannot change because of evaluator, evidence, project, publication, or current use, so state any changing adequacy or evaluation as a separate claim
one named describing use selects one already identified U.Viewpoint episteme Pupdate only that use's exact viewpoint selection; the selection creates no context object, selects no view, and establishes neither conformance, U.View membership, nor episteme identity
claim scope changesupdate the exact U.ClaimScope and its A.2.6 membership semantics; do not infer another episteme automatically
selected bounded model-use or multi-view structure changesupdate the exact collection or structure relation and re-evaluate affected interpretation claims; do not infer another episteme or view family automatically
publication form, carrier, rendering, audience, bounded use, or publication occurrence changesestablish the exact E.24.PUB change only; publication is not view membership or episteme succession
mathematical or tool representation changesapply C.29 and the selected representation-transition relation

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

Current objectFPF kind or relationSubject pattern
U.Epistemeone knowledge holon with identity <claim content, EntityOfConcern, effective ReferenceScheme>C.2.1
EpistemeConstitutionRelation occurrencethe obtaining direct relation among the exact claim graph, exact EntityOfConcern, and effective reference scheme that constructively identifies one epistemeC.2.1 and A.6.REL
EpistemeEmpiricalGroundingRelation occurrencethe direct relation between one identified episteme and one exact grounding holon for one exact nonempty covered claim subgraph, while every empirical claim in that subgraph has a current mapping to the required observation, intervention, measurement, or test relations involving that holon; evaluation or evidence supports an assertion unless explicitly mapped as part of the empirical testC.2.1 and the governing observation, intervention, measurement, test, evaluation, or evidence patterns
classification assertion episteme, when separately currenta claim-bearing episteme whose EntityOfConcern is the exact candidate and whose claim content states a classification judgment under the exact governing criterion: A.1 for an admitted holon kind or C.3.2 for a local kindC.2.1 for assertion identity; the pattern governing the criterion for the judgment; E.24.UK only for public U-kind admission
EpistemeEditionRelation occurrencethe direct historical continuation relation between one exact earlier episteme and one exact later episteme; exact source use, the applicable continuation policy or rule, and the preserved and deliberately changed claim, EntityOfConcern, and scheme features decide whether it obtains; Work, Method, provenance, and change facts supply case facts only; apply the shared 4.9 inception boundary only when that separate fact is consumedC.2.1, coordinated with C.2.P, A.3.1, A.3.4, and C.2.1:4.9 only for a separately current inception claim
EpistemeConstitutionRelationSignature, EpistemeEmpiricalGroundingRelationSignature, or EpistemeEditionRelationSignatureone C.2.1 declaration episteme whose exact EntityOfConcern is its direct relation kind; the fixed A.6.0 predicate gives that same individual U.Signature membership, and RelationSignature is its relation-facing use with complete direct semantics and exact A.6.5 SlotSpecsC.2.1 for declaration identity, A.6.0 for membership and reusable vocabulary, and A.6.5 for SlotSpecs
SlotSpecone declaration-content component of that RelationSignatureA.6.5
assertion or description epistemea claim-bearing episteme that states or describes one of the direct relationsC.2.1 and the direct claim or description pattern
U.MethodDescriptionthe same U.Episteme individual when A.3.2 recognizes one admitted U.Method as its exact EntityOfConcern and its claims, interpreted under the effective U.ReferenceScheme, make at least one substantive claim about that method as a way of doing; mention, bibliographic metadata, or approval alone does not establish membership, and adequacy for a receiving use is evaluated separatelyC.2.1 for episteme identity; A.3.2 for dependent-kind membership
U.Viewthe same U.Episteme individual when it conforms to at least one exact U.Viewpoint episteme; formally, when EpistemeViewpointConformanceRelation(E,P) obtains for that pairC.2.1 for episteme identity; E.17.0 for dependent-kind membership; A.6.3 only when source-to-receiving construction is current. Conformance of E to P, that construction, current-use selection, and publication remain separate.
describing-use viewpoint selectionone named describing use selects one already identified U.Viewpoint episteme through an exact reference; it selects no viewE.10.D2 and E.17.0
multi-view collection or organizationan exact C.13 collection only when a receiving use depends on the plurality as a collection, and an exact A.22 U.Structure only when that use additionally depends on organization among those viewsC.13, A.22, and the direct organizing relations
cross-view correspondence, consistency, realization, trace, or change-impact claimone exact direct subject relation under its own governor; a C.2.1 episteme may assert or describe it, but a heading, edge, carrier, or E.17 publication invents no relationthe exact direct relation pattern; when none is current, return an exact missing-relation blocker naming the participants, required predicate and use, and missing governor
publication occurrencethe occurrence that makes one selected episteme edition available to a declared audience for a declared bounded useE.17 and E.24.PUB
publication formthe arrangement, notation, or rendering convention that expresses the selected episteme edition for that publication useE.17 and E.24.PUB
U.PresentationCarrierthe exact physical or digital carrier that bears the publication formE.17 and E.24.PUB
mathematical representationa C.29 representation used for an explicit modeling or reasoning purposeC.29

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.

Triangle cornerC.2.1 projectionWhat the projection suppresses
Symbolselected representation elements and any publication carrierrepresentation scheme, admitted operations, publication occurrence, and correspondence to the episteme
ConceptU.ClaimGraph interpreted under an effective U.ReferenceSchemeclaim scope, justification, viewpoint, and edition relations
Objectexact EntityOfConcern and any current EpistemeEmpiricalGroundingRelationthe difference between what claims concern and the holon through which they are empirically inspectable

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:

ValueMeaningIdentity status
entityOfConcernRefdesignation of the exact EntityOfConcern in the description episteme's constitution relationits resolved exact EntityOfConcern, not the reference value or designation, is C.2.1 identity-bearing
effective U.ReferenceSchemerules by which the description claims refer to and can be checked against that entityC.2.1 identity-bearing
viewpointRef, when currentgoverned reference resolving to the exact U.Viewpoint episteme selected for this describing use under E.17.0use qualifier outside episteme identity; work that changes an identity discriminator identifies another episteme independently
claimScopeRef, when currentdesignation of the exact U.ClaimScope under A.2.6claim-use qualifier
modelUseStructureRef, when currentdesignation of one independently selected BoundedModelUseStructure : U.Structureoptional interpretation qualifier, not a context root

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:

  1. which of claim content, EntityOfConcern, and effective reference scheme are preserved, restricted, bridged, or changed;
  2. 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;
  3. which claims in Y are preserved from or supported by X under the named morphism, the exact correspondence or retargeting relation governed by that morphism pattern, and any F.9 Bridge that governs cross-context sense use when current;
  4. 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)

  1. Episteme identity. Claim content, exact EntityOfConcern, and effective U.ReferenceScheme are recoverable, and the text states what changes each discriminator. A dependent episteme kind such as U.MethodDescription or U.View adds a governed membership judgment for the same individual, not another identity discriminator.
  2. Direct constitution and case judgment. EpistemeConstitutionRelation has 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.
  3. 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.0 predicate gives that same individual U.Signature membership and RelationSignature is 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.
  4. Classification discipline. A.1 governs recognition under an admitted holon kind, C.3.2 governs local-kind membership, and E.24.UK governs 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.
  5. Empirical-grounding discipline. GroundingHolonSlot occurs only inside EpistemeEmpiricalGroundingRelationSignature. 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.
  6. Edition discipline. EpistemeEditionRelation has 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.
  7. 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.View membership. 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.
  8. Description boundary. The EntityOfConcern and any Description episteme about it remain distinct, including self-description and episteme-about-episteme cases.
  9. 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.
  10. Agency, work-result, and identity-inception boundary. Only systems perform authoring, evaluation, revision, publication, viewing, query, redrawing, and use work. A.6.1 declares 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 one missing-governor blocker naming the entity, facts, required predicate, and receiving use. Otherwise do not open the inception boundary. No morphism, heading, representation, form, bare A.6.1 result, generic work result, or universal production relation supplies that fact.
  11. Publication boundary. Episteme, publication occurrence, publication form, view, and carrier keep separate identities. Plain published episteme names a contingent relation use, not another durable kind.
  12. 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.
  13. 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.
  14. Recursive assurance. Self-reference and meta-description do not form a minimal justification cycle; assurance terminates in independently governed evidence, observation, or formal derivation.
  15. 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

Anti-patternActual failureRepair
Filled-card ontologyA completed record is treated as what makes an episteme or relation exist.Recover the C.2.1 identity first. Identify a filled card as an episteme only when its claim content, EntityOfConcern, and effective reference scheme are recoverable; identify its reusable layout, exact carrier, and publication occurrence separately under their direct patterns.
Manifest-created declarationA manifest row, list, citation, identifier, or edition marker is treated as creating declaration identity, U.Signature membership, or a dependency.Identify the declaration episteme through the C.2.1 triple, judge same-individual U.Signature membership under A.6.0, and expose a manifest only for actual dependencies or provided names. A readable one-off assertion stops without either.
Classification as admission relationA candidate is said to acquire or lose holonhood when a governing FPF pattern or assertion changes.Apply the A.1 constructive criterion for an admitted holon kind; let E.24.UK govern only admission of that public kind; identify a separate C.2.1 assertion episteme when project review needs the classification claim.
Dependent kind as second identityU.MethodDescription, U.View, or another dependent episteme kind is given an extra identity discriminator merely because its direct pattern supplies a membership condition.Keep the C.2.1 identity of the same episteme individual. Apply the direct pattern only to judge dependent-kind membership; if work changes a C.2.1 discriminator, identify the resulting episteme through that changed discriminator.
Context identifier in episteme identity by habitA surrounding project or model-use context identifier is treated as identifying every episteme used there.Keep the shared C.2.1 identity context-independent; add claim scope, viewpoint, or bounded model-use structure only through the direct relation on which the current use depends.
Grounding by evidence presenceStored evidence or one unrelated measurement is treated as grounding the whole episteme.Select the exact covered claim subgraph, map every empirical claim in it to its required observation, intervention, measurement, or test relations involving the grounding holon, and test continuity of that complete coverage predicate. Evaluation or evidence supports the grounding assertion unless an exact evaluation relation is explicitly part of the empirical test; availability alone determines no world-side grounding state.
Edition work as relation participantRevision Work is inserted into EpistemeEditionRelation, so two Work occurrences appear to create two continuities between the same editions.Keep earlier and later epistemes as the two participants. Use Work, Method, source use, provenance, and change facts only as case facts for the independently stated continuity rule.
Edition by filename or Method labelv2, a later timestamp, or a Method named revision is taken as continuity.Recover both episteme identities, exact source use, the applicable continuity rule, its preserved and deliberately changed features, and its fork, translation, retargeting, and reconstruction failures.
Published-episteme kindTemporary participation in publication is treated as a second durable episteme kind.Keep the episteme identity and state the exact publication occurrence; use Plain published episteme only for that contingent use.
View as formatting, generation, or publicationA filtered table, diagram, query result, or published face is called a view because of appearance, construction history, or carrier, and a heading or edge is treated as cross-view correspondence.Identify the receiving episteme under C.2.1 and apply E.17.0 conformance for U.View membership. Add A.6.3 only for an actual source-to-receiving construction. Apply the exact direct subject-relation governor to correspondence; if none is recoverable, return an exact blocker naming the participants, required predicate and use, and missing governor.
Bridge as use verdictAn obtaining Bridge, its predicate profile, or a card is treated as proving that one comparison, translation, publication, or other use is suitable, authorized, or already performed.Keep the Bridge under F.9. State the proposed use in a separate ordinary C.2.1 assertion with the Bridge as EntityOfConcern and <u,d,r,t> plus polarity; use A.10 for ordinary evidence reliance, B.3 only for an actual named assurance claim, and the direct pattern for any receiving object that actually exists.
Mathematical identity leakA tuple key or graph node identity becomes episteme identity.Keep C.29 representation identity separate and use the C.2.1 identity triple.

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

Source and statusAdopted moveRejected overreadPractical effect in C.2.1
Catarina Dutilh Novaes, Formal Languages in Logic (2012), conceptual lineageTreat a formal language as a cognitive tool whose notation and admissible operations affect reasoning.A notation, calculus, or formal-language file does not thereby identify the episteme or its EntityOfConcern.The semantic-triangle case keeps the effective reference scheme and C.29 representation operations explicit while episteme identity remains independently governed.
Sybille Krämer, "Why notational iconicity is a form of operational iconicity" (2017), diagrammatic-reasoning lineagePreserve the operational consequences of spatial and material notation.Visual arrangement does not make diagram elements actual relation participants and does not prove that a view preserves source claims.The wiring-diagram and view cases use an explicit representation correspondence or viewing relation rather than relying on visual similarity.
Lambros Malafouris, People Are STRANGE (2026), current continuation of Material Engagement TheoryUse changing boundaries under material engagement as pressure on grounding: when an engagement changes what can be inspected or inferred, FPF still identifies the exact holon in the current grounding occurrence.A material setting, carrier, or tool is not automatically the episteme's EntityOfConcern or grounding holon.The pump and learning cases name one exact grounding holon and the direct grounding relation structure instead of absorbing the surrounding setting into episteme identity.
Florio and Linnebo, Introduction to Constructional Ontology (2024) and Borgo and Righetti, Towards Applied Constructional Ontology (2025), current constructional-ontology lineAdapt the separation among accepted inputs, the construction by which a whole emerges, and the resulting identity rule as a stress discipline for episteme constitution.EpistemeConstitutionRelation is not imported as a constructor object or work occurrence, and C.2.1 does not import a universal staged ontology.Sections 4.1 and 4.2 make the exact claim graph, EntityOfConcern, reference scheme, and their constitutive organization explicit in the constitution test; a tuple, card, or carrier cannot substitute for that construction or its identity rule.
Andrei Rodin, Venus Homotopically (2016), constructive identity-grounding lineageAdapt the use of observations, theoretical background, and a physically testable trajectory to make an identity judgment across different presentations inspectable.Shared wording, one label, or one grounding referent does not by itself prove identical EntityOfConcern, episteme, or substitutable claim content.The two-observation case in 9.6 separates the world-side identity assertion from both observation epistemes and keeps their C.2.1 identities independently testable.
Chris Partridge, BORO Ontology (2025), bounded four-dimensional extensional comparatorUse extensional identity as a stress test when a grounding relation can cease and later recur: a demonstrated temporal gap distinguishes the occurrences.C.2.1 does not import unrestricted composition, collapse work with participating systems, or attribute constructional input identity to BORO.Section 4.3 uses the maximal continuous grounding interval as the recurrence discriminator, while evidence availability or absence alone neither proves nor disproves a temporal gap.
W3C PROV-O Recommendation (2013), stable provenance lineageKeep an entity, an activity that uses or generates it, and revision or derivation metadata distinct.wasRevisionOf, a provenance edge, or an activity named revision does not establish FPF edition continuity.EpistemeEditionRelation uses provenance and source-use facts only inside the applicable continuity test; the earlier and later epistemes remain its two participants.
W3C RDF 1.2 Concepts, Candidate Recommendation Snapshot of 7 April 2026, current representation standardDistinguish an asserted triple, an unasserted triple term, and a reifier used for statements about a proposition.An RDF triple, reifier, graph edge, or annotation is not the direct relation occurrence merely by representation.The relation-object boundary keeps assertion episteme, relation-occurrence description episteme, graph representation, and direct relation obtaining separate.
Almeida, Guizzardi, Sales, and Fonseca, gUFO: A Gentle Foundational Ontology for Semantic Web Knowledge Graphs (March 2026), current preprintUse its typology and reification patterns for relational aspects as a current comparison case when deciding whether an explicit relation pattern is needed.C.2.1 does not import a universal relator, situation, or graph-reifier ontology; each direct relation pattern defines or constrains its participants, obtaining condition, and occurrence-identity rule.Constitution, grounding, and edition relations receive separate rules rather than one record-shaped reification scheme.
Anthropic, A global workspace in language models (6 July 2026), current primary research summary with linked paperRecognize that learned internal representations can causally mediate reasoning while remaining distinct from produced text.A latent activation, probe label, or readable internal trace is not automatically a claim-bearing episteme.Case 9.8 keeps the observed system-side activation phenomenon, its probe representation, decoded rendering, and any claim-bearing probe episteme distinct; C.2.1 admission still requires recoverable claim content, an exact EntityOfConcern, and an effective reference scheme.
Cheng et al., Teaching Thinking Models to Reason with Tools (May 2026), current preprintKeep tool use, reasoning trajectories, evaluation, and their failure modes explicit because tool integration can change or degrade reasoning behavior.Tool availability, a tool trace, or an evaluation harness does not by itself establish claim truth, grounding, or episteme identity.Case 9.8 separates enacted inference and call work, the exact work-to-trace relation or A.6.1 binding current in that case, answer and evaluation epistemes, representation use, evidence, and empirical grounding; a changed tool regime reopens only the exact changed objects and relations.

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.1 for holon recognition, A.6.REL for direct relation occurrences, A.6.0 for independent same-individual U.Signature membership and relation-facing RelationSignature use, A.6.5 for declaration-local SlotSpecs and participant designations, A.7 for entity-description distinction, and C.29 for mathematical representation.
  • Coordinates with: A.3.2 for U.MethodDescription membership without a second episteme identity; C.3.2 for local-kind membership judgments; E.24.UK for ontology-level U-kind admission; E.10.D2 for Description and specification-use discipline, including selection that creates neither conformance nor membership; A.6.1 for typed operation positions and exact current application bindings; A.6.2, A.6.3, and A.6.4 for morphing, source-to-receiving viewing construction, and retargeting; A.6.3.RT for representation transitions; E.17.0 for conformance of fixed E to fixed P and U.View membership; C.13 and A.22 for 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.9 for exact Bridge semantics when a claim concerns a bounded cross-context use; E.13 when a visible representation-quality proxy is used as practical epistemic value; A.2.6 for claim scope; A.1.1 for bounded model-use structure; A.10 and B.3 for evidence and assurance; A.14 only when a phase or separately selected edition collection is current; C.2.P, A.3.1, and A.3.4 when 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.17 for multi-view publication forms and uses; E.24.PUB for publication occurrences, forms, and carriers; and G.11 for 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.

  1. Say what the sentence is doing: defining, claiming, instructing, comparing, locating a source, describing a publication, or supporting a project use.
  2. Recover the one unresolved episteme, publication, source-to-use, carrier, or use-disposition distinction.
  3. 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:

  1. 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;
  2. 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;
  3. slash lists and heterogeneous rows become false group kinds;
  4. unclear source meaning is guessed into FPF-governed wording rather than blocked or assigned to an accepted FPF extension;
  5. authors copy the same loose wording into DRRs, patterns, source-relation notes, source-ref target notes, or project texts.

Forces

ForceTension
Precision vs readabilityFPF-governed wording needs kinds named by value, but a sentence overloaded with every possible kind becomes unreadable.
Preservation vs cleanupAccepted source text or accepted governing text must not be paraphrased away, but source-companion statement cannot be mistaken for pattern authority.
Local repair vs new ontologyMany phrases only need local A.6.P and F.18 recovery; a few reveal a real missing FPF kind or relation.
FPF-side vs project-side workThe same word can describe FPF pattern authorship or a user's project publication, record, work, or action.
Guidance vs auditThe pattern must tell authors what to do, while check rows only verify that the rewrite was carried out.

Solution

Repair episteme-publication-heavy wording by epistemic precision restoration, not by dictionary replacement.

A successful rewrite satisfies these field-validity constraints:

  1. the head kind and sentence function are recoverable under E.10;
  2. a stable reusable name has an F.18 naming result;
  3. a relation, comparison, dependency, support, sameness, grounding, mapping, or endpoint claim has A.6.P relation precision, with use-boundary and project-side reliance questions split into their own fields;
  4. 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.1 typing or named FPF claim or declared-use boundary named by value;
  5. publication, view, face, and carrier distinctions satisfy E.17.0, E.17, and MVPK;
  6. the repaired text satisfies E.2 Pillars, especially P-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 under E.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;
  7. the final phrase preserves the distinction without adding another claim;
  8. 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:

Compact epistemic precision-restoration row:
  exactSpanOrSentence:
  sentenceFunction:
  recoveredKindOrRelation:
  selectedWordingOrDisposition:
  remainingReaderUse:

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.

  1. Name the sentence function. State what the sentence would let a reader claim or do.
  2. 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.
  3. 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.18 and A.6.P recovery;
  • a relation claim that needs a RelationKind, a QualifiedRelationRecord, 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 FPF kinds, or current FPF episteme and publication ontology;
  • the claim is understandable, but current FPF does 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, selected EntityOfConcern, 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 when projectSideFPFRef is current. The selected value is one current value, not the list: C.11 ChoiceResult; C.11 decision record; A.6.A action invitation; A.15 U.WorkPlan; A.15.1 dated U.Work occurrence; U.Method; U.MethodDescription; A.20 constraint or adjudication decision record; A.21 GateDecision; A.21 DecisionLogRef; A.10 evidence path; typed evidence record; B.3 AssuranceResult; 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 DRR content decision, or campaign-scoped content question, but it does not carry current authority, evidence, or use-boundary claim until an accepted architecture decision, accepted DRR, 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.P for relation precision;
  • F.18 for a reusable name;
  • C.30.P for a hidden architecture or structure distinction;
  • C.16.P or C.16.Q for 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.

Recovered categoryUse the contribution that answers the remaining question
Publication occurrence, form, face, presentation carrier, rendering, or availabilityUse E.17 to select a source-backed face for a named reader and use; use E.24.PUB when publication-occurrence identity, form, carrier, audience, bounded use, or availability matters. If the claim is that access actually occurred, use the pattern for that exact access relation; availability alone does not establish access.
Evidence, provenance, or currentnessUse A.10 for one claim-bound evidence-provenance path and bounded reliance. Use G.6 only when later citation or replay needs an addressable path through several already established objects and relations. Use G.11 when staleness or refresh of a source, edition, evidence set, dashboard, or carrier is the live question.
Generated or discovered result reached through a carrierUse C.35 to decide whether the exact result may seed architecture work. Keep its publication occurrence and carrier under E.17 or E.24.PUB; C.35 admits or rejects the result, not a generic "generated carrier".
FPF, DPF, or LPF edition, package carrier, or access carrierUse E.4.FPF for FPF form and publication- or access-carrier assembly and E.4.DPF for DPF or LPF authoring and publication- or access-carrier assembly. Use E.4.PFIP only for accepted-source integration or predecessor-publication preservation, E.4.PFR only for a relation or edition maintenance claim, and E.4.DPF.DA only for whole-package adequacy.
Work or reliance prompted by a carrier or displayUse A.15.2 for an identified WorkPlan and A.15.1 for performed Work. Use A.15 only while the system-role kind or assignment, Method, WorkPlan, and performed Work remain entangled. Use A.15.4 only while the appearance hides the direct prerequisite for the intended Work or reliance use; once that prerequisite is known, use its direct evidence, gate, decision, permission, or assurance pattern.
Architecture or structure useUse C.30.P while the architecture or structure claim is still hidden, C.33 to test what selected structure a carrier or observation actually captures and what must return from source, and C.34 only for a claimed correspondence or preservation between two exact structures.
Base or support wordingUse A.6.6 only when the wording hides an actual basedness relation. Name the dependent, base, and direct predicate first and stop when that ordinary assertion answers the use. If the wording instead concerns evidence, assurance, or work enablement, use the pattern for that claim; leave navigation or ordinary help in ordinary language.

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.

TermCurrent interpretationMust not mean
FPF as epistemeThe whole FPF is a claim-bearing episteme with publications, parts, patterns, pattern sections, DRRs, and companion publications and documents named for source, evidence, architecture, or review use.A file, repository, taxonomy, pattern-language metaphor, or packet-local summary by default.
FPF patternA named FPF pattern: a reusable episteme species that gives action guidance for a problem situation. It is applied in a current problem situation.Any recurring arrangement, procedure, method call, route, cluster label, checklist, or document named only as a citation or source-finding pointer.
pattern sectionEither a part of the pattern episteme or a bounded PublicationUnit of that pattern publication, depending on sentence function. State which one matters when the distinction carries a claim.Independent pattern, file location, generic locus, or record with named authority-reference relation.
accepted campaign DRRA campaign decision source that states accepted content decisions for one campaign.A pattern, current-authority summary, open-ended plan, review log, or replacement for pattern text.
relationClaimSliceEmpty, or a local note that A.6.P relation precision is current for one sentence. It must name the relation problem being handled: relation, comparison, dependency, support, sameness, grounding, mapping, endpoint claim, or cross-context bridge claim. The recovery then names RelationKind, QualifiedRelationRecord, relation phrase, candidate-set note, or bridge card when current, with typed endpoints, slots, qualifiers, and scope.Dictionary replacement, one new umbrella kind, a bare RelationKind standing in for a relation record, a generic relation slot, support relation by default, or a list left as the final answer.
declaredUseBoundaryThe declared use boundary and blocked use outside that boundary when the sentence says what declared use boundary applies to a use, act, claim, or reliance. Use A.6.B when the boundary claim needs L-, A-, D-, and E-claim separation.Generic supported use, permission-by-appearance, or visual cue or readability cue treated as use-boundary.
projectSideFPFRefThe project-side FPF kind and reference named by value when a publication, display, cue, or explanation is treated as a project-side source for work, evidence, gate, constraint, adjudication, decision, commitment, method, action invitation, assurance, or engineering justification. The field points to that kind and reference; use the relevant FPF pattern for the relation and its checks.One slot accepting records, actions, methods, carriers, evidence, gates, decisions, assurance, and engineering justification interchangeably.
rejectedOverreadA local field naming the tempting interpretation, evidence, gate, work, permission, approval, commitment, release, safety-proof, engineering-justification, or pattern-entry interpretation that must not be granted by resemblance alone. It is valid only with the recovered relation or subject-specific source, scheme, scope, practice, or use that blocks it. It is not U.Kind, not a record kind, not a review-finding kind, and not a moralized defect class.A general risk slogan, review finding, moralized "bad use", vague misuse label, or reusable FPF kind.
useBoundaryTargetKind, useBoundaryTargetRefSource-local helper fields. Prefer declaredUseBoundary; if these fields appear in material being repaired, they name the kind and reference inside declaredUseBoundary, not an A.6.P relation slot.A generic supported use, document capability, "claim outside the declared boundary", review permission, or untyped pattern assignment.
Episteme, Publication, and Carrier Distinctions
TermCurrent interpretationMust not mean
U.EpistemeClaim-bearing episteme or episteme species. Use when the value is a claim-bearing episteme that can be described, viewed, grounded, revised, published, or relied on under FPF.File, paragraph, screen, carrier, status note, process state, or generic "content".
C.2.1 episteme constitution and neighboring relationsAn exact episteme is identified through claim content, one exact EntityOfConcern, and one effective ReferenceScheme under EpistemeConstitutionRelation. Empirical grounding is a separate EpistemeEmpiricalGroundingRelation; describing-use viewpoint selection, E.17.0 conformance and same-individual U.View membership, C.29 representation, and publication or carrier relations are also separate. SlotKinds occur only inside the exact reusable RelationSignature that declares their participant meanings.One universal episteme-slot tuple, card, field family, or context container.
EntityOfConcern, EntityOfConcernRefThe EntityOfConcern reference under C.2.1 named by a claim-bearing episteme or episteme-lane U.View: entity, relation, FPF pattern, FPF publication, project episteme, project publication, project-side FPF kind and reference named by value, work or action when that work or action is itself the entity of concern, or another explicitly typed EntityOfConcern referent. Use this when the text is really about what the episteme is about. In publication-unit work, EntityOfConcernRef is used only through a claim-bearing episteme or episteme-lane U.View; it does not float as a free field on the unit.Generic topic, local table subject, file title, reviewed publication, review packet, or review record, required project-side work, decision, action invitation, authoring work, or anything someone happens to talk about.
wording such as describedEntity, DescribedEntityRef, primary described entityUse the exact EntityOfConcern participant and its applicable reference under C.2.1 when a claim-bearing episteme is current. Use publicationUnitPrimaryEntityOfConcern when one bounded PublicationUnit carries or exposes a claim-bearing episteme or same-individual U.View and the primary entity of concern must be named.A second C.2.1 slot family, a free publication-unit field, a generic topic, a second current name, or a new ontology beside EntityOfConcern.
publicationUnitPrimaryEntityOfConcernThe primary entity of concern, non-claim-bearing kind named by value, topic, or subject that one bounded PublicationUnit is mainly about for the current use. When a claim-bearing episteme or episteme-lane U.View is current, this must be recoverable from the selected EntityOfConcernRef; otherwise name the non-claim-bearing kind named by value or keep topic and subject as plain explanatory prose.EntityOfConcernRef created without a claim-bearing episteme or episteme-lane view, publication-unit title by default, authoring process, carrier identity, or reader interest.
GroundingHolon, empirical-grounding relationThe exact grounding holon and obtaining C.2.1 EpistemeEmpiricalGroundingRelation that maps named empirical claims of one exact episteme to the required direct observation, intervention, measurement, or test relations.A constituent of episteme identity, a convenient source citation, an untyped entity mention, or the declaration-local GroundingHolonSlot used as the world-side value.
U.View, U.EpistemeViewSame-individual dependent membership of one already identified episteme when an exact E.17.0 EpistemeViewpointConformanceRelation to at least one exact viewpoint episteme obtains. A.6.3 source-to-receiving construction, describing-use viewpoint selection, publication, form, and carrier remain separate. An MVPK face can use this typing only under its exact E.17 constraints.A UI view, reader viewpoint, screen, generic publication face, projection by default, or new claim-bearing episteme by membership alone.
ViewpointOne exact U.Viewpoint episteme used as the viewpoint participant of an E.17.0 conformance relation or selected for one named describing use. Selection does not prove conformance or U.View membership. If source wording says “system in role,” use E.10.ROLE and recover the exact concern, object, local system-role kind, classification judgment, participant relation, or assigned System by value.A reader opinion, episteme-identity slot, pattern-application order, publication label, carrier label, or assignment manufactured by the viewpoint phrase.
publicationA publishable episteme, view, record relation, act or occurrence of publishing, or publication form, depending on sentence function. Always split by kind before use.Generic document, any public-looking file, or proof that a claim is authorized.
U.EpistemePublication (rejected spelling)No durable kind. Recover the claim as the selected U.Episteme, an EpistemePublicationRelation occurrence or reference when availability matters, publication form, or U.PresentationCarrier, according to sentence function. The spelling may remain only in this rejection explanation or a negative test.A positive object, kind, reference, field, publication identity, or carrier identity.
publication formThe typed form in which an episteme, view, or record is published.The claim-bearing episteme itself, the face rendered for a reader, or the carrier holding bytes.
generic publication faceReader-facing publication projection or face. It is not U.View by default; it becomes a view only when E.17 or the applicable view pattern supplies that typing.U.View by default, carrier, UI face, front-end display, MVPK face under E.17 constraints, or claim-bearing episteme.
MVPK face under E.17 constraintsE.17 face published under MVPK constraints from a source episteme or episteme-lane view, publication viewpoint, scope, pins, and face kind. It may be a U.EpistemeView when the MVPK profile makes that typing current.Generic publication face, carrier, UI face, front-end display, or proof of evidence, work, gate, or authority by presentation.
carrier, front-end, renderingPublication-side or access-side bearer or display relation. Use U.PresentationCarrier under E.17 and E.24.PUB when that exact carrier is current; otherwise name the file carrier, transport carrier, rendering, front-end relation, access-carrier relation, or another carrier relation by sentence function.Episteme identity, publication form, U.View, proof of evidence, or authority-reference relation.
PublicationUnitE.17.AUD-cluster head for one bounded unit inside a publication that a person inspects as one unit: a pattern body, section, table, note, card, sheet, screen block, or another bounded publication unit whose boundary is named. A card, sheet, or screen block counts only when its boundary is inside a named publication or generic publication face and the sentence needs that bounded unit as the inspected publication unit. It is part of or bounded by the publication face that renders or locates it, whether that face is generic or published under E.17 and MVPK constraints. It may carry or expose a claim-bearing episteme, view, record, cue, or local rendered content when that carried value and relation are named, but it is not identical with the carried value.Authoring process, review work, file, carrier, front-end, UI behavior, dashboard behavior or export behavior, whole publication architecture, U.Episteme, U.View, publication form, generic publication face, MVPK face under E.17 constraints, or "anything written".
project-side FPF kind and reference named by valueEvidence record, gate record, Work record, status record, commitment record, system-role-assignment record, decision record, selected source U.Episteme, EpistemePublicationRelation occurrence reference when availability matters, status-register entry, or another project record whose FPF kind is named.Semantic content in general, current process state, or a free-form note.
source documentA document named for source-use, evidence use, architecture use, or review use. Name that document use directly.A governing source by folder proximity, the EntityOfConcern carried or exposed by that source document, or the authority-reference relation unless that relation is explicit.
reviewed publication, review packet, or review recordThe reviewed publication named by value, review packet, review record, or bounded publication unit sent or inspected in review.The EntityOfConcern carried or exposed by that reviewed publication, review packet, or review record, the source relation behind it, or a packet-local summary.
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:

  1. preserves the E.10 result rather than restarting from word taste;
  2. names the recovered kind, relation, or non-use disposition;
  3. hands any remaining relation, naming, publication, evidence, work, decision, or assurance claim to its exact pattern;
  4. 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

Boundary caseC.2.P resultWhy this protects use
Ordinary reader helpThe sentence says a note helps a reader find another section, with no evidence, authority, use-boundary, work, gate, decision, or project reliance claim. Leave ordinary wording ordinary or make one local wording repair.Keeps ordinary prose affordable; support as ordinary help is not forced into a record.
Relation-only support wordingThe sentence says one claim, source description, grounding relation, evidence record, B.3 AssuranceResult, engineering-justification result, causal-use relation, mathematical-lens relation, characteristic relation, declared-use boundary, work relation, or publication-companion use bears on another claim, and source-relation use or publication construction is already clear. Apply A.6.P; no C.2.P recovery is needed.Prevents this pattern from absorbing relation precision restoration.
Known FPF kind named by valueThe sentence already names the project-side FPF kind and reference, such as an evidence path, gate decision, decision record, Work occurrence, B.3 AssuranceResult, or architecture pattern application. Apply the named pattern without an intermediate C.2.P step.Avoids a needless logical hop and keeps the relevant neighboring-pattern application intact.
Source phrase without recovered FPF-governed useSource wording is interesting but its FPF kind, relation, or use disposition cannot be recovered. Keep it as reduced-use cue or block its FPF use.Preserves source meaning without guessing FPF meaning.
Replacement head is another umbrellaA proposed repair changes support to basis, display to face, or route to path while the kind and relation are still hidden. Mark repair incomplete.Blocks lexical churn and forces the kind named by value, relation, and declared use boundary to be recovered.
Apparatus too heavyA one-sentence local repair is replaced by a full record, checklist, and source note with no additional declared use boundary. Use the local sentence or compact row instead.Keeps first-use cost and maintenance cost inside the quality claim.

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

LensRiskMitigation
OntologyPrecise-looking words become a new parallel ontology.Require recovery to current FPF kinds and relations before reuse.
UsabilityThe rule becomes too heavy for ordinary edits.Use the smallest sufficient rewrite mode. Reserve the full check for several interacting unresolved fields, contested source-to-FPF use, or a reusable ontological or naming decision.
PreservationSource-relation or source-ref target text is mistaken for direct pattern authority.Keep source-related statements separate from the ordinary pattern guidance.
Checklist ritualThe rule becomes a form to satisfy rather than a wording action to perform.Put the action in Solution; use row evidence only when wording has FPF-governed use.

Conformance Checklist

ItemCheck
CC-C2P-1C.2.P opens only after E.10 leaves one source-expression, episteme, publication, carrier, source-to-use, or use-disposition distinction unresolved.
CC-C2P-2If the exact receiving pattern and field are already recoverable, the practitioner uses them directly.
CC-C2P-3The selected product is direct repair, the five-field compact row, a materially justified full check, or an explicit non-use result.
CC-C2P-4A direct repair needs no record; optional fields appear only when changing them could change the claim or use.
CC-C2P-5A full check is used only for several interacting unresolved fields, contested source-to-FPF use, or a reusable ontological or naming decision. Pattern editing alone is not a trigger.
CC-C2P-6Claim content, episteme, publication occurrence, form, bounded PublicationUnit, view, carrier, rendering, and project-side use remain distinct when current.
CC-C2P-7Relation precision goes to A.6.P, stable naming to F.18, episteme identity to C.2.1, and publication or carrier claims to E.17 or E.24.PUB once that direct branch is known.
CC-C2P-8The wording names a contributingPattern only for the concrete definition, constraint, or test it supplies; no pattern ownership or pseudo-agency is implied.
CC-C2P-9Slash compounds and lists do not hide an unnamed kind or relation. Examples are marked as examples rather than treated as a complete extension.
CC-C2P-10The final wording remains precise plain language: a cold reader can recognize the situation, take the next action, and see the stop or non-use boundary.
CC-C2P-11Source wording is not forced into FPF vocabulary when no FPF-governed use is recoverable.
CC-C2P-12Source expression, source episteme, publication availability, source-to-use relation, any reverse source-return edge, work-side relation, and physical raw material remain separate. A.6.P.WMR or A.15.4 opens only while its exact relation or reliance question remains unresolved.

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

Anti-patternFailureAvoidance
Token swapReplace display with face or host with file without recovering kind and sentence function.Apply head-kind and relation recovery before rewriting.
Group-kind listLeave a list such as pattern, record, relation, or action as if the list names one kind.Decide whether the sentence needs one kind, a relation record, a tuple-like record, alternative cases, or a blocked ontology.
Type-correct but inert rewriteAll overread is removed, all heads are typed, and no practical guidance remains: the reader can see that local checks passed but cannot tell why the distinction matters, what to do, or which FPF pattern application or project-side FPF kind carries the claim being made.Recover the didactic or recognition function in wording whose claim being made is recovered through the named FPF pattern, keep any Plain line mapped to the recovered Tech interpretation when both registers are current, state the remaining reader use, or demote the phrase to reduced-use cue, blocked use, or rewrite incomplete instead of pretending the repair landed.
Expressive overread reboundA repair restores practical guidance with a memorable Plain or didactic line, but that line carries a claim not recoverable from the Tech fields, named FPF kind, recovered relation, project-side reference, disposition, or pattern application.Map the line to the recovered Tech interpretation under E.10:6.2; use the FPF pattern that defines, constrains, or tests the claim; or demote the phrase to reduced-use cue, blocked use, or rewrite incomplete.
Pillar-blind precision passA broad cleanup proves trigger removal and kind recovery, but never checks whether E.2 P-2, E.6, E.8, or E.12 still let the intended reader see the working situation, why it matters, and what first useful move remains.For FPF-governed Problem frames, Problem sections, recognition texts, examples, and worked slices, state the remaining reader use or FPF pattern application. Preserve intentional didactic metaphors when they are ordinary recognition aids or when their claim being made maps back to Tech. If the didactic function was harmed, repair the Plain wording so it maps back to the recovered Tech interpretation, or mark the rewrite incomplete instead of accepting type-correct but inert wording.
Source-companion header leakageCarry a source-companion header into a pattern and let Authority: none or Current use define the new pattern.State the pattern-use claim and authority claim in the pattern header and relations.
Pattern as procedureSay the pattern is called, routed, invoked, or chained as if it were executable code.Say that a practitioner uses or applies the pattern in a problem situation. If actual project activity is claimed, name the relevant work occurrence, method, decision, or action invitation; add actor or U.MethodDescription identity only when it changes the claim or its later use.
Strength metaphorSay a claim is strong or weak without a characteristic, threshold, evidence class, scope, gate, or use-boundary relation.Name the comparison characteristic, threshold, evidence class, scope, gate, or use-boundary relation, or replace the metaphor with the recovered use-boundary relation.

Consequences

BenefitTrade-off and mitigation
Prevents parallel episteme and publication ontology from entering FPF-governed wording.Adds a small recovery step before apparently simple rewrites; mitigate by using the smallest sufficient mode.
Preserves accepted glossary and rules without turning source-related statements into accidental pattern authority.Requires a clear separation between pattern guidance and source-related statements.
Makes unclear meaning fail closed.Some attractive phrases will not be accepted until their kind or relation is actually recovered.
Improves DRR and pattern drafting discipline.Authors must resist convenient lists and umbrellas when one kind named by value or relation is needed.

Operating consequence

For each repair:

  1. start from the sentence's function and practical consequence, not from a word list;
  2. preserve the E.10 result and recover only the one still-hidden episteme, publication, carrier, source-to-use, or use-disposition distinction;
  3. use the direct pattern as soon as it is known;
  4. choose direct repair before a compact row, and a compact row before a full check;
  5. keep the final sentence readable to a cold practitioner and state what action or non-use remains;
  6. 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.

Reduced source ideaAdapted FPF invariantRejected shortcutRecovery section
ISO 704:2022 and ISO 1087:2019 terminology work distinguishes the entity under discussion, the concept used in a terminology system, the definition, the designation, and term-formation practice.Recover the FPF kind, relation, and sentence function before accepting a rewritten phrase. Use external terminology work only as external corroboration for careful designation and definition practice.Do not replace FPF episteme and publication ontology with an ISO concept system, a dictionary substitution, or a global class row.C.2.P:4.1, C.2.P:4.4, and C.2.P:10
SHACL-style constraint validation makes local constraints explicit and fail-closed when a data shape does not satisfy them.Use only the fail-closed analogy: when the FPF kind, relation, or declared use boundary cannot be recovered, return a non-use result instead of accepting the wording.Do not import SHACL ontology, machine-validation authority, or shape vocabulary as FPF pattern ontology.C.2.P:4.0a, C.2.P:4.2, and C.2.P:8
Word-sense disambiguation and ambiguity-resolution practice treats sense recovery as context-sensitive rather than solved by the most common word sense.When one local head or qualifier carries several plausible senses, recover the local FPF context and the applicable named FPF pattern before choosing wording.Do not import machine-learning benchmarks or treat common usage as proof that the local FPF sense is recovered.C.2.P:4.4, C.2.P:4.1.2, E.17.AUD.LHR, and F.18

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.10 supplies the head-kind, term, morphology, register, and forbidden-umbrella discipline.
  • E.10.D2 gives the "thing vs words vs rules" discipline and the carrier humility rule.
  • F.18 gives 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.P gives 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.1 gives episteme identity through exact claim content, EntityOfConcern, and effective ReferenceScheme and keeps empirical grounding and edition continuity as distinct direct relations.
  • A.7 keeps EntityOfConcern, Description episteme, and publication carrier distinct.
  • E.17.0, E.17 distinguish views, viewpoints, MVPK faces, publication forms, and publication projections.
  • A.15.4 shows 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, and A.3.3 provide the movement, control, and temporal machinery used when episteme-publication prose talks about route, trajectory, movement, cadence, or dynamics.
  • E.19 already treats terminology and sentence-level precision restoration as required review checks, not editorial polish.
  • A.6.A carries action-invitation discipline when a publication, representation, or cue invites an action without itself becoming authority, evidence, gate passage, or work completion.
  • C.11 carries decision-making and decision-record discipline when the question under repair is a decision rather than generic action.
  • A.15 and A.15.4 split system-role kind and assignment, Method, WorkPlan, and actual-Work alignment from appearance-based reliance repair; do not use A.15 as a universal repair for episteme-publication wording.
  • E.9 is the campaign DRR pattern for campaign-level content decisions; E.11 is only for entry-discoverability situations and must not organize an episteme and publication repair by default.

These internal FPF patterns remain primary:

Claim needRelevant FPF pattern(s)Alignment with C.2.PAdoption result
Head-kind disciplineE.10Use head-kind recovery before accepting a phrase.Adopt.
Stable namingF.18Run a name card when a reusable head is being minted.Adopt.
Relation precisionA.6.PRecover relation kind, endpoints, slots, qualifiers, and scope when a relation or use-boundary claim is current.Adopt.
Carrier and EntityOfConcern-description humilityA.7Keep EntityOfConcern, Description episteme, and carrier apart before treating a publication as evidence, work, gate, or authority.Adopt.
Episteme and publication ontologyC.2.1, E.17.0, E.17, MVPKSeparate episteme, publication, view, generic publication face, MVPK face under E.17 constraints, publication unit, carrier, and rendering.Adopt.
Project-side downstream useA.6.A, A.10, A.15, A.15.4, B.3, A.20, A.21, C.11When a publication, display, cue, or explanation is treated as evidence, gate, decision, work permission, method, assurance, or engineering justification, name the applicable FPF pattern and the project-side FPF kind and reference.Adopt.

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.2 Pillars, especially P-2 Didactic Primacy; E.10, E.10.ARCH, A.7, F.18, A.6.P, C.2.1, E.17.0, E.17, MVPK, and A.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, and E.17.ID.CR.
  • Does not replace: E.10 general lexical rules, F.18 naming protocol, A.6.P relation 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:

  1. Auditable. A reader can trace R to concrete evidence and see how reuse penalties were applied.
  2. Composable. R can be propagated through claim graphs conservatively, without illegal scale arithmetic.
  3. Orthogonal. R is not conflated with F (expression) or G (scope).
  4. 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.
  5. Minimal. The solution does not introduce new core types or new face-kinds.

Forces

ForceTension
Single number vs multi-tradition evidencePeople want one scalar ↔ evidence comes from heterogeneous practices (proofs, tests, telemetry, expert review).
Rigor vs humilityClaims need to be usable in decisions ↔ overconfident scores are dangerous and hard to unwind.
Formal vs empirical warrantProof can be decisive in a formal theory ↔ real-world deployment requires empirical adequacy and drift management.
Scope realism vs marketing scopeNarrow scopes raise R ↔ incentives push for broad statements with hidden preconditions.
Reuse vs relation-specific lossReuse is valuable ↔ a changed scope, kind, plane, notation, local meaning, model-use basis, or evidence basis can introduce a different and separately governed loss.
Toolability vs expressive freedomA validator needs crisp rules ↔ authors want flexible narratives and domain nuance.

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 for c, treated as a ratio-scale scalar in [0,1] (or an ordinal proxy at [M‑0/M‑1]; see §4.5.A). R_eff is 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 K or 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).
  • ReferencePlane is declared where applicable; plane crossings apply CL^plane and 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); if ReferencePlane=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 R means “the evidence and its relevance supports relying on this claim under this scope.”
  • A higher F means “the claim’s form is amenable to higher-formality checking and wider reuse,” but does not itself imply the claim is warranted.
  • A larger G means “the claim applies to more cases,” but does not itself imply the claim is warranted in those cases.

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.

  1. State the plant claim and its scope. Under A.2.6 the engineer explicitly narrows the temperature interval to [122,148]°C because the plant calibration rule reports a ±2 °C bias. This changes G; it is not an F.9 semantic Bridge and is not inferred from the words "lab" and "plant".
  2. 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=2 under policy Φ_v1, compute R_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:

  • CL be the congruence level declared by the applicable scope, semantic, notation, model-use, or evidence-reuse relation (B.3 and its direct subject pattern).
  • CL^k be the congruence level of an applicable kind relation (C.3/C.3.3).
  • CL^plane be 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 when ReferencePlane differs.

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_eff requires 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:

  1. Fix the typed claim. State the claim as a typed proposition about a EntityOfConcern (Kind‑CAL, C.3).
  2. Declare claim scope. Write G explicitly using A.2.6 operators; avoid scope-by-wording.
  3. Declare interpretation conditions. State design or run stance, ReferencePlane, effective scheme, model-use basis, working situation, and validationMode ∈ {postulate, inferential, axiomatic} only where each changes this claim or its use. G already carries claim scope; do not add a generic Context identifier.
  4. Bind evidence. Attach evidence stubs and lane tags (TA/VA/LA) and validity windows / decay policy where applicable (B.3.3, B.3.4).
  5. Choose Γ-mode. Declare whether the support is series (required) or parallel (independent lines to the same claim).
  6. Compute R_raw. Use the weakest-link fold on the entailment spine; for parallel support, use max only with an explicit independence note.
  7. 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.
  8. Compute R_eff. Apply the declared penalty policies into R (never into F or G), 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.

PathIdEntailment spine (required supports)CL_minCL^k_minCL^plane_minPolicy-id(s) (Φ / Ψ / Φ_plane)R_rawR_effLane tags (TA/VA/LA)valid_until
P‑1c ← {c_a, c_b, c_c}23Φ=Φ_v1, Ψ=Ψ_v20.820.67{TA, LA}2026‑09‑30

Notes:

  • CL_*_min values are bottlenecks on the relevant path/dimension (no averaging).
  • valid_until is 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)=F5 because 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.

IDRequirementPurpose
CC‑C.2.2‑1 (Triad publication).Authors of a KD‑CAL location SHALL publish ⟨F,G,R_eff⟩ for one exact claim, rather than publishing R alone.Keeps the warrant attached to its claim and declared scope.
CC‑C.2.2‑2 (R-only penalty routing).A conforming implementation of KD‑CAL reuse SHALL satisfy INV‑C2.2‑1.Ensures declared relation losses reduce warrant without silently mutating expression or scope.
CC‑C.2.2‑3 (Weakest-link fold).A conforming implementation of KD‑CAL reliability propagation SHALL use DEF‑C2.2‑3 as the default for required supports, unless an alternative Γ‑fold is explicitly declared and remains monotone and conservative.Prevents confidence laundering through aggregation.
CC‑C.2.2‑4 (Relation visibility for reuse).Authors SHALL name every scope-translation, kind, plane, notation, source-local, model-use, or evidence-reuse relation traversed by the path and cite the fit or loss rule that affects R_eff.Makes each actual reuse loss auditable without inventing one crossing kind.
CC‑C.2.2‑5 (Penalty policy visibility).Authors or tooling SHALL reference the active policy identifiers used for Φ, Ψ, Φ_plane and the penalty aggregation rule Π (if not the default) when computing R_eff.Ensures repeatability and prevents hidden policy drift.
CC‑C.2.2‑6 (Type before scope).Authors and validators SHALL enforce WFC‑C2.2‑1 for scope composition operations.Prevents ill-typed scope algebra from creating incoherent reliability claims.
CC‑C.2.2‑7 (Evidence binding).Authors SHALL bind any asserted R_eff to evidence references that enable TA/VA/LA inspection, consistent with the assurance lane discipline (B.3.3) and evidence decay discipline (B.3.4).Keeps R grounded and updateable.
CC‑C.2.2‑8 (No ordinal arithmetic).Validators SHALL reject any computation that treats F or CL as if they were ratio-scale numbers (e.g., averaging, subtraction), except where explicitly permitted as a policy-defined penalty function on R. Validators SHALL also reject arithmetic over R_eff when it is published as an ordinal proxy ([M‑0/M‑1]).Enforces CSLC legality and prevents silent scalarisation.
CC‑C.2.2‑9 (Interpretation conditions declared).Authors SHALL distinguish design- and run-time assurance and declare ReferencePlane, effective scheme, model-use basis, working situation, and validationMode where each changes the claim or use.Makes interpretation auditable without a generic Context identity field.
CC‑C.2.2‑10 (Parallel requires independence).Authors SHALL treat max-composition of support paths as admissible only when an explicit independence justification is recorded; otherwise supports are treated as one entangled line and remain weakest-link.Prevents confidence inflation by double-counting correlated evidence.

Common Anti-Patterns and How to Avoid Them

Informative; non-binding.

Anti-patternSymptomWhy it failsHow to avoid / repair
Averaging assuranceA mean/weighted sum of R values is reported as “confidence”.It violates WLNK and is usually illegal scale arithmetic.Use weakest-link min on the entailment spine, then apply congruence penalties into R only.
Truth-by-scoreR=0.9 is treated as “the claim is true.”R is warrant strength, not ontological truth.Require explicit evidence links and scope; treat R as decision warrant only.
Scope launderingThe claim’s applicability grows by wording changes while G is unchanged.It silently widens scope, making comparisons meaningless.Use A.2.6 operators and treat scope changes as explicit revisions.
Relation launderingA claim or its evidence is reused after a changed scope, kind, plane, notation, local meaning, model use, or evidence basis, while R is carried over unchanged.It hides the actual change and its relation-specific loss.Name the direct relation or scope operation and recompute R_eff from its declared loss; stop if that relation is missing.
DesignRunTag chimeraDesign-time proofs and run-time telemetry are mixed as if they were the same evidence object.Evidence belongs to different stances and decays differently.Separate lanes and validity windows; treat crossings explicitly.
Ordinal arithmeticCL or F levels are averaged to produce a pseudo-score.It violates scale legality and produces non-auditable numbers.Keep CL/F ordinal; convert only via declared penalty tables on R.
Many-weak-makes-strongNumerous low-quality supports are combined to inflate confidence.It violates the weakest-link intent of conservative propagation.Default to min for required supports; allow max only with explicit independence arguments.

Consequences

Informative; non-binding.

BenefitsTrade-offs and mitigations
Comparability. Different claims can be compared in a disciplined way when F and G are explicit.Conservatism. Weakest-link propagation can feel pessimistic; mitigate by making support structure explicit and improving the weakest evidence.
Auditability. Relation-specific reuse loss is visible and localised to R.Overhead. Declaring the relations actually traversed and the evidence links is work; mitigate with templates and reuse of standard lane schemas.
Upgradeable knowledge. R can improve incrementally as evidence accumulates, without rewriting the claim.Scalar temptation. People still want one number; mitigate by requiring lane breakdown visibility behind the number.

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 R coordinate 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.

Practice claimPost‑2015 source anchorAlignment to this patternAdoption status
Verification and validation should be distinguished and tied to evidence quality, not to rhetoric.ASME V&V 40‑2018 (model credibility assessment).This pattern separates VA and LA lanes and binds R_eff to evidence and declared scope rather than to narrative confidence.Adopt, with KD‑CAL’s conservative fold as an explicit default.
Trustworthiness depends on intended use, affected risks, operating conditions, and explicit limits.NIST AI Risk Management Framework 1.0 (2023).This pattern makes claim limits explicit through G and applies CL penalties only through the actual relation used by a reuse path.Adapt, because FPF treats declared relation loss as an epistemic penalty, not only as an organisational risk statement.
Safety arguments should make claims, evidence, and assumptions explicit and reviewable.UL 4600 (2020) and related assurance-case practice in autonomous systems.This pattern treats R as an auditable warrant signal whose inputs are explicit evidence items; any reuse names the exact relation traversed and its declared loss.Adopt, while remaining notation-independent and avoiding tool mandates.
Empirical results should be accompanied by structured provenance and usage conditions to enable reuse and critique.“Datasheets for Datasets” (Gebru et al., 2018) and “Model Cards” (Mitchell et al., 2019).Scope discipline and lane reporting make empirical warrant reusable only when the exact evidence, claim, use, conditions, and any evidence-reuse or dataset relation are explicit; that relation's declared loss routes to R_eff only.Adopt, with relation-specific congruence penalties as the reuse control mechanism.
Reproducibility requires packaging evidence and making it re-checkable by others.ACM Artifact Review and Badging (updated practices post-2015) and The Turing Way (2019).This pattern treats evidence as inspectable across TA/VA/LA lanes and lets reliability decay when evidence becomes stale or non-replayable.Adapt, because FPF treats freshness and relation-specific reuse losses as first-class calculus inputs.
Strong inference benefits from “severe tests” rather than from accumulation of weak confirmations.Mayo (2018) on severity in statistical inference.Weakest-link propagation and explicit scope declarations discourage superficial confirmation piling and encourage explicit, discriminating evidence.Adapt, because KD‑CAL is agnostic to frequentist vs Bayesian inference but requires auditability.

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:

  1. teams collapse several facets into one maturity story;
  2. F is silently misused as a surrogate for articulation, closure, anchoring, and representation factors;
  3. thresholds are published as vague readiness statements instead of explicit facet conditions;
  4. source phenomena, governed epistemes, publication forms, publication faces, and carriers are conflated;
  5. bridge and endpoint work inherit under-described upstream states.

Forces

ForceTension
Multi-facet fidelity vs readable publicationThe chart must preserve several independent facets without becoming unreadable.
Stable basis vs local thresholdsBasis slots should stay stable across contexts, while thresholds remain context-local.
Position semantics vs publication semanticsA position claim is not identical to the source phenomenon, publication form, or carrier through which it is currently expressed.
Comparability vs non-collapseTeams need to compare positions, but not by flattening them into one pseudo-scale.
Bridge reuse vs local authorityCross-context work benefits from a stable upstream chart, yet each context keeps local threshold authority.

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.3 for F;
  • C.2.4 for articulation explicitness;
  • C.2.5 for language-state closure degree;
  • C.2.6 for language-state anchoring mode;
  • C.2.7 for 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.Episteme publication 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 F statement.

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-1 U.LanguageStateSpace SHALL be treated as the declared language-state chart over U.CharacteristicSpace, not as a rival kernel space and not as a disguised F progression.
  • CC-C.2.2a-2 Published positions SHALL cite explicit facet subject patterns when those positions matter for movement, routing, or endpoint entry.
  • CC-C.2.2a-3 Position claims SHALL use slot-explicit values, ValueSet claims, or intervals; uncertainty SHALL NOT be hidden inside stage words such as ready, early, or mature.
  • CC-C.2.2a-4 A position claim in the chart MUST NOT be conflated with the current ground, witness, publication form, publication face, or carrier.
  • CC-C.2.2a-5 Cross-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-6 Corridor 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-7 If 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 F to 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.

Claim needSoTA practice (post-2015)Primary source (post-2015)Alignment with C.2.2aAdoption status
Complex technical state should be published through explicit views, viewpoints, and model distinctions rather than one implicit maturity word.Contemporary architecture-description governance separates source architecture description, view, viewpoint, and correspondence evidence instead of letting one visible adjective stand in for the whole state.ISO/IEC/IEEE 42010:2022C.2.2a adopts this by keeping chart position, publication form, face, and carrier in distinct slot groups and by rejecting stage-language as a surrogate coordinate system.Adopt.
Governance-relevant readiness requires context-local profiles and thresholds, not one global adjective.Current governance and risk frameworks use explicit profiles, thresholds, and scoped conditions rather than one blanket readiness label.NIST AI RMF 1.0 (2023)C.2.2a adopts the threshold-publication discipline and rejects the popular shortcut where ready, early, or mature replaces explicit slot conditions.Adopt/Reject-popular-shortcut.

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.3C.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:

  1. Does the row name the positioned episteme publication rather than a ground, form, face, or carrier?
  2. Does it state every facet that can change the named next action and mark a relevant unknown honestly?
  3. Are the grounds and any relied-on local threshold recoverable?
  4. Does the row say what action is allowed, blocked, or still undecided without pretending to authorize it?
  5. 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.4C.2.7, A.16, A.16.0A.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:

  1. Rigor is narrated inconsistently. Different contexts invent local mode/tier language with no shared comparability.
  2. Status and rigor collapse. Something accepted, published, or approved is mistaken for something precisely expressed.
  3. Expression changes are hidden. A move from sketch to predicates or from executable model to proof is not recorded as a distinct content change.
  4. 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.
  5. 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

ForceTension
Readability vs precisionNatural language is fast and legible; formal systems are unambiguous and checkable. F needs a gradient, not a cliff.
Local freedom vs shared comparabilityContexts need local exemplars and thresholds, but cross-context reasoning requires one stable characteristic.
Exploration vs assuranceEarly work must be allowed at low F, while high-assurance work needs explicit higher anchors.
Notation diversity vs semantic stabilityDifferent symbol systems may express the same rigor level; notation choice alone must not redefine F.
Thin characteristic vs rich practiceThe core characteristic should stay simple, while still supporting concrete guidance, examples, and review discipline.

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 (abbreviated F in 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:

  • F is not G; scope remains governed by U.ClaimScope and other USM structures.
  • F is not R; evidence, warrant strength, and decay remain assurance concerns.
  • CL and bridge losses affect R, not F.
  • Changes in notation, carrier, or rendering form do not change F if 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 F value.
  • Thresholds that depend on rigor should be written explicitly as F >= Fk conditions.
  • Any raise or lowering of F is a content change, not a status-only change.
  • F remains 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-1 Every normative U.Episteme SHALL declare exactly one U.Formality value, either a default anchor or a local sub-anchor explicitly docked to one.
  • CC-F-2 F SHALL be treated as an ordinal characteristic; arithmetic over F values is invalid.
  • CC-F-3 Higher F SHALL mean greater or equal strictness of expression, not greater truth, trust, or scope.
  • CC-F-4 Contexts MUST NOT publish alternative "formality modes" or "tiers" as surrogates for F.
  • CC-F-5 Local sub-anchors SHALL preserve the global ordering and the parent anchor meaning.
  • CC-F-6 The episteme-level F of a composite episteme SHALL be bounded by the least-formal essential support on the relevant support path.
  • CC-F-7 Implementations MUST NOT average F values numerically.
  • CC-F-8 Changes in G, R, or CL SHALL NOT change F unless the expression form itself changes.
  • CC-F-9 Cross-context transport SHALL preserve the attributed F; if the receiving context rewrites the claim materially, it becomes a new episteme with its own F.
  • CC-F-10 Translation loss, bridge loss, and plane crossings SHALL affect R rather than being hidden as F changes.
  • CC-F-11 Assigned F values SHALL be justifiable by observable content such as explicit predicates, executable semantics, or machine-checked proofs.
  • CC-F-12 Declaring a tool or notation SHALL NOT by itself justify a higher F unless the content satisfies the target anchor semantics.
  • CC-F-13 Status labels such as Draft, Approved, or Published MUST NOT substitute for F.
  • CC-F-14 A context that uses F in gates or policies SHALL write those thresholds explicitly.
  • CC-F-15 Language-state facets such as articulation or closure MUST NOT be hidden as pseudo-levels of F.

Common Anti-Patterns and How to Avoid Them

Anti-patternWhat it looks likeHow FPF prevents it
Status leakageAn episteme is called highly formal because it is approved or published.CC-F-13 keeps status and formality separate.
Tool-worshipA notation, prover, or execution harness is named, so the episteme is rated high-F without checking the content.CC-F-11 and CC-F-12 require observable semantic grounds.
Appendix inflationA small high-formality appendix is used to advertise the whole episteme as high-F.CC-F-6 keeps the whole episteme capped by the least-formal essential support.
Proxy ladderA local context invents "bronze / silver / gold" or "ready / mature / final" and uses it instead of F.CC-F-4 rejects rival ladders.
Characteristic captureArticulation, closure, scope, or evidence is spoken of as if it were part of F.CC-F-8, CC-F-10, and CC-F-15 keep the characteristics orthogonal.

Consequences

BenefitTrade-off / Mitigation
Shared rigor language. Cross-domain publication units can be compared by one stable expression characteristic.Authors must learn the anchor ladder and declare F explicitly.
Safer composition. Composite epistemes stop inheriting a misleadingly high rigor label from one polished segment.Reviewers must identify essential support rather than read only visible polish.
Cleaner governance. Thresholds can be written as explicit F conditions instead of vague maturity labels.Contexts must translate old local language into the canonical characteristic.
Better interaction with other characteristics. F, G, R, and language-state facets remain distinct.Authors lose the convenience of one master-ladder story; that loss is deliberate.

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 F coordinate of the typed F-G-R assurance tuple.
  • Builds on: characteristic machinery from A.18 / A.19 and 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, and C.2.7.
  • Coordinates with: C.19.2 when a declared use asks whether increasing rigor of expression or selecting/configuring a formal apparatus repays application work. F measures 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

  1. Can a competent reader misread the claim materially? If yes, the expression is likely at F0-F2; if not, it may be F3 or above.
  2. Are the critical claims visible as explicit predicates or invariants? If yes, the expression is at least F4.
  3. Does the expression have declared executable semantics? If yes, it is likely in the F5-F6 region.
  4. Would a logic kernel or type checker reject an incorrect change to a core claim? If yes, the expression is likely F7-F8, or F9 if 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 F ladder.
  • 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

ForceTension
Thin profile bundle vs practical coordinationKeep the bundle small, but still give one stable place where the language-state facets are named together.
Reuse vs duplicationReuse A.18/A.19 characteristic machinery and E.18 transition-structure publication rather than building a rival calculus.
Local thresholds vs cross-context comparabilityContexts need local thresholds, but the facet names must stay stable enough for bridge work and viewpoint bundles.

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.Formality from C.2.3
  • articulationExplicitnessRef -> U.ArticulationExplicitness from C.2.4
  • languageStateClosureDegreeRef -> U.LanguageStateClosureDegree from C.2.5
  • languageStateAnchoringModeRef -> U.LanguageStateAnchoringMode from C.2.6
  • languageStateRepresentationFactorBundleRef -> U.LanguageStateRepresentationFactorBundle from C.2.7
  • thresholdRefs? -> context-local threshold declarations over the named facets
  • routeNotes? -> 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, or U.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-1 A language-state facet profile SHALL reference the patterns that define its facets rather than invent local unnamed factors.
  • CC-C.2.LS-2 C.2.LS MUST NOT redefine F or create a second formality progression.
  • CC-C.2.LS-3 Thresholds that matter for routing, reopening, or lexical repair SHALL be published on explicit facets.
  • CC-C.2.LS-4 Trajectory accounts that rely on facet profiles SHOULD reuse A.16 move kinds and E.18 transition-structure publication rules.
  • CC-C.2.LS-5 Composite labels such as early, settled, or ready SHALL NOT stand in for the explicit facet bundle when those states matter operationally.
  • CC-C.2.LS-6 Composite readings, overlays, and route notes SHALL remain decomposable into named facets and MUST NOT behave as hidden master factors.
  • CC-C.2.LS-7 A 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/late as a master scale. Split the judgement into the named facets.
  • Formality capture. Letting F stand in for closure or articulation. Publish those facets explicitly.
  • Bundle inflation. Turning U.LanguageStateFacetProfile into a second A.19. Keep it thin and referential.
  • Opaque readiness. Using words such as ready or mature without 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.16 for admissible moves, the applicable pattern for a downstream definition or test, the applicable gate or Work pattern for those claims, and an authoritySourceRef only 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.

Claim needBounded comparisonExact sourceUse in C.2.LSDisposition
Readiness claims should stay scoped instead of collapsing into one global adjective.A profile can state scoped conditions and local thresholds rather than one blanket readiness label.NIST AI RMF 1.0 (2023)Require explicit facet-level thresholds and reject a polished profile label as a substitute for the facet values.Adopt/Adapt.
A publication can keep several named description elements visible without making their container identical to those elements.Architecture-description vocabulary distinguishes named elements and their correspondence in a published description.ISO/IEC/IEEE 42010:2022Use this only as a narrow publication comparator; it does not establish the language-state facet ontology.Narrow comparator only.

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.9 for any Bridge and bounded-use claim, and F.9.1 only 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/F3 because the note is structurally controlled but still lightweight;
  • AE = AE2 because candidate anchors are visible but not yet fully relation-shaped;
  • CD = CD1 because several routes remain live;
  • LanguageStateAnchoringMode = AM.OperatorLoop because 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:

  1. start from the local authoring problem rather than from a memorized progression;
  2. name the facet refs explicitly;
  3. add threshold refs only when a threshold changes routing, repair, or another operative decision;
  4. 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, and LanguageStateRepresentationFactorBundle;
  • any threshold refs that substantively affect routing, repair, bridge interpretation, or review load;
  • the local relation to F when readers might otherwise treat F as 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, or B.5.2.0 actually match the facet bundle;
  • if the profile crosses a Bridge or viewpoint boundary, did the author use F.9 for 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

ForceTension
Early capture vs false precisionCapture low-articulation cues without pretending they already have stable slots.
Comparability vs local nuanceKeep a shared ordinal discipline while allowing context-local threshold declarations.
Branch readiness vs exploratory opennessSay when a direct semantic branch can receive the episteme without forcing every cue through relation repair.

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

AnchorReadingTypical admissible publication state
AE0a cue is felt or observed but cannot yet be stated as a stable question or contrastpreserve the source or cue without claiming a route
AE1a stable cue, question, contrast, or disturbance is nameablean early cue publication becomes useful
AE2candidate anchors, participants, actions, fields, or meanings are visible, but the branch or structure remains partialroute candidates and missing pieces can be stated
AE3the governed claim structure is recoverable enough to choose its direct semantic branchthe relevant repair or authoring pattern may receive it if the local threshold is met
AE4a complete branch-appropriate form is publishable with the participants, conditions, and bounds needed by the current usethe direct subject pattern can check or use the publication
AE5the meaning remains stable in one named receiving use, and a later change can be reviewed without reconstructing it from the sourcethe receiving use is straightforward, though not automatically true, closed, trusted, or authorized

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

  • AE may state an entry threshold for the direct semantic branch named by the current use.
  • A.6.P is only the relational branch. A note does not enter it merely because a table, arrow, or sentence looks relation-shaped.
  • AE may justify why an episteme remains in A.16.1 or B.4.1 while 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.
  • AE shall not stand in for closure, confidence, truth, trust, or authorization. High F does not imply high AE, and high AE does not imply high F.

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-1 AE SHALL NOT be treated as a synonym for F.
  • CC-C.2.4-2 A route change SHOULD require the local articulation threshold declared for that receiving branch; A.6.P applies only to a current relational branch.
  • CC-C.2.4-3 AE judgements 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-4 Raising AE SHALL NOT be described as if it automatically settled closure, truth, trust, authority, or admissibility.
  • CC-C.2.4-5 Relation-shaped notation SHALL NOT raise the level or select A.6.P when the actual claim belongs to another branch.

Common Anti-Patterns and How to Avoid Them

  • Formal-looking but semantically thin. High F, low AE. Declare both.
  • Mystical cue immunity. Low AE is 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, and C.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.P to 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 under C.2.1;
  • for an admitted dated Work occurrence, use A.15.1;
  • for a representation claim, use C.2.P.DR, adding A.6.3.RT only when a representation transition is current;
  • for an abductive prompt or explicit open question, use B.5.2.0 or the direct question pattern;
  • for a Characteristic or Scale claim, use A.17 and A.18, with C.16.P when its scalar wording hides the construction;
  • for an ordinary domain claim, keep the episteme publication under C.2.1 and 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 Work before an occurrence is admitted;
  • if AE justifies 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

ForceTension
Commitment vs explorationPreserve open search without losing auditability.
Stability vs reversibilityAllow closure increases, but also admissible reopening and reframing.
Authority vs explicit retreatLet strong closure matter, but keep visible the moves that relax it.

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

AnchorReadingTypical governance effect
CD0exploratory-openbroad rival space remains live
CD1weakly stabilizedsome contrasts are present, but rival routes remain normal
CD2narrowed candidate spaceexplicit rivals remain, but the field is meaningfully reduced
CD3selected route or framingone route is chosen, though reopening remains routine
CD4publication- or operation-fixed under guardchanges require named justification
CD5strongly fixedrelaxation requires an explicit A.16.2 move and governance note

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-1 Closure SHALL be declared independently from F and AE when it matters for routing, docking, or reopening.
  • CC-C.2.5-2 Reopen/backoff moves SHALL cite the prior closure state they are relaxing.
  • CC-C.2.5-3 Strong-closure states SHOULD name the guard, governingPatternRef, or authoritySourceRef that makes the closure binding.
  • CC-C.2.5-4 Endpoint 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 CD explicitly.
  • 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, or authoritySourceRef makes 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

ForceTension
Embodiment vs abstractionPreserve embodied and operator-facing cases without making them mystical exceptions.
Small core vs real diversityKeep the core compact while allowing multiple admissible anchoring regimes.
Comparability vs oversimplificationCompare anchoring regimes without flattening them into text-vs-nontext slogans.

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

ModeReadingTypical evidence anchor
AM.EmbodiedFeltbodily or kinesthetic anchoring matters directlyembodiment note, felt trace, human witness
AM.TraceAnchoredtraces, logs, telemetry traces, or observations anchor the epistemetrace references, measured events, observations
AM.ModelLatentlatent or internal model state is the key anchormodel-state refs, probe results, latent summaries
AM.DocumentMediateddocument or description is the principal anchordocuments, cards, method-description text
AM.OperatorLoopthe episteme is directly tied to operator intervention or console controloperator witness, console event, policy hook
AM.Mixedmore than one anchoring mode matters substantivelyexplicit component list and why the mix matters

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-1 Anchoring mode SHALL NOT be inferred from publication phrasing alone when it matters for source use, reliance, or bridge interpretation.
  • CC-C.2.6-2 Embodiment-sensitive or operator-loop cases SHOULD declare the embodiment or operator anchor explicitly.
  • CC-C.2.6-3 U.LanguageStateAnchoringMode MUST NOT be collapsed into U.LanguageStateRepresentationFactorBundle.
  • CC-C.2.6-4 Mixed-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.9 for any Bridge and bounded-use claim, and F.9.1 only 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

ForceTension
Comparability vs reductionismAllow comparison without compressing several factors into one slogan.
Compact core vs extensibilityKeep a minimal starter bundle while leaving room for domain-specific refinements.
Representation vs anchoringDescribe how the current episteme is represented without hiding what it is anchored to.

Solution

U.LanguageStateRepresentationFactorBundle is a factor bundle, not one scalar characteristic. The minimal core starter set is:

  • U.LocalityDistribution
  • U.Sparsity
  • U.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

FactorQuestion it answersTypical values
LocalityDistributionIs the representation concentrated in local units or distributed across many units?local / mixed / distributed
SparsityHow concentrated are activation, representation use, or descriptive marks?sparse / mixed / dense
SymbolicityHow explicit are the symbolic structures and tokens?symbolic / mixed / subsymbolic

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-1 LanguageStateRepresentationFactorBundle SHALL be published as a factor bundle, not as a hidden scalar.
  • CC-C.2.7-2 Local aliases such as EncodingBasis MAY exist only with an explicit docking to the governed factors.
  • CC-C.2.7-3 Representation factors MUST NOT silently replace LanguageStateAnchoringMode or LanguageStateClosureDegree.
  • CC-C.2.7-4 New 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 EncodingBasis or 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.9 for any Bridge and bounded-use claim, and F.9.1 only 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.10 evidence 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, dated U.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, use E.18 directly.
  • If the evidence relation or provenance relation for a claim is already current, use A.10 directly.
  • 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, use A.3.2.
  • If the current claim concerns operation algebra, laws, admissibility predicates, transport, audit, or governing-definition assignment, use A.6.1 or E.20.
  • If the current claim concerns planned work or dated work, use A.15.2 or A.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:

  1. Graph path becomes work route. A path or path slice in E.18 is treated as an ordered work narrative, even when no work occurrence, work plan, or method description is current.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Mechanism, method, and work collapse. A method-like expression is repaired to method or mechanism by vocabulary rather than by the current claim: way of doing, description, formal substrate, law-governed mechanism, plan, occurrence, evidence, or quote-only wording.

Forces

ForceTension
Representation usefulness and action overreadGraphs, queries, predicates, and dashboards are useful precisely because they expose structure; their shape does not supply hidden work, permission, or release.
Legitimate path words and metaphor repairA.10 evidence path, E.18 graph path, and carrier file paths may be legitimate; path becomes a defect only when it carries a stronger action or authority claim by metaphor.
Method generality and subject disciplineAlgorithms, programs, solver models, proofs, SOPs, and process models can all be useful, but first identify the direct object or relation, the current claim, and any exact representation use. Select U.MethodDescription only after the claim-bearing episteme passes the A.3.2 membership test; representation form alone selects nothing.
Declarative and imperative labels are too crudeCurrent programming and process practice includes effects, handlers, constraint models, object-centric events, e-graphs, and process theories; the repair names the direct object or relation, current claim, any representation use, and subject pattern rather than choosing one programming-paradigm slogan.
Subject pattern and local repairWhen E.18, A.10, A.3.1, A.3.2, A.6.1, A.15.2, A.15.1, E.17, or another pattern already governs the current claim, this pattern names only the overread and leaves the next claim to that pattern rather than duplicating it.

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:

  1. 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.
  2. 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.
  3. 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 none only when the receiving use needs an inspectable account of that distinction.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. State the blocked stronger action claim. Block only the stronger claim that is not recoverable.
  9. 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:

DeclarativeRepresentationRepair:
  VisibleExpressionOrArtifact:
  CurrentDirectObjectOrRelation:
  RepresentationOrCorrespondenceUse: <exact relation and represented target> | none
  SourceOrPublicationRelation:
  TemptingStrongerActionClaim:
  RecoveredGoverningPattern:
  RetainedUse:
  BlockedStrongerActionClaim:
  StopOrReopenCondition:

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?

Visible expression or artifactExact current direct object or relationRepresentation or correspondence useStronger action claim blocked
highlighted graph pathexact E.18 graph path or PathSlice, with any flow valuation kept separatethe graphic rendering corresponds to that path when the relation is current; otherwise none when the PathSlice itself is under inspectionno prescribed route, valve work, or release by the highlight
dashboard tileexact status or state value with its bearer and value frame, plus any current source or publication relationthe tile represents that value only through an exact current relation; otherwise none when the publication face itself is the direct objectno gate passage or release permission from green appearance
evidence-path expressionexact A.10 evidence or provenance relation for the named claim or effecta diagram may represent that relation; otherwise none when the relation itself is currentno approval, permission, assurance, or release from path shape
solver fileexact publication form or carrier-side object, and whichever formal substrate, claim-bearing episteme, method, mechanism declaration, plan, run, or evidence relation is independently currentthe solver expression corresponds to separately identified claims or a formal object when that relation is stated; otherwise noneno method, mechanism, performed work, result, or evidence by file form or executability
publication tableexact publication face or form and source relation, with table values or claims kept under their subject patternsthe table corresponds to a separately identified object or claim only when the exact relation is current; otherwise noneno evidence, approval, gate passage, or action authority from table layout

Subject pattern selection

If recovery shows...Use this subject patternKeep this boundary
graph object, graph path, PathSlice, crossing, flow valuation, transformation-flow structure relation, or graph expression over that structureE.18, E.18.2, or E.18.1 when P2W carry-through is currentGraph structure or path structure is not work route, method narrative, evidence result, or pattern dispatch by layout.
evidence relation or provenance relation for a claim, effect, or reliance useA.10Evidence path is not approval, permission, gate passage, release, safety, work occurrence, or assurance by itself.
state, status value, readiness, validity, or predicate-like value whose bearer and value frame is hiddenA.19.SPR or the direct status-value or state-value patternA predicate or state-like value is not a workflow, gate, or proof unless the subject pattern says so.
publication face, source expression, generated explanation, dashboard face, publication unit, or source-chain relationE.17, E.17.EFP, C.2.P, A.15.4, or source-use pattern named by valuePublication and source visibility do not create work, evidence, authority, release, or gate passage.
mathematical representation, formal object, formal substrate, invariant, or mathematical-lens outputA.6.0, C.29, or direct mathematical patternMathematical representation is not method, mechanism, proof of project result, or work execution until that claim is separately recovered.
context-local semantic way of doingA.3.1 U.MethodA method claim is not closed by code, diagram, proof script, plan, run, or mechanism declaration; use E.10.ARCH:3.1 only to recover the project concern and then recover each linked typed value under its own subject pattern.
already identified U.Episteme with one admitted U.Method as its exact EntityOfConcern and at least one substantive claim about that method as a way of doingA.3.2 U.MethodDescriptionCode, SOP, proof-script, solver-model, process-model, protocol, recipe, and diagram forms are clues only. A name, citation, approval, runnable form, or representation correspondence does not establish membership.
law-governed operation algebra, laws, admissibility predicates, transport, audit, realization, or governing-definition assignmentA.6.1 and E.20Mechanism meaning is not selected by saying "algorithm" or "method"; it needs mechanism fields.
planned work, intended window, resource budget, acceptance criterion, or source “role requirement”A.15.2 U.WorkPlan for the plan. Resolve a “role requirement” separately to its exact local system-role kind, separate System-classification judgment, future assignment condition, capability, participant relation, or other direct condition; if unresolved, use E.10.ROLE.A plan is not a Method, MethodDescription, evidence, gate passage, performed Work, or assignment occurrence. A required kind or condition does not create the future assignment.
exact dated Work occurrenceRecover every exact actual performer and its obtaining A.2.1 system-role assignment through A.13, then let A.15.1 U.Work independently identify the dated occurrence, enacted Method, time, and containing System. A representation claiming the exact Work keeps every actual performer named or recoverable. Keep the underlying assignment facts recoverable; include an assignment identifier in the representation only when the receiving use needs it. Add an F.6 relation through that same obtaining assignment only when the representation or receiving use expressly represents precise assignment-bound attribution. Missing or failed F.6 leaves the Work intact and blocks only that attribution.The Work occurrence is not its trace, record, binding, resource use, result, diagram, plan, MethodDescription, source cue, or evidence path.
run trace or performed-work recordC.2.1 for the exact trace or record episteme, plus its direct description, publication, source-use, or evidence-use pattern only when that claim is currentThe episteme may designate exact W, RA, holder S, and performedUnderAssignment(W, RA) when it makes that attribution; it neither is the Work occurrence nor makes the relation obtain.
concrete parameter or participant bindingthe exact direct subject-relation pattern, or A.6.1 for one independently identified operation application and its actual argument or result bindingA declaration, call position, trace field, or type-compatible token establishes no actual binding.
performed resource usethe exact direct resource-use relation involving the already identified Work occurrence; use B.1.6 only when aggregation is currentResource use is a separately obtaining relation, not a Work field, record field, or result.
result or outputidentify the exact result entity or episteme first; use A.15.PROD when production, entity inception, or production completion is current, and A.6.RCD only when the needed direct result relation has no current governorA binding, record field, Work occurrence, or nearby output label does not identify the result or establish production.
FPF pattern application, pattern relation, neighboring-pattern relation, or placement cueE.8, F.19, E.10.ARCH, or the direct pattern relation named by valuePattern relations are declarative references or applications, not exits, receivers, routes, calls, owners, homes, or dispatches.
quoted source wording or ordinary navigationquote-only or ordinary proseDo not repair ordinary words into FPF terms when no FPF-governed claim is being made.

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:

Current objectSubject pattern
constraint-governed U.Structure across several constrained lociA.22.CGUS
transformation-flow structure, path, path slice, crossing, guard, or valuationE.18 and E.18.3 when unfolding use is current
description, diagram, table, graph, route card, slide, README line, or narrative that renders the structureConstraintGovernedUnfoldingStructureDescription@Context, DemonstrativeUnfoldingSlice@Context, A.6.3.NAR, E.17, or the direct description subject pattern
reusable semantic way of doing, or a claim-bearing episteme that passes the A.3.2 MethodDescription membership testA.3.1 for the method; A.3.2 for the qualifying episteme
work plan, work readiness, or performed workA.15 family
evidence, assurance, gate, decision, architecture, publication, or currentness-refresh claimthe subject pattern for that claim

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:

Current claimSubject pattern
context-local semantic way of doing a transformation or enactmentA.3.1 U.Method
transformation or enactment kind stated inside a current method claimkeep it as one method-identity field or claim content under A.3.1; it is not a peer U.Method
independently grounded actual bounded changeA.3.4 U.Transformation
possible, required, desired, intended, planned, predicted, modeled, or asserted changekeep it as claim content under the exact requirement, architecture, capability-gap, functional-view, method, work-plan, dynamics-model, publication, or other subject pattern; wording alone admits no U.Transformation
already identified episteme whose exact EntityOfConcern is one admitted U.Method and whose claims include at least one substantive way-of-doing claimA.3.2 U.MethodDescription
formal substrate, signature, postulates, laws, or mathematical declarationA.6.0; use C.29 when mathematical-lens use is current
operation algebra, admissibility predicates, transport, audit, realization, or mechanism-governing-definition assignmentA.6.1 and E.20
planned workA.15.2 U.WorkPlan
dated performed workA.15.1 U.Work
evidence relation or provenance relation for a claimA.10
wording quoted from source with no FPF-governed usequote-only source wording

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:

DeclarativeRepresentationRepair:
  VisibleExpressionOrArtifact: P2W graph expression with a highlighted path or path slice
  CurrentDirectObjectOrRelation: exact E.18 `PathSlice` and E.18.1 carry-through relation among the named records when those objects are current
  RepresentationOrCorrespondenceUse: C.29 correspondence from this P2W graph expression to the exact E.18 `PathSlice`
  SourceOrPublicationRelation: none
  TemptingStrongerActionClaim: ordered work route for the team
  RecoveredGoverningPattern: E.18.1, with A.15.2 or A.15.1 only if planned or dated work is current
  RetainedUse: selected graph path and carry-through relation for inspection
  BlockedStrongerActionClaim: no work route or prescribed workflow by path shape alone
  StopOrReopenCondition: reopen when path, source currentness, graph edition, or intended work relation changes

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:

DeclarativeRepresentationRepair:
  VisibleExpressionOrArtifact: reactor-cooling heat-flow graph with one highlighted preserved path
  CurrentDirectObjectOrRelation: exact E.18 heat-flow path or `PathSlice`; keep boundary conditions and any flow valuation under their subject patterns
  RepresentationOrCorrespondenceUse: C.29 correspondence from this reactor-cooling graph rendering to the exact selected E.18 heat-flow `PathSlice`
  SourceOrPublicationRelation: none
  TemptingStrongerActionClaim: graph path authorizes physical valve-change work
  RecoveredGoverningPattern: E.18 and C.29 for graph and lens use; A.21, A.10, A.15.2, and A.15.1 only if gate, evidence, work plan, or dated work is current
  RetainedUse: graph structure for comparison, model review, and source-finding
  BlockedStrongerActionClaim: no release, gate passage, physical intervention, or work occurrence by highlighted path alone
  StopOrReopenCondition: reopen when gate decision, source currentness, measurement boundary, or work plan becomes current

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:

DeclarativeRepresentationRepair:
  VisibleExpressionOrArtifact: CRISPR guide-selection table with off-target scores and candidate ranking
  CurrentDirectObjectOrRelation: candidate-guide comparison and exact characteristic values under C.16 or A.19; add an A.10 evidence relation only when it independently obtains
  RepresentationOrCorrespondenceUse: C.29 correspondence from this table's candidate and off-target-score representation elements to the exact candidate-guide comparison and exact characteristic values named above
  SourceOrPublicationRelation: none
  TemptingStrongerActionClaim: ranked row approves biological intervention
  RecoveredGoverningPattern: C.16 or A.19 for characteristics when current; A.10 for evidence; A.15.2 for experimental work plan; A.21 or authority pattern only if approval or gate claim is current
  RetainedUse: source-finding, candidate comparison, and constraint review
  BlockedStrongerActionClaim: no edit approval, work occurrence, safety claim, or gate passage from table rank alone
  StopOrReopenCondition: reopen when protocol, gate decision, evidence path, lab classification or assignment, exact GrantedPermissionRelation@Context or direct authority result, or dated lab Work becomes current; unresolved “role authorization” goes to E.10.ROLE, and an unsupported stronger permission or authority claim returns missing-governor

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

CheckRequirement
CC-C2PDR-1A repair separately names the visible expression or artifact, the exact current direct object or relation, and any current representation or correspondence use. Record none for the representation branch only when the receiving use needs an inspectable account. No field types structures, relations, formal objects, publication objects, or carrier-side objects as one family of representation kinds.
CC-C2PDR-2When a representation use is current, the repair names its exact represented EntityOfConcern or claim and, for a mathematical-lens or selected-structure use, the preserved and lost structure and admitted and blocked uses required by its subject pattern; any current source or publication relation is named independently. When RepresentationOrCorrespondenceUse is none, no represented-target, preserved/lost-structure, or lens-use account is required.
CC-C2PDR-3The tempting stronger action claim is explicit: route, call, dispatch, invoke, run, flow, send, receive, authorize, release, prove, prescribe, execute, select, pass a gate, or record work.
CC-C2PDR-4The recovered subject pattern is named by value, or the case is demoted to quote-only, ordinary prose, reduced-use cue, blocked use, or incomplete rewrite.
CC-C2PDR-5Legitimate A.10 evidence path, E.18 graph path, PathSlice, carrier file path, URL, or mathematical path use is preserved when its exact evidence, provenance, graph, carrier/source, or mathematical object or relation is current.
CC-C2PDR-6Method-like and algorithm-like wording identifies the visible expression, direct object or relation, current claim, and any exact representation use before selecting a subject pattern. If A.3.2 is selected, one already identified C.2.1 episteme has one admitted U.Method as its exact EntityOfConcern and at least one substantive way-of-doing claim; code, SOP, proof, solver, workflow, process, procedure, recipe, protocol, model, or diagram form alone does not pass.
CC-C2PDR-7An E.10.ARCH:3.1 project-concern recovery may connect method, mechanism, formal-substrate, work values, evidence relations, source relations, gate relations, or result relations, but each connected value keeps its own subject pattern and typed claim.
CC-C2PDR-8The repair leaves one retained use and one blocked overread; type-correct but inert wording is incomplete.
CC-C2PDR-9The pattern does not become a general representation theory, API pattern, schema pattern, legal framework, workflow framework, or generic admissibility pattern.
CC-C2PDR-10Subject patterns keep their invariants. This pattern only restores representation use and blocked overread before those patterns carry their own claims.

Common anti-patterns

Anti-patternSymptomRepair
Path word deletionEvery path is replaced or avoided.Preserve legitimate A.10, E.18, carrier, mathematical, URL, and quoted-source path uses; repair only hidden stronger claims.
Imperative metaphor as ontologyRepresentations "route", "call", "dispatch", "receive", "invoke", or "flow" by prose habit.Separate the visible expression, direct object or relation, exact representation use or none, and blocked stronger action claim; then write the direct relation declaratively.
Algorithm as method or description by formCode, solver model, proof script, workflow, SOP, recipe, protocol, or diagram form is treated as proof of U.Method or U.MethodDescription.Use A.3.1 only for the recovered reusable way of doing. Use A.3.2 only for an already identified claim-bearing episteme with one admitted U.Method as exact EntityOfConcern and a substantive way-of-doing claim; otherwise keep the representation or other claim with its subject pattern.
Mechanism by prestigemechanism is used because the word sounds more rigorous than method or algorithm.Require operation algebra, laws, admissibility predicates, transport, audit, realization, or governing-definition assignment.
Dashboard as gateGreen status, dashboard tile, score, or status label becomes permission or release.Recover source relation or publication relation, state-family value, evidence relation, and gate or release pattern when current.
Pattern dispatcherPattern relations are written as routes, exits, receivers, calls, owners, or homes.Write declarative neighboring-pattern boundary or application relation; use E.8 and F.19 together when both publication-form and phrase-apparatus claims are live, or use the one subject pattern when only one claim is live.
Generic representation theoryThe repair tries to classify every representation in FPF or becomes an API pattern, schema pattern, legal framework, workflow framework, or generic admissibility pattern.Stop at the representation-use field set and use the subject pattern for the current claim.

Relations

  • Builds on: E.10, E.10.ARCH, C.2.P, A.7, E.17, E.8, and F.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.P for one recurring case: declarative representation and imperative-metaphor overread.
  • Used by: E.10.ARCH applicability-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.1 keeps 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.

Exact source or practice anchorSource-use function or relationWhat it changes here
E.10, E.10.ARCH, and C.2.PCurrent FPF precision-restoration architecture.This pattern is a bounded child realization under C.2.P, not a new umbrella pattern.
A.10 and E.18Local FPF subject patterns for evidence paths, provenance paths, transformation-flow graph paths, and path slices.Path wording is legitimate when the exact evidence or provenance relation, graph path, or PathSlice is current; the defect is stronger overread.
A.3.1, A.3.2, A.6.0, C.29, A.6.1, E.20, A.15.2, and A.15.1Local FPF method-like and algorithm-like wording discipline.The repair identifies the represented object and current claim before choosing method, qualifying method-description episteme, formal substrate, mechanism, work plan, or work occurrence; representation form alone chooses none of them.
Stefano Gogioso, Vincent Wang-Mascianica, Muhammad Hamza Waseem, Carlo Maria Scandolo, and Bob Coecke, "Constructor Theory as Process Theory", arXiv:2401.05364, EPTCS 397, 2023; David Deutsch and Chiara Marletto, "Constructor theory of time", arXiv:2505.08692v3, revised 2026-06-05.Current SoTA decision payload for transformation-theory and process-theory repair of computation, method, and dynamics wording.Computation, information, dynamics, and procedure wording is interpreted through possible or impossible transformation and compositional-process claims when that claim is current, not through software notation or ordered instruction prose first.
Roger Bosman, Birthe van den Berg, Wenhao Tang, and Tom Schrijvers, "A Calculus for Scoped Effects & Handlers", Logical Methods in Computer Science 20(4), 2024, arXiv:2304.09697; Cristina Matache, Sam Lindley, Sean Moss, Sam Staton, Nicolas Wu, and Zhixuan Yang, "Scoped Effects as Parameterized Algebraic Theories", ESOP 2024 extended version, arXiv:2402.03103.Current SoTA decision payload for effectful computation and programming-model wording.Operation syntax, semantic handling, scope, resources, equations, and effect information remain separable; pure-function slogans and imperative-declarative slogans are not enough.
Francesco Chiariello, Valeria Fionda, Antonio Ielo, and Francesco Ricca, "Direct Encoding of Declare Constraints in ASP", Theory and Practice of Logic Programming 25, 2025, arXiv:2412.10152; Alessandro Berti et al., "OCEL (Object-Centric Event Log) 2.0 Specification", arXiv:2403.01975; Lien Bosmans et al., "Dynamic and Scalable Data Preparation for Object-Centric Process Mining", arXiv:2410.00596.Current SoTA decision payload for process-model, trace, workflow, and event-record wording.Constraint, event, object, relation, data model, ingestion, transformation, storage, and analysis claims are recovered separately before a method, work plan, work occurrence, evidence, or gate claim is accepted.
Aleksei Tiurin, Chris Barrett, Dan R. Ghica, and Nick Hu, "Equivalence Hypergraphs: DPO Rewriting for Monoidal E-Graphs", arXiv:2406.15882, v2 revised 2025-05-20.Current SoTA decision payload for graph, equivalence, and compositional-representation wording.Graph, equality, equivalence, and rewrite objects keep their direct kinds; any representation relation to them remains separate from instruction order, method, work, or action claims.
Robert Kowalski 1979; E. F. Codd 1970; Selinger et al. 1979; van der Aalst, Pesic, and Schonenberg 2009; Van Roy and Haridi 2004; Deutsch 2013; Deutsch and Marletto 2015.Historical lineage or contrast only.These sources explain why the overread is recognizable; they do not carry current SoTA weight for this pattern by age, fame, or popularity.

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

ForceTension
Bounded typed use vs public ontology growthA project needs typed claims now, but not every useful kind needs its own durable public U.* name.
Kind vs declarationA kind can continue across compatible declaration editions without becoming identical to the episteme that declares its criterion.
Identity vs localityA changed practice or source warns that the membership distinction may differ, but cannot prove sameness or difference.
Admissibility vs uncertaintyAn ill-typed or out-of-applicability request must not look like an admissible candidate whose relevant facts are unsettled.
Condition vs evidentiary useThe governed condition named by the criterion makes membership hold; an item's use as evidence alone does not. The criterion may itself concern an episteme, status, or relation.
Extent vs ontologyA set of true members can serve a query without becoming a collection holon, entity-set kind, or direct classification relation.
Scope vs kindA claim can have narrow scope without creating a narrower kind or storing scope on the kind.
Formal discipline vs ordinary useRepeated typed use may need a declaration; one readable case should not require a card or extension table.

Four Objects and a Pre-judgment Check

Keep these four objects separately recoverable:

ObjectMeaningSubject pattern
U.Kind individual and any U.SubkindOf factsOne intensional classification distinction, recovered through its candidate domain, operative membership condition, intended member/non-member boundary, and continuity rule. U.SubkindOf facts form a preorder; mutually obtaining facts state classification equivalence for the declared alignment and do not merge kind identities.C.3, C.3.1, and accepted E.24.UK results for U.Kind and U.SubkindOf
KindSignatureOne U.Signature declaration episteme whose exact EntityOfConcern is the kind and whose claim content declares candidate ValueKind, criterion, applicability, reference scheme, assumptions, dependencies, formality, and any current ExtentRule.C.3.2, A.6.0, and C.2.1
classification judgmentOne evaluation for an admissible exact candidate, kind, signature edition, and context slice with result true, false, or unknown. It is not a direct relation occurrence by default.C.3.2
KindExtension(k, slice)An optional set-valued representation of candidates whose admissible judgment is true for the fixed signature edition and slice.C.3.2, with C.29 when the representation changes a claim-bearing use

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.

  1. 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.
  2. Use C.3.1 for subkind and continuity. A U.SubkindOf fact 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.
  3. Use C.3.2 for declaration and admissible judgment. A repeated condition may justify a KindSignature. First check candidate ValueKind and applicability. Only an admissible application returns true, false, or unknown.
  4. 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.
  5. Keep four outcomes distinct. not-applicable means the judgment should not be formed. For an admissible candidate, a satisfied criterion gives true, a known failed criterion gives false, and missing support or an unavailable required dependency gives unknown. A guard may decline use without rewriting any of these results.
  6. Materialize an extension only for use. A query, quantification, comparison, or review may need KindExtension(k, slice). It represents admissible candidates judged true; notation, rows, or set membership do not create an ontic collection or classification relation.
  7. Keep scope, formality, Work, and publication separate. Formality characterizes the declaration episteme. Scope belongs to claims or capabilities. U.Work is a kind and W : U.Work is 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

Current questionSubject pattern
What kind does this claim quantify over, and what makes it the same kind later?C.3 and C.3.1; use candidate domain, membership distinction, and continuity rule
Does one kind count as a subkind of another for this declared applicability?C.3.1; distinguish criterion entailment, exhaustive closed-domain evaluation, classification equivalence, and kind identity
May this candidate be evaluated under this declaration and slice?C.3.2 admissibility; not-applicable forms no three-valued judgment
Does this admissible candidate satisfy this kind under this declaration edition and slice?C.3.2 returns true, false, or unknown
Does a receiving use need the represented set of true members?C.3.2; C.29 when the representation itself changes a claim-bearing use
Does the assertion hold in a target slice?A.2.6 for its U.ClaimScope; do not attach that scope to the kind
Did the practice, source, team, or other locality change?Compare exact kind definitions. Reuse the same kind when its distinction continues. Use C.3.3 only after two distinct kinds and a proposed correspondence are independently present
Did only the reference-scheme edition change?C.3.2 for another KindSignature edition and C.3.1 for continuity and any renewed subkind test; the scheme is not a kind or relation-occurrence identity key
Did only the context slice change?C.3.2 for another applicability check, judgment input, and possible extension; the slice alone creates no bridge
Is this kind proposed as another durable public FPF U.* kind?E.24.UK, followed by applicable naming patterns
Is a candidate, quality, relation, construction, episteme, status, publication occurrence, or Work being identified?Its direct subject pattern; C.3 consumes that result and does not create it by classification notation

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

SituationC.3 typed-reasoning moveBoundary
Pump #14 is evaluated as a cooling pump.Use one local kind, one declared criterion, one exact plant slice, and one true/false/unknown judgment.The pump and its cooling, flow, and measured-state facts remain under direct physical and measurement governors.
A maintenance episteme is classified while PDF and HTML forms circulate.Judge the exact episteme against the local kind criterion.Publication form and carrier do not decide membership.
A temperature value is classified into an interval.Keep the value under its unit and measurement interpretation and judge the value directly.Do not fabricate a value-shaped entity merely to classify it.
A schema labels a row Customer.Treat the label as a cue to recover the actual candidate and criterion.Schema spelling alone yields neither true nor a public U-kind.
A measurement required by a criterion is unavailable.Return unknown; let a safety guard decline the use separately.Do not coerce missing information to false.
A log row is labelled inspection work.First identify any exact dated W : U.Work under A.15.1; only then can W be a candidate for a local kind.The row, plan, or label is not W, and U.Work never occupies W's individual position.

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

CheckRequirement
CC-C3-1U.Kind and U.SubkindOf rely on exact accepted E.24.UK results; another public kind name still requires its own admission.
CC-C3-2Kind, KindSignature, admissibility result, admissible three-valued judgment, and optional extension remain distinct; scheme and locality are not stored on the kind.
CC-C3-3Kind identity is tested through candidate domain, membership distinction, intended member/non-member boundary, and continuity rule. A practice/source change is a comparison cue, not proof.
CC-C3-4Candidate and slice applicability is checked before judgment; not-applicable is distinct from admissible unknown.
CC-C3-5The governed condition named by the criterion decides membership. Evidentiary use alone does not constitute an independent condition, while directly criterion-bearing epistemes, statuses, and relations keep their own governors.
CC-C3-6Subkind facts follow C.3.1's criterion-entailment or exhaustive closed-domain branch and form a preorder; classification equivalence does not merge kind identities.
CC-C3-7Kind scope is absent; declaration and assertion scopes remain on their epistemes, and the slice remains an evaluation input.
CC-C3-8An extension is a representation of admissible true candidates, not U.EntitySet, a world-side collection-belonging claim, a collection holon, or a direct relation occurrence.
CC-C3-9C.3.3 is used only after distinct kinds and a proposed correspondence are independently established; same-kind reuse still gets a fresh receiving judgment.
CC-C3-10U.Work, exact W : U.Work, and any episteme about W remain distinct.

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 KindSignature as 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 false when the criterion cannot be evaluated.
  • Treating KindExtension or 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.

Needed detailDirect locusContent carried there
Kind identity, subkind relation, and continuityC.3.1admitted U.Kind and U.SubkindOf, criterion-entailment or exhaustive closed-domain obtaining, preorder and classification equivalence, participant-determined relation identity, and operational before/after continuity.
Declaration, candidate judgment, and extensionC.3.2KindSignature, exact four-key judgment, true/false/unknown, optional KindExtension, and scope/formality/evidence boundaries.
Cross-local kind useC.3.3identity comparison first; same-kind reuse without a bridge; for distinct kinds, an obtaining directional KindBridge, its separate assertion, preservation/loss, and a fresh admissible receiving judgment.
Local adaptation without cloning a kindC.3.4A KindUseAdaptationDeclaration for one named local use of an exact base kind, its pinned base-kind judgment and additional candidate-feature constraints, the exact three-valued KindUseAdaptationJudgment, and any separately declared KindUseAdaptationCorrespondenceDeclaration between two exact adaptation declarations.
Abstraction facetC.3.5KindAT as an editorial planning facet on one exact local kind, with no effect on the kind, declaration, judgment, extension, bridge assessment, guard, or F–G–R.
Typed guards and applied examplesC.3.ADeclaration-level kind compatibility and exact candidate-use judgments kept separate across regulatory, assurance, ESG, and Method–Work uses, including the independently grounded actual W : U.Work boundary.

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.6 context-slice and scope discipline, A.6.0 reusable declaration discipline, C.2.1 episteme identity, F-G-R, and direct subject patterns for candidate features.
  • Coordinates with: C.3.1 through C.3.5, C.3.A, C.29, E.24.UK, A.8, A.11, F.8, F.18, and generic A.22.CGUS when typed reasoning is one locus in an admitted unfolding structure; coordinates with StructuralCT2RTypingGroundingUnfoldingStructureBlock only 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 with A.7.1 for a general diagnostic return.
  • Does not replace: direct candidate-feature ontology, A.14 collection membership, A.2.6 scope, C.29 representation use, ontic settlement in E.24, U-kind admission in E.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

ForceTension
Small typed reasoning vs ontology growthProjects need reusable kinds without a new public U.* name for each distinction.
Preorder vs kind identityMutual subkind facts may hold for different intensional kinds; classification equivalence must not collapse their identities.
Criterion entailment vs observed supportExact rule entailment or an exhaustive closed domain can make the relation obtain; a non-exhaustive sample only supports an assertion.
Stable kind vs changing declarationA kind may continue across a compatible change, while a changed membership distinction must not inherit identity silently.
Applicability vs uncertaintyA non-applicable classification request is not an unknown judgment and cannot establish or refute a subkind fact.
Locality vs correspondenceA changed practice or source prompts comparison but does not establish another kind or a bridge.

Core Objects

ObjectMeaningBoundary
U.KindThe admitted meta-kind whose individuals are reusable intensional classification distinctions. One individual is recovered through its candidate domain, operative membership condition, intended member/non-member distinction, and continuity rule.A KindSignature, label, source boundary, reference scheme, current extension, or receiving use is not the kind.
U.SubkindOfThe admitted direct relation kind whose occurrences relate exact narrower and broader U.Kind participants within declared applicability. Its obtaining facts form a preorder.It is not a predicate expression, assertion episteme, dependency, part-whole relation, construction, system-role assignment, or admission relation.
SubkindOfObtains(k1, k2)The relation-obtaining condition. It holds either because the exact membership criterion for k1 entails the criterion for k2 under an aligned interpretation and applicability, or because every candidate in a deliberately closed finite domain has been evaluated and every admissible true result for k1 is also true for k2.The first branch is criterion-based. The second is explicitly domain-bounded. Non-exhaustive observations support a separate assertion but do not make the relation obtain.
R_sub : U.SubkindOfOne obtaining relation occurrence between exact narrower kind k1 and broader kind k2.Use a designator only when a receiver needs it. The ordered kind participants determine occurrence identity; schemes, signatures, evidence, assertions, and publications do not.
subkind assertion epistemeA C.2.1 episteme that affirms, denies, or leaves unresolved the obtaining condition and cites its interpretation, applicability, branch, and support.The assertion does not make the relation obtain; a negative or unresolved assertion designates no obtaining occurrence.
classification equivalence for an alignmentMutual obtaining U.SubkindOf facts between two kinds within the same declared applicability.It says that the two membership distinctions classify alike there. It does not identify the kinds. A consumer that needs a partial order may order these equivalence groups.
KindSignature editionThe C.3.2 declaration episteme used to interpret and evaluate one kind.It is neither the kind nor the subkind relation.

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

  1. 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.
  2. Check admissibility first. Compare only candidates admissible under both aligned declarations and the stated applicability. not-applicable forms no C.3.2 judgment.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Decide kind continuity independently. Apply the before/after test in section 6 whenever criterion, candidate domain, assumptions, dependencies, effective scheme, or locality changes. Another KindSignature edition neither proves nor denies kind continuity.
  9. Keep scope and Work outside the kind. A kind carries no claim scope. An exact W : U.Work remains 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:

QuestionContinuity consequence
What candidate domain and operative membership condition did the old kind use?Write at least one intended member and one relevant non-member or boundary case that exposes the discriminator.
What exact criterion, domain, assumption, dependency, or interpretation changed?Separate a wording, unit, source, or scheme change from a changed membership law.
Under an explicit alignment, do the old and new conditions classify the boundary probes alike for the receiving typed use, and does the operative discriminator keep the same meaning?If yes, the same kind may continue; cite the actual declaration edition in each judgment. If no, identify another kind.
Did only the practice, source, team, or publication locality change?Run the same comparison. Locality alone supplies no result and no KindBridge.
Are two distinct kinds now being related?State an obtaining U.SubkindOf fact when its criterion or closed-domain branch passes. Use C.3.3 only for a separately justified directional correspondence.

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

SituationC.3.1 moveBoundary
CoolingPumpKind is below PumpKind.Use criterion entailment: the cooling-pump condition already requires the governed pump condition. State the readable relation and its applicability.Do not infer a public U.CoolingPump, and do not use current extension rows as the truth-maker.
A closed inspection lot has five cabinets.If the declared candidate domain is exactly those five cabinets, check admissibility and evaluate every candidate. The domain-bounded InspectedCabinetKind subkind claim can obtain when every narrower true is broader true.The same observations do not establish an open-ended order over all future cabinets.
MorningShiftQualifiedOperatorKind and UnionRosteredOperatorKind happen to select the same people in a closed current roster.Mutual domain-bounded subkind facts may obtain, giving classification equivalence for this roster.The kinds remain distinct because their operative membership conditions differ; antisymmetry does not merge them.
A signature adds an aligned unit conversion.Apply section 6, keep the kind, identify the new signature edition, and retain edition-specific judgments.Do not rewrite earlier judgments as if the new edition had been used.
A signature changes from physical cooling performance to a schema label.The boundary probes expose a changed candidate domain and discriminator; identify another kind.Do not hide the mismatch by editing the extension.
Pump #14 changes state in a later plant slice.Re-evaluate the admissible candidate and allow the extension to change.Candidate-state change alone does not create a kind, signature, or relation occurrence.
InspectionWorkKind is used locally.Classify only an independently identified W : U.Work.U.Work, a plan, or a log row cannot occupy W's candidate position.
WorkPlan depends on Work.Use the governing work or E.24.UK relation.Do not encode dependency as U.SubkindOf.
SafetyCriticalFunctionKind is proposed as a subkind of FunctionKind.First recover both function senses under A.6.F, then use exact criterion entailment or the deliberately closed-domain branch.The word function, a risk label, or current examples establish neither the kinds nor the subkind fact; another public U.* name still requires E.24.UK.
A project proposes public U.CoolingPump.Take the recovered kind to E.24.UK, then apply naming patterns if admitted.Local typed use and U.SubkindOf do not admit or publish another durable kind.

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

CheckRequirement
CC-C31-1Each U.Kind individual has a recoverable candidate domain, operative membership condition, intended member/non-member boundary, and continuity rule. Practice/source provenance is a comparison cue, not an automatic identity discriminator.
CC-C31-2U.SubkindOf cites E24UK-AR-USUBKINDOF-R5-01, has exact ordered kind participants, declared applicability, one valid obtaining branch, and participant-determined occurrence identity.
CC-C31-2aPredicate content, C.2.1 assertion, evidence item, representation edge, scheme and signature editions, and optional occurrence designator remain distinct; none makes the relation obtain by form.
CC-C31-2bObtaining facts form a preorder. Mutual facts between distinct kinds record classification equivalence for the alignment; a partial order is formed only over equivalence groups when needed.
CC-C31-3Criterion entailment compares exact membership rules under aligned interpretation, or exhaustive evaluation covers a deliberately closed finite domain. Non-exhaustive observations support only the assertion.
CC-C31-4Only candidates admissible under both declarations enter the comparison. unknown neither establishes nor refutes a universal proposal; not-applicable forms no judgment.
CC-C31-5Reference schemes and declaration editions qualify interpretation, applicability, and assertions but do not identify the relation occurrence. An aligned edition change triggers reevaluation of the same participant-determined relation.
CC-C31-6Kind continuity uses before/after candidate-domain, membership-discriminator, member/non-member probes, and receiving-use tests; old judgments retain their cited edition.
CC-C31-7A locality change prompts the continuity test; C.3.3 is used only after two distinct kinds and a correspondence proposal exist.
CC-C31-8Scope is absent from the kind, and U.Work, one W : U.Work, and any episteme about W remain distinct.

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 KindSignature as 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.REL for U.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.2 judgments and extensions, C.3.3 correspondence between independently identified distinct kinds, A.2 when one local kind is a system-role kind, A.6.5 declaration-slot uses that consume an already obtaining subkind relation, C.29 representations, E.24.UK durable U-kind admission, and A.8, A.11, F.8, and F.5 when 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

ForceTension
Readable use vs reusable declarationOne case should stay ordinary, while repeated classification needs a stable criterion and assumptions.
Admissibility vs uncertaintyCandidate or slice mismatch means no judgment; missing knowledge for an admissible request means unknown.
Criterion condition vs evidentiary useThe direct condition named by the criterion can be physical, relational, epistemic, institutional, or publication-dependent; use as evidence alone creates none of them.
False vs unknownKnown criterion failure differs from unavailable support or dependency.
Intent vs extensionA declaration can stay fixed while candidate state or selected slice changes the true-candidate set.
Set use vs ontologyA query may need a set without creating a collection holon, direct relation occurrence, or U.EntitySet.
Scope vs evaluation inputClaims may be scoped; the kind is not. The context slice is an explicit input.

Four Objects and One Applicability Result

ObjectMeaningIdentity and governor
U.Kind individual and orderThe intensional kind and any obtaining U.SubkindOf facts used by typed reasoning.C.3 and C.3.1; not this declaration, a practice/source label, or a new public-kind admission.
KindSignatureA U.Signature declaration episteme whose exact EntityOfConcern is the kind.A.6.0 and C.2.1 govern the episteme and its editions.
classification judgmentOne evaluation for an admissible exact candidate, kind, signature edition, and slice, returning true, false, or unknown.C.3.2; it is not a direct relation occurrence or guard result by default.
KindExtension(k, slice)An optional set-valued representation of admissible candidates judged true for the pinned signature edition and slice.Local calculation unless C.29 governs a claim-bearing use.

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 ValueKind or 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.ContextSlice applicability 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 ExtentRule for 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.

  1. 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.
  2. Pin the inputs. Name candidate, kind, exact signature edition, and exact slice; avoid implicit latest or current.
  3. Check admissibility. If the candidate does not satisfy the declared candidate ValueKind or interpretation, or the slice is outside declared applicability, return not-applicable and stop. Do not form J.
  4. Evaluate the governed condition. For an admissible candidate, a satisfied criterion gives true; a known failed criterion gives false.
  5. Keep non-settlement visible. Missing support or an unavailable declared dependency gives unknown, not false.
  6. 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.
  7. Separate guard disposition. A guard checks admissibility, scope coverage, and any judgment as separate predicates. It may decline use on not-applicable or unknown without converting either to false.

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 k and slice.
  • State the candidate domain without inventing U.EntitySet.
  • Include exactly admissible candidates whose judgment is true. Keep unknown and not-applicable distinct 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 true judgment for k1 must not coexist with an admissible false judgment for k2 within 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:

ChangeDirect consequenceWhat does not follow automatically
practice, source, team, or locality changescompare the exact kind definitions and declaration meaningsanother kind or KindBridge
two distinct kinds and a directional correspondence are currenttest C.3.3 obtaining and evaluate the receiving candidate afreshtransferred source truth
criterion, candidate domain, applicability, EntityOfConcern, or scheme changesanother KindSignature edition; C.3.1 decides kind continuityanother kind merely by edition
candidate fails ValueKind or slice applicabilitynot-applicable; no judgmentunknown or false
candidate state changesreevaluate in the relevant slice when admissiblea new signature or kind
support or dependency becomes unavailableunknown for an admissible requestnot-applicable or known false
publication form changesanother form or carrier may express the same epistemeanother signature, kind, or classification

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

CaseRepaired use
Vehicle and PassengerCarCheck candidate admissibility and use C.3.1's exact obtaining branch; a registry result is an extension representation, not U.EntitySet.
AuthenticatedRequestName the standard and key-validity dependency. An admissible request with unavailable key support yields unknown; a non-request value is not-applicable.
AdultPatientPin jurisdictional threshold, measurement time, and candidate identity. A patient with missing birth support is unknown; a non-person value rejected by ValueKind is not-applicable.

Work Boundary

Classification does not weaken the work ontology:

  • U.Work is the admitted kind;
  • W : U.Work is 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

  1. Start with one readable classification sentence and its practical use.
  2. Recover the exact candidate and the governed criterion conditions before discussing support.
  3. Reuse an existing signature edition only when it truly governs candidate ValueKind, criterion, applicability, scheme, and dependencies.
  4. Check admissibility. Stop with not-applicable when candidate or slice lies outside the declaration.
  5. For an admissible request, return true, false, or unknown without folding in the guard decision.
  6. Create an extension only for a named set-consuming use.
  7. If a separate assertion is required, give its C.2.1 episteme the exact EntityOfConcern, content, scope, support use, and edition.

Conformance Checklist

CheckRequirement
CC-C32-1Kind, KindSignature, pre-judgment admissibility, admissible three-valued judgment, and optional extension remain separately recoverable.
CC-C32-2The signature's EntityOfConcern is the kind, and its content names candidate ValueKind/domain, criterion, applicability, scheme, assumptions, dependencies, formality, and any extent rule.
CC-C32-3Candidate mismatch or slice outside applicability yields not-applicable and no judgment; only admissible requests return true, false, or unknown.
CC-C32-4The directly governed condition named by the criterion decides satisfaction. Evidentiary use alone does not constitute an independently governed condition; an episteme, relation, status, or publication occurrence may be the condition when its direct pattern says so.
CC-C32-5Missing support or unavailable dependency for an admissible request yields unknown, distinct from known false.
CC-C32-6No world-side collection-belonging claim, U.EntitySet, collection holon, or direct classification occurrence is inferred from judgment or extension.
CC-C32-7A separate classification assertion is a C.2.1 episteme and creates neither candidate nor kind.
CC-C32-8Subkind checks compare admissible judgments and use C.3.1's criterion-entailment or exhaustive closed-domain branch; samples only support an assertion.
CC-C32-9Locality change triggers kind-definition comparison. Only independently identified distinct kinds with an obtaining correspondence use C.3.3; receiving judgments remain fresh.
CC-C32-10The kind carries no scope; the slice is an evaluation input and declaration/assertion scopes stay on their epistemes.
CC-C32-11Physical, episteme/publication, value, schema, unavailable-support, not-applicable, registration-status, and Work cases respect the same architecture.
CC-C32-12Ordinary use stays readable, and declarations or extensions appear only for named receiving uses.

Common Anti-Patterns and Remedies

Anti-patternRemedy
Treating a kind and its KindSignature as one objectIdentify the kind and declaration episteme separately.
Returning unknown for a candidate outside ValueKind or applicabilityReturn not-applicable and form no judgment.
Returning false for missing supportPreserve unknown; let the receiving guard decide whether to decline use.
Treating any evidence item or record as membershipAsk whether the criterion directly concerns that governed episteme, relation, status, or publication occurrence. If not, keep it only as support.
Reusing a world-side belongs-to predicate or minting a relation by notationKeep the result as a classification judgment unless a direct relation pattern is justified.
Treating an extension or braces as ontologyKeep the candidate domain and extension as representations; use C.29 when claim-bearing.
Attaching scope or formality to the kindKeep them on their declaration or assertion epistemes.
Editing an extension to hide a subkind counterexampleRepair the relation proposal, declaration alignment, or distinct-kind bridge.
Classifying a record as actual WorkRecover an independently grounded W : U.Work; keep its record separate.

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.3 correspondence between independently identified distinct kinds, C.3.4 local adaptations, C.29 mathematical representations, C.2.3 formality, F-G-R evidence and assurance, A.14 collection membership, and E.24.UK durable 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 KindBridge is needed. When two independently identified kinds are distinct and a directional correspondence predicate holds, one KindBridge direct 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-applicable before a fresh true | false | unknown receiving 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

  1. False splitting. A locality change creates two apparent kinds and a bridge even though the membership distinction is unchanged.
  2. Semantic drift. A genuinely different receiving kind is treated as the source kind because names or extensions look alike.
  3. Hidden order loss. Subkind facts collapse, invert, or become unsettled without being reported.
  4. Entangled channels. Scope, sense, and kind correspondence are bundled into one score or record.
  5. Classification transfer. A source judgment is copied as receiving truth without checking receiving admissibility and criterion satisfaction.
  6. 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

ForceTension to resolve
Same-kind reuse vs bridge disciplineDo not invent a bridge for provenance, but make real distinct-kind correspondence explicit.
Minimal disclosure vs precisionState only what the receiving use consumes while keeping direction, definedness, and loss inspectable.
Local autonomy vs reuseReceiving kinds keep their membership distinctions; correspondence does not merge them.
Separate channels vs workloadScope, sense, and kind correspondence remain separate without forcing all three into every use.
Fresh truth vs useful supportSource results may support reliance but never substitute for receiving admissibility or judgment.

Solution — Compare Identity, Then Relate Distinct Kinds

  1. 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.
  2. 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 KindBridge obtains merely because source, practice, team, wording, or scheme changed.
  3. Open a bridge only for two distinct kinds. A KindBridge occurrence 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.
  4. Keep the assertion separate. A C.2.1 bridge-assertion episteme designates the relation when needed and carries paired KindSignature editions, 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.
  5. Evaluate the receiving candidate. First return admissible or not-applicable under the receiving signature and slice. Only an admissible request returns true, false, or unknown. A source judgment may support the bridge assertion or reliance but is never copied as receiving truth.
  6. Route consequences narrowly. When a receiving claim relies on the obtaining bridge and fresh receiving result, apply only the justified CL^k consequence 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:

  1. exact ordered source-kind and target-kind participants and the proof that they are distinct;
  2. the directional correspondence predicate, applicability, and definedness; and
  3. 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 KindBridge when 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^k from exemplars. Calibrate on concrete counter‑examples and preserved properties; resist optimistic ratings.

Review playbook (10 minutes)

  1. 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.
  2. Order claims honest? Any inversions? Collapses disclosed?
  3. CL^k plausible? Based on preserved properties, not name similarity?
  4. Loss notes present? Will they force narrowing of Scope or extra tests?
  5. Definedness area clear? Guard will fail closed outside it?
  6. 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)

Anti‑patternWhy it’s wrongRemedy
One interoperability score, or mandatory scope-plus-kind bridgesBlurs independent channels and invents unused relationsOpen only the exact Scope, kind, and sense relations consumed by the receiving use; keep their losses and R consequences separate
Claiming preserved while inverting orderMakes typed reasoning unsoundMark as not preserved; add loss note; consider adapter or subkind redesign
Hiding collapsesOverstates coverageList collapsed subkinds explicitly; plan extra R for lost granularity
Implicit latest mappingNon-deterministic and non-auditablePin both scheme editions and the mapping-rule edition in the bridge assertion; outside bridge definedness decline that bridge use without changing an independently obtained receiving result.
Using KindBridge to widen GConflates entityOfConcern with applicabilityKeep Scope edits in USM (ΔG±); KindBridge never widens Scope
Adjusting F/G for poor CL^kViolates F–G–R & USM separationRoute consequences to R only; consider narrowing Scope or adding adapters

Conformance Checklist

IDRequirement
KB-01A locality or scheme change first triggers kind-definition comparison. A bridge has exact ordered, independently identified distinct kind participants and an obtaining directional correspondence predicate.
KB-02A KindBridge maps neither Scope nor sense; A.2.6 and F.9 are added only when their own exact use is current.
KB-03Participants, distinctness, direction, predicate, applicability, definedness, and participant-determined identity are recoverable. Scheme/signature/assertion/card/publication editions qualify interpretation or reliance but do not reidentify the occurrence.
KB-04Receiving classification checks admissibility before a fresh three-valued judgment. Source truth is never copied; bridge refusal does not rewrite the receiving result.
KB-05An order-preservation assertion names exact source and target subkind facts and the two bridge relations used.
KB-06Inversion is non-preservation with loss; unsettled order remains unknown.
KB-07Collapse designates affected source order facts and lost distinctions without rewriting either kind order.
KB-08CL^k is an assessment in the bridge assertion and does not alter kind identity, formality, scope, or abstraction facet.
KB-09Reliance applies only justified CL^k consequences to R; admissibility, F, G, and classification truth stay unchanged.
KB-10Chained bridge reliance uses the weakest link while keeping occurrences and assertions distinct.
KB-11Loss notes state non-preserved criteria or subkind facts and do not change either kind.
KB-12Definedness is explicit; outside it the guard declines that bridge use while independent receiving classification keeps its own result.

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 KindUseAdaptationDeclaration when a procedure needs a narrower or differently named use of an existing kind without defining another kind. The declaration pins the base KindSignature edition, local candidate constraints or vocabulary bindings, intended guard use, and applicability. Check admissibility before returning true, false, or unknown. A locality change first triggers kind-identity comparison: the same kind needs no KindBridge; 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.SubkindOf facts form a preorder and kinds carry no Scope.
  • C.3.2 — Kind intent, admissibility, judgment, and extension: KindSignature is 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:

  1. KindUseAdaptationDeclaration states one named use of a base kind.
  2. KindUseAdaptationJudgment is the three-valued result for one admissible candidate under pinned declaration and signature editions.
  3. KindUseAdaptationCorrespondenceDeclaration records 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

  1. Kind sprawl. Teams mint near-duplicates for every procedure.
  2. Hidden constraints. Informal acceptance rules leak into prose and cannot be replayed.
  3. Scope conflation. Jurisdiction, API version, or another scope condition is smuggled into kind identity.
  4. Automatic bridge pressure. A changed source or team is treated as proof of another kind and a bridge.
  5. Collapsed outcomes. A non-applicable candidate, unsettled admissible candidate, and guard refusal are reported as one unknown or false result.

Forces

ForceTension to resolve
Local specialization vs common coreA use needs tailoring without forking the base kind.
Expressivity vs determinismReal constraints must remain reproducibly checkable.
Applicability vs uncertaintyCandidate/slice mismatch stops before the judgment; missing facts preserve unknown.
Scope vs candidate constraintsConditions on ClaimScope stay under A.2.6; conditions on the candidate enter classification.
Reuse vs proliferationStable conceptual distinctions may warrant a separately identified kind, but declaration reuse alone does not.
Locality vs identityA changed locality prompts comparison of membership distinctions, not automatic bridging.

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:

  1. the exact base kind and pinned base KindSignature edition;
  2. the receiving use and adaptation type: constraint, vocabulary, or composite;
  3. additional directly governed candidate conditions, when any;
  4. vocabulary or notation bindings;
  5. exact candidate and slice applicability plus dependencies;
  6. scope expectations routed separately through A.2.6; and
  7. 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 KindBridge exists 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 KindUseAdaptationCorrespondenceDeclaration may 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 its EntityOfConcern.
  • 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 KindSignature episteme 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 KindUseAdaptationJudgment pins both editions and preserves unknown; 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

Anti-patternWhy it is wrongRepair
Adaptation declaration treated as a new typeDuplicates the kind and hides the declaration episteme.Keep the base kind; for a stable conceptual refinement identify another local kind and establish U.SubkindOf independently.
Claim- or Work-scope condition hidden in an adaptation judgmentConflates the candidate with where a claim or Work applies.Move the scope condition to A.2.6; keep candidate constraints and declaration applicability explicit.
Unversioned or applicability-free declaration used by a guardMakes evaluation non-replayable.Give the declaration a designator, pin its edition and dependencies, state applicability, and distinguish not-applicable from unknown.
Locality change treated as automatic bridgeSplits the same kind or transfers source truth.Compare kind definitions first. Same-kind reuse needs no bridge and still gets a fresh receiving result; distinct-kind use needs an obtaining C.3.3 correspondence.
Many declarations with the same local meaningProduces catalog entropy and inconsistent behavior.Consolidate redundant declarations; for a stable conceptual distinction, separately identify a local kind and establish its obtaining U.SubkindOf relation.
Declaration name treated as a kind synonymHides constraints and invites misuse.Designate the exact declaration edition and base kind separately in prose and guards.

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:

  1. Are the exact base kind and declaration editions recoverable?
  2. Is the type—constraint, vocabulary, or composite—correct?
  3. Are candidate conditions, applicability, and ClaimScope separated?
  4. Does evaluation distinguish not-applicable, true, false, unknown, and guard refusal?
  5. On locality change, was kind identity compared before any bridge was claimed?
  6. For distinct-kind use, do the bridge predicate, receiving declaration, fresh judgment, any adaptation correspondence, and only justified R consequence remain separate?
  7. Does a stable conceptual distinction warrant another kind, or is the declaration sufficient?

Conformance Checklist

IDRequirement
KUA-01The declaration is a C.2.1 episteme with base kind as EntityOfConcern, effective scheme, pinned editions, use, constraints/bindings, applicability, dependencies, and its own formality.
KUA-02It creates no kind or subkind fact.
KUA-03Admissibility precedes the three-valued judgment; guard refusal is separate.
KUA-04Vocabulary preserves the base judgment; constraint/composite uses governed candidate conditions and the three-valued conjunction rule.
KUA-05Claim-scope conditions remain under A.2.6 and are not folded into kind identity.
KUA-06A guard designates exact editions, checks applicability, evaluates the exact candidate, and makes a separate use decision.
KUA-07Stable refinement is independently identified and checked; declaration reuse does not promote it.
KUA-08Guard-addressable adaptation and correspondence declarations resolve to their exact editions and all interpretation, dependency, definedness, direction, and loss values required by section 6.3; a catalog remains representation and does not merge kind identities.
KUA-09Locality change triggers identity comparison. Same-kind reuse has no bridge and still gets a fresh receiving judgment; distinct-kind use requires an obtaining C.3.3 correspondence before bridge reliance.
KUA-10Non-applicability forms no judgment; unavailable admissible dependencies yield unknown; correspondence failure blocks use without rewriting the receiving result.

C.3.4:End

KindAT — Intentional Abstraction Facet for Kinds (K0…K3)

One-line summary. KindAT is an informative editorial facet on one local U.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, a KindSignature, 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, obtaining U.SubkindOf relations, and kind continuity.
  • C.3.2: the separate KindSignature declaration episteme, exact four-input classification judgment, and optional pinned-edition extension representation.
  • C.3.3: the obtaining KindBridge relation and its separate bridge-assertion episteme carrying CL^k, loss, evidence, and admitted use.
  • C.3.4: the RoleMask declaration episteme and exact masked judgment.
  • A.2.6, C.2.2, and C.2.3: Claim/Work scope, F–G–R, and U.Formality on 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 KindSignature remains a declaration episteme whose own U.Formality may change;
  • J(candidate, kind, signatureEdition, slice) remains true, false, or unknown;
  • any KindExtension remains 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)

Decision areaK0K1K2K3
declaration workidentity/cohort criterion when reuse needs itbehavioral acceptance criterionexplicit invariant-bearing signatureequivalence-invariant signature
assurance workexact candidates and slicesbehavioral diversitysubkind and boundary coverageequivalence witnesses
bridge expectationinstance correspondencepattern correspondencekind/order correspondenceequivalence-preserving correspondence
refactoring cueidentify a stable kind only when a real reusable criterion appearscrystallize a stable criterion when warrantedmaintain order and signature continuity explicitlykeep the equivalence notion explicit

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.SubkindOf determines 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.SubkindOf relation 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

  1. Is the tagged object the exact local kind rather than its signature, card, candidate, claim, or extension?
  2. Does the anchor describe the kind's intentional stance rather than the current number of candidates?
  3. Are proposed F and R changes stated as planning decisions over their actual owners rather than effects of KindAT?
  4. Does a stable mask distinction require a separately identified kind and independently obtaining subkind relation?
  5. 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.SubkindOf relation 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. UndirectedGraph up to node relabeling: state the equivalence notion and require bridge/evidence witnesses that preserve it.

Conformance checklist (normative)

IDRequirement
AT-01KindAT is a facet with no algebra or threshold and appears in no guard or composition rule.
AT-02The tag designates one exact local kind; catalogs only represent that assignment and its references.
AT-03No text makes KindAT change F, G, R, classification truth, or extension contents.
AT-04KindBridge relation, bridge assertion, CL^k, and KindAT remain separate.
AT-05Catalog use references the separate signature, order, mask, bridge, and extension objects without collapsing them.

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, and unknown remain 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.SubkindOf relations.
  • C.3.2: KindSignature declaration epistemes, J(candidate, kind, signatureEdition, slice), true/false/unknown, and optional extension representations.
  • C.3.3: obtaining KindBridge relations and separate bridge-assertion epistemes carrying CL^k, loss, evidence, definedness, and admitted use.
  • C.3.4: RoleMask and MaskAdapter declaration epistemes and J_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:

  1. the declaration-level compatibility of a claim's quantified kind with a consumer's expected kind;
  2. the classification of one exact candidate under one exact signature edition and slice;
  3. Claim or Work scope coverage;
  4. cross-context kind and scope bridges and their R consequences;
  5. a RoleMask declaration and exact masked judgment; or
  6. 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 KindSignature edition 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.

  1. Exact declarations. A kind designator never substitutes for the exact KindSignature edition needed by the use.
  2. 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.
  3. Three classification values. true means the criterion is known to hold; false means it is known to fail; unknown means the evaluation cannot settle because evidence or a declared dependency is unavailable or the candidate is outside the evaluation domain.
  4. Separate guard disposition. A guard returns an action disposition such as allow or refuse. Both false and unknown normally cause fail-closed refusal, but the guard MUST preserve which classification value it consumed.
  5. Scope separation. Scope coverage is a USM predicate over a named slice. It does not classify the candidate or repair kind compatibility.
  6. 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.
  7. 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:

  1. recover the exact KindSignature declaration episteme editions whose respective EntityOfConcern values are k_claim and k_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;
  2. 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 identified R_sub : U.SubkindOf occurrence only when occurrence identity is needed; or
    • across contexts, an obtaining KindBridge relates exact source k_claim and target k_receive under the paired source and target KindSignature editions, and a separate current bridge assertion states the mapping, applicability, loss, CL^k, evidence, and admitted receiving use;
  3. require U.ClaimScope(C) to cover the exact TargetSlice and require an explicit Gamma_time selector;
  4. apply only the justified bridge consequences to R;
  5. check evidence freshness separately when the admission implies reliance; and
  6. 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:

  1. identify the candidate under its direct governor before classification;
  2. satisfy Guard_TypedClaim for the same claim-kind and receiving-kind editions and slice;
  3. evaluate J(candidate, k_receive, receiveSignatureEdition, TargetSlice);
  4. continue candidate-bearing use only on true: for a same-context proper subkind, the already established SubkindOfObtains(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;
  5. refuse on known false while retaining that value; and
  6. refuse on unknown while 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:

  1. pin both declaration episteme editions;
  2. 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_A to exact target-side kind k_A', its separate assertion carries the current mapping and loss basis, and k_A' is identical to k_B or SubkindOfObtains(k_A', k_B; targetReferenceScheme) holds;
  3. compute serial scope as the intersection of the two governed scopes and require coverage of TargetSlice;
  4. route bridge consequences to R and check freshness separately; and
  5. when an actual produced candidate enters B, evaluate J(candidate, k_B, edition_B, TargetSlice) and continue only on true, preserving false and unknown separately 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:

  1. 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;
  2. check artifact scope separately through USM;
  3. evaluate J_mask(candidate, kind, kindSignatureEdition, roleMaskEdition, TargetSlice);
  4. continue only on true, refuse while preserving known false, and fail closed while preserving unknown;
  5. keep context predicates out of the candidate-feature criterion; and
  6. for cross-context use, establish the KindBridge relation and assertion, target declarations, and any separate MaskAdapter declaration 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:

  1. recover the same governed claim, quantified kind, and signature edition;
  2. satisfy declaration-level typed admission in that line's slice;
  3. when a line's evidence is candidate-specific, bind each exact candidate and its exact judgment rather than treating a row label as classification;
  4. preserve line-specific bridge consequences and freshness;
  5. provide the USM independence justification; and
  6. 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:

  1. recover an obtaining Scope Bridge and its applicable congruence assessment when Claim scope crosses context;
  2. 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;
  3. recover the independently authored target KindSignature edition;
  4. require translated Claim scope to cover TargetSlice;
  5. when an actual candidate is current, evaluate the fresh target judgment J(candidate, targetKind, targetSignatureEdition, TargetSlice) and preserve all three values;
  6. apply the justified scope- and kind-bridge consequences to R only; and
  7. 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)

IDRequirement
GC-01A universally quantified claim pins both claim-kind and receiving-kind declaration editions; same-context restriction requires the receiving kind to be identical to or a subkind of the claim kind, while producer/output positions use their own direction. No candidate is invented.
GC-02Every claim-to-candidate use pins candidate, claim kind, receiving kind, both needed signature editions, and slice; it evaluates the target receiving judgment and consumes true/false/unknown.
GC-03unknown and known false remain distinct from each other and from guard refusal.
GC-04RoleMask use recovers the declaration episteme and exact masked judgment; any MaskAdapter remains a separate declaration.
GC-05Cross-context use recovers both bridge channels, the exact target declaration, and a fresh target judgment when a candidate is current; penalties route to R only.
GC-06Scope, Gamma_time, freshness, type compatibility, classification, and disposition remain separate.
GC-07SpanUnion preserves one typed claim and line independence; candidate-specific evidence names exact candidates and judgments.
GC-08KindAT appears in no guard, and no plan, row, card, log, or slice substitutes for an actual candidate or Work occurrence.

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.

  1. Pin the quantified claim kind, receiving kind, and both exact signature editions.
  2. 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.
  3. Check Claim scope against the exact TargetSlice and Gamma_time.
  4. Apply R consequences and freshness/threshold checks.
  5. 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.

  1. Identify the candidate under its direct governor.
  2. Complete D1.
  3. Evaluate the exact four-input target judgment under the receiving-kind declaration; use the already established order or bridge for the claim-kind consequence.
  4. On true, continue; on false, refuse as known failure; on unknown, refuse and retain the non-settlement reason.

D3 — Compose or cross a context.

  1. Pin source and target declarations.
  2. Recover the obtaining kind relation/bridge and separate assertion; recover Scope Bridge separately.
  3. Check the serial or translated scope.
  4. If an actual output/candidate is current, evaluate it under the target declaration.
  5. Apply R consequences and decide separately.

D4 — Publish a union.

  1. Complete the relevant D1/D2 checks per line.
  2. Demonstrate support-line independence.
  3. Publish only the supported union; retain line-specific classifications and bridge consequences.

Guard anti-patterns and remedies (informative)

Anti-patternWhy it is wrongRemedy
Widening G to repair kind mismatchapplicability is not typed compatibilityrepair the order/bridge/adapter or refuse
Asking whether an unnamed candidate “counts”hides candidate identity and signature editionstay at declaration level or name the exact candidate and four inputs
Treating unavailable support as falseturns non-settlement into world-side failureretain unknown; let the guard refuse separately
Treating a mask label as a kindhides the declaration and constraintsdesignate the exact RoleMask edition and evaluate J_mask
Copying source classification through a bridgebridge evidence is not target truthrecover the target declaration and evaluate the target candidate afresh
Gating on KindATthe facet is not a guard Characteristicuse the actual declaration, judgment, scope, evidence, and policy predicates
Calling a plan, row, or JobSlice “the work”erases the world/episteme boundaryidentify the independently grounded dated Work occurrence when Work is current

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).

  1. Check P's governed scope and explicit time against S_local.
  2. Recover the exact authority/local declarations, KindBridge relation, and bridge assertion.
  3. Check bridge applicability and route its consequence to R.
  4. Evaluate J(candidate, localKind, localSignatureEdition, S_local).
  5. Continue only on true; retain known false or unknown before refusing.
  6. Check freshness of relied-on regulatory and candidate support separately.

Guard_RegChange(change, impactedDeclarations, impactedScopes).

  1. Decide whether the change alters criterion, reference scheme, applicability, or more than one.
  2. Author the required signature episteme edition and let C.3.1 settle kind continuity.
  3. Update Scope independently when jurisdiction/version/time coverage changes.
  4. Reassess the bridge assertion's mapping, loss, CL^k, evidence, and admitted use.
  5. 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]
  1. Inventory regulatory claims, exact category declarations, and applicability slices.
  2. Recover or author target KindSignature declaration editions; keep F on those epistemes.
  3. Establish KindBridge relations and separate assertions with loss and admitted use.
  4. Rewrite candidate-bearing guards to pin candidate, local kind, signature edition, and slice.
  5. Preserve unknown and record refusal separately.
  6. Route Scope through USM and bridge consequences through R.
  7. 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]
RowsColumnsCell content
exact kind/subkind signature editions or RoleMask declaration editionsexact context slices with versions and Gamma_timeexact candidate(s) when current, judgment values, evidence units and support relations, freshness, bridge/assertion references, and receiving use

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, KindSignature edition, and assumed scope slices.
  • VA-2. A proof of a universal claim need not invent a candidate; application to an actual candidate uses Guard_CandidateUse separately.
  • 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
Anti-patternRemedy
one golden case stands for a kindstate the declaration-level claim and plan explicit subkind/boundary coverage
a matrix row is treated as classificationname exact candidates and judgments in candidate-bearing cells
“latest data”pin freshness and time policy
trusted tool substitutes for content supportkeep TA separate and recover the governed candidate facts/support
bridge presence substitutes for target evaluationuse the independent target declaration and fresh target judgment
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:

  1. pin the claim, exact quantified claim kind, receiving kind, and both needed KindSignature editions;
  2. establish the correct same-context restriction direction or the exact source-claim to target-receiving KindBridge relation and separate assertion;
  3. check Claim scope and explicit Gamma_time;
  4. 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;
  5. when a RoleMask is used, recover its declaration edition and evaluate the exact masked judgment;
  6. apply justified bridge consequences to R only;
  7. check formality and freshness on their actual owners; and
  8. 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:

  1. require the capability's governed Work scope to cover exact JobSlice with explicit time;
  2. check capability measures, qualification/currentness, and fit as separately governed predicates;
  3. pin every expected input/output local kind and signature edition;
  4. for every actual input candidate, evaluate J(inputCandidate, expectedInputKind, inputSignatureEdition, JobSlice) and preserve all three values;
  5. use exact RoleMask declarations and masked judgments when procedural tailoring is current;
  6. establish exact target bridges/declarations and fresh target judgments for cross-context candidates;
  7. before execution, return only an entry disposition and keep W absent;
  8. after execution, identify W independently and, for every actual output candidate relied on, evaluate the exact output judgment;
  9. keep W, inputs, outputs, JobSlice, capability, plan, logs, and assertions distinct; and
  10. refuse fail-closed on false or unknown without 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
Anti-patternRemedy
widening Work scope to hide an input mismatchrepair declaration compatibility, adapter, mask, or bridge; otherwise refuse
calling JobSlice or WorkPlan the workbefore execution keep W absent; after execution identify the independently grounded dated W
treating a log or result row as Wkeep it as a separate episteme that designates W
omitting the exact candidate or signature editionpin all four judgment inputs
converting unavailable support to falseretain unknown and refuse separately
treating bridge or adapter records as target truthrecover target declarations and evaluate candidates afresh

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

ForceTension
Choice doctrine versus candidate formation and generationC.11 must govern choice among already-available options without swallowing C.38 formation of complete ways or C.18 open-ended search and generation.
Evidential, causal, and subjunctive dependenceThe pattern must stay usable with classical decision language while making room for causal and success-first repairs where correlation is not enough.
Decide now versus probe moreThe chooser may need to stop and choose now, or spend more effort on information and computation first. The theory must make that trade legible.
Decision subject versus narrower agent languageThe chooser may be one person, one team, one organization, or another collectivity-bearing system. The pattern must not silently force all cases into one narrow Agent reading.
Minimal mathematical floor versus premature heavy formalismThe pattern needs a stable object stack for disciplined reasoning and inspection, but it should not pretend that one full quantum-like or geometry-heavy package is already settled.

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.

ChoiceResult.causalUseSpec?:
  causalUseQuestionRef?: CausalUseQuestionRef
  targetCausalityLadderRung: CausalityLadderRung
  causalUseClaimKind: CausalUseClaimKind
  causalActionPolicyClass?: CausalActionPolicyClass
  causalSupportComponentRefs?: CausalSupportComponentRefs
  causalUseEvidenceDesignRef?
  causalUseSupportResultRef?: CausalUseSupportResultRef
  supportedUse
  unsupportedUse

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.

  1. Fix the chooser and the choice-bearing level. State one DecisionSubject and one DecisionSubjectGranularity. If the real dispute is still about who or what counts as the chooser, coordinate with A.13 instead of hiding that dispute inside one local choice; planned C.9 may later consolidate an agency-characteristic profile but supplies no current governing force.

  2. 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 apply C.38. If the hard work is open-ended invention, expansion, or reframing, apply C.18.

  3. Make the comparison basis explicit. State one PreferenceOrder or one EvaluativeMeasure, plus one BeliefState and one OutcomeModel. 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.

  4. 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 one InterventionModel when taking one option changes the world through intervention rather than mere observation. Add one CounterfactualModel plus one SubjunctiveDependenceRelation when 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.

  5. Run the probe-worthiness test before commitment. State one ProbeActionSet, one ProbeBudget, and one CostToProbe. Use ValueOfInformation for additional observation or measurement, and ValueOfComputation for 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 current OptionSet and current comparison basis, not one full sequential or non-myopic experimental program. Richer OED lines may strengthen this doctrine, but the local C.11 closure rule already has to decide whether the next feasible probe can still change the current choice. If no feasible further probe fits the remaining ProbeBudget, or if the best available probe no longer justifies its CostToProbe, 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 current OptionSet should be rejected, run it, update the BeliefState and OutcomeModel, 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 apply C.24.

  6. Apply one ChoiceRule and emit one ChoiceResult plus the next question. End with one explicit result: choose now, reject current set, probe again, or reroute because this is no longer local choice. If the result is choose now, name the winning option or the retained tie-set plus the reason no remaining feasible probe is worth its cost. If the result is reject 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 is probe again, name the next probe and the exact comparison defect it is supposed to repair. A C.11 pass 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 DecisionSubject at one DecisionSubjectGranularity;
  • one current OptionSet;
  • one current comparison basis through PreferenceOrder or EvaluativeMeasure, plus one BeliefState and one OutcomeModel;
  • 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 honest reject current set result rather than one fake winner;
  • one EvaluativeMeasure for 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 BeliefState revision, 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 DecisionSubject at 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 ValueOfInformation or ValueOfComputation, is large enough to justify its CostToProbe;
  • 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.

  • ChoiceRule is the doctrine or operator that says how the current comparison basis, dependence layer, and probe-worthiness value support one ChoiceResult.
  • ChoiceResult is 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 now
  • reject current set
  • probe again
  • reroute

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 OptionSet survives 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 OptionSet is 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 OptionSet is 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.38 when labels or fragments must first become complete-enough ways of obtaining the same result;
  • to C.18 when the option set itself is under open-ended invention or reframing;
  • to C.19 when the question is now how broadly to keep exploring or exploiting one candidate pool;
  • to C.24 when one choice result already exists and the next task is now sequencing, enactment, or execution-path probe work;
  • to G.5 when the next task is declaring or naming selector-facing selected-set content; when that result already exists, use E.17 for its source-backed publication face and return to source and E.24.PUB for 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:

DecisionSubject(...)
DecisionSubjectGranularity(...)
OptionSet(...)
ComparisonBasis(
  preferenceOrder or evaluativeMeasure,
  beliefState,
  outcomeModel,
  optional intervention/counterfactual/subjunctive layer
)
ChoiceRule(
  closure rule over the current basis and probe decision value
)
ProbeDecisionValue(
  probeActionSet,
  probeBudget,
  costToProbe,
  valueOfInformation,
  valueOfComputation
)
ChoiceResult(
  choiceDisposition = choose_now | reject_current_set | probe_again | reroute,
  selectedOption or retainedTieSet or rejectedCurrentSet or rerouteOwner,
  reason this result is lawful now
)

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, or Front+Archive.
  • Apply one declared decision lens over that source family rather than inventing one hidden universal winner rule.
  • CostToProbe, ValueOfInformation, and ValueOfComputation belong 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 DominanceSet and 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.SelectorMechanism remains the cited set-return floor
    • SelectionSlot remains the selector output floor
    • if later selector-facing set-result declaration is required, that set-returning floor may support one Shortlist or one RankedShortlist in G.5 rather 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 now because the current shared BeliefState and OutcomeModel already make one option or tie-set survive, and no still-feasible probe is worth its cost;
  • probe again because one further observation, measurement, or comparison pass could still change the ranking without requiring a heavier causal, subjunctive, or context-order repair;
  • reroute because the current decision question is no longer really comparing one fixed OptionSet, 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 now because, 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 again because one intervention-relevant uncertainty still blocks a lawful causal comparison and one named next probe could still change which option causally survives;
  • reroute because 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 now because, under the declared counterfactual or subjunctive structure, one option survives once the predictor-coupled comparison is made explicit;
  • probe again because one further model clarification, predictor assumption check, or decision-procedure comparison could still reverse the current survivor relation;
  • reroute because 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 again because 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 now because 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;
  • reroute because 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 now under one declared order or framing because rival orders no longer change which option survives;
  • probe again because 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;
  • reroute when 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.38 first.
  • 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.18 first.
  • 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 local ChoiceResult.
  • 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 or CheckpointReturn.
  • 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 a Shortlist or RankedShortlist when alternatives remain for later choice, a JointUseSet when every named member is included for one bounded use, a narrowed handoff, abstain, or escalation. None is one more local ChoiceResult. If that result already exists and the current question is presentation or availability to an audience, use E.17 for the source-backed publication face and return to source and E.24.PUB for 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:

  • DecisionSubject and DecisionSubjectGranularity;
  • OptionSet;
  • one evaluative basis through PreferenceOrder or EvaluativeMeasure;
  • BeliefState;
  • OutcomeModel;
  • ChoiceRule;
  • ChoiceResult.

The following objects activate when the case needs them:

  • InterventionModel for causal repair;
  • CounterfactualModel plus SubjunctiveDependenceRelation for success-first or predictor-coupled repair;
  • ProbeActionSet, ProbeBudget, CostToProbe, ValueOfInformation, and ValueOfComputation when 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, not Agent;
  • DecisionSubjectGranularity names 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.P together with A.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 make choose now, reject current set, probe again, or reroute lawful in this case;
  • ChoiceResult: the emitted result record saying which of those lawful choice results actually follows now under the current ChoiceRule;
  • 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.11 need not be one person-like agent;
  • a team, committee, organization, or coupled human-tool system may be the DecisionSubject when 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 ROE or 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: DecisionSubject at one DecisionSubjectGranularity;
  • what is currently choosable: OptionSet;
  • how the options are compared: PreferenceOrder, EvaluativeMeasure, BeliefState, and OutcomeModel;
  • which heavier dependence layer is active when the case needs it: InterventionModel, CounterfactualModel, and SubjunctiveDependenceRelation;
  • what comparison doctrine currently governs the case: one explicit ChoiceRule;
  • what further probing is still available and worth paying for: ProbeActionSet, ProbeBudget, CostToProbe, ValueOfInformation, and ValueOfComputation;
  • what the current comparison concludes: one emitted ChoiceResult that 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, or reroute.

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

IDRequirementPurpose
CC-C11.1The pattern SHALL state that C.11 governs choice among already-available options rather than formation of comparable ways or open-ended candidate generation.Keeps C.38 and C.18 outside and prevents candidate-construction or search takeover.
CC-C11.2The pattern SHALL keep DecisionSubject as the default chooser term, and SHALL NOT use Agent as the generic chooser term unless one explicit agency claim is governed by A.13; measured characteristic and evidence claims use the A.17/A.18/A.19/C.16/A.10 stack, and planned C.9 supplies no current governing force.Prevents unwanted narrowing of the chooser.
CC-C11.3The pattern SHALL state the boundary among C.11, C.38, C.18, C.19, C.24, and G.5 explicitly in the body.Prevents collapse of choice doctrine, same-result way formation, open-ended generation, candidate-pool policy, planning, and selector-facing result declaration.
CC-C11.4Solution SHALL state one inspectable decision procedure from DecisionSubject and OptionSet through comparison basis, dependence layer, probe-worthiness test, one explicit ChoiceRule, and one emitted ChoiceResult.Keeps C.11 as one operational answer to the choice question rather than one survey of schools.
CC-C11.5The pattern SHALL name one minimal decision inventory including DecisionSubject, DecisionSubjectGranularity, OptionSet, PreferenceOrder, EvaluativeMeasure, BeliefState, OutcomeModel, ChoiceRule, ChoiceResult, ProbeActionSet, ProbeBudget, CostToProbe, ValueOfInformation, and ValueOfComputation.Keeps the calculus objectual rather than slogan-like.
CC-C11.6Load-bearing inventory terms used in the pattern text SHALL receive local plain glosses or equivalent operational clarification inside the body.Prevents the core terminology from remaining implicit or displaced into outside basis carriers.
CC-C11.7Relation-heavy terms such as PreferenceOrder, CounterfactualModel, and SubjunctiveDependenceRelation SHALL remain answerable to A.6.P together with A.6.5.Keeps dependence language inspectable and deconflicted.
CC-C11.8Active-inference and quantum-like lines SHALL be introduced through the limitations they repair, not as prestige branch names.Preserves practical meaning and avoids branch-name citation without operational load.
CC-C11.9The pattern SHALL expose one minimal mathematical floor without overclaiming one full quantum-like or geometry-heavy formal package.Keeps the pattern usable now while leaving heavier support work typed and explicit.
CC-C11.10ProbeBudget SHALL stay in C.11 while it means the budget for further probing before choice, and ValueOfInformation / ValueOfComputation SHALL stay theory-side comparative criteria even when C.19 or C.24 later consume their outputs.Preserves the bounded-resource bridge without letting neighboring patterns steal the doctrine.
CC-C11.11Shortlist or other selector-facing set-result declaration SHALL NOT be treated as part of C.11; if the question shifts to declaring or naming that result, the text SHALL apply G.5. Actual presentation or availability SHALL remain separate: use E.17 for the publication face and return to source and E.24.PUB for the publication occurrence and availability.Preserves the boundary among local choice, selector-result declaration, and publication availability.
CC-C11.12When one heavier dependence layer or neighboring family line is activated, the text SHALL state what limitation of the simpler comparison it repairs and what changes in the actual comparison once that line is in play.Prevents branch-name citation from replacing use-time doctrine.
CC-C11.13The text SHALL make the closure rule explicit enough to justify why the lawful result is choose now, reject current set, probe again, or reroute rather than some softer holding-pattern output, and SHALL treat vaguer endings as unfinished rather than as lawful results.Prevents the decision record from ending in one sophisticated but operationally empty result.
CC-C11.14The decision record SHALL make one minimal decision-record shape explicit: chooser, option set, comparison basis, one explicit ChoiceRule, probe decision value, and one emitted ChoiceResult; choose now, reject current set, probe again, and reroute outputs SHALL each state their mandatory fields explicitly enough to determine the lawful choice result without reopening surrounding rationale.Keeps the pattern usable as one working decision record rather than one doctrinal memo.
CC-C11.15If a ChoiceResult is supported by a causal effect, counterfactual comparison, causal policy, or off-policy causal evaluation claim, it SHALL carry ChoiceResult.causalUseSpec? with the target rung, claim kind, relevant support-component refs, support-result ref when consumed, supported use, and unsupported use.Prevents decision-theory vocabulary from certifying causal-use support.

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.

Anti-patternSymptomWhy it failsHow to avoid / repair
Candidate-formation or search takeoverThe text starts constructing complete ways or generating options as if that work were already part of decision doctrine.C.11 loses its decision-theory EntityOfConcern and silently absorbs C.38 or C.18.State the option set as already existing; use C.38 for same-result way formation and C.18 for open-ended generation.
Policy collapseExploration or exploitation governance over a candidate pool is written as if it were identical with choosing among current options.Choice doctrine and candidate-pool policy become indistinguishable.C.19 remains explicit as the neighboring pattern for selection policy and exploration governance.
Planning collapseSequencing, replanning, and enactment budgeting are written as if they were already part of the choice calculus.Planning-side question moves out of C.24 by accident.Execution order and operational budgeting remain in C.24, even when C.11 says more probing is rational.
Inventory without decision ruleThe current comparison names many objects and schools but never shows how to move from a live option set through one ChoiceRule to one ChoiceResult.The pattern becomes one cleaned-up survey rather than one decision discipline.State one explicit decision-record shape: chooser, option set, comparison basis, dependence layer, probe-worthiness test, one explicit doctrine, and one emitted result.
Hidden basis shiftDifferent options are compared under different belief states, outcome models, or dependence layers without one explicit statement that the basis changed.The comparison only looks precise; in fact the choice rule cannot be audited.Keep one shared comparison basis until one named probe or model change updates it, and state explicitly when the dependence layer changes.
No closure ruleThe text sounds careful but never says what makes choose now, reject current set, probe again, or reroute lawful.The record never closes into one explicit decision result.State the closure conditions explicitly and show why the current case satisfies exactly one of them.
Undefined load-bearing termsTerms such as PreferenceOrder, BeliefState, or OutcomeModel appear without local operational clarification.Core comparison objects stay implicit and the decision question depends on outside theory or undocumented assumptions.Give one local plain gloss or equivalent operational clarification for each load-bearing term used in the pattern text.
Bounded-resource bridge lossProbeBudget, ValueOfInformation, or ValueOfComputation are mentioned, but the text silently lets C.19 or C.24 own them.The theory-side doctrine disappears into neighboring policy or planning prose.Keep those objects theory-side in C.11; let neighboring patterns consume their outputs without minting the concepts.
Result-boundary collapseThe text treats declaring selector-facing set content, or later making it available, as if either were identical with deciding.Choice doctrine silently absorbs the G.5 result question or the publication question.Keep both outside C.11: use G.5 to declare the selector-facing result, E.17 for its publication face and return to source, and E.24.PUB for the publication occurrence and availability.
Agent-default narrowingEvery chooser is described as one Agent even when the subject is really one team, organization, or other collectivity-bearing system.The governed chooser is narrowed before the doctrine even starts.DecisionSubject remains the default, and DecisionSubjectGranularity types the chooser-bearing level.
Prestige-branch citationActive inference or quantum-like work is cited only as one fashionable name.The text sounds current without stating what limitation is being repaired.The repaired limitation is stated directly: embodied online updating for active inference, and context or order effects for quantum-like lines.
Cost-free deliberationThe text speaks as if probing and computation are free.Bounded-resource doctrine disappears behind one idealized choice moment.ProbeBudget, CostToProbe, ValueOfInformation, and ValueOfComputation stay visible in the calculus.

Consequences

BenefitsTrade-offs / Mitigations
Keeps decision doctrine distinct from search, candidate-pool policy, and planning.The same working episode now needs an explicit question split across choice, pool policy, and planning rather than one blurred rationality account.
Makes evidential, causal, and subjunctive branches comparable in one place.The pattern becomes more explicit about dependence language and therefore needs tighter lexical discipline.
Keeps bounded-resource probing inside the doctrine rather than as one afterthought.Fast-path use now carries a slightly richer inventory before the doctrine feels natural under pressure.
Keeps active-inference and quantum-like repairs visible without letting them silently replace the whole core.Those lines stay load-bearing only when they change the actual ChoiceResult, unfinished state, or reroute logic; heavier formal packages still remain outside this body.
Makes the choice result explicit through one ChoiceResult record instead of one general statement that the case is complex.Each decision record has to show why choose now, reject current set, probe again, or reroute is lawful, which removes rhetorical room to sound informed without committing to one result.
Makes downstream work cleaner because search, pool policy, publication, and enactment can receive one explicit output instead of one blurred upstream "decision happened" claim.Reroutes now require one named next subject pattern and one reusable part of the record instead of one vague upstream claim that deliberation happened somewhere.
Lets one comparison stay open honestly through one explicit tie-set or probe again result instead of forcing a fake winner.Some outcomes will look less rhetorically decisive because the pattern refuses to hide unfinished comparison under elegant prose.

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

ClaimSoTA practicePrimary sourceAlignment with C.11Adoption status
Decision theory still needs an explicit classical baseline over options, preferences, utility, and uncertainty.Contemporary reference treatments still present decision theory through option sets, preferences, utilities, and uncertainty as the baseline language of rational choice.Decision Theory (Stanford Encyclopedia of Philosophy, Fall 2023)C.11 adopts this as the baseline vocabulary for choice among already-available options.Adopt.
Evidential dependence is not enough in all cases.Causal decision theory remains the standard repair when intervention structure matters.Causal Decision Theory (Stanford Encyclopedia of Philosophy, Winter 2024)C.11 keeps one explicit evidential-versus-causal split rather than one blended correlation claim.Adopt.
The field no longer stops honestly at the older EDT/CDT split.Functional or success-first work keeps subjunctive dependence live in Newcomb-like and related cases.Functional Decision Theory: A New Theory of Instrumental RationalityC.11 keeps success-first or subjunctive repair visible without treating it as one settled default doctrine.Adapt.
The live EDT/CDT/FDT family map now has more technical comparison structures than one older philosophical split alone.Recent mechanized or causal-graph taxonomies compare live decision-theory families through more explicit technical structures rather than only one slogan-level naming dispute.Mechanized-causal-graphs taxonomy of decision theories (2023)C.11 therefore treats EDT, CDT, and success-first or FDT-like lines as technically live family options rather than one frozen classroom argument.Adapt.
Decision under bounds cannot leave probing and deliberation cost as one slogan.Current metareasoning and optimal-experimental-design lines treat information acquisition, probing, and computation allocation as first-class theoretical questions rather than free background steps.Metareasoning: Theoretical and Methodological DevelopmentsC.11 therefore keeps ProbeActionSet, ProbeBudget, CostToProbe, ValueOfInformation, and ValueOfComputation inside the doctrine rather than hiding them in planning-only prose; the current closure rule is intentionally local or myopic over the next feasible probe, with richer sequential or non-myopic OED left as later strengthening.Adapt.
Decision and update can be embodied, online, and socially coupled.Active-inference work treats decision as tightly coupled to action, inference, and expectation regimes rather than one disembodied one-shot selection.Embodied decisions as active inferenceC.11 carries this as one neighboring repair of the chooser picture, makes social-expectation pressure explicit enough for use-time reroute or probe logic, and states honestly that full ROE or social-expectation object modeling remains outside this local choice body.Adapt.
Some decision cases exhibit context effects, order effects, response-replicability tension, and incompatible-question structure.Current quantum-like decision and cognition work treats those cases as one measurement-sensitive research program rather than one discarded curiosity or one automatic physics transfer.Measurement-theory decision/cognition anchor (2025)C.11 carries this as one named neighboring branch where those repaired limitations are real, while leaving heavier branch-specific formalism outside this body.Adapt.
Incompatible question/context structures need a cleaner cue than "context matters."Contextuality-by-Default treats same-content-looking measurements in different contexts as distinct random variables unless an admissible joint treatment is supplied.Use CbD as the clean formal cue when question/context structure changes variable identity, joint availability, or admissible comparison inside the current option set.Adopt/Adapt.
Some quantum-like lines also claim one practical representational gain from linear state dynamics over harder nonlinear underlying processes.Quantum-like modeling in biology presents linear Hilbert-space dynamics as one simplifying and potentially faster information-processing lens over nonlinear classical biophysical dynamics, while treating this as representational modeling rather than proof that the modeled system is physically quantum.Quantum-like modeling in biology with open quantum systems and instrumentsC.11 takes this only as one possible practical reason to keep the quantum-like branch available when measurement-sensitive effects are real; it does not treat quantum-like choice as one claim of physical quantumness.Adapt cautiously.
Broader contextual and multilevel lines pressure decision texts to keep one typed substrate rather than pure verbal drift.Current multilevel-learning and evolution-as-inference work argues for one shared formal lens across levels even when the heavier final geometry is still unsettled.Multilevel selection as Bayesian inference, major transitions in individuality as structure learningC.11 therefore keeps one minimal typed floor and one wider chooser-bearing scope while stating by value that full aggregation doctrine, cross-scale or cross-collective conflict doctrine, and heavier multilevel mathematics remain outside this local choice body.Adapt.

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, or reroute result under one shared BeliefState and OutcomeModel.

  • 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 fuller ROE, 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.LRN for learning-word recovery, C.11.CRC for a missing finite configuration-relative comparison claim, C.17 for bounded characterization, and planned C.9 only as a future agency-characteristic-profile consolidation
  • Read next when this question leaves local choice: C.38 for forming complete ways of obtaining one result, C.18 for open-ended candidate generation and reframing, C.19 for one explicit pool-policy result over exploration or exploitation governance, C.24 for one enactment-facing call plan or CheckpointReturn, G.5 for the selector-facing result kind that is actually current—retained alternatives, all-member joint use, narrowed handoff, abstain, or escalation—and C.28 when 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.28 causal-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:

  1. State the current DecisionSubject, OptionSet, comparison basis, and ChoiceRule.
  2. Ask whether the apparent QL issue changes the local choice result: choose now, reject current set, probe again, or reframe the governing question.
  3. 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.
  4. 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, or B.5.2 as appropriate.
  5. If the issue changes boundary state, bridge/export faithfulness, coordinated-work evidence, measurement admissibility, or viability envelope, apply the pattern governing that claim.
  6. Emit one ChoiceResult and 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:

Question that appears in the decision caseFirst pattern
Boundary interaction, API read, workshop, dashboard, or message changes the represented stateC.26.1 only for the remaining state or probe question, with A.6, A.6.B, and A.6.P still active
Cross-context export, translation, or same-label comparison loses state or comparabilityF.9
Coordinated work evidences a state no report faithfully carriesA.15 plus evidence patterns, with C.26.2 only for the remaining low-recoverability distributed-state reading
Measurement, metric, survey, or score frame changes the represented stateC.16 plus evidence patterns
Viability envelope, adaptation cost, or boundary-maintenance decision is load-bearingC.25 first, with C.26.3 only for the remaining probe/export/frame/coarsening viability question
Current option set is suspect, incomplete, frame-generated, or still being expanded/reframed/searchedC.18, C.19, A.19, or B.5.2 before applying C.11

Useful outputs:

  • choose now under a declared order/frame;
  • probe again because another question order, response-replicability check, or frame test could still change the survivor relation;
  • reroute because 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.29 may supply a lens-supported prediction, distinction, obstruction, diagnostic boundary, or rival-lens note that a decision record can cite. If the output is a ChoiceResult or local choice record, use C.11 to state and test the decision. Any G.5 selector-result declaration and G.9 benchmark result remain separate. When one of those results 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. C.29 does not select the option by mathematical elegance.

C.11:End

Configuration-Relative Contribution Comparison

Tech name: ConfigurationRelativeContributionComparison

Plain name: compare what this finite change adds to the current configuration

Type: C-pattern

Status: Stable

Placement: a narrow companion used before C.11 when 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

ForceTension
Local simplicity vs finite realityDerivatives and local prices can be useful while the realizable change is indivisible, thresholded, or interacting.
Multiple results vs decision closureSeveral benefits, harms, and resources must stay visible without preventing a bounded choice.
Current value vs future optionsWaiting, learning, staging, reversibility, and path dependence can change later possibilities.
Reuse vs domain authorityFPF can supply the comparison grammar; domain Methods must calculate quantities and judge evidence.
Recognition vs assuranceA well-formed comparison can still lack trustworthy inputs, implementation capability, or required assurance.

Solution

Construct the smallest finite counterfactual comparison that can change one named decision.

  1. Name the receiving decision. State the deciding System, current DecisionSubject, decision deadline, current OptionSet or the option-set question that this comparison will inform, and which result could change the decision.
  2. 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, use A.1.CSD first; bring back only consequence claims compatible with this S0/Δ/S1, horizon, evidence window, and receiving decision. A historical, empty, or ideal configuration is not the default baseline.
  3. Name the finite change. State the addition, replacement, removal, intervention, or probe Δ, the realizable candidate configuration S1, admissibility conditions, implementation capability, transition Work, reversibility, and excluded variants.
  4. 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.
  5. 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.
  6. 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.
  7. Recover constraints and interactions. State active and potentially activated constraints, complements, substitutes, thresholds, congestion, downstream effects, common causes, overlaps, and double-counting risks.
  8. 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.
  9. Qualify evidence and uncertainty. Identify source claims, currentness, uncertainty, sensitivity/robustness results, transfer limits, rival explanations, and A.10 reliance dispositions where an evidence-bearing claim is used.
  10. Write the comparison claim. State what S1 contributes relative to S0 only 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.
  11. 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.
  12. Return to C.11. C.11 combines this claim with preferences, belief state, outcome model, probe worth, and other premises and emits one ChoiceResult. 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.

receivingDecisionRef:
currentConfigurationRef: S0
candidateFiniteChangeRef: Δ
candidateConfigurationRef: S1
systemBoundaryAndAffectedSystems:
horizonAndScenarios:
resultCoordinateRefs:
protectedCoordinateRefs:
resourceCoordinateRefs:
constraintsAndInteractions:
transitionAndImplementationBasis:
futureOptionEffects:
evidenceAndUncertaintyRefs:
comparisonClaim:
unsupportedOverreads:
reopenCondition:
nextGoverningPattern: C.11

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

Expression encounteredExact questionRequired boundary
Finite difference or counterfactual configuration comparisonWhat changes between realizable S0 and S1 over the declared horizon?Default here for indivisible, non-smooth, thresholded, path-dependent, or strongly interacting changes. Do not infer additivity.
Derivative or gradientWhat is the local rate of change with respect to a coordinate under smoothness and small-change assumptions?It approximates the finite contribution only when the validity region and remainder are adequate for Δ.
SensitivityHow does a result vary with a parameter, assumption, input, model, or scenario?It supplies robustness or assurance information; it need not describe a realizable configuration change.
Shadow price or dual variableWhat is the local value of relaxing a formulated active constraint under the primal/dual model?It depends on formulation, active set, regularity, units, and local region; it is not the contribution of an arbitrary asset or intervention.
Functional variation / calculus of variationsHow does a functional change when the varied object is a function, path, trajectory, field, control, or shape in a declared admissible variation space?Name the functional, admissible variations, constraints, boundary conditions, stationarity/extremum claim, sufficiency, and validation. An Euler–Lagrange equation is not a generic contribution claim or proof that a physical System optimizes.
Variational inferenceWhich member of an approximation family best approximates a target probability distribution under a declared divergence or bound?The result is an approximate distribution and uncertainty account, not an extremal physical trajectory, capability acquisition, or general marginal value.
Evolutionary variationHow are retained variants generated and selected in an evolutionary or cultural process?The shared word variation does not identify the mathematical object or Method above; route to C.18, C.36, or the field practice.

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

  1. Is one receiving decision named?
  2. Are S0, finite Δ, and realizable S1 explicit?
  3. Are system boundary, affected Systems, horizon, scenarios, and evidence window compatible—and, when a missing bearer could change the comparison, was A.1.CSD used before freezing this coordinate?
  4. Are result and resource coordinates explicit, with protected coordinates not silently scalarized?
  5. Are implementation capability, transition Work, reversibility, and excluded variants recoverable?
  6. Are constraints, interactions, overlap, thresholds, congestion, and downstream effects considered where material?
  7. Are future option effects distinguished from realized results?
  8. Are evidence, uncertainty, sensitivity/robustness, transfer limits, and unsupported overreads visible?
  9. Is each derivative, sensitivity, shadow-price, functional-variation, variational-inference, or evolutionary-variation result used only for its exact question?
  10. Does the output remain a comparison claim, with C.11 retaining the ChoiceResult?
  11. Is the smallest reopen condition stated?

Common Anti-Patterns and Repairs

Anti-patternRepair
Candidate value is constant across configurationsName S0, interactions, horizon, and affected Systems.
Average benefit chooses the next elementPreserve result/resource vectors and return the comparison to C.11.
Derivative times step equals finite contributionState smoothness region and remainder or perform the finite comparison.
Shadow price equals asset valueKeep the local active-constraint result and model the finite intervention separately.
Functional stationarity proves physical optimalityUse C.29, physical/domain evidence, sufficiency checks, and validation.
Variational inference is calculus of variations or “learning”Recover the target distribution, approximation family, objective, returned approximation, and diagnostics.
More information is already more capability or valueTreat information as a decision input and test the target result separately.

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

Source lineAdopted moveLimit retained here
Current C.11, A.19, and C.29Keep choice, comparison mechanisms, and mathematical-lens use with their current owners.Internal architecture is not evidence for domain quantities.
Ortega and Braun, information-processing costs in decision making, 2013Treat information and computation as explicit decision resources.Statistical-physics form is a model under assumptions, not proof of literal physical free-energy minimization.
Blei, Kucukelbir, and McAuliffe, Variational Inference: A Review for Statisticians, 2017Keep target distribution, approximation family, optimization, speed/scale, and uncertainty trade-offs visible.Historical field anchor; it does not define calculus-of-variations design or general contribution.
MIT OpenCourseWare, Matrix Calculus for Machine Learning and Beyond, 2023 calculus-of-variations materialTreat a function, trajectory, or field as the varied object under admissible variation and boundary structure.Course material supplies a mathematical distinction, not FPF ontology, physical evidence, or DPF admission.
Huan, Jagalur, and Marzouk, optimal experimental design review, 2024/2026Keep design variables, utility, model assumptions, computational cost, robustness, and myopic/non-myopic boundaries explicit.Specialist experiment design remains outside this finite comparison pattern.
Current systems, operations, finance, and human-capability cases named in the receiving DPF programmeStress-test finite baseline, interactions, constraints, uncertainty, and option effects across unlike fields.Cross-field recurrence establishes the comparison spine, not transferable formulas, thresholds, or authority.

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, and C.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.CSD when affected-System consequence coordinates are missing; C.18 when the candidate changes the possibility space; C.19 for pool governance; B.3 for 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.

FormPractical readingFacts required before the trace is truthfulWhat the form does not establish
Γ_m.sum(parts)These exact constituents are assembled as this integrated whole.one exact candidate whole; exact constituent entities; exact obtaining constructive part-relation occurrences; the assembly rule or method and its applicability; the candidate's identity or reidentification rulethat proximity, one drawing, a parts list, or the constituent set alone makes the whole; that every constituent change ends the whole
Γ_m.set(elems)These entities belong to this collection under the collection's own rule.one identified collection; identified entities; the belongs-to occurrences that obtain; the collection's belongs-to and identity rulesthat the notation creates the collection or relation; component integration, acting-system organization, agency, A.1 holonhood, constructive parthood, or transitive belonging
Γ_m.slice(entity, facet)This exact aspect is distinguished from this bearer under this facet.one exact bearer; one exact aspect; the governed facet; an exact obtaining aspect or portion relation and its identity rulean arbitrary view, time window, selected concern, or label becoming a world-side part

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, and slice are 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. set supports a collection account; it does not imply integrated assembly, ComponentOf, system agency, or A.1 recognition. Use sum only 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:groundedBy link and declared validationMode; 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.Structure does 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:

  • ComponentOf may accompany a sum construction;
  • an ordinary belongs-to sentence may accompany a set construction; the collection's own pattern supplies its meaning, occurrence history, and any recurrence rule;
  • AspectOf may accompany a slice construction;
  • PortionOf needs the direct portion relation and metrical semantics in A.14, not a facet spelling alone;
  • ConstituentOf needs 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)

BiasSymptomCounter-move
Constructor-centrismThe trace is treated as the real structure and the direct relation as decorative.Recover exact entities and obtaining direct relations first; use the trace only as their construction account.
Declaration-centrismA readable part edge is accepted without identifying the assembly, collection rule, facet, or identity conditions.Name the whole, collection, or aspect and its construction facts, then add the shortest truthful trace.
Collection mistaken for compositionA belongs-to statement or set trace is used to infer an integrated assembly or acting system.Keep collection identity and belonging separate; use sum only with independently obtaining constructive part relations and an assembly. The same candidate may have both accounts when both claims pass.
Snapshot extensionalismAny constituent replacement is taken to end the whole, or the same input set is taken to guarantee the same whole.Apply the candidate's direct identity and reidentification rule; include assembly relations and conditions.
Temporal leakageSequence, phase, or work order is encoded as structural construction.Keep order and time with their direct method and temporal patterns.
Evidence-created structureA current drawing, trace, or evidence record is taken to make the assembly obtain.Keep construction facts, trace claims, evidence, currentness, and receiving reliance separate.
Subject-owner bypassMethod steps, work items, a selected structure, or several changes are declared parts by generic C.13 notation.Require their direct composition owner; stop before structure holonhood or transformation composition when that governor is missing.

Conformance Checklist (normative, calculus‑level)

The following regulate a C.13 use.

IDRequirementPurpose
CC-C13-1 — Three forms.Use only sum, set, or slice for the C.13 construction narrative.Preserve a small cross-domain calculus.
CC-C13-2 — Exact direct basis.Name the whole, collection, or aspect; its inputs; the direct relation occurrences that obtain; its construction rule; and its identity or reidentification rule.Prevent notation-created entities and relations.
CC-C13-3 — Assembly-sensitive identity.Do not infer the identity of a whole, collection, or aspect from the input list alone; preserve assembly relations, rule conditions, and the direct reidentification law.Distinguish the same inputs under different assemblies, and one whole surviving a permitted constituent change.
CC-C13-4 — No order or time by constructor.Keep execution order, parallelism, temporal coverage, and phase with their direct patterns.Preserve the boundary among structural construction, temporal extent, and method order.
CC-C13-5 — Narratability.State the construction in ordinary language before or beside the shorthand.Keep the construction usable without notation.
CC-C13-6 — Direct-relation discipline.Use ComponentOf, a collection's own belongs-to predicate, AspectOf, PortionOf, or ConstituentOf only with the meaning defined for that relation; the trace defines none of them.Keeps public relation meanings with the patterns that define them.
CC-C13-7 — Trace separation.Treat a materialized trace as a C.2.1 episteme about construction; creating, publishing, losing, or revising it does not create or end the whole, collection, or aspect it describes.Keep ontology and epistemics separate.
CC-C13-8 — Collection belonging is not component parthood.A set construction establishes no integrated assembly, acting eligibility, or holonhood.Prevent collection-to-system drift.
CC-C13-9 — Facet explicitness.A slice use names the exact aspect, bearer, governed facet, direct relation, and identity rule; a temporal window is not a structural facet here.Prevent arbitrary slicing.
CC-C13-10 — Subject owner.Apply C.13 to method, work, or discipline holons only after their direct patterns identify exact parts and whole-forming relations.Permit accepted holon construction without generic decomposition.
CC-C13-11 — Published-edge boundary.A direct structural Working-Model edge remains usable without a trace. If its publication elects B.3.5 or a named current requirement demands that profile, the edge follows B.3.5 for the required trace link and validation mode; C.13 does not treat that publication apparatus as the world-side relation, assembly, or identity rule.Keep direct use, construction, and elected publication assurance distinct.
CC-C13-12 — Dependent structure stop.A selected U.Structure is not a holon, agent, or a new whole named by an MHT claim merely by selection, label, or diagram.Preserve the dependent-structure boundary.
CC-C13-13 — Transformation stop.Do not infer transformation composition, parthood, holonhood, or atomism from entity construction, method or work decomposition, timing, or missing part facts.Preserve the missing-governor boundary.

Common Anti-Patterns and How to Avoid Them

  • Constructor as public relation. A Γ_m trace 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 set construction is used to infer integrated assembly structure. Keep collection belonging distinct; use sum only 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, and slice explain 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:

  • sum asks how exact constituents and constructive relations assemble an integrated whole;
  • set asks which entities belong to a collection under that collection's identity and belongs-to rule;
  • slice asks 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 W applied method M to measurand x, using model f, calibration basis K, and actual input bindings X, and obtained output quantity value y with stated uncertainty u; episteme E states 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.

Scale typeComparisonsLocationDifferencesRatiosAdmissible summariesTypical unsupported anti-patterns
Nominal=, ≠mode, frequenciescounts, proportionsaveraging labels; ordering categories without a declared order
Ordinal<, =, > (rank)median, quantilesnot meaningfulorder‑respecting summaries (median rank, percentiles)arithmetic mean of ranks; variance on ranks; linear blends of ranks
Interval<, =, >mean locationΔ meaningfulratio not meaningfulmean, sd of differences, correlationratio claims (“twice as hot” in °C); geometric mean
Ratio<, =, >mean locationΔ meaningfulratios meaningfularithmetic/geometric means, cv, growth ratesadding heterogeneous units; log on nonpositive values

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:

ObjectGoverning question
Raw instrument outputWhat signal, bytes, count, image, trace, or other emitted entity exists?
IndicationWhat displayed or decoded value did the instrument provide under its indication semantics?
Actual subject stateWhat obtains for the physical, social, architectural, or epistemic subject independently of the record?
Measurement resultWhat value or values are attributed to the measurand, with relevant method, model, calibration, uncertainty, and time information?
Measurement-result epistemeWhat durable C.2.1 claim states that result and its interpretation basis?
Diagnosis or causal conclusionWhat later domain interpretation is supported under its own method and result algebra?
Criterion or acceptance verdictDid the exact criterion application return pass, fail, or unknown?
Decision resultWhat did separate C.11 decision work decide?

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

BiasSymptomCorrection
Number-as-factA displayed value lacks measurand, Characteristic, Scale, model, calibration, uncertainty, or time stance.Rebuild the complete C.16 chain.
Instrument realismRaw output or indication is asserted as the actual subject state.Separate output, indication, attributed result, and subject state.
Uncertainty launderingA point estimate is carried forward while model and calibration uncertainty disappear.Recover input uncertainties, correlations, propagation, and interpretation.
Dashboard authorityA tile or score is reused as diagnosis, assurance, acceptance, or decision authority.Route the later use to the exact patterns for its Work, result, provenance, currentness, and reliance claims.
Common-scale pressureDistinct scales are normalized merely because comparison is desired.Require an exact transformation and receiving comparison pattern; otherwise preserve incomparability.

Conformance Checklist (Normative)

  1. Subject: one exact measurand or measurement subject is named, with correct entity or relation arity.
  2. CSLC: Characteristic, Scale, Level or Coordinate, Unit when current, polarity, and time stance are explicit.
  3. Method/model: the exact U.Method, MethodDescription boundary, measurement model edition, inputs, output quantity, assumptions, and validity domain are recoverable.
  4. Calibration: applicable calibration work/result, reference basis, coefficients or corrections, validity interval, and uncertainty contribution are cited when required.
  5. Work: every actual performer has the A.13 core; the dated U.Work is 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.
  6. 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.
  7. Separation: raw output, indication, actual subject state, result, result episteme, diagnosis, verdict, and decision are not collapsed.
  8. Comparability: direct or transformed comparison names its exact basis and does not upgrade the Scale or mint a common scale.
  9. Provenance/use: A.10/G.6 provenance, G.11 currentness, bounded reliance, assurance, and later work remain under their subject patterns.
  10. 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.

Exact source and source-use decisionVisible C.16 mutationRejected overreadSmallest source-change replay
JCGM 200:2012, VIM3, online entry 2.9 measurement result, including the online corrections/annotations current at the qualification date — adopt the attributed-values-plus-relevant-information boundary.M-RES-1, M-RES-2, the calibrated-detector case, and checklist items 6–7 keep measurand, attributed values, uncertainty/relevant information, and result episteme distinct.A displayed indication, raw output, actual subject state, diagnosis, verdict, or decision is not the measurement result.Reopen only M-RES-1/2, the calibrated-detector result paragraph, and checklist items 6–7 if VIM changes the result/measurand boundary.
JCGM GUM-6:2020, Developing and using measurement modelsadapt its model/input/output/model-adequacy and uncertainty discipline to the C.16 measurement chain.M-MODEL-1, M-IO-1, M-UNC-1/2, the engine-test case, and checklist items 3–4 make model edition, actual inputs, output quantity, assumptions, calibration, covariance, propagation, and validity domain recoverable.Model input/output roles are not universal work relations; more provenance pointers do not reduce uncertainty; a formula or function does not prove that measurement work occurred.Reopen only M-MODEL-1, M-IO-1, M-UNC-1/2, the engine-test uncertainty paragraph, and checklist items 3–4 if GUM changes model construction, adequacy, or propagation requirements.
ISO 80000-1:2022, Quantities and units — Part 1: General and ISO/IEC 25024:2015, confirmed current in 2022Bridge-only for quantity/unit names and data-quality-measure alignment.They may populate a Concept-Set/Bridge used by M-CSLC-2 or a receiving data-quality measure; they do not change C.16's separation between Characteristic/Scale and measurement result.Standard quantity, unit, or quality-measure labels do not authorize arithmetic, comparability, acceptance, or a C.16 result.Reopen only the affected Bridge row plus M-CSLC-2 and checklist item 2; reopen no measurement case unless the mapped term was load-bearing there.
QUDT Schema 3.4.0, June 2026 catalogueBridge-only for citable quantity-kind, unit, dimension, and datatype identifiers.A C.16 record may cite a QUDT identifier after the F-pattern Bridge establishes the correspondence; M-CSLC-2 still governs admissible C.16 use.A shared URI does not prove same measurand, Scale, model, calibration regime, or direct comparability.Reopen only the cited Bridge mapping, M-CSLC-2, and checklist items 2 and 8 when the mapped QUDT graph or identifier changes.
W3C/OGC SOSA/SSN Recommendation 19 October 2017Bridge-only for sensor, observation, procedure, feature-of-interest, and observed-property terms. The 2023 Edition First Public Working Draft of 16 September 2025 is watch-only until it reaches a governing publication status.A Bridge may align an external observation/procedure record with C.16's measurand, method, work, indication, and result boundaries; it never replaces M-WORK-1 or M-RES-1/2.An SOSA/SSN observation graph does not by itself establish FPF work identity, actual bindings, measurement result, result episteme, or later use.Reopen only the affected SOSA/SSN Bridge, M-WORK-1, the external-record case that uses it, and checklist items 5–7 when the Recommendation changes or the 2023 Edition advances with a conflicting normative separation.

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 as DHCMethodRef, and C16RouteRef; 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:

  1. name the exact measurand or subject, Characteristic, Scale, value or Level, Unit, polarity, and time stance;
  2. separate reusable method and model from dated work and actual bindings;
  3. name input quantities, output quantity, calibration basis, uncertainty propagation, and one measurement-result episteme;
  4. distinguish emitted output, indication, actual subject state, measurement result, result episteme, diagnosis, criterion verdict, and decision; and
  5. 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:

FieldRequired content
Measurand and CharacteristicWhat exact subject quantity or characteristic is intended to be measured?
Scale and time stanceOn what Scale and Unit, at what time or window, is the value attributed?
Method, model, calibrationWhat reusable method/model and applicable calibration basis govern the reading?
Work and bindingsWhich dated work, performer, resources, and actual arguments participated?
Inputs, output, uncertaintyWhich model inputs determine the output quantity, and how is uncertainty propagated?
Result epistemeWhich C.2.1 episteme states the attributed value and interpretation basis?
BoundaryWhich raw output, indication, subject state, diagnosis, verdict, or decision remains separate?
UseWhich exact later use is supported, degraded, deferred, or unsupported?

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, use C.16, A.17, A.18, or A.19 directly.
  • If the claim being made is a Q-bundle, quality-term or evaluative characterization, or pattern-quality coordinate, use C.25, C.16.Q, or E.21 directly 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 ClaimGraph located?

The recoverable item may be:

  • a Characteristic under A.17;
  • a Scale, coordinate, value, unit, scoring method, measure, or measurement use under A.18 and C.16;
  • a CharacteristicSpace under A.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 metric as a universal measurement kind;
  • treating score as proof, readiness, gate passage, release permission, or decision;
  • treating axis, dimension, feature, property, or level as a recoverable characteristic by appearance;
  • treating strong, weak, robust, high, low, or better as meaningful without a scale and comparison reference or comparator set;
  • turning C.16.P into a CHR super-pattern or replacement for C.16, A.17, A.18, A.19, C.25, C.29, or E.21;
  • copying first-stage characterization repair lists into every subject pattern.

Forces

ForceTension
Compact comparison vs recoverable constructionReaders want quick words such as strong, weak, metric, score, and level; FPF needs characteristic, scale, value, and use boundaries.
Measurement discipline vs ordinary evaluationSome words are informal cues, some are real measurement claims, and some are quality-term or evaluative characterization.
Proxy usefulness vs proxy overreadIndicators and scores can be useful proxies but can also hide distortion, threshold choice, and non-comparability.
Characteristic-space breadth vs gate disciplineA characteristic space can guide comparison without becoming a gate, decision, or release authority.
Mathematical-lens use vs scalar shortcutA mathematical lens may expose structure, but C.29 lens-use result is not repaired by score wording alone.
Small repair vs full formMany cases need one repaired phrase or compact note, not a full measurement or characteristic-space publication.

Solution

Repair compressed characterization wording by producing a characteristic-scale repair note or equivalent local rewrite.

Minimum fields when a note is needed:

CharacteristicScaleRepairNote:
  triggerSpan:
  boundedTextSpanOrPublicationUnit:
  bearer:
  candidateConstruction:
  recoveredCharacteristic?:
  recoveredScale?:
  recoveredCoordinate?:
  recoveredValue?:
  recoveredScore?:
  unit?:
  scoringMethod?:
  indicatorRelationRef?: U.RelationRef for the selected indicated-characteristic, proxy, measurement-use, evidence-use, or other direct relation
  indicatorRelationDisposition: direct-relation | ordinary-indicator-wording | missing-governor
  comparisonReferenceOrComparatorSet?:
  thresholdRuleOrReference?:
  proxyDistortionRisk?:
  relationFunctionClaimRef:
  repairedWordingOrDemotion:
  admissibleUse:
  nonAdmissibleUse?:
  remainingReaderUse:
  disposition:

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

  1. Capture the trigger. Copy the exact word or phrase and the sentence that uses it.
  2. 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.
  3. 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.
  4. 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.
  5. 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-governor rather than storing an indicatorRole label.
  6. Separate adjacent claims. Evidence, assurance, gate, work, decision, causal-use, release, benchmark, publication, or authority claims are governed by their direct patterns.
  7. 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

Trigger wordingFirst recovery questionNot enough
metricIs there a declared Characteristic, Scale, measure, unit, scoring method, and admissible use?Saying "metric" as a synonym for evidence, quality, performance, or success.
scoreWhat value on which scale, computed how, and used for what comparison or threshold?Score as proof, gate passage, readiness, or release.
axis or dimensionIs this a Characteristic, coordinate in a characteristic space, mathematical factor, latent coordinate, structural aspect, or ordinary explanatory direction?Axis or dimension as self-evident ontology.
feature or propertyIs this an observed feature, characteristic, model feature, entity property, relation property, or ordinary prose?Feature or property as automatic characteristic.
strong or weakStrong or weak on which scale, for which characteristic, under which comparison reference or comparator set?Strength without scale.
robustRobust to what perturbation, under which scale, comparison, loss, or preserved-structure and lost-structure?Robust as general praise.
levelLevel on which declared scale or abstraction, not a free hierarchy.Level as undefined scale or maturity status.
indicatorIndicator of what characteristic or claim, with what proxy relation and distortion risk?Indicator as the indicated property.
thresholdPredicate over which characteristic space coordinates, with what comparison operator, cut value, band, region, dominance condition, scalarization policy if any, comparison reference or comparator set, gate or acceptance relation, and non-use boundary?Threshold as characteristic, measure, scalar score, decision, or proof by itself.
benchmarkBenchmark for which characteristic, comparison set, front, archive, or harness?Benchmark result as proof or release.

Adjacent Claim Governance Named by Value

Recovered construction, claim kind, or admissible-use boundarySubject pattern
CharacteristicA.17
Scale, value set, value, coordinate, unit, scoring method, measurement useA.18, C.16
CharacteristicSpaceA.19 or A.19.ECS when evaluation-characteristic-space construction is live
Q-bundle or quality-characterization disciplineC.25
Quality-term or evaluative characterization wordingC.16.Q after any needed characteristic and scale repair
Pattern-quality coordinate or pattern-quality evaluationE.21
Mathematical function, mathematical lens, preserved-structure and lost-structure, model adequacy or lens-use resultC.29
CHR mechanism, characteristic-space mechanism, selector, suite, or set-return lawA.19.CN, G.0, A.19.UINDM, A.19.USCM, A.19.ULSAM, A.19.CPM, A.19.SelectorMechanism, G.5, C.11, or mechanism pattern named by value
Evidence or proofA.10 or evidence pattern governing the claim
Assurance or engineering justificationB.3 or assurance pattern governing the claim
Gate, constraint, release, readiness thresholdA.20, A.21, release or admissibility pattern, or gate pattern governing the claim
Decision, choice, selected optionC.11
Causal-use claimC.28
Work, method, operation, implementationA.15, A.15.4, method or work pattern
Source, publication, carrier, dashboard, documentationC.2.P, E.17, or publication or source-use pattern governing the claim
Relation construction, comparison relation, or wording that says one value supports or is based on anotherA.6.P or retained relation named by value specialization

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, or indicator trigger lists that belong here;
  • C.16.P begins 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

WordingRepair
"This pattern is stronger."Recover the characteristic and scale. If the sentence means pattern-quality evaluation, use E.21; if it means relation strength, use A.6.P; if no scale exists, demote to ordinary prose or rewrite with the exact gain.
"Architecture score improved."Recover whether this is a score on a declared scale, pattern-quality coordinate, grounded architecture adequacy value, selected-structure characteristic value, Q-bundle value, benchmark result, gate threshold, or ordinary comparison. Use C.16.P before using the score.
"The metric supports launch."Recover measure, characteristic, scale, scoring method, threshold predicate or reference, and gate or decision pattern. The metric alone is not launch evidence, gate passage, decision authority, or launch justification.
"The model has robust quality."Recover robustness perturbation and scale, quality-term or evaluative characterization under C.16.Q, Q-bundle under C.25, or mathematical-lens use under C.29.
"Latent axis explains behavior."Recover whether axis is a latent coordinate, factor, mathematical lens, characteristic, or ordinary source-local word. Use C.29 when a mathematical-lens use is being claimed.
"The benchmark proves the method is better."Recover benchmark harness, characteristic space, comparison set, scale, statistical or evidential claim, and decision use. Use evidence named by value, decision, and work patterns as needed.

Bias-Annotation

BiasSymptomCorrection
Scalar verdict biasstrong, weak, robust, or high is used as a verdict without characteristic, scale, and comparison reference.Recover the characteristic-scale construction or demote the adjective to ordinary prose.
Proxy promotion biasAn indicator, metric, score, or benchmark result is treated as the thing indicated.Name the proxy relation, distortion risk, admissible use, and subject pattern for any wider claim.
Gate-by-number biasA threshold or score is treated as release, readiness, proof, or decision authority.Recover the threshold rule and cite the gate, assurance, decision, or release pattern that actually governs the use.

Conformance Checklist

CheckRequirement
CC-C16P-1The repair names trigger span, bearer, recovered characteristic or scale construction, subject pattern, admissible use, and remaining reader use. Necessary subject applicability and stop conditions remain explicit; an explanatory nonAdmissibleUse is optional under the full F.19:4 test.
CC-C16P-2metric, score, axis, dimension, feature, property, indicator, strong, weak, robust, level, coordinate, threshold, and benchmark are trigger words, not recovered kinds by themselves.
CC-C16P-3Direct C.16, A.17, A.18, A.19, C.25, C.29, E.21, or subject-pattern use applies the subject pattern directly when construction is already recoverable.
CC-C16P-4Evidence, assurance, gate, work, decision, causal-use, release, publication, benchmark, and authority claims are governed by their direct patterns.
CC-C16P-5The repair does not create a metrics-only restoration pattern, CHR super-pattern, scalar verdict, undefined maturity-status scheme, or release decision.
CC-C16P-6The repaired wording preserves one useful admissible reader use; type-correct but inert characterization wording is not recovered by value.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
Metric-as-evidenceA metric is treated as evidence, proof, gate input, or decision authority without evidence named by value, gate, decision, and measurement construction.Recover characteristic and scale construction, then apply A.10 or evidence named by value, gate, or decision pattern if that claim is being made.
Score-as-gateA score is treated as gate passage, readiness, release, or decision.Recover scale, threshold rule or reference, comparison reference or comparator set, and exact gate, decision, or release pattern.
Axis-as-ontologyAxis or dimension is treated as if it already named a characteristic or factor.Recover Characteristic, coordinate, latent factor, mathematical lens, structural aspect, or ordinary prose.
Strong-without-scaleStrong or weak modifies a claim without scale, characteristic, or comparison reference or comparator set.Write the characteristic named by value and scale or demote to ordinary prose.
Indicator-as-indicated-characteristicIndicator wording hides the indicated characteristic or proxy relation.Name the indicated characteristic or claim, exact direct relation, and proxy-distortion risk; return missing-governor when the relation cannot be recovered.
Characterization repair copied everywherePatterns for the next questions keep their own metric, score, or strong trigger lists.Keep one thin cue and use C.16.P for hidden construction.

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.

Practice sourceSource-use relation and currentnessWhat C.16.P adopts or adaptsFPF import boundary
ISO/IEC/IEEE 15939:2017 systems and software measurement process.Current-standard reference for measurement-process discipline.Disciplines CharacteristicScaleRepairNote fields for measure, scale, indicator, measurement use, and information need; informs CC-C16P-1 and direct requires C.16, A.17, and A.18.Does not make "metric" a recovered kind, evidence relation, gate, or decision by itself.
ISO/IEC 25010:2023 product quality model.Current-standard reference for quality-characteristic families.Disciplines quality and scalar-quality cases: a quality word needs characteristic and scale construction or quality-pattern use named by value before comparison, score, or gate use.Does not import ISO quality characteristics as the FPF quality ontology; quality-term or evaluative characterization still requires C.16.Q, C.25, or E.21 when live.
ISO/IEC 80000 quantities and units practice and VIM-style metrology vocabulary.Current reference for quantities, units, and measurement vocabulary.Disciplines unit, value, scale, and scoring-method fields; blocks number-without-scale and unitless comparison overreads.Does not impose physical-quantity metrology on qualitative, ordinal, or pattern-quality characteristic spaces.
NIST AI RMF 1.0 metric and risk-management practice, including measurement, monitoring, validity, and risk-tolerance framing.Current practice reference for proxy and indicator risk.Disciplines indicatorRelationRef, indicatorRelationDisposition, proxyDistortionRisk, threshold rule or reference, and non-admissible use; informs the indicator and proxy and score-as-gate anti-patterns.Does not let a risk metric, dashboard, or benchmark become assurance, release permission, or decision authority.
Current FPF internal characterization stack: A.17, A.18, C.16, A.19, C.25, C.29, and E.21.Current FPF governing-source relation; primary authority for FPF characteristic and scale recovery.Selects the subject pattern after repair and prevents C.16.P from becoming a CHR super-pattern.Does not copy local trigger lists into subject patterns or replace characteristic named by value-space, quality, mathematical-lens, benchmark, gate, or decision patterns.

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.10 catches hidden characteristic and scale wording and selects this pattern only when construction is hidden.
  • E.10.ARCH defines the shared wording-use recovery order and applicability row.
  • A.17, A.18, and C.16 govern characteristics, scales, values, measures, and measurement use.
  • A.19 governs characteristic-space construction.
  • C.25 governs Q-bundles.
  • C.16.Q governs quality-term or evaluative characterization wording.
  • E.21 governs pattern-quality evaluation characteristic spaces.
  • C.29 governs 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.P first.
  • 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:

  1. Phenomenal character or qualia when the experienced quality itself is the topic of description rather than an externally measured characteristic.
  2. Preconceptual fit or felt rightness before stable EntityOfConcern characterization.
  3. Latent and distributed fit signals in learned representations, world models, or active inference loops.
  4. Explanatory merit of a theory, problem frame, or conjecture.
  5. Architectural-description fitness and compression merit of an architecture description or architecture model under a declared viewpoint.
  6. Engineering quality families such as reliability, maintainability, security, evolvability.
  7. Usefulness and selection value in open-ended search, novelty–quality–diversity, or portfolio selection.
  8. 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 ReferencePlane values 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 affordance cases that must leave quality-term restoration for A.6.A or 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:

  1. 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.

  2. Recover the bearer and publication lane. Name the bearer and the relevant A.7 lane or kind: EntityOfConcern being described, description, episteme or publication face, carrier when the carrier itself is evaluated, pattern, model, policy, explanation, candidate, architecture description, work result, relation, action loop, or ordinary prose.

  3. Recover interpretation locality and reconstruct candidates. Recover the effective ReferenceScheme, probe/model frame, separate A.19.CPM comparison frame or none, U.ClaimScope, evaluator, and U.ViewpointRef or none. 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.

  4. 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. Apply A.6.P, A.6.A, C.16.P, C.29, C.2.P, or the pattern for the recovered claim.

  5. Select one explicit quality sense. Pick one QualitySense token and state why rival senses were rejected in this local context.

  6. 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 explicit qualityTermAscription(...) transitional repair form with bearer, effective ReferenceScheme, probe/model and comparison frames, evaluator and U.ViewpointRef, U.ClaimScope, normal form, result boundary, and separate witness/evidence/grounding and cross-local qualifiers.

  7. 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:

qualityTermAscription :=
{
  bearerTuple: exact bearer designator(s),
  qualitySense: QualitySense,
  effectiveReferenceScheme: U.ReferenceScheme,
  probeOrModelFrameRef: exact domain-local probe or model frame,
  comparisonFrameRef: exact A.19.CPM-governed comparison frame | none,
  evaluatorRef: exact evaluator or policy ref | none,
  viewpointRef: U.ViewpointRef | none,
  referencePlane?,
  representationSchemeRef?: U.RepresentationScheme ref,
  normalForm: SignalPack | Characteristic | Bundle | Objective,
  claimScope: U.ClaimScope,
  contextSliceRefs?: exact U.ContextSlice refs,
  gammaTime?,
  representationSubstrate?: embodied-kinesthetic | latent-distributed | symbolic-local | hybrid,
  qualityResultClaimRef?: exact separately constituted result-episteme ref,
  witnessRefs?: exact witness refs,
  evidenceProvenancePathRefs?: refs to exact direct relations in an A.10 path,
  empiricalGroundingRelationRef?: exact EpistemeEmpiricalGroundingRelation occurrence ref | none,
  bridgeOccurrenceRef?: exact F.9 Bridge occurrence ref | none,
  bridgeUseClaimRef?: exact F.9 bounded-use claim ref | none,
  bridgeCardRef?: exact F.9 Bridge Card ref | none,
  bridgeStanceNoteRef?: exact F.9.1 stance-episteme ref | none,
  endpointPatternLocator?: pattern ref for the endpoint,
  endpointSourceRelationRef?: exact direct source or publication relation ref,
  admissibleUse,
  nonAdmissibleUse
}

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 -ility heads published as one Characteristic or one Q-Bundle,
  • selector-context uses published as an Objective headed by QS.UseValue unless 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:

QualitySense :=

    senseId,
    bearerArity,
    articulationMode,
    representationSubstrate,
    defaultNormalForm,
    admissibleNormalForms,
    probeOrModelFrameKind,
    comparisonFrameRequired,
    admissibleEvidenceModes,
    admissibleChangeClasses,
    bridgePolicy

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 }
  • admissibleNormalForms is the explicitly declared set of admissible evaluative normal forms for the sense. defaultNormalForm names the primary evaluative normal form; any additional endpoint forms MUST be declared here rather than inferred ad hoc. probeOrModelFrameKind constrains only the domain-local probe/model configuration, while comparisonFrameRequired states whether a separate A.19.CPM comparison configuration must be named. bridgePolicy can 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:

QualitySense tokenUse when “quality” means…Default normal formTypical substrateMust not be silently collapsed into
QS.PreconceptualFitpreconceptual fit, felt rightness, “quality before definition”, kinesthetic or embodied salienceSignalPackembodied-kinesthetic or hybridCharacteristic, utility, fitness score
QS.PhenomenalCharacterphenomenal character, qualia, or felt characteristic when the experienced quality itself is describedSignalPackembodied-kinesthetic or hybridQS.PreconceptualFit, engineering quality, utility
QS.LatentFitdistributed fit or tension in learned representations, world models, probes, prediction structuresSignalPacklatent-distributed or hybridQS.PreconceptualFit, engineering quality, explanatory merit
QS.ExplanatoryMeritepistemic merit of an explanation, conjecture, problem frame, or theoryBundlesymbolic-local or hybridengineering -ilities, use-value
QS.ArchitecturalDescriptionFitnesstask-fit and compression merit of an architecture description, architecture model, or viewpoint bundle as a description of structure for downstream reasoningBundlesymbolic-local or hybridQS.EngineeringQualityFamily, QS.ExplanatoryMerit, publication polish
QS.EngineeringQualityFamilyreliability, availability, security, maintainability, evolvability, usability, and related engineering familiesBundlesymbolic-local or hybridfunction or capability statements, preconceptual fit
QS.UseValueusefulness of a candidate under a declared goal or CG-frame; the “Q” head in NQD or QD by defaultObjectivesymbolic-local or hybridengineering quality family, explanatory merit
QS.ControlAdequacyadequacy of a policy, model, or controller in a closed action loopBundlehybridbare model “quality”, felt fit

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.UseValue unless a different QualitySense is explicitly declared.

  • In engineering contexts, bare quality SHALL rewrite either to:

    • one explicit U.Characteristic + CSLC Scale, or
    • one explicit Bundle, preferably published as a Q-Bundle when composite.
  • In phenomenological contexts, bare quality SHALL rewrite to QS.PhenomenalCharacter when the experienced quality itself is the topic of description, and to QS.PreconceptualFit when 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, use QS.ArchitecturalDescriptionFitness.

Required slots for a conforming qualityTermAscription

A conforming qualityTermAscription SHALL make explicit:

  1. 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.

  2. QualitySense. Name the intended evaluative family.

  3. Effective ReferenceScheme. State the effective U.ReferenceScheme by value so every designator and local sense in the ascription is interpretable. A generic context label or a representation scheme is not a substitute.

  4. 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.

  5. 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 none when the ascription proposes no comparison; do not let the probe/model frame silently select one.

  6. Evaluator and viewpoint reference. State the evaluator or policy and, independently, either one U.ViewpointRef or none. A non-none reference SHALL resolve to one exact viewpoint episteme under E.17.0; neither the reference nor its resolution is the evaluator.

  7. Normal form and result boundary. State whether the ascription uses SignalPack, Characteristic, Bundle, or Objective. If separately performed assessment work produced a result claim, cite that exact C.2.1 episteme through qualityResultClaimRef; do not identify the work, result, bearer, or transitional record with one another.

  8. ClaimScope, selected slices, and time. State one U.ClaimScope and its exact U.ContextSlice membership when the members matter. State Γ_time when omission changes meaning. U.WorkScope and U.PublicationScope remain 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.

  9. 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.

  10. 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.

  11. 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 state none; witness or record presence does not create that relation.

  12. 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 EntityOfConcern is 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 Characteristic unless 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.F first 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.M module-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, -ility names are quality-family labels, not automatically Characteristics. They become admissible only as one explicit U.Characteristic or one explicit Bundle (preferably expressed through Q-Bundle when 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 neither Disjoint, 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.PreconceptualFit and QS.LatentFit are usually only candidates for partial correspondence. If their exact F.17 cells are cross-local, test an F.9 kind such as Partial-overlap; an optional partialAnalogy note may help read the resulting bounded-use claim but cannot establish identity.
  • A progression from QS.PreconceptualFit to QS.PhenomenalCharacter needs its exact direct relation or bounded-use account; shared articulation history does not make the senses identical.
  • Using QS.PreconceptualFit to 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.EngineeringQualityFamily to QS.UseValue is 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.ExplanatoryMerit and QS.UseValue remain non-identical unless an exact F.9 Bridge obtains. An F.9.1 nonEquivalent note 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.PreconceptualFit or sometimes QS.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 Characteristic or Bundle publication under another declared sense; it is not identical with dynamic quality.
  • QS.ArchitecturalDescriptionFitness and QS.EngineeringQualityFamily have 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 the qualitySense slot.
  • reArticulate(...) — change articulationMode while 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 governed U.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(...) — change U.ClaimScope or its exact U.ContextSlice members.
  • 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:

  • LqualityTermAscription repair-form skeleton, QualitySense semantics, 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.Characteristic or Q-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 named U.Characteristic, Q-Bundle head, 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, episteme or publication face, or carrier when the carrier itself is evaluated) and, when omission changes meaning, an explicit referencePlane;

  • 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; use A.6.A or another applicable action-invitation pattern, with source-tradition affordance wording 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:

  1. Select a QualitySense and retain rival candidates while ambiguity is live.
  2. Name the exact bearer, effective ReferenceScheme, U.ClaimScope, and any meaning-changing Γ_time, reference plane, representation scheme, or substrate.
  3. Name the probe or model frame and the separate comparison frame or explicit none; then name evaluator and U.ViewpointRef independently.
  4. Choose an admissible normal form and identify any separately constituted quality-result claim.
  5. 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.
  6. 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.
  7. If the repaired sentence is boundary-bearing, emit L/A/D/E hooks rather than letting quality carry them implicitly.
  8. 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:

  1. 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 a QualitySense and explicit endpoint classification.
  2. 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.
  3. CC-C16Q-3 - Exact probe/model and comparison frames. The domain-local probe or model frame and the separately governed comparison frame or explicit none are stated and reviewable; no generic field silently selects either frame.
  4. CC-C16Q-4 - Effective scheme, evaluator, and viewpoint reference. The effective U.ReferenceScheme is explicit. Evaluator and U.ViewpointRef are separate; a non-none reference resolves one exact viewpoint episteme and grants no conformance, membership, authority, or result.
  5. CC-C16Q-5 - Substrate and referencePlane are declared when relevant. Cross-talk between preconceptual, latent-distributed, symbolic-local, and ReferencePlane values world, concept, and episteme is not allowed without explicit substrate and, when live, plane declarations.
  6. CC-C16Q-6 - ClaimScope, slices, and Γ_time are explicit. One U.ClaimScope, its meaning-changing U.ContextSlice members, and any meaning-changing Γ_time are stated; work or publication scope does not substitute for claim scope.
  7. CC-C16Q-7 - Admissible normal form and result boundary. The ascription uses SignalPack, Characteristic, Bundle, or Objective with the corresponding normal-form discipline; any checked object, assessment work, result claim, witnesses, evidence-provenance path, and empirical-grounding relation remain independently identified.
  8. CC-C16Q-8 - No illegal scalarization. Composite senses are not collapsed into one score without an explicit admissible scoring and comparison method.
  9. 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.
  10. CC-C16Q-10 - QD default. In search, selection, or NQD practice, quality resolves to QS.UseValue unless overridden explicitly.
  11. CC-C16Q-11 - Engineering family discipline. Engineering -ility uses resolve to one explicit U.Characteristic or one explicit Bundle, preferably a Q-Bundle when composite; they do not remain free-floating adjectives.
  12. CC-C16Q-12 - Functional separation. Function or capability claims remain distinct from quality-family claims.
  13. 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 EntityOfConcern is that claim. A stance word, CL, shared label, or loss note establishes none of them.
  14. 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/E claims and the patterns used to define or test them are explicit.
  15. CC-C16Q-15 - Lexical firewall. Bare quality is absent from Tech and normative prose except as quoted and marked metalinguistic discussion.
  16. 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.
  17. 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, episteme or 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.
  18. 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.
  19. 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

Anti-patternSymptomWhy it failsHow to avoid or repair
Magic scalar qualityone number silently stands for several evaluative familiescollapses senses, carriers, and scoring legalitypublish one explicit QualitySense and an admissible normal form
Preconceptual-as-metricfelt fit is presented as if it were already a measured characteristicerases articulation stage and overstates evidencekeep it as SignalPack until an admissible proxy is declared
Engineering adjective driftreliable, maintainable, or high-quality appear with no explicit Characteristic or Q-Bundlehides measurement shape and scoperewrite to one U.Characteristic or one Q-Bundle
Selector ambiguityquality in QD and NQD is left undefinedbreaks comparability and selection semanticsdefault to QS.UseValue unless another objective head is declared explicitly
Model-quality collapselatent fit, explanatory merit, and control adequacy are merged under one phrasedestroys carrier and frame distinctionssplit into separate qualityTermAscription(...) records
Architecture-vs-description collapsearchitecture quality is used with no explicit bearer lanecollapses the system-side bearer into its description, carrier, or publication facepublish the bearer lane explicitly and select QS.EngineeringQualityFamily or QS.ArchitecturalDescriptionFitness
Action-invitation-as-qualityaction invitations are narrated as if they were evaluationsthe rewrite hides action semantics instead of clarifying themstop the Q-rewrite and apply A.6.A or another applicable action-invitation pattern; name the action invitation and its relevant relation when later use depends on them; keep source-tradition affordance wording only as a quoted cue
Generic-frame collapseone evaluationFrame or context label is expected to supply probe, model, comparison, scope, and scheme semanticshides independently governed choices and makes a changed comparison look like the same claimname the effective ReferenceScheme, probe/model frame, A.19.CPM comparison frame, and ClaimScope separately
Embedded viewpointthe record stores a viewpoint-looking value as evaluator or generic contextcollapses reference, viewpoint episteme, evaluator, and resultstore one governed U.ViewpointRef or none; resolve it under E.17.0 and keep evaluator separate
Witness-is-groundinga test report, trace, score, or filled record is cited as empirical groundingpresence of a carrier or result label establishes no direct relationname witness refs and A.10 path separately; cite an exact obtaining EpistemeEmpiricalGroundingRelation or none
Bridge-by-label or stance noteshared quality wording or an F.9.1 stance word is treated as the cross-local relation or use authoritycreates false identity, silent loss, and unauthorized substitutionresolve exact F.17 cells, test and cite the F.9 Bridge, then state the separate bounded-use claim; add a Card only as optional packaging and a stance note only when its EntityOfConcern is that claim

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.

Claim (C.16.Q need)SoTA practice (post-2015)Source use and currentnessPrimary source (post-2015 unless marked lineage)Alignment with C.16.QAdoption status
Description-side quality must not be confused with system-side quality.Contemporary architecture-description practice distinguishes the system or entity that fills the architecture-description EntityOfConcern from the architecture description and structures discourse through viewpoints, concerns, and model kinds.Current-standard and reference-only use. The standard is a current architecture-description reference for entity, description, and viewpoint separation; it is not treated as a full quality-term repair method.ISO/IEC/IEEE 42010:2022, Software, systems and enterprise - Architecture description.C.16.Q mirrors this split by separating QS.ArchitecturalDescriptionFitness from system-side QS.EngineeringQualityFamily, and by requiring an explicit bearer lane plus referencePlane when phrases such as architecture quality appear.Adopt and adapt. Adopt the EntityOfConcern-vs-description split; adapt by making lexical repair and bearer-lane publication mandatory. Reject importing the standard's conceptual model as FPF ontology.
Engineering “quality” should resolve to explicit heads, not free adjectives.Contemporary systems/software quality practice works through named characteristics and subcharacteristics used to specify, measure, and evaluate quality, and to define acceptance criteria and requirements.Current-standard and reference-only use. The standard supplies a current quality-model reference for explicit heads; C.16.Q still requires FPF U.Characteristic, Q-Bundle, objective, or endpoint governance named by value.ISO/IEC 25010:2023, Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Product quality model.C.16.Q adopts the explicit-head discipline by assigning engineering uses either to one admissible Characteristic or to one explicit Bundle or Q-Bundle, and by refusing to leave quality requirement(s) as bare noun phrases.Adopt and adapt. Adopt explicit quality heads; adapt by treating composite families as bundles rather than pretending that every family label is already a scalar. Reject ISO characteristic lists as automatically sufficient FPF evaluation spaces.
Evolutionary architecture needs continuously checked heads rather than generic “quality”.Evolutionary-architecture practice uses fitness functions to drive, manage, and automate change across architectural concerns, and ties structure to the capacity for change.Current-practice reference use. The row records concern-specific fitness heads, not a universal definition of quality.Ford, Parsons, Kua, Sadalage (2022), Building Evolutionary Architectures, 2nd ed.C.16.Q aligns by treating engineering quality families and change-enabling concerns as explicit evaluative heads under declared frames, not as one rhetorical “high quality” scalar.Adopt and adapt. Adopt the fitness-function discipline; adapt by keeping QS.EngineeringQualityFamily, QS.ControlAdequacy, and QS.UseValue distinct and by forbidding function and quality-family collapse.
In QD, NQD, or selector settings, “quality” is an objective head under a declared search frame.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 and behavior descriptors; the archive is not a synonym for one hidden global score.Current-best source use for selector-quality semantics in this pattern revision. The row governs the QS.UseValue default, objective form, and scalar-collapse boundary; it does not define all QD and NQD practice.Fontaine, Togelius, Nikolaidis, Hoover (2020), Covariance matrix adaptation for the rapid illumination of behavior space; Fontaine & Nikolaidis (2023), Covariance Matrix Adaptation MAP-Annealing.C.16.Q therefore defaults selector-context quality to QS.UseValue in Objective form, while keeping novelty, diversity, and constraints explicit and separate.Adopt and adapt. Adopt objective-explicit selector semantics; adapt by making the Q-head a named QualitySense and by rejecting unexplained scalar collapse.
Latent fit, world-model adequacy, and closed-loop control must not collapse into one phrase.Contemporary world-model and active-inference work evaluates generative and predictive models, planning, action, uncertainty reduction, and intrinsic objectives through explicit factor sets rather than through one undifferentiated “model quality”.Current research and practice source use. The row is used for multi-factor separation of latent, control, and value claims; it is not imported as an active-inference ontology for FPF.Parr, Pezzulo, Friston (2022), Active Inference: The Free Energy Principle in Mind, Brain, and Behavior; LeCun (2022), A Path Towards Autonomous Machine Intelligence; Friston et al. (2024), Designing Ecosystems of Intelligence from First Principles.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.Adapt. Adapt multi-factor evaluation into one repair discipline; reject the colloquial habit of letting model quality silently cover representation, prediction, control, and utility at once.
Preconceptual felt fit should remain pre-metric until admissibly articulated.TAE-style practice treats felt aspects of thinking as something that can be clarified progressively with tentative language that stays responsive to lived experience and widens conceptual structure.Current-practice reference use with lineage use. The row is used for progressive articulation and the SignalPack boundary; it is not current-best source use for metric construction.Schoeller (2022), work on Thinking at the Edge and embodied critical thinking.C.16.Q uses this as a practice reason for QS.PreconceptualFit in SignalPack form, with exemplars, articulation notes, and an explicit ban on premature promotion to Characteristic.Adopt and adapt. Adopt progressive articulation from felt sense to wording; adapt by giving that articulation an admissible publication form and explicit witness discipline.
Some trigger uses of “quality” are really about action invitation, not evaluative characterization.Recent source-tradition affordance work treats affordances as perceptually available action possibilities, and in some accounts as invitations or action-guiding structures that position the agent to act.Current research cue and boundary cue. The row is used only to recognize action-invitation cases and send them to A.6.A or another applicable action-invitation pattern.Hansen (2024), Perceiving affordances and the problem of visually indiscernible kinds; Jorba & Lopez-Silva (2024), Mind in action: expanding the concept of affordance.C.16.Q closes the quality ascription and names the action invitation and relevant relation when later use depends on them, rather than forcing a QualitySense or qualityTermAscription(...).Adopt and adapt. Adopt the action-guiding insight; adapt by keeping action-invitation use explicit and the quality ascription closed. Reject importing affordance as a quality sense or FPF pattern name.
Explanation quality is an epistemic merit family, not engineering quality or selector utility.Contemporary philosophy of explanation treats understanding, explanatory value, and the cognitive significance of explanations as a distinct epistemic topic.Lineage and reference source use for a local evaluative family. The row is used for the QS.ExplanatoryMerit distinction and anti-scalarization boundary; it is not presented as current-best source use for all explanation evaluation.Khalifa (2017), Understanding, Explanation, and Scientific Knowledge.C.16.Q therefore treats explanatory evaluation as QS.ExplanatoryMerit, typically Bundle-shaped, and rejects silent collapse into engineering -ilities, bare usefulness, or one unexplained “high-quality explanation” score.Adapt. Adapt explanatory-value practice into a slot-explicit evaluative family; reject cross-family scalarization by label.

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 QualitySense starter 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, or ReferencePlane wording 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 in C.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, QualitySense rows, 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 engineering Q-Bundle publication.
  • 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 for U.ClaimScope and U.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 and U.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 qualityTermAscription repair-form skeleton, the QualitySense starter 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 general C.25 unless 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:

  1. identify the bearer being discussed;
  2. say what it is new compared with;
  3. say which objective, acceptance criterion, or must-constraint matters;
  4. 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:

  1. select one A.19 CharacteristicSpace and its A.19.ECS specification;
  2. fix the finite comparison corpus, inclusion rule, source editions, scope, comparison window, and evidence;
  3. identify the objective, acceptance criterion, and must-constraints actually used;
  4. identify the similarity or measurement Method used and any model, encoder, distance definition, invariances, calibration, and uncertainty basis it needs;
  5. for each coordinate, cite an existing complete C.16 measurement result, perform and constitute the missing C.16 measurement, or state a C.2.1 non-measurement ascription under its declared rule;
  6. form only the aggregate conclusion needed by the receiving comparison;
  7. 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

What the reader needsC.17 treatment
Evaluation spaceCreativityCharacteristicSpace is a local designator for one A.19 U.CharacteristicSpace. Its slots bind selected Characteristics to Scales and value sets.
Evaluation specificationOne C.2.1 episteme specializes A.19.ECS for the selected bearer kind and use. It states applicability, coordinate meanings, evidence and missingness rules, calibration, result shape, protected trade-offs, stop, and reopen conditions.
Comparison basisA finite corpus or reference set, with inclusion rule, source editions, coverage boundary, and comparison window. Use a separate source-selection episteme when the selection must persist.
Similarity or measurement procedureOne U.Method, with a separate MethodDescription when needed. Identify the model, encoder, distance definition, invariances, calibration, and limits used by that Method.
Generative expectationOne model episteme and its separately recoverable training basis: members or selection rule, source editions, training window, preprocessing, and evidence.
Evaluated bearerThe design, episteme, System, dated Work, finite set, or change under its already established kind. Creative outcome may remain ordinary prose; it is not another kind. When a change or Work episode has no single result episteme, identify that actual bearer and cite the result-and-evidence bundle used by the claim instead of wrapping the bundle in a new outcome kind.
Coordinate resultOne claim about the bearer, characteristic, scale value, scope, use, window, method or probe, basis, rationale, uncertainty, and evidence.
Aggregate resultOne CreativityEvaluationResult episteme whose EntityOfConcern is the bearer and whose claims state only the bounded coordinate and comparison conclusion.
Optional profileCreativityProfile is a local, non-arithmetic payload containing selected coordinate-claim references, their declared arrangement, and any current frontier or incomparability annotation.
Representation and publicationA table, chart, dashboard, or publication form represents or publishes the payload or result. It is not the payload or result.
Optional recordA separate CreativityEvaluationRecord episteme may package references to the configuration, results, profile, evidence, rendering, and actual Work for a named receiver.
Assessment occurrenceDated Work exists only when an overall assessment actually occurred and its System, assignment, Method enactment, Work extent, and evidence are recoverable. Any claimed application of a Mechanism operation is a separate conditional fact under A.6.1.

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:

Retired headUse instead
U.CreativitySpacethe selected A.19 CharacteristicSpace, locally called CreativityCharacteristicSpace when a short name helps
U.CreativityProfilethe optional local CreativityProfile payload, with any representation, publication form, or record identified separately
U.ReferenceBasethe finite corpus or reference set and, when needed, its source-selection episteme
U.SimilarityKernelthe Method used plus its model, encoder, distance definition, calibration, and limits
U.GenerativePriorthe model episteme and its separate training basis
U.CreativeOutcomethe bearer under its existing kind
U.CreativeEvaluationthe separately recoverable configuration, coordinate claims, aggregate result, optional payload and record, and any actual assessment Work

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.ECS specification 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 as None | 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 is not 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, report not yet obtained or 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.16 measurement-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.1 ascription 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

  1. Never use Novelty alone to approve or prefer a bearer. Pair it with Use-Value or the relevant ConstraintFit gate.
  2. State the selected characteristic subset, polarities, eligibility conditions, and comparability basis of every dominance claim.
  3. Preserve partial orders and incomparability. A Pareto or constraint-bounded Front follows from the declared rule; a visually pleasing hull is not a frontier.
  4. 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.
  5. Do not average ordinal Scales without an accepted model that supports the conversion.
  6. A result may state a frontier relation over a declared set. Use C.18 to maintain the current Front and Archive, C.19 to state pool treatment and tie-break policy, G.5 to declare selector-facing results, and C.11 to 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 DiversityOfSearch to 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

  1. Name the bearer, comparison corpus, objective, and must-criteria.
  2. State the smallest supported difference and consequence; stop if that answers the question.
  3. When numbers matter, select the space and specification and build each coordinate through C.16 or C.2.1.
  4. Compare with declared gates and a partial order; keep incomparability visible. When a retained set matters, report its declared Diversity_P or other needed set reading without turning that reading into selection policy.
  5. 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

IDRequirement
CC-C17-1The result identifies the bearer, comparison basis, objective or must-criterion, supported difference or coordinate, consequence, evidence, and limit needed by its use.
CC-C17-2A qualitative result stops before scores, reusable objects, or Work detail when none is needed.
CC-C17-3Every selected characteristic has a declared Characteristic, Scale, polarity, admissible operations, missingness rule, and evidence route under one selected A.19 space and A.19.ECS specification.
CC-C17-4Novelty identifies the finite corpus and inclusion rule, source editions, comparison window, Method, distance definition, coordinate construction and resulting Scale, calibration, uncertainty, scope, evidence, and use. The 1 - max similarity construction requires calibrated [0,1] similarity results or a declared lawful normalization to that range. When representations or observations are compared instead of the bearers, the result identifies both, the describing, projection, measurement, or other support relation, a compatible corpus basis or stated mapping, and relevant loss. When the value is load-bearing, the evidence includes an appropriate robustness diagnostic such as nearest-neighbour inspection, corpus/Method sensitivity, or an invariance ablation; the input inventory alone is not robustness evidence.
CC-C17-5Surprise identifies one model episteme and its separate training basis, modeled sample unit, encoding, size treatment, and discrete probability or continuous measure. A cross-bearer comparison uses a justified common extent, declared per-unit or code-length normalization, or another calibrated rule; otherwise the raw result stays basis-local. Use-Value identifies its objective or criterion; an improvement or gain also identifies its baseline and comparison or counterfactual Method. ConstraintFit identifies the must-constraints and their sources. AttributionIntegrity identifies the applicable duty set, the source or rule used to determine applicability, Scale, missingness rule, and evidence for each duty it evaluates. An empty applicable-duty set produces no numeric ratio; omit the characteristic or return explicit not applicable, distinct from an unresolved applicable duty.
CC-C17-6Each coordinate is either a complete C.16 measurement result or a C.2.1 non-measurement ascription under an explicit rule. A displayed number alone fails.
CC-C17-7Aggregate result, optional profile payload, representation or publication form, optional record, and any dated assessment Work remain distinct.
CC-C17-8Novelty is paired with Use-Value or ConstraintFit for approval-facing use; must-constraint failure remains an eligibility failure unless an independently valid exception applies.
CC-C17-9Dominance names the characteristic subset, Scale compatibility, polarity, eligibility conditions, and comparison rule. Frontiers are computed from that rule; scalarization is explicit and primitive coordinates remain available.
CC-C17-10Every used retained-set or applied reading identifies its bearer or set, local rule and Scale, and evidence. Diversity_P, Illumination, retained-set readings, and Work readings do not silently become selection rules or characteristics of a different bearer.
CC-C17-11Uncertainty, evidence, time window, model or corpus drift, and any cross-source or cross-scale loss are visible at the claim that depends on them.
CC-C17-12Dated overall-assessment Work is asserted only with its actual System, assignment, Method enactment, Work extent, and evidence. Do not infer an A.6.1 operation application from those facts. When an exact application or binding is separately claimed, satisfy the current A.6.1 application account and cite that application. Coordinate-measurement Work remains separate.
CC-C17-13Use C.17 to report characteristics and comparison results, C.18 for generation plus Archive and Front maintenance, C.19 for pool policy, G.5 for selector-facing declarations, and C.11 for choices.
CC-C17-14The seven retired predecessor heads are not used to create new kinds or actors.
CC-C17-15A cold reader can tell what to inspect first, when to stop, and what additional evidence is required for the stronger branch.

Common failures and repairs

FailureRepair
“It is creative.”Name the bearer, comparison basis, practical criterion, supported difference, consequence, and limit.
Novelty without a fixed corpus and MethodFix the finite corpus, inclusion rule, model or encoder, Method, Scale, and comparison window before using a coordinate.
Randomness treated as creativityPair Novelty or Surprise with Use-Value and ConstraintFit.
Gain without a baselineName the before-state and the A/B, back-test, causal-inference, or other comparison Method appropriate to the claim; otherwise report supported usefulness rather than gain.
One magic scoreKeep primitive coordinates, gates, partial order, incomparability, and sensitivity visible.
Pretty scatterplot called a frontierState the eligibility and dominance rule and compute the non-dominated set.
Ordinal arithmeticUse order-safe summaries or justify the model that supports an interval interpretation.
Profile-plan blurKeep the profile as coordinate-claim payload; put intended Work in a WorkPlan and actuals on dated Work.
Dashboard as evidence or resultIdentify the result and evidence independently; treat the dashboard as a representation.
Global or cross-scale noveltyName the source and receiving bases, mapping, direction, loss, evidence, and use.
Illumination or diversity silently drives selectionKeep it as telemetry unless a C.19 pool policy declares the use.
Pattern, model, record, or assignment said to assessName the System and dated Work only when an actual assessment occurred; otherwise state the result claim directly.

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.

Current practice and sourceSource-use decisionConcrete C.17 consequence
Judge novelty and usefulness as distinct, context-dependent questions. Harvey and Berry, Toward a Meta-Theory of Creativity Forms: How Novelty and Usefulness Shape Creativity, Academy of Management Review 48(3):504-529 (2023), DOI 10.5465/amr.2020.0110; Sen et al., Automated Creativity Evaluation of Language Models Across Open-Ended Tasks, ACL 2026, DOI 10.18653/v1/2026.acl-long.1061.Adopt the separation of creative breadth from task fulfilment and the dependence of usefulness on the practical situation. Adapt it by using the named comparison basis, Use-Value, and ConstraintFit already defined here. Reject a context-free creativity score and the cited paper's particular semantic-entropy or automated-judge machinery as universal FPF measures.The first move names both what the bearer differs from and which objective or must-criterion matters. Approval-facing use cannot substitute Novelty for Use-Value or ConstraintFit; CC-C17-1, CC-C17-5, and CC-C17-8 test that boundary.
Preserve a collection of different locally strong alternatives when the question needs coverage rather than one winner. Qin et al., A survey on Quality-Diversity optimization: Approaches, applications, and challenges, Swarm and Evolutionary Computation 100:102240 (2026), DOI 10.1016/j.swevo.2025.102240.Adopt the quality-diversity and illumination insight that coverage and local quality can matter together. Adapt it as Diversity_P, Illumination, or another declared retained-set reading. Reject MAP-Elites, a QD score, feature descriptor, container, or quota as a default C.17 method or selection rule.A set reading stays telemetry with its bearer, rule, Scale, and evidence. Use C.18 for Archive and Front maintenance, C.19 for pool treatment, and G.5 for selector-facing declarations; CC-C17-9 and CC-C17-10 keep these moves separate.
Test whether a result survives reasonable corpus, metric, and representation choices. Lu et al., Rethinking Creativity Evaluation: A Critical Analysis of Existing Creativity Evaluations, EACL 2026, DOI 10.18653/v1/2026.eacl-long.297; Stein et al., Exposing Flaws of Generative Model Evaluation Metrics and Their Unfair Treatment of Diffusion Models, NeurIPS 2023, DOI 10.52202/075280-0165.Adopt sensitivity checking and comparison with evidence suited to the receiving domain. Adapt it by making the corpus, inclusion rule, Method, model or encoder, distance, calibration, and uncertainty part of the claim. Reject transfer of one metric across domains, minor prompt or implementation stability as validity, and leaderboard standing as evidence of the bearer characteristic.For a load-bearing value, inspect neighbours and run the applicable corpus/Method sensitivity or invariance probe. If the conclusion changes, report that dependence or incomparability instead of hiding it in one score; CC-C17-4 and CC-C17-11 make this visible.
Check whether optimizing a proxy stops improving the result that matters. Gao, Schulman, and Hilton, Scaling Laws for Reward Model Overoptimization, ICML 2023, PMLR 202:10835-10866, https://proceedings.mlr.press/v202/gao23h.html.Adopt the warning that further proxy optimization can reduce performance under a separate target judgement. Adapt it by retaining primitive coordinates, gates, evidence, and held-out or delayed observations and by giving the local result a stop or reopen condition. Reject the reward-model setting or its fitted scaling law as a universal degradation model, and reject a rising proxy score as evidence that the bearer improved.The design and policy cases keep tooling and legal or equity gates visible even when another value improves. Scalarization never erases the primitive coordinates; later target evidence can reopen only the claims that relied on the proxy.

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, and B.3.
  • Coordinates with: E.10.LRN for ambiguous learning-family wording, A.13 for exact evaluator recovery and any separate agency or autonomy claim, F.9 for an actual Bridge, F.18 for lexical candidate-family diversity, A.0:QF.2a for an optional structured cross-scale qualifier, B.4 and G.11 for evolution and refresh, A.15.1, A.15.2, B.1.6, A.3.1, and A.3.2 for Work, plans, resources, and Method descriptions, A.2.1 and F.6 only for an expressly consumed precise assignment-bound attribution, and A.6.1 only for a separately claimed application of one exact declared Mechanism operation.
  • Supplies results to: C.18, C.19, and G.5 for their exact set-side questions, C.11.CRC only when one finite configuration-relative comparison is missing, and C.11 for 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: OpenEndedSearchArchiveAndFrontStewardship Plain-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, and E.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, the C.30 family, 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.5 for downstream selected-set result declaration, C.11 for local choice, the applicable C.30 or C.32 pattern for an architecture claim or candidate, C.36 for cultural-evolution case work, A.15.2 for planning, A.15.1 for performed Work, and G.11 for currentness and refresh.

Forces

ForceTension
Exploration valueA retained variant may be valuable as a stepping stone even when it is not on the current front.
Front honestyA front must preserve the declared comparator, dominance set, admissibility, and partial-order semantics.
Descriptor currentnessDescriptor maps, distance definitions, characteristic spaces, and family coordinates change over time.
Practical continuationEngineering teams need selected sets, architecture candidates, work plans, and measurements from archives without letting the archive authorize those moves.
Cultural and style casesMusic, dance, science, medical, product, and AI-agent variants need source labels and term bridges without minting cultural root kinds.
Telemetry usefulnessCoverage, novelty, diversity, QD score, and lineage are useful signals but can be overread as value, proof, or decision.

Solution

Keep archive, front, telemetry, generation, and downstream relations as separate records.

Archive Record

ExplorationArchiveRecord@Context:
  archiveRef:
  variantSetRef:
  descriptorMapRef:
  characteristicSpaceRef:
  distanceDefinitionRef?:
  retentionPolicyRef:
  retainedExplorationValue:
  steppingStoneUse?:
  lineageOrEditionPins:
  telemetryRefs?:
  currentnessAsOf:
  currentStatus:
  stopOrRefreshReason:
  nextGoverningRelation:

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

FrontRecord@Context:
  frontRef:
  candidateSetRef:
  comparatorOrDominanceSetRef:
  admissibilityRef:
  descriptorMapRef?:
  characteristicSpaceRef?:
  relationTokenSetRef:
  excludedTelemetryRefs?:
  selectedSetResultRef?:
  currentnessAsOf:
  currentStatus:
  stopOrRefreshReason:
  nextGoverningRelation:

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

ExplorationArchiveRecord@Context:
  archiveRef: dance-lab-variant-archive-2026
  variantSetRef: choreography variants generated during a festival lab
  descriptorMapRef: timing, body vocabulary, risk, teachability, audience recognizability
  characteristicSpaceRef: festival style-engineering characteristic space
  distanceDefinitionRef: difference in timing and body-vocabulary descriptors
  retentionPolicyRef: keep rare but teachable variants and variants that open later combination work
  retainedExplorationValue: stepping stones for teaching and later style intervention
  steppingStoneUse: candidate material for C.36 cultural-evolution case work
  lineageOrEditionPins: lab session, teacher edit, platform-publication edition
  telemetryRefs: replay counts, class adoption counts, jury notes
  currentnessAsOf: lab records and platform-publication edition reviewed through 2026-07-31
  currentStatus: active for retained exploration and teaching use
  stopOrRefreshReason: reopen through G.11 if the teaching-use judgement, retention policy, lineage, or platform edition changes
  nextGoverningRelation: C.36

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.

FrontRecord@Context:
  frontRef: cooling-module-maintainability-energy-front
  candidateSetRef: retained cooling-module architecture candidates
  comparatorOrDominanceSetRef: energy-use and maintainability comparator
  admissibilityRef: safety and manufacturing constraints already admitted by project policy
  descriptorMapRef: thermal performance, service access, part count, manufacturing tolerance
  characteristicSpaceRef: product-family architecture characteristic space
  relationTokenSetRef: non-dominated candidates under current comparator
  excludedTelemetryRefs: tests outside the current temperature envelope
  currentnessAsOf: comparator, safety constraints, and test evidence reviewed through 2026-07-31
  currentStatus: active non-dominated front for the declared comparator
  stopOrRefreshReason: reopen if eligibility, comparator, dominance grounds, or evidence edition changes
  nextGoverningRelation: C.30

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.

OpenEndedVariantGenerationRecord@Project:
  problemCardRef?:
  generationMethodOrFamilyRef:
  sourceRefs?:
  evaluatorOrComparatorRef?:
  emitterPolicyRef?:
  insertionPolicyRef?:
  dedupThreshold?:
  deduplicationBasisRef?:
  deduplicationUnit?:
  variantSetRef:
  descriptorMapRef:
  characteristicOrDescriptorSetRef:
  archiveOrFrontRef?:
  architectureCandidateRefs?:
  culturalVariantRefs?:
  telemetryRefs?:
  projectLocality?:
    generationWorkOccurrenceRef:
    compositeProjectWorkOccurrenceRef:
    governingRelationPatternRef:
    exactGenerationToProjectRelationRef:
  workPlanOrMeasurementRef?:
  refreshRef?:
  currentnessAsOf:
  currentStatus:
  stopOrRefreshReason:
  nextGoverningRelation:

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:

projectLocality:
  generationWorkOccurrenceRef: HarnessVariantGenerationRun-2026-07-31 : U.Work
  compositeProjectWorkOccurrenceRef: AgentHarnessProjectWork-2026 : U.Work
  governingRelationPatternRef: A.15.1
  exactGenerationToProjectRelationRef: OperationalPartOf_work(HarnessVariantGenerationRun-2026-07-31, AgentHarnessProjectWork-2026)

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:

Mode wordingRequired claimBlocked overread
exploratoryThe candidate, trajectory, or recombination is new or distant under the declared descriptors but remains admissible under the same effective generator, types/operators, evaluator, retention rule, and environment.Archive distance, novelty, local learning progress, or rarity does not prove that the space expanded.
expansiveA new dimension, candidate type, operator, building block, goal/action, or reachable region becomes admissible while the higher-order generation/evaluation regime remains sufficiently comparable for the stated use.A newly visited region is not expansion unless it was unavailable under the earlier effective space.
transformationalThe rule or representation that generates, admits, evaluates, retains, reproduces, or environmentally enables candidates changes so that what counts as a candidate, successor, or acceptable result changes.Rewording, a new score, or one surprising candidate does not establish a changed regime.

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=steppingStone when 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-1 Descriptor, characteristic, distance, and family-coordinate refs are named before generation, archive update, or front publication.
  • CC-C18-2 Archive and front returns are separate from a selected-set result unless one is explicitly declared from them through G.5.
  • CC-C18-3 Telemetry 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-4 Retained exploration value, stepping-stone use, lineage, and edition pins are recorded for archive use.
  • CC-C18-5 Architecture candidates use C.30 family patterns before becoming architecture moves.
  • CC-C18-6 Cultural variants use C.36 or term-bridge patterns before becoming cultural-evolution claims.
  • CC-C18-7 Refresh uses G.11 with the smallest affected archive, front, descriptor, edition, or lineage locus.
  • CC-C18-8 Agent-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 without E.23 re-evaluation.
  • CC-C18-9 A filled projectLocality? names independently admitted dated generation and composite project U.Work occurrences, the subject pattern, and one exact obtaining relation; @Project alone remains retrieval-only.
  • CC-C18-10 Problem-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-11 The 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 to G.11.
  • CC-C18-12 Any 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.

Source or source familyAdopted FPF moveRejected overreadField or boundary changed
Lin et al., Quality-Diversity Optimization as Multi-Objective Optimization, arXiv:2602.00478v1 (2026-01-31).Treat QD and Q-front work through declared Q components, DominanceSet, comparator refs, archive relation, front relation, G.5 selected-set result declaration, separate audience publication, and refresh.Cell-filling or popularity accounts are the current ontology by default.FrontRecord@Context must keep dominance grounds, comparator refs, and Q-component refs explicit.
Qin et al., A survey on Quality-Diversity optimization: Approaches, applications, and challenges, Swarm and Evolutionary Computation 100:102240 (2026), DOI 10.1016/j.swevo.2025.102240, https://www.sciencedirect.com/science/article/pii/S2210650225003979.Use current survey support for approaches, applications, archive use, diversity use, and challenge framing.Survey taxonomy replaces FPF relation definitions.Use C.18 to state and test the ExplorationArchiveRecord@Context, FrontRecord@Context, and OpenEndedVariantGenerationRecord@Project; use 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, and G.11 for refresh.
Batra et al., Quality Diversity for Robot Learning: Limitations and Future Directions, arXiv:2407.17515v1 (2024-07-09).State retained exploration value, generalization pressure, and limitations when an archive is used beyond current dominance.Bounded archives or cell occupancy are enough evidence that NQD and OEE are useful.retainedExplorationValue, retentionPolicyRef, telemetryRefs, and nextGoverningRelation must be filled when the archive is relied on.
Zhang et al., Darwin Godel Machine, arXiv:2505.22954v3 (2026-03-12).Keep generated agents, archive lineage, empirically validated changes, method-family use, evaluation, and refresh separate.OEE is one winner-selection method or source-free self-improvement story.OpenEndedVariantGenerationRecord@Project records generation and archive or front linkage, while evaluation and refresh move to their subject patterns.
Novikov et al., AlphaEvolve, arXiv:2506.13131v1 (2025-06-16).Separate generated method text, method description, evaluator relation, selected set, source-use relation, performed work, and work result.Generated algorithm text is proof, gate permission, accepted method selection, or performed work.evaluatorOrComparatorRef, lineage, source refs, and nextGoverningRelation decide whether to use C.18, A.19, G.5, C.11, A.15, or G.11.
Cultural-evolution and style-engineering source pressure from the music and dance intake.Keep generated style or tradition variants as archive or front records until a cultural-evolution case or term bridge is current.A cultural-style variant is a root cultural kind or a selected set by label.culturalVariantRefs continue to C.36, F.17, F.18, or F.9; selected-set result declaration continues to G.5, with a stable public identity added only through its conditional UTS branch.
Architecture-search and product-family work.Treat retained structures as candidate architecture moves only after the architecture claim is named.An archive of layouts is the architecture or the architecture decision.Architecture candidates require C.30, C.30.ASV, C.30.AD, or C.32.P2S after C.18 records descriptor, archive or front relation, and telemetry.
Taylor, Evolutionary Innovations and Where to Find Them, 2019, read with Di Bona et al., higher-order novelties, 2025, and Kalambokidis et al., diversity and open-ended evolution, 2026.Distinguish exploratory, expansive, and transformational claims; keep generator, evaluator, building blocks, retention/reproduction, environment, and opportunity structure explicit.A taxonomy or high novelty/diversity result proves that a transferred non-evolutionary case changed its possibility space.C.18:4.3a requires an exact earlier/candidate mapping and evidence limit; causal production uses C.28.

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 bind S to 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 S values 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 S within 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 affect R only.

Norms (SLL).

  • SLL‑1 (Declaration). Any profile claiming scale behaviour SHALL declare S and 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 S is 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).

  1. Choose knobs S that are plausibly monotone in the Context (compute/data/capacity/FoA).
  2. Pick 3–5 probe points per active knob (edge/mid/edge) under iso‑scale parity; use a fractional factorial if >2 knobs.
  3. Run replicates (≥ 3 preferred) and bootstrap 95% CI on the primary objective(s); log seeds.
  4. Estimate local slopes on a log‑log grid; apply piecewise/segmented regression or a knee detector (e.g., L‑curve/Kneedle) to support χ.
  5. Record invariants (pinned knobs, safety envelope) and publish SLL.Card@Context.
  6. 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

BiasSymptomCorrection
Bigger-is-better biasMore compute, data, capacity, or freedom of action is treated as automatic improvement.Declare S, ScaleWindow, and elasticity class before using the scale claim.
Telemetry-as-objective biasCoverage or illumination is promoted into dominance by default.Keep telemetry report-only unless the selector policy explicitly admits it.
Knee-by-story biasA plateau or knee is asserted from one anecdote or one late observation.Require scale-probe points, replicates or uncertainty, and a cited threshold policy.

Conformance Checklist (CC-SLL)

  1. S declared or S = N/A with rationale.
  2. Scale-probe performed; χ recorded with replicates and CI; invariants disclosed.
  3. iso-scale parity or loss notes + penalties → R only; editions/seeds pinned; ComparatorSet cited.
  4. If used as tie-breaker, the selector cites χ and lens id in E/E-LOG provenance.
  5. 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.1 supplies scale-window and scaling-law evidence for C.29 when a mathematical lens claims scale behavior, universality, knees, exponents, coarse-graining validity, or diminishing returns. C.29 cannot 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.29 uses 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_share keeps 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?:

PoolPolicyResult.causalUseSpec?:
  causalUseQuestionRef?: CausalUseQuestionRef
  targetCausalityLadderRung: CausalityLadderRung
  causalUseClaimKind: CausalUseClaimKind
  causalActionPolicyClass?: CausalActionPolicyClass
  causalSupportComponentRefs?: CausalSupportComponentRefs
  causalUseEvidenceDesignRef?
  offPolicyCausalEvaluationResultRef?
  causalUseSupportResultRef?: CausalUseSupportResultRef
  supportedUse
  unsupportedUse

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.DominanceRegime from G.Core and [G.5](/generated/patterns/G.5); in ordinary Q-front use this means {Q components} with ConstraintFit=pass as 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_P unless 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 in CharacteristicSpace.
  • Policy family: one uncertainty-aware explore policy family with one declared regime key and explicit change triggers; UCB-class with moderate temperature and explore_share ≈ 0.3–0.5 is one didactic starter profile, not the semantic default family.
  • Provenance (minimum): record DescriptorMapRef.edition, DistanceDefRef.edition, DHCMethodRef.edition, emitterPolicyRef, insertionPolicyRef, scalar dedupThreshold, deduplicationBasisRef, deduplicationUnit, timeWindow, and seeds.

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 graduationConditionRef is satisfied. When that condition relies on assurance, assuranceResultRef cites 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 dated U.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).

  1. Read the current C.18 archive/front reference and its replay boundary; do not recompute either object inside C.19.
  2. 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.
  3. Apply eligibility and the direct condition cited by graduationConditionRef: record graduation pressure and choose exactly one currentTreatment from widen | keep_frontier | narrow_to_subset | sunset_line. If assurance is part of that judgement, cite the bounded B.3 result separately.
  4. 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.
  5. 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.
  6. Emit one PoolPolicyResult with livePool, 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 a wild_bet_quota; otherwise exploit top‑trust region.
  • Spike‑first — pick highest Use‑Value subject to ConstraintFit=pass and a small Cost‑to‑Probe cap.
  • Safety‑first — minimize SafetyRisk subject to Use‑Value ≥ θ and ConstraintFit=pass.
  • Platform‑option — maximize Option‑Value under probe cost bounds.
  • Pilot-then-scale — optimize Use-Value on the declared pilot scope. Set currentTreatment = widen only when assuranceResultRef cites the exact B.3 assurance result whose supported scope includes the proposed wider pool, and changeTrigger names 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 FamilyCoverage or MinInterFamilyDistance gate, a family or subfamily quota, or a diversity-promoting sampler; no universal k, δ_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 alongside emitterPolicyRef. (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 from widen | 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_F
  • governingLens = barbell_policy_v2
  • currentTreatment = keep_frontier
  • changeTrigger = graduation_condition_v3 is satisfied for one retained line

or, for one narrower family region:

  • livePool = family_region_beta
  • governingLens = heterogeneity_first
  • currentTreatment = narrow_to_subset
  • changeTrigger = 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 widen when 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_frontier when several lines must remain live under the current lens and no narrower admissible subset is yet justified.
  • Close as narrow_to_subset when one declared lens now justifies retaining one smaller internal live set without pretending that one scalar winner has already been chosen.
  • Close as sunset_line when 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_line
  • changeTrigger = ...
  • 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 capabilityInstanceRef and its capabilityStatementRef; 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, and RelianceDisposition
  • competenceModelRef? = ... 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 either
  • goalSpaceExpansionPolicyRef? = ... only when one independently declared archive or curriculum expansion policy governs goal- or task-space growth
  • assuranceResultRef? = ... when graduation, scaling, or widening relies on one exact B.3 assurance result and its bounded supported scope
  • whyNotLocalChoice = ... when the result might otherwise be mistaken for C.11

An admissible short record may therefore read:

livePool = frontier_F
governingLens = barbell_policy_v2
currentTreatment = keep_frontier
changeTrigger = graduation_condition_v3 is satisfied for one retained line
whyNotLocalChoice = several family regions remain live

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:

livePool = frontier_F
governingLens = frontier_sweeper_v3
currentTreatment = keep_frontier
changeTrigger = one retained line satisfies graduation_condition_v3
whyNotLocalChoice = three family regions remain live

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:

livePool = diagnosis_task_regions_{alpha,beta}
governingLens = curriculum_expansion_policy_v3
currentTreatment = keep_frontier
changeTrigger = capability_statement_CS-44 gains an evidence-qualified transfer claim for region_beta
capabilityInstanceRef = diagnostic_agent_capability_v4
capabilityStatementRef = capability_statement_CS-44
a10RelianceRef = A10_CS-44_keep-frontier_W8
goalSpaceExpansionPolicyRef = curriculum_expansion_policy_v3
whyNotLocalChoice = both regions remain live; no individual task or probe is selected

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:

livePool = family_region_beta
governingLens = barbell_policy_v2
currentTreatment = sunset_line
changeTrigger = reopen only if new evidence or quota deficit reactivates the region
whyNotLocalChoice = other regions still remain live under the same pool policy

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:

livePool = retained_subset_{option_B, option_C}
governingLens = pool_policy_completed
currentTreatment = narrow_to_subset
changeTrigger = retained subset is explicit; pool policy is complete
nextQuestionPatternLocator = G.5 because selector-facing result declaration is now current
whyNotLocalChoice = pool governance is already complete

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.

PoolPolicyResult:
  livePool:
  governingLens:
  currentTreatment:
  changeTrigger:
  termBridgeRefs?:
  nextQuestionPatternLocator?:

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 in emitterPolicyRef?. If the active insertion policy is not inherited, record it in insertionPolicyRef?. If the deduplication threshold is not inherited, record scalar dedupThreshold? together with its deduplicationBasisRef? and deduplicationUnit?; 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.Q QS.UseValue objective 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 Surprise or Illumination into 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 δ_family threshold 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 PoolPolicyResult MUST identify livePool, governingLens, changeTrigger, and exactly one currentTreatment token from widen | keep_frontier | narrow_to_subset | sunset_line; lens and 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.19 MUST name the applicable pattern rather than restate it: C.11, C.24, G.5, E.17, or E.24.PUB.

  • C19-11 If goal- or task-space expansion, autotelic pressure, or capability-discovery support is used, the record MUST cite goalSpaceExpansionPolicyRef only 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; add a10RelianceRef only for an evidence-bearing or source-bearing claim on which the pool treatment actually relies; and use competenceModelRef only 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.18 as the pool-policy pass specifies. Any other next-result question uses the exact transfer in C.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 and changeTrigger names 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 currentTreatment token: widen, keep_frontier, narrow_to_subset, or sunset_line. If the current question is no longer pool policy, name the next subject pattern instead of inventing another pool treatment.
  • Letting Surprise or Illumination quietly 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.4 instead of adding a neighboring result's fields or claims to PoolPolicyResult.

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, and sunset_line as 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.

Source or source familyAdopted FPF moveRejected overreadPractitioner implication
Russo et al., A Tutorial on Thompson Sampling, arXiv:1707.02038v3 (2020-07-14).Treat explore/exploit balancing as an explicit sequential policy pressure rather than one hidden winner-selection aftereffect.Thompson sampling or any bandit algorithm becomes the default C.19 method.A pool-policy result names the policy or lens and the change trigger; local option choice still requires C.11.
Frazier, A Tutorial on Bayesian Optimization, arXiv:1807.02811v1 (2018-07-08), and Yu et al., Efficient and Principled Scientific Discovery through Bayesian Optimization: A Tutorial, arXiv:2604.01328v3 (2026-04-07).Keep acquisition, cost, uncertainty, and experiment-selection pressure visible when pool policy is used for expensive probing.Bayesian optimization vocabulary locally redefines FPF choice, work, or evidence kinds.Use BO-style source pressure to require policy ids, evidence/cost boundaries, and stop or change triggers, while comparison and enactment stay with their subject patterns.
Qin et al., A survey on Quality-Diversity optimization: Approaches, applications, and challenges, Swarm and Evolutionary Computation 100:102240 (2026), DOI 10.1016/j.swevo.2025.102240, https://www.sciencedirect.com/science/article/pii/S2210650225003979.Preserve live front, archive, coverage, and diversity pressure without collapsing them to one scalarized winner.QD taxonomy redefines the archive and front relations stated through C.18, redefines the G.5 selected-set result, or authorizes a default family quota, DPP sampler, or max-min rule.Keep keep_frontier, narrow_to_subset, and sunset_line distinct; use C.18 for archive and front meaning, G.5 for result declaration, and a profile admitted by the applicable policy for any heterogeneity rule.

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, and sunset_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 as S grows). 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)

  1. 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.
  2. The result says no scale claim yet, local analogy or policy, bounded scale comparison, or full Scale-Audit selected; it does not hide the choice of audit depth.
  3. A performed comparison uses parity, current editions, explicit uncertainty, material resource and safety accounts, and lawful Pareto or declared policy operations.
  4. 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.
  5. Non-dominance returns no empirical scale preference. Any generality tie-break is identified as a separately declared local policy.
  6. A waiver identifies the policy it overrides, rationale, admitted review System, direct responsibility relation or exact missing governor, and expiry or review window.
  7. A live Heuristic Debt entry meets the bounded BLP-4 trigger; ordinary local tactics create no debt record.
  8. Prescription architecture and adaptation policy are routed through their direct patterns rather than reported as consequences of BLP.
  9. An actual durable audit is exported to G.11; a bounded-use or no-claim exit is not padded into an audit artifact.
  10. 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, or Bitter Lesson is 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-4 trigger 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.29 stop 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

Source or source familyAdopted FPF moveRejected overreadPractitioner implication
Yousefi and Collins, Learning the Bitter Lesson: Empirical Evidence from 20 Years of CVPR Proceedings, arXiv:2410.09649, as current empirical pressure around Sutton's 2019 Bitter Lesson.Treat scale-amenable computational approaches in machine learning as a live empirical comparison pressure.The same empirical result automatically governs modules, organizations, work arrangements, epistemes, or every other bearer.For a computational claim, test the declared task family and scale window. For another bearer, label the move as local analogy or policy and provide its own scale predicate and evidence.
Kaplan et al., Scaling Laws for Neural Language Models, arXiv:2001.08361, and Hoffmann et al., Training Compute-Optimal Large Language Models, arXiv:2203.15556.Keep compute, data, model size, budget, and scale-window relations explicit when a bearer is claimed to improve with scale.Parameter count, compute spend, or one benchmark substitutes for the audited objective vector.State the swept dimensions, alpha and delta tolerances, CI, and budget window before preferring the general bearer.
Lu et al., The Bitter Lesson of Diffusion Language Models for Agentic Workflows: A Comprehensive Reality Check, arXiv:2601.12979.Treat current agentic-substrate claims as evaluation-sensitive and task-family-sensitive, especially when efficiency hype competes with reliability."More agentic" or "more efficient backbone" proves better workflow performance.Keep agent-loop or substrate selection under E.23, G.9, and C.19.1 with task-family evaluation, protected trade-offs, and stop/switch conditions.

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

ForceTension
Early value vs richer assuranceA useful result should arrive before exhaustive configuration, but higher consequence may justify deeper setup.
One current path vs live alternativesInventing rivals creates bureaucracy; ignoring genuine alternatives can lock in avoidable cost or loss.
Local economy vs reuseOne-off work favors a small path; repeated work can amortize configuration and improve transfer.
Direct kinds vs shared comparisonUnlike candidates must retain their kinds while being compared against one declared use and guarantee.
Method guidance vs actual workA practitioner can use a U.MethodDescription episteme as guidance; that episteme cannot configure or apply itself.

Solution

Keep the five positions separate

Use this minimal lens before taking a branch:

  1. Declared use: the practical question, direct result kind, claimed guarantee, non-negotiable constraints, and horizon.
  2. Selected or candidate direct-kind object: the method description, model, ontology module, formal technique, or other governed object being considered.
  3. Application MethodDescription: this pattern's U.MethodDescription episteme and the admitted U.Method it describes. A practitioner uses its claims to guide the Work; neither the episteme nor the Method performs it.
  4. Performer and work: when an admitted U.System performs dated configuration or application U.Work using 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.
  5. 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 now names one selected option or an honestly retained tie-set;
  • reject current set returns to a named candidate-generation pattern or closes with no current application;
  • probe again retains one probe and its epistemic budget because it can still change the choice;
  • reroute names 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

  1. State the practical use, direct result kind, claimed guarantee, constraints, horizon, and current apparatus state.
  2. If one apparatus is already selected, test its credible adaptation path without inventing choice. If candidates are missing, use C.18 first.
  3. Name available alternatives by their direct kinds and apply the shared eligibility predicate.
  4. 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.
  5. 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.
  6. If choice is current, consume one lawful C.11 ChoiceResult; otherwise continue on the one-apparatus path.
  7. Prepare the needed A.15.2 plan or, for tool-call enactment, C.24 call plan. Have the admitted system perform A.15.1 work.
  8. 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

IDCheck
CC-C19.2-1The declared use names a direct result kind, guarantee, constraints, and horizon.
CC-C19.2-2A current single-apparatus case proceeds without a fabricated OptionSet or ChoiceResult.
CC-C19.2-3Candidate generation, local choice, planning, tool-call planning, dated work, and direct result retain their subject patterns.
CC-C19.2-4Every candidate retains its direct kind and satisfies one explicit eligibility predicate for the same use and guarantee.
CC-C19.2-5Any C.11 result is exactly choose now, reject current set, probe again, or reroute.
CC-C19.2-6The intended-reader position, U.MethodDescription episteme, described U.Method, admitted performing U.System, dated U.Work, and problem-facing result remain distinct. Every precise performer has an A.13 core, and the Work is independently admitted under A.15.1. F.6 is required only when the receiving use also needs precise assignment-bound attribution. A short projection exposes assignment identity, species, participants, or attribution detail only when that use relies on them, attribution is ambiguous, or source wording must be repaired.
CC-C19.2-7The first useful result and stop are practical, and every reopen condition changes a named next action.
CC-C19.2-8No generic apparatus U-kind, hidden scalar, or unadmitted CGUS is introduced.

Common Anti-Patterns and How to Avoid Them

Anti-patternRepair
Configure everything because the basis is rich.Name the useful-result threshold and retain only setup work with expected return.
Invent a rival to make the method look comparative.Use the one-apparatus path until candidate or choice work is genuinely current.
Call candidate generation a choice.Use C.18 for generation/reframing; let C.11 operate only on an existing eligible set.
Treat ChoiceResult as a plan or result.Keep selected object, plan, dated work, application note, and domain result separate.
Let a U.MethodDescription episteme, its described Method, a plan, option row, publication, or reader position perform Work.State in ordinary language that an admitted System performs dated Work using the Method. Recover its A.13 core and independently admit the Work under A.15.1; add F.6 only when the present use needs precise assignment-bound attribution. Expand assignment and attribution detail only when that use needs it, attribution is ambiguous, or the source wording must be repaired.
Rank heterogeneous candidates under one hidden “depth” score.Preserve direct kinds and compare only declared use-bearing dimensions without hidden scalarization.

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

Practice questionCurrent practice and sourceFPF alignmentDisposition
How much reasoning effort repays its cost?Resource-rational analysis ties computation to action value under bounded resources (Lieder & Griffiths 2020, with Russell & Wefald 1991 as lineage).The useful-result threshold and non-dominated next move govern setup and application work. The repeated-handoff and one-off cases show the practical difference.Adapt. FPF retains multiple separately defined dimensions rather than one universal value-of-computation scalar.
Should ontology/formality be complete before use?Demand-driven incremental formalization starts from useful work and deepens when use repays it (Shipman & McCall 1999, still current as the named HCI/knowledge-base precursor).The one-apparatus path allows value before total configuration, with reopen on recurrence, failure, automation, or stronger guarantee.Adopt as continuing lineage. No HOS tool or single formality ladder is imported.
Do different questions warrant different apparatus and outputs?Current competency-question work distinguishes purposes and expected products rather than imposing one ontology checklist (Keet & Khan 2024).Eligibility is tied to one declared use/result/guarantee; the pattern does not universalize one method or checklist.Adapt. Question differentiation changes candidate eligibility and return.
How should concern and purpose constrain a model or architecture description?ISO/IEC/IEEE 42010:2022 keeps concerns, stakeholders, viewpoints, and architecture descriptions explicit without prescribing one tool.Declared use, guarantee, and direct result keep apparatus application purpose-bound while subject patterns retain their kinds.Adapt. Use the purpose/concern discipline without importing architecture-description ontology into every apparatus.

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.18 for candidate generation and reframing; C.19 for candidate/front stewardship; C.19.1 for scale-amenable bearer preference; C.22.1 for adaptation signatures; E.23 for repeated improvement; and C.31.ASAP for architecture-scale preference.
  • Uses conditionally: C.11 only when an actual local-choice question over a live eligible set exists. It consumes, but does not extend, the four ChoiceResult dispositions.
  • Hands off enactment to: A.15.2 for work plans, A.15.1 for dated work, and C.24 only for tool-call enactment planning. The direct domain pattern contains the defining content for the practical result.
  • Description-level specialization: A.7.1 narrows 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 neither U.SubkindOf nor a world relation.
  • Does not replace: durable U-kind admission in E.24/E.24.UK, parsimony in A.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

ForceTension
Pluralism vs cohesionRival claims and practices can remain visible while the exact assembly must still sustain one field-level whole.
Continuity vs genuine reidentificationParts and relations can change while the same discipline continues, but a name must not hide a changed assembly or boundary.
Readable minimum vs constructive assuranceOrdinary work needs a short part-and-assembly account; reliance-bearing work may need a C.13 trace, evidence, currentness, and assurance.
Local meaning vs cross-field reuseA practice or term can be reused through an exact bridge without the bridge becoming a discipline part or merging its endpoints.
Rigor vs agilityExact parts and identity are required, while comparison, publication, health, and registry apparatus are added only for a named receiving use.
Didactic presentation vs ontologyA discipline card can aid reading but none of its rows, columns, or empty positions makes a world-side relation obtain.

Solution - recover the whole from direct construction

Run the complete recognition test

Recover six constructive components for the same exact candidate:

  1. Exact candidate. Identify one exact U.Entity and its proposed field boundary. A public name or description is only a designator or episteme about that candidate.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Apparent discipline contentSubject pattern and C.20 boundary
field or domain namecatalogue, designation, or wording pattern; the name is not the candidate or its construction
theory, model, canon item, definition, standard, or practice descriptionC.2.1 identifies the exact episteme; it becomes a discipline part only if a separate disciplinePartOf occurrence obtains
reusable method or method familyA.3.1 identifies each Method and B.1.5 any composite Method; use, registry membership, or family similarity is not discipline parthood
organization, laboratory, committee, journal operator, or professional bodyA.1 identifies any system; its system-role assignments and Work stay direct; carrying or stewarding a discipline is not parthood
dated research, engineering, teaching, revision, evaluation, or governance workA.15.1 identifies each Work occurrence; performing work about or within a discipline does not make the work or performer a part
selected organization of relations for one model useA.22 identifies the dependent U.Structure; selection gives it no holonhood or discipline parthood
sense or structure bridgeF.9 identifies the exact Bridge occurrence and endpoints; crossing, translation, congruence, or loss does not join the endpoint disciplines into one whole
comparison predicate, characteristic space, comparator, or aggregationuse C.16 for the measured values and A.19.CPM for the exact comparison; comparability is not a discipline constituent or identity condition unless a separate C.20 whole-forming claim makes an exact contribution current
publication, form, carrier, card, dashboard, registry, or bibliographyC.2.1, E.17, and E.24.PUB keep content, form, carrier, and availability separate; publication does not construct the field
evidence, provenance, currentness, assurance, gate, or authorizationuse A.10 for evidence and provenance, G.11 for currentness, B.3 for assurance, A.21 for gates, and the applicable decision pattern for authorization or choice claims; epistemic support changes no world-side part or identity fact

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.

Reader functionSystem-side safety sceneEpisteme-side discipline sceneC.20 boundary
Exact objectOne production line with hazardous operations is an exact U.System under A.1; its work and state remain separate.One exact canon or discipline-description U.Episteme states accident-model and tolerable-risk claims about its declared EntityOfConcern under its effective ReferenceScheme. The SafetyEngineering-SE field candidate remains another entity.Neither the system nor one episteme is the discipline; identify the field candidate and test its construction independently.
Concept contributionAcceptance clauses and evaluation templates bound to exact rigs and windows are epistemes used by the plant system and its Work, not concepts owned by the system.Canon content can include causality models, design rules, proofs, benchmarks, formal knowledge bases, proof carriers, and concept schemas under their direct episteme, form, or representation patterns.Ask which exact claim-bearing contribution is constitutive and which whole-forming claim connects it; conceptual relevance alone creates no part.
Symbolic representationLocal SOP and checklist notation can express plant procedures for one bounded use.CLIF, RDF/TriG, proof scripts, diagrams, and other notation packages can express or represent canon content.E.17/E.24.PUB and C.29 govern form, carrier, publication, and representation; symbolic appearance identifies none of System, Episteme, or Discipline.
Assembly contrastA line-specific standard, plant procedures, and a certifying unit are exact epistemes, Methods, systems, system-role kinds or assignments, or Work inputs around a possible Safety-Plant-A field candidate.Canon papers, formal models, a journal or committee, and system-safety or resilience-engineering tradition claims are likewise separately governed around SafetyEngineering-SE.A list or historical Gamma_disc fold constructs neither candidate. For either scene, recover exact parts, obtaining disciplinePartOf occurrences, whole-forming couplings, assembly, reidentification, whole characteristic, and larger-assembly compatibility.
Evidence-lane contrastLA test campaigns with freshness windows, VA design proofs, and TA tool qualifications can support exact plant-side claims.VA proofs over kinds, LA replications or meta-analyses, and TA evidence for checkers can support exact canon or construction claims.A.10 keeps the exact source, currentness, and reliance needed by the use. When an actual named assurance claim is current, B.3 adds only the characteristics and result fields that its argument consumes. Evidence changes no System, Episteme, or Discipline identity and creates no part relation.

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-v5 supplies the hazard, causal, and acceptable-argument meanings used by the two Methods;
  • HazardAnalysisMethod-v4 supplies the reusable analysis practice by which those meanings constrain identification and treatment of hazards;
  • IncidentLearningMethod-v2 supplies 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.

LensQuestion and counter-bias
GovernanceAre field names, classification claims, revision rationales, source “steward” or “owner” wording, any separately obtaining kind or assignment, responsibility, authority, ownership, governance, publication Work, and publication availability kept with their subject patterns, or has a name, card, registry, title, or publisher acquired force it does not have?
ArchitectureAre construction, Characteristic/Scale, comparison or aggregation, evidence/assurance, health, publication, and selection still separate branches, or has a convenient CAL/CHR-style record become an omnibus discipline constructor?
Onto/EpistAre the discipline, domain designation, semantic locality, system, episteme, description, representation, and evidence claim distinct, with each claim returning to an exact EntityOfConcern and ReferenceScheme?
PragmaticCan ordinary authoring and edition work stop at exact parts, couplings, assembly, and reidentification, while only the receiving comparison, assurance, publication, or decision opens deeper apparatus?
DidacticDo twin labels, the System/Episteme contrast, cards, columns, diagrams, and examples aid recognition without supplying hidden parts, relations, kinds, identity, or truth?

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.

Bias riskFailureCounter-move
Label realismA familiar field name is treated as the whole.Recover candidate, parts, direct occurrences, assembly, identity, and whole characteristic.
InstitutionalismThe largest organization carrying the work is treated as the discipline.Keep the system, system-role kind and assignment, and Work direct; test parthood separately.
Canon or method monocentrismOne document set or method family stands for both knowledge and practice.Require independently identified contributions on both sides and exact coupling claims.
Schema completionFive filled positions or heterogeneous fields manufacture construction.Use the two-participant direct relation and ordinary whole-forming claims; treat cards as descriptions.
Bridge universalismTranslation or high congruence merges fields.Keep Bridge, bounded-use proposition, reliance, comparison, and discipline construction separate.
Metric reificationHealth or maturity value is treated as discipline identity.Keep C.21 readings and G.4 thresholds as evaluations over the exact discipline.
Snapshot extensionalismAny changed part creates another discipline, or the same part list guarantees sameness.Apply the assembly-sensitive reidentification rule.

Conformance Checklist

IDPassing condition
CC-C20-1One exact candidate U.Entity and proposed field boundary are named before U.Discipline recognition.
CC-C20-2Every claimed part is independently identified under its subject pattern; at least one exact knowledge-bearing contribution and one exact reusable-practice contribution are current.
CC-C20-3Every disciplinePartOf occurrence passes the required-or-currently-realized-alternative predicate and is identified by exact participants plus maximal continuous obtaining interval.
CC-C20-4Contribution claims and other whole-forming facts are stated in ordinary domain language and retain their direct predicate, local-claim, or reusable-definition disposition.
CC-C20-5The assembly names exact parts, relations, required contributions, alternatives, incompatibilities, boundary, stop conditions, and substitution conditions. A card or trace is not its cause.
CC-C20-6The direct reidentification rule says which part, relation, coupling, boundary, and characteristic changes preserve or end the whole.
CC-C20-7At least one exact A.17 Characteristic is composition-grounded and not reducible to one constituent, count, label, or external health score; A.18 governs its Scale and C.16 opens only for an actual measurement.
CC-C20-8Candidate-side interfaces and identity-preservation conditions fit at least one governed possible larger field assembly; an actual larger-discipline part claim still needs its own obtaining occurrence.
CC-C20-9Domain names, epistemes, Methods, systems, Work, structures, Bridges, comparisons, publications, evidence, and decisions remain with subject patterns unless the separate C.20 part predicate actually obtains.
CC-C20-10Any selected bounded-model-use structure is optional, independently identified, tied to one named receiving use, and creates no part, holon, subkind, viewpoint count, breadth, or identity.
CC-C20-11Applied, multidisciplinary, transdisciplinary, tradition, lineage, and school claims state their own criteria; no public U-kind or discipline part follows from wording or counts.
CC-C20-12Any cross-field use separates the F.9 Bridge, bounded-use proposition, direction/rule/tolerance/polarity, A.10 or B.3 reliance branch, observed loss, and actual comparison.
CC-C20-13Comparison declares characteristic, scale, unit, polarity, comparator, scope, window, and admissible operation under C.16/A.19.CPM; C.20 performs no comparison and defines no reliability fold.
CC-C20-14A health value, state label, evidence profile, registry row, description edition, publication occurrence, form, or carrier changes no discipline construction fact by itself.
CC-C20-15Any C.13 trace names the already grounded candidate, exact parts, direct occurrences, assembly, identity rule, and whole characteristic; Gamma_m.sum or historical Gamma_disc syntax creates none of them.
CC-C20-16Core prose and labels follow E.10 and remain notation- and tool-neutral; a didactic discipline column carries no hidden semantics.

Common Anti-Patterns and How to Avoid Them

Anti-patternRepair
"TDD discipline" or another Method/tradition label already names a discipline.Treat "Test-Driven" as a tradition, method-family, or other local classification only under its exact criterion and subject. Identify each Method under A.3.1; identify a discipline only by the complete C.20 construction test.
“Safety Discipline Owner” or another owner or steward title proves ownership, parthood, responsibility, or decision authority.Treat the title as an E.10.ROLE trigger. Admit the System that actually performs any Work; recover any local system-role kind, classification, or assignment independently; and cite the exact ownership, responsibility, authority, governance, or other direct relation that obtains. If no pattern establishes the stronger relation, return missing-governor.
"ClinicalSafetyDomain Governance" or another compound domain-governance label supplies a discipline and its comparison policy.Separate the subject-area or catalogue label, exact governance system-role kind and assignment, direct governance rule, Work, any independently constructed C.20 discipline, and the A.19.CPM/G.0 comparison declaration. The compound label creates none of those objects or facts.
"The five card positions are filled, so the discipline exists."Recover the exact candidate, direct part occurrences, whole-forming claims, assembly, reidentification, characteristic, and larger-assembly compatibility.
"The department is the discipline."Keep the organization as an exact system and its activity as Work; establish any discipline part relation independently.
"Every canonical paper and standard is a discipline part."Identify each episteme and apply the C.20 predicate; citation, canonical status, or publication is insufficient.
"Every method used in the field is a part."Identify the Method under A.3.1 and test whether the current assembly makes its contribution constitutive; registry membership and use alone are insufficient.
"The Bridge set assembles a transdiscipline."Keep each Bridge and bounded-use proposition direct; apply a declared breadth criterion or rerun the full construction test for a new candidate.
"The selected model-use structure is the discipline context."Keep the optional A.22 Structure attached only to the named use; it is neither whole nor part by selection.
"Three viewpoints make the field multidisciplinary."State a project-local breadth predicate over exact disciplines and contributions; viewpoint or structure count proves nothing.
"The journal, card, or dashboard carries the discipline."Separate discipline, description episteme, publication occurrence, form, carrier, and health reading.
"A maturity drop created a new discipline edition."Keep the C.21 result separate and apply the C.20 reidentification rule to actual construction changes.
"A later canon edition is the later discipline."Apply C.2.1 to the canon and C.20 to the field; historical continuation and discipline continuity are separate claims.

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

Current source or practice lineC.20 adoptionBoundary of non-overread
Constructional-ontology work cited in A.1 and C.13 requires explicit constituents, constructive relations, assembly, dependence, and identity choices rather than an extensional list.Require exact part occurrences, whole-forming claims, an assembly-sensitive reidentification rule, and one composition-grounded whole characteristic.A graph, card, constructor expression, shared label, or input set creates neither whole nor relation.
Current science-of-science and reproducibility practice cited in C.21 treats field health as several typed, scoped, time-qualified characteristics.Let C.21 evaluate exact disciplines without importing health coordinates into construction.Reproducibility, standardization, disruption, diversity, or evidence granularity is not discipline identity or truth by itself.
Current model, workflow, and publication practice separates semantic ways of doing, claim-bearing descriptions, actual work, results, and publication availability.Keep Methods, epistemes, Work, results, and publication occurrences independently governed even when their exact relations support a field assembly claim.Use, representation, occurrence, evidence, or publication does not make an entity a discipline part.
Plural-field and translation practice needs explicit local meanings, direction, substitution conditions, and visible loss.Use the exact F.9 Bridge plus a separate bounded-use proposition and direct reliance or comparison branch when crossing is current.A Bridge count or high congruence neither merges disciplines nor creates a transdisciplinary kind.

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:

  1. Object collapse. A definition set, Method, MethodDescription, measurement Work, result episteme, series episteme, publication occurrence, form, and carrier are called one “DHC artefact.”
  2. Scope slippage. ClaimScope and a selected TargetSlice are treated as interchangeable, although the scope states where the claim holds and the slice is only an optional computation or publication input.
  3. 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.
  4. 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.
  5. 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

ForceTension
Comparability vs nuanceA wider field picture is useful, but exact definitions, populations, windows, schemes, and local meanings must survive.
Readable minimum vs replayOne ordinary claim should be cheap; a numerical comparison or reusable series needs enough identity to be repeated.
Ordinal vs interval or ratioRanks and categories invite illegal arithmetic.
Formal status vs actual adoptionApproval by a standards body and use by a population can vary independently.
Direct comparison vs cross-local relationCompatible readings compare directly; distinct local senses add a directional relation and its loss.
Recency vs stabilityHealth changes through time; a trend needs explicit windows and current definition editions.
Evidence vs publicationSupport, measurement, series content, dashboard representation, and audience availability answer different questions.

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.

ObjectWhat it isWhat it is not
DHC Characteristic and Scale declarationsExact A.17 Characteristic and A.18 Scale definitions, with Unit and polarity when applicable.A dashboard field or a health verdict.
DHCDefinitionSet when a reusable selection is neededOne C.2.1 episteme about the already identified discipline. Its ClaimGraph states the intended use and selects exact Characteristic, Scale, Unit, and measurement-definition editions.A slot-set kind, the discipline, or a publication. Ordinary one-coordinate use needs no such episteme.
DHCMethodRef.editionThe existing C.16 measurement-definition value for one Characteristic and Scale. It resolves the exact U.Method, any U.MethodDescription edition, model, calibration basis, uncertainty treatment, construction, and time or population policy used by the reading.The Method, MethodDescription, measurement Work, or result.
DHC coordinate resultA C.16 measurement result and, when persisted as a claim, one C.2.1 result episteme about the discipline.A time-series publication, dashboard row, or acceptance decision.
DHCSeries when repeated use needs oneOne C.2.1 episteme whose EntityOfConcern is the discipline and whose ClaimGraph orders exact coordinate-result episteme refs by window under one intended use, ClaimScope, comparison basis, and definition basis. Content change creates another episteme edition under the applicable edition rule.A publication occurrence, form, carrier, table, or the Work that assembled it.
dashboard row or sliceA C.29 or G.12 representation over exact result or series refs.The result, evidence, series episteme, publication, or discipline.
publication occurrenceAn obtaining E.24.PUB availability relation among one selected episteme edition, audience declaration, bounded-use declaration, form, carrier, and availability interval.Rendering, upload, release, measurement, or series-assembly Work.

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.edition resolves 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.edition appears only when a named reusable definition selection exists.
  • TargetSliceRef appears 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 authoritative ClaimScope; the slice never substitutes for that scope.
  • DistanceDefRef.edition appears 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.

  1. ReproducibilityRate — ratio in [0,1]; Unit replicated_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.

  2. 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 general de facto < de jure ladder and no default health polarity.

  3. PracticeAdoptionRate — ratio in [0,1]; Unit adopting_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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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 - HHI may 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.

  1. 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.

  2. 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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

  1. State the ordinary health question and smallest useful conclusion.
  2. Identify the discipline under C.20 and one exact Characteristic and Scale.
  3. State ClaimScope, comparison or observation basis, and time or population basis.
  4. Stop if an ordinary typed claim is enough.
  5. If measuring, comparing, or aggregating, recover the C.16 chain and DHC replay basis; add only the exact legal-operation and crossing branches used.
  6. If repeated windows matter, construct a series episteme from exact result refs.
  7. If a dashboard matters, represent those results under G.12.
  8. 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

CheckPassing condition
CC-C.21-1The discipline, intended use, one exact Characteristic, Scale, ClaimScope, comparison or observation basis, and time stance are recoverable.
CC-C.21-2ClaimScope is authoritative. A TargetSliceRef appears only when consumed and its exact relation to the scope is stated.
CC-C.21-3A minimal readable claim may stop without a definition set, EvidenceGraph, registry, dashboard, or publication apparatus.
CC-C.21-4Every persisted, compared, aggregated, or published coordinate carries the active DHC replay basis; no generic “metric edition” substitutes for an exact object.
CC-C.21-5Characteristic, Scale, Unit, polarity or target rule, and legal operations are coherent. Ordinals are not averaged and Units are not mixed.
CC-C.21-6Direct comparison uses C.16's compatible-semantics branch. F.9 is required only for actual distinct-local-sense use and then carries direction, admitted use, and loss.
CC-C.21-7Formal recognition and actual adoption or convergence are separate Characteristics; neither rank proves health or SoTA.
CC-C.21-8EvidenceUnitResolution, ClaimsPerArtifact, and SupportAnchorsPerClaim are separate; their constructions and Units are not interchanged.
CC-C.21-9Entropy and concentration are separate, with opposite directions explicit; any transformation and receiving Scale are declared.
CC-C.21-10Measurement definition, exact Method, MethodDescription, model, calibration, Work, result, result episteme, series episteme, dashboard representation, publication occurrence, form, and carrier remain distinct where present.
CC-C.21-11Freshness, evidence reliance, assurance, acceptance, public naming, and refresh machinery appear only when a named receiver consumes them.
CC-C.21-12Unknown inputs remain unknown under the receiving method; missing inputs are not coerced to zero or to a health verdict.
CC-C.21-13Engineering-grade extension readings cite the direct pattern and rule and do not become evidence, assurance, gate, release, Work, or project authority.

Common Anti-Patterns and How to Avoid Them

  • Treating discipline health as one scalar before separately typed coordinates exist.
  • Treating ClaimScope and TargetSlice as 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/artifact and anchors/claim alternative 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

SoTA or practice anchorContribution used hereNon-overread
Open Science Collaboration (2015), Munafò et al. (2017), and current reproducibility and metascience practiceReproducibility, claim resolution, support visibility, freshness, and population definition remain separate coordinates and bases.A field-level rate does not certify one claim as true.
Fortunato et al. (2018) and Wu, Wang, and Evans (2019) disruption-index workDisruption and consolidation are read through a declared corpus, method edition, and target band rather than a monotone novelty target.Disruption is not quality, truth, safety, or usefulness by itself.
Standards lifecycle and ecosystem-adoption practiceFormal recognition and observed adoption are separate.Official status, popularity, and convergence do not prove one another or SoTA.
Plural-tradition and relation-mapping practiceAlignmentDensity counts exact obtaining directed relations with visible loss.A relation count is not universal language, consensus, or authority.
Diversity measurement practiceEntropy and concentration retain their separate constructions and directions.Similar labels do not make their Scales interchangeable.

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

Minimal DHC claim
  Discipline: <exact discipline>
  Intended use: <question or action>
  ClaimScope: <where the claim holds>
  Characteristic and Scale: <exact definitions>
  Comparison or observation basis: <population/corpus/cohort/window>
  Ordinary result: <what is supported; what is not>

Only if measurement, comparison, or aggregation is current
  DHC replay basis: <active exact refs and editions from C.21:4.0a>
  TargetSlice: <optional; only if consumed, with relation to ClaimScope>
  Comparison branch: <direct compatible semantics | exact F.9 relation + direction/use/loss>
  Legal operation or target-distance rule: <exact ref>

Only if a reusable series, dashboard, or publication is current
  Series episteme: <exact coordinate-result refs and windows>
  Dashboard representation: <optional G.12 row/slice refs>
  Publication: <optional E.24.PUB relation, audience, bounded use, form, carrier, interval>

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

  • TaskSignature assignment means one obtaining TaskSignatureAssignmentRelation among 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.6 U.ClaimScope value used by this declaration; it is not an evidence-path slice, baseline-set slice, container, or assignment participant.
  • threshold is not one undifferentiated family here:
    • articulation and closure thresholds stay with cue or prompt subject patterns such as B.4.1 and B.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.

Name and kind map for code-shaped heads. The names below identify different structural positions; capitalization does not make them peer kinds.

Head used in this patternRecoverable kind or positionDirect governance boundary
TaskSignatureC.2.1 episteme and species of U.Signature; this pattern's primary EntityOfConcernC.22 governs its A.6.0 direct fields, Vocabulary, Laws, and Applicability; C.2.1 governs constitution; E.17 governs publications and carriers.
ProblemSideEpistemeRef and ReceivingUseEpistemeRefParticipant designations in an assertion or description of TaskSignatureAssignmentRelation, not content or identity positions of TaskSignatureC.22.2 or the direct problem-side pattern defines or constrains the first episteme; the receiving-use episteme states the use but does not prove that an assignment obtains.
TaskKindTaskSignature position filled by one exact C.3 U.Kind value that types the current task or work targetC.3 governs the kind value; the field does not mint U.Task.
TaskFamilyRefOptional reference position for the comparison-relevant task familyC.22 and C.22.1 govern task-family anchoring; the reference is not the family or a selected method.
ProblemProfileC.2.1-conformant U.Episteme that describes the stabilized problem and may reference the TaskSignature assignmentIt is not the actual Problem, TaskSignature, assignment relation, method, plan, or Work occurrence.
ScopeSlice(G)Local position whose filler is the exact A.2.6 U.ClaimScope value that bounds claims about the exact EntityOfConcernRefA.2.6 governs membership; the position is not an E.18 path slice or a new slice kind.
CHR field heads in 5.1TaskSignature positions filled by characteristics, scales, units, polarity values, scope values, evidence relations, and currentness conditionsC.16 and each subject-pattern locator identify the exact definitions and constraints for the fillers; C.22 states why the selector-facing use needs them.
QD and OEE extension heads in 5.1Optional TaskSignature positions filled by exact characteristic-space, archive, policy, telemetry, generator-family, validity-region, and transfer-rule values or referencesC.18, C.19, G.5, G.11, and the named direct patterns keep authority over those fillers. ArchiveConfig, TelemetryHooks, and GeneratorIntent do not become root kinds here.

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

ForceTension
Parsimony vs sufficiencyFewer fields to avoid ceremony vs enough to drive admissible gating.
UnknownsMany traits are unknown in the initial problem record → tri-state semantics propagate to Acceptance without silent coercions.
CHR admissibilityNo mean on ordinals; no unit mixing; aggregation is admissible only after polarity and scale type are declared.
Locality vs portabilityThe declaration is use-bounded. Cross-semantic reuse first resolves two exact local senses and tests whether an F.9 Bridge obtains; the proposed use and any evidence reliance or assurance remain separate claims.

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:

  1. Confirm that the problem-side representation is stable enough for selector-facing use; otherwise use C.22.2.
  2. Name the receiving eligibility, acceptance, or selection question and the TaskKind, optional task family, or work target that the signature will declare.
  3. Include only the problem traits whose values can change that receiving use. Leave a non-current optional extension absent.
  4. Type each live characteristic by scale, unit, polarity, reference plane, and admitted comparison relation before aggregation or comparison.
  5. 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.
  6. Close with one minimal TaskSignature. Pass later eligibility and acceptance claims to C.23 and G.4, and actual method-family selection to G.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:

  1. 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.
  2. Reliance-bearing use. Add an addressable ProblemProfile episteme 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.
  3. 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). Include ConditionClass such as stiffness or kappa proxies where applicable.
  • Constraints — explicit hard and soft constraint classes (feasibility predicates; ResourceEnvelope and RiskEnvelope). Acceptance-gate thresholds live in G.4 only; never inside CHR or code paths.
  • ShiftClass and 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.6 U.ClaimScope value that bounds this declaration's claims about EntityOfConcernRef (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.
  • MissingnessMCAR, MAR, or MNAR (or mapped equivalents) per CHR.Missingness; Acceptance and flow use preserve the declared missingness semantics.
  • KindSet — selected C.3 U.Kind values 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 to U.CharacteristicSpace, with declared d≥2; characteristics are CHR‑typed; ReferencePlane per characteristic; pin edition via CharacteristicSpaceRef.edition.
  • ArchiveConfig — archive topology (grid, CVT, or graph), resolution (bins or centroids), K‑capacity, InsertionPolicyRef (elite replacement, dedup, or novelty), and DistanceDefRef.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 authorises ParetoPlusIllumination, policy‑id cited).
  • IlluminationSummary — a telemetry summary over Diversity_P; reported by default; excluded from dominance unless a CAL enables ParetoPlusIllumination (policy‑id cited).
  • IlluminationMap (parity-run) — parity-run publication is complete when an IlluminationMap publication (grid, CVT, or graph per ArchiveConfig) records coverage per niche or cell with DescriptorMapRef and DistanceDefRef.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).
  • TelemetryHooksPathSliceId only 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 registered GeneratorFamily (G.5), with pointers to EnvironmentValidityRegion, 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.

TaskSignature <: U.Signature

EntityOfConcernRef = exact task or work target declared for the named receiving use
effectiveReferenceScheme = exact scheme in which TaskKind, TaskFamilyRef?, KindSet, and characteristic values are interpreted
SubjectKind = TaskKind, one exact C.3 U.Kind value
RangedValueKind = U.Entity
SliceSet = declared A.2.6 claim-scope slices
ExtentRule = entities admitted by KindSet inside those slices
ResultKind = absent; selector outcomes are not TaskSignature values

Vocabulary:
  TaskFamilyRef?
  KindSet
  characteristic bindings with Scale, Unit, Polarity, ReferencePlane, admitted comparison relation, and value or admitted unknown
  constraint relation references
  evidence-use relation references only when the receiving use relies on them
  optional QD, OEE, archive, generator, parity, budget, telemetry, and specialization vocabulary only when current

Laws:
  include only positions that can change eligibility, acceptance, or selection for the declared use
  preserve admitted unknown and distinguish it from absent non-current vocabulary
  apply CHR scale, unit, polarity, ReferencePlane, and comparison legality before aggregation
  keep acceptance verdicts, selector outcomes, selected methods, plans, Work, and performed results outside the signature
  keep each reliance-bearing field connected to its exact basis relation and subject pattern

Applicability:
  exact U.ClaimScope and any required A.2.6 membership
  declared qualification or use window when current
  qualification, freshness, edition, and evidence-use conditions on which use relies
  exact F.17 local senses, an obtaining F.9 Bridge, and a separate bounded-use claim only when cross-semantic reuse is current

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:

TaskSignatureAssignmentRelation <: U.Relation
  ProblemSideEpistemeSlot = <ProblemSideEpistemeSlot, U.Episteme, U.EpistemeRef>
  TaskSignatureSlot = <TaskSignatureSlot, U.Signature, U.EntityRef constrained to TaskSignature>
  ReceivingUseEpistemeSlot = <ReceivingUseEpistemeSlot, U.Episteme, U.EpistemeRef>

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:

  1. The TaskSignature exposes its exact EntityOfConcernRef, effective U.ReferenceScheme, direct declaration fields, Vocabulary, Laws, and Applicability.
  2. The assignment relation recovers its exact problem-side episteme, exact TaskSignature, exact receiving-use episteme, obtaining conditions, and occurrence extent.
  3. Every live field has an admitted filler kind or scale discipline and, under reliance, an exact basis relation with a subject pattern.
  4. A live but unrecovered value is unknown only where the field's exact value rule permits it and a downstream policy states how the named use handles it.
  5. A non-current optional extension is absent; absence and unknown are not interchangeable.
  6. 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 (per ArchiveConfig) in addition to or instead of a Pareto set. Illumination enters dominance only if DominanceRegime=ParetoPlusIllumination is enabled by CAL (policy id cited); otherwise, QD telemetry values are reported but excluded from dominance.
  • When GeneratorIntent is present, G.5-governed selection may use a registered GeneratorFamily (POET‑class); the selection domain becomes pairs {environment, method}, with Environment guarded by EnvironmentValidityRegion and TransferRulesRef (C.23 wiring). Report IlluminationSummary as a telemetry summary over Diversity_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 remake when 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 durable Strategy U-kind is introduced.
  • Transdiscipline vs domain. Comparability uses the exact ReferenceScheme, ClaimScope, characteristic meanings, and U.Discipline relation 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)

  1. Minimal A.6.0 declaration. TaskSignature exposes exact EntityOfConcernRef, effective U.ReferenceScheme, SubjectKind, RangedValueKind, optional ResultKind, SliceSet, and ExtentRule, plus Vocabulary, Laws, and Applicability. Add SignatureManifest only when dependency replay needs actual imports and provided names; it does not supply signature identity.

  2. Signature and assignment present. Every exported selector-facing case names one TaskSignature identity and edition plus one TaskSignatureAssignmentRelation whose 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 preserves unknown, 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.

  3. 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.

  4. 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.

  5. 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.

  6. Cross-semantic use is separated. Declare ReferencePlane for 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.

  7. Acceptance thresholds live in CAL. No acceptance-gate thresholds in CHR or code paths; only in G.4 AcceptanceClauses.

  8. 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.5 governs any Pareto-set result when its admissible relation remains partial.

  9. 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.

  10. 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.

  11. Structure and gates are conditional. Apply E.18 crossing checks only when a selected transformation-flow structure and exact GateCrossing are 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.

  12. QD fields (when QD is in scope). A TaskSignature with PortfolioMode=Archive or 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.

  13. DominanceRegime default. DominanceRegime defaults to ParetoOnly. Illumination enters dominance only through a cited CAL.Acceptance policy enabling that relation; the SCR records the policy id.

  14. 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.

  15. GeneratorIntent (when OEE is in scope). A TaskSignature supports the claimed OEE generator-family use only when GeneratorIntent cites EnvironmentValidityRegion and TransferRulesRef with ids resolvable in G.5 and C.23. Any downstream abstention is their result, not a C.22 output.

  16. Budgets. When Budgeting is live, its evaluation, time, and batch values carry declared units and the applicable E/E-LOG exploration-budget id.

  17. Archive-comparison support. A TaskSignature supports the claimed archive comparison only when DistanceDefRef.edition and the applied novelty measures are CSLC-admissible and editioned. The archive or selector pattern defines or constrains any downstream abstention or returned-set result.

  18. Planes. QD heads and characteristics declare a ReferencePlane when 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.

  19. 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.

  20. 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, and G.9 use.

Common Anti-Patterns and How to Avoid Them

CountercaseRepair
A preferred method or strategy name is inserted into S2 before eligibility is tested.Remove the method value, restore the exact problem traits, and let A.19, C.23, G.4, and G.5 govern later comparison and selection.
A live unknown is encoded as false, 0, or an empty value.Restore unknown, name the direct basis relation and receiving-use policy, and let the downstream pattern produce the result governed by that policy.
Ordinal values or values with unlike units are averaged into one score.Recover scale, unit, polarity, reference plane, and admitted order for every head; use only a directly governed admissible comparison or leave the candidate set partially ordered.
One TaskSignature mixes design-time traits, later run observations, and incompatible DesignRunTag positions.Split the claims by their actual Work and relation positions; retain only the traits current in this signature edition. Use E.18 only when a selected transformation-flow relation is current, F.9 only when exact local meanings differ and its Bridge predicate is true, and the Work pattern for the actual run.
A new file, card, or database row is treated as a new TaskSignature.Compare the declaration content, exact task or work target, and effective reference scheme. Reuse the same identity when only publication, carrier, serialization, or designator changed; issue a new edition when an identity component changed.
A broad domain, organization, or location label is used as if it supplied scope, measurement, evidence, or selection rules.Recover the exact EntityOfConcern, effective ReferenceScheme, A.2.6 ClaimScope relation, U.Discipline when current, characteristic rules, and direct selector or policy relations that the use actually needs.
Data shift is assumed away because the old profile used iid.State the current ShiftClass or unknown, cite its evidence and currentness relation, and state the changed-use result under the exact acceptance or selector predicate.
A vendor, tool, or fashionable method label is treated as a normative selector input.Keep it only as a Plain example or recover the exact method-description, capability, evidence, and selector relations on which comparison relies.

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.

Current source and statusAdopted or adapted moveEffect in C.22Limitation and review condition
Roger Jiao, "Towards rigorous problem formulation for engineering design research: from motivations to measurable claims via metric-measure-method", Journal of Engineering Design 37, 2026; Szajnfarber, Lifshitz, and Tushman, "Beyond translation: how context work during problem formulation enables effective solving by outsiders", 2026 research article.Adopt problem-before-method formulation, operational characteristics and measures, and a named decision or action that will use the result. Adapt context work into the signature's exact task or work target, direct declaration fields, Vocabulary, and Applicability plus the problem-side and receiving-use slots of TaskSignatureAssignmentRelation.Changes the working question, local mantra, signature content, assignment relation, reliance replay, and the manufacturing and clinical transfer cases. A fashionable method or available dataset cannot define the TaskSignature or its assignment.These sources study engineering research formulation and outsider problem solving; they do not establish FPF kinds or one universal signature schema. Review the adaptation if later cross-domain evidence overturns the importance of measurable problem characteristics or receiving-use locality.
Cenikj, Kudela, Tuba, and Eftimov, "Evaluating Real-World Generalizability of Algorithm Selection Models", current June 2026 conference-linked paper and arXiv version.Adopt measurable problem characteristics as selector inputs and the empirical warning that transfer between benchmark and real-world landscapes can fail.Changes ScopeSlice(G), evidence and currentness relations, crossing discipline, unknown handling, and the rule that an old selector result reopens only when it depended on a changed field.The study concerns optimization landscapes and algorithm-selection models, not all methods or sectors. Do not infer universal transfer failure or a complete TaskSignature field list from its benchmark set.
Qin et al., "A survey on Quality-Diversity optimization: Approaches, applications, and challenges", Swarm and Evolutionary Computation 100, 2026; Lin et al., "Quality-Diversity Optimization as Multi-Objective Optimization", current 2026 preprint.Adopt collection-valued QD results, user-declared behavior or characteristic space, explicit containers and policies, and set-aware comparison. Adapt the MOO reformulation as one current option rather than the definition of QD.Changes the optional QD positions, DominanceRegime, report-only illumination boundary, archive case, and refusal of one default scalar score.The survey is broad but QD-specific; the MOO reformulation is a current preprint and one competing approach. Neither authorizes every diversity measure to enter dominance. Review when stronger comparative evidence changes container, metric, or scalarization treatment.
SciML, "Problem Interface" and "Common Solver Options", living documentation generated in June 2026.Adapt the practical separation between a constructed problem value and later solver dispatch, plus explicit problem remake when fields change.Changes the ODE case and the smallest-repair rule: a semantic field change revises the TaskSignature edition, and a changed problem-side or receiving-use position revises the assignment relation before selector replay; solver implementation does not become the problem or TaskSignature.This is current software practice, not a transdomain ontology and not evidence that every project needs an immutable software record. Review on material interface or dispatch changes; preserve the general separation only while it continues to improve the declared use.

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 different ScopeSlice(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 TaskSignature edition.
  • 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 QD or OEE heads 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 better language 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 TaskFamily and work target
  • later G.5 / G.9 portfolio 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

ForceTension
Threshold crossing vs final scoreA static outcome can look similar even when one system specialized much faster or more cheaply than another.
Local novelty vs reproducible evidenceCorridor-entry claims matter, but they are easy to over-romanticize when no baseline or entry evidence is published.
Task anchor vs adaptation-signature questionThe section must keep the adaptation-signature question readable without retyping task anchoring from C.22 or turning selector/parity law into the same pattern.
Reuse upside vs specialization costTransfer, retention, and downside matter to the same claim even when the first threshold crossing looks impressive.

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 TaskFamilyRef or TaskSignature, not one generic improvement claim.
  • The signature should expose at least:
    • thresholdTarget
    • timeToThreshold
    • budgetToThreshold
    • postThresholdEfficiency?
    • priorExposureDeclaration
    • transferTarget?
    • 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.22 continues to carry the declared task-family anchor, task typing, and baseline TaskSignature. C.22.1 narrows 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 corridorEntryBaseline first: the prior repertoire, baseline set, or comparison family relative to which corridor entry is being claimed.
  • Then publish the corridorEntryEvidence that 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.

Source-bound anchor familySource-use relation/currentnessWhat it disciplines in this pattern
QD / OEE corridor-entry workCurrent QD overview plus current FPF OEE/NQD neighbours.Corridor baseline, descriptor shift, stepping-stone evidence, and whether novelty is reproducible rather than one exotic sample.
Agentic adaptation benchmarksCurrent narrow source lines such as FactorMiner and SkillOpt when the task family is comparable.Threshold target, time-to-threshold, budget-to-threshold, prior exposure, and post-threshold efficiency under a declared task-family anchor.
Transfer / retention evaluationSource-use relation/currentness supplied by the applying benchmark or neighbour pattern.Transfer target, retention window, downside, and reuse evidence so specialization speed is not confused with one isolated threshold crossing.

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 TaskFamilyRef or TaskSignature.

  • 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.22 anchoring 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-1 An adaptation signature SHALL bind to one declared TaskFamily or TaskSignature, one work target, and one work-measure threshold target rather than one generic improvement story.
  • CC-C22.1-2 An adaptation signature SHALL publish timeToThreshold, budgetToThreshold, and priorExposureDeclaration; if threshold was not reached, the signature SHALL say so explicitly instead of implying success.
  • CC-C22.1-3 Any 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-4 This pattern may refine specialization timing and reuse claims over the declared C.22 anchor, but it SHALL NOT redefine acceptance-gate thresholds, task-family attachment, or selector/parity law governed by another FPF pattern.
  • CC-C22.1-5 Downstream 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

ForceTension
Actuality vs discoverabilityA Problem can obtain before anyone evaluates, notices, describes, or publishes it.
Readable problem talk vs typed dependencePractitioners need a direct sentence, while load-bearing use needs exact condition and applicability occurrences.
One applicability relation vs duplicated participantsPredicate, problem-for entity, claim scope, and declared criterion-applicability window are useful independently of PFR but must not be writable both as applicability-relation participants and as PFR participants; the applicability occurrence extent remains derived.
Continuous identity vs repeated episodesOne adverse episode may receive many assessments; the same participants may also stand in later adverse episodes after a real recovery.
Open episode use vs final intervalCurrent work needs to reference a Problem before the adverse episode has ended.
Predicate truth vs epistemic supportEvaluation and evidence support claims about adverse truth but do not make the world-side dependent relation obtain.
Solvability vs Problem actualityFinding a method changes what can be done, not whether the current condition remains adverse.
Anticipated-condition claim vs actual occurrenceA useful forecast, scenario, or hazard card can describe a possible condition before any actual-condition relation obtains.

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.

NameCard:
  NameCardId: NC-PROBLEM-CRITERION-APPLICABILITY-RELATION
  GovernedValueRef: ProblemCriterionApplicabilityRelation under C.22.PFR
  SubjectPatternLocator: C.22.PFR
  ReferenceScheme: FPFCoreReferenceScheme
  LocalSenseRef: obtaining relation saying that one characteristic-space predicate currently governs one exact problem-for entity and claim scope under one declared criterion-applicability window, independently of whether an actual condition presently satisfies the adverse predicate; repeated occurrences with the same four participants are distinguished by maximal continuous actual applicability
  TechLabel: ProblemCriterionApplicabilityRelation
  PlainLabel: problem-criterion applicability
  CandidateSet: ProblemCriterionApplicabilityRelation; CriterionApplicabilityRelation; ProblemCriterionUseRelation; ApplicableProblemCriterion
  RejectedCandidates: CriterionApplicabilityRelation overclaims a universal criterion ontology; ProblemCriterionUseRelation hides obtaining applicability behind use wording; ApplicableProblemCriterion turns a relation into an adjective-headed value
  SelectionRationale: preserve distinct applicability occurrences for different exact entities, scopes, or declared windows and after actual loss and restoration of applicability, without making a predicate-description edition identity-bearing
  PublicRowStatus: pending
  LineageEntries: replaces description-edition and generic criterion-use identity proposals
  RefreshCondition: reopen if the four fixed participants plus maximal continuous actual applicability cannot distinguish applicability occurrences, or if the direct rule no longer separates criterion governance from adverse-condition satisfaction

Use one individuable dependent U.Relation for applicability:

ProblemCriterionApplicabilityRelation:
  ProblemCriterionPredicateSlot: CharacteristicSpacePredicate, byValue
  ProblemForEntitySlot: U.Entity, byRef with an exact local ValueKind
  PredicateClaimScopeSlot: U.ClaimScope, byValue
  DeclaredCriterionApplicabilityWindowSlot: DeclaredCriterionApplicabilityWindow, byValue; use an explicit unbounded value when no finite bound is intended

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.

NameCard:
  NameCardId: NC-PROBLEMATIC-FOR-RELATION
  GovernedValueRef: ProblematicForRelation under C.22.PFR
  SubjectPatternLocator: C.22.PFR
  ReferenceScheme: FPFCoreReferenceScheme
  LocalSenseRef: actual dependent evaluative relation with one actual-condition relation occurrence and one problem-criterion-applicability relation occurrence as its only non-derived participants, individuated by those participants plus the actual inception of each maximal continuous adverse episode
  TechLabel: ProblematicForRelation
  PlainLabel: actual problem
  CandidateSet: ProblematicForRelation; AdverseCriterionAssessmentRelation; ProblemUseRelation; ProblemRelation; ProblemSituationRelation
  RejectedCandidates: AdverseCriterionAssessmentRelation omits the problem-for relation; ProblemUseRelation hides the actual adverse condition; ProblemRelation hides criterion applicability; ProblemSituationRelation falsely requires situation
  SelectionRationale: make ordinary Problem recoverable without copying applicability participants and distinguish repeated adverse episodes without requiring a universal adverse-evaluation relation occurrence
  PublicRowStatus: pending
  LineageEntries: situation-first, card-as-world, bearer-duplicating, and description-edition identity proposals retired
  RefreshCondition: reopen if participant references plus actual adverse inception cannot keep one stable occurrence reference through closure or distinguish later adverse episodes, or if the predicate's condition-to-input rule no longer yields one unambiguous characteristic point and problem-for link

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:

ProblematicForRelation:
  ActualConditionRelationSlot: U.Relation, byRef
  ProblemCriterionApplicabilityRelationSlot: U.Relation, byRef

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:

PFR.problemCriterionPredicate
  := PFR.problemCriterionApplicabilityRelation.problemCriterionPredicate
PFR.problemForEntity
  := PFR.problemCriterionApplicabilityRelation.problemForEntity
PFR.predicateClaimScope
  := PFR.problemCriterionApplicabilityRelation.predicateClaimScope
PFR.declaredCriterionApplicabilityWindow
  := PFR.problemCriterionApplicabilityRelation.declaredCriterionApplicabilityWindow
PFR.problemCriterionApplicabilityExtent
  := maximal continuous obtaining extent of PFR.problemCriterionApplicabilityRelation

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:

  1. The exact ActualConditionRelation obtains under its direct pattern.
  2. The exact ProblemCriterionApplicabilityRelation obtains 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.
  3. Apply the predicate's exact ConditionToPredicateInputRule to 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:

<actualConditionRelationRef,
 problemCriterionApplicabilityRelationRef,
 adverseEpisodeStart>

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.start until its actual cessation at A.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.start with 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:

  1. the exact obtaining condition and the value or point it supplies;
  2. the criterion that makes that point adverse, including the selected input path and cut or band;
  3. 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, while InspectorSystemRole is 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

  1. The actual condition is an explicitly individuated obtaining U.Relation under its direct pattern.
  2. CharacteristicSpacePredicate is given by value and includes one exact ConditionToPredicateInputRule: 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.
  3. ProblemCriterionApplicabilityRelation has 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.
  4. PFR has exactly two non-derived participant slots: actual condition and criterion applicability.
  5. Predicate, entity, scope, declared criterion-applicability window, and actual applicability-occurrence extent are projected from applicability rather than copied into PFR.
  6. 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.
  7. Evaluation work, outcomes, measurements, evidence, assessment claims, descriptions, and cards do not create or identify PFR by default.
  8. 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.
  9. [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.
  10. 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.
  11. Method availability and solvability claims remain separate from PFR actuality and identity.
  12. 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.
  13. Ordinary readable use can stop before explicit PFR materialization when no receiving claim needs Problem identity.
  14. 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

Anti-patternFailureRepair
Card-created ProblemCreating or accepting a ProblemCard is treated as Problem actuality.Test actual-condition obtaining, applicability obtaining, and adverse predicate truth; keep the card as an episteme about zero or more occurrences.
Duplicated applicabilityPredicate, entity, scope, or interval is writable in both applicability and PFR.Keep those values only in ProblemCriterionApplicabilityRelation and derive PFR projections.
Applicability conditioned on adversityCriterion applicability is ended whenever the actual condition becomes non-adverse, so PFR tests the same predicate twice and cannot replay A-B-C with one applicability occurrence.Let applicability state which criterion governs the entity and scope under the declared window; test adverse-condition satisfaction only in PFR §4.3.
Relation-as-coordinateAn arbitrary condition relation is said to be adverse without naming the characteristic point, projection, or link to the problem-for entity.Use the predicate's exact direct-input or governed-projection rule; reject the nearest plausible projection that does not meet that rule.
Assessment-constituted PFREvaluation work or an assessment result becomes a universal PFR participant or is treated as starting or ending the world-side episode.Let evaluation and evidence support a boundary claim; keep PFR participants, actual inception, and actual cessation world-side.
Evidence-window splittingEach measurement or assessment window creates a new Problem occurrence.Use actual adverse inception and cessation for occurrence identity; keep support windows with the claims they warrant.
Unknown-as-recovery or continuityMissing evidence is treated as proof of recovery or as permission to bridge the gap.Record continuity unresolved; later evidence may revise the boundary assertion but does not create the world-side episode.
Open-interval churnEvery observation changes the identity key, or open is used for an unsupported evidence gap.Keep participants plus actual adverse inception as the stable reference; use open only for supported current obtaining and add the recovered end to the claimed extent on closure.
Method-selected resolutionFinding a repair method is treated as ending the Problem.Update the solvability claim; end PFR only when the adverse condition or another obtaining condition ceases.
Criterion-edition identityRewording or republishing a coextensional criterion creates a new Problem.Recover the by-value predicate; create another applicability occurrence only when a fixed participant changes or when actual applicability ceases and later obtains again.

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

Current lineWhat it contributesFPF adoption
FPF A.19, A.19.CPM, G.4, and direct state and gate patternsCurrent FPF already separates characteristic-space predicate, comparison semantics, typed acceptance use, and supported outcome.Adopt directly. Put the by-value predicate in applicability and leave comparison, acceptance, evaluation, and support with the selected consumer rather than duplicating them in PFR.
FPF A.6.REL relation-occurrence disciplineRelation occurrences can be explicit participants, and separate episodes with the same participants need a subject pattern-supplied boundary discriminator.Adapt. Use the two relation participants plus actual adverse inception as the stable reference for one maximal continuous adverse episode; keep its recovered end as derived extent rather than a changing key field.
FPF A.15.1 and C.27.TA temporal conventionsTemporal statements name bearer, reference, and interval, while later evidence can revise a claim about an occurrence without changing what occurred.Adapt. Use [adverseEpisodeStart, open] only for supported current obtaining, publish a recovered end on the same stable occurrence reference, and keep unresolved continuity explicit rather than inferring a world-side boundary from evidence availability.
Operator seminar practice on development work, selected slides (2026)Practical explanation separates problematization, characteristics and criteria, method search, performed work, working results, and repeated improvement while keeping them in one understandable progression.Adapt as a use-pressure test. Keep actual PFR identity with the adverse condition and criterion applicability; keep method search, Work, results, and repetition as separate exact assertions under their own predicates, using E.18.1/E.23 only for the applicable carry-through or improvement questions instead of making them PFR participants.
Almeida, Guizzardi, Sales, and Fonseca, gUFO, 2026 preprintCurrent relation and situation comparisons provide stress pressure for dependent relations, reification, and occurrence identity.Use as a comparator. Retain a dependent relation with explicit participants and identity while avoiding a universal situation object or imported category hierarchy.
TypeDB relation instancesRelation instances can participate in other relation instances in an implementable model.Adapt as implementation evidence. Permit actual-condition and applicability occurrences as PFR participants without treating the database model as the source of PFR truth.

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.REL governs explicit individuation of both PFR participants and PFR itself when a receiving use needs identity.
  • A.6.RCD governs 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.5 governs the two PFR participant SlotSpecs and the four applicability SlotSpecs.
  • A.19 governs the characteristic space used by CharacteristicSpacePredicate; the selected direct consumer governs its condition-to-input rule and comparator semantics, A.19.CPM governs comparison when that is the consumer, and G.4 governs 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.22 governs selector-facing task typing and TaskSignature assignment after a problem-side episteme is usable.
  • C.22.2 governs 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.1 and A.3.4 govern 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.TA governs temporal aspect statements when interval publication or temporal adequacy is current.
  • A.10, B.3, and G.11 govern 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:

  1. what signal or cue made the practitioner stop;
  2. the one exact joint EntityOfConcern, effective U.ReferenceScheme, and U.ClaimScope for the claims being carried;
  3. which claim family is current: actual-PFR assertion, anticipated-condition claim, method-availability or solvability claim, or another directly governed problem-side claim;
  4. why this is not merely a wish, ticket, slogan, label, or preselected Work request;
  5. what would count as improvement or as an acceptance probe; and
  6. 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.

  1. Capture the symptom, anomaly, risk, stakeholder cue, drift, hypothesis, or other observed signal before naming an actual Problem.
  2. Recover the one joint EntityOfConcern, effective ReferenceScheme, ClaimScope, and claim family. If the claims concern unrelated entities, split the ClaimGraph and card.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Current claim, relation, or boundary that changes the card useLocal ProblemCard contentSubject pattern
Characterization, measurement, indicator, Q-bundle, comparison, acceptance, or parityCharacterization cue, acceptance probe, candidate criterion, comparator cue or window cue, and the current reason the relation changes the problem formulation.C.16, A.19, C.25, G.0, G.4, or G.9 according to the relation named by value.
Archive, pool, front, shortlist, selected set, retained candidate, or set-return sourcesourceSetRef, source-set kind, selection or retention criterion, budget or window when current, and non-scalar next use.C.18, C.19, G.5, G.9, G.11, A.6.P:7a, or C.16.Q according to the relation named by value.
Method family, work planning, work-entry readiness, performed work, result record, evidence, provenance, assurance, gate, or autonomyProblem-side cue, source reference when it changes formulation, and stop condition before that outside use.G.5, A.15, A.15.5, A.10, G.6, B.3, A.21, or E.16 according to the claim named by value.
Temporal, causal-use, representation-transition, retargeting, bridge, structural-reinterpretation, or wording-use relationRelation reference plus the inheritance boundary: what can be reused from the old card and what relation is reopened.C.27, C.28, A.6.3.RT, A.6.4, E.17, F.9, E.18, or E.10 according to the relation named by value.
First-principles or mathematical structure cueCandidate structure, preserved and lost structure when current, practical payoff for problem formulation, problem-formulation follow-up reason, and stop condition.C.29 for mathematical-lens use; A.6.0 for a FormalSubstrate U.Signature declaration when that signature declaration is current.
Agentic safe probe or world-affecting next actionProbe need, risk condition, bounded next action, and the safety named by value, autonomy, gate, work, evidence, or assurance claim kind that blocks local action.C.24, E.16, A.21, A.15, A.10, G.6, or B.3 according to the relation named by value.

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;

  • firstPrinciplesCue when 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.

Field current-use classRequired treatment
C.2.1 constitutionState the exact ClaimGraph, one joint EntityOfConcern, and effective ReferenceScheme. These constitute the card episteme; ClaimScope, viewpoint, assumptions, windows, and receiving use qualify the relevant claims and relations, while id, carrier, and publication remain outside constitution.
Core problem-side claimsState the signal, ClaimScope, claim family, not-wish reason, improvement check or acceptance probe, and honest next use.
Conditional claims and referencesAdd only the exact characterization, comparison, risk, validation, freshness, set-source, representation, forecast, solvability, PFR, or other direct relation content that changes the move.
Subject-pattern cueKeep only the local cue or reference needed by the card, then name the direct pattern and claim kind that govern the outside 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:

problemCardWitnessRefs:
  problemSignalRef?
  sourceSetRef?
  selectionOrRetentionCriterion?
  characterizationRelationRef?
  parityRelationRef?
  freshnessRef?
  representationOrWordingUseRelationRef?

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-ready is 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.

CheckRequired test
C.2.1 identityThe card has one exact ClaimGraph, one independently identified joint EntityOfConcern, and one effective ReferenceScheme. Unrelated PFRs or other concerns force ClaimGraph/card split.
Claim-family separationActual-PFR assertion polarity, reliance result, anticipated-condition claim, and method-availability or solvability claim remain distinct.
PFR boundaryAny affirmative actual-PFR assertion names an occurrence independently established by C.22.PFR. A card, signal, label, viewpoint, evidence item, method, or negative assertion creates or ends none.
Core usabilityThe card states signal, ClaimScope, claim family, not-wish reason, improvement check or acceptance probe, and honest next use.
P2W-ready reasonP2W-ready appears only with an improvement check or acceptance probe and one named downstream use; it is problem-side readiness only.
Field budgetConditional content appears only when current; absence and admitted unknown remain distinct.
Exact source and setA set-derived card preserves exact sourceSetRef, set kind, retention or selection criterion, and non-scalar next use without becoming an archive or portfolio object.
Direct-governor cueClaims outside C.22.2 remain local cues or references and name the exact pattern and claim kind used next.
Constitution stays exactOnly ClaimGraph, one joint EntityOfConcern, and effective ReferenceScheme constitute the card. Scheme, ClaimScope, assumptions, windows, viewpoint, receiving use, and any exact A.15.6 Work reference stay in their claims and direct relations; no setting, carrier, or organization is added as a participant.
Currentness and changeFreshness, changed representation, retargeting, or unknown-blocked use states refresh, retirement, bounded use, abstainOrNoChange, or the exact relation reopened.
Scalar and proxy guardGoldilocks, NQD, OEE, set-return, priority, indicator, or stepping-stone wording does not become one readiness score or substitute for value.
First-principles payoffA mathematical cue states practical payoff, preserved and lost structure when current, follow-up reason, and stop; C.29 governs the lens use.
External wording recoveryPassport, rule-of-choice card, evidence pack, autonomy budget, logs, gates, portfolio, factory, and similar source terms enter only as exact signal, set, characterization, comparison, or follow-up material under their direct governors.
Record-budget invariantThe card is as small as the current next use permits; a template, relation aid, or worked example is not another FPF kind.

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.

FPF-governed useCurrent recoveryC.22.2 disposition
Symptom, anomaly, deviation, risk signal, or stakeholder signalProblem signal or exact signal referenceMay trigger a card but is not an actual Problem or complete problem-side claim by itself.
Problematic situationPlain cue for an exact condition, entity, Work, transformation, or relation under its direct patternThe phrase introduces no U.Situation; an actual Problem still requires one obtaining C.22.PFR relation.
Actual ProblemOne obtaining ProblematicForRelation with exact condition and applicability participantsC.22.PFR governs actuality and identity; the card can assert or designate it only after that settlement.
Forecast, scenario, counterfactual, or anticipated conditionExact non-actual claim with assumptions, horizon, and direct governorPreserve the claim family; do not turn affirmative wording into current PFR obtaining.
Method availability or solvabilityClaim over admitted methods, evidence, constraints, and one intended useSelecting a method revises this claim but does not end an actual PFR.
Framed problem-side representationClaimGraph about one joint EntityOfConcern under one effective ReferenceScheme and ClaimScopeCenter of ProblemCard; representation change uses its direct transition, retargeting, Bridge, or wording-use governor.
Candidate from archive or retained poolMember of an exact source set under a retention relationPreserve sourceSetRef, set kind, criterion, budget/window, and non-scalar next use; set semantics remain outside the card.
Selected problem from a set-return treatmentExact selected member under a direct selection relationThe card may carry the member, but selection, parity, archive, and set-return claims remain with G.5, C.18, C.19, G.9, G.11, A.6.P:7a, or C.16.Q as applicable.
Problem ready for selector-facing useCard sufficient to prepare or assign TaskSignatureC.22 constitutes and assigns TaskSignature; C.22.2 does not dump card content into it.
Downstream task, method, plan, or performed-Work cueExact value or relation under C.22, G.5, A.15, or another direct patternKeep only the problem-side cue and stop before claiming the downstream result.
E.8 or E.9 Problem frameAuthoring or decision-rationale sectionNot a ProblemCard and not an actual Problem by heading alone.

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.

Term or local nameCurrent FPF recoveryLocal disposition
ProblemOrdinary wording, ProblemCard claim content, or actual PFR according to the sentenceC.22.2 governs the card; C.22.PFR governs the actual relation. Label alone decides neither.
ProblemCardC.2.1 episteme about one joint EntityOfConcernCompact problem-side result before P2W; not a work request or world-side Problem.
ProblemProfileC.2.1 episteme used by a named receiving selection useNot the card, TaskSignature, method, or Work request.
TaskKind, TaskFamilyRef, TaskSignatureC.22 selector-facing declaration content and epistemeDownstream typing values; not WorkPlan entries.
TaskSignatureAssignmentRelationObtaining relation among exact problem-side episteme, TaskSignature, and receiving-use epistemeSeparate from all three participants and from card fields.
Method-family selection claimG.5 comparison or selection resultNot a card field and not PFR cessation.
U.Method, U.MethodDescriptionMethod and method-description valuesGoverned by their direct method patterns.
U.WorkPlan and its declaration-local SlotFillingsPlanItem contentIntended Work and planned-filling rows addressed only through that WorkPlanDefined and tested by A.15.2 and A.15.3; not a TaskSignature or ProblemCard.
U.WorkPerformed dated WorkGoverned by A.15.1; its record or evidence is separate.
Result, measurement, assertion, evidence, or relianceExact output under C.16, C.2.1, A.10, G.6, B.3, G.11, or the direct result patternCan support a card claim but neither constitutes the card nor makes PFR obtain.

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.16 carries measurement characterization, backing, and comparability discipline;
  • A.19 carries characteristic, scale, unit, polarity, and indicator-use discipline;
  • C.25 carries Q-bundles and quality-like multi-characteristic bundles;
  • G.9 carries parity, comparison-window, comparator, budget, unit, repeatability, and reproducibility pins;
  • G.0 carries comparison-frame and CG-Spec governance;
  • G.4 carries acceptance clauses and threshold predicates;
  • use G.5 for selector-facing selected-set result declaration when the problem enters a selected set; when actual audience availability is separately 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.

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.

Source form familyC.22.2 preservationSubject pattern named by value for outside use
Problem card, problematization passport, problem-side note, or ordinary problem signalCarry the signal, joint EntityOfConcern, effective ReferenceScheme, ClaimScope, exact claim family, not-wish or not-preselected-work reason, improvement check or acceptance probe, and honest next use.C.22.2 governs only the problem-side episteme; downstream selector-facing use remains with C.22.
Archive, portfolio, palette, front, shortlist, selected set, LivePool, set-return, or retained candidatePreserve sourceSetRef, source-set kind, selection or retention criterion, budget or window when current, and non-scalar next use.C.18, C.19, G.5, G.9, G.11, A.6.P:7a, and C.16.Q according to the relation named by value.
Characterization passport, characteristic card, parity plan, comparison note, rule-of-choice card, or acceptance-looking rowPreserve the cue, candidate criterion, comparator cue or window cue, and current reason the relation changes formulation.C.16, A.19, C.25, G.0, G.4, G.9, or C.11 according to the relation named by value.
Evidence pack, provenance note, assurance row, gate log, autonomy budget, runbook, rollback plan, method selection, work plan, performed-work note, result record, or result measurementPreserve only the problem-side cue, risk or validation boundary, source reference, and stop condition before that use.A.10, G.6, B.3, A.21, E.16, G.5, A.15, C.16, or G.11 according to the claim named by value.
Candidate solution, described system, ordinary log, budget, ledger, protocol, plan, pack, or factory wordingRecover the use under repair: problem-side source material, problem-side source relation, selected-set material, work, evidence, gate, or autonomy material, or ordinary example.Apply the subject pattern for the recovered relation; do not mint a local C.22.2 kind from the label.

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:

Source wordingCurrent FPF pattern or relationRequired problem-card preservation when the corresponding claim is being made
Problem archiveC.18, C.19, A.10, G.6Preserve source set or reference, retention criterion, candidate status, and provenance relation.
Problem portfolioG.5, C.19, G.9, G.11Preserve selection or retention criterion, budget or window, review cadence, and selected-set or LivePool relation.
PaletteC.18, C.19, G.5Preserve candidate-family or option-set interpretation without turning it into evidence or approval.
FrontC.18, A.19, C.25, G.5Preserve declared characteristics and non-dominated set interpretation.
ShortlistG.5, with G.9 when comparison pins matterPreserve selected-set criterion and downstream use.
Ranked shortlistG.5 only when a declared order is declaredPreserve ranking criterion or narrow to selected set with tie notes.
Selected setG.5Preserve selected-set output, selection pins, and unknown handling.
LivePoolC.19Preserve pool policy, current treatment, and change trigger.
Set-returnG.5, C.18, C.16.Q, declared comparison recordsPreserve set-valued result when no total order is declared.

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:

Source-side cueCurrent FPF pattern or relationC.22.2 use
Zero-principles and first-principles invariants, constraints, symmetry, composition, multi-scale description, variational structure, probability or information, and resource limitsC.29, with A.19, C.16, C.25, and G.9 when characteristics, measurement characterization, quality bundles, or parity are currentCarry a first-principles or mathematical structure cue and apply the subject pattern for the claim being made, relation, or boundary.
Second-principles method-family implicationsG.5, A.15, E.18, A.19 as applicableName the method-family cue; do not perform method selection in the problem card.
Third-principles reproducibility, checks, templates, records, logs, rollback, evidenceA.10, G.6, B.3, A.21, G.11, E.16 as applicableName the reproducibility or evidence cue and apply the subject pattern for the claim kind named by value before relying on that claim.

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.

Card-use conditionLocal dispositionNext pattern application
The current reason is sufficient for the named reversible P2W use.P2W-ready only for that named use, with effective ReferenceScheme, ClaimScope, qualification window, validation boundary, and stop condition.Apply measurement, evidence, temporal, refresh, representation, gate, autonomy, Work, or assurance patterns only when those claims are part of the use.
The reason is useful but narrower than the attempted use.Narrow the attempted use; name the narrowed use, blocked attempted use, and stop condition.Apply the subject pattern for the missing claim, relation, or boundary.
Source material, source relation, validation, or currentness is stale, conflicted, uncalibrated, or untied to the current relation.Choose abstainOrNoChange, refresh, or reopen; name the missing relation, evidence-needed cue when current, and decision point.Use A.10, G.6, B.3, C.16, C.27, G.11, A.6.3.RT, A.6.4, E.17, F.9, or E.18 according to the reopened relation.
The proposed next action can affect the world, spend resources, call tools, delegate to agents, change operational state, or make safety, release, gate, or work claims.Block local use or name the governing relation; keep only the problem-side cue inside the card.Apply B.3, A.21, E.16, A.15, A.10, G.6, or B.2.5 when the corresponding controlled-EntityOfConcern relation is current.

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:

State or disposition labelRequired interpretation
draftSignalA problem signal has been captured, but the card is not yet reviewable.
reviewableThe problem-side record can be inspected, challenged, sent onward, or refined, but it is not necessarily P2W-ready.
P2W-readyLocal disposition label with plain gloss: problem-side input ready. The problem-side record is sufficient for downstream P2W or selector-facing use; it is not ReadyForWork, GateReady, MethodReady, AutonomyReady, or work authorization.
subject-pattern cueA claim, relation, or boundary outside C.22.2 changes the current problem-card use; the card names the governing FPF pattern and claim kind named by value to use next without claiming that use inside C.22.2.
staleFreshness or expiry blocks the intended downstream use until refreshed, retired, or otherwise disposed.
refreshedThe relevant signal, source material, source relation, ReferenceScheme, ClaimScope, characterization, parity, evidence, provenance, assurance, representation relation, or wording-use relation has been updated enough for the named use.
retiredThe problem-side record is no longer used as a current problem for downstream work.
archivedThe record is retained under the relevant archive, pool, front, or selected-set pattern without being current for P2W.
abstainOrNoChangeNo downstream receiving use is selected because the signal is stale, duplicate, already solved, already absorbed, unnecessary, or not worth current downstream Work.

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, or G.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.

Pattern or pattern familyWhen it matters for the cardC.22.2 use
C.22Problem-side record, ProblemProfile, and TaskSignature are being related.Keep TaskSignature minimal and apply representation-transition, bridge, retargeting, structural-reinterpretation, or wording-use patterns only when a current relation claim or use-boundary appears.
C.16, A.19, C.25, G.9, and G.11Characterization, characteristic, Q-bundle, parity, or freshness representation changes the selected entity or comparison relation.Preserve only the problem-card cue and apply the characterization, parity, bundle, or refresh relation named by value when that relation is being made.
C.29A mathematical representation preserves, coarsens, or retargets the EntityOfConcern or the problem-side representation.Use C.29 output and representation or wording-use relation references when structure changes entity interpretation.
C.18, C.19, and G.5Archive, pool, front, shortlist, selected set, method-family, or selected-set output uses transformed representations.Preserve source-set reference, criterion, and downstream use; keep selection semantics outside the card.
A.6.P, C.16.Q, E.10, E.17, F.9, E.18, A.10, G.6, B.3, A.21, E.16, and A.15Source wording, quality wording, multi-view, bridge, structural reinterpretation, evidence, provenance, assurance, gate, autonomy, method, or work relation is current.Keep the local cue only; apply the subject pattern for the claim being made, relation, or boundary before reusing readiness or relying on the transformed material.

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.

Source detailCurrent FPF recoveryC.22.2 carry-forward relation
Source examples: person, team, organization, System, community, episteme, and exact WorkRecognition material for the EntityOfConcern or exact A.15.6 Work when it changes problem-card use; not a new FPF kind taxonomyA domain or practice locus may qualify the effective ReferenceScheme, ClaimScope, horizon, indicators, cost of error, the exact system-role kind or assignment, participation, viewpoint, or comparison, but it neither constitutes the card nor identifies an actual Problem.
Engineering language for reproducibility and management language for coordination, rights, resources, and responsibilityVerification and reproducibility, coordination, right, resource, system-role classification or assignment, participation, and responsibility claims are different FPF relationsC.22.2 may retain bare role only as an E.10.ROLE cue; any exact kind, assignment, participation, budget, right, or responsibility field or relation reference follows its direct pattern. Claims outside the problem-side record stay there.
Problem factory, solution factory, and factory-of-factoriesSource exposition for three related work families, not FPF process kindsC.22.2 covers only the problem-side output. Solution and P2W relations use G.5, A.15, E.18, A.10, G.6, B.3, A.21, E.16, and G.11; organizational-development or platform-capability questions are outside this pattern.
Characterization protocol: ReferenceScheme, ClaimScope or slice, compared set, exact system-role-kind, assignment, participation, or viewpoint qualification, scale, polarity, measurement Method, freshness, repeatability, budget, missing data, and comparison rulesC.16, A.19, C.25, G.9, and the exact qualification patternProblemCard cites characterization, qualification, and comparability relations when current; available measurement or a visible label alone is not an accepted use relation.
Indicator uses: mandatory constraints, optimization objectives for the current cycle, and risk signalsCharacteristic and Q-bundle use under selected comparison or acceptanceC.22.2 preserves whether an indicator is used as a mandatory constraint, optimization objective, or monitored risk signal when that distinction affects acceptance; the use is not a system-role kind or assignment.
Problem portfolio as a period-bounded selected set with budget, assignment or participation cue, review cadence, and not-selected dispositionG.5, C.19, G.9, G.11, A.6.P:7a, C.16.Q, and E.10.ROLE when bare role is the source cueProblemCard preserves the source set or reference, selection or retention criterion, budget or window, review cadence, and not-selected or stepping-stone disposition. If an actual System, local system-role kind, assignment, participation, or responsibility relation matters, cite that independently obtaining direct claim rather than the portfolio wording.
Goldilocks as zone-of-growth selection calibrated to current capability, effective ReferenceScheme, and ClaimScopeProblem-side entry to current NQD, OEE, and set-return familyC.22.2 does not turn Goldilocks into one global difficulty scale or scalar readiness score.
Stepping stones as option value: new actions, tools, data, interfaces, environments, or experiment modes that may expand downstream searchRetained archive, front, or pool member, or selected-set reasonC.22.2 may record stepping-stone value only with a governing set-return, archive, or pool pattern and a retention or tie-break criterion.
P2W chain: signatures and principles help select formalism, ontology, characterization, and method-family materialA.6.0, A.6.1, C.16, A.19, C.29, G.5, and E.18C.22.2 supplies problem-side cues and relation references; it does not select the formalism, ontology, mechanism, or method family by itself.
P2W chain: condition measurement and comparison help select a concrete methodC.16, A.19, C.25, G.9, G.5, and A.15State the comparison-and-acceptance cue or acceptance-criterion reference and parity and characterization relations needed by downstream method selection.
P2W chain: work planning makes planned work inspectableA.15.2 and A.15.3C.22.2 may emit or bind TaskSignature, but the identifiable plan is one exact U.WorkPlan; any planned-filling row remains declaration-local content addressed through that plan.
P2W chain: performed work produces work-result recordsA.15, A.10, G.6, and B.3C.22.2 does not treat performed work or result records as problem-card fields beyond problem-side cues or named relation references.
P2W chain: result measurement can trigger refresh or return to earlier source materialC.16, G.11, A.10, G.6, B.3, C.18, and C.19C.22.2 states freshness or expiry and unknown-handling dispositions that let downstream result measurement refresh, retire, or re-open the problem-side record.
Runbook, rollback plan, canary, SafeStop, error budget, and override protocolWork, gate, autonomy, evidence, and control recordsThese source forms are not C.22.2 subobjects; apply A.15, A.21, E.16, A.10, G.6, or B.3 when the corresponding claim is current.
Trust debt after reliance-window expiryFreshness and decay indicator and bounded-risk continuation questionTreat trust debt as an indicator or problem-formulation follow-up reason, not as punishment, proof failure, or gate passage by itself.

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.

Current source or relation lineReferencePattern useDisposition
Problem framing turns an ill-structured situation into a solvable design problem and requires care because "framing" is ambiguous.2025 CEEA paper "Towards a Theoretical Framework of Framing in Engineering Design", https://doi.org/10.24908/pceea.2025.19713Contributes deconfliction of symptom, situation, framed problem representation, and task.Adopted as field and kind-recovery cue; wording is expressed in current FPF terms.
Strategic problem framing distinguishes symptoms and attention allocation from causal problem formulation.2025 Organization Science article "Looking at the Trees to See the Forest: Construal Level Shift in Strategic Problem Framing and Formulation", DOI suffix 2024.19134, https://doi.org/10.1287/orsc.2024.19134Motivates the fields for problem signal, problem hypothesis/cause-theory cue, and improvement check.Adapted; causal claims still apply C.28 plus evidence, provenance, or assurance patterns when current.
QD and OEE work motivates collections, fronts, archive retention, set-return, and non-single-winner treatment.2026 survey "A survey on Quality-Diversity optimization: Approaches, applications, and challenges", https://www.sciencedirect.com/science/article/pii/S2210650225003979; QD-as-MOO reference https://arxiv.org/abs/2602.00478 checked 2026-05-20Motivates set-source-reference and Goldilocks docking into current C.18, C.19, G.5, G.9, G.11, A.6.P:7a, and C.16.Q.Adopted as field and relation cue; no local QD or OEE vocabulary or scalar readiness score is introduced.
Open-ended coding agents use archives, self-improvement, problem variants, evaluator feedback, and stepping-stone retention.Darwin Godel Machine https://arxiv.org/abs/2505.22954, FrontierSmith https://arxiv.org/abs/2605.14445, and AlphaEvolve https://arxiv.org/abs/2506.13131, all checked 2026-05-20Contributes record-form, set-source reference, Goldilocks, safe-probe, and freshness fields and relation references for archive, problem generation, safe probes, evaluator feedback, no-change and abstain dispositions, and autonomy and evidence boundaries.Adapted as recent trend cue; C.22.2 is not turned into AI-agent doctrine or an AI-agent management pattern.
External AI-agent and autonomy practice more often makes evidence, log, gate, autonomy-budget, and update-discipline claims current.Presented material plus current FPF autonomy, evidence, and gate patternsMotivates subject-pattern assignment for validation, AI-agent cues, and safe probing.Non-FPF-governed for the center of C.22.2; FPF-governed content remains with E.16, A.21, A.10, G.6, B.3, A.15, and G.11.

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:

Source or relation cuePopular shortcut rejectedRequired local resultReopen condition
Problem framing is ambiguous and abstraction shifts matter.Symptom, root-cause story, request, or ticket is treated as the problem.Recover signal, framed problem representation, EntityOfConcern, effective ReferenceScheme, ClaimScope, viewpoint qualification, improvement check, and rival formulation when current.Reopen when scheme, scope, viewpoint, rival formulation, evidence need, or improvement or acceptance probe changes.
P2W uses only a reviewable problem-side record.P2W-ready is treated as Work authorization, gate passage, method selection, evidence proof, assurance, or selected solution.State problem-formulation follow-up reason, validation boundary, readiness disposition, retained P2W use, blocked attempted use, and subject-pattern cue when an outside claim is current.Reopen when the signal, EntityOfConcern, ReferenceScheme, ClaimScope, acceptance probe, follow-up reason, validation boundary, freshness, or named outside claim changes.
QD, OEE, and set-return work produce archives, fronts, pools, and selected sets.Priority score, single winner, local problem portfolio, or local selected-set claim.Preserve sourceSetRef, source set kind, selection or retention criterion, and a non-scalar next use; apply the governing set, parity, archive, pool, or refresh pattern when current.Reopen when the source set, retention criterion, parity relation, archive, pool, front, selected set, budget, window, or freshness disposition changes.
Open-ended agents, problem variants, evaluator feedback, and stepping stones change signal interpretation.Agent output, evaluator trace, or generated variant is treated as enough to act.Record generator, evaluator, variant, or stepping-stone reason source only as a problem-side cue; name validation, freshness, and pattern reference named by value before probe or action.Reopen when generator, evaluator, variant, stepping-stone reason source, safety condition, probe condition, or pattern reference named by value changes.
First-principles or mathematical structure can improve formulation.A named formalism or mathematical or ontological prestige is treated as adequacy or rigor.Record the candidate structure, either its relation to the problem-side EntityOfConcern or the C.29 mathematical-lens-use relation, preserved and lost structure when current, practical formulation payoff, problem-formulation follow-up reason, and stop condition.Reopen when candidate structure, preserved or lost structure, problem-formulation follow-up reason, stop condition, or C.29 result changes.
Early class or kind taxonomy looks available.A class list or ontology-first taxonomy is treated as the problem formulation.Keep the formulation question current; record candidate structure, preserved and lost structure when current, and representation or retargeting relations before freezing kind structure.Reopen when formulation question, kind structure, relation, representation-transition relation, or retargeting relation changes.
Object model looks clarifying.Object-model clarity freezes the wrong EntityOfConcern or relation.Keep EntityOfConcern and relation reviewable; name representation-transition, retargeting, or bridge relation references before reusing a local cue or readiness disposition.Reopen when EntityOfConcern, relation, view, bridge relation, or representation-transition relation changes.

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

InvariantRequirement
One card, one joint EntityOfConcernOne ProblemCard has one ClaimGraph, one independently identified EntityOfConcern, and one effective ReferenceScheme. Several PFR references may share the card only when one direct pattern identifies their joint concern; otherwise split the claims and card. C.22.2:20.1b supplies the joint, forced-split, and many-cards/one-PFR replay.
ProblemCard is not PFRThe card may assert, deny, forecast, describe, or discuss solvability, but only C.22.PFR establishes actual Problem obtaining and identity.
Claim families remain distinctActual-PFR assertion polarity, A.10/B.3 reliance, G.11 currentness, anticipated-condition claims, and method-availability or solvability claims do not collapse.
P2W-ready is problem-side readinessThe card can be ready as input to P2W or C.22 without being ready for Work execution, gate passage, method selection, evidence reliance, or autonomy.
Constitution and qualification stay separateClaimGraph, one joint EntityOfConcern, and effective ReferenceScheme constitute the card. ClaimScope, assumptions, window, viewpoint, receiving use, and any exact A.15.6 Work reference stay in their claims and direct relations; no carrier, organization, or setting constitutes the card or PFR.
Claims outside C.22.2 stay outsideEvidence, assurance, gate, autonomy, Work, archive, selected-set, comparison, acceptance, representation, temporal, causal, and mathematical-lens claims remain with their governors.
Stale or blocked cards state a dispositionA stale, unknown-blocked, changed-representation, or missing-governor card states refresh, retirement, bounded use, abstainOrNoChange, or the exact relation reopened.

Misuse Modes and Repairs

Misuse modeSymptomRepair
Card-as-executable-work requestA solution-shaped task or implementation request is treated as a problem-side record.Recover the signal, joint EntityOfConcern, effective ReferenceScheme, ClaimScope, claim family, reason this is not a preselected Work request, improvement check or acceptance probe, and honest next use before applying a Work pattern.
Content creepThe card starts carrying claims outside the problem-side record.Keep only the cue or reference needed by the problem-side record and apply the pattern that defines or constrains the claim being made.
Hidden scalarizationGoldilocks, readiness, priority, OEE, QD, or indicator wording becomes one local score.Preserve source-set kind, selection or retention criterion, characteristic or Q-bundle relation, and non-scalar next use.
Silent retargetingA changed EntityOfConcern, representation scheme, diagram, functional description, or transformation-flow path interpretation inherits old readiness by wording continuity.Name the representation-transition, retargeting, bridge, structural-reinterpretation, or wording-use relation before reuse.
Refresh dead endExpiry or unknown handling is recorded as a passive note.State refresh, retirement, bounded use, abstainOrNoChange, or the relation that is reopened.

Use-Quality Checks

These checks protect the card's practical use; they do not add fields.

CheckQuality question
RecognitionCan the practitioner recognize the working situation before outside-governed relation material appears?
Thin affordanceCan the exact Thin contract in C.22.2:2.1 fit under one page when only its core items are current?
Next useDoes the card choose P2W-ready, characterize, compare, search, refresh, retire, archive, abstainOrNoChange, or the FPF pattern governing the named claim kind, relation kind, or boundary?
Record budgetAre heavier fields present only because they change the current move?
P2W exportDoes the card state what P2W may use now and which subject-pattern cues remain outside the card?

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.

CaseProblem-side signalRepaired card useBoundary preserved
AI and human task transfer reworkRepeated rework appears after transfer between human and agent.Stabilize signal, EntityOfConcern, effective ReferenceScheme, ClaimScope, acceptance probe, and safe-call or Work relation before another delegation.The card is not a prompt retry instruction and does not justify another delegation.
Musical mastery tempo driftPractice tempo drifts away from the intended mastery band.State the temporal claim, practice scheme and scope, acceptance probe, and C.27 relation when tempo, rhythm, recovery, or learning rate changes the next use.A trend line is not an intervention model or evidence of mastery.
Customer-service escalation after a policy or interface changeEscalation volume rises after the change.Stabilize affected customer hand-off, acceptance probe, risk boundary, measurement relation, and causal-use relation when that relation is being made.Escalation volume is not an automatic fix request, staffing plan, rollback order, or causal proof.
Literature-synthesis anomaly before method selectionAn anomaly does not fit current category labels.Preserve rival formulation, EntityOfConcern, evidence need, bridge, representation, or mathematical-lens relation when that relation is being made, and next discrimination action.The anomaly is not proof for a new theory or a selected research method.
Selected-set candidate before P2WA retained candidate from a front or pool looks promising.Preserve sourceSetRef, source-set kind, selection or retention criterion, non-scalar next use, and only the currentness or window on which that use relies.Set membership is not selected-solution proof, priority score, or work authorization.

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.

Card fieldFilled value
Source signalEscalations reopen after hand-off from first-line support to specialist support.
Problem-side EntityOfConcernThe hand-off ambiguity at the support interface, not the whole escalation process.
Effective ReferenceScheme and ClaimScopeScheme: support-interface hand-off under the new policy edition. ClaimScope: SupportOps-EU.
Claim familyAnticipated-condition claim: while the ambiguity remains under the current policy wording, reopened escalations are expected to continue. The card asserts no actual-PFR occurrence, causal-use result, or solvability result.
Not-wish, not-ticket, and not-preselected-Work reasonThe incoming request to "rewrite the escalation workflow" is a proposed Work request. It neither identifies the joint concern nor shows that a rewrite is the needed Method or Work.
Improvement check or acceptance probeSample reopened cases; accepted improvement means fewer reopened hand-offs within that ClaimScope and window without increasing unresolved safety, compliance, or customer-impact exceptions.
Honest next useUse E.18.1 to carry only the hand-off-ambiguity claim and acceptance probe into one next relation question. Do not select a method, approve a rewrite, pass a gate, or authorize Work.
Qualification window (current here)Two-week incident window under the stated policy edition.
Problem-formulation follow-up reason (current here)Separate interface wording, System, assignment, Method, and Work alignment, evidence, currentness, and possible policy-boundary relations before any Method or WorkPlan choice.
Validation boundary (current here)Same support interface, policy edition, ClaimScope, incident window, and source logs; refresh if the scheme, scope, source logs, window, or acceptance probe changes.
Readiness dispositionP2W-ready only for the narrow next use above, because the card carries the ambiguity claim, rejects the preselected Work request, and supplies an acceptance probe.
Subject-pattern cues (current here)A.6 for policy or interface wording; A.2, A.2.1, F.6, and A.15 for System, assignment, Method, and Work alignment; A.10 only if evidence reliance becomes current; G.11 for currentness; A.21 only if a gate claim later becomes current.

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.

BranchExact card-side objectsMechanically recoverable result
One joint multi-PFR cardRobot7ReleaseEpisodesCard-E1 = <CG-Robot7-ReleaseEpisodes-E1, Robot-7, Maintenance-Scheme-A>. The exact ClaimGraph contains two affirmative assertion nodes designating PFR-InspectionAssignment-17 and PFR-InspectionAssignment-18. A.1 independently identifies Robot-7 : U.System, and both PFRs have that same System as their applicability-derived problem-for entity.One ClaimGraph has one direct, genuinely joint EntityOfConcern, so one card carries both PFR references. The card records two occurrences; it does not merge them.
Unrelated PFRs force splitProposed CG-Mixed-RobotReleaseProblems-E0 contains PFR-InspectionAssignment-17 about A.1-identified Robot-7 and PFR-InspectionAssignment-27 about separately A.1-identified Robot-8. No direct pattern in this replay identifies one joint EntityOfConcern for those claims; a list of the two Systems is not one.E0 cannot constitute one ProblemCard. Split it into CG-Robot7-ReleaseProblem-E1 in Robot7ReleaseProblemCard-E1 and CG-Robot8-ReleaseProblem-E1 in Robot8ReleaseProblemCard-E1, each with its own exact System EntityOfConcern and effective scheme.
Several cards retain one PFRRobot7SafetyCard-E1 = <CG-Robot7-Safety-E1, Robot-7, RobotSafety-Scheme-A> qualifies its designation by SafetyAssuranceViewpoint-E1 and receiving use AutonomousInspectionReleaseReview-E1. Robot7StaffingCard-E1 = <CG-Robot7-Staffing-E1, Robot-7, MaintenancePlanning-Scheme-B> qualifies its designation by MaintenancePlanningViewpoint-E1 and receiving use InspectionAssignmentRepairPlanning-E1. Both exact ClaimGraphs designate PFR-InspectionAssignment-17.The differing ClaimGraphs, schemes, viewpoints, and receiving uses identify or qualify two cards and their claims; the PFR reference remains exactly PFR-InspectionAssignment-17. Revising, merging, splitting, publishing, or replacing either card changes no PFR participant or adverse episode.

Anti-Cases

Anti-caseCorrect result
The card is cited as safety acceptance, gate passage, tool-call action invitation, or work authorization.Apply the safety named by value, gate, autonomy, work, evidence, provenance, or assurance pattern; keep only the problem-side cue in the card.
A mathematical phrase is added because it sounds rigorous.Use C.29 only when the candidate structure, preserved and lost structure, payoff, follow-up reason, and stop condition are recoverable.
A source archive produces a "best" problem by one score.Use source-set and selected-set patterns; the card carries a non-scalar source-set reference, criterion, and problem-side next use.

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, or B.3;
  • local choice among explicit options: use C.11; use G.5 when selector-facing set-result declaration is current; when that result already exists and actual audience availability is current, use E.17 for its source-backed publication face and return to source and E.24.PUB for the publication occurrence and availability;
  • agent tool-call, gate, or autonomy claim: use C.24, E.16, or A.21; ProblemCard may only name the problem-side cue or relation named by value;
  • ordinary discussion with no downstream receiving use: no C.22.2 use.

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.2 has practical value for FPF when it reduces at least one expensive failure: a wish enters P2W as TaskSignature; a preselected work request is treated as the problem; method selection happens before the problem is reviewable; a problem from a set loses sourceSetRef; 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.29 patterns 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 ProblemCard adds 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 TaskSignature minimal; and add conditional fields only when their relation is current.
  • For problems emitted from archives, pools, fronts, selected sets, or portfolios, the practitioner preserves sourceSetRef or 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, and A.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, and E.10.MOVE. Use C.22.PFR when actual Problem obtaining or identity is current. Use C.32.P2S only 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_eff only (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 unknown S2 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:

LOG.Deduce_f(TaskSignature S2) → {Admit | Degrade(mode) | Abstain}

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 unknownDegrade(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 tolerates stiff?=unknown if Jacobian_sparsity=high (guarded precondition); MaturityCard=L3 (replicated & benchmarked). Outcome: Admit.
  • Explicit‑RK: requires stiff?=false; with unknownDegrade(sandbox) (probe).
  • Symplectic: eligible only when Hamiltonian=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 requires convex_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 demands service_level≥B (ordinal predicate). With B met but baseline parity unknown ⇒ Degrade(scope‑narrow).
  • Heuristic meta‑search: MaturityCard=L1Degrade(sandbox) or Abstain depending 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)

IDRequirementPurpose
CC-C23.1For each MethodFamily, an editioned MaturityCard SHALL name the exact family and registry edition, evidence profile, claim scope, qualification window, intended use, rung justification, A.10 anchors, and freshness windows; cite a relation and loss note only when the admission claim actually relies on it.Makes maturity auditable without a generic context.
CC-C23.2Each executable SoS-LOG rule declaration MUST cite the exact MethodFamilyId and registry edition, rule and policy editions, Eligibility and CG-Spec verdicts, EvidenceProfile minima, Acceptance verdict, claim scope, qualification window, Γ-fold contributors where used, decision result, and EvidenceGraph path. Relation and loss-policy ids appear only when the branch relies on them.Keeps every decision premise reconstructable.
CC‑C23.3Enumerations used by the rules (Degrade(mode); Maturity rungs) SHALL be closed and UTS‑registered (twin labels).
CC‑C23.4Unknowns in S2 SHALL map to `{degradeabstain
CC-C23.5If a branch relies on an F.9 Bridge, kind relation, or plane relation, it MUST cite that exact obtaining relation, direction, what meaning is preserved and what is lost, receiving use, and applicable loss policy; supported penalties affect R_eff only. A changed family, evidence profile, claim scope, qualification window, or use is not by itself a crossing.Keeps F and G invariant and relation claims truthful.
CC‑C23.6No thresholds in CHR or Maturity; thresholds live only in AcceptanceClauses (G.4).Separation of concerns.
CC‑C23.7MaturityCard SHALL NOT be turned into a global scalar; treat as poset; any ordering MUST be lawful over CHR types.Forbids cross‑scale scalarisation.
CC‑C23.8Publish to UTS with twin labels; run GateCrossing visibility checks on cited crossings: CrossingBundle attestation (E.18/F.9/F.17/E.17/A.21 where live), LanePurity, and Lexical SD (E.10) under GateChecks/GateProfile (A.21).Publication & crossing visibility hygiene.
CC‑C23.9All enumerations (e.g., Degrade(mode), Maturity rungs) SHALL declare a closed value set and Scale kind, and be registered at UTS (LEX enum clarity).Avoids lexical drift; lawful typing.
CC‑C23.10RSCR tests cover negative/refusal paths (illegal CHR ops; CG‑Spec gate fail; Bridge missing; Φ table/policy‑id missing; Lexical SD violations (E.10)); ensure branch coverage (Admit/Degrade/Abstain, unknown).
CC‑C23.11If QD fields are in scope, R0.QD MUST pass: lawful CharacteristicSpaceRef (d≥2, characteristics typed, planes declared per characteristic), ArchiveConfig (topology/resolution/K, InsertionPolicyRef, editioned DistanceDef), EmitterPolicyRef present.QD legality gate.
CC‑C23.12DominanceRegime SHALL default to ParetoOnly; switching to ParetoPlusIllumination MUST be authorised by CAL and cited by id in SCR.Prevents implicit scalarisation.
CC‑C23.13If PortfolioMode=Archive, LOG MUST allow archive outputs (R6) and publish IlluminationSummary as a report-only telemetry metric unless CAL opts‑in to dominance participation.Lawful archive semantics.
CC‑C23.14If GeneratorIntent present, R7 MUST verify EnvironmentValidityRegion and TransferRulesRef; outputs are declared {environment, method} sets; coverage/regret telemetry published.OEE legality & telemetry.
CC‑C23.15On illumination increases/archive changes, edition increments (BehaviorSpace/DistanceDef/EmitterPolicy) and the policy‑id responsible SHALL be logged (R8).Reproducibility & refresh.

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 CallPlan or a CheckpointReturn.

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

  1. Which accepted A.15.7 decision or C.11 ChoiceResult fixed the action or option now being planned?
  2. Does every planned step name an admitted Method, rather than only a vendor route or endpoint label?
  3. Which budget is current: a still-upstream probe budget or an enactment/call budget?
  4. What event stops or replans the route?
  5. 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:

CallPlan:
  decisionBasis:
    situationResponsiveDecisionEpistemeRef?  # A.15.7; only when this plan relies on the retained decision
    fixedOptionChoiceResultRef?               # C.11; only a choose-now result
  objective
  plannedCallsInOrder:
    - methodRef
      methodDescriptionRef?          # only when the route description is needed
      dependsOnPlannedStepRefs?      # only when dependency changes the route
      mayRunInParallelWithStepRefs?  # only when safe parallelism matters
  plannedBudgetEnvelope
  stopOrReplan
  nextPlannedAction
CheckpointReturn:
  decisionBasis:
    situationResponsiveDecisionEpistemeRef?  # A.15.7
    fixedOptionChoiceResultRef?               # C.11 choose-now result
  objectiveOrTaskFamily
  testedMethodRefs
  testedMethodDescriptionRefs?
  evidenceRefs
  burnedBudget
  residualBudget
  recommendedNextAction
  commitTrigger

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

ForceTension
General method vs local shortcutA scalable approach may improve with data or compute, while a narrow route may be safer or cheaper in the present task.
Exploration vs deliveryA bounded probe may reduce uncertainty, while service and cost limits require commitment or stop.
Assurance vs autonomyA named high-consequence use may need a bounded assurance result, while ordinary planning should not inherit assurance apparatus.
Description vs enactmentA callable route description helps planning, but it is not the Method, plan, call, or evidence of performance.

Solution

Local objects and boundaries

  • ATC.CallRouteDescription is a U.MethodDescription for 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.CallPlan is a U.WorkPlan for intended calls. Its steps select Methods and may cite route descriptions.
  • ATC.CheckpointReturn is 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.CallGraphRef cites the applicable G.6 trace 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:

planCalls(
  decisionBasis,
  objective,
  admittedMethodRefs,
  routeDescriptionRefs?,
  budget
) -> CallPlan

revisePlan(
  currentCallPlanRef,
  checkpointOrSignalRefs,
  residualBudget
) -> CallPlan | CheckpointReturn | neighborExit

[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:

CallPlan optional branch fields:
  poolPolicyResultRef?             # C.19; only while live-pool treatment still matters
  emitterPolicyRef?                # C.19; only when this exact versioned profile is used
  scaleClaimProbeResultRef?        # C.19.1 first result
  scaleComparisonResultRef?        # only when the probe selected a bounded comparison
  scaleAuditResultRef?             # only when the probe selected a full Scale-Audit
  blpLocalPolicyRef?               # C.19.1 local policy or analogy, not empirical evidence
  blpWaiverRef?                    # separate from the comparison result
  explore_share?                   # only with the applicable C.19 branch
  risk_bound
  cost_ceiling
  time_ceiling
  stop_conditions
  tie_breakers?
  comparison_tolerances?
  assuranceResultRef?              # only for a named assurance use

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:

CallPlan.causalActionUseSpec?:
  causalUseQuestionRef: CausalUseQuestionRef
  targetCausalityLadderRung: CausalityLadderRung
  causalUseClaimKind: CausalUseClaimKind
  causalActionPolicyClass?: CausalActionPolicyClass
  causalEvidenceDesignRef?
  causalSupportComponentRefs?
  causalUseSupportResultRef?: CausalUseSupportResultRef
  supportedUse
  unsupportedUse

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 now ChoiceResult—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.

CallPlan:
  decisionBasis:
    situationResponsiveDecisionEpistemeRef = patch_action_decision_17
  objective = produce_patch_and_verify
  plannedCallsInOrder =
    - methodRef = InspectRepositoryMethod_4
      methodDescriptionRef = inspect_repo_route_v3
    - methodRef = EditCandidateMethod_2
      methodDescriptionRef = edit_candidate_route_v2
    - methodRef = TargetedTestMethod_7
      methodDescriptionRef = targeted_tests_route_v5
  plannedBudgetEnvelope = {time<=45_minutes, compute<=x2, cost<=y2, risk<=r2}
  stopOrReplan = targeted_tests_fail_twice
  nextPlannedAction = enact_now

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.

CheckpointReturn:
  decisionBasis:
    fixedOptionChoiceResultRef = ci_route_choice_09
  objectiveOrTaskFamily = unfamiliar_ci_failure
  testedMethodRefs = [LogTraceMethod_2, MinimalReproductionMethod_5]
  evidenceRefs = [trace_result_1, reproduction_result_1]
  burnedBudget = 1_probe_cycle
  residualBudget = 2_probe_cycles
  recommendedNextAction = run_minimal_reproduction_once_more
  commitTrigger = reproduction_is_stable_and_required_evidence_is_current

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

  1. Every result cites exactly one accepted decision basis: the A.15.7 decision episteme or the C.11 ChoiceResult that made planning current.
  2. 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.
  3. The plan records time, compute, cost, and risk ceilings plus stop or replan conditions.
  4. 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.
  5. A scale branch first cites one actual C.19.1 probe result, then any selected comparison or Scale-Audit result; a BLP-waiver remains separate from evidence.
  6. Every vendor-bound ATC.CallRouteDescription identifies source scheme, exact edition, intended use, and selected Method; an arbitrary profile, adapter, or Bridge cannot substitute.
  7. 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.
  8. A CheckpointReturn states tested Methods, evidence, burned and residual budget, next action, and commit trigger.
  9. 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.
  10. A causal action-use branch uses the current C.28 question, support-component, and support-result contract and grants no downstream authority.
  11. 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.

ContributionAdopted, adapted, or rejected moveBoundary and trade-off
ToolPlanner, EMNLP 2024, ToolPlanner: A Tool Augmented LLM for Multi Granularity Instructions with Path Planning and FeedbackAdopt: keep path planning, feedback, and replanning explicit instead of hiding them inside one call loop.The gain is replayable route revision; the cost is a plan object. The LLM benchmark does not define universal FPF objects.
PlanningArena, ACL 2025, PlanningArena: A Modular Benchmark for Multidimensional Evaluation of Planning and Tool LearningAdapt: check tool selection, reasoning, user-input interpretation, and execution-relevant constraints separately instead of treating one aggregate score as plan quality.Its scenarios do not set universal weights or safety limits. C.24 keeps only the dimensions that change this plan or checkpoint.
IBM Research, ECAI 2025, From Grounding to Planning: Benchmarking Bottlenecks in Web AgentsRetain with a rejected overread: keep route grounding distinct from plan quality, but reject the claim that planning is always the dominant bottleneck.This preserves a cheap diagnostic split without hard-coding a web-agent bottleneck order.
Aghzal et al., 2026 preprint, Why Do LLM-based Web Agents Fail? A Hierarchical Planning PerspectiveAdopt: separate high-level planning, low-level execution, and replanning; a sound plan does not excuse failed grounding or adaptive control.The result makes the IBM split conditional. It does not make every web-agent layer mandatory in a known fixed route.
DeepPlanning, ACL 2026, DeepPlanning: Benchmarking Long-Horizon Agentic Planning with Verifiable ConstraintsAdapt: retain global budgets, dependencies, or safe parallelism when material, and use the bounded scout and checkpoint cycle for information needed before commitment.Long-horizon benchmarks expose degradation and efficiency trade-offs, but their task schemas do not belong in every ordinary call plan.
C.19.1 current scale-comparison sources and methodAdopt conditionally: use Bitter-Lesson pressure only with the actual probe and a named bearer, scale window, evidence, cost, safety, and uncertainty.Generality is not a winner by label; local policy and waiver stay separate from empirical comparison.

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.1 supplies admitted Method identity; neither decision branch admits a Method merely by selecting an action.
  • The steering Method in A.15.7 is used to reach the situation-responsive decision cited through situationResponsiveDecisionEpistemeRef; when this plan relies on the decision, its episteme has the identity conditions defined in C.2.1.
  • A C.11 ChoiceResult whose result is choose now is cited through fixedOptionChoiceResultRef.
  • C.18 supplies generated candidate or front material, and C.19 supplies PoolPolicyResult or EmitterPolicy only when live-pool treatment still constrains the plan. Neither admits a Method.
  • C.19.1 supplies the scale-claim probe, any selected comparison or Scale-Audit result, and any separate local policy or BLP-waiver; C.24 invents none of them.
  • A.15, A.15.1, A.15.2, A.2.1, and F.6 keep Method, description, plan, Work, performer, and attribution distinct.
  • G.6 supplies the trace representation cited by ATC.CallGraphRef.
  • B.3 supplies one bounded assurance result only when a named assurance use is current.
  • C.28 supplies causal-use support when the plan is used for causal evidence, intervention, policy, fairness, or counterfactual work.
  • C.27 evaluates temporal claims about speed, narrowing, recovery, or stop/replan rate. More calls or faster narrowing is not success by itself.
  • E.23 may use C.24 plans and checkpoints inside improvement Work; C.24 does not restate the improvement loop.
  • E.10.MOVE, E.11.PUR, and A.15.5 recover 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:

  1. Composite families are scalarized illegally. Terms such as resilience, security, or maintainability are treated as if one number exhausted them.
  2. Scope is confused with measurement. A claim's ClaimScope / WorkScope is spoken of as if it were a magnitude rather than a USM set-valued applicability object.
  3. 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.
  4. Guards become unstable. Admission checks silently mix scope coverage, numerical thresholds, mechanism presence, and evidence freshness in one phrase.
  5. Evaluative governing-pattern selection remains underspecified. After C.16.Q repairs a bare quality term, or C.16.P repairs 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

ForceTension
Simplicity vs category hygieneAuthors want one convenient quality label; the framework must still keep CHR, USM, mechanism, status values, and status-use relations distinct.
Comparability vs local applicabilityMeasures should compare legally across contexts, while scope remains context-local and set-valued.
Thin ontology vs practical authoringThe pattern should regularize quality authoring without creating a new heavy kernel family for every -ility.
Endpoint clarity vs expressive breadthSome quality terms really are one characteristic; others are bundles. The endpoint rule must cover both without ambiguity.

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, or Security; 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 one A.22 U.Structure with 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.ContextSlice describing 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.Mechanism realizations, 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-1 If an engineering quality claim is intended as one measurement characteristic, the publisher SHALL bind it to one named U.Characteristic with one declared scale.
  • CC-C.25-2 If 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-3 ClaimScope and WorkScope SHALL remain USM set-valued scope objects; they MUST NOT be treated as ordinal or numeric quality levels.
  • CC-C.25-4 Mechanism or status slots MUST NOT be conflated with Measures[CHR].
  • CC-C.25-5 Any scalar comparison or thresholding inside a Q-Bundle SHALL apply only to declared CHR measures, not to scope slots.
  • CC-C.25-6 When cross-context comparison is current, the publisher SHALL align the exact bundle heads or slots, resolve the two exact F.17 local senses, test the direct F.9 Bridge 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 uses A.10, while B.3 opens only when an actual named assurance claim is current.
  • CC-C.25-7 A materialized Q-Bundle SHALL be recoverable as content of one exact C.2.1 episteme 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

Anti-patternWhat it looks likeHow FPF prevents it
One-number -ilityResilience = 82 with no declaration of what is being measured and what scope/scenario is intended.CC-C.25-2 requires a Q-Bundle when the family is composite.
Scope as metricThe claim treats wider applicability as a higher quality value rather than as a larger USM set.CC-C.25-3 keeps scope set-valued and non-CHR.
Mechanism equals qualityPresence of a mechanism or certificate is reported as if it were the measurement itself.CC-C.25-4 keeps mechanism/status slots distinct from measures.
Collapsed guard proseOne sentence mixes coverage, thresholds, windows, and mechanisms without typed separation.C.25 rewrites the claim into explicit slots and typed guard factors.

Consequences

BenefitTrade-off / Mitigation
Category hygiene. Scope, measurement, mechanism, and status no longer collapse into one term.Slightly heavier authoring structure; mitigation: only composite cases need the full bundle.
Portable comparison. CHR measures compare legally, while scope remains governed by USM set algebra.Authors must declare scales and scope explicitly.
Cleaner gating. Method/work guards can read the same structure without hidden semantics.Requires discipline in separating guard factors.
Better endpoint classification. C.16.Q can terminate in either one characteristic or one Q-Bundle with a clear endpoint pattern.Requires a first-pass endpoint decision during authoring.

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.

Current problem-solving lineWhat it solves wellRemaining limit or effort costC.25 disposition
ISO/IEC 25010:2023 product quality modelProvides a current reference model of nine product-quality characteristics and their subcharacteristics for specification, measurement, evaluation, and acceptance criteria. It prevents one undifferentiated word quality from doing all the work.Its reference taxonomy does not identify one local claim episteme, its exact bearer, use-bounded scope, window, mechanism prerequisite, or evidence reliance. A domain may also need qualities outside its ICT-product boundary.Adopt characteristic decomposition and explicit measures; do not import the taxonomy as a universal bundle schema or bearer identity.
Google SRE Workbook: Implementing SLOs and Alerting on SLOsCouples an indicator and objective to an explicit time window, error budget, stakeholder decision, and actionable response; multiwindow and multi-burn-rate alerts expose the precision/recall and management trade-off.It is a mature service-reliability line, not a general ontology of resilience, security, maintainability, or assurance. It assumes measurement and operational-policy work whose cost is justified only for the receiving use.Adapt the explicit measure/window/action boundary and the rule that engineering effort should match the decision; do not make an SLO or error budget mandatory for every quality family.
NIST SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient SystemsTreats cyber resilience through distinct goals, objectives, techniques, approaches, and design principles for anticipating, withstanding, recovering from, and adapting to adverse conditions. It keeps resilience from becoming one score.The line is security-specific and intentionally broad; applying its life-cycle and risk constructs can be expensive. It does not provide one lightweight local claim identity or universal aggregation law.Adopt the separation of scenario, measures, mechanisms, and outcomes when they are load-bearing; reject a universal resilience scalar and do not copy the full handbook into a Q-Bundle.
OMG SACM 2.3Separates structured claims, argument links, artifact references, counter-evidence, and interchange packages, making an assurance case inspectable across tools.A complete assurance case and its interchange structure can be much heavier than an ordinary quality claim. SACM does not decide which quality contributors make the claim true or whether one bundle guard is admissible.Keep quality claim content distinct from evidence and assurance. Open A.10 or B.3 only on their own trigger instead of embedding an assurance case in C.25.

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.6 for scope algebra, A.6.1 for mechanism references, and C.16 / A.18 for CHR legality.

  • Coordinates with: C.2.2a, A.16.0, A.10 for ordinary reliance on a bounded cross-context use, B.3 only when an actual named assurance claim is current, A.15 for gate use, C.16.P for unresolved characteristic, scale, score, metric, or proxy wording inside a quality-family statement, C.16.Q for overloaded quality or evaluative-characterization wording, C.33, C.34, and C.35 when captured structure, lost structure, preservation, or generated-result adequacy becomes part of a composite architecture quality family, C.17, C.18, and C.19 for adjacent quality-family measures, and F.9 or F.9.1 when 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, or RPO,
  • 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:

  1. identify the exact bearer and the quality-family label used in the claim;
  2. if one measure on one declared Scale carries the claim, state that Characteristic and stop;
  3. otherwise add only the differently typed contributors that jointly carry the claim;
  4. omit scope, window, mechanisms, status, or evidence when changing that slot would change neither the claim nor the receiving action;
  5. identify the enclosing C.2.1 episteme through its claim content, bearer, and effective ReferenceScheme; and
  6. 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:

  1. Is the endpoint shape admissible? One characteristic where one characteristic is live, one bundle where several typed contributors are load-bearing.
  2. Are scope and mechanism slots kept distinct from measures?
  3. Is any summary number trying to replace the bundle?
  4. Would a gate still be auditable if the family label were removed?
  5. If the claim crosses contexts, is bridge work kept in F.9 rather 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:

  1. Decide whether one Characteristic answers the quality question; if it does, stop there.
  2. If several differently typed contributors are load-bearing, identify the bearer and include only those measures, scopes, windows, mechanisms, statuses, or evidence anchors.
  3. If one proxy or this proportional bundle answers the receiving question, stay in C.25.
  4. Open C.26.3 only when the current question concerns a viable region, disturbance, boundary condition, intervention, adaptation cost, or failure mode.
  5. Open C.27 only when rate-change under effort, window, resistance, recovery, or cadence changes the admissible use of a temporal claim. Minimum viability-envelope note:
FieldRequired content
BearerOne exact U.System under A.1 when that System is the subject; or one exact A.22 U.Structure when selected organization is the subject, with independently identified constituents, selected obtaining relations, applied constraints, and one selection-use frame. A service label, team label, or list of system-role kinds and assignment occurrences does not identify the bearer by itself.
Protected promise / functionThe promise, function, use, operating regime, or stakeholder value the envelope protects
VariablesWhich qualities, constraints, resources, risks, or state descriptors define the envelope
Viable region / boundsWhat counts as inside, near edge, degraded, or outside the envelope for this use
Disturbance classWhat perturbation, demand shift, environment change, probe, or boundary condition stresses the envelope
ActuatorsWhat work, design move, policy, boundary change, sensor change, or resource change can move the bearer
Trade-off / lossWhat gets worse, hidden, coarsened, delayed, or made more expensive
Admissible useWhich action, decision, relation, or triage use the envelope reading can carry
Non-admissible useWhich release, audit, assurance, or universal quality claim requiring additional support it does not support
Failure modeWhat it means to leave the envelope or to mistake one proxy for the envelope

Useful outputs:

  • one C.2.1 quality-claim episteme with Q-Bundle-shaped content when the issue is quality decomposition;
  • a C.26.3 envelope-regulation note when probes/actuators/boundary conditions change the admissible viability reading;
  • a C.27 temporal-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.

Working viewValue
Primary readerArchitect, method author, steward, or manager deciding whether QL wording improves a concrete FPF representation.
Primary EntityOfConcernA local use of quantum-like mathematical language in pattern prose or work guidance.
Admissible moveAdmit, select another applicable pattern body, narrow, or escalate the QL wording by ordinary FPF pattern, QL cue, payoff, minimal admissible output, and local stop.
Outside workPhysical quantum claims, general ontology, ordinary uncertainty/complexity, ordinary DDD locality, ordinary compression, and search/regime generation.
What changes in practiceThe writer stops asking "does quantum-like help here?" and asks "what representational mistake does this lens prevent here?"

What this lens buys in practice:

QL supportPractical gain
Probe-aware designDesign a workshop, dashboard, API read, survey, readiness check, or metric publication as a state-shaping interaction when it is not only a readout.
Comparison-frame disciplineNotice earlier that two options, scores, or judgments cannot be compared in one frame without a bridge, coupling, or declared joint-comparison route.
Export humilityStop false cross-context substitution quickly: a carried value, report, or label may not export the same state for the intended use.
Low-recoverability distributed-state readingTalk about team, organization, market, or service-mesh behavior without inventing a group mind and without reducing the state to one report.
Envelope-first viabilityMove from "which single metric wins?" to a viability envelope with variables, sensors, actuators, costs, and failure modes.
Admissible coarsening useUse a cheaper state representation when it helps, while keeping source, loss, admissible use, non-admissible use, and reopen condition visible.

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 universal U.Frame, or a substitute for an effective U.ReferenceScheme.
  • state: the represented condition relevant to the current decision, not a generic new U.State kind.
  • 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:

Risky phraseBetter FPF phrase
Dashboard changed the state.Dashboard publication or use changed work behavior or evidence conditions.
Metric acted as observer.Measurement/publication regime functioned as a probe interaction.
Organization knows.Coordinated work traces support a low-recoverability state reading over a declared collective bearer.
Market is entangled with product team.Ordinary market, feedback, negotiation, and organizational-coupling routes fail; local reads or exports are not admissibly comparable or reusable without declaring the probe, frame, update, or export relation.
Boundary collapsed after workshop.Workshop work selected or created a local boundary reading for this decision window.
State cannot be copied.No faithful-enough export supports the named receiving use under its effective reference scheme and declared loss.
Same metric in two contexts.Same-named results under independently recovered measurement and comparison frames; compare only through an admitted joint-comparison route.
Quantum-like service health.Viability-envelope reading affected by probe, export, or coarsening cue.

Example style:

StyleExample
BadThe team's quantum-like distributed state collapsed after the readiness dashboard observation.
BetterThe readiness dashboard was not a passive read: its publication changed team behavior, so the dashboard result cannot be used alone as pre-publication readiness evidence.
BestApply C.16 to ordinary metric issues and B.3 to release assurance. Retain C.26.1 only for the residual false passive-read issue: dashboard publication changed readiness behavior in window W. Decision diff: do not use the dashboard as sole release evidence; add independent work traces and record non-admissible use.

Informative bilingual translation note:

EnglishPrefer in Russian or bilingual useRisk
probeprobe / пробное воздействие / считывающее взаимодействие"измерение" is too narrow; "зонд" sounds too physical.
state readingчтение состояния / state-reading claim"состояние" without reading sounds ontological.
frameрамка сравнения, probe frame, or model frame"контекст" can collide with bounded context.
instrumentinstrument-like operation / операция-инструмент"прибор" sounds too physical.
distributed statedistributed-state reading"распределённое состояние" sounds like a new object.
faithful-enough exportдостаточно верный перенос для заявленного use"копия" suggests an impossible-copy ideal.

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

ForceTension
Ordinary FPF patterns firstC.11, A.6, F.9, A.15, C.25, C.16, A.10, B.3, C.18, C.19, and A.19 already do real work. QL wording must add only the remaining state, probe, or export cue.
Lightweight use vs claims requiring additional evidenceA local diagnostic note should be cheap; reusable guidance, assurance, physical claims, or superiority claims need heavier evidence and explicit neighboring-pattern selection.
Useful math vs misleading vocabularyQuantum-like formalisms help with order, contextual probability, incompatible probes, instruments, and open information systems; popular quantum words easily overclaim.
Representation cost vs representation lossA cheaper state representation may be the right engineering move, but only if the source, shortcut, loss, admissible use, and reopen condition stay visible.
Recognition vs assuranceWorking readers need fast entry; the assurance section needs enough typed fields to prevent the lens from taking over neighboring pattern work, impossible-copy overread, and hidden ontology.

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:

  1. Name the ordinary FPF pattern that already carries the baseline question.
  2. Recover the exact claim-bearing subject: quality bearer or C.2.1 model-claim episteme, effective U.ReferenceScheme, probe or model frame, comparison frame, and U.ClaimScope; record grounding and viewpoint only through their separately obtaining relations.
  3. 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.
  4. Apply the ordinary subject patterns and retain C.26 only if one named contextual-model obstruction survives and changes the admissible inference or action.
  5. Fill the QL-lite card if that cue survives; otherwise return to the ordinary subject pattern without QL wording.
  6. 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.
  7. 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.

Working viewUse it whenOrdinary output
Recognition noteThe reader only needs to see that an ordinary FPF pattern plus a QL cue may prevent a representational mistake.Five-field QL-lite note, local stop, and next action.
Decision-bearing recordThe QL reading changes a boundary, bridge, work, measurement, viability, or representation decision.Typed fields for carrier, window, rival, loss, minimal admissible output, admissible use, non-admissible use, and neighboring-pattern handoff.
Assurance recordThe claim becomes reusable law, audit and evidence support, release-facing support, empirical-superiority claim, formal reconstruction, or ontology-bearing claim.Evidence graph, measurement relation or assurance relation, source-support relation, rival-model comparison, and explicit escalation outside QL-lite.

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:

Working-reader situationUse
Practitioner or architectThree-to-five-field recognition note plus decision diff.
FPF pattern authorFull card, examples, neighboring-pattern selection, and local anti-cases.
Checking readerPattern-application check plus false-positive and false-negative tests.
Assurance or audit readerFull evidence record with B.3, A.10, and C.16 integration.
Research or formalization readerM3 or M4 formal model, rival models, and empirical or theoretical support.

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:

Checking failureRepair
"QL word appeared, escalate to assurance."Ask what claim and evidence demand are actually being made.
"This sounds metaphorical, remove it."Ask what representational mistake the wording prevents.
"Use ordinary FPF only."Name the ordinary FPF pattern that carries the residual claim.
"No quantum-like unless mathematically formalized."Allow QL-lite when it prevents local false reading and no formal claim is made.
"Everything with feedback is QL."Apply C.16, C.25, or A.15 first to ordinary feedback, control, and metric-gaming cases.

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:

Gate questionApplicable FPF pattern
Is this ordinary boundary, interface, API, or protocol ambiguity?A.6 and the direct boundary or interface pattern.
Is this ordinary Bridge between exact local senses, publication/export, substitution, or declared loss?F.9, publication, representation, and loss-accounting patterns.
Is this ordinary measurement, metric gaming, scale, coordinate, or noise?C.16.
Is this ordinary evidence, provenance, method, or carrier issue?A.10 and, when assurance-bearing, B.3.
Is this ordinary work, routine, incentive, alignment, or authority issue?A.15 and neighboring work/authority patterns.
Is this ordinary quality-bundle, viability, feedback, or dynamics tuning?C.25, U.Dynamics, and measurement or work patterns.
Is this ordinary representation-scheme transition or controlled coarsening?A.6.3.RT, A.6.3.CSC, and ordinary representation patterns.
After the ordinary subject patterns, does one named contextual-model obstruction such as no-global-section, incompatible probe algebra, or order-sensitive instrument behavior still change the admissible inference or action?Use C.26 or the relevant C.26.* child with the minimum sufficient field set; otherwise omit QL wording.

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.

FieldQuestion
Claim-bearing subject and schemeWhat exact quality bearer and ascription, or exact C.2.1 model-claim episteme and EntityOfConcern, is at issue under which effective U.ReferenceScheme?
Claim-use boundaryWhich exact probe or model frame, comparison frame, and U.ClaimScope govern this use? None is a universal context owner.
Grounding and viewpointWhich exact EpistemeEmpiricalGroundingRelation obtains, or is grounding explicitly absent? If viewpoint matters, which U.ViewpointRef resolves to exact P, and which separate evaluator performs the evaluation?
Ordinary FPF patternWhich FPF pattern already carries the baseline question?
QL cue or formal cueWhich order effect, frame effect, incompatible probe structure, response-replicability tension, measurement-changing-state, no faithful-enough export under the declared probe, frame, or use, bridge loss or export loss, mutual interaction whose local reads and exports are no longer admissibly comparable or reusable without declaring the probe, frame, or update relation, open-information-system update whose update rule, probe frame, or export admissibility is part of the modeling condition, or state-representation coarsening effect changes the admissible reading?
Representational payoffWhat mistake does the lens prevent, or what cheaper representation does it support?
Minimal admissible outputWhat may be concluded or done now?
Decision diffWhat would be done incorrectly under the ordinary false reading, and what changes after QL repair?
Local stop or neighboring-pattern handoffWhich use is non-admissible under this card, and which neighboring FPF pattern defines or constrains that use?

Decision diff examples:

False readingQL repairDecision diff
Dashboard passively shows release readiness.Dashboard publication changes readiness behavior.Do not use dashboard alone as release evidence; add independent work traces or redesign metric publication.
Workshop discovered the boundary.Workshop also created the boundary meaning.Do not export workshop result as timeless domain fact; record window, participants, carriers, and unresolved rivals.
Service is healthy because latency is green.Viability envelope is degraded by support load and promise failure.Add envelope variables and actuators; do not greenlight based on latency alone.
Summary preserves architecture state.Summary is a coarsened shortcut with declared loss.Use for orientation only; return to source for release or design lock.

Minimum viable QL-lite note:

Ordinary patterns: C.16 + A.15.
Claim line: exact readiness-ascription claim ReadinessAscription-4 about bearer DeliverySystem-12 under OperationsReferenceScheme; probe/model frame ReadinessPublicationFrame; comparison frame PrePostReadinessFrame; claim scope ReleaseWindow-W.
Grounding and viewpoint: no EpistemeEmpiricalGroundingRelation is yet established; OperationsViewpointRef resolves to OperationsViewpoint-P. Admitted ReleaseEvaluationSystem-7 performs dated ReleaseAssessmentWork-7, enacts ReleaseAssessmentMethod-3, and is holder of obtaining ReleaseEvaluatorAssignment-7, a directly declared ReleaseEvaluatorSystemRoleAssignment occurrence; F.6 states that the System performed the Work under that assignment. If only a non-performing participant in a separate evaluation relation is meant, name that relation and position instead.
Mistake prevented: dashboard result would be read as passive release-readiness evidence.
Probe effect: publication changed team behavior during W.
Decision diff: do not use dashboard alone for release; add independent work traces.
Stop: not a reusable QL model, not assurance evidence, not physical quantum claim.

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.

Mini-outputCluster meaning
Use or choose nowThe low-recoverability reading is enough for the declared local action or decision.
Probe againOne named probe, order/frame test, measurement, source check, or bridge check could still change the result.
RerouteThe question under repair belongs to another FPF pattern rather than QL-lite.
No QL wordingOrdinary uncertainty, measurement, work, bridge, quality, or search patterns carry the case.

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:

Cue familyQL only if
Probe, order, or frameThe operation changes the admissible reading of the output, comparison, or represented state.
Export or bridgeThe export is not faithful enough for the intended use, and ordinary bridge and loss discipline does not fully carry the remaining export/use issue.
Distributed-state readingCoordinated behavior, trace pattern, or work result supports a low-recoverability state reading no single carrier faithfully exports, after ordinary rivals are checked.
Viability envelopeProbe, sensor, actuator, export, boundary condition, or coarsening changes the admissible viability reading.
CoarseningThe reduced-detail state representation depends on a QL cue plus declared loss, admissible use, non-admissible downstream use, and reopen trigger; ordinary compression or abstraction alone is not enough.
Positive activation pressureNegative activation test
------
One named no-global-section, incompatible-probe, order-sensitive instrument, contextual-probability, non-faithful export, or QL-specific coarsening obstruction survives the ordinary subject patterns and changes the admissible inference or action.No QL activation from discreteness, tokenization, low-bit quantization, stochasticity, ordinary uncertainty, nonlinearity, complexity, ordinary coupling, ordinary feedback, emergence, tacit knowledge, ordinary openness, ordinary compression, ordinary coarsening, ordinary DDD locality, ordinary API boundary, ordinary bridge loss, ordinary feedback control, local vocabulary, graph shape, or impressive quantum-like vocabulary alone.

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.

CC-C26-CAUSAL-EXIT:
If the question under repair is intervention, counterfactual comparison,
causal effect, causal fairness, causal policy, or realizability of counterfactual-rung data,
redirect the claim or question to C.28 before retaining QL-lite or QL-NQ.

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.

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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).
  6. 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).
  7. 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).

If the question under repair is mainly...First FPF patternAdd QL only when...
Choice, comparison, or question order[C.11](/generated/patterns/C.11)incompatible probes, order effects, non-shared comparison frames, or no declared admissible joint comparison route change the choice-state reading.
Boundary interaction or interface readingUse the subject pattern selected by step 4 above. In particular, use [A.6.C](/generated/patterns/A.6.C) only when recovered contract, SLA, protocol, or agreement-like wording bundles several contract-side claims, and use [A.6.B](/generated/patterns/A.6.B) only for L/A/D/E boundary-package classification.the probe or interaction changes the represented state, export validity, or viability decision.
Bridge between exact local senses or publication/export[F.9](/generated/patterns/F.9); [E.24.PUB](/generated/patterns/E.24.PUB); [E.17](/generated/patterns/E.17) or [E.17.EFP](/generated/patterns/E.17.EFP) only for the separately current multi-view or explanation-faithfulness questionone named probe/export obstruction survives the exact Bridge, publication, representation, and loss account and changes the admitted receiving use.
Work enactment or coordinated behavior[A.15](/generated/patterns/A.15), with [A.10](/generated/patterns/A.10) / [B.3](/generated/patterns/B.3) for evidencecoordinated work evidences a low-recoverability distributed-state reading not faithfully exportable as one representation.
Measurement, metric, score, or dashboard[C.16](/generated/patterns/C.16), [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3)the measurement regime, publication act, or operational use functions as a probe interaction that updates the represented state.
Viability or quality bundle[C.25](/generated/patterns/C.25), U.Dynamics, [A.6](/generated/patterns/A.6), [A.15](/generated/patterns/A.15)envelope regulation depends on probe, boundary condition, actuator, export, or coarsened state representation.
Candidate generation or option-menu suspicion[B.5.2](/generated/patterns/B.5.2), [C.18](/generated/patterns/C.18), [C.19](/generated/patterns/C.19), [A.19](/generated/patterns/A.19)QL wording only marks that the current frame may be suspect; search patterns generate alternatives.
Representation shortcutCSC, RT, ordinary abstraction, representation learning, POMDP, search-space pruningthe shortcut depends on contextual probability, incompatible probes, instrument-like update, open-information-system update rule, probe-frame, or export-admissibility cue, or lossy state export.

Escalation by evidence or authority demand

Claim-use classUseRequired basis
Ordinary FPF patternQL is not needed.Use the ordinary FPF pattern plainly.
QL-lite noteLocal diagnosis, model note, or worked recognition.Fill the short card and, for a quality ascription or model claim, its one-line identity/use boundary.
Reusable pattern proseA pattern, example, or neighboring note will repeat the move.Add typed state, probe, or export fields, source support, and local anti-cases.
Decision or assurance useThe claim affects boundary, release, audit, evidence, or work decision.Add rival explanations, evidence-use class, loss notes, and explicit neighboring-pattern selection.
Ontology or physical claimA physical substrate, new ontology, or empirical superiority is asserted.This pattern does not support the claim; use a separate physical or empirical support outside this pattern cluster.
For QL claims that carry decision, assurance, ontology, physical-substrate, or empirical-superiority use, compare rival model families before retaining QL as load-bearing. Failure of a simple Bayesian or passive-read model is not yet evidence for QL necessity; it is evidence for trying richer classical, causal, performative, instrument, active-sensing, or representation-abstraction rivals before QL carries the claim:
Rival familyUse firstKeep QL active only when
Classical Bayesian, nonparametric Bayesian, or ordinary probabilistic updateC.11, measurement and evidence patterns, and model-expansion patternsincompatible sample spaces, contextual probability, order-sensitive query structure, or failure of ordinary total-probability composition remains active.
Causal intervention or ordinary world-state change modelA.15, boundary patterns, and evidence patternsthe intervention is also being used as a read, export, comparison, or optimization of the state it changes.
Performative prediction, strategic response, or dashboard-induced behaviorC.16, A.10, B.3, C.26.1, and viability/work patternsinstrument-like state update, incompatible probes, or non-faithful state export remains after the ordinary behavior account is written.
POMDP, active sensing, active inference, or experimental designA.3, C.16, U.Dynamics, and action-cost patternsthe formal claim also involves incompatible probe frames, contextual probability, or state-representation loss.
State abstraction, representation learning, surrogate modeling, sketching, or ordinary compressionA.6.3.CSC, A.6.3.RT, A.19, F.9, and ordinary representation patternsthe shortcut depends on contextual, instrument-like, open-information-system update/probe/export-admissibility, or incompatible-probe structure rather than ordinary abstraction engineering.
Causal abstraction or approximate causal abstractionUse first when the shortcut claims to preserve intervention, explanation, manipulation, or cross-scale structure.contextual probability, incompatible probes, instrument-like update, open-information-system update rule/probe-frame/export-admissibility, or lossy state export remains after the causal-abstraction mapping between source-scale and target-scale states and interventions is stated.

Math reveal sequence:

Mathematical-formality classUseForm
M0 - no mathEveryday FPF use.Plain-language QL-lite note: false passive read, output, admissible use, and stop.
M1 - structural sketchA reader needs to see why ordinary comparison or export fails.Diagram or table: probes, frames, carriers, export loss, unsupported comparison.
M2 - toy formalizationPattern example, education, or contested architecture claim.Small finite-state, matrix, or instrument-like toy model, explicitly non-authoritative.
M3 - decision-bearing formal modelReusable guidance or high-impact decision.Declared assumptions, rival models, validation/evidence, and failure conditions.
M4 - formal assurance / research claimQLP-3 assurance or reusable-law claim.Full formal reconstruction, baseline, proof/data, source constraints, and limitations.

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:

LevelUseRequired content
QLP-0 recognitionExample, teaching case, or local recognition prompt.Claim, example, ordinary FPF pattern, QL cue, and local stop.
QLP-1 local working useLocal architecture discussion, triage, or provisional design reasoning.QLP-0 content plus evidence carrier, time window, uncertainty/confidence statement, and stop/reroute condition.
QLP-2 decision-bearing useBoundary decision, bridge/export use, viability move, work claim, or representation shortcut changes what the team should do.QLP-1 content plus rival explanations, export/loss note when live, minimal admissible output, selected applicable pattern body, admissible use, and non-admissible use.
QLP-3 assurance or reusable guidance useThe claim is used for assurance, audit, durable pattern action guidance or conformance text, reusable relation, name, or measure, or high-stakes decision support.QLP-2 content plus A.10 and B.3 assurance result, C.16 template if measured, documented bridge and loss relation, source-support relation, and explicit local stop or inherited-boundary note.

Recognition case matrix

CaseFirst applicable pattern bodyQL cue to testLocal stop
Domain workshop changes the splitDirect boundary/Work patterns, then F.9 for exact cross-local-sense interpretation and C.26.1 only for a surviving probe obstructionThe workshop is both evidence and intervention; question order or facilitation frame changes the recommendation, team alignment, or exact local sense.Do not replace DDD or direct relation law with QL; keep exact claim scope, reference scheme, local-sense endpoint, and bridge/export loss visible.
Same label in different semantic localitiesF.9, designation, and direct scope or model-use patternsAn admitted probe or export changes operational state, or the carried expression loses load-bearing local sense.Same spelling is not same sense and does not establish a Bridge, grounding relation, joint algebra, or subject crossing.
Organization acts from a latent decisionA.15, A.10, B.3, C.26.2Coordinated Work under exact system-role assignments, records, commitments, traces, and routines evidence a low-recoverability state no participant faithfully reports.Do not infer a group mind or timeless culture.
Survey, dashboard, policy, or API read of cultureC.16, A.10, F.9, C.26.1, C.26.2The probe may change the state it evidences, and the export may lose load-bearing structure.Treat the output as carrier/probe, not as the state itself.
Service boundary under loadC.25, A.6, A.15, C.26.3Viability depends on changing caching, throttling, routing, staffing, protocol, Bridge, or selected model-use boundary.Do not reduce viability to one green metric.
Moving body or sensor to see the missing faceactive or embodied inference accounts, C.26:4.5 state-representation coarsening cardThe system spends energy, time, risk, attention, or coordination to obtain a discriminating observation.Do not call ordinary sensing or active inference quantum-like without a QL cue.
Glass memory / hysteresisC.26.1, C.26.3, U.DynamicsPrior state constrains current response; state history or retained trace changes admissible reading.Do not force dynamics variables unless load-bearing.
Cell-like service or access analogyA.6.P:4.11a, then only the exact boundary, interaction, Work, viability, repair, or other subject pattern needed by the claimCell-like criteria may suggest questions about boundary, controlled exchange, protected invariants, repair, state-continuity, or a resource analogue; they do not make those claims obtain together.Retain the analogy only when one recovered direct claim changes the decision and an ordinary subject pattern does not already carry the residual QL issue.
Suspect option menuB.5.2, C.18, C.19, A.19Current options may be products of the current measurement frame.QL only marks suspicion; search patterns generate alternatives.

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:

Main questionFirst FPF pattern or relation
Coarsened rendering of source episteme or source publication for narrower useA.6.3.CSC
Same-selected-entity representation-scheme or reasoning-medium transitionA.6.3.RT
Cross-context equivalence, substitution, projection, export, or lossF.9 for the Bridge and bounded-use claim; F.9.1 only for an optional stance note about that claim. Keep the lens-specific preserved and lost structure here.
Measurement coordinate, scale, score, result, or dashboard readingC.16
Evidence carrier, provenance, method, support, or time windowA.10
Assurance claim, release support, audit, readiness, or compliance useB.3
Search-space pruning, option generation, or missing alternativesC.18, C.19, A.19
Residual QL state, probe, frame, export, or coarsening cue after those patterns actC.26

Start with this coarsening mini-card:

Mini-entryQuestion
SourceWhich fuller state representation, trace set, model, measurement scheme, or dynamics account loses distinctions in the shortcut?
ShortcutWhich smaller representation is being used instead, and for which bounded decision or action class?
LossWhich precision, distinction, uncertainty, comparability, traceability, or relation structure is lost?
Admissible useWhich bounded decision, probe, comparison, time-window reading, or action class remains admissible for this reduced-detail state representation?
Reopen triggerWhich dispute, drift, failure, threshold crossing, bridge demand, or decision change requires return to the source-bearing episteme or source publication?

For the representation shortcut itself, fill this coarsening card:

FieldQuestion
Source representationWhich fuller model, state space, trace set, measurement scheme, probability model, dynamics model, or representation loses distinctions in the shortcut?
Coarsened representationWhich typed, symbolic, finite, operator-like, Hilbert-like, rough-set, low-bit, or source-loss-affected representation is used instead?
Shortcut mechanismWhich projection, typed-state reduction, finite-dimensional representation, operator-like update, rough-set approximation, state aggregation, compression, or linearization is doing the representational work?
Shortcut purposeWhich bounded decision, probe, comparison, time-window reading, or action class needs the reduced-detail state representation?
What is lostWhich precision, distinction, uncertainty, compatibility, traceability, causal detail, or cross-context relation is lost?
Loss budgetHow much loss is accepted for this decision, probe, comparison, route, or time window?
Admissible useFor which decisions, probes, comparisons, candidate-route selections, or time windows does the shortcut preserve the required distinctions?
Non-admissible useFor which claims, audits, bridges, comparisons, future actions, or high-stakes decisions does the shortcut lack the required distinctions, source support, or recoverability?
Ordinary explanations still activeWhich ordinary abstraction, causal abstraction, approximate causal abstraction, state aggregation, representation learning, POMDP simplification, heuristic compression, CSC, RT, or low-bit implementation account remains sufficient if the QL cue is absent?
Evidence or formal sourceWhich model, trace, experiment, source, or formal argument supports the shortcut rather than merely naming it quantum-like?
Reopen triggerWhich dispute, drift, threshold crossing, failure, audit, bridge demand, or decision change requires consulting the source representation or checking the exact subject assertion under an ordinary FPF pattern?

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.

Declaration fieldQuestion
Baseline representation and costWhat ordinary model or route is too expensive, and by which resource: time, memory, measurement, coordination, latency, energy, risk, attention, cognitive load, privacy, or social cost?
New representationWhich changed representation creates the claimed gain?
MechanismWhich compression, linearization, operator-state update, reduced information-state encoding, shortcut, or approximation mechanism creates the gain?
Claimed gainWhat exactly becomes faster, cheaper, more stable, smaller, or more tractable?
Loss or error budgetWhich precision, expressivity, compatibility, comparability, evidence-support class, traceability, or future-use loss is accepted for the intended use?
Admissible useFor which decisions, probes, comparisons, candidate-route selections, time windows, or action classes does the declared gain meet the required threshold?
Non-admissible useFor which claims, audits, bridges, comparisons, future actions, or high-stakes decisions does the declared gain fail the required threshold?
Ordinary alternativesWhich ordinary compression, approximation, abstraction, feature-engineering, active-inference, search, POMDP, or low-bit route was tried or remains sufficient?
Evidence or formal sourceWhich source, model, trace, worked case, benchmark, or formal analogy supports the claimed mechanism?
Reopen triggerWhich dispute, drift, threshold crossing, failure, audit, bridge demand, or decision change requires consulting the source representation or checking the exact subject assertion under an ordinary FPF pattern?

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:

Dynamics fieldQuestion
Rate or accelerationWhich transition, inference, recovery, sensing, routing, or stabilization rate matters?
InertiaWhat makes the represented state, work routine, boundary condition, or model slow to change?
Damping or resistanceWhat absorbs, slows, filters, or resists the transition?
Effort or actuator capacityWhich action, probe, resource, or authority relation can change the transition fast enough?
EvidenceWhich trace, model, experiment, or operational observation supports the dynamic reading?

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

IDCheck
CC-C26.1The text names the ordinary FPF pattern before admitting QL wording.
CC-C26.2The text states the QL cue as a probe, order, frame, export, comparison, open-information-system update/probe/export-admissibility, or coarsening effect, not as vague complexity.
CC-C26.3The text states a practical representational payoff.
CC-C26.4The text states the minimal admissible output.
CC-C26.5The text states a local stop or neighboring-pattern handoff.
CC-C26.6The text inherits QL-NQ and does not repeat global physical-quantum exclusions as local guidance.
CC-C26.7If a representation shortcut is used, the coarsening card names source, shortcut, loss, admissible use, non-admissible use, and reopen trigger.
CC-C26.8A speed, compression, linearity, or tractability claim declaration names baseline representation and cost, changed representation, mechanism, claimed gain, loss budget or error budget, ordinary alternatives, evidence source or formal source, and reopen trigger.
CC-C26.9If the claim becomes reusable, assurance-bearing, measurement-like, relation-minting, high-stakes, or superiority-claiming, the text escalates beyond QL-lite.
CC-C26.10The text does not mint U.Probe, generic U.State, U.DistributedState, U.Lens, a new boundary kind, or a social-substance kind.
CC-C26.11A cold reader can tell what changes in practice in the first minute.
CC-C26.12Every quality ascription or model claim carried by C.26 names the exact bearer or C.2.1 claim-bearing episteme, effective U.ReferenceScheme, probe/model frame, comparison frame, U.ClaimScope, and the separately obtaining grounding relation or its explicit absence.
CC-C26.13Any viewpoint use has one U.ViewpointRef resolving to exact P; the evaluator, P, and the reference remain distinct.
CC-C26.14C.26 opens only for one named contextual-model obstruction that survives ordinary subject patterns and changes an admissible inference or action; local outputs stay in their own algebras unless an admitted comparison route exists.
CC-C26.15A BoundedModelUseStructure is selected independently for a named receiving use, and any subject crossing has its own exact direct governor and occurrence; labels, cards, diagrams, references, Bridges, and shared participants create neither.
CC-C26-CAUSAL-EXITIf the question under repair is intervention, counterfactual comparison, causal effect, causal fairness, causal policy, off-policy causal evaluation, or realizability of counterfactual-rung data, the text redirects the claim or question to C.28 before retaining QL-lite or QL-NQ.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
Quantum-like as prestige wordThe case is only complex, uncertain, nonlinear, discrete, or hard to measure.Use ordinary FPF patterns. Admit QL only with a declared cue and payoff.
Precautionary suppressionQL wording is rejected because it is unusual, while no ordinary FPF pattern has carried the residual false passive read, false export, false comparison frame, unsupported distributed-state reading, or single-metric viability mistake.Name the ordinary FPF pattern that carries the residual claim. If no such pattern can be named, allow QL-lite at recognition or local-working support condition.
Physical overreadThe text sounds as if organizations, services, or teams are physically quantum systems.Cite inherited QL-NQ; rewrite the claim as mathematical or representational.
Passive dashboardA metric or score is used as a neutral fact after its publication or operational use changed behavior.Use measurement and evidence patterns and, if needed, C.26.1.
Faithful-copy exportA survey, report, API response, or context map is treated as the live state itself.Use bridge/export loss, C.26.2, or ordinary publication patterns.
Speed or compression sloganA shortcut is called fast, cheaper, linear, low-bit, symbolic, or compressed without a declared claim.Write the speed, compression, or linearity claim declaration: baseline representation and cost, changed representation, mechanism, claimed gain, loss budget or error budget, ordinary alternatives, evidence source or formal source, and reopen trigger. Keep the coarsening card only for the representation shortcut itself.
Hidden search problemThe option menu is frame-bound, but the text tries to solve it by naming QL.Use QL only as a suspicion cue; apply search patterns to generation and regime movement.
Cell-like service jumpA service or access bearer is called cell-like because it has a boundary or internal state.Use A.6.P:4.11a to recover only the boundary, controlled-exchange, state, viability, behavior, coupling, resource, invariant, repair, or continuity claim the current decision needs, then use that claim's subject pattern. Do not assemble the possibilities as one service bundle. Retain the analogy only for a residual QL issue that changes the decision.

Near-miss taxonomy:

Near missWhy not QL by itself
Feedback loopOrdinary dynamics/control unless admissible reading, export, or comparison is affected.
Metric gamingOrdinary metric/incentive problem unless measurement publication changes the state reading.
UncertaintyOrdinary epistemic uncertainty unless an exact probe/model frame, comparison frame, or effective reference scheme changes variable identity or comparison law and one named contextual-model obstruction remains.
ComplexityOrdinary complexity unless shortcut, export, or probe issue remains.
CompressionA.6.3.CSC, A.6.3.RT, modeling, or implementation pattern first; QL only for state-representation residue.
DDD bounded-context cueDirect boundary, local-sense, work, and model-use subject patterns first; the label does not identify a universal object or activate QL. Retain C.26 only when a named probe, order, comparison, or export obstruction changes the admissible inference.
Low-bit or quantized implementationEngineering representation first; not QL because it is "quantized".
Collective behaviorA.15, distributed cognition, routines, and evidence patterns first; QL only for low-recoverability state-reading residue.

Cluster conformance scenarios

Use these as quick applicability tests. A good C.26 use leaves one practical output, not just a clever label.

ScenarioExpected routeAvoidExpected output
Dashboard readiness improves because teams optimize the displayed metric.C.16 / A.15 first; C.26.1 only if the output is reused as a passive readiness read after state-shaping publication.Treating the dashboard value as release evidence by itself.Redesign metric publication or add independent work traces before release use.
Workshop "discovers" a boundary but also creates alignment and local meaning.A.6 / A.15 first; C.26.1 for false pre-probe discovery reading.Exporting the workshop result as a timeless domain fact.Record window, participants, carriers, unresolved rivals, and bridge/export limits.
API read warms cache and changes downstream timing.Interface semantics, A.6, and C.16 first; C.26.1 if the read result is reused as passive state export.Saying the API read simply copied state.Mark the read as non-neutral for that timing window or redesign the read path.
Two service health reports use different measurement frames.C.16 / F.9 first; C.26 only if no admissible shared comparison frame remains.Averaging the scores as one posterior-looking value.Name the frame difference and either build an admissible comparison route or stop comparison.
Team survey says "aligned", but incident behavior contradicts it.A.10 / A.15 / B.3 first; C.26.2 if coordinated work traces support a low-recoverability distributed-state reading.Treating survey output as the team state.State a low-recoverability carrier/window-bound reading and the rival explanations.
Market "expects" a feature because many actors change behavior.Declare bearer/traces; ordinary market, incentive, and evidence explanation first; C.26.2 only for residual low-recoverability state reading.Inventing a market mind.Name actor traces, window, rivals, and the least-supported behavior-based reading.
Latency is green while support load and customer promise degrade.C.25 / C.16 first; C.26.3 if viability reading is probe/export/frame/coarsening-distorted.Calling one green metric viability.Add envelope variables, actuators, costs, and failure mode.
Summary compresses an architecture decision for executives.A.6.3.CSC first; no QL unless a state-representation shortcut has QL residue.Treating the summary as full architecture state.Use for orientation only; return to source for release or design lock.
Diagram translates the same system into graph form.A.6.3.RT first; no QL unless incompatible representation, probe, or export cue remains.Calling any diagram a QL state model.Declare representation-scheme change, reasoning-medium change, and source tether.
Low-bit model approximates expensive simulation.Modeling, approximation, compression, or implementation pattern first; QL only if the shortcut claim depends on QL state, probe, or frame admissibility.Treating low-bit or linear form as QL activation.Name baseline, shortcut, loss budget or error budget, ordinary alternatives, and reopen trigger.
Assurance load is raised only because the word "quantum-like" appears.Keep QL-lite unless decision, release, audit, reusable-law, comparative, formal, or ontology-bearing claim exists.Escalating because of vocabulary alone.Keep recognition or local-working support condition, or retire QL if ordinary patterns now carry the residue.
Author claims QL is faster or better than a classical method.Require baseline, metric, mechanism, evidence or formal argument, loss/use declaration, ordinary alternatives, and reopen trigger.Accepting superiority rhetoric.Either write the claim declaration or remove the speed/superiority claim.

QL can also generate better design options:

ProblemQL-inspired design option
Dashboard changes behavior destructively.Delay publication, split private and public metrics, add independent sampling, or publish confidence and loss boundaries.
Workshop creates alignment but masquerades as discovery.Record pre-workshop hypotheses, post-workshop commitments, and created boundary meaning separately.
API read disturbs state.Add non-mutating read, shadow read, sampling window, idempotence declaration, or separate observation channel.
Metrics in two contexts are not comparable.Build a bridge or coupling record or stop comparison.
Summary is overused as source.Add admissible-use label and return-to-source trigger.
Viability scalar hides damage.Build envelope variables and actuators; add a failure-mode sensor.

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.

AI caseRoute
LLM summary of an architecture recordA.6.3.CSC, A.6.3.RT, and A.10 first; C.26 coarsening only if a state-representation shortcut is being overused.
Prompted model evaluation changes model or prompt behaviorC.16 / B.3 first; C.26.1 only if the eval output is treated as a passive model-state read.
Agent work cycle "discovers" requirementsA.15 / A.10 / A.6 first; C.26.1 only if the interaction created the requirement framing.
Synthetic personas "represent market state"A.10 / B.3 first; C.26.2 only if a low-recoverability state-reading claim is carefully bounded with non-admissible use visible.

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:

CriterionGood indicator
Fewer false passive readsDashboards, workshops, API reads, and reports are less often treated as neutral state copies.
Fewer invalid comparisonsSame-named metrics from different contexts are not silently compared.
Better bridge recordsF.9 records more often include admissible export use and non-admissible export use.
Better release and evidence disciplineB.3 and A.10 are invoked only when the claim’s evidence or authority demand requires them.
Less metaphorical leakageFewer field, collapse, entanglement, and group mind phrases appear in normative text.
Faster local notesPractitioners can write QL-lite notes without full audit cards.
More retirementsQL wording is removed when ordinary FPF patterns carry the claim.

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

Pattern claimPractice sourcePattern implication
Mathematical objects can be transferred as modeling lenses without claiming the target domain is made of the source-domain stuff.Wigner on mathematical usefulness, Jaynes on probability as logic of science, and Khrennikov on quantum formalism outside physics.Treat QL as a math-lens transfer card: explain the useful structure first, then state the inherited boundary.
Quantum-like is a mathematical or representational modeling lens, not a physical claim about the modeled system.Basieva, Khrennikov, and Ozawa on quantum-like modeling in biology with open-system and instrument language.Keep QL-NQ as non-entailment, not as the main claim; use detached mathematical modeling where state, probe, or export cue is real.
Linear quantum-like representation can make selected information-state processing more tractable if the representation and loss profile are declared.Basieva-Khrennikov-Ozawa linearity / speed-up / stability arguments and finite-dimensional matrix-calculus discussions.Support the state-representation coarsening card discipline; block blanket "quantum-like is faster" claims unless baseline cost, shortcut, loss, and reopen trigger are named.
Quantum probability is useful where inference is contextual, previous judgments change state, or possibilities interfere, but QL is not automatically the only formal route.Quantum cognition work, quantum-instrument work, and process-theory cautions about classical instrument alternatives.Use QL-lite as useful abstract modeling, not as proof of non-classical necessity.
DDD, microservice, active-inference, and measurement practice already supply ordinary FPF patterns.DDD and microservice domain analysis, active-inference measurement-as-action work, performative prediction, metric-induced behavior.Keep ordinary FPF patterns first; add QL only for the remaining state, probe, export, frame, or coarsening cue.

Selected operational source anchors

This section is intentionally short. It carries operational anchors for using the pattern, not an expanded bibliography.

ClaimSource familyPractical implication
Mathematical formalisms can be transferred as modeling lenses without claiming the target domain is made of the source-domain stuff.Wigner on mathematical usefulness, Jaynes on probability as logic, and Khrennikov's quantum-like modeling line.Treat QL as a math-lens transfer: name the useful structure, the ordinary FPF pattern, and the local stop before any claim requiring additional evidence or authority.
Quantum-like open-system and instrument formalisms can model state and probe interaction without physical quantum ontology.Basieva, Khrennikov, and Ozawa and arXiv, plus Khrennikov on open systems.Keep QL-NQ central and use QL only where probe, instrument, open-information-system update rule, probe frame, export admissibility, or state export cue changes the admissible reading.
Question order, contextual judgment, and instrument-like operations are practical cues, but not automatic proof that QL is necessary.Quantum instruments for question-order effects, Quantum Cognition, and process-theory non-exclusivity.Use QL-lite when order/frame/probe effects change the result; keep classical instrument, Bayesian, causal, and ordinary measurement rivals live.
Same-content-looking measurements under different probe or measurement frames should not be silently treated as the same random variable or as jointly distributed.Contextuality-by-Default.Use C.26 only when the exact frames change variable identity, joint availability, or admissible comparison and a named obstruction survives ordinary measurement and Bridge patterns; otherwise keep those ordinary subject patterns.
Viability and active sensing often mix reading and acting, but ordinary control and measurement patterns remain primary.Free-energy and quantum-cognition link, physiological regulation and FEP, active inference behavior, and smart-building active inference.For viability cases, name sensors, probes, actuators, and envelope variables first; retain QL only for remaining probe, frame, export, or coarsening cue.
Boundary and DDD-locality questions are already disciplined by ordinary architecture practice.Computational boundary of a self, Markov blankets of life, Azure domain analysis, and DDD 2025 SLR.Apply direct boundary, local-sense, work, model-use, interface, and Bridge subject patterns first. If Markov-blanket wording is present, recover its exact claim and subject pattern; retain C.26 only where a named probe, order, comparison, export, or state-reading obstruction remains load-bearing.
Low-bit, tokenized, compressed, geometric, or neural representations may be useful shortcuts without being QL activation.1-bit LLMs, implicit continuity in language models, emergent quantumness in neural networks, and covariant gradient descent.Keep implementation substrate, geometry, compression, and representation shortcuts in ordinary FPF patterns unless a declared QL cue changes the admissible use.
Unknown alternatives and regime movement are search/generation problems, not QL claim authority.Open-endedness and quality-diversity through AI feedback.Use QL only to mark a suspect frame; apply search or regime patterns to generation of alternatives.

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.28 before 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, and C.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 Lens is a pattern label for a modeling lens and modeling discipline, not U.Lens, not QuantumLikeArchitecture, not Quantum Substrate, not Quantum Ontology, and not a universal architecture doctrine.

C.29 mathematical-lens use relation

C.26 is 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 remains QL-NQ. A QL-lite note does not inherit a blank full MathLensUse.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.

Working surfaceValue
Primary readerArchitect, platform lead, domain modeler, or manager judging a boundary read, workshop, dashboard, metric, API read, or bridge result.
Boundary interaction under concernA boundary interaction being used as evidence, export, comparison, or decision input.
Boundary-interaction decision useReplace false passive-read wording or unjustified lossless boundary-to-decision inference with a probe-coupled boundary decision and reroute where needed.
Outside workOrdinary message passing, ordinary causal intervention, ordinary API semantics, bridge loss alone, and generic relation-token minting.
What changes in practiceThe team records what the probe changed before using its output as architecture evidence.

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

ForceTension
Boundary discipline vs probe sensitivityA.6 and F.9 already govern boundaries and bridges; this pattern adds only the state-changing or export-changing probe relation.
Intervention vs readoutMany actions change the world ordinarily. QL is active only when the action is being used as a read, export, comparison, or optimization of the state it changes.
Lean use vs evidence-support classA working team needs a small card; release, audit, or measurement claims need evidence and measurement-governing patterns or records.
Coupling words vs relation tokensWords such as coupling, interaction, and export are plain explanatory wording until A.6.P / F.18 ratifies a reusable relation token.

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:

Mini-entryQuestion
Ordinary governing patternWhich ordinary FPF pattern already carries the baseline boundary, bridge, measurement, work, or viability question?
False passive readWhich reading would be false: "the dashboard, workshop, API read, survey, message, or bridge just reports state"?
Probe effectWhat changed because of the probe, intervention, export, order, frame, or boundary crossing?
Practical changeWhat does the team do differently now: mark probe-coupled, redesign the probe, order, or frame, rewrite bridge or export, add evidence, or apply a neighboring FPF pattern?
Stop or neighboring-pattern handoffWhich use is unsupported by this note, and which FPF pattern carries that use?

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:

FieldQuestion
BoundaryWhich boundary, role relation, authority relation, context bridge, service interface, team boundary, or system edge is crossed or queried?
Probe or interactionWhich workshop, dashboard, API read, metric, meeting, survey, message, event stream, or other typed probe lane is active?
QL cue or formal cueWhich instrument-like update, order sensitivity or frame sensitivity, incompatible-probe structure, no faithful-enough export under the declared probe, frame, or use, or mutual interaction whose local reads and exports are no longer admissibly comparable or reusable without declaring the probe, frame, or update relation makes ordinary passive-read wording false?
False passive readingWhat discovery, neutral observation, one-way transfer, or unjustified lossless-message reading would be false?
Pre-probe hypothesisWhat did the team think the boundary state, alignment, readiness, context cut, or export validity was before the probe?
Observed or inferred post-probe stateWhat changed, stabilized, became visible, became non-exportable, or lost admissible use because of the probe or interaction?
Update class, if load-bearingIs the update a system change, work change, epistemic reading update, carrier update, emitted-output update, formal model update, or update-law change?
State-change evidenceWhich traces, changed decisions, changed labels, changed priorities, behavior shifts, timing changes, or export failures support the state-change reading?
Uncertainty / confidence postureWhat remains inferred, approximate, disputed, probe-dependent, or not yet distinguishable?
State history / memory, if load-bearingState this only when path dependence, order effect, hysteresis, or retained trace changes the current lawful reading.
DecisionWhat changes now: mark probe-coupled, redesign probe, order, or frame, add evidence, rewrite bridge or export, split, merge, orchestrate differently, or apply a neighboring FPF pattern?
Decoupling / redesign optionCan the probe, order, frame, bridge, metric, dashboard, API read, or boundary interaction be redesigned so the needed output is less state-changing or more faithfully exportable?

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:

ResultMeaning
Keep boundary, mark probe-coupledThe boundary remains, but the read/export is no longer treated as passive.
Redesign probe/order/frameThe workshop, dashboard, API read, survey, metric, or question order changes to reduce distortion.
Redesign bridge/exportThe bridge/export gains loss notes, use scope, confidence, and return-to-source path.
Split/merge/orchestrate differentlyBoundary structure changes because the interaction changes the phenomenon.
Apply F.9Only bridge and loss remains live.
Apply C.16The probe is really a standard measurement with declared scale, method, evidence, and result.
Apply A.15The hard part is work enactment rather than probe-coupled reading.
Apply C.25Viability-envelope regulation is primary.

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?

Slice fieldExample content
CaseA product organization considers splitting payment handling out of a checkout bounded context after repeated payment-failure incidents.
Ordinary DDD findingCheckout and Payment use different local meanings for Order.status, PaymentFailure, and Retryable; an ordinary F.9 bridge is needed.
Probe / interventionThe event-storming workshop starts from payment-failure dashboards and asks teams to place incidents by owner, customer impact, and recovery path.
Post-probe readingProduct, Support, and Payment start treating payment failure as a customer-risk gate, not only a technical retry condition.
EvidenceIncident labels are reclassified, escalation changes, backlog priority changes, and the dashboard query is rewritten.
Export lossCopying PaymentFailure = customer risk into both contexts loses the difference between retryable technical failure, promise breach, and support escalation trigger.
Decision outputKeep the split, mark the workshop result as probe-coupled, add F.9 loss notes, and add a payment-risk escalation promise to the boundary design.

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:

  1. Name the boundary or relation being crossed.
  2. Name the probe lane, including the concrete artifact or work act that produced the output.
  3. State the false passive reading: what the team would have assumed if the probe were only a window.
  4. State the pre-probe hypothesis and the observed or inferred post-probe state.
  5. State the evidence carriers and uncertainty posture.
  6. State the export loss, memory, order effect, or frame effect that makes the output not faithful enough for the declared use.
  7. 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.

RoleBoundary-facing question
Observable or output dimensionWhat readiness, status, alignment, failure, response, risk, split, promise, or boundary condition is being read?
Probe methodWhich dashboard, API read, workshop order, survey, canary, incident review, event stream, or meeting format acts on the situation?
Measurement / interaction schemeWhat timing, threshold, sampling rule, question order, aggregation, publication path, or access path shapes the output?
Output or result recordWhat score, label, context map, API response, survey answer, incident class, readiness status, or bridge field was emitted?
State updateWhat behavior, alignment, meaning, trust, priority, escalation, or timing changed because of the probe?
Evidence carrierWhich log, dashboard export, meeting note, trace, decision record, ticket history, context map, or API result carries the output?

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".

Trigger surfaceFirst questionIf yesIf no
"The dashboard shows readiness."Did publishing or using the dashboard change readiness behavior, escalation, staffing, or release posture?Use C.26.1; state probe, update, evidence, and admissible use.Use C.16, A.10, B.3, or ordinary reporting.
"The workshop discovered the boundary."Did question order, framing, participants, or artifacts change local meaning, ownership, trust, or viability?Use C.26.1 with this context-cut worked use slice; add F.9 if bridge/export loss is live.Use ordinary DDD / F.9 bounded-context work.
"The API read returns state."Is the read path state-changing under interface semantics, timing, cache, consistency, or downstream behavior?Use C.26.1 if the result is later treated as a passive read.Use ordinary API semantics, measurement, or data freshness.
"The message transferred the decision."Did the message change authority, trust, escalation, timing, or local meaning enough that copy or transfer is false?Use C.26.1 and apply the relevant work or authority pattern to commitments or authority.Use publication, bridge, or work enactment patterns.
"The split improved viability."Did the split/probe alter the viability envelope being evaluated?Coordinate with C.26.3.Use ordinary boundary, quality-bundle, or architecture patterns.

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

CaseSupported C.26.1 useNear miss and neighboring-pattern handoff
Readiness dashboardThe readiness score changes team behavior: teams stop surfacing borderline failures because the dashboard is watched by release management. The score is probe-coupled evidence, not a passive readiness copy.If the dashboard only reports a well-defined measure with no behavior-changing or frame-changing effect, use C.16 plus evidence patterns.
API consistency checkA "read" through a cache warms entries and changes later latency, so the readout changes the performance state later used in the decision.If the call is simply a mutating operation by interface semantics, use ordinary API/work semantics and say so plainly.
Survey orderAsking "who owns incidents?" before "which context owns payment failure?" changes the resulting context map and escalation plan.If different answers merely reveal unresolved meanings, use F.9 / A.6.P first.
Event-storming workshopThe workshop produces a map and also changes team alignment, local vocabulary, and backlog priority.If it only documents known differences, use ordinary DDD and bridge fields.
Service splitSplitting Checkout and Payment changes recovery paths and support load, so the split is part of the phenomenon being evaluated.If the split only reduces deployment coupling with no probe/export effect, use ordinary boundary and quality patterns.
Incident metricPublishing "cache failover is the primary risk" shifts attention, staffing, and reproduction work.If the metric is only a report of already-carried evidence, use A.10 / B.3.

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.

Evidence postureAdmissible useTypical carriers
QLP-0 recognitionFlag a likely probe-coupled situation for local discussion.Meeting note, dashboard screenshot, issue comment, context-map draft.
QLP-1 local working useChange a local probe/order/frame, bridge note, or boundary decision in a team setting.Before/after labels, changed tickets, changed dashboard query, changed escalation path, changed architecture note.
QLP-2 decision-bearing / reusable usePublish as a repeatable FPF example or organization guideline, or use the reading in a local decision with consequence.Multiple cases, comparison with ordinary routes, named uncertainty, near-miss cases.
QLP-3 assurance or reusable-law useUse in release, audit, contractual, reusable-law, or high-impact decision support.Evidence graph, measurement method, assurance tuple, traceable source references, rival explanation comparison.

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

IDCheck
CC-C26.1.1The boundary, role relation, authority relation, bridge, split, or queried system edge is named.
CC-C26.1.2The active probe or interaction lane is typed as work, method, measurement, speech act, interaction channel, evidence carrier, bridge/export act, or API/service operation; any quantum-instrument wording is recorded only as a modeling analogy unless formalized elsewhere.
CC-C26.1.3Observable, probe method, measurement scheme or interaction scheme, emitted output or result record, update class, and evidence carrier are separated when they carry the claim.
CC-C26.1.4The QL cue or formal cue is named, or the case is handled without QL wording.
CC-C26.1.5The false passive reading or unjustified lossless-transfer reading is stated.
CC-C26.1.6The pre-probe hypothesis and observed/inferred post-probe state are stated without fake precision.
CC-C26.1.7State-change evidence and uncertainty/confidence posture are stated.
CC-C26.1.8State history, memory, path dependence, or order/frame sensitivity is stated when load-bearing.
CC-C26.1.9The state change, export loss, or viability change caused by the probe/interaction is stated.
CC-C26.1.10The output is one of the pattern finish conditions.
CC-C26.1.11The decoupling, probe-redesign, order-redesign, frame-redesign, bridge-redesign, or boundary-redesign option is stated when it could reduce the problem.
CC-C26.1.12The local evidence posture is stated when the claim is reused, contested, or higher consequence.
CC-C26.1.13Ordinary intervention, bridge, work, measurement, and viability routes are tried before QL wording is retained.
CC-C26.1.14Coupling or interaction wording is not minted as a reusable relation token without A.6.P / F.18.
CC-C26.1.15The pattern inherits QL-NQ from C.26 instead of restating the inherited boundary as local law.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
Every interaction is QLAny message, meeting, or API call is called probe-coupled.Require a false passive-read, export, comparison, or optimization use.
Causal action mistaken for probeA deployment or command changes the world, and QL is invoked.Use intervention or work-governing patterns unless the action is being used as a readout of the state it changes.
Bridge loss aloneExport loses local meaning, but no state-changing probe is live.Use F.9 with loss notes.
Context-word driftContext hides source-local meaning, a selected model-use organization, ClaimScope, a probe frame, or a measurement setup.Name the actual value. Retain bounded context only when using the established DDD term.
Relation token leakagecoupledBy(...) appears as if already ratified.Keep it as local drafting form or apply A.6.P and F.18.

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

Pattern claimPractice sourcePattern implicationAdoption stance
A probe or instrument can produce both an output and a state update; the output alone does not specify the operation.Quantum-instrument modeling of question order, response replicability, and QQ-equality.Ask what operation produced both output and update before treating dashboards, API reads, workshops, surveys, or metrics as passive reads.Adapt the instrument/update lesson; do not import a full organization ontology.
Contextual judgment and order effects are common enough to be a practical modeling cue.Quantum Cognition.Treat question order, workshop order, and dashboard framing as possible state-shaping operations when they change the decision.Adopt as a recognition cue with critical limits.
Classical instrument models may explain some sequential-decision data, so QL is useful but not uniquely necessary by default.Quantum-like Cognition in Process Theories: An Analysis.Keep rival routes visible; QL remains a modeling lens, not a necessity claim.Use as non-exclusivity discipline.
A prediction, score, or metric can change the target distribution because people act on it, without requiring a QL probe reading.Performative Prediction.Move dashboard-induced or score-induced behavior to performative-prediction and ordinary measurement, intervention, or work patterns unless a residual incompatible-probe, order, contextual-probability, or instrument-like export support load remains.Adopt as a classical rival path that sharpens when C.26.1 is actually useful.
Boundaries can be modeled by what a system can measure, model, and affect, while mathematical boundary descriptions are not new worldly substances.The Computational Boundary of a Self and The Markov blankets of life.Make the boundary/probe relation explicit without reifying the boundary or coupling phrase.Adapt for boundary-function discipline.
Bounded-context and microservice practice already governs ordinary domain cuts and integration points.Use domain analysis to model microservices and DDD in software development: a 2025 SLR.Use C.26.1 only when the cut, workshop, bridge, dashboard, API extraction, split, or merge changes represented boundary state or export validity.Use DDD as baseline; add C.26.1 only for the probe-coupled support load.

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.18 gives 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.2 when coordinated work evidences a non-exportable distributed state; C.26.3 when 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 Interaction names a boundary and probe relation, not Entangled Boundary, CoupledBy(...), Interaction Field, State-Changing Communication, or a reusable relation token. Relation wording remains local until A.6.P and F.18 ratify 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.

Working surfaceValue
Primary readerArchitect, incident lead, organizational analyst, or manager judging whether coordinated work, behavior, or trace patterns evidence a minimal collective-state reading.
Evidence-bound state readingAn evidence-bound state reading over a declared collective U.System.
Minimal state-reading moveInfer only the minimal carrier-bound and window-bound state claim, name rivals, and state export and probe limits.
Outside workGroup-mind ontology, survey-as-state, timeless culture claims, ordinary routine claims, and formal measurement not governed by C.16.
What changes in practiceThe team can use coordinated work, behavior, or trace patterns as evidence without pretending one report faithfully exports the whole state.

Plain glosses:

  • collective bearer: the declared team, organization, service mesh, market slice, or other U.System whose 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

ForceTension
Work evidence vs explicit reportCoordinated work may provide more direct evidence than any one report, but the report is often the only portable carrier.
Minimal evidence-bound claim vs useful claimThe pattern must say something useful without claiming group mind or durable hidden ontology.
Evidence vs measurementSome cases have formal measures; many have traces, commitments, routines, and artifacts instead.
Export need vs export lossThe state often must be summarized for a decision, but the summary may lose the coordination that matters.
Primary source family vs QL lensDistributed cognition, team cognition, routines, and socio-technical evidence are primary; QL enters only when probe, frame, or export effects are load-bearing.

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:

  1. state what ordinary routines, policies, incentives, shared stimuli, dashboard-following, or copied artifacts explain;
  2. state what the carriers show;
  3. state what residue remains as a minimal state reading;
  4. state what action this residue supports.

Start with this recognition note:

Mini-entryQuestion
Collective bearerWhose coordinated work or behavior is being read: which team, organization, service mesh, market slice, or other declared collective system?
Carriers / windowWhich traces, artifacts, work results, commitments, dashboards, API responses, or records ground the reading, and during which window?
Minimal state readingWhat is the minimal state reading supported by the coordinated work or behavior, or by the trace pattern?
RivalWhich ordinary rival explanation remains live: policy, routine, shared stimulus, dashboard-following, copied artifact, or propagation effect?
Practical changeWhat can be done now without exceeding the evidence: adjust communication, triage, routing, planning, probe design, or return to a fuller evidence record?

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:

FieldQuestion
Collective bearerWhich declared collective U.System is being described?
Observed coordinated work, behavior, and trace patternWhich role-work, service behavior, market participant traces, routine, commitment, artifact use, or coordinated action is observed?
State readingWhich minimal state reading is consistent with the work?
QL cue or formal cue if retained after ordinary work, evidence, or routine explanationWhich probe, export loss, incompatible frame, compound-system decomposition, or no faithful-enough export under the declared probe, frame, and use makes ordinary work and evidence wording insufficient after ordinary explanations have been tried?
Evidence carriersWhich logs, traces, records, commitments, artifacts, dashboards, API responses, or documents ground the reading?
Probe or measurement approximationWhich survey, dashboard, API read, interview, trace query, metric, or publication approximates the state, and how may that probe change, thin, or frame the state reading?
Attempted export and faithful-enough criterionWhat export was attempted, and what would count as faithful enough for the current decision?
Loss cause and higher-fidelity exportWhy is the current export not faithful enough, and could a more discriminating probe, bridge, representation, or time window produce a higher-fidelity export?
Time windowDuring which window does the claim hold?
Persistence postureIs the reading momentary, recurring, stabilized for the incident/release/window, or expected to persist under stated conditions?
Decay and refresh conditionWhat would make the reading expire, refresh, lose support, or need a new probe?
Reprobe costWhat does it cost in time, risk, disruption, attention, coordination, privacy, or evidence quality to check again?
Rival explanation not ruled outWhich ordinary explanation remains possible?
Minimal supported claimWhat may be said without exceeding the evidence, carrier set, time window, or export limit?
Supported action or useWhich planning action, communication action, incident action, routing action, bridge use, evidence use, or decision use may now be taken without exceeding the claim?

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:

ResultMeaning
Minimal evidence-bound state assertionState the collective bearer, observed coordinated work, behavior, or trace pattern, carriers, time window, confidence posture or assurance posture, rivals, and export limit.
Export-loss repairKeep the state reading minimal and add a bridge or publication note about what the attempted report, survey, API response, dashboard, or policy sentence lost.
Probe-coupled neighboring-pattern handoffApply C.26.1 when the survey work, dashboard publication or use, interview, API operation, or publication act changed the state being evidenced.
Measurement or evidence neighboring-pattern handoffApply C.16, A.10, or B.3 when the main support requirement is scale, method, evidence, assurance, or audit posture.
Work or authority neighboring-pattern handoffApply A.15 or the relevant authority or work pattern when a command, routine, incentive, or playbook explains the coordination without remaining export or probe support requirement.
No EDSE claimDrop the distributed-state wording when the carriers, window, rivals, or minimal admissible output cannot be stated.

Rival explanation rule

Before using this pattern, name the principal ordinary rivals:

RivalRepair
Policy, command, coercion, or management pressureUse work-claim or authority-claim patterns unless export or probe loss remains live.
Shared incentive or common external stimulusKeep the claim as parallel response if that explains the coordination.
Routine, habit, script, or playbookState the routine; avoid current-state wording that requires additional evidence.
Dashboard-following, metric gaming, or social desirabilityUse C.26.1 and evidence patterns for probe-caused change.
Copied artifact, template, policy sentence, or API responseUse F.9, E.17 publication, or bridge loss before EDSE.
Diffusion, contagion, media amplification, or signalingUse the appropriate propagation or evidence pattern and keep only the remaining work-enacted state claim.

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.

FieldQuestion
Whole systemWhich collective U.System is being read, and under what boundary?
SubsystemsWhich teams, roles, services, markets, routines, artifacts, or work lanes are locally readable?
Local state readingsWhat can be said about each part without inventing a shared inner representation?
Correlation or coordination evidenceWhich traces, timing, work transfers, commitments, artifact uses, or role-work alignments show coordination?
Factorable partWhich part of the behavior is explained by policy, routine, shared stimulus, incentive, dashboard following, or copied artifact?
Coordination residueWhat remains as a minimal distributed-state reading after the ordinary rival explanations are named?
Minimal supported claimWhat evidence-bound claim survives for the declared time window and carrier set?
Supported action or useWhich planning action, communication action, incident action, routing action, bridge use, evidence use, or decision use may now be taken without exceeding that minimal claim?

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:

  1. Name the collective bearer as a declared U.System boundary, not a bare social label.
  2. 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.
  3. Name the evidence carriers through A.10 so the reading is inspectable.
  4. State the time window, persistence support, decay/refresh condition, reprobe cost, and ordinary rival explanations.
  5. Name the candidate state reading only as a minimal evidence-bound U.Episteme reading.
  6. State the attempted export and what it lost.
  7. State the minimal supported claim, the supported action or use it carries now, and the other uses that remain unsupported by this reading.
  8. Add B.3 assurance 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:

EnactedDistributedStateEvidence(
  collectiveBearer = ...,
  boundary = ...,
  observedCoordinatedWork = ...,
  evidenceCarriers = ...,
  probeOrExport = ...,
  timeWindow = ...,
  persistenceSupport = ...,
  ordinaryRivals = ...,
  factorablePart = ...,
  coordinationResidue = ...,
  exportLoss = ...,
  minimalSupportedClaim = ...,
  boundedActionSupported = ...,
  unsupportedUse = ...
)

The syntax is illustrative. The content is not optional when the state reading is used for a decision.

Well-formedness constraints:

  • collectiveBearer is a declared collective system, not a metaphorical subject.
  • evidenceCarriers are inspectable publication units, traces, records, commitments, logs, or work-result records.
  • timeWindow bounds the claim; persistence beyond that window needs its own support.
  • ordinaryRivals include at least the principal policy, incentive, routine, shared stimulus, dashboard-following, copied-artifact, or social-desirability explanation that could explain the same coordination.
  • minimalSupportedClaim states only what survives after rivals and export loss are named.
  • unsupportedUse names 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:

ObjectRole in the claim
Enacted workWhat people, services, routines, artifacts, or market participants actually did in coordination.
Evidence carrierThe log, trace, ticket, meeting note, deployment record, dashboard export, report, API response, or policy text that makes some part of the work inspectable.
Probe / approximationThe survey, dashboard query, interview, trace query, report request, metric, or publication act that frames the state reading.
Distributed-state readingThe minimal U.Episteme claim inferred from coordinated work or behavior under carriers, window, rivals, and export limits.

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

CaseSupported C.26.2 readingNear miss or neighboring-pattern handoff
Incident release freezeTeams stop releases, prepare rollback evidence, redirect support work, and change escalation before a written decision appears.If a manager issued a clear command and the work merely followed it, use work and authority patterns with evidence, not EDSE.
Service-mesh throttling regimeRoute changes, saturation traces, retry patterns, and on-call routines show a coordinated throttling state under policy P.If one controller rule fully explains the behavior, state the rule and use ordinary system/dynamics evidence.
Market expectation shiftPricing, support inquiries, partner messages, and risk notes move together after a public signal.If media amplification or common stimulus explains the movement, keep only that propagation/evidence claim.
Team "already decided" postureBacklog changes, review comments, and role assignments show that the team is acting under an unstated decision.If the claim is only a vibe or a few statements, do not use EDSE; gather carriers or keep it as informal observation.
Survey of cultureSurvey answers conflict, but work traces show a stable escalation habit.Treat the survey as a probe and possible export loss; do not make it the state itself.
Dashboard-following organizationTeams coordinate around the public metric after the metric becomes visible.Apply C.26.1 for probe-caused change; EDSE may carry only the residual coordinated-state reading.

Evidence posture and confidence

EDSE claims become useful when the text says how much consequence the evidence can carry.

Evidence postureAdmissible useAdditional support requirement
QLP-0 recognitionFlag a possible enacted state for discussion or triage.Name bearer, work, carriers, and time window.
QLP-1 local working useAdjust local planning, incident response, or communication.Add rivals, export loss, persistence, and reprobe condition.
QLP-2 decision-bearing / reusable usePublish as a repeatable example or internal practice, or let the reading change a bounded decision.Add case comparison, near misses, and evidence-carrier discipline.
QLP-3 assurance or reusable-law useUse for release, audit, legal, accountability, reusable-law, or high-impact allocation.Apply A.10, B.3, C.16, and the relevant authority or work patterns.

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

IDCheck
CC-C26.2.1The collective bearer is a declared U.System or collective system, not a bare group label.
CC-C26.2.2Observed coordinated work, behavior, and trace pattern is named.
CC-C26.2.3Evidence carriers and time window are named.
CC-C26.2.4The QL cue / formal cue is named if QL wording is retained.
CC-C26.2.5Persistence class, decay or refresh condition, and reprobe cost are named when the claim is not momentary.
CC-C26.2.6The minimal supported claim is stated.
CC-C26.2.7At least one substantive ordinary rival explanation is named.
CC-C26.2.8The compound-state decomposition separates whole system, subsystems, local readings, factorable part, and coordination residue when the distributed-state reading is load-bearing.
CC-C26.2.9Any survey, dashboard, report, API response, or policy sentence is typed as representation, carrier, or export, not as the distributed state itself.
CC-C26.2.10Probe / measurement approximation, attempted export, faithful-enough criterion, loss cause, and higher-fidelity export possibility are stated when export or measurement carries the claim.
CC-C26.2.11Export loss is stated when the claim depends on export that is not faithful enough for the declared use.
CC-C26.2.12The evidence posture is stated when the claim is reused, contested, or higher consequence.
CC-C26.2.13Formal measurement uses C.16; evidence and assurance use A.10 or B.3; bridge loss uses F.9.
CC-C26.2.14The pattern inherits QL-NQ from C.26 and does not mint U.DistributedState.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
Group mind claimThe text says the team, market, service, or organization knows or wants something.Rewrite as an evidence-bound state reading over a collective bearer during a window.
Survey-as-stateA survey answer is treated as the distributed state.Treat the survey as probe result, emitted output, or evidence carrier and ask what it lost or changed.
Tacit skill overreachA tacit skill or team vibe is called distributed state.Require coordinated work, carriers, time window, and rival explanations.
Routine mistaken for stateA playbook explains the action, but the text claims latent alignment.Name the routine and keep the claim requiring additional evidence out.
Timeless cultureA momentary observation becomes a durable culture claim.State window, persistence support, decay, and reprobe condition.

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

Pattern claimPractice sourcePattern implicationAdoption stance
Coordinated work can evidence state-like organization without reducing that state to one participant report.Representing distributed cognition in socio-technical systems, team cognition, shared mental models, transactive memory, organizational routine dynamics resources, work traces, and socio-technical systems.Make these the primary grounding; infer only minimal evidence-bound state readings from carriers, traces, and work.Adapt as primary non-QL grounding.
Probe/export conditions can change or thin the state reading.Quantum-like modeling in biology with open quantum systems and instruments / arXiv and Open Systems, Quantum Probability, and Logic for Quantum-like Modeling in Biology, Cognition, and Decision-Making.Activate QL only when probing, formalizing, exporting, or bridging changes or loses load-bearing structure.Adapt as secondary modeling support.
Contextual judgment and previous judgments can alter the state being reported.Quantum Cognition.Treat surveys, interviews, reports, and dashboards as possible probes of enacted state, not faithful copies by default.Use as probe/export caution with ordinary evidence routes.
Some sequential data can be carried by classical instrument models.Quantum-like Cognition in Process Theories: An Analysis.Keep non-necessity visible: EDSE is a useful FPF evidence pattern, not proof that only QL formalism works.Use as rival-model discipline.
Carrier plurality is normal in operational evidence.Observability, incident-management, audit, work-trace, and assurance practice.Use logs, traces, dashboards, meeting records, commitments, artifacts, and operational changes as carriers, not as faithful copies of the whole state.Adopt through A.10 / B.3 routes.

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.1 when the probe changes the state being evidenced; C.26.3 when 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 Evidence names an evidence-bound U.Episteme reading over work carriers, not Distributed Mind, Collective Consciousness, Social Field, or Organization 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.

Working cardValue
Primary readerArchitect, platform lead, reliability lead, product manager, or operations lead preserving viability under changing conditions.
Primary EntityOfConcernThe exact viability bearer: either one System with its A.1 identity, one A.22 U.Structure identified by its four discriminators, or another truthful subject with its direct identity rule. The primary result is a C.2.1 episteme about that bearer, not a plan or the writing card.
Admissible movePoint the local viability-bearer position to that exact object and record the pattern used to identify it; then name envelope variables, disturbance, sensors/probes, candidate interventions, boundary condition, adaptation cost, and failure mode.
Outside workOne-metric quality tuning, generic control theory, biological proof, full FEP doctrine, and ordinary feedback without an envelope/boundary claim.
What changes in practiceThe team stops treating one dashboard value as viability and designs the actual envelope-regulation move.

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.22 U.Structure from 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 governed U.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.
  • service or 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; a U.MethodDescription or policy episteme; a proposed setting change; a U.WorkPlan; an access or permission claim; or a Bridge proposal or description. Separately identify any dated U.Work, independently grounded U.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

ForceTension
Bundle vs scalarViability usually concerns a bundle, but dashboards often expose one or two proxies.
Stability vs changeThe system may preserve function by changing internal settings, external environment, boundary conditions, or operating regime.
Sensing vs interventionA measurement value is not a change or Work. Its use may report, probe, or participate in a separately grounded behavior-changing Work, interaction, or governance claim.
General envelope regulation vs optional QL coordinationUse C.26.3 for the envelope-regulation claim and C.25, U.Dynamics, A.6, A.15, and C.16 for its exact constituent claims and objects. Add C.26 / QL only when a probe, frame, export, coarsening, order, or incompatible-representation issue remains load-bearing.
Light use vs dynamics detailRate, inertia, damping, latency, and effort of the recovered intervention object or resulting change matter only when load-bearing.

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:

Mini-entryQuestion
Viability bearerIs it one System with its A.1 identity, one A.22 U.Structure with exact constituents, selected obtaining relations, applied constraints, and a named selection-use frame, or a population/market slice with its own declared basis? A list of system-role kinds and assignment occurrences is not a bearer.
Protected promise / functionWhich U.PromiseContent, stakeholder value, function, operating regime, commitment payload, or delivery promise is protected?
Envelope variablesWhich two to five variables matter, rather than one comfort scalar?
DisturbanceWhat pushes the exact object in the local viability-bearer position outside the declared envelope?
Sensor / probe / candidate interventionWhat reads the situation? What change is proposed, which exact object carries that proposal, and what actual Work, transformation, relation, or resulting state exists, if any?
Trade-off / failureWhat gets worse, what cost is paid, and what failure would show the envelope move did not work?

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:

FieldQuestion
Viability bearerIs it one System with its A.1 identity, one A.22 U.Structure with exact constituents, selected obtaining relations, applied constraints, and a named selection-use frame, or a population/market slice with its own declared basis? A list of system-role kinds and assignment occurrences is not a bearer.
Protected promise / functionWhich U.PromiseContent, stakeholder value, function, operating regime, commitment payload, or delivery promise is protected?
Current service/access claims, if anyWhich independently governed service/access claims are current, and what exact subjects, relations, and subject patterns do they name?
Envelope variablesWhich characteristics or quality-bundle dimensions define viability?
Viable region / boundsWhat counts as inside, near edge, degraded, or outside the envelope for this use?
QL cue or formal cue if retainedWhich probe, order, export, coarsening, incompatible-frame, open-information-system update law, probe-frame relation, export admissibility, or measurement-changing-state cue remains after ordinary viability patterns are active?
DisturbanceWhat pushes the exact object in the local viability-bearer position outside the declared envelope?
Sensors / probesWhich metric, dashboard, alert, health check, review, trace query, observation setup, or probe reads the envelope, and can it change behavior or hide unmeasured dimensions?
Candidate intervention and recovered direct objectWhat change is proposed? Recover whether the proposal concerns a Method or description, setting proposal, U.WorkPlan, access or permission claim, or Bridge proposal or description. Separately identify any dated U.Work, independently grounded U.Transformation or other actual change, obtaining relation occurrence, or resulting state already claimed to exist. Which exact objects are current, and under which subject patterns?
Boundary condition preserved / changedWhich access, ownership, context, interface, promise, or environment condition matters?
Trade-off conditionWhich envelope dimension is protected, relaxed, delayed, made more expensive, or deliberately held constant?
Adaptation costWhat is spent, delayed, damaged, risked, or made harder by the adaptation?
Failure modeWhat breakdown, drift, unsafe persistence, or loss of viability shows that the move failed?

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:

ResultMeaning
Envelope-regulation claimWrite one C.2.1 episteme whose EntityOfConcern is the exact viability bearer and whose ClaimGraph states the protected promise/function, envelope variables, viable region/bounds, disturbance, sensors/probes, candidate interventions, boundary condition, trade-off condition, adaptation cost, and failure mode. Its effective ReferenceScheme supplies the reading context.
Candidate-intervention recovery or redesignRecover the direct object first. Revise only the current proposal—its Method or description, setting proposal, WorkPlan, access or permission claim, or Bridge proposal or description—and identify any dated Work, actual change, obtaining relation occurrence, and resulting state separately. A fixed F.9 Bridge is not an intervention object: after an endpoint sense or profile changes, test another F.9 candidate and identify it only if the predicate obtains.
Measurement/probe redesignRedesign a dashboard, alert, health check, readiness score, or review process because it distorts the envelope it reports.
Neighbor coordination without QLKeep the C.26.3 envelope-regulation claim and use C.25, C.16, A.6, A.15, U.Dynamics, C.18, C.19, or A.19 for the exact neighboring objects and claims. Omit C.26 / QL when no QL cue is load-bearing.
No envelope claimDrop the viability-envelope wording when the exact object for the local viability-bearer position and the pattern used to identify it, protected promise/function, viable region/bounds, disturbance, candidate interventions, adaptation cost, and failure mode cannot be stated.

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.

Anti-patternWhat goes wrongRepair
Metric-as-envelopeA proxy is treated as the whole envelope.Recover the exact object filling the local viability-bearer position and the pattern used to identify it, protected promise, full envelope, unmeasured dimensions, and admissible use.
Goodharted viabilityActors optimize measured slots while damaging unmeasured survivor relations or future adaptability.Treat probe-caused behavior with C.26.1; add evidence for unmeasured envelope dimensions.
Intervention overfitA proposed or enacted move preserves one parameter while pushing another cost, latency, boundary relation, or promise outside bounds.Add the trade-off condition, authority, latency, adaptation cost, and failure mode; recover any Method, description, plan, Work, change, setting, or relation under its subject pattern.

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:

  1. 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.Structure through 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.
  2. Name the envelope variables and the viable range or qualitative boundary for each.
  3. Name the disturbance or regime change.
  4. Name sensors/probes and say whether they only report, also frame, or also change behavior.
  5. 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.
  6. State the boundary condition being preserved or changed.
  7. State the trade-off condition and adaptation cost.
  8. State the failure mode and re-probe/destabilization condition.
  9. 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.

exact object in the local viability-bearer position and pattern used to identify it: ...
protected promise or function: ...
envelope variables: ...
viable region: ...
disturbance: ...
sensors or probes: ...
candidate intervention and recovered direct object: ...
authority and latency for the applicable Work, setting change, or relation: ...
boundary condition: ...
trade-off condition: ...
adaptation cost: ...
failure mode: ...
re-probe or destabilization condition: ...

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.Structure has 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.

ItemViability-facing question
Envelope variableWhich quality, resource, promise, risk, or operating dimension is inside/outside viable range?
SensorWhich metric, alert, trace, health check, survey, review, or observation reports part of the envelope?
ProbeWhich measurement setup, dashboard, readiness check, review, experiment, or incident query may change behavior or expose hidden dimensions?
Candidate interventionWhat change is proposed? Recover whether cache, throttle, routing, staffing, protocol, escalation, access, bridge, or context-split wording denotes a Method or description, setting proposal, plan, 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 claimed to exist.
Boundary conditionWhich access, ownership, context, interface, promise, environment, or information constraint shapes the envelope?
Adaptation costWhich latency, risk, effort, attention, support load, compliance exposure, energy, trust, or future flexibility is spent?

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:

ReadingUse whenPractical output
Scalar quality repairOne characteristic or Q-bundle dimension is enough.Apply C.25, measurement patterns, or evidence patterns as appropriate.
Homeostatic envelopeThe target is to keep a bundle inside a stable range under disturbance.State variables, range, disturbance, sensor, candidate intervention with its recovered direct object, and failure mode.
Allostatic envelopeFunction is preserved through one or more separately governed changes.State the proposal's exact Method or description, setting proposal, WorkPlan, access or permission claim, or Bridge proposal or description; separately state any dated Work, actual transformation or other change, obtaining relation occurrence, resulting state, and moved cost.
Probe-coupled viabilityThe measurement, dashboard, review, or readiness check changes the envelope it reports.Coordinate with C.26.1.
Enacted viability stateCoordinated work evidences the envelope state better than one report.Coordinate with C.26.2.

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

CaseSupported C.26.3 readingNear miss / reroute
Checkout cache under spikeCache aggressiveness preserves latency but increases stale payment-failure status and support load.If only cache latency is at issue, use ordinary performance and quality-bundle patterns.
Smart-building energy controlEnergy, comfort, privacy, occupancy, and abrupt weather changes form one envelope with sensors and candidate interventions recovered under their subject patterns.If the case only tunes one thermostat setting, use ordinary control/measurement language and state any actual setting change separately.
Incident staffingA proposed staffing intervention may preserve recovery time while increasing coordination overhead and error risk; recover whether the proposal concerns a Method or description, staffing or assignment-setting proposal, or WorkPlan. Separately identify any dated staffing Work, changed assignment relation, other actual change, or resulting state claimed to exist.If staffing is merely a work-allocation issue, use A.15 and planning patterns.
Compliance exposureA fast remediation path lowers outage time but increases evidence gaps and audit risk.If audit evidence is primary, apply A.10 or B.3; keep C.26.3 only for envelope trade-off.
Service boundary splitSplitting a service may reduce deployment coupling while changing endpoint senses and increasing operational support-transfer cost.If only cross-local semantic correspondence is at issue, resolve the exact senses and test the resulting F.9 candidate; if the split changes the viability envelope, use C.26.3.
Body-temperature analogyFunction may be preserved by clothing, room air, activity, or exposure, not only internal heat production.Use only as explanatory analogy; do not make biology the proof for software.

Source-to-pattern translation

Allostasis, active inference, FEP, Markov blankets, and computational-boundary sources are useful here only after translation into FPF architecture terms:

Source-side termFPF-facing translation
HomeostasisKeep one parameter or bundle inside viable bounds.
AllostasisPreserve function through one or more separately governed changes to settings, environment, boundary condition, or operating regime; the source term does not determine Method, description, plan, Work, transformation, relation, or resulting state.
Active inference / perception as actionMeasurement, sensor placement, and action have cost and can change later state estimates.
Markov blanket or computational boundaryStatistical or probabilistic boundary-lens cue only after recovery. Accepted local Markov dynamics stay with A.3.3; lens use stays with C.29, and C.26 or C.26.3 stays current only when quantum-like, probe, frame, viability, or measure-model-act claims remain. Physical boundary, interface module, component, functional element, boundary description or publication, and agency threshold require their subject patterns; Markov wording does not admit them by itself.
Criticality / metastabilityStability may be regime-bounded and fluctuation-bearing, not one final fixed point.
Expected free energy / precision controlInformation gathering, action, and confidence have cost; use only when those costs change the architecture decision.

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

IDCheck
CC-C26.3.1The viability bearer is one exact System under A.1, one exact A.22 U.Structure under all four identity discriminators, or another exact subject under its direct identity rule; the local position introduces no kind, relation, or configuration object.
CC-C26.3.2The protected promise or function is named.
CC-C26.3.3Envelope variables or quality-bundle dimensions and the viable region / bounds are named.
CC-C26.3.4Disturbance class and scenario/window are named.
CC-C26.3.5Sensors/probes and their possible behavior-changing or dimension-hiding effects are named when measurement carries the envelope claim.
CC-C26.3.6Each candidate intervention is recovered as a proposal about an exact Method, description, setting proposal, WorkPlan, access or permission claim, or Bridge proposal or description; dated Work, actual change, obtaining relation occurrence, and resulting state remain separate. A fixed F.9 Bridge is never the object revised or ended by Work; an endpoint/profile change opens a new candidate that must pass F.9 independently.
CC-C26.3.7Boundary condition, trade-off condition, and adaptation cost are stated.
CC-C26.3.8Failure mode and re-probe/destabilization condition are stated.
CC-C26.3.9Metrics or dashboards are not treated as the envelope itself.
CC-C26.3.10The QL cue / formal cue is named if QL wording is retained.
CC-C26.3.11QL wording appears only when probe, order, export, coarsening, or incompatible frame interaction remains load-bearing.
CC-C26.3.12Rate/inertia/damping/effort and second-order dynamics variables appear only when load-bearing.
CC-C26.3.13Homeostasis, allostasis, active inference, and Markov-boundary wording are restored into FPF subject patterns before they carry the claim; Markov-blanket wording does not by itself create boundary, interface, component, agency, or viability authority.
CC-C26.3.14The pattern does not mint ViabilityParameter, HomeostasisOntology, or a new control ontology.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
One metric as viabilityAvailability, latency, or score stands for the whole envelope.Add the exact object filling the local viability-bearer position and the pattern used to identify it, protected promise, other dimensions, and failure mode.
Fixed setpoint thinkingStability means one variable must never move.Ask whether allostasis preserves function by changing settings, environment, boundary, or regime.
Passive sensor assumptionA dashboard is treated as neutral even after it changes behavior.Use C.26.1 and evidence patterns.
Candidate intervention without a recovered object, predicate, or applicable authorityThe text recommends a change without recovering its proposal-side Method, description, setting proposal, WorkPlan, access or permission claim, or Bridge proposal or description; fails to identify separately any dated Work, actual transformation, obtaining relation occurrence, or resulting state on which it relies; or claims Work no system can perform in time.Recover the proposal-side object first; identify every actuality separately under its subject pattern; state authority and latency only for the applicable Work, change, or relation.
Biological proof jumpHomeostasis or FEP language is used as proof for software or organizations.Treat it as modeling discipline and apply existing FPF patterns to claims.
Markov-blanket collapseA statistical separation, physical interface, interface module, functional element, component, boundary description, and agency threshold are all called the Markov blanket.Split the source phrase through A.6.RSIR: use C.29 or C.26 for lens use; use A.1 plus the direct relation pattern for holon delimitation or boundary crossing; use A.6.P, A.6.0, and A.6.5 for relation, signature, or slot claims; use A.6.M for module-interface claims; use A.6.F for functional claims; use A.14, C.13, or B.3.5 for component claims; use C.30.AD or E.17 for descriptions; use A.13, A.19, or C.16 for agency-threshold claims.

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

Pattern claimPractice sourcePattern implicationAdoption stance
Viability maintenance is not fixed-value homeostasis only; stability can be relational, variational, dynamic, allostatic, metastable, and resilient.Conceptual foundations of physiological regulation incorporating the free energy principle and self-organized criticality.Use viability envelopes and stability-through-change; reject one-scalar optimization and "all architecture is homeostasis."Adapt as architecture-facing envelope discipline.
Action and perception are coupled under partial observability and cost.Active inference as a theory of sentient behavior.Treat sensors, probes, dashboards, and source-labelled actuators as relevant to the envelope claim when they change behavior or viability; recover each candidate intervention as its exact FPF object before relying on it.Adapt for measurement-as-action and planning cost.
Active-inference engineering already appears in energy/building control under privacy, partial observability, evolving conditions, and abrupt changes.Active Inference for Energy Control and Planning in Smart Buildings and Communities.Use engineering examples cautiously: they show the kind of control problem, not settled FPF doctrine.Use as emerging engineering anchor.
Boundaries can be statistical or computational descriptions of what a system can measure, model, and affect.The Computational Boundary of a Self and The Markov blankets of life.Name boundary conditions and information constraints without reifying a boundary substance.Adapt with map-territory caution.
Excess Bayesian / active-embodied inference shows the cost of moving sensor, body, instrument, or access point to obtain a discriminating observation.Connecting the free energy principle with quantum cognition.Treat probe placement, access placement, and observation cost as part of viability-envelope work when they change the decision.Adapt for probe/action cost, not as a replacement for ordinary Bayesian or active-inference routes.
Platform and software engineering already treats many quality concerns as trade-off bundles.Reliability, incident, platform, compliance, energy, support, operator-load practice, and Google SRE SLO / error-budget practice, coordinated with C.25.Make the quality bundle explicit, recover each candidate intervention as its direct object, and state applicable authority, latency, adaptation cost, and failure mode.Adopt through FPF quality-bundle routes.

Worked-slice discipline from these rows:

  • state the envelope before importing source terminology;
  • translate source terms into selected structures, ArchitectureOf@Context relations, 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.1 when sensors, probes, dashboards, or metrics change represented state; C.26.2 when 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 Regulation names architecture work over a viability envelope and boundary/action conditions, not Homeostasis Pattern, Allostasis Doctrine, Control Ontology, Quality Optimization Pattern, or Viability Substance.

C.26.3:End

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:

ReadingWhat the claim treats as sufficientNormal result
Dyn0a state or snapshotordinary prose; C.16 only when measurement construction matters
Dyn1a rate, trend, trajectory, flow, throughput, tempo, or cadenceordinary prose or a C.16 result
Dyn2effort, input, policy, timing, resistance, feedback, or constraint is claimed to change a rate, rhythm, recovery, or regimeone small C.27 card

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

  1. Recover the source temporal claim as one exact C.2.1 episteme or as the exact claim denoted by a ClaimAddress.
  2. 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.
  3. Classify the source claim as Dyn0, Dyn1, or Dyn2.
  4. If it is Dyn0 or Dyn1 and no intervention-sensitive use remains, stop or use C.16.
  5. If it is Dyn2, write the one-screen card below.
  6. Add a direct neighboring result only when the supported use relies on its distinction.
  7. 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:

Dyn2TemporalClaimAdequacyCardClaimContent
sourceTemporalClaimRef:
positiveTemporalAspectClaimRef:
move:
claimedInterventionOrInput:
interventionWindow?:
resistanceOrCost:
reasonForReading:
supportedUse:
unsupportedUse:
reopenTrigger:

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:

Dyn2TemporalClaimProfileClaimContent

sourceTemporalClaimRef:
positiveTemporalAspectClaimRef:
dynOrder: Dyn2
boundaryCrossingUse:
supportedUse:
unsupportedUse:
validityOrReopenCondition:
activeNeighborResults:
  - exact result kind and reference supplied by its direct pattern
    contributionToThisUse:

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.

sourceTemporalClaimRef:
  exact ClaimAddress to the backlog-reduction claim
positiveTemporalAspectClaimRef:
  exact [C.27.TA](/generated/patterns/C.27.TA) claim that states the review System's backlog-reduction
  rate over sprints N and N+1
move:
  accelerate backlog reduction
claimedInterventionOrInput:
  planned addition of two reviewers under the WorkPlan
interventionWindow:
  sprints N and N+1
resistanceOrCost:
  queue coordination and domain ramp-up
reasonForReading:
  planning assumption plus prior Work trace if available
supportedUse:
  local staffing discussion and plan choice
unsupportedUse:
  causal proof, long-term capacity model, or benchmark superiority
reopenTrigger:
  work-mix shift, saturation, quality loss, or no measured reduction after sprint N

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.

sourceTemporalClaimRef:
  exact ClaimAddress to the slow-rollout claim
positiveTemporalAspectClaimRef:
  exact [C.27.TA](/generated/patterns/C.27.TA) claim that states CheckoutSystem-1's reduced rollout
  cadence during the two-week window
move:
  brake the rollout
claimedInterventionOrInput:
  proposed rollout-setting change
interventionWindow:
  two weeks
resistanceOrCost:
  slower feature availability and continuing service demand
reasonForReading:
  planning assumption plus the exact [C.26.3](/generated/patterns/C.26.3) envelope-regulation claim
supportedUse:
  local rollout decision
unsupportedUse:
  causal proof, promise fulfilment, or assurance closure
reopenTrigger:
  changed envelope bounds, disturbance, service demand, or rollout result

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.

sourceTemporalClaimRef:
  exact ClaimAddress to the stabilization claim
positiveTemporalAspectClaimRef:
  exact [C.27.TA](/generated/patterns/C.27.TA) claim about LearnerSystem-1's daily task-practice cadence
move:
  stabilize
claimedInterventionOrInput:
  scheduled daily drills
interventionWindow:
  four weeks
resistanceOrCost:
  fatigue, attention drift, task novelty, or habit formation
reasonForReading:
  observed task-completion cadence and error trace, or an explicit planning assumption
supportedUse:
  local practice design
unsupportedUse:
  proof that the Method improves all learning or every task family
reopenTrigger:
  retention falls, task family changes, or the rhythm proxy stops matching performance

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

CaseWhat C.27 preservesDirect next pattern or stop
“Backlog is 120 items today.”Dyn0 snapshotstop; C.16 only when the measurement construction matters
“Backlog fell by 20 items per week.”Dyn1 ratestop or C.16; no intervention claim
“More tool calls will speed debugging.”exact outcome rate, System actor only when Work is claimed, input, resistance, evaluation evidence, stop or replan, and unsupported reasoning-quality inferenceC.24, A.15.1, F.6, evaluation, and evidence as applicable
“Method A improves faster than Method B.”Dyn1 versus Dyn2 comparison, baseline and other windows, effort parity, hidden costs, and no causal or universal superiorityG.9 and C.16; C.28 only for causal use
Equal final scoresadaptation window, effort parity, rework, validity, and recovery may still differG.9
“Velocity improved after becoming the target.”measure, target pressure, actual Work change, gaming or selection, causal claim if any, and proxy divergence remain separateC.16, E.13, C.28 when causal; C.26 only for residual QL
“Team throughput rose, so the organization became agile.”source and target bearers, aggregation, bearer continuity, mix shift, and transfer boundaryaggregation and evidence patterns; C.18.1 when a scale variable is claimed
“Adoption continues after incentives stop.”coasting basis, window, evidence or assumption, supported use, and reopenplanning, evidence, or assurance when current
“The old rollout policy improved recovery, so the new policy will too.”behavior policy differs from proposed policy; overlap, uncertainty, and transfer risk are currentevaluation or control pattern
“The process sped up” across orders, invoices, shipments, and ticketsobject bearers, event traces, interactions, queue effects, and aggregation cannot collapse into one scalarobject-centric process evidence and aggregation patterns
“The team's release rhythm became smoother after review moved earlier.”exact team release-cycle bearer, release and review windows, event-log, queue or rework evidence, transfer delay or queue pressure, and local method use; no organization-agility or promise inferenceC.27.TA, C.16 or evidence, and the direct method pattern
“The new playbook shortened incident recovery.”detection-to-mitigation or mitigation-to-recovery interval, incident mix, dependency and coordination resistance, local use, no guarantee or causal proofC.28, promise, service, and assurance only when their uses are current
“The shortlist arrived faster, so search improved.”faster narrowing can reduce novelty, diversity, frontier coverage, or search healthC.17, C.18, and C.19
“More data, reviewers, tokens, calls, or capacity doubles improvement.”scale variable, scale window, probes, elasticity, and parity are missingC.18.1 and G.9
“Release velocity rose while service demand and recovery time worsened.”acceleration, braking, recovery, hidden cost, and unsupported improvement claim remain visibleC.26.3, C.25, and direct harm, safety, or assurance patterns
“We can halve review time for this regulated release.”temporal action and window do not establish safety, legality, quality, or release permissiondirect legal, quality, safety, gate, and assurance patterns
“The process is agile.”recover the actual local head before treating agility as a temporal claimA.6.P first; C.27 only if braking, redirection, or rate change is current
“This chapter accelerates orientation.”ordinary explanatory proseno C.27 record unless used for a decision, comparison, promise, or intervention claim
Dashboard, probe, token, or active-sensing wordingordinary measurement and use questions remain primaryC.16, planning, evidence, control; C.26 only for a residual QL cue

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.

Trigger in the supported useDistinction C.27 must not hideExact destination
rate, measure, metric, score, proxy, or base-characteristic wording is not yet recoverabledo not guess the characteristic or measure from a familiar wordC.16.P
rate or rate-change measurementbase characteristic, coordinate construction when current, construction method, sampling window, comparability, noise or stability, and evidence legalityA.19 and the exact C.16 result
planned versus actual effortWorkPlan, MethodDescription, resource envelope, performed U.Work or Gamma_work trace, effort window, and evidence remain separateA.15.2, A.15.1, F.6, B.1.6, and resource patterns
temporal slices, phases, Work logs, or resource burncomposition and aggregation do not become acceleration or a transition lawB.1.4 and B.1.6
actor, assignment, authority, or capabilityactual System actor; separate local system-role kind, System classification, assignment occurrence, authority, capability, Work, and effectA.2.1, A.15.1, F.6, and the direct relation patterns
resistance used beyond local diagnosisqualitative judgement, measurement, model assumption, planning assumption, or unknownexact evidence, C.16, model, planning, or assurance result
control or adaptive policyhorizon, feedback update, constraints, uncertainty, stop rule, and policy regime only when currentA.3.3, C.19, C.24, or evaluation pattern
policy transferbehavior policy, proposed policy, overlap or transfer risk, uncertainty or bound, and unsafe exploration remain visibleevaluation or control pattern
sequential intervention regimeone impulse does not describe a sequence of decision rulescontrol, policy, or evaluation pattern
causal useintervention, comparator or counterfactual, assignment or time zero, follow-up, outcome, estimand when current, assumptions, rival causes, identification and evidence designexact C.28 causal-use result
dynamic benchmarkDyn1 versus Dyn2, baseline, sampling, claim, validity, adaptation or effort windows, budget parity, comparator edition, and freshnessG.9 parity plan or report and C.16
metric as target or public signalmeasurement, incentive, changed Work, gaming or selection, causal effect, and proxy or utility distortion are different claimsC.16, E.13, C.28 when causal, assurance when current
multiple object tracesobject bearers, events, interactions, queues, convergence or divergence, and aggregationobject-centric process evidence and aggregation patterns
cross-scale transfersource bearer, target bearer, aggregation, bearer continuity, mix shift, and explicit transfer-use boundaryaggregation, evidence, and architecture patterns
changed scale variableresource or capacity variable, scale window, probes, elasticity as rising, knee, flat, declining, or unknown, and parity; this differs from transferring a reading across bearersC.18.1 and G.9
time-scale choice changes usespot, episode, sprint, life-cycle, learning-cycle, technoevolution, lifetime, or another exact temporal scale is named only when it changes bearer, evidence, use, or reopenC.27.TA and the direct domain pattern
task-family adaptationdeclared TaskFamily or TaskSignature, usable threshold, time and budget to threshold, prior exposure, transfer, retention, and downsideC.22.1
search speednarrowing speed differs from novelty, archive growth, illumination, frontier coverage, and search healthC.17, C.18, and C.19
method composition or capability emergencetemporal adequacy does not define method composition, Work enactment, adaptive cycle, or capability emergenceB.1.5 and B.2.4
evolution or language-state movementtemporal adequacy does not define state-change loops, cue stabilization, reopening, operationalization, or retirementA.4, B.4, A.16, and B.4.1
autonomy budget or freedom of actiontokens, guards, ledger, depletion, override, pause and resume remain their own claimsE.16
viability regulationcite the exact C.26.3 claim episteme or ClaimAddress; its bearer is one exact System, one A.22 Structure with all four discriminators, or another subject with its direct identity ruleC.26.3
selected organization as viability bearerexact constituents, selected obtaining relations, applied constraints, and one selection-use frame; a list of role kinds and assignments is insufficientA.22 and C.26.3
promise, gate, or high-stakes actiontemporal action and window do not establish promise, acceptance, harm, safety, legal, ethical, financial, quality, service, or assurance claimsA.2.3, A.2.8, A.2.9, A.6.C, F.12, and direct assurance or domain patterns
evidence path or freshnesspath, slice, provenance, assurance, decay, and epistemic debt remain separate from the temporal claimA.10, G.6, B.3, and B.3.4
dashboard, telemetry, pack, or refreshhealth-slot meaning, series and slice construction, publication pins, shipping, and refresh orchestration remain separateC.21, G.12, G.10, G.11, and G.6
flow, gate, or crossingselected flow, gate check, decision log, PathSlice, constraint and gate fit, time pins, and crossing remain separateE.18, A.20, and A.21
unstable publication unitrepair the mixed publication subject before judging any remaining temporal claimE.17.AUD and E.17.ID.CR
residual probe, frame, order, export, or coarsening cueordinary temporal, measurement, Work, benchmark, proxy, scale, adaptation, viability, promise, and evidence questions must already be carriedC.26
formal representation or transformationrepresented mathematical structure, bounded transformation, and dynamics model remain distinct from temporal-claim adequacyC.29, A.3.4, and A.3.3
dynamic quality familyquality-bundle content and endpoint identity remain in the quality claimC.25
selector or publication availabilityselector result, source-backed face, publication occurrence, form, carrier, and audience availability remain separateG.5, E.17, and E.24.PUB
coasting, debt, or hysteresis beyond local usewhat continues differs from what remains; reversibility, residue, repayment, braking, and recovery need their direct planning, quality, safety, wellbeing, or assurance claimsdirect planning and domain patterns

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

CheckRequirement
C27-1A C.27 result exists only when the temporal distinction changes a practical use.
C27-2The source temporal claim is one exact C.2.1 episteme or the exact claim denoted by a ClaimAddress; a materialized C.27 adequacy episteme has that source episteme or addressed claim—not the reference value—as its EntityOfConcern.
C27-3The source claim's world-side EntityOfConcern remains with the source claim and is not duplicated as the adequacy episteme's subject.
C27-4C.27 cites an exact C.27.TA episteme or ClaimAddress and does not redefine its bearer, predicate, temporal reference, window, coupling, or currentness.
C27-5Dyn0, Dyn1, and Dyn2 classify claims, not Systems or other world objects.
C27-6The local result is the one-screen card; a boundary-crossing profile contains only the small header and exact direct-result references.
C27-7The card names claimed input, resistance or cost, reason for the reading, supported use, unsupported use, and reopen condition without implying causal effect, Work, authority, value, promise, or assurance.
C27-8Performed Work names the actual System actor, whose A.13 core precedes independent A.15.1 Work admission. F.6 follows only when precise assignment-bound attribution is current. An assignment remains a separate obtaining relation and never acts.
C27-9A non-system input uses its actual direct relation or remains an unresolved or source-side intervention claim; no generic applier branch is created.
C27-10A viability use cites an exact C.26.3 claim episteme or ClaimAddress and an exact System or A.22 Structure bearer; no generic viability or configuration relation is invented.
C27-11Measurement, dynamics, Work, causality, benchmark, promise, value, quality, viability, scaling, adaptation, search, publication, assurance, and residual QL stay with their direct patterns.
C27-12Cases precede the optional trigger reference, and the trigger reference copies no neighboring schema.
C27-13At least one golden case stops at ordinary prose, Dyn0, or Dyn1, and braking or coasting is not treated as failed acceleration.
C27-14Publication occurrence, form, carrier, and availability appear only when they change use and do not reidentify unchanged claim content.

Common Anti-Patterns

FailureRepair
Rate becomes intervention knowledgeSeparate Dyn1 reading from Dyn2 claim; write the small card or stop.
Effort-free accelerationName the claimed input, window when different, resistance or cost, and reason for the reading.
Past slope becomes control lawKeep it diagnostic or cite the direct dynamics, control, or evaluation result.
Rate change after effort becomes causal proofKeep causal use unsupported or cite the exact C.28 result.
Rhythm becomes decorationCite the exact C.27.TA claim; add coupling only when cross-bearer use relies on it.
Metric improvement becomes System improvementSplit measure, target, Work change, gaming or selection, causal claim, and proxy distortion.
Local speed becomes aggregate agilityName both bearers, aggregation, continuity, mix shift, and transfer boundary.
Faster becomes betterReopen value, harm, quality, promise, safety, legal, ethical, or assurance claims through their direct patterns.
Every temporal word gets a profileUse practical-use relevance, not keyword matching.
Assignment, policy, Method, tool, or record becomes an actorName the actual System actor or the non-system object's direct relation.
C.27 profile becomes promise or gateKeep the unsupported use explicit and cite the direct promise, service, gate, or assurance result.
Coasting becomes free evidence of successName the basis and window as evidence, assumption, or unknown, then state reopen.
Reversibility is assumedState reversible, costly, irreversible in the window, or unknown only when the use relies on it.
Probe or active-sensing wording activates QLComplete ordinary-pattern non-use tests; use C.26 only for a residual cue.

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 lineLesson retained in C.27Boundary
D2-SRC-1 — state, first-derivative, second-derivative, effort intervals, rhythm and practiceask whether the text reads rate or claims effort changes rate; preserve practice and dance transferreject new physical Kernel kinds
D2-SRC-2 — learning-based and engineering MPChorizon, constraints, uncertainty, feedback update, and stability matter only for control-style usecite dynamics, control, evidence, and assurance results
D2-SRC-3 — safe RL, off-policy evaluation, conservative offline RL, and dynamic treatment regimesbehavior policy, proposed policy, overlap, unsafe exploration, nonstationarity, and repeated timing matter for policy transferdo not transfer one observed slope to another policy
D2-SRC-4 — causal inferenceintervention, comparator, timing, outcome, estimand, assumptions, rival causes, identification and evidence design distinguish causal useC.28 carries the causal-use result
D2-SRC-5 — performative prediction and Goodhart variantspublication and targets can change behavior; measure, target, Work change, and proxy distortion differC.16 and E.13 carry their questions
D2-SRC-6 — object-centric process miningscalar throughput can hide multiple object bearers, event traces, interactions, and aggregationcite object-centric process evidence
D2-SRC-7 — active inference and active sensingmeasurement can be actionordinary measurement, planning, evidence, control, and causal patterns remain primary; QL is not automatic
D2-SRC-8 — rhythm, synchronization, groove, and entrainmentbearer, temporal reference, window, evidence, and supported use are primary; coupling is conditionalC.27.TA carries the positive temporal-aspect claim
CT-TIME-SRC — constructor theory of timetask or transformation, duration and clock relations, and dynamics remain distinctA.3.4 carries transformation, C.27.TA the positive aspect, A.3.3 dynamics

Source references:

Relations

Direct patternC.27 consumes or statesThat pattern keeps
C.27.TAexact positive temporal-aspect episteme or ClaimAddressbearer, predicate, temporal reference, window, coupling, currentness
C.2.1 and A.7source claim identity and the separate adequacy epistemeepisteme identity, EntityOfConcern, ClaimGraph, description and described-object separation
C.16exact measurement result when relied oncharacteristic, scale, unit, construction, sampling, comparability, evidence
A.3.3 and A.3.4boundary that a temporal claim needs dynamics or concerns a transformationtransition law, model, simulation, prediction, control, transformed object and relation
A.15.2, A.15.1, F.6, and A.2.1planned input, actual System actor, assignment when relied on, and performed Work referenceplan, Work identity, actor, assignment, authority and attribution
C.28exact causal-use result when temporal wording is used causallyintervention, comparator, timing, outcome, estimand, assumptions, rival causes, identification and evidence design
G.9dynamic comparison questionparity plan and report, baseline, freshness, comparator, budget and evidence pins
C.18.1, C.22.1, C.17, C.18, and C.19temporal question in scaling, adaptation, creativity, open search, or pool policyscale, task-family, novelty, archive, frontier and search-health claims
C.26.3exact envelope-regulation episteme or ClaimAddress used by a braking, recovery, cadence or stabilization claimexact bearer, protected claim, envelope, disturbance, probes, interventions, cost and failure mode
E.13, promise, service, value, quality, harm, and assurance patternstemporal action and bounded supported or unsupported usevalue, proxy, promise, acceptance, quality, harm, safety, legal, ethical and assurance claims
A.10, G.6, B.3, B.3.4, G.10, G.11, and G.12the temporal reading that relies on evidence or currentnessevidence paths, provenance, assurance, decay, shipping, refresh, series and publication pins
E.17 and E.24.PUBonly the publication distinction that changes usesource-backed face, publication occurrence, form, carrier, audience and availability
C.26only that a residual QL cue remains after ordinary patternsprobe, frame, order, export and coarsening discipline

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.2 or A.15.1.
  • If the question is measurement construction, rate construction, scale, score, or metric comparability, use C.16 and 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:

  1. Cadence and rhythm become decorative words. A text says "release cadence" or "team rhythm" without naming bearer, interval, timing reference, or use.
  2. Freshness becomes a vague virtue. A source, benchmark, dashboard, or claim is called current without a validity window or refresh relation.
  3. 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.
  4. 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.
  5. 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

ForceTension
Positive temporal subject vs claim adequacySome temporal aspects merely need to be named; others become authored temporal claims whose adequacy must be judged by C.27.
Bearer and intervalA rhythm, latency, recovery time, or validity window means little without a bearer and temporal reference.
Local timing vs durable useA local work note may need one interval; a public claim, benchmark, source use, or assurance relation may need currentness and refresh discipline elsewhere.
Transformation and dynamics pressureA temporal aspect can time a transformation or dynamics model without becoming the transformation or the dynamics episteme.
Measurement pressureSome temporal aspects require measurement construction; others only need a named temporal reference.

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:

TemporalAspectStatementClaimContent:
  entityOfConcernRef:
  aspectPredicate:
  temporalReference:
  windowOrInterval:
  entityRulePatternCitation?:
  effectiveReferenceSchemeRef?:
  claimOrWorkScopeRef?:
  selectedStructureRef?:
  sourceOrUseBoundaryRef?:
  localUseCondition?:
  measuredReadingRef?:
  directRelationDeclarationRef?:
  obtainingRelationOccurrenceRef?:
  receivingUseRulePatternCitation?:
  validityOrCurrentnessCondition?:
  refreshOrReopenCondition?:
  blockedLocalOverread?:

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

Temporal useDirect pattern or rule citation
positive temporal-aspect claim about an object or claimC.27.TA
adequacy or supported use of an authored temporal claimC.27
bounded transformation under conditions with temporal referenceA.3.4 plus C.27.TA
state-space or transition-law modelA.3.3
planned work timingA.15.2
dated work occurrence or traceA.15.1
measurement construction for rate, duration, latency, or freshnessC.16 and related characterization patterns
causal-use timing, intervention window, comparator, or follow-up intervalC.28
benchmark freshness, baseline window, comparator edition, or parity windowG.9
source currentness, evidence decay, provenance, or assurance refreshevidence, source, provenance, assurance, and refresh patterns

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:

RhythmAspectClaimContent:
  entityOfConcernRef:
  aspectPredicate: rhythm | cadence | synchronization
  timingReference:
  rhythmWindowRef:
  intervalStructure?:
  rulePatternCitation?:
  directCouplingRelationDeclarationRef?:
  obtainingCouplingOccurrenceRef?:
  validityWindowRef?:

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.

TemporalAspectStatementClaimContent:
  entityOfConcernRef: the exact C.30 architecture claim about the selected interlevel-conflict structure.
  entityRulePatternCitation: C.30 plus the selected architecture-structure pattern.
  claimOrWorkScopeRef?: exact A.2.6 claim scope for the pump-station operations-service architecture concern during release train R14-R15.
  aspectPredicate: recoveryTiming.
  temporalReference: release train cycle.
  windowOrInterval: two release cycles after the accepted architecture move starts.
  measuredReadingRef?: operations-service conflict indicator, if C.16 measurement is being made.
  directRelationDeclarationRef?: A.3.4 transformation declaration, if that relation is current.
  obtainingRelationOccurrenceRef?: omitted here; the expected reduction is not an obtaining transformation occurrence.
  receivingUseRulePatternCitation: A.3.4 for bounded transformation, C.30 for selected architecture structure, and the evidence/result pattern for an observed effect.
  validityOrCurrentnessCondition?: valid only while the same selected structure, release train, and conflict indicator remain in force.
  refreshOrReopenCondition?: reopen if the conflict indicator worsens, the release train changes, or the selected structure changes before R15 close.
  blockedLocalOverread: this recovery-timing claim does not prove that the architecture move reduced the conflict.

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

CheckRequirement
CC-C27TA-1The first result names one exact EntityOfConcern, temporal predicate, temporal reference, and interval or window. A materialized result is ClaimGraph content in one C.2.1 episteme.
CC-C27TA-1aNo generic context value is required. Measurement, effective scheme or scope, selected Structure, source or use boundary, local-use condition, currentness, reopen, coupling, direct relation, PatternID citation, and blocked overread appear only when changing that value could change the claim or receiving action.
CC-C27TA-2The aspect label is a predicate or qualifier in claim content, not an identified temporal-aspect object, and the statement distinguishes the positive claim from C.27 adequacy.
CC-C27TA-3When present, PatternID citations are ordinary rule locators. Any direct relation uses a separate exact declaration reference and cites an obtaining occurrence only after its own predicate passes.
CC-C27TA-4Rhythm or cadence claims use the four-part minimum; cross-bearer fields appear only when an independently established relation changes the receiving use.
CC-C27TA-5Currentness or freshness claims add a source-use boundary, currentness, refresh, or reopen condition only when it changes the receiving use.
CC-C27TA-6Recovery, stabilization, inertia, and effort-over-time claims begin with the four-part minimum; disturbance, measurement, effort, relation, and rule fields are conditional.
CC-C27TA-7The claim does not infer evidence, permission, value, gate passage, work completion, causal use, or a relation occurrence from a temporal predicate.
CC-C27TA-8Measurement construction, dynamics laws, transformations, work, benchmark parity, and source or evidence use stay with their direct patterns; publication occurrence, form, and carrier do not reidentify unchanged claim content.

Common Anti-Patterns

Anti-patternSymptomRepair
Cadence without bearer"Weekly cadence" appears without saying what has the cadence.Name the exact EntityOfConcern, cadence predicate, temporal reference, and interval; add other fields only when the receiving use needs them.
Freshness without windowA source is called current without reference time or validity window.Name the exact source, current or fresh predicate, reference time or edition, and validity window; add a refresh condition only when the next use depends on it.
Recovery without an adequate temporal claimA claim says "recovery improved" without an exact bearer, temporal reference, or interval.State the four-part minimum; add a disturbance, measure, rule citation, or relation only when the receiving use depends on it.
Rhythm as valueA rhythm is treated as good by default.Use the direct value, assurance, quality, or proxy pattern for those separate claims.
Timing as transformationA time window is treated as if it specified the change.Use A.3.4 for the transformation relation and C.27.TA for the temporal aspect.

SoTA-Echoing

Source familyCurrent lesson for C.27.TAFPF decision
Control and model-predictive practiceHorizons, constraints, update intervals, and feedback timing are distinct from the controlled object and the control law.Treat temporal aspects as named slots; use A.3.3, evidence, and control-related patterns for models and control claims.
David Deutsch and Chiara Marletto, "Constructor theory of time" (arXiv:2505.08692v3), version-specific source posture.A task or transformation specification need not itself specify duration or the internal course of performance; duration and dynamics can be recovered through timer and clock relations among attributes. Reopen this row if a later version changes the task/duration/timer/clock separation used here.Require C.27.TA temporal aspects to name bearer and temporal reference. Use A.3.4 for the transformation, A.3.3 for dynamics episteme, and C.27 only when an authored temporal claim uses the aspect for a practical use.
Dynamic treatment regimes and policy evaluationIntervention timing, follow-up interval, policy window, and outcome window must be separated before causal or policy claims are made.Use C.27.TA for temporal windows; use C.28 and evidence patterns for causal-use and policy claims.
Object-centric process and event-log practiceA scalar throughput or latency can hide multiple bearers, event types, and interaction windows.Name the exact EntityOfConcern, temporal predicate, and temporal reference before using a rate, cadence, or trajectory across objects.
Rhythm and synchronization researchRhythm needs a bearer, timing reference, and window; phase or interval structure and coupling matter only when the receiving use relies on them.Keep rhythm and cadence as predicates or qualifiers in temporal claim content; state a separate temporal-adequacy or other subject assertion only for its current use, and resolve the defining or constraining ClaimGraph through C.27 or the relevant pattern locator.

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.27 consumes this exact temporal-aspect episteme or one exact C.2.1 ClaimAddress to 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

  1. What exact causal-use question is being asked, and which claim-bearing episteme states it?
  2. Is the intended statement observational, interventional, or counterfactual?
  3. 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?
  4. Which common validity problem could overturn the use: intervention definition or consistency, time order, confounding, overlap, interference, selection or missingness, measurement, or transport?
  5. What causal statement or evidential reliance is supported now, and what stronger statement is not?
  6. 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:

CausalUseTriageRecord:
  causalUseQuestionRef?: CausalUseQuestionRef
  causalUse: yes | no | unclear
  targetCausalityLadderRung?: CausalityLadderRung
  comparatorOrCounterfactualRef?
  availableSupportCues?
  liveThreats?
  supportedUse?
  unsupportedUse?
  nextCausalUseAction

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.

nextCausalUseAction =
  stopNoCausalUse |
  reportAssociationOnly |
  keepNonCausalSimulationUse |
  downgradeCausalWording |
  requestIdentificationOrBound |
  requestEstimate |
  requestCounterfactualSamplingRealizabilityCheck |
  requestPerformedSamplingEvidence |
  requestTransportCheck |
  requestEvidenceDesign |
  sendFairnessUseToD5BiasAuditReport |
  sendParityUseToG9 |
  abstainDownstream

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:

  1. Rung collapse: observation, intervention, and counterfactual comparison are treated as the same question.
  2. Support collapse: data regime, identification, estimation, direct sampling, and simulation are treated as one alternative-valued “basis”.
  3. 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

ForceTension
Causal safety vs affordabilityOrdinary claims need a quick screen; consequential claims need replayable support.
Formal precision vs readable practiceGraphs, estimands, assumptions, and proofs matter, but a cold reader still needs a clear first action.
Identification vs estimation vs realizabilityThe target may be identifiable but not yet estimated, bounded but not point-identified, or directly sampleable only under special constraints.
Domain breadth vs one patternPotential outcomes, SCMs, target trials, causal ML, transport, causal RL, representation learning, and fairness use different specialist methods.
Shared support vs local authorityNeighbours need the result, but keep their own decision and publication rules.

Solution

Use the smallest result that answers the current question:

  1. triage the claim;
  2. stabilize the question in a small card when it must be reused;
  3. run the common threat screen;
  4. add only the specialist result needed now; and
  5. issue a small CausalUseSupportResult when 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.

  • CausalUseQuestionRef identifies the exact question content, normally a C.2.1 episteme.
  • CausalEstimandRef identifies the mathematical target or the episteme that describes it under its direct pattern.
  • PotentialOutcomeContrastRef identifies the exact contrast or its description.
  • CausalUseSupportResultRef identifies one C.2.1 result episteme defined below.

Support is composable. A real result may use several components:

CausalSupportComponentRefs:
  evidencePathRefs?
  empiricalDataRegimeRefs?
  identificationResultRef?
  estimateResultRef?
  counterfactualSamplingRealizabilityResultRef?
  simulationResultRef?
  targetTrialMappingResultRef?
  offPolicyCausalEvaluationResultRef?
  causalVariableRepresentationRecordRef?
  transportabilityResultRef?

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.

ComponentQuestion it answersDoes not establish
evidence path and data regimeWhat observations, assignments, or samples are available, and where did they come from?identification or a valid estimate
identification resultCan the estimand be expressed or bounded from those data and assumptions?a numerical estimate or direct sampling
estimate resultWhat value and uncertainty were obtained under an identification or design basis?identification by the number alone
counterfactual-sampling realizability resultCan samples from the declared target distribution be obtained under the stated constraints, and how was that decided?a WorkPlan, performed sampling, resulting data, or identification of every target
simulation resultWhat did the model produce under its assumptions and validation?realized evidence or an intervention effect
target-trial mapping resultHow does the declared trial protocol map to one observational data source, and which gaps, residual-confounding risks, and sensitivity checks remain?identification, low risk of bias, or a valid estimate by reporting completeness alone
off-policy evaluation resultWhat does logged behaviour support about one evaluation policy under the stated history, confounding, overlap, endpoint, estimator, and uncertainty conditions?authority to deploy or unqualified policy optimality
causal-variable representation recordWhich learned, selected, or abstracted variables preserve the interventions, invariances, and queries needed for this use?causal validity for every query, shift, or domain
transportability resultWhich support transfers between exact endpoints, under which assumptions?transfer by a shared label or population name

CausalEmpiricalDataRegime is a local classification used only when it helps distinguish evidence:

CausalEmpiricalDataRegime =
  observationalOrNaturalBehaviorData |
  randomizedInterventionData |
  governedInterventionData |
  realizedCounterfactualSamplingData

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

CausalityLadderRung =
  observationalAssociationRung |
  interventionalActionRung |
  counterfactualComparisonRung
  • 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

CausalUseClaimKind =
  causalEffectClaim |
  counterfactualComparisonClaim |
  causalFairnessClaim |
  causalPolicyClaim |
  causalBenchmarkParityClaim |
  causalEvidenceSupportClaim |
  causalAssuranceSupportClaim

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:

LocalCausalUseQuestionCard:
  causalUseQuestionRef: CausalUseQuestionRef
  targetCausalityLadderRung: CausalityLadderRung
  causalUseClaimKind?
  comparatorOrCounterfactualRef?
  causalEstimandRef?
  supportedUse
  unsupportedUse
  nextCausalUseAction

Use a durable card only for a reusable or consequential claim:

DurableCausalUseQuestionCard:
  causalUseQuestionRef: CausalUseQuestionRef
  targetCausalityLadderRung: CausalityLadderRung
  causalUseClaimKind
  comparatorOrCounterfactualRef?
  causalEstimandRef: CausalEstimandRef
  potentialOutcomeContrastRef?: PotentialOutcomeContrastRef
  interventionOrAssignmentWindowRef?
  followUpWindowRef?
  outcomeMeasureRef?
  causalAssumptionRefs
  rivalCauseRefs?
  causalSupportComponentRefs
  commonThreatScreenRef?
  supportedUse
  unsupportedUse
  stopOrReopenCondition

When another pattern needs a stable conclusion, issue this small C.2.1 result episteme:

CausalUseSupportResult:
  causalUseQuestionRef: CausalUseQuestionRef
  causalUseClaimKind: CausalUseClaimKind
  targetCausalityLadderRung: CausalityLadderRung
  causalEstimandRef?: CausalEstimandRef
  causalSupportComponentRefs: CausalSupportComponentRefs
  commonThreatScreenRef?
  verdict: supported | bounded | unsupported | undecided
  supportedUse
  unsupportedUse
  limits
  evidenceWindowRef?
  reopenCondition

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.

CommonCausalThreatScreen:
  causalUseQuestionRef
  interventionWellDefinedOrConsistency?: clear | liveThreat | notApplicable
  temporalOrdering?: clear | liveThreat | notApplicable
  exchangeabilityOrConfounding?: clear | liveThreat | notApplicable
  positivityOrOverlap?: clear | liveThreat | notApplicable
  interferenceOrSpillover?: clear | liveThreat | notApplicable
  selectionCensoringOrMissingness?: clear | liveThreat | notApplicable
  measurementErrorOrConstructShift?: clear | liveThreat | notApplicable
  transportToTarget?: clear | liveThreat | notApplicable
  routedThreatRefs?
  resultingSupportBoundary

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:

CausalIdentificationResult:
  causalUseQuestionRef: CausalUseQuestionRef
  causalEstimandRef: CausalEstimandRef
  availableDataRegimeRefs
  causalAssumptionRefs
  modelOrDiagramRefs?
  calculusOrDerivationMethodRef?
  status: identified | bounded | nonidentified | unclear
  identifyingExpressionOrDerivationRef?   # required when identified
  boundResultRef?                         # required when bounded
  obstructionOrFailureWitnessRef?         # required when nonidentified
  falsificationOrNegativeControlRef?
  sensitivityAnalysisRef?
  supportedUse
  unsupportedUse

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.

CounterfactualSamplingRealizabilityResult:
  causalUseQuestionRef: CausalUseQuestionRef
  targetCounterfactualDistributionRef
  targetCausalityLadderRung: counterfactualComparisonRung
  modelOrDiagramRefs?
  sameUnitConflictCheck
  ancestorRegimeConflictCheck
  physicalConstraintRefs
  ethicalConstraintRefs
  operationalConstraintRefs
  unitHistoryAvailabilityRef?
  decisionMethodRef
  decisionDerivationRef?
  positiveSamplingConstructionRef?  # required when realizable
  boundResultRef?                   # required when bounded
  obstructionOrFailureWitnessRef?   # required when nonrealizable
  status: realizable | bounded | nonrealizable | unclear
  supportedUse
  unsupportedUse

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.

TargetTrialProtocolRecord:
  causalUseQuestionRef: CausalUseQuestionRef
  targetPopulationRef
  eligibilityCriteriaRef
  treatmentStrategyRefs
  assignmentProcedureRef?
  timeZeroRef
  followUpWindowRef
  outcomeMeasureRef
  potentialOutcomeContrastRef?: PotentialOutcomeContrastRef
  causalEstimandRef: CausalEstimandRef
  analysisPlanRef

An observational emulation keeps the protocol and its mapping to available data as separate results:

TargetTrialMappingResult:
  causalUseQuestionRef: CausalUseQuestionRef
  targetTrialProtocolRef
  observationalDataSourceRef
  eligibilityCriteriaMappingRef
  treatmentStrategyMappingRefs
  assignmentAndTimeZeroMappingRef
  followUpWindowMappingRef
  outcomeMeasureMappingRef
  identifyingAssumptionRefs
  protocolToDataGapAccountRef
  residualConfoundingAssessmentRef
  sensitivityMappingRefs
  supportedUse
  unsupportedUse
  reopenCondition

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.

CausalEstimateResult:
  causalEstimandRef: CausalEstimandRef
  identificationResultRef?: CausalIdentificationResultRef
  designBasedIdentificationResultRef?
  dataRef
  estimatorMethodRef
  diagnosticRefs?
  uncertaintyResultRef
  sensitivityAnalysisRef?
  estimationConsistencyResultRef?  # when consistency is a live support condition
  methodSpecificDetailRefs?        # only for the selected estimator family
  supportedUse
  unsupportedUse

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.

CausalTransportabilityResult:
  causalUseQuestionRef: CausalUseQuestionRef
  sourcePopulationRef?
  targetPopulationRef?
  sourceDomainRef?
  targetDomainRef?
  sourceEnvironmentRef?
  targetEnvironmentRef?
  sourceDataGeneratingRegimeRef?
  targetDataGeneratingRegimeRef?
  selectionAssumptionRefs?
  domainShiftAssumptionRefs?
  sourceWindowRef?
  targetWindowRef?
  overlapEvidenceRef?
  transportComparatorOrFormulaRef
  semanticBridgeRef?          # only when interpretation differs
  supportedUse
  unsupportedUse
  unresolvedAssumptionRefs?

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.

OffPolicyCausalEvaluationResult:
  causalUseQuestionRef: CausalUseQuestionRef
  evaluationPolicyRef
  behaviorPolicyRef
  sequentialHorizonRef?
  unitHistoryConditioningRef?
  confoundingAssumptionRefs?
  overlapOrSupportCheckRef
  policyTransportabilityResultRef?
  estimatorRef?
  uncertaintyResultRef?
  supportedUse
  unsupportedUse
  reopenCondition

Causal representation. Use this record only when variables are learned, selected, or abstracted rather than supplied by the domain:

CausalVariableRepresentationRecord:
  causalUseQuestionRef: CausalUseQuestionRef
  sourceRepresentationRef
  selectionOrAbstractionMethodRef
  representationAssumptionRefs
  interventionValidityResultRef
  invarianceResultRefs?
  abstractionFidelityResultRef?
  counterfactualQueryPreservationResultRef?
  uncertaintyResultRef?
  shiftLimitRefs?
  supportedUse
  unsupportedUse
  reopenCondition

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:

CausalGraphRepresentationKind =
  causalDirectedAcyclicGraphRepresentation |
  acyclicDirectedMixedGraphRepresentation |
  singleWorldInterventionGraphRepresentation |
  structuralCausalModelTwinNetworkRepresentation |
  ancestralMultiWorldNetworkRepresentation |
  counterfactualGraphicalModelRepresentation

GraphSeparationCriterionKind =
  dSeparationCriterion |
  mSeparationCriterion |
  singleWorldInterventionGraphSeparationCriterion |
  ancestralMultiWorldNetworkSeparationCriterion |
  counterfactualGraphSeparationCriterion

CausalInferenceCalculusKind =
  doCalculus |
  ctfCalculus |
  potentialOutcomeCalculus |
  gFormulaCalculus

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:

CausalUseEvidenceDesignRecord:
  causalUseQuestionRef: CausalUseQuestionRef
  targetCausalityLadderRung
  causalEstimandRef?
  interventionOrProtocolRef?
  plannedDataRegimeRefs?
  identificationQuestionRef?
  estimationQuestionRef?
  samplingRealizabilityQuestionRef?
  transportQuestionRef?
  targetTrialMappingResultRef?
  offPolicyCausalEvaluationResultRef?
  causalVariableRepresentationRecordRef?
  causalEvidenceMethodDescriptionRefs?
  causalEvidenceWorkPlanRef?
  realizedCausalEvidenceWorkRefs?
  workAttributionResultRefs?
  evidencePathRefs?
  modelAssumptionRefs?
  simulationValidationRef?
  decisionThresholdAffected?: yes | no | unclear
  evidenceValueOrProbeWorthinessRef?
  costOrRiskRef?
  supportedUseIfSuccessful
  unsupportedUseWithoutFurtherEvidence

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:

CausalActionPolicyClass =
  naturalBehaviorPolicy |
  interventionalPolicy |
  counterfactualPolicy |
  mixedPolicy

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:

Wording cueRecover
“causal question”the exact question content and its C.2.1 episteme
“estimand”the mathematical target or the episteme that describes it
“causal evidence”evidence paths, empirical data regimes, and the separate identification, estimate, sampling-realizability, performed-sampling, resulting-data, simulation, and transport results actually used
“policy optimality”policy class, off-policy result, support result, limits, and the downstream choice decision
“fairness evidence”causal question and support result here; BiasAuditReport@Context and audit decision in D.5
“what would have happened”a sampling-realizability result, performed sampling with resulting data, an identified or bounded estimate, simulation, or an unsupported claim—named separately

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

Current issueUseC.28 contribution
measurement or metricC.16causal support only when the measure is used causally
temporal trend or rateC.27causal support only when time order is used as cause evidence
evidence path and provenanceA.10support-result and component refs
assuranceB.3one possible basis for a separate bounded assurance result
local choiceC.11question, support result, and policy class when needed
live-pool policyC.19causal data or policy support when needed
call planC.24causal action-use field when planned calls serve a causal claim
bias or fairness auditD.5causal question, rung, estimand, support result, and the additional counterfactual-identification and estimation-consistency conditions when that branch is current
method dispatchG.5causal method-use classification and support refs
benchmark parityG.9rung, estimand, support-component, transport, and support-result parity

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

CasePlain bounded result
association only“The evidence supports an association report; it does not support an intervention-effect claim.”
temporal change only“The change in time is recorded; a causal-effect claim remains unsupported.”
non-causal simulation“The simulator produced these traces; no causal use is claimed.”
simulation used causally“The validated model supports this bounded model-based comparison; it does not supply realized or interventional evidence.”
metric-only fairness“The metric disparity is reported; causal fairness is not established.”
logged policy“The evaluation supports only the named behaviour/evaluation-policy regime and overlap limits; unqualified optimality is unsupported.”
cross-rung benchmark“The methods answer different causal questions; publish the bridge and its loss, report degraded parity, or abstain instead of naming one causal winner.”

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

CaseResult
“Users who received X improved, so X works.”Observational rung; association supported; intervention effect unsupported unless identification/design results close the gap.
“We changed X once, so the policy works everywhere.”Interventional result limited to its population/environment/window; transport requires exact endpoints and assumptions.
“The simulator shows what would have happened.”With no causal reliance, exit to model reporting. With causal reliance, cite the simulation result, assumptions, validation, supported model use, and unsupported realized/interventional use.
“The trial was randomized, therefore the estimate is valid.”Run the common threats: interference, attrition, measurement, adherence, and analysis can still lower the result.
“The observational estimand is identified.”Cite the identifying expression/derivation, bound, or nonidentification witness; the label alone is incomplete.
“The fairness metric improved, therefore the intervention is fair.”Report metric change. A counterfactual-fairness claim additionally needs its causal estimand, counterfactual-identifiability assumptions, estimate-consistency basis when used, and bounded C.28 support before D.5 audits it.
“Logged replay says this policy is optimal.”Cite behaviour/evaluation policies, overlap, confounding, transport, uncertainty, and bounded support; unqualified optimality is unsupported.
“Method A beats Method B causally.”Use G.9; different rungs, estimands, support components, endpoints, or windows require a bridge with stated loss, degraded parity, or abstention.

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

  1. One exact causal-use question remains identifiable from entry to result; question, claim, estimand, evidence, and records are not treated as one object.
  2. This edition introduces no universal causal-use-question, estimand, or potential-outcome-contrast kind; it uses local refs to actual objects instead.
  3. Data regime, identification, estimate, sampling realizability, performed sampling evidence, simulation, and transport remain distinct and may be combined.
  4. A support result states evidence support only; every publication, choice, deployment, fairness, or assurance decision remains with its direct pattern.
  5. An identified result cites an expression or derivation; a bounded result cites a bound; a nonidentified result cites an obstruction or witness.
  6. A causal estimate cites an identification or explicit design-based result. Method-family details appear only when that Method is selected.
  7. The common threat screen routes every live ordinary threat or lowers the result; it is not a mandatory dossier.
  8. Non-causal simulator reporting and simulation-supported causal use take different routes at first entry.
  9. 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.
  10. 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 realizable label cannot satisfy this branch.
  11. 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.
  12. Transport identifies every changed population/domain/environment/data-generating-regime endpoint separately from semantic schemes.
  13. A counterfactual-fairness escalation exposes its additional identification assumptions and, when an estimate is used, estimation consistency before D.5 consumes it.
  14. CausalActionPolicyClass has the same four members in definition, examples, and consumers; unresolved classification is not a member.
  15. Every specialist field changes support, a downstream decision basis, evidence work, or a reopen condition.
  16. 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.
  17. 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.
  18. 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

Anti-patternRepair
Fill-all-cards defaultStart with triage and add only the live profile.
Rung label as validity proofRun the common threat screen and cite the actual results.
One support-basis enumKeep data, identification, estimate, sampling, simulation, and transport separate.
Estimate creates identificationRequire an identification or design-based result first.
Graph-only causalityCite the model or diagram, assumptions, and replayable derivation or bound.
Feasibility as performed evidenceKeep the sampling-realizability result separate from a WorkPlan, dated Work, and resulting data.
Work or plan as dataRequire the A.10 path to the resulting sample or data before claiming the empirical regime.
Simulation as realized evidenceUse simulationResultRef and state unsupported realized/interventional use.
Shared context label proves transportName exact causal endpoints, assumptions, and formula.
Support verdict authorizes actionReturn the support result to the downstream decision pattern.
Specialist branch named but not consumablePut its exact result ref in the common component contract and keep its assumptions, limits, uncertainty, and reopen condition with that result.
Ontology dossier as precisionKeep specialist refs behind the ordinary question, threat, and support statement.

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.

Status and live problemContribution usedAdopted, adapted, or rejected FPF move
Lineage: seeing, doing, imagining, and identificationPearl hierarchy and identification tradition, On Pearl's Hierarchy and the Foundations of Causal InferenceRetain the three-rung distinction and no unsupported climb. This is history and foundation, not proof that one graphical school covers every domain.
Current counterfactual theoryCorrea and Bareinboim, 2025, Counterfactual Graphical ModelsName graph form and calculus when the derivation depends on them. Do not make the formalism part of ordinary triage or treat a graph label as a result.
Current reporting practiceTARGET Statement, BMJ 2025, Reporting of observational studies explicitly emulating a target trialRetain causal question and estimand, assumptions, protocol-to-data mapping, estimate and precision, and sensitivity reporting. Reject the overread that complete reporting is identification or low risk of bias.
Current bounded transport researchNeurIPS 2025, Causal Effect Estimation under Covariate ShiftKeep identification and estimation under a named shift explicit. This does not replace the broader endpoint and assumption requirements for other transport problems.
Current sampling-realizability decisionRaghavan and Bareinboim, ICLR 2025, Counterfactual Sampling RealizabilityAdopt: make realizability a replayable prospective result with its decision Method and construction, bound, or obstruction. Reject the earlier C.28 collapse with WorkPlan, dated Work, or data.
Current Layer-3 identification and boundsRaghavan and Bareinboim, 2026, Causal Identification from Counterfactual Data: Completeness and Bounding ResultsAdopt as composition, not collapse: realized counterfactual data may feed a separate identification or bound result. Producing those data still needs dated Work and an evidence path to the result; realizability alone supplies neither data nor identification.
Lineage and current domain practice: potential outcomesRubin 1974 and later target-trial practiceRetain estimand, contrast, assignment/time zero, follow-up, outcome, and analysis plan. Use PotentialOutcomeContrastRef, not an unadmitted U-kind.
Conditional estimator familyChernozhukov et al. 2018, Double/debiased machine learningUse orthogonal scores and cross-fitting only for a selected DML Method. Reject their use as universal estimation fields.
Current counterfactual-fairness limitMa et al., CLeaR 2026, Consistent End-to-End Estimation for Counterfactual FairnessAdopt: a supported counterfactual-fairness use exposes additional counterfactual-identifiability assumptions and estimation consistency. Infinite data does not repair either omission; D.5 receives a bounded or unsupported result when they are absent.
Lineage: causal representationSchölkopf et al., Toward Causal Representation LearningRetain intervention validity, invariance, abstraction fidelity, query preservation, and shift checks when learned causal variables are used. This broad source is lineage, not a claim that one representation is current-best for every domain.
Lineage: sequential causal policyMaiti and Bareinboim, Sequential Causal Games, plus causal bandit and data-fusion workRetain natural, interventional, counterfactual, and mixed policy distinctions and keep history, overlap, and transport visible. Do not infer policy optimality from replay reward.
2026 domain-specific representation and policy alternativesMandyam et al., CANDOR, and Balashankar et al., Domain Faithfulness through Counterfactually Robust LearningReject as shared-interface additions: imperfect counterfactual annotations, healthcare policy evaluation, subgroup rules, and representation/training choices materially affect their domain Methods, diagnostics, and supported use, but add no missing universal C.28 field. Keep them in method-specific detail and reopen only if a cross-domain result exposes a new minimum support distinction.
Lineage: fairness and accuracyPlecko and Bareinboim, Fairness-Accuracy Trade-Offs: A Causal PerspectiveRetain the causal estimand and trade-off question, but do not use this lineage alone as current counterfactual-fairness support. The 2026 identification and consistency conditions above now bound D.5 consumption.

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.16 keeps measurements and scales; C.27 keeps temporal-claim adequacy.
  • A.10 keeps evidence paths and provenance and may cite C.28 support components and result.
  • A.2.4 classifies how an episteme is used; it cannot promote simulation output or association into stronger causal evidence.
  • A.15 keeps Method, plan, Work, and attribution for interventions, target trials, and sampling.
  • B.3 may cite a C.28 result as one basis for a separate bounded assurance result.
  • C.11, C.19, and C.24 keep choice, pool treatment, and call planning and consume only the needed causal refs.
  • D.5 keeps bias/fairness audit and uses BiasAuditReport@Context when a causal fairness question is consequential or reusable.
  • G.5 keeps method dispatch; G.9 keeps parity and benchmark conclusions; G.11 keeps refresh planning.
  • C.26 is 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.

First questionRequired answer before claim-bearing lens use
Is the mathematical phrase changing the next lens-use action, or only helping recognition?If no action changes, keep ordinary prose or write NoMathLensUseNeededNote.
What phenomenon is being seen through the lens?Name TargetPhenomenon in problem-owning language.
What concrete mathematical object, formal position, learned representation, simulation object, or local formalism is being used?Name CandidateMathObject; broad family names are prompts only.
What structure is preserved?Name PreservedStructure.
What structure is lost or deliberately ignored?Name LostStructure; empty loss needs equivalence or isomorphism justification.
When should this lens use narrow, stop, or return to another source or pattern?Name StopCondition; a declared lens use requires that concrete condition.

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.P governs relation precision restoration, but not every mathematical-object transfer.
  • A.3.3 governs state, transition, observation, validity, constraints, and calibration for dynamics, but not all mathematical representation choices.
  • A.19 governs characteristic spaces, structural overlays, comparability, normalization, and bridge-aware state comparison, but not the adequacy of all mathematical lenses.
  • C.18.1 and C.19.1 govern scale-law and BLP claims, but not non-scale mathematical lenses.
  • C.26 is the local precedent for mathematical-lens detachment, but only for quantum-like modeling.
  • F.9 governs 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

ForceTension
Compression vs truthfulnessA useful mathematical lens compresses many cases by pairing compression with declared losses.
Plural mathematical foundations vs FPF simplicityThe intended gain is access to modern plural foundations and applied mathematics, with each selected lens tied to a stated use, declared loss, and neighboring-pattern application.
SoTA openness vs metaphysical safetyVanchurin-like and Sandberg-like material enters as current lens prompts, not final ontology.
General pattern vs local precisionC.29 stays non-duplicative with A.6.P, F.9, C.26, C.28, A.3.3, and A.19; its contribution is coordination around declared mathematical-lens use.
Didactic usability vs formal rigorThe first user needs one small card; expert use needs lens mapping mode, invariant claims, loss, LensUseBoundaryValue, rival lenses, and stop conditions.
Evocative metaphor vs ontology guard“Lens,” “structure survives transfer,” and “where the lens stops” help readers think, while fields named by value recover FPF claim-bearing use or use-boundary claim.
Transfer reach vs domain fitCategory, RG, variational, quantum-like, and learning lenses are useful because they transfer across domains; that same transfer reach makes misuse easy.

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:

Plain reader questionTech recovery
What structure helps?CandidateMathObject or CandidateLensFamily in a LensCandidateNote.
How does it represent the phenomenon?LensMappingMode.
What survives?PreservedStructure.
What disappears or is deliberately ignored?LostStructure.
Why trust this use?LensUseBoundaryValue, validation overlay when validation use is being claimed, and governing evidence and assurance patterns when their claims are being made.
What can the reader now do?NextLensUseAction or declaredLensUse.
When must this use stop or return?StopCondition; include blockedLensOverread? only when it passes F.19's plausible-reader test.

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.

First-principles familyUse when the working problem asksRequired C.29 recoveryStop or neighboring-pattern application
Boundary, exterior derivative, Stokes-like local-to-global relationHow local increments, flows, sources, interfaces, or balances compose into a global claim.Name the domain, boundary, field, form, or flow, derivative, divergence, or curl-like operator, boundary condition, and what is conserved, sourced, or lost at the boundary.Does not make all boundary language one mechanism; measurement, evidence, and bridge claims are governed by C.16, A.10, or F.9.
Cohomology, closed relation and relation named by value split, topological obstructionWhy a local rule cannot be made global, or why a transfer or composition is blocked.Name the cycle or cocycle-like object, equivalence class or obstruction, local closure condition, failed exactness witness or failed global witness, and the blocked claim.Useful obstruction is a LostStructure or StopCondition; it is not a causal explanation without C.28 and evidence.
Symmetry, invariance, equivariance, Noether-like conservationWhich transformations leave the relevant claim unchanged, or which conservation-like quantity follows from an invariance.Name the transformation family, action on the described variables, invariant or conserved quantity, assumptions, and distinctions intentionally lost.Does not transfer physical conservation, coordinate-free truth, or causal mechanism without domain evidence relation and dynamics semantics.
Variational principle, action, energy, free-energy, loss, or value functional, Legendre or convex dualityWhether a behavior, representation, design, or trade-off follows from stationarity, extremum, dual variables, or potential transformation.Name the functional, constrained variation space, constraints, boundary conditions, stationarity or extremum condition, dual transform, and what the dual view makes visible.Does not imply the target literally optimizes that functional unless A.3.3, A.10, or C.28 governs the dynamics semantics, evidence relation, or causal use.
RG, coarse-graining, fixed point, basin, universalityWhy different microdescriptions can share one macropattern, or when a scale claim stops.Name the scale variable, scale window, coarse-graining rule, fixed point or attractor, basin condition or regularity condition, invariant or exponent, and lost microstructure.Scale-law adequacy and general method scale-preference claims are governed by C.18.1 and C.19.1; architecture scale-preference claims are governed by C.31.ASAP; no micro-mechanism identity is licensed.
Diagonal, self-reference, fixed-point theorem, no-go familyWhether a universal evaluator, complete language, self-model, closure rule, or governance rule is blocked by self-application.Name the encoding, evaluator or self-map, diagonal or fixed-point construction, universal claim being tested, and the impossibility or closure boundary named by value.Does not prove every recursive-looking case is a no-go theorem; assurance or governance claims are governed by B.3, E.19, or the local domain pattern.
Composition, category, operad, optic, semiring or limit transformWhether composition, interface, view, transformation, or algebraic law is the useful preserved structure.Name objects, morphisms or relations, composition law, identity or interface condition, preserved algebraic law, failed transfer, and any limit transform such as classical or tropical or Fourier-Laplace or Legendre.Bridge semantics and substitution safety are governed by F.9; C.29 only records the declared lens use and its loss.
Probability, information, observation, acquisitionWhich uncertainty, information, typicality, readout, or next observation changes the next lens-use action.Name the random variables or distributions, utility or information criterion, observation or probe design variable, model assumptions, estimation method, validation boundary, and robustness note.Measurement, evidence, experiment planning, causal-use verdicts, and assurance stay with C.16, A.10, C.28, A.15, and B.3.
Bounded-observer structural information, MDL, epiplexity, compression, or description-recoverability lensWhether a bounded observer can recover enough selected structure from an architecture description, relation trace, generated graph, reusable-structure accounting result, or other source episteme to change the next lens-use action.Name the source episteme or trace, observer boundary, candidate information measure or coding scheme, mapping mode, preserved selected structure, lost structure, visible payoff, observation or postulate boundary, and source-return condition.Does not make epiplexity or compression an architecture characteristic, quality score, selector result, evidence relation, assurance result, OOD guarantee, or causal proof. Architecture, structural-view, reuse-accounting, measurement, evidence, assurance, and bridge claims are governed by C.30, C.30.ASV, C.30.AD, C.31, C.31.RSA, C.16, A.10, B.3, or F.9 when those claims are being made.

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:

MathLensUse.StructuralInformationLensUse@Context:
  TargetPhenomenon:
  SourceEpistemeOrTraceRef:
  BoundedObserverRef or observerBoundary:
  CandidateMathObject:
  LensMappingMode:
  PreservedStructure:
  LostStructure:
  VisiblePayoff:
  ObservationBoundary?:
  PostulateBoundary?:
  SourceReturnCondition?:
  LensUseBoundaryValue:
  declaredLensUse:
  StopCondition:
  blockedLensOverread?:

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.

Local C.29 descriptionCandidate mathematical objectVisible payoffStop condition
MLU.Description@ArchitectureGraphDSMtyped graph, hypergraph, DSM, DMM, or MDM matrixdependencies, clusters, change propagation, and bottlenecksfor semantic interface correctness, compositional quality, or an architecture decision, apply the pattern for that separate claim
MLU.Description@TransformationFlowStructuregraph, morphism-family, wiring, matrix, or network expression over a selected TransformationFlowStructureflow topology, crossings, carried relations, and path slices without hidden scalarizationfor a Work occurrence, gate decision, or evidence claim, apply its subject pattern
MLU.Description@ArchitectureLCAlayered control structure or multi-rate control modelplanner, regulator, plant, observer, feedback timing, and externality separationstability or causal-use questions require their dynamics, evidence, and C.28 basis
MLU.Description@EpiplexityStructuralInformationbounded-observer structural information or two-part codelearnable reusable structure versus residual or unmodeled structureestablish any utility, assurance, out-of-distribution guarantee, or causal-proof claim through its subject pattern
MLU.Description@RGArchitecturescale map over architecture descriptions, fixed-point or basin metaphor, or declared coarse-graining mapscale-stability of an architecture vector and exploding exceptionsa literal physical-RG claim requires its domain theory
MLU.Description@MultilevelLearningFrustrationmultilevel learning over structurally renormalizable descriptions, frustrated optimization landscape, or variational residual modelresidual-reducing architecture moves across declared scopes or holon levelsa project-wide optimization claim requires a separately justified global function

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:

MLU.Description@RGArchitecture:
  TargetPhenomenon:
  CandidateMathObject:
  LensMappingMode:
  ScaleWindow?:
  CoarseGrainingRule?:
  PreservedStructure:
  LostStructure:
  VisiblePayoff:
  SourceReturnCondition?:
  declaredLensUse:
  NextLensUseAction:
  StopCondition:
  blockedLensOverread?:

For architecture work, a common RG-shaped candidate object is:

A_l = (Holons_l, FunctionalRelations_l, FlowRelations_l, ControlRelations_l,
       ModuleRelations_l, InterfaceSpecificationRefs_l, DependencyEdges_l,
       WorkMethodRefs_l, EvidencePackageRefs_l, QualifierRefs_l)

R_l : A_l -> A_{l+1}

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:

MLU.Description@MultilevelLearningFrustration:
  TargetPhenomenon:
  CandidateMathObject:
  LensMappingMode:
  PreservedStructure:
  LostStructure:
  VisiblePayoff:
  declaredLensUse:
  NextLensUseAction:
  SourceReturnCondition?:
  StopCondition:
  blockedLensOverread?:

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 CharacteristicSpace overlay with no domain-transfer, prediction, assurance, publication, or reusable explanation claim, which stays under A.19.
  • the use under repair makes a different kind of claim: use C.11 for a ChoiceResult or local choice record; G.5 for selected-set result declaration; G.9 for selector or benchmark result claims; A.15, A.15.2, and A.15.1 for a selected Method, U.WorkPlan, performed U.Work, or work-result record; E.17 for a source-backed publication face and return to source and E.24.PUB for publication occurrence and availability; or A.15.4 for 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, or A.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:

Claim-bearing questionGovern there firstC.29 remainder
relation-precision structure, relation kind, or structure-preserving relation wordingA.6.P and local relation patterns; A.6.RCD only for the exact residual needed claim after existing direct relations failmathematical-lens use only if a mathematical object changes the stated use; C.29 correspondence does not admit or make the relation obtain
state variables, transition law, observation map, constraints, or calibrationA.3.3 and A.19preserved structure and lost structure and lens stop condition
measurement construction, scale, unit, polarity, or comparabilityC.16lens-use boundary value for measurement-dependent use
scale law, universality, knee, exponent, general method-scale preference, or architecture scale preferenceC.18.1 or C.19.1 for scale-law and general method BLP claims; C.31.ASAP for architecture scale-preference claims over a declared alternative set, scale variable, and scale windowscale-bounded mathematical-lens use
cross-context meaning, bridge use, or substitution useF.9mathematical structure used inside the bridge claim
causal, intervention, policy, or counterfactual useC.28whether the lens preserves, approximates, or blocks causal-use structure
evidence, provenance, source currentness, assurance, release, selector, or benchmark useA.10, B.3, or relevant G.* patterndeclared mathematical-lens use as one input only

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.

  1. 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.
  2. Choose the smallest output class that preserves honesty. The output-class decision happens before any full-card fields.
  3. Name the concrete mathematical object or structure. Family labels such as category theory, field, graph, quantum, RG, or geometry are entry prompts, not adequate CandidateMathObject values for the stated use by themselves.
  4. 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.9 governs that claim; the C.29 fields record only mathematical-lens use for the declared transfer.
  5. State preserved structure and lost structure. This is the central repair action.
  6. State what becomes visible. Name the invariant, obstruction, fixed point, symmetry, conservation law, diagnostic boundary, lens-bounded distinction, model-selection consequence, or other payoff.
  7. 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.
  8. If the claim does not pass, repair rather than merely fail. Downgrade, narrow, switch to a principal rival lens, add LensUseBoundaryValue or validation regime, split any non-lens claim to its governing FPF pattern, or remove the mathematical phrase from claim-bearing use.

Application output classes:

Output classOutputUse conditionRequired content
NoMathLensUseNeededNoMathLensUseNeededNote or ordinary Plain orientationMathematical language is local, didactic, or accepted local theory and is not used for transfer, decision, evidence, assurance, publication, bridge, comparison, or reusable explanation.State why no C.29 output is needed; no card.
LensCandidateNoteMathLensUse.LensCandidateNoteA problem whose next lens-use action can depend on a mathematical lens is stable enough for a first candidate lens, but no adequate mathematical object has been named yet.TargetPhenomenon, ProblemStructureCue, CandidateLensFamily, optional CandidateMathObject?, WhyThisLensCouldHelp, ExpectedVisiblePayoff, ObservableOrControllableCue?, NextLensUseAction, OrdinaryRivalOrFallback, StopCondition, NextMathLensUseOutput.
OneLineMathLensUse.OneLineAn under-specified phrase affects explanation, decision, prediction, comparison, publication, bridge, assurance input, or reusable transfer and needs repair before reuse.TargetPhenomenon, CandidateMathObject, LensMappingMode, PreservedStructure, LostStructure, VisiblePayoff, NextLensUseAction, optional ObservationOrReadoutNeeded?, OrdinaryRivalOrFallback, StopCondition.
MiniCardMathLensUse.MiniCardThe lens is declared usable for a reusable explanation, local decision, comparison, or method-selection claim.OneLine content plus InvariantsExposed, LensUseBoundaryValue, declaredLensUse, optional blockedLensOverread?, principal rival, and RivalLensRelation? when another mathematical lens changes the bounded lens-use action.
FullCardMathLensUse.FullCardPublication, bridge, assurance input, benchmark, model selection, prediction, formal pattern claim, or repeated cross-case use is being made.Full MathLensUse.Card@Context plus any conditional overlays.
NeighborGoverningPatternNoteNeighborGoverningPatternNoteThe claim being made is causal use, bridge or substitution, measurement construction, scale construction, direct comparability, evidence-stub adequacy, dynamics semantics, temporal adequacy, decision result, selected method, work plan, performed work, evidence trust, assurance, explanation rendering, comparative review, representation transition, coarsening, scale law, release, selector, or benchmark.Name the governing FPF pattern and apply C.28, F.9, C.16, A.3.3, C.27, C.11, A.15, A.15.1, A.15.2, A.15.4, A.10, B.3, E.17.EFP, E.17.ID.CR, A.6.3.RT, A.6.3.CSC, C.18.1, C.19.1, or a relevant G pattern. The C.29 application keeps only the declared lens-use result.

Micro-template examples:

Architecture and P2W first-use slice:

MathLensUse.LensCandidateNote@ArchitectureP2W := {
  TargetPhenomenon: cooling-fixture deformation problem accepted as a problem-side distinction,
  ProblemStructureCue: heat-flow balance, boundary condition, interface reference plane, and deformation residual change the next architecture or method-choice question,
  CandidateLensFamily: boundary and variational heat-flow lens,
  CandidateMathObject?: temperature field with boundary-condition relation and optional energy functional,
  WhyThisLensCouldHelp: the lens can expose whether the useful distinction is a preserved heat-flow invariant, a boundary-condition mismatch, or a deformation factor outside the model,
  ExpectedVisiblePayoff: decide whether the next honest output is a C.29 one-line lens use, an A.6.0 FormalSubstrate signature declaration, or an E.18.1 P2W carry-through use of the accepted problem-side distinction,
  ObservableOrControllableCue?: boundary temperatures, heat-flow observations, reference-plane assignment, deformation readout,
  NextLensUseAction: write `MathLensUse.OneLine` only after mapping, preserved structure, lost structure, and stop condition are nameable; apply `A.6.0` only when `U.Signature(profile=FormalSubstrate)` must be declared; apply `E.18.1` only when the accepted problem-side distinction must be used in later FPF work,
  OrdinaryRivalOrFallback: ordinary deformation narrative plus local measurement note,
  StopCondition: keep the candidate note until mapping, preservation, loss, and stop conditions support a one-line use; return to the ordinary deformation narrative if the candidate lens does not change the next action,
  NextMathLensUseOutput: MathLensUse.OneLine or NeighborGoverningPatternNote
}

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.

MathLensUse.LensCandidateNote example := {
  TargetPhenomenon: slow Product-X team flow,
  ProblemStructureCue: waiting and work-in-progress look more important than individual task difficulty,
  CandidateLensFamily: queue or flow lens,
  CandidateMathObject?: single-server or multi-server queue candidate,
  WhyThisLensCouldHelp: arrivals, service time, WIP, and waiting time could expose the bottleneck,
  ExpectedVisiblePayoff: decide whether delay is arrival-rate, service-rate, batching, or WIP-boundary pressure,
  ObservableOrControllableCue?: arrivals, service time, wait time, WIP limit,
  NextLensUseAction: observe the variables before claiming queue adequacy,
  OrdinaryRivalOrFallback: ordinary process narrative without queue assumptions,
  StopCondition: stay with the candidate note until observations support queue adequacy; use the ordinary process narrative if the queue candidate does not change the next action,
  NextMathLensUseOutput: NoMathLensUseNeededNote or MathLensUse.OneLine after observation
}
MathLensUse.OneLine example := {
  TargetPhenomenon: Product-X backlog delay,
  CandidateMathObject: queue model over arrivals, service time, waiting time, and work in progress,
  LensMappingMode: representation,
  PreservedStructure: flow, bottleneck candidates, wait, WIP, service-rate pressure,
  LostStructure: motivation, priority politics, contractual duties, skill learning, quality of work,
  VisiblePayoff: identify whether delay is arrival-rate, service-rate, batching, or WIP-boundary problem,
  NextLensUseAction: observe arrivals, service, wait, and WIP; test one local WIP-limit or batching hypothesis,
  ObservationOrReadoutNeeded?: service-time and wait-time observations,
  OrdinaryRivalOrFallback: process narrative without queue assumptions,
  StopCondition: return to the process narrative or choose another lens when observations do not support the queue representation or its declared losses prevent the next action
}
MathLensUse.MiniCard example := {
  TargetPhenomenon: production-line throughput and latency,
  CandidateMathObject: queueing network with stated stations and service-rate assumptions,
  LensMappingMode: representation,
  PreservedStructure: flow, bottlenecks, service rates, waiting times,
  LostStructure: human meaning, contractual obligations, rare failure modes, causal interventions not represented by the network,
  InvariantsExposed: bottleneck station and queue-length sensitivity under stated assumptions,
  LensUseBoundaryValue: accepted local theory plus local observations,
  declaredLensUse: throughput and latency reasoning inside the declared line model,
  PrincipalRivalLens?: direct empirical dashboard readout,
  RivalLensRelation?: complementary,
  StopCondition: stop or narrow throughput and latency use when the stated service-rate assumptions fail or omitted rare failures affect it; apply C.28 when an intervention claim is needed
}
MathLensUse.OneLine := {
  TargetPhenomenon,
  CandidateMathObject,
  LensMappingMode,
  PreservedStructure,
  LostStructure,
  VisiblePayoff,
  NextLensUseAction,
  ObservationOrReadoutNeeded?,
  OrdinaryRivalOrFallback,
  StopCondition
}

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 := {
  TargetPhenomenon,
  ProblemStructureCue,
  CandidateLensFamily,
  CandidateMathObject?,
  WhyThisLensCouldHelp,
  ExpectedVisiblePayoff,
  ObservableOrControllableCue?,
  NextLensUseAction,
  OrdinaryRivalOrFallback,
  StopCondition,
  NextMathLensUseOutput
}

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:

OutputMeaning
NoMathLensUseNeededNoteOrdinary local math or didactic metaphor; no transfer, decision, evidence, assurance, publication, bridge, comparison, or reusable-explanation use.
MathLensUse.LensCandidateNoteCheap first-candidate note for an under-lensed problem whose next lens-use action can depend on a mathematical lens; not evidence and not a full lens-use card.
MathLensUse.OneLineTarget, mathematical object, lens mapping mode, preserved structure, lost structure, visible payoff, next lens-use action, optional observation or readout needed, ordinary rival or fallback, and stop condition.
MathLensUse.MiniCardOne-line plus invariant or payoff, LensUseBoundaryValue, declared lens use, stop condition, optional grounded overread, and rival-lens relation when disagreement changes the next lens-use action.
MathLensUse.FullCardFull card for publication, bridge, assurance input, model selection, benchmark, prediction, or reusable explanation.
NeighborGoverningPatternNoteA named neighboring FPF pattern defines or constrains the causal, bridge, evidence, scale, dynamics, temporal, decision, work, explanation, comparison, representation, measurement, or assurance claim being made; the C.29 application records only the declared lens-use result.

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.

Lens-use aspectQuestion it answersWhere it is recorded
Mapping constructionHow does the mathematical object represent, abstract, embed, quotient, simulate, learn, or transfer the phenomenon?LensMappingMode, PreservedStructure, LostStructure, and any ScaleWindow? or CoarseGrainingRule?.
Lens-use boundary valueWhat limited lens-use value is declared for this use?LensUseBoundaryValue, validation overlay when validation use is being claimed, and neighboring evidence or assurance patterns when their claims are being made.
Declared lens useWhat can the working reader now do, and when must the use stop or return?declaredLensUse, NextLensUseAction, StopCondition, optional blockedLensOverread?, and named governing FPF patterns.

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:

LensUseBoundaryValue valueDeclared useStop or neighboring-pattern condition
analogy-only promptorientation, hypothesis generation, recognition cuedecision, assurance, causal claim, or publication as established model
diagnosticOnlyfinding a candidate obstruction, bottleneck, mismatch, missing state variable, or rival-lens splitprediction, decision, causal use, bridge substitution, assurance, or ontology without the neighboring-pattern result named by value
formal derivation inside accepted theorylocal explanation or theorem-backed transfer when assumptions holdempirical claim without observation or evidence
simulationcandidate model and scenario explorationreal-world causal or predictive reliance without validation
empirical fitlocal prediction inside validation regimeout-of-regime generalization and causal use
accepted domain theorylocal domain model usecross-context ontology import
SoTA-echo candidatestructured exploration and lens-use testingaccepted FPF law, assurance, release, or foundation claim
mechanized proofformal property under assumptionsreal-world adequacy unless assumptions, bridge, and evidence hold

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:

  1. observe or measure a newly named variable or relation;
  2. compare only under a declared structure and loss boundary;
  3. diagnose a bottleneck, obstruction, mismatch, invariant, or failed transfer;
  4. choose or reject a principal rival lens for this local use;
  5. narrow, downgrade, or block a tempting overread;
  6. 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.

ProblemStructureCueCheap CandidateLensFamilyFirst bounded lens-use action and stop
waiting, backlog, bottleneck, or throughputqueue or flow networkObserve arrivals, work in progress, service time, wait time, and bottleneck candidate; do not infer obligation, motivation, or managerial authority from the queueing lens alone.
state change, trajectory, stabilization, or control pressurestate-space, dynamics, Markov, ODE, or control lensName state, transition law, observation map, and validity window; use A.3.3 for dynamics semantics, temporal aspects to C.27.TA, and temporal-use claims to C.27 when those claims are being made.
conditional-independence boundary, active-inference boundary, Markov blanket, or computational-boundary cueprobabilistic graphical model, Markov-blanket, information-theoretic, active-inference, or contextual-probability lensName variables or states, conditional-independence assumption, observation and action partition, model-use boundary, and stop condition; physical boundary, interface module, component, description, and agency-threshold claims remain with their direct patterns.
dependency, interface, composition, or transfer failuregraph, hypergraph, category, operad, or compositional lensExpose edges, edge meaning, slots, interfaces, composition law, and failed transfer; use F.9 when cross-context meaning or substitution is being claimed.
local-to-global boundary relation, conservation across a boundary, or source balance or sink balanceStokes-like, exterior-derivative, divergence, flux, or boundary-operator lensName the domain, boundary, local rule, boundary condition, and conserved or sourced quantity; do not infer mechanism, evidence, or bridge safety without the relevant subject pattern.
local rule that cannot become a global solution, or a transfer blocked by topologycohomology, closed relation, relation named by value, obstruction, or failed-extension lensName the local closure condition, global witness that fails, obstruction class or equivalent diagnostic boundary, and the blocked claim.
comparison, similarity, distribution shift, population movement, or shape changemetric-space distance, topology, embedding, or optimal-transport lensDeclare what distance, neighborhood, order, embedding, coupling, or transport cost preserves and what it loses; use C.16 for comparability and measurement construction when those claims are being made.
scale transition, coarse behavior, universality, knee, fixed point, or basin-of-attraction cuecoarse-graining, RG, fixed-point, or scaling-law lensName scale variable, scale window, coarse-graining rule, fixed point or attractor, basin condition or regularity condition, and invariants; use C.18.1 for scale-law adequacy, C.19.1 when general method scale-preference or BLP preference is being claimed, and C.31.ASAP when an architecture scale-preference claim is being made.
invariance under transformations, coordinate changes, or conservation-like claimsymmetry, group action, Noether-like, invariant, or equivariant representationIdentify the transformations, invariant or conserved quantity, assumptions, distinctions preserved, and coordinate details lost; do not import physical conservation without evidence.
extremal behavior, trade-off, dual view, potential, or cost relation or resource relationvariational, Lagrangian or Hamiltonian, action, energy, or free-energy, Legendre, convex-duality, or constrained-optimization lensName the functional, variation space, constraints, boundary conditions, stationarity or extremum condition, dual transform, and what the dual view makes visible.
self-reference, universal evaluator, complete-language claim, closure paradox, or impossible total methoddiagonal, fixed-point theorem, no-go, or self-application lensName the encoding, evaluator or self-map, diagonal construction, universal claim tested, and closure or impossibility boundary named by value; do not turn every loop into a no-go theorem.
uncertainty, information value, missing observation, active probe, or next sample choiceprobabilistic, information-theoretic, BED, OED, active-learning, or Bayesian-optimization lensName the variables or distributions, utility or information criterion, design variable, acquisition candidate, model assumptions, estimation method, validation boundary, and robustness note.
intervention, policy effect, or counterfactual questionSCM, causal graph, or causal abstraction lensName the causal object, intervention or assignment, outcome readout, and whether counterfactual structure is preserved, approximated, or not claimed; keep causal-use question and verdict with C.28.
learned scientific representation, latent state, surrogate solver, or operator viewneural operator, latent representation, surrogate solver, or world-model lensAdd the observation map, data or training regime, validation slice, generalization claim, uncertainty or approximation note, and stop condition.
probe effects, order effects, context effects, incompatible frames, or measurement-as-interventionquantum-like or contextual-probability lensUse C.26 for quantum-like adequacy when order effects, probe effects, or context effects are actually being made; block physical quantum ontology unless separate physics evidence is supplied.

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:

First honest entry caseWhat the working reader metFirst C.29 answer
Pre-articulation cueSomething feels structurally wrong, but it is not yet a claim and no stable ProblemStructureCue can be named.Do not impose a mathematical lens. Use C.2.LS, A.16, A.16.1, B.4.1, B.5.2.0, or the relevant language-state pattern first; apply C.29 only when the problem structure is stable enough.
No lens or under-lensed problemA problem situation is stable enough for mathematical help, but no CandidateMathObject has been named.Use MathLensUse.LensCandidateNote: ProblemStructureCue -> CandidateLensFamily -> NextLensUseAction.
Under-specified lensA phrase such as field-like, graph-like, or quantum-like appears, but no object, mapping, preservation, or loss is stated.Write MathLensUse.OneLine or downgrade to ordinary prose.
Useful lens with overreadThe lens is useful, but the text turns it into ontology, evidence, causality, assurance, bridge, or release authority.Use MathLensUse.MiniCard or MathLensUse.FullCard and name blocked use plus neighboring subject pattern.
Ordinary local mathA Markov kernel, ODE, graph data structure, or accepted domain theory appears inside its local domain use.Return NoMathLensUseNeededNote and stay with the local pattern.
Wrong first patternThe reader reaches for C.26, F.9, C.28, C.16, or A.3.3 before knowing whether mathematical-lens use is being made, or reaches for C.29 when a neighbor already governs.Name the first subject pattern and state what C.29 contributes, if anything.

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.19 CharacteristicSpace with 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.

False-negative situationWhy C.29 appliesCheap action
“Something is off, but we cannot yet say whether it is flow, priority, meaning, or evidence.”The cue is not stable enough for ProblemStructureCue.Stay in language-state work first; do not make C.29 create a mathematical lens from an unstable cue.
“We have many tasks waiting, but cannot see where flow slows.”Queue or flow structure can expose bottleneck and WIP boundary.Use MathLensUse.LensCandidateNote for queue or flow; estimate arrivals, service, waiting, and bottleneck.
“This comparison feels important, but distance is unclear.”Metric-space distance, topology, embedding, or transport adequacy is being claimed.Name what comparison preserves and loses before using the comparison.
“We transfer a structure between contexts because it looks the same.”Mathematical-lens use and bridge loss are being claimed.Name preserved structure and lost structure and use F.9 when cross-context meaning or substitution is being claimed.
“A latent space is used as a scientific explanation.”Learned-lens overread is being made.Name observation map, validation slice, generalization boundary, and stop causal or ontology overread.
“The method scales because the mathematics is elegant.”Scale-law adequacy or BLP preference claim is being made.Name scale variable or scale window; use C.18.1 for scale-law adequacy, C.19.1 for general method scale-preference or BLP preference, and C.31.ASAP for architecture scale preference.

Entry guidance states when C.29 is the first subject pattern and when another pattern is first:

Entry situationFirst subject patternTempting wrong first pattern
mathematical-lens use inside a phrase such as "market is a field"C.29C.26, F.9, or A.3.3 before declared lens use is checked
explanation-facing rendering that uses a mathematical lensE.17.EFP; C.29 only for the mathematical-lens use part when that lens affects explanation useC.29 as the first pattern for every explanation
bounded comparative review unit with a mathematical comparison constructionE.17.ID.CR; C.29 only for declared lens use or rival-lens relationC.29 as the comparison or adjudication record
same-EntityOfConcern representation-scheme transitionA.6.3.RT; C.29 only if the transition imports a contested or use-affecting mathematical lensC.29 for every table, diagram, geometry, or notation shift
coarsened rendering useful only under narrower declared lens use and source-bearing reopenA.6.3.CSC; C.29 only if the coarsening depends on mathematical abstraction or coarse-grainingC.29 as source-bearing return or bridge relation
within-context representation adequacyC.29F.9 when no cross-context meaning claim is being made
quantum-like dashboard or probe-order claimC.26 plus C.29 compatibilityphysical quantum ontology
graph state spaceA.19 or A.3.3 unless lens transfer is explicitC.29 for every graph word
category bridge across contextsF.9 for bridge semantics; C.29 only for the declared mathematical-lens-use accountduplicate bridge semantics inside C.29
prediction, rate, trajectory, recovery, convergence, or rhythm claimC.27 when temporal adequacy is being claimed; C.29 only for declared lens usetreating a mathematical prediction cue as enough for temporal-use adequacy
decorative scale languageno C.18.1 or C.19.1 unless scale behavior is being claimedscale-law review for every scale word

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, LensUseBoundaryValue or 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.

Object or claim being madeGoverning FPF patternC.29 contribution
mathematical-lens useC.29Names the C.29 discipline: candidate mathematical object, lens mapping mode, preserved structure and lost structure, invariant or distinction, LensUseBoundaryValue, declared lens use, any justified blocked overread, and stop or return condition.
durable reusable names beyond pattern-local fieldsF.18Cite when MathLensUse names become durable beyond C.29-local use.
broad wording and epistemic precision restorationF.19, E.10, C.2.PUse F.19 for ordinary precise-plain-language repair, E.10 for cues and unresolved wording, and C.2.P for unresolved epistemic meaning.
relation precision, arity, polarity, needed-claim derivation, and slot structureA.6.P, A.6.RCD, A.6.5Apply the direct relation and derivation governors first. C.29 applies only if a mathematical object represents the settled claim or derivation and changes the stated lens use.
object, description, and carrier distinctionA.7Do not identify the phenomenon directly with the mathematical object.
dynamics state space and transition lawA.3.3Assess imported or contested lens use; do not govern dynamics semantics.
CharacteristicSpace, slots, topology, order, and metric-space distance overlaysA.19Apply only when an overlay becomes a domain-transferring or publication-bearing lens.
Decision, selector-result, benchmark-result, or publication-availability claimC.11 for a ChoiceResult or local choice record; G.5 for selected-set result declaration; G.9 for selector or benchmark result use; E.17 for a source-backed publication face and return to source; and E.24.PUB for the publication occurrence and availabilityCan contribute a lens-bounded prediction, distinction, obstruction, diagnostic boundary, or rival-lens note; it does not make the decision, result, or publication claim.
selected method, method-family selection, U.WorkPlan, performed U.Work, work-result record, or work-relevant appearance-based reliance repairA.15, A.15.1, A.15.2, A.15.4Can contribute method-relevant lens use; method, plan, performed Work, and any result record stay with their direct patterns, while A.15.4 only repairs reliance on a misleading appearance.
evidence relation, source currentness, provenance, evidence carrier, or model card or datasheet used as evidenceA.10States LensUseBoundaryValue only; evidence relations and provenance remain A.10 matters.
assurance, readiness, reliability, release confidence, safety, trust, or engineering justificationB.3 plus relevant G patterns when the corresponding claim is being madeTreats declared lens use as possible input only; mathematical elegance does not raise assurance.
measurement construction, scale, unit, or comparability, or evidence-stub adequacyC.16States measurement-dependent LensUseBoundaryValue only; measurement construction, scale, unit, or polarity, direct comparability, and evidence-stub adequacy stay with C.16.
explanation-facing rendering or generated explanation useE.17.EFPStates mathematical-lens use for the mathematical explanation used inside the rendering; explanation-use discipline stays with E.17.EFP.
bounded comparative review unitE.17.ID.CRStates declared lens use for a mathematical comparison construction or rival lens when that construction affects the comparative review use.
same-EntityOfConcern representation-scheme transitionA.6.3.RTApplies only if the representation shift imports a contested or use-affecting mathematical lens.
coarsened rendering with narrower declared lens use and source-bearing reopenA.6.3.CSCApplies only if the coarsening depends on mathematical abstraction, quotienting, or coarse-graining.
cross-context meaning, bridge kind, direction, CL, loss, and substitutionF.9Reference Bridge; do not duplicate Bridge Card semantics.
causal-use question or verdictC.28Block causal overread or cite a C.28 application or CausalUseSupportResultRef.
forecast, rate, trajectory, rhythm, recovery, convergence, stabilization, temporal window, or rate-change used as sufficient for a useC.27Can state a prediction-relevant or distinction-relevant mathematical-lens use; temporal-claim adequacy stays with C.27.
scale-law and Bitter-Lesson preference claimsC.18.1, C.19.1, C.31.ASAPCite scale-window, scale-law, BLP, or architecture scale-preference evidence when scale behavior, general method scale preference, or architecture scale preference is being claimed.
quantum-like modelingC.26Treat C.26 as C.29-compatible specialization, not as full-card inheritance for every QL-lite note.
Selector and benchmark results, parity and SoTA packs, and model-selection publicationsG.5, G.9, G.2, G.10, E.17, and E.24.PUB when publication is currentUse G.5 and G.9 for selector and benchmark result content, G.2 and G.10 for SoTA-pack and shipping claims, E.17 for a source-backed publication face and return to source, and E.24.PUB for an actual publication occurrence and availability. A MathLensUse.* card can contribute declared lens use for a selector or benchmark input only.

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:

AspectFields or refsBoundary
Selected mathematical representation and lens mappingCandidateMathObject, LensMappingMode, PreservedStructure, LostStructure, InvariantsExposedNames the selected mathematical object and the representation or correspondence used for the C.29 account; does not assert world-side participation, identify the phenomenon with the mathematical object, or replace an A.6.0 FormalSubstrate signature.
Use boundary and validationLensUseBoundaryValue, ValidationUseOverlayRef?, LearnedLensOverlayRef?, failure case, uncertainty or approximation noteStates the lens-use boundary value for this lens use; does not create an evidence relation, benchmark result, assurance, or release confidence.
FPF use and boundariesdeclaredLensUse, StopCondition, blockedLensOverread?, BridgeRefSet?, CausalUseDisposition?, AssuranceUseDisposition?, ExportPolicyRef?States what the reader may do, when to stop or return, and which governing FPF patterns define or constrain neighboring claims.

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.

MathLensUse.FullCard base fields:
MathLensUse.Card@Context := {
  TargetPhenomenon,
  entityOfConcernRef?,
  BoundedContext,
  CandidateMathObject,
  LensMappingMode,
  PreservedStructure,
  LostStructure,
  InvariantsExposed,
  LensBoundedPredictionOrDistinction?,
  LensUseBoundaryValue,
  declaredLensUse,
  StopCondition,
  blockedLensOverread?
}

Conditional fields apply only when the corresponding neighboring claim, claim-bearing use, or publication use is being made:

MathLensUse.FullCard conditional fields := {
  DynamicsRef?,
  TransitionLawRef?,
  ObservationMapRef?,
  ScaleWindow?,
  CoarseGrainingRule?,
  SourceReturnCondition?,
  PublicationUseClassification?,
  PrincipalRivalLens?,
  RivalLensSet?,
  RivalLensRelation?,
  ValidationUseOverlayRef?,
  LearnedLensOverlayRef?,
  BridgeRefSet?,
  CausalUseDisposition?,
  AssuranceUseDisposition?,
  ExportPolicyRef?
}

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.

MathLensUse.ValidationUseOverlay@Context :=

  ClaimUse,
  ValidationRegime,
  EvaluationSlice,
  ApproximationOrUncertaintyNote,
  KnownFailureCaseOrCounterexample,
  SensitivityOrRobustnessNote?,
  DomainOfApplicability,
  OutputChangeCondition?

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.

MathLensUse.LearnedLensOverlay@Context :=

  DataOrTrainingRegime,
  ObservationMapRef,
  GeneralizationClaim,
  DiscretizationOrResolutionPolicy?,
  ValidationRegime,
  ApproximationOrUncertaintyNote,
  StopCondition

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:

Tempting overreadStop condition form
out-of-distribution generalizationno generalization outside the declared validation regime
causal mechanismno causal mechanism claim without [C.28](/generated/patterns/C.28) and evidence relation
latent dimension ontologylatent coordinate or factor is not an entity kind without separate ontology and evidence
unobserved-variable recoveryno recovery of hidden variables beyond the declared observation map and validation slice
benchmark superiorityno benchmark or selector superiority outside the declared evaluation slice and relevant G.* record
assurance or release useno assurance, release, or reliability use without [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), and relevant G-pattern result
MathLensUse.CausalAbstractionCheck@Context :=

  LensMappingMode,
  InterventionStructureStatus ∈ {preserved, approximated, notClaimed},
  CounterfactualUseStatus ∈ {preserved, approximated, notClaimed},
  C28ApplicationRef?

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

Failed or missing itemRequired repair
no CandidateMathObjectIf the problem still needs a mathematical lens for the next lens-use action, first name the ProblemStructureCue and write a MathLensUse.LensCandidateNote with the cheapest candidate lens family and next lens-use action; downgrade to ordinary prose or remove the mathematical claim only when no candidate lens changes action.
no LensMappingModeChoose a lens mapping mode or downgrade to analogy-only prompt.
no PreservedStructureRemove the claim-bearing mathematical phrase.
no LostStructureAdd a loss note, downgrade, or justify an equivalence or isomorphism claim through the subject pattern.
no invariant, obstruction, distinction, or payoffKeep the phrase as didactic recognition cue or orientation-only.
no LensBoundedPredictionOrDistinction where decision, prediction, or model selection is being claimedBlock decision or assurance use; downgrade to analogy-only if no declared lens-use consequence is named.
evidence is analogy-onlyBlock decision, publication-as-established-model, assurance, release, and causal use unless evidence relation, validation regime, causal-use relation, or assurance result is supplied by its subject pattern.
no LensUseBoundaryValueBlock decision, publication, assurance, benchmark, and release use.
causal, intervention, policy, or counterfactual overreadApply C.28 or block causal use.
cross-context meaning, export, or substitution overreadApply F.9 or block export and substitution.
scale, universality, knee, exponent, or scale-advantage claimApply C.18.1 or C.19.1, or keep the lens local and bounded by stop condition.
assurance or release useApply A.10, B.3, or relevant G patterns, or block assurance use.
StopCondition is genericName the condition for narrowing or stopping, a no-lens exit, or source-return trigger. Include a blocked overread only when it passes F.19's plausible-reader test.

Field meanings

FieldMeaning selected for C.29Boundary guard
TargetPhenomenonPlain entry prompt naming the phenomenon or situation to be understood.Not a U.Kind, not by itself the exact EntityOfConcern designation of a claim-bearing episteme, and not by itself a publication-side designation or claim about that phenomenon.
entityOfConcernRef?EntityOfConcern reference named by value when the lens appears inside a claim-bearing episteme, PublicationUnit, benchmark, bridge, or assurance-bearing statement.Required only when the lens appears in a claim-bearing episteme, PublicationUnit, benchmark, bridge, or assurance-bearing statement.
BoundedContextContext in which the lens is claimed to work.Cross-context use cites F.9.
CandidateMathObjectConcrete mathematical object, structure, formal position, learned representation, or local formalism.Broad family labels are prompts until narrowed.
LensMappingModeC.29-local lens mapping mode.Stays separate from F.9 BridgeKind, A.6.P RelationKind, C.3 kind, and domain relation kinds; cross-context transfer uses F.9 when bridge semantics are being claimed.
PreservedStructureStructure preserved by the lens in the declared use.No preserved structure means the mathematical phrase cannot justify the stated use.
LostStructureStructure the lens drops, abstracts away, or does not preserve.Empty loss requires explicit equivalence or isomorphism justification through the subject pattern.
InvariantsExposedInvariant, obstruction, fixed point, symmetry, conservation law, diagnostic boundary, or other payoff.If no payoff is visible, downgrade to recognition cue.
ObservableOrControllableCue?Cheap cue naming what can be observed, read out, assigned, varied, or validated before a candidate lens can change action. Examples include arrivals, work in progress, service time, wait time, edge meaning, intervention assignment, outcome readout, observation map, validation slice, scale variable, or scale point.Not a measurement construction, evidence record, causal-use result, or validation verdict. Apply C.16, A.10, C.28, or A.3.3 when those claim types are being made.
ObservationOrReadoutNeeded?Optional one-line note naming the observable, readout, assignment, outcome, validation slice, or scale point still needed before the stated bounded lens-use action is justified.If this missing item makes a measurement, evidence, causal, dynamics, or validation claim being made, that claim is governed by the neighboring pattern governing that claim.
LensBoundedPredictionOrDistinction?Required when prediction, decision, method selection, model selection, or publication-as-model is being claimed.Not required for orientation-only use.
DynamicsRef?, TransitionLawRef?References to dynamics defined by A.3.3 when dynamics semantics are being claimed.C.29 does not define dynamics.
ObservationMapRef?Probe, readout, or observation map when observation makes the declared lens use bounded enough for the stated claim.Required when learned or measurement-dependent lens use is being made.
ScaleWindow?, CoarseGrainingRule?Scale range and coarse-graining or compression rule when scale behavior, macro description or effective description, universality, coarse behavior, latent compression, or renormalized description is being claimed.C.18.1 and C.19.1 govern scale-law and BLP evidence; the C.29 output states only how the lens remains adequate inside the declared window.
SourceReturnCondition?Condition under which the reader must return from the compressed or coarse description to the source-domain variables, observations, cases, or mechanisms.Required only when abstraction, coarse-graining, compression, latent representation, or macro-modeling drops source-domain distinctions that could matter to the stated use.
PublicationUseClassification?Optional note for publication-facing use: orientationOnly, explanationFacing, comparisonInput, decisionInputCandidate, benchmarkInput, assuranceInputCandidate, or reusableModelPublication.Does not publish, release, benchmark, assure, or decide anything by itself; the governing publication, benchmark, evidence, decision, and assurance patterns still govern those claims.
OutputChangeCondition?Condition under which this C.29 output must be narrowed, demoted, replaced, retired from claim-bearing use, or handed to a neighboring FPF pattern.Not a process log or standing state-family record; it states a result boundary for the lens use being made.
OrdinaryRivalOrFallbackOrdinary prose, accepted local theory, direct measurement, or simpler neighboring-pattern application the reader would use without this lens.Required for cheap outputs; prevents prestige bias before broad rival review.
PrincipalRivalLens?Default ordinary or most relevant rival lens.Preferred over a broad literature survey.
RivalLensSet?Broader comparison set only when publication, selection, or claim-bearing comparison is being made.Not a G.5 selector, benchmark harness, or parity result.
RivalLensRelation?Declared relation between the lens in this use and the principal rival or rival set being compared. Allowed local relation values include ordinaryFallback, complementary, sameUseLowerCost, morePreservedStructureHigherCost, lowerErrorOnDeclaredEvaluationCriterion, clearerExplanationForDeclaredReader, bridgeNeedsF9, causalUseNeedsC28, differentScaleWindow, differentLossProfile, incomparableForCurrentUse, blockedByStopCondition, and unresolved. Examples: a queueing lens and a causal lens can be complementary for different lens-use actions; a latent manifold and a causal graph can conflict when latent axes are read causally; an RG-like lens and a micro-dynamics lens can have different scale windows.Names disagreement only; a C.29 output is not a winning-lens choice, literature review, selector result, benchmark result, or parity result. Any superiority claim names the evaluation criterion, reader, cost, scale window, or subject pattern that makes the comparison bounded for use.
LensUseBoundaryValueLocal finite lens-use boundary field.Not evidence, an EvidenceGraph, a PathId, or an assurance score.
BridgeRefSet?Reference to F.9 Bridge material when context crossing is being claimed.Bridge semantics stay with F.9.
CausalUseDisposition?One of noCausalUseClaim, causalUseBlocked, C28ApplicationRef, or CausalUseSupportResultRef.No causal-reference shortcut; no causal verdict from C.29.
AssuranceUseDisposition?One of noAssuranceUseClaim, assuranceUseBlocked, evidenceInputOnly, A10Ref, or B3ApplicationRef.No assurance verdict from mathematical elegance.
declaredLensUseDeclared lens use in this C.29 application.Matches evidence and validation regime.
blockedLensOverread?Optional tempting neighboring use that is blocked or governed by another subject pattern; include it only when it passes F.19's plausible-reader test.Names the neighboring pattern when that neighboring claim is being made. groundedLensOverread? is an alias for this same optional value.
StopConditionCondition for narrowing, stopping, returning to source material, or applying the direct pattern for a neighboring claim.States the concrete boundary of the declared lens use.
ExportPolicyRef?Governed reuse or export policy when publication or downstream reuse is being claimed.Not required for local orientation or mini-card use.

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.P handles relation precision restoration.
  • A.3.3 handles dynamics semantics.
  • A.19 handles characteristic spaces, overlays, normalization, and comparability.
  • F.9 handles cross-context semantics and Bridge loss.
  • C.18.1 and C.19.1 handle scale-law and BLP claims.
  • C.26 handles one specific quantum-like lens family.
  • C.28 handles causal-use question and verdict.
  • A.10 and B.3 handle evidence and assurance.
  • C.11, A.15, A.15.1, A.15.2, and A.15.4 handle 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, and A.6.3.CSC handle explanation-facing renderings, bounded comparative review units, same-EntityOfConcern representation-scheme transitions, and controlled semantic coarsening.
  • C.27.TA handles temporal aspects; C.27 handles 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

Tempting nameReason rejected
Mathematical Ontology PrincipleSmuggles the metaphysical claim C.29 rejects.
Single-Foundation Math StanceWould collapse plural lens families into one foundation claim; C.29 instead tests each selected family by declared mapping, local use, and recoverable loss.
Math Metaphor AdequacyToo narrow and too vague; the selected answer is structure-preserving representation, not mere metaphor.
Quantum-Like GeneralizationMisplaces the general pattern under one special lens.
Category-Theoretic Bridge PatternOver-privileges category theory; C.29 is broader.

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

Earlier wording riskRecovered wording in C.29
source or targetUse source material, cited source-use row, entityOfConcernRef, governing FPF pattern, BridgeRefSet, or pattern reference named by value as appropriate.
raw source intake as evidenceRecovered as source text and source-use rows, not authority. Selected content is integrated through C.29:13a, C.29:13, and the field rows and checklist rows for its claim being made.
structure-preserving identificationRewritten to structure-preserving representation or mapping unless direct equivalence is explicitly the LensMappingMode.
Source compound fields that merge dynamics reference and transition-law referenceRewritten as separate DynamicsRef? and TransitionLawRef? fields.
Procedure-like pattern-control languageRewritten as pattern application, Disposition, BridgeRefSet, C28ApplicationRef, or CausalUseSupportResultRef only when that neighboring-pattern application or causal-use record ref is being cited.
ExportPolicySplit into declaredLensUse, StopCondition, optional blockedLensOverread?, and optional ExportPolicyRef?.
free intensity qualifierReplace with named adequacy fields, evidence relation, scale construction, comparability construction, lens-use boundary value, and stop-condition wording.
model, lens, math as prestige headsRecovered as CandidateMathObject, LensMappingMode, PreservedStructure, LostStructure, and LensUseBoundaryValue.
Causal or assurance implicationsRecovered as CausalUseDisposition? and AssuranceUseDisposition?, with C.28, A.10, B.3, and G-patterns as neighboring governors.

Archetypal Grounding

ArchetypeCandidate lensPreservationLossOutput and stop condition
Production line as queueing networkQueueing networkflow, service rates, bottlenecks, waiting timehuman motivation, contractual duties, rare events not modeledMathLensUse.MiniCard; admits throughput and latency reasoning; narrow or stop when the stated assumptions fail or the use depends on an omitted feature.
Team backlog as queueQueueing lenswork arrival, work in progress, service time, waiting timeobligation, motivation, priority legitimacy, skill learningMathLensUse.OneLine or mini-card; admits bottleneck reasoning; moral or managerial authority, when claimed, needs its own basis.
Manager sees slow throughput but has no lensQueue or flow candidate notepossible arrivals, work in progress, service bottleneck, waiting timemotivation, duty, priority legitimacy, full team ontologyStart with MathLensUse.LensCandidateNote; use MathLensUse.OneLine or mini-card only after the candidate queue or flow lens changes the next lens-use inspection.
Measurement comparison as declared distance or scoring choiceMetric-space distance, embedding, or scoring-function lenscomparability, distance, proximity, clustering, threshold structureevidence relation, causal mechanism, value judgmentMathLensUse.OneLine or mini-card; admits comparison design and sensitivity checks, not truth or priority by itself.
Stabilizing system as state-space dynamicsState-space or transition lensstate variables, transition relation, attractor, control handle when the neighboring relation is named by valueunobserved motivation, obligation, causal mechanism beyond the modelMathLensUse.OneLine or mini-card; admits state inspection or transition inspection, not full dynamics ontology.
Research field as citation graph or category-like networkGraph or categorical structureadjacency, composition, interface, failed transfer, citation or transformation patternssemantic truth, evidence relation, social meaningFirst inspect adjacency, composition, interface, or failed transfer; MathLensUse.MiniCard plus F.9 when contexts cross; never substitute graph proximity for truth or evidence.
Quantum-like dashboardQuantum-like probe and order lensorder effects, probe effects, incompatible frames when actually presentphysical quantum ontologyC.26 with C.29-compatible stop condition QL-NQ; not a full-card cost for QL-lite notes.
RG-like scale-law claimCoarse-graining or fixed-point lensscale variable, coarse-graining rule, invariants across scalesmicro-mechanism identity and universal applicabilityC.29 plus C.18.1 or C.19.1; stops outside scale window.
Learned operator as scientific lensLearned operator, latent space, surrogate solvertrained input-output structure, resolution behavior when validatedcausal mechanism, out-of-domain generalization, unobserved variablesLearned-lens overlay; validation regime and stop condition required.

Worked micro-cases by failure mode:

Failure modeReader seesC.29 repair
No-lens repair"Throughput is slow, but we have no model."Start with a queue or flow MathLensUse.LensCandidateNote; observe arrivals, work in progress, service time, wait time, and bottleneck candidate before using MathLensUse.OneLine or mini-card.
Under-specified-lens repair"The market is a field."Write MathLensUse.OneLine only if the candidate mathematical object, mapping, preserved structure, lost structure, payoff, and stop condition can be stated; otherwise remove the phrase or keep it as ordinary metaphor.
Overread repair"The latent manifold explains reality."Use the learned-lens overlay, name observation map and validation slice, and stop causal or ontology overread unless an exact causal or ontological predicate is defined and current facts satisfy it.
Wrong-neighbor repair"The same graph appears in two contexts, so the meanings are the same."Apply F.9 for Bridge semantics; keep C.29 only for mathematical-lens use.
Local-math non-useAccepted Markov kernel inside local dynamics.Stay in A.3.3; return NoMathLensUseNeededNote if useful; do not use C.29 merely because local mathematics appears.
Speculative SoTA stressVanchurin-style universe-as-learning.Treat as candidate-lens stress, not accepted physics, foundation, assurance, or release input.

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

Bias riskC.29 correction
Mathematical prestige biasRequire CandidateMathObject, LensMappingMode, PreservedStructure, LostStructure, LensUseBoundaryValue, and StopCondition.
Physics envyPhysical source-domain ontology does not transfer without separate proof or evidence and subject pattern.
Category-theory monocultureUse category-theoretic material only when composition, interfaces, views, transformations, or transport structure matters to the stated use; otherwise choose the local lens family that exposes the working cue.
Speculation launderingVanchurin enters as candidate lens or SoTA-echo, not accepted fact.
Over-formalizationLow-consequence analogy can remain local prose; reusable or decision-bearing lens needs a MathLensUse.* card.
Dry ontology driftKeep Plain explanations where they improve recognition, but recover claim-bearing commitments through fields named by value or a named neighboring pattern.
Scale blindnessRequire ScaleWindow?; coordinate scale claims with C.18.1 or C.19.1.
Causal launderingIf the lens licenses causal claims, apply C.28; MathLensUse cannot supply causal use by itself.
Assurance launderingMathematical elegance does not raise R; evidence and assurance use apply A.10, B.3, and relevant G patterns.
Pattern-as-actor wordingA pattern is described as writing, deciding, raising assurance, authorizing work, or creating project records; repair it through claim-bearing text, project-side records, governing FPF patterns, and subject-pattern application, because patterns supply discipline, not agency.

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.

IDRequirementPurpose
CC-C29-0 Use conditionUse C.29 only when a mathematical object, formalism, family, learned representation, or simulation object is used for explanation, decision, prediction, publication, comparison, assurance input, bridge, or reusable transfer.Keeps local analogies lightweight.
CC-C29-1 Output class selected before full cardSelect no-C.29-output-needed, one-line, mini-card, full-card, or NeighborGoverningPatternNote output before presenting full-card fields.Prevents card-before-problem bureaucracy.
CC-C29-2 Named mathematical objectA mathematical phrase affecting explanation, decision, prediction, publication, comparison, assurance input, bridge, or reusable transfer names a concrete CandidateMathObject, not a prestige family label.Blocks prestige vocabulary.
CC-C29-2a Intervention preservationIf LensMappingMode is abstraction, quotient, coarse-graining, macro-model, or simulation and causal use is being claimed, state whether intervention and counterfactual structure is preserved, approximated, or not claimed, then apply C.28 for causal-use question and verdict.Prevents causal abstraction laundering.
CC-C29-3 Lens mapping modeState the C.29-local lens mapping mode and do not use it as F.9 BridgeKind, A.6.P relation kind, or A.6.RCD derivation/admission result. Formula, query, path, graph, diagram, assertion, and definition remain representation or claim-side objects; if bridge semantics are claimed, apply F.9.Prevents hidden bridge, relation-kind, occurrence-identity, or ontology conversions.
CC-C29-4 Preserved structureState what structure the lens preserves.Makes transfer testable.
CC-C29-5 Lost structureState what does not transfer; if nothing is lost, justify an equivalence or isomorphism claim through the subject pattern.Prevents map-territory collapse.
CC-C29-6 Invariants exposedName invariants, obstructions, fixed points, symmetries, conservation laws, dualities, distinctions, or diagnostic boundaries.Makes the lens usefulness visible.
CC-C29-6a First-principles family recoveryWhen a first-principles lens-family row from C.29:4.2b is used for claim-bearing lens use, recover the concrete CandidateMathObject or candidate family, preserved structure, lost structure, visible payoff, lens-use boundary value, and stop condition or neighboring-pattern application for that family.Prevents family names such as boundary, cohomology, symmetry, variational, RG, diagonal, composition, probability, information, or structural-information compression from replacing actual MathLensUse recovery.
CC-C29-6b Bounded-observer structural-information lensWhen MDL, epiplexity, compression, graph information, or description-recoverability changes the next lens-use action, recover TargetPhenomenon, source episteme or trace, bounded observer, candidate measure or code, mapping mode, preserved and lost selected structure, visible payoff, observation or postulate boundary, source-return condition, lens-use boundary value, and stop condition.Prevents C.29 from turning recoverable-structure estimates into architecture ontology, quality, selector, evidence, assurance, OOD, or causal claims.
CC-C29-6c Architecture-local lens descriptionsWhen MLU.Description@RGArchitecture, MLU.Description@MultilevelLearningFrustration, or another architecture-local lens description is used for claim-bearing lens use, recover declared scope or scale window, candidate mathematical object, mapping mode, preserved structure, lost structure, source-return condition, next lens-use action, and stop condition; apply the neighboring patterns define or constraining those claims to architecture, scale-preference, measurement, evidence, assurance, selected-set, and decision claims.Prevents architecture lens descriptions from becoming architecture ontology, RG proof, global-optimizer proof, scale preference, evidence, assurance, selector, or decision authority.
CC-C29-7 Lens-bounded prediction or distinctionWhen decision, prediction, model selection, or publication-as-model is being claimed, state at least one lens-bounded prediction, distinction, obstruction, or diagnostic boundary, or downgrade to analogy-only prompt.Prevents decorative formalism.
CC-C29-8 State, observation, and evidence separationIf state, observation, probe, readout, or evidence is being claimed, apply A.3.3, A.19, C.16, or A.10 as needed.Prevents passive-read and dashboard mistakes.
CC-C29-8a Neighboring claim distributionIf the output being made is a choice result, method or work record, evidence relation, assurance claim, explanation rendering, comparative review unit, representation shift, coarsened rendering, temporal claim, selector, benchmark, or publication-facing use, name the governing FPF pattern and project-side record.Prevents C.29 from absorbing neighboring claims.
CC-C29-9 Scale windowIf scale, universality, knees, exponents, or coarse-graining are being claimed, declare the scale range and coordinate with C.18.1 and C.19.1.Prevents universalization.
CC-C29-9a Temporal use boundaryIf the claim being made is about forecast, rate, trajectory, rhythm, recovery, convergence, stabilization, speed, temporal window, or rate-change as sufficient for a use, cite C.27 or state that temporal adequacy is not being claimed.Prevents mathematical prediction cues from replacing temporal-claim adequacy.
CC-C29-10 Rival lens disciplineUse a principal rival or default ordinary lens by default; require a broader rival set only for selection, publication, or claim-bearing comparison. When a rival relation is being claimed, name the declared relation value and any evaluation criterion, cost, reader, scale window, or neighboring pattern that makes the comparison bounded for use.Prevents unnecessary literature-review work and unnamed lens-superiority claims.
CC-C29-10a Validation regimeIf the lens is used for prediction, publication, assurance input, benchmark, model selection, or scientific claim or model claim, add validation regime, evaluation slice, uncertainty or approximation note, failure case, domain of applicability, and output-change condition when needed.Keeps prediction-bearing and model-bearing uses SoTA-aligned.
CC-C29-10b Source-use relationIf a source changes C.29 declared lens use, name its SourceUseRelation with source material reference, declared C.29 output or lens-use boundary, source-use disposition, source-currentness or supersession condition, and output-change condition. Include a blocked source-prestige overread only when it passes F.19's plausible-reader test.Separates the source-use relation from source-use disposition and makes its governing slots recoverable.
CC-C29-10c Source-currentness and return conditionIf source material, source-use family, source-use decision, or a neighboring subject pattern changes the declared lens-use boundary for this output, state SourceReturnCondition? or OutputChangeCondition? and narrow, demote, replace, retire, or block the claim-bearing use.Keeps SoTA currentness and neighboring-pattern currentness tied to the declared C.29 output rather than to source prestige or process evidence.
CC-C29-11 LensUseBoundaryValueLabel LensUseBoundaryValue as analogy-only prompt, diagnosticOnly, formal derivation, simulation, empirical fit, accepted domain theory, SoTA-echo candidate, or mechanized proof, with a matching declared-use boundary.Prevents evidence laundering.
CC-C29-12 No ontology smugglingDo not import source-domain ontology without separate proof or evidence and subject pattern.Protects FPF from metaphysical collapse.
CC-C29-13 Stop conditionState the condition for narrowing, stopping, returning to source material, or applying a neighboring pattern.Makes closure locally visible.
CC-C29-14 Bridge disciplineCross-context mathematical transfer cites F.9; Bridge and C.29 fields agree without duplicate writing.Keeps semantics bounded.
CC-C29-15 Causal-use disciplineCausal-use claims apply C.28; C.29 cannot carry a causal-use verdict by itself.Blocks causal laundering.
CC-C29-16 Assurance disciplineAssurance, release, reliability, and engineering-justification claims apply A.10, B.3, and relevant G patterns.Prevents elegance from raising assurance directly.
CC-C29-17 C.2.P recoveryBroad heads, source wording or target wording, mapping wording, pattern-application wording, and Plain metaphors are recovered to FPF kinds named by value, fields, neighboring patterns, or explicit non-transfer dispositions.Keeps the pattern from minting parallel ontology.
CC-C29-18 Plain and Tech balanceA Plain sentence can remain when it aids recognition; if it makes ontology, evidence, causal, assurance, bridge, gate, work, decision, or use-boundary commitment, that commitment is recovered through the Tech fields or neighboring pattern.Preserves didactic usefulness without shadow semantics.
CC-C29-19 Non-use and false-positive bankThe pattern includes non-use examples for ordinary local domain equations, local graph data structures, A.19 overlays, local category proofs, and one-off metaphors.Prevents C.29-everywhere.
CC-C29-20 Repair matrixFailed checks map to repair outputs: downgrade, narrow, add loss, add evidence or validation, choose a rival lens, apply a neighbor, block an unsupported use, or stop and return.Keeps C.29 as a repair pattern.
CC-C29-21 Validation harnessStable-pattern review requires the small harness cases in §11a or an accepted equivalent validation record.Makes repeated validation visible without turning the harness into a benchmark mandate.

Common Anti-Patterns and How to Avoid Them

Anti-patternWhat it looks likeRepair
Map-territory collapse“The organization is a quantum system.”“A quantum-like lens models order, probe, or contextual-probability effects; no physical quantum ontology is licensed.”
Prestige substitution“Use category theory” without naming objects, morphisms, functors, preservation, or loss.Name the categorical structure, preserved composition or interface, and failed transfer.
Family-name as objectfield, graph, category, RG, or quantum appears as if the family name were enough.Name the concrete object, structure, formal position, or downgrade to Plain recognition.
C.29-everywhereEvery measurement template, score, graph, kernel, ODE, equation, or local formal object is treated as requiring C.29.Require lens-transfer, publication, assurance, bridge, comparison, or reusable-explanation use.
Card-before-problemThe author fills fields before stating the working phrase and first repair.Begin with the phrase, stated use, output class, and first repair output.
Local-theory over-escalationAccepted local dynamics or domain equations are treated as needing C.29 by default.Keep them under the local domain pattern or A.3.3 unless a separate lens-transfer claim, publication use, assurance input, bridge, comparison, or reusable-explanation use is being made.
False exactnessEquivalence, isomorphism, or representation is declared by value when only analogy, fit, or simulation exists.Downgrade LensMappingMode or justify the declared relation named by value through the subject pattern.
RG-as-vibe“Everything is coarse-graining” with no scale window, coarse-graining rule, or fixed point.Declare scale variable, coarse-graining rule, invariants, and rival micro-models.
Elegant-math overrideA specialized or elegant mathematical lens is selected over a more general or scale-amenable alternative because of elegance or prestige while a general method scale-preference claim or architecture scale-preference claim is being made.Use BLP scale-audit when a general method scale-preference claim is being made; use C.31.ASAP when an architecture scale-preference claim is being made; otherwise mark the lens as local and bounded by C.29 stop condition.
Familiar math misses needed structureA graph, linear trend, average, two-characteristic chart, or score is used because it is familiar while the working problem needs uncertainty, topology, dynamics, causal structure, scale law, distribution geometry, or operator view.Name the working problem cue; choose a lens family that exposes the missing structure, or keep the simple math as local orientation only and block transfer, decision, evidence, assurance, publication, bridge, comparison, or reusable-explanation use.
Vanchurin over-adoption“FPF now says physics is learning.”Mark as candidate lens; retain open questions and evidence limits.
Invariant-free metaphor“Market is a field” with no invariant, transition law, observation map, or LensUseBoundaryValue.Downgrade to local metaphor or build a MathLensUse.OneLine or mini-card.
Loss-free bridgeMathematical structure is exported across contexts without F.9, loss notes, counter-example, or declared lens use.Use F.9 Bridge plus MathLensUse LostStructure and StopCondition.
Duplicate bridge writingC.29 repeats sense cells, CL, substitution scope, and Bridge-declared lens use.Let F.9 write Bridge semantics; cite Bridge from the C.29 output.
LensMappingMode as BridgeKindA local LensMappingMode value is used to skip F.9.Do not define a bridge-valued LensMappingMode; use a local transfer class only for declared lens use and apply F.9 to cross-context meaning, substitution, CL, sense cells, or Bridge-declared lens use.
Causal launderingLens fit is treated as proof of intervention effect.Apply C.28 and evidence design, or block causal use.
Assurance launderingElegant formalism is treated as release confidence.Use A.10 and B.3; C.29 can be evidence input only when LensUseBoundaryValue and validation regime are declared.
LensUseBoundaryValue launderingSoTA-echo candidate sounds like authority.Restrict to exploration or lens-use tests unless validation and neighboring evidence patterns define or constrain prediction, decision, causal use, bridge substitution, assurance, or ontology.
RivalLensSet as literature reviewThe C.29 application produces a survey instead of naming the rival lens being compared.Use PrincipalRivalLens? by default; add RivalLensRelation? when disagreement changes the next lens-use action; broaden to RivalLensSet? only when publication, selection, or claim-bearing comparison is being made.
StopCondition boilerplateThe card says only “does not prove everything.”State the concrete stop, no-lens exit, or source-return condition; include a blocked overread only when it passes F.19's plausible-reader test.
Neighbor absorptionC.29 repeats F.9, C.28, A.3.3, A.19, C.11, A.15, A.10, B.3, C.16, C.27, E.17.EFP, E.17.ID.CR, A.6.3.RT, A.6.3.CSC, or assurance semantics.Apply the subject-pattern table and cite the neighboring pattern.
Plain metaphor carrying law“What survives transfer” becomes an unstated Tech claim.Recover the commitment through C.2.P fields or keep it as ordinary Plain recognition only.
C.29 local-kind inflationMathLensUse.Card is treated as a universal U.* object or durable FPF record.Keep it pattern-local; durable cross-pattern records require explicit minting or reuse, naming, kind, and design-rationale decision through F.8, F.18, C.3, and E.9.

Consequences

BenefitCost or handling
FPF gains a general discipline for mathematical lens use while mathematical lenses stay tied to declared structure, declared loss, and declared lens use.Adds one new pattern; neighboring-pattern applications govern evidence, causal, bridge, assurance, work, decision, publication, and FPF-kind-governance uses.
Existing specialized lenses such as C.26 become easier to explain as special cases.C.26 needs only relation wording, not a rewrite of its core.
Authors get a small checklist before using terms such as field, quantum, category, RG, manifold, graph, or information geometry.Some quick analogies will be downgraded to local prose; this is intended.
Vanchurin-like speculative work can enter as candidate-lens stress tests.Requires strict Adapt-not-Adopt marking.
Cross-domain transfer becomes auditable through preserved structure and lost structure and stop conditions.More upfront statement effort; reduces downstream epistemic precision repair.
C.29 can stay readable rather than becoming a dry ontology form.Requires a Plain and Tech discipline: Plain metaphors can guide recognition, but Tech fields govern claim-bearing uses.

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:

New conditionRequired result
validation slice fails, degrades, or no longer matches the stated regimeChange LensUseBoundaryValue to the updated boundary value, update the failure case, narrow the declared lens use, or block prediction-facing use.
a principal rival lens changes the next lens-use actionAdd PrincipalRivalLens? and RivalLensRelation?, or replace the lens for that use.
the lens becomes decision-facing, publication-facing, assurance-input, benchmark, model-selection, prediction, or repeated cross-case claim inputUse MathLensUse.FullCard and the applicable overlay or governing FPF pattern.
source-use relation becomes outdated, contradicted, or demoted to background onlyChange the SourceUseRelation, update the lens-use boundary value, or retire the lens from claim-bearing use.
bridge, causal, measurement, scale, temporal, evidence, assurance, selector, or benchmark claim is being madeName the governing neighboring pattern and keep C.29 to the declared lens-use part.
abstraction, compression, coarse-graining, or latent representation drops a distinction now needed for the declared useAdd SourceReturnCondition?, narrow the use, or block the compressed-lens claim.

Smallest source-return and output-change conditions:

ConditionRequired result
source material or a source family changes the lens family, validation boundary, limitation, or stated use used by this C.29 outputUpdate SourceUseRelation, LensUseBoundaryValue, and OutputChangeCondition?; narrow, replace, or retire claim-bearing use when the new source-use row no longer fits the declared use.
a later source supersedes or contradicts the source-use decision that bounded the lens useMark the source-use decision as superseded or contradicted for that use, then select a new source-use relation, lower the output class, or block claim-bearing use.
a neighboring subject pattern changes the declared lens-use boundary for measurement, evidence, causal use, assurance, Bridge semantics, scale law, selector, benchmark, decision, or workKeep C.29 only for the declared lens-use part and apply the changed subject pattern to the neighboring claim before the C.29 output is reused.
the same lens family starts carrying validation, causal-use, evidence, assurance, selector, benchmark, release, or work claimAdd the subject-pattern application, or narrow the C.29 result to lens-bounded prediction, distinction, obstruction, diagnostic boundary, or stop condition only.
preserved structure or lost structure can no longer be replayed from the source-domain variables, observations, cases, mechanism, or epistemeAdd SourceReturnCondition?, restate PreservedStructure and LostStructure, lower the output class, or block the compressed-lens claim.

AI-assisted thin-echo result rule:

Thin echo or query shapeRequired result
field-like, quantum-like, category-like, manifold, entropy, RG, graph, embedding, or another mathematical prestige head appears aloneDo not answer from the family label. First name the use under repair or state that no C.29 use is being made.
claim being made is causal, measurement, bridge, evidence, temporal, work, assurance, selector, or benchmark-facingName the governing FPF pattern before any C.29 output.
C.29 still applies after the subject-pattern checkReturn at least CandidateMathObject, PreservedStructure, LostStructure, NextLensUseAction, and StopCondition, or downgrade to LensCandidateNote or NoMathLensUseNeededNote.

C.29 edge-case boundary results:

Edge caseRequired result
mechanized proof of a model propertyState assumptions and proven property; empirical evidence or assurance use stays with A.10, B.3, or relevant G patterns.
simulation-calibrated lensScenario exploration is allowed; prediction, decision, or counterfactual reliance needs validation and the neighboring-pattern result named by value.
latent-space visualizationUse learned-lens overlay and stop latent ontology, causal mechanism, or unobserved-variable recovery unless separately governed by the neighboring pattern governing that claim.
isomorphism or equivalence claim named by valueJustify the relation named by value or downgrade LensMappingMode.
multi-lens compositionName the principal lens and neighboring notes; avoid one giant full card that mixes queue, graph, causal, temporal, and assurance authority.
lens becomes accepted domain theoryKeep local domain theory with the domain pattern; durable FPF naming or kind change needs F.18, C.3, F.8, and E.9.
mathematical notation shift onlyUse A.6.3.RT unless mathematical-lens use changes the declared use.
coarsened explanationUse A.6.3.CSC for source-bearing return, narrowed use, and coarsened rendering; cite C.29 only for abstraction adequacy.

Harness shape:

FieldMeaning
CaseIdStable case id.
InputPhraseThe phrase or claim a cold user might write.
ExpectedFirstPatternC.29, a neighboring pattern, or no C.29 output needed.
ExpectedMathLensUseOutputClassNoMathLensUseNeeded, OneLine, MiniCard, FullCard, or NeighborGoverningPatternNote.
RequiredFieldsMinimal fields or overlays required.
NeighborPatternRefsNeighboring subject patterns named by value when their claims are being made.
ExpectedRepairDowngrade, narrow, add loss, add evidence or validation, choose a rival lens, apply a neighbor, or block an unsupported use.
ExpectedStopConditionConcrete narrowing, stop, source-return, or neighboring-pattern condition.
ExpectedNonUseDecisionPresent only for false-positive cases.

Minimum harness cases:

CaseExpected result
“organization is quantum”C.26 plus C.29 compatibility only if order or probe effects are being claimed; otherwise downgrade to metaphor; physical quantum ontology blocked.
Markov kernel in accepted local reliability modelA.3.3; no full MathLensUse.FullCard unless lens-transfer, publication, assurance, bridge, or reusable explanation is being claimed.
category-like research fieldC.29 mini-card and possibly F.9; semantic truth and evidence relation explicitly lost.
RG-like scale lawC.29 plus C.18.1; scale window and coarse-graining rule required.
Vanchurin-style universe-as-learningcandidate lens only; not accepted physics; stop condition blocks ontology.
queueing production linepositive mini-card; throughput and latency reasoning admitted; human meaning, contractual obligations, and unmodeled rare events remain explicit losses; stop or narrow when assumptions fail or those losses affect the use.
team backlog behaves like a queuemini-card admits waiting and bottleneck reasoning; motivation and duty remain explicit losses; return or change lens when those losses prevent the next action.
same graph formalism in two contextsF.9 governs Bridge semantics; C.29 governs declared lens use.
latent manifold or neural operator as scientific modellearned-lens overlay requires observation map, training regime or validation regime, generalization claim, uncertainty note, and stop condition.

Reader-fit checks for stable-pattern review or material refresh:

ReaderRequired result
engineer-managerCan decide local metaphor, one-line, or mini-card without using the full card by default.
researcherCan state preserved structure, lost structure, and stop condition without turning the pattern into a philosophy-of-mathematics essay.
FPF stewardCan identify the subject pattern for causal, evidence, bridge, scale, measurement, dynamics, temporal, decision, work, explanation, comparison, representation, or assurance claim before accepting a C.29 claim.
SoTA authorCan mark a source as adopt, adapt, reject, or candidate stress test without laundering speculative work into accepted FPF law.
AI-assisted readerRecovers C.29 or the neighboring subject pattern from the query, and does not answer from a thin echo such as field-like, quantum-like, or category-like alone.

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

AlternativeWhy rejected
Keep only local math-lens hooksLeaves no general conformance pattern; C.26-style guardrails do not transfer to non-QL lenses.
Add only a paragraph to A.6.POverloads relational precision restoration with general modeling adequacy.
Add only a paragraph to F.9Bridge discipline is about cross-context semantics; C.29 also governs within-context mathematical representation.
Treat Vanchurin as a new FPF foundationToo speculative and ontology-bearing; selected source-use disposition is candidate-lens stress test only.
Treat Sandberg thread as a foundations listUseful recognition cue, but not a proof source, closed taxonomy, or FPF law.
Require a fixed list of permitted lens familiesWould make first repair depend on list membership instead of declared structure, loss, and declared lens use.
Make mechanized proof mandatory for every C.29 outputToo narrow. Mechanized proof can be one LensUseBoundaryValue value, but adequacy can also rest on accepted domain theory, formal derivation, simulation, or empirical fit.

Pillar impact analysis

PillarImpact
P‑1 Cognitive ElegancePositive: first-principles structure becomes visible without ornamental formalism; one lens-use card replaces many prestige metaphors while example rows stay subordinate to declared fields and declared lens use.
P‑2 Didactic PrimacyPositive: first-minute use starts with the useful question "what structure changes the next lens-use action?", then Plain wording remains backed by recoverable Tech fields.
P-3 Scalable FormalityPositive: admits maturation from ordinary cue to candidate lens, one-line repair, formal derivation, validation regime, or evidence-backed domain theory.
P‑4 Open‑Ended KernelPositive if placed in Part C, not Kernel; avoids making any mathematical family or foundation a kernel axiom.
P‑5 FPF LayeringPositive: C.29 becomes a modular parent pattern or coordinator for specific mathematical lenses while neighboring patterns keep their own authority.
P‑6 Lexical StratificationPositive: separates Plain "lens" from technical CandidateMathObject, LensMappingMode, PreservedStructure, LostStructure, StopCondition, and evidence fields.
P‑7 Pragmatic UtilityPositive if every mathematical-lens use result changes a lens-bounded prediction, distinction, obstruction, model choice, diagnostic boundary, or stop condition.
P‑8 Cross‑Scale ConsistencyPositive: scale windows, coarse-graining, local-global relations, composition, dynamics, symmetry, and boundary conditions become declared rather than assumed.
P-9 State ExplicitnessPositive: state, observation, dynamics, measurement, lens-use boundary value, and stop-condition fields cite A.3.3, A.19, C.16, and A.10 when those claims are being made.
P‑10 Open‑Ended EvolutionPositive: new lens families and first-principles modeling structures can be added without destabilizing Core.
P‑11 SoTA AlignmentPositive: admits current mathematical modeling, applied category theory, scientific machine learning, causal abstraction, learning-dynamics research, and plural foundations without over-adopting them.

Principle-taxonomy balance

PillarC.29 effect
GovNew mathematical-lens use norms require E.9 design-rationale discipline and SoTA discipline when they alter FPF norms.
ArchWrong subject-pattern assignment is blocked; C.29 coordinates but does not replace neighboring patterns.
ontology and episteme distinctionRepresentation, mapping, preservation, loss, and LensUseBoundaryValue are explicit.
PragA useful lens produces a useful prediction, distinction, obstruction, or stop condition; otherwise it remains didactic prose.
DidThe card gives a small first-use check while experts can inspect field meanings named by value.

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 LensUseBoundaryValue affected 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.
SourceUseRelationDeclared C.29 useUse boundary or return
recognitionCueHelp the reader notice an invariant, obstruction, symmetry, duality, state variable, scale cue, or comparison cue.For evidence, truth, ontology, a causal-use verdict, assurance, or release confidence, establish that separate claim and its basis through its subject pattern.
candidateLensPromptSuggest a first candidate lens family or mathematical object to test against the problem cue being repaired.Test a candidate cheaply when it could change the next lens-use action; require use of that lens only after its contribution is established.
adequacyControlSourceDiscipline preserved structure, lost structure, stop condition, validation regime, or neighboring-pattern application.Satisfy C.29's field requirements and the applicable subject pattern for the resulting claim.
validationBoundarySourceConstrain the declared validation regime, evaluation slice, uncertainty, failure case, or domain of applicability.An evidence relation, assurance claim, benchmark result, or release confidence requires its own basis and subject-pattern result.
acceptedDomainTheoryPermit local use inside a domain where the theory is already the governing local formalism.For cross-context ontology import or broader transfer, apply F.9, the needed evidence relation, and a stop condition.
proofUnderAssumptionsJustify a formal property under stated assumptions.A formal proof can support a real-world-adequacy claim only when its assumptions, observations, Bridge, and evidence relation are also established.
negativeExampleExpose failure, obstruction, non-transfer, counterexample, or stop condition.Scope the result to the demonstrated failure and its return condition.
rivalLensSourceName a principal rival lens or relation that changes the bounded lens-use action being made.Keep the principal-rival choice bounded to the current lens-use action. Undertake a literature review, or establish a selector or benchmark result, only for that separately current question.
sourceIdentityLocatorPreserve source identity by value when a source is being cited or traced.Use a separate source-use relation and adequacy basis when the claim needs substantive support.
historicalBackgroundOnlyExplain lineage or terminology.For present-day prediction, decision, Bridge, causal, assurance, or FPF-kind-governance use, establish a current source-use relation and apply its subject pattern.
SoTA lineSelected action-guidance effectDisposition
---------
Applied category theory and compositionalityUse category-theoretic material for composition, interfaces, views, transformations, and transport discipline. Require named structure, preserved composition or interface, lost structure, and failed transfer.Adapt. Useful for composition and interface questions when those structures matter to the stated use.
Obstructions to compositionalityTreat failures and obstructions as first-class LostStructure and StopCondition material.Adapt. A lens can be useful because it names where transfer fails.
Plural foundations of mathematicsAllow multiple structural families with local adequacy, declared mapping, and declared loss.Adopt. Source-use relation: plural-foundations source-use decision.
Geometric deep learning, invariance, and equivarianceUse symmetry, group action, invariance, and equivariant representation as lens-discovery cues when generic feature lists hide the relevant sameness under transformations. Ask which transformations are declared as preserved or invariant, which distinctions are preserved, and which coordinate details can be lost.Adapt as lens-discovery source. Not evidence for domain law, causal mechanism, or coordinate-free truth.
Optimal transport and distribution geometryUse transport plans, couplings, Wasserstein-like geometry, and declared movement cost as lens-discovery cues for population, distribution, shape, shift, or allocation questions. Ask what is transported, under which cost, and what structure or mass is lost.Adapt as lens-discovery source. Not evidence for causality, fairness, mechanism, or policy effect.
Model reporting and responsible modeling practiceIntended use, evaluation conditions, limitations, validation regime, failure cases, uncertainty, and domain of applicability become C.29 validation fields for prediction, publication, assurance-input, benchmark, model-selection, and scientific or model uses.Adapt. Turns reporting practice into fields and repair actions.
Causal and approximate causal abstractionWhen abstraction, quotient, coarse-graining, simulation, or macro-modeling is being claimed, ask whether intervention and counterfactual structure is preserved, approximated, or not claimed; use C.28 for causal-use question and verdict. Approximate abstraction is a source-backed lens-use note, not a softened causal-use grant.Adapt. No C.29 output is causal authority.
Causal representation learningUse causal-representation work as a discovery guard for latent variables, learned factors, interventions, assignments, and invariance across environments. If a latent lens is being read causally, keep causal-use question and verdict with C.28.Adapt as lens-discovery source. Blocks “latent means causal”; does not make representation learning a causal verdict.
Scientific machine learning as hybrid first-principles and data-driven modelingTreat first-principles structures as plural and domain-bound: conservation laws, constitutive relations, boundary conditions, symmetries, known dynamics, numerical stability, uncertainty, and data-driven approximation can each discipline a lens. Require the C.29 user to name the concrete structure and validation boundary rather than saying "science says so."Adapt. Reinforces the first-principles position without making any one SciML family the FPF foundation.
Variational principles and constrained extremaUse action, energy, free-energy, loss, value, entropy, or resource functionals as first-principles lenses only when the constrained variation space, constraints, boundary conditions, stationarity or extremum condition, conserved or dual quantities, and neighboring dynamics applications and evidence applications are named.Adapt as first-principles lens-discovery source. Does not imply the target literally optimizes the declared functional; dynamics, evidence, causal-use, and assurance claims are governed by neighboring patterns.
Physics-informed ML and learned scientific representationsUse physics-informed losses, governing equations, neural operators, surrogate solvers, and learned representations only with observation map, training or simulation regime, resolution or discretization policy, generalization claim, validation slice, uncertainty or approximation note, and stop condition.Adapt. Contributes learned-lens overlay fields; does not license out-of-regime solver replacement, causal mechanism, or unobserved-state truth.
Scientific and physics foundation modelsTreat foundation-model claims in scientific domains as learned-lens stress tests: broad pretraining, in-context dynamics inference, zero-shot or transfer claims, and cross-domain simulation all require declared training regime, task family, validation regime, uncertainty, failure cases, and output-change condition.Adapt as SoTA pressure. A foundation-model result can suggest a candidate lens or benchmark question; it is not accepted FPF law and not a universal first-principles source.
Koopman, operator-theoretic dynamics, and system identificationUse observables, operator representations, dynamic-mode decomposition, and sparse identification as discovery cues for nonlinear dynamics. Name the state, observable or readout, forecast or control use being tested, and the governing dynamics or temporal-use pattern.Adapt as lens-discovery source. Does not prove a real mechanism, dynamics semantics, evidence, or temporal-use adequacy.
Probabilistic programming, Bayesian workflow, and model criticismUse priors, likelihood assumptions, posterior predictive checks, prior-data conflict, model mismatch, and uncertainty as lens-use cues. Ask what the probabilistic lens makes visible, what assumptions it imports, and where prediction or explanation stops.Adapt as lens-discovery and criticism source. Not a truth verdict, evidence verdict, or assurance result by itself.
Modern Bayesian experimental design, OED, active sensing, and adaptive samplingUse modern BED and OED, expected-information-gain estimation, acquisition-function, active-learning, Bayesian-optimization, and robustness results to ask which observation, probe, assignment, fidelity, or sample would change the lens's next lens-use action. Require declared utility, design variable, model assumptions, computational tractability, model-misspecification or robustness note, and validation boundary before using the result for prediction, decision, experiment planning, evidence, causal-use verdict, or assurance.Adapt as current lens-discovery source. Not a measurement construction, evidence record, causal-use result, experiment plan, or assurance claim by itself.
Uncertainty, approximation, sensitivity, and robustness practicePrediction or scientific or model use requires approximation or uncertainty note, known failure or counterexample, and domain of applicability.Adapt. Prevents empirical-fit overread.
Vanchurin 2026Use as structure-dense candidate lens and overclaim stress-test: learning dynamics, coarse-graining, effective geometry, gauge, metric-tensor, or distance language, variational or thermodynamic optimality.Adapt, not adopt. Not central SoTA authority and not accepted physics.
Sandberg structural-sameness examplesUse as recognition examples for invariants, obstructions, dualities, fixed points, symmetries, and conservation-like structures.Adopt as recognition cue and examples, not proof authority.

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:

MathLensUse.OneLine@RodinP2W:
  TargetPhenomenon: accepted problem-side distinction that may need later formal declaration
  CandidateMathObject: one selected formal structure or structural family
  LensMappingMode: exact formal equivalence, interpretation, homomorphism, or near-sameness candidate
  PreservedStructure: the invariant, composition law, obstruction, boundary relation, or formal relation that survives the lens use
  LostStructure: world-facing detail, measurement condition, causal condition, bridge loss, or implementation detail not preserved by the formal relation
  VisiblePayoff: the reader can decide whether a formal declaration is needed before mechanism, method, or work reasoning
  NextLensUseAction: apply `A.6.0` if a `U.Signature(profile=FormalSubstrate)` declaration is needed; apply `E.18.1` if accepted problem-side material must be used through P2W in later FPF work
  StopCondition: return to the subject pattern when the needed claim concerns observation-bound world adequacy, causal use, an evidence relation, Bridge-declared lens use, or work-start conditions; use the formal result within its stated preservation and loss

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 idSource itemWhat it contributesUse in C.29
FPF-CORE-2026Current FPF Core Specification, especially E.9, E.10, F.19, C.2.P, A.6.P, A.3.3, A.19, A.10, A.15, A.15.1, A.15.2, A.15.4, B.3, C.11, C.16, C.18.1, C.19.1, C.26, C.27, C.28, E.17.EFP, E.17.ID.CR, A.6.3.RT, A.6.3.CSC, F.9, G.5, G.9.Governs C.29 adequacy, lexical precision repair, epistemic precision repair, pattern placement, bridge discipline, decision boundaries, work boundaries, evidence boundaries, assurance boundaries, explanation boundaries, comparison boundaries, representation boundaries, state boundaries, measurement boundaries, dynamics boundaries, temporal boundaries, causal-use boundary, and evidence and assurance escalation.Governing inheritance. C.29 applications satisfy E.9. Use F.19 for ordinary wording; apply C.2.P when phrase-local episteme material, publication material, or source-use material needs epistemic precision restoration.
SAND-THREAD-MATH-LINKS-2026-05-12Accessible mirror of Sandberg thread, lines headed “Math,” linking to the original X post.Recognition examples of structural sameness: generalized Stokes, CLT as RG or fixed-point interpretation, Lawvere-style diagonal family, Noether, Legendre transforms.Adopt as recognition cue and examples, not proof authority. Direct X content was not treated as a formal source.
VAN-GEOM-LEARNING-2025/2026Vitaly Vanchurin, Geometric Learning Dynamics, arXiv:2504.14728 v3, last revised 2026-03-14 and accepted for publication in Biological Cybernetics.Candidate lens family: geometric learning dynamics over the relation between metric tensor, noise covariance, and learning regime; useful as a replayable source for metric-tensor, noise-covariance, and learning-dynamics lens selection.Adapt, not adopt. Use as SoTA-echo candidate lens or stress test for CandidateMathObject, LensMappingMode, preserved structure and lost structure, validation boundary, and stop condition; do not accept the physical or biological interpretation as FPF law.
RODIN-2023Andrei Rodin, One Mathematic(s) or Many? Foundations of Mathematics in Today's Mathematical Practice, arXiv:2301.08131.Contributes plural-foundations source material and mutual-interpretability caution.Adopt as source material for multiple structural families checked through local adequacy, declared mapping, and recoverable loss.
FONG-SPIVAK-2018/2019Brendan Fong and David I. Spivak, Seven Sketches in Compositionality and An Invitation to Applied Category Theory, arXiv:1803.05316 and book publication context.Contributes applied category theory as one useful family for composition, interfaces, views, transformations, and bridges.Adopt and adapt for examples and transport discipline when those structures matter to the stated use.
GDL-BRONSTEIN-2021Bronstein et al., Geometric Deep Learning: Grids, Groups, Graphs, Geodesics, and Gauges, arXiv:2104.13478.Contributes lens-discovery cues through symmetry, invariance, equivariance, group action, geometric structure, and graph structure.Adapt as discovery source. Helps find a candidate lens; does not supply domain evidence, causal mechanism, or validation by itself.
PEYRE-CUTURI-2019Gabriel Peyré and Marco Cuturi, Computational Optimal Transport, arXiv:1803.00567 and Foundations and Trends in Machine Learning publication context.Contributes distribution-geometry discovery cues through transport plans, couplings, Wasserstein-like distances, movement cost, and shape or population shift.Adapt as discovery source. Helps formulate comparison and movement questions; does not supply causal, fairness, mechanism, or policy-effect evidence by itself.
PUCA-ETAL-2023Puca, Hadzihasanovic, Genovese, Coecke, Obstructions to Compositionality, arXiv:2307.14461.Contributes source material for making failures and obstructions to compositional transfer explicit.Adapt into LostStructure, StopCondition, and checks that not every transfer preserves the needed structure.
MODEL-REPORTING-2018/2021Mitchell et al., Model Cards for Model Reporting; Gebru et al., Datasheets for Datasets.Contributes intended-use, evaluation-condition, limitation, dataset-context, and out-of-scope-use declarations for model and data-bearing lenses.Adapt. Use for declaredLensUse, StopCondition, validation regime, limitation notes, domain-of-applicability fields, and optional blockedLensOverread? when it passes F.19's plausible-reader test; establish evidence or assurance separately.
CAUSAL-ABSTRACTION-2017/2019Rubenstein et al., Causal Consistency of Structural Equation Models; Beckers and Halpern, Abstracting Causal Models.Contributes the question of whether abstraction, quotient, macro-model, or coarse-graining preserves intervention and counterfactual structure.Adapt. Contributes to MathLensUse.CausalAbstractionCheck; causal-use question and verdict still belongs to C.28.
APPROX-CAUSAL-ABSTRACTION-2019/2020Beckers, Eberhardt, and Halpern, Approximate Causal Abstraction and Approximate Causal Abstractions, arXiv:1906.11583 and PMLR 2020.Contributes the distinction between approximate and exact micro-to-macro causal abstraction, including discrepancy between micro-model and macro-model causal descriptions and uncertainty in probabilistic causal models.Adapt. Justifies the approximated value in MathLensUse.CausalAbstractionCheck; causal-use question and verdict still belongs to C.28.
CAUSAL-ABSTRACTION-JMLR-2025Causal Abstraction: A Theoretical Foundation for Mechanistic Interpretability, JMLR 2025.Contributes generalized mechanism transformation, graded faithfulness, and abstraction checks for learned systems, including where representation mappings become too flexible to license explanation or causal use.Adapt. Strengthens the abstraction-preservation question; causal-use question and verdict still belongs to C.28.
SCHOLKOPF-ETAL-2021Scholkopf et al., Towards Causal Representation Learning, Proceedings of the IEEE 2021, arXiv:2102.11107.Contributes distinctions among learned latent representations, causal variables, interventions, assignments, environment invariance, and causal-use claims.Adapt as discovery source. Helps detect when C.28 applies; does not make a latent representation causal by itself.
SCIML-NEURAL-OPERATORS-2019/2021Raissi, Perdikaris, and Karniadakis on PINNs; Karniadakis et al. on physics-informed machine learning; Lu et al. on DeepONet; Li et al. on Fourier neural operators.Contributes learned-lens obligations: observation map, data or training regime, discretization or resolution policy, generalization claim, validation regime, uncertainty, and stop condition.Adapt. Use as source material for the lightweight learned-lens overlay; do not promote a full SciML specialization or assume out-of-domain generalization.
SCIML-DIETRICH-SCHILDERS-2025Dietrich and Schilders, Scientific machine learning, Mathematische Semesterberichte 2025, DOI 10.1007/s00591-025-00399-4.Contributes the hybrid first-principles and data-driven framing: conservation laws, constitutive relations, boundary conditions, physical consistency, operator learning, probabilistic approaches, uncertainty, robustness, and validation limits.Adapt. Reinforces plural first-principles discipline and validation boundaries; does not make SciML a universal FPF foundation.
PIML-SURVEY-2025When physics meets machine learning: a survey of physics-informed machine learning, Machine Learning for Computational Science and Engineering 2025, DOI 10.1007/s44379-025-00016-0.Contributes physics-informed learning as integration of prior physics knowledge with data-driven models for data efficiency, generalization, and plausibility, including Lagrangian or Hamiltonian mechanics, energy conservation, physics-informed losses, and physics-informed optimization as current first-principles lens families.Adapt. Strengthens the learned-lens and variational-principle use; does not make physics-informed wording sufficient evidence or assurance.
NEURAL-OPERATORS-NRP-2024Neural operators for accelerating scientific simulations and design, Nature Reviews Physics 2024, DOI 10.1038/s42254-024-00712-5.Contributes neural operators as learned mappings between functions over continuous domains, often constrained by physics and domain structure, with generalization and validation boundaries.Adapt. Contributes operator lens discovery and function-space lens discovery and validation-regime prompts; does not license out-of-regime solver replacement.
PHYSICS-FOUNDATION-MODEL-2025Towards a Physics Foundation Model, arXiv:2509.13805.Contributes SoTA pressure around broad pretraining, in-context dynamics inference, cross-domain simulation, zero-shot transfer, and long-horizon prediction.Adapt as candidate and stress-test. Does not make a foundation model accepted physics, causal-use verdict, assurance, or a universal first-principles source.
KOOPMAN-SINDY-DMD-2016Brunton, Proctor, and Kutz, Discovering governing equations from data by sparse identification of nonlinear dynamical systems; Kutz et al., Dynamic Mode Decomposition: Data-Driven Modeling of Complex Systems.Contributes operator and system-identification discovery cues through observables, dynamic-mode decomposition, sparse identification, forecast use, and control-oriented representation.Adapt as discovery source. Does not make the identified operator a real mechanism or validate temporal-use claims by itself.
BAYES-WORKFLOW-PPL-2018/2020van de Meent et al., An Introduction to Probabilistic Programming; Gelman et al., Bayesian Workflow.Contributes probabilistic-model discovery and criticism cues through priors, likelihood assumptions, posterior predictive checks, prior-data conflict, model mismatch, uncertainty, and iterative model revision.Adapt as discovery and criticism source. Does not make posterior fit truth, evidence, or assurance by itself.
MODERN-BED-2023/2024Rainforth, Foster, Ivanova, and Bickford Smith, Modern Bayesian Experimental Design, arXiv:2302.14545; accepted/published in Statistical Science context.Contributes current BED as utility-driven and computationally constrained, with recent methods for tractable expected information gain, sequential or adaptive design, and practical deployment limits.Adapt as current discovery source. Does not make C.29 a measurement-construction, evidence, causal-use, or experiment-planning pattern.
MODERN-OED-2024/2026Huan, Jagalur, and Marzouk, Optimal experimental design: Formulations and computations, Acta Numerica 2024; arXiv:2407.16212 v2 2026.Contributes broad current OED framing: design variables, utility criteria, computational methods, sequential design, complex models, and prediction-oriented data acquisition.Adapt as current discovery source. C.29 may ask what data acquisition would make the lens usable, but neighboring patterns define or constrain experiments, evidence, causal-use verdict, and work planning.
BO-AL-ADAPTIVE-SAMPLING-2024Di Fiore, Nardelli, and Mainini, Active Learning and Bayesian Optimization: A Unified Perspective to Learn with a Goal, Archives of Computational Methods in Engineering 2024, DOI 10.1007/s11831-024-10064-z.Contributes active learning, Bayesian optimization, and adaptive sampling as goal-driven acquisition schemes, not as generic "collect more data" advice.Adapt as current discovery source. Use only for the candidate observation, probe, or acquisition action; do not import selector, evidence, or assurance authority.
EIG-DENSITY-APPROX-2024/2026Li, Baptista, and Marzouk, Expected information gain estimation via density approximations: Sample allocation and dimension reduction, arXiv:2411.08390 v3 2026.Contributes current computational caution: EIG estimation itself can require density approximation, sample-allocation, and dimension-reduction choices before it is usable.Adapt as computational-tractability source. A claimed information-gain lens needs estimation and approximation fields when the computation is required for the declared lens use.
ROBUST-GBOED-2025Barlas, Sloman, and Kaski, Robust Experimental Design via Generalised Bayesian Inference, arXiv:2511.07671.Contributes robustness prompts for model misspecification, outliers, and incorrect noise assumptions through generalized Bayesian OED or Gibbs Bayesian OED and Gibbs expected information gain.Adapt as robustness source. If model misspecification is plausible, the C.29 output records the robustness note; it does not turn robustness into evidence or assurance by itself.
VVUQ-UQ-PREDICTION-2010/2012/2007Oberkampf and Roy, Verification and Validation in Scientific Computing; National Research Council, Assessing the Reliability of Complex Models; Gneiting and Raftery, Strictly Proper Scoring Rules, Prediction, and Estimation.Contributes validation, uncertainty, prediction scoring, calibration caution, sensitivity or robustness notes, and domain-of-applicability boundaries.Adapt. Prediction, publication-as-model, benchmark, model-selection, or assurance-input uses need validation or uncertainty fields; source prestige does not supply those fields.

Source locators and recoverability.

Source idLocator(s)Recoverability and use in C.29
SAND-THREAD-X-2026-05-12Original X post locator: https://x.com/anderssandberg/status/2053757849918939364Source identity locator. Keep the X link because the source being mirrored matters. Do not rely on direct X content as proof text unless the post content is actually retrievable in the checking environment.
SAND-THREAD-MATH-LINKS-2026-05-12Accessible mirror or quotation carrier: https://axisofordinary.substack.com/p/links-for-2026-05-12, section headed Math, linking to the X post above.Checked source-text carrier. Supplies the recognition examples: generalized Stokes and boundary-exterior derivative duality; de Rham, cohomology, and topological obstruction; CLT as RG viewpoint or fixed-point viewpoint; Lawvere-style diagonal family; Noether and symmetry-conservation; Legendre, duality, and tropical-limit family.
VAN-GEOM-LEARNING-2025/2026https://arxiv.org/abs/2504.14728; arXiv v3 revised 2026-03-14; accepted in Biological CyberneticsCandidate-lens source. Supplies a replayable geometric-learning-dynamics source for metric tensor, noise covariance, learning-regime, and validation-boundary questions. Use as SoTA-echo stress test for lens selection and stop condition; do not use as accepted physics, biological mechanism, evidence, assurance, or FPF law.
RODIN-2023https://arxiv.org/abs/2301.08131Plural-foundations source. Contributes multiple interpretable mathematical foundations or families checked through local adequacy, declared mapping, and recoverable loss.
FONG-SPIVAK-2018/2019https://arxiv.org/abs/1803.05316; Cambridge page: https://www.cambridge.org/core/books/an-invitation-to-applied-category-theory/D4C5E5C2B019B2F9B8CE9A4E9E84D6BCApplied-category-theory source. Contributes category theory as one useful organizer for composition, interfaces, views, transformations, and bridges when those structures matter to the stated use.
GDL-BRONSTEIN-2021https://arxiv.org/abs/2104.13478Geometric-deep-learning discovery source. Contributes symmetry, invariance, equivariance, group action, graph structure, and geometric structure cues for candidate-lens discovery; not evidence that a domain law, causal mechanism, or validation claim holds.
PEYRE-CUTURI-2019https://arxiv.org/abs/1803.00567Optimal-transport discovery source. Contributes transport plans, couplings, Wasserstein-like geometry, costed movement, and distribution, population, shape, shift, or allocation comparison; not causal, fairness, mechanism, or policy-effect evidence by itself.
PUCA-ETAL-2023https://arxiv.org/abs/2307.14461Obstruction source. Contributes source material for making failures of transfer explicit; feeds LostStructure, StopCondition, and the rule that not every functor-like transfer preserves the needed structure.
MODEL-CARDS-2018/2019https://arxiv.org/abs/1810.03993Model-reporting source. Supplies intended-use, evaluation-slice, limitation, and out-of-scope-use structure for model-bearing lenses; does not make reported model use bounded by itself.
DATASHEETS-2018/2021https://arxiv.org/abs/1803.09010; CACM page: https://cacm.acm.org/research/datasheets-for-datasets/Dataset-documentation source. Supplies provenance, composition, collection, recommended use, and limitation prompts when a lens depends on data or dataset-derived representation.
CAUSAL-CONSISTENCY-2017https://arxiv.org/abs/1707.00819Causal-abstraction source. Contributes a check for whether SEM descriptions at different granularities agree about intervention effects; feeds the intervention-preservation question without giving C.29 causal authority.
CAUSAL-ABSTRACTION-2019https://arxiv.org/abs/1812.03789; AAAI page: https://ojs.aaai.org/index.php/AAAI/article/view/4117Causal-abstraction source. Contributes distinctions among transformations, abstractions, and named abstraction classes; used only to require explicit C.28 application when causal use is being claimed.
APPROX-CAUSAL-ABSTRACTION-2019/2020https://arxiv.org/abs/1906.11583; PMLR page: https://proceedings.mlr.press/v115/beckers20a.htmlApproximate causal-abstraction source. Contributes approximated intervention and counterfactual preservation value in the lightweight causal-abstraction check; does not let C.29 decide causal-use question and verdict without C.28.
CAUSAL-ABSTRACTION-JMLR-2025https://jmlr.org/beta/papers/v26/23-0058.htmlCurrent causal-abstraction source. Contributes generalized mechanism-transformation and graded-faithfulness checks for learned systems; keeps causal-use question and verdict with C.28.
SCHOLKOPF-ETAL-2021https://arxiv.org/abs/2102.11107; DOI 10.1109/JPROC.2021.3058954Causal-representation discovery source. Contributes the question whether a learned latent representation has intervention, assignment, outcome, and environment-invariance evidence relation before causal use; causal-use question and verdict are governed by C.28 when causal use is being claimed.
PINN-2019DOI 10.1016/j.jcp.2018.10.045Physics-informed ML source. Contributes validation, training-regime, governing-equation, and inverse-problem and forward-problem distinctions for learned mathematical lenses.
PIML-2021DOI 10.1038/s42254-021-00314-5Physics-informed machine-learning survey source. Contributes physics-informed learning as a broad learned-lens family requiring problem, prior-knowledge, validation, and uncertainty boundaries.
DEEPONET-2021DOI 10.1038/s42256-021-00302-5Neural-operator source. Contributes operator-learning as a learned mathematical lens over function spaces; requires training domain, observation map, generalization claim, and stop condition.
FNO-2020/2021https://arxiv.org/abs/2010.08895Neural-operator source. Contributes resolution and PDE-family generalization checks; does not license out-of-regime solver replacement without validation.
SCIML-DIETRICH-SCHILDERS-2025DOI 10.1007/s00591-025-00399-4; https://link.springer.com/article/10.1007/s00591-025-00399-4Current SciML survey source. Contributes hybrid first-principles and data-driven framing, physical consistency, operator learning, probabilistic approaches, uncertainty, robustness, and validation limits.
PIML-SURVEY-2025DOI 10.1007/s44379-025-00016-0; https://link.springer.com/article/10.1007/s44379-025-00016-0Current physics-informed ML survey source. Contributes prior-physics integration as data-efficiency, generalization, and plausibility cues; not evidence or assurance by itself.
NEURAL-OPERATORS-NRP-2024DOI 10.1038/s42254-024-00712-5; https://www.nature.com/articles/s42254-024-00712-5Neural-operator review source. Contributes function-space lens obligations and operator lens obligations, physics constraints and domain constraints, and validation boundaries for scientific simulation and design.
PHYSICS-FOUNDATION-MODEL-2025https://arxiv.org/abs/2509.13805Physics-foundation-model candidate source. Contributes candidate and stress-test handling of broad scientific foundation-model claims; does not make those claims accepted FPF law.
KOOPMAN-SINDY-DMD-2016SINDy DOI 10.1073/pnas.1517384113; DMD DOI 10.1137/1.9781611974508Operator-dynamics and system-identification discovery source. Contributes observable, dynamic-mode-decomposition, or sparse-identification lens choices for nonlinear dynamics; dynamics semantics, evidence, and temporal-use adequacy still require A.3.3, A.10, or C.27 when those claims are being made.
BAYES-WORKFLOW-PPL-2018/2020Probabilistic programming arXiv https://arxiv.org/abs/1809.10756; Bayesian Workflow arXiv https://arxiv.org/abs/2011.01808Probabilistic-model discovery and criticism source. Contributes prior, likelihood, posterior predictive, prior-data conflict, model mismatch, uncertainty, and revision cues; does not make probabilistic fit a truth, evidence, or assurance result by itself.
MODERN-BED-2023/2024https://arxiv.org/abs/2302.14545; DOI 10.48550/arXiv.2302.14545Modern Bayesian experimental design source. Contributes current BED as utility-driven and computationally constrained, with tractable EIG, sequential/adaptive design, and deployment limits; neighboring patterns still govern measurement construction, evidence, causal-use verdict, and work planning.
MODERN-OED-2024/2026https://arxiv.org/abs/2407.16212; Cambridge Core DOI 10.1017/S0962492924000023Modern optimal experimental design source. Contributes broad OED formulations and computations for complex models; C.29 uses it only to ask what acquisition would make a candidate lens usable.
BO-AL-ADAPTIVE-SAMPLING-2024DOI 10.1007/s11831-024-10064-z; https://link.springer.com/article/10.1007/s11831-024-10064-zAdaptive-sampling source. Contributes goal-driven acquisition and the BO and active-learning relation; does not create selector, evidence, or assurance authority.
EIG-DENSITY-APPROX-2024/2026https://arxiv.org/abs/2411.08390; DOI 10.48550/arXiv.2411.08390EIG computation source. Contributes density-approximation, sample-allocation, and dimension-reduction caution for expected-information-gain claims.
ROBUST-GBOED-2025https://arxiv.org/abs/2511.07671; DOI 10.48550/arXiv.2511.07671Robust experimental-design source. Contributes generalized-Bayesian robustness checks for model misspecification, outliers, and incorrect noise assumptions.
OBERKAMPF-ROY-2010Cambridge page: https://www.cambridge.org/core/books/verification-and-validation-in-scientific-computing/contents/9399D588DE8B3D49E392CF0436D5A67DVerification-and-validation source. Contributes separation of verification, validation, uncertainty, calibration, and prediction-use boundaries.
NRC-VVUQ-2012DOI 10.17226/13395; https://nap.nationalacademies.org/catalog/13395/assessing-the-reliability-of-complex-models-mathematical-and-statistical-foundationsVVUQ source. Contributes uncertainty-quantification and reliability-limit fields for complex model use.
GNEITING-RAFTERY-2007DOI 10.1198/016214506000001437Prediction-scoring source. Contributes proper-scoring and prediction-evaluation fields when a lens claims predictive use.

Source-use boundary notes

  1. VAN-GEOM-LEARNING-2025/2026 is 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 on CandidateMathObject, LensMappingMode, preserved and lost structure, validation boundary, and stop condition.
  2. 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.
  3. SAND-THREAD-MATH-LINKS-2026-05-12 is a recognition cue, not a mathematical proof source or FPF law.
  4. 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.
  5. 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.

Lens familyWhat it catchesFPF useCommon stop conditionLikely neighboring patterns
Boundary, Stokes, and cohomologyBoundary operators, exterior-derivative or divergence-like local-to-global relations, flows, closed relation and relation named by value splits, and topological obstructions.Use when local rules, interfaces, flows, or balances must be related to a global claim or blocked global extension.Does not license all boundary phenomena as the same physical mechanism; evidence, measurement, and bridges remain neighboring work.F.9, A.19, C.16, A.10
Obstruction-first and failed-transfer lensImpossibility, incompatibility, failed composition, blocked transfer, missing invariant, or diagnostic boundary.Use when the useful mathematical result marks where a transfer, comparison, model, or simplification stops.Does not make the rival claim true or the failure cause known without the neighboring-pattern result named by value.F.9, A.6.P, A.10, E.19
Symmetry, invariance, equivariance, and NoetherGroup actions, invariants, equivariant representations, conservation-like constraints, and geometric-deep-learning regularities.If the problem depends on sameness under transformations or a conservation-like claim, ask which transformations are declared as preserved or invariant, what remains invariant, and which distinctions are lost.Does not transfer physical conservation law, causal mechanism, or coordinate-free truth without domain evidence.A.10, C.16, A.19, domain pattern
Variational, action, optimization, and LegendreAction, energy, free-energy, loss, value, entropy, or resource functionals; stationarity, extrema, dual variables, potentials, and Legendre or convex duality.Use when the useful lens is an extremal condition, constrained variation space, boundary condition, dual view, or trade-off.Does not imply the target literally optimizes unless dynamics and evidence-provenance claims are governed by their neighboring patterns.A.3.3, C.28, A.10, G.6
Diagonal, self-reference, and no-goSelf-application, universal evaluators, closure limits, diagonal constructions, and impossibility boundaries.Use when the payoff is to block a tempting universal claim or expose a closure boundary.Does not prove every recursive-looking case is a diagonal or no-go case.B.3, E.19, local domain pattern
RG, coarse-graining, fixed point, and universalityWhy different micromodels yield one macropattern; fixed points, basins, scale windows, universality classes, or stable-law-like alternatives.Use for scale transitions, abstraction, domain compression, and macropattern claims that require a declared scale variable and coarse-graining rule.Does not assert micro-mechanism identity or universal applicability outside ScaleWindow.C.18.1, C.19.1, A.3.3
Category, compositionality, optics, and semiring-limitComposition, interfaces, views, transformations, algebraic laws, limit transforms, and cases where changing algebra changes what is preserved.Multi-view architecture, bridges, system composition, and classical or tropical or Fourier-Laplace or Legendre-style transform cues.Does not imply all target objects are categories or that every functor-like transfer preserves the needed structure.F.9, A.6.P, A.19
Information geometry and learning dynamicsUpdate, curvature, optimization trajectory.Adaptive systems, learning agents, epistemic dynamics.Does not license “everything is learning” ontology.A.3.3, A.10, C.28
Optimal transport and distribution geometryTransport plans, Wasserstein-like geometry, couplings, costed movement between distributions, populations, shapes, or allocations.Use when the question is how one distribution, population, shape, or allocation can move toward another under declared costs and losses.Does not license causality, fairness, mechanism, or policy effect by itself.C.16, A.10, C.28, D.5
Operator learning, SciML, and latent representationsLearned function-to-function operators, neural operators, surrogate solvers, embeddings, and world-model representations.Use when the first useful lens is an operator over functions, states, or fields; name the observation map, training or simulation regime, validation slice, and generalization boundary.Does not license out-of-domain solver replacement, causal mechanism, or unobserved state truth without validation and the neighboring-pattern result named by value.A.10, C.16, A.3.3, C.28
Koopman and operator-theoretic dynamicsObservables or coordinates where nonlinear dynamics can be represented by an operator, often approximately linear.Use when nonlinear dynamics need a tractable forecast, control, or diagnostic representation; name the observable or readout and the forecast or control use being tested.Does not prove a real linear mechanism or temporal-use adequacy; dynamics semantics, evidence, and temporal claims stay with A.3.3, A.10, and C.27.A.3.3, A.10, C.27
Causal representation and causal abstractionCausal graphs, SCMs, causal representation learning, micro-to-macro mappings, quotient models, and intervention-preservation questions.If the user asks what to change to get an effect, test causal graph, SCM, or causal abstraction as the candidate lens, not correlation graph or latent manifold by default.C.29 can state declared lens use only; causal-use question and verdict, intervention claims, and counterfactual reliance stay with C.28.C.28, A.10, A.3.3
Quantum-like and contextual probabilityProbe effects, incompatible frames, order effects.Dashboards, workshops, surveys, measurement-as-intervention.Quantum-like is not physical quantum unless separate physics evidence is supplied.C.26, C.16, F.9

Relations

  • Architecture lens boundary: C.32.P2S, C.32.PAD, and C.32.ADA may 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, and C.35 may 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.9 design-rationale discipline and the source-use rows in C.29:13a.

  • Contributes to: E.2 pillar-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.26 is selected as a C.29-compatible specialization for quantum-like modeling, with affordability qualifications.

  • Neighboring claims stay with their subject patterns. Use F.9 for bridges; C.28 for causal use; A.3.3 for dynamics semantics; A.19 and C.16 for characteristic-space and measurement construction; A.10 and B.3 for evidence and assurance; C.11 for decision records; A.15 for method/Work alignment, A.15.2 for plans, and A.15.1 for performed Work; A.15.4 for reliance on a misleading appearance; E.17.* for explanation and comparative-review publication use; A.6.3.RT and A.6.3.CSC for representation transition and coarsening; C.27.TA, C.27, C.18.1, C.19.1, and C.31.ASAP for 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:

ArchitectureQuestionCard@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureQuestionProjectUseRelationRef?: U.RelationRef, only when a named pattern defines this project-use relation and the occurrence obtains
  architectureClaimRef?: ArchitectureClaimRef
  describedHolonRef:
  architectureRelationDisposition:
    actualRelationNamed | actualRelationStillToRecover |
    candidateOrExpectedOnly | nonArchitectureQuestion
  architectureRelationRefs?: FinSet(U.RelationRef)
  claimScope?:
  effectiveReferenceScheme?:
  modelUseStructureRef?: only when one selected bounded model-use structure changes this architecture use
  architectureConcernCue:
  architectureConcernClaimRefs?: FinSet(U.EpistemeRef)
  sourcePhrase?, if useful:
  questionDisposition:
    concernCueOnly | problemCardReady | architectureClaimReady | nonArchitectureClaimReady
  selectedStructureRefs?: FinSet(U.StructureRef)
  candidateOrExpectedStructureRefs?: FinSet(U.StructureRef)
  selectedStructureKindRefs or candidateStructureKindRefs:
  inspectedMaterialUse, if current: claim content | description | view | representation | publication form | source | decision | mathematical lens | other exact use
  inspectedMaterialUseRelationRefs?: references to exact obtaining relations that establish the inspected-material use
  firstArchitectureMove:
  architectureDescriptionBridge, if durable description use is current:
  claimPatternRefs?: FinSet(PatternRef), if another claim is being made:
  non-admissible overread:

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:

  1. Are we recovering an actual architecture relation, considering a candidate structure, or only reading a representation?
  2. Which subject relations actually obtain, and which exact A.22 structure is selected from them?
  3. 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?
  4. 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.Architecture as 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

ForceTension
Everyday architecture speech vs FPF kind precisionEngineers need familiar phrases such as functional architecture, physical architecture, and control architecture; a precise FPF use recovers the described holon, selected structure, structure kind, architecture concern, admissible-use frame, and the exact use of inspected material as source, description, view, or publication form.
Direct architecture relation vs claim vs descriptionAn obtaining ArchitectureRelation, a C.2.1 claim about it or about candidate or expected structure, and a useful architecture description are easy to collapse into one word even though only the direct relation is subject-side architecture.
Multi-view adequacy vs module reductionArchitecture includes functional, flow, control, module structure, interface relation, Work, system-role-kind or assignment structure, evidence relation, information structure, placement structure, scale, and declared logical structures; module diagrams are only one structure kind.
Small first architecture move vs full recordThe practitioner often needs one architecture question card, not a complete architecture description record set.
Multi-view architecture discipline vs tool lock-inCurrent FPF separates holons, selected structures, descriptions, viewpoints, views, correspondences, publications, source return, and the patterns used for separate claims without importing a tool-specific lifecycle.
Structure source relation vs overreadA structure, graph, lens, measurement, or model can supply a source relation for an architecture description without proving evidence, assurance, causality, gate passage, or release.

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:

  1. architectureBearingHolonRef — the exact U.Holon whose realized organization is at issue; and
  2. selectedArchitectureStructureRef — one exact U.Structure selected 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:

ArchitectureClaim ::= {
  claimEpistemeRef: U.EpistemeRef,
  entityOfConcernRef:
    describedHolonRef | architectureRelationRef | selectedStructureRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,
  claimScope?: U.ClaimScope, byValue,
  content: {
    describedHolonRef: U.HolonRef,
    architectureRelationAssertion:
      obtains | doesNotObtain | unresolved | candidateOrExpectedOnly,
    architectureRelationRefs?: FinSet(U.RelationRef),
    selectedStructureRefs?: FinSet(U.StructureRef),
    candidateOrExpectedStructureRefs?: FinSet(U.StructureRef),
    structureKindRefs: FinSet(ArchitectureStructureKindRef),
    architectureConcernClaimRefs?: FinSet(U.EpistemeRef),
    architectureConcernCue?: Plain recognition wording,
    admissibleUse,
    nonAdmissibleUse
  },
  modelUseStructureRef?: U.StructureRef,
  empiricalGroundingRelationRef?: U.RelationRef
}

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:

ModeCurrent EntityOfConcernAdmissible C.30 useBoundary
Direct holonic architecture modeOne exact ArchitectureRelation between a described holon and an actual selected structure, plus any C.2.1 claim about it.Recover the actual subject relations, selected structure, architecture relation, structure kind, concern, admissible-use frame, and first move.Do not apply MHT merely because the architecture has levels, scopes, parts, modules, or views.
Architecture-bound holon modeAn architecture residual raises a whole-reidentification question for a candidate result holon.Use C.30 only for the actual-relation or modal-claim architecture residual; use B.2 or B.2.P when whole reidentification is current.MHTTriggerProfile is not a general architecture heuristic.
Non-holonic description, record, or mathematical modeA description, view, diagram, dashboard, model, source relation, publication form, or mathematical-lens result is under repair.Use C.30.AD, C.30.AD.BA, C.30.ASV, E.17, A.10, or C.29 according to the object or claim being repaired; use the pattern that defines or tests any other claim.Do not treat the representation as the architecture or as MHT evidence by label.

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:
  candidateMoveClaimEpistemeRef: U.EpistemeRef
  architectureClaimRef?: ArchitectureClaimRef
  describedHolonRef:
  currentArchitectureRelationRefs?: FinSet(U.RelationRef)
  currentSelectedStructureRefs?: FinSet(U.StructureRef)
  candidateStructureRefs: FinSet(U.StructureRef)
  candidateStructureKindRefs:
  affectedArchitectureCharacteristicRef:
  candidateMoveClaim:
  candidateSetOrArchiveRef:
  selectedSetResultRef?:
  localChoiceRef?:
  patternUseRecommendationRef?:
  workPlanRef?:
  workEntryReadinessRef?:
  gateDecisionRef?:
  performedWorkRef?:
  stopCondition:

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:

C30ArchitectureDescriptionBridge minimum:
  architectureDescriptionRef: exact U.EpistemeRef
  entityOfConcernRef: exactly one described holon,
    obtaining ArchitectureRelation occurrence, or selected U.Structure
  effectiveReferenceScheme: U.ReferenceScheme, byValue
  architectureClaimRefs?: bounded claim content or trace
  selectedStructureRefs or structureKindRefs:
  architectureStructuralViewRefs?: only for exact description epistemes
    with independently obtaining E.17.0 viewpoint conformance
  viewpointConformanceRelationRefs?:
  admissibleUse:
  nonAdmissibleUse:
  correspondenceClaimOrRelationRefs or sourceReturnCondition?:
    only when reuse, cross-view use, or source return is needed
  freshnessClaimRefs?: only when currentness bounds admissible use

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 ::= {
  sourceEpistemeRef | sourceViewRef,
  publicationViewpointRef?,
  publicationScopeId,
  claimScope?,
  effectiveReferenceScheme?,
  modelUseStructureRef?,
  mvpkFaceRef,
  publicationFormRef,
  sourcePinSetRef,
  audience,
  admissiblePublicationUse,
  nonAdmissiblePublicationUse
}

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.

ModelCardOrSystemCardBoundaryNote@Project ::= {
  sourcePublicationRef,
  entityOfConcernRef,
  entityOfConcernKind:
    model | deployedAISystem | architectureClaim |
    evaluationHarness | policy | otherDeclared,
  architectureStructureKindRefs?,
  intendedUseScope,
  evaluationScopeAndKnownLoss?,
  deploymentInterpretationOrUseMismatch?,
  evidenceOrAssurancePatternLocator?,
  nonAdmissibleUse:
    notArchitectureAdequacy | notSafetyProof |
    notReleaseAuthorityByPublicationAlone
}

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.

ArchitectureNameFormationRule:

If a text says "<X> architecture", the phrase is precise only when the following are recoverable:
  describedHolonRef,
  actual subject relation occurrences or an explicit candidate or expected stop,
  architectureRelationRefs only when those exact relations obtain,
  claimScope? when claim coverage changes use,
  effectiveReferenceScheme for any claim episteme,
  modelUseStructureRef? only when that structure changes interpretation or selection,
  structureKindRef = <X>StructureKind or a declared local classifier,
  actual selectedStructureRefs or separately named candidateOrExpectedStructureRefs,
  architectureStructuralViewRefs only when a conforming view episteme is being used,
  admissibleUse,
  nonAdmissibleUse.
If <X> is not a declared structure kind, the phrase is plain recognition wording only.
PhraseRequired recovery
functional architecturestructureKindRef = FunctionalStructure; functions, effects, capabilities, and functional dependencies named as structure content; transformation-flow structures, paths, and flow valuations are assigned to TransformationFlowStructure or C.30.TFS-REL.
modular architecturestructureKindRef = ModuleInterfaceStructure; A.6.M ModuleInterfaceClaim content, selected dependency structure, independently identified interface specifications, substitutability rule, and change policy. Cite a direct module relation only after its exact predicate is defined and current facts make it obtain; the claim record is not that relation.
logical architecturestructureKindRef = DeclaredLogicalStructure; local definition says whether logical means information relation, functional relation, runtime relation, responsibility relation, allocation relation, or another relation class.
physical architecturestructureKindRef in {MaterialSpatialStructure, PlacementDeploymentStructure} or a locally declared physical structure kind.
control architecturestructureKindRef = ControlStructure; an LCA record may describe the control structure, but use the applicable dynamics, temporal, causal, evidence, safety, or assurance patterns for any separate proof claim.
information architecturestructureKindRef = InformationDataStructure; state bearer and residence, schema refs, semantic refs, persistence locus, provenance relation, custody relation, and source-return conditions.
security architecturestructureKindRef = SecurityTrustBoundaryStructure; recover protected asset or effect, trust boundary, adversarial path, authority or privilege relation, secure-default or hardening boundary, and the applicable pattern for any evidence, assurance, or gate claim.

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.

ArchitectureCharacteristicAssignment:

A. SystemQualityAffectedByArchitecture
   Bearer: exact described U.Holon, named product holon, or named system holon
   Applicable pattern: C.25 Q-Bundle or C.16
   Examples: maintainability, evolvability, resilience, availability, safety, observability

B. ArchitectureStructuralCharacteristic
   Bearer: one exact selected U.Structure, obtaining ArchitectureRelation,
           actual subject relation or constraint, or separately admitted
           module or interface relation
   Applicable pattern: C.16, A.17-A.19, C.25, or the direct
                      characteristic-space or Q-bundle pattern
   Examples: coupling, cohesion, interface alphabet, substitutability,
             hidden coupling, reusable-structure share

C. ArchitectureDescriptionOrViewAdequacy
   Bearer: one exact architecture-description episteme, one exact view episteme,
           one exact correspondence model, or one exact publication-use object
   Applicable pattern: C.30.AD, C.30.ASV, E.17.0, E.17, C.16.Q, or C.16
   Examples: viewpoint coverage, correspondence adequacy,
             source-return adequacy, description modularity

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:

ArchitectureStructuralCharacteristicQBundleClaimLine ::= {
  architectureClaimRef?: ArchitectureClaimRef,
  entityOfConcernRef:
    architectureBearingHolonRef | architectureRelationRef |
    selectedStructureRef | directStructuralRelationRef |
    structuralCharacteristicRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,
  claimScope?: U.ClaimScope, byValue,
  structuralCharacteristicCueOrRef,
  affectedQBundleSlotRef,
  relationClaimKind:
    structuralCharacteristicRelevantToQBundleSlot |
    structuralCharacteristicConstrainsQBundleSlot |
    structuralCharacteristicPredictsQBundleSlot |
    structuralCharacteristicProxiesQBundleSlot |
    structuralCharacteristicCausalHypothesisForQBundleSlot |
    structuralCharacteristicEvidenceRelationForQBundleSlot,
  relationGroundingKind:
    modelBased | empirical | causalModelBased | expertJudgement |
    sourceLineageOnly | SoTAActionLineage | reportOnly,
  directRelationDisposition:
    noDirectRelationClaimed | admittedRelationAndOccurrence |
    missingGovernor,
  admittedRelationKindOrDeclarationRef?,
  obtainingRelationOccurrenceRefs?: FinSet(U.RelationRef),
  missingRelationParticipantRefs?,
  proposedPredicate?,
  affectedUse?,
  futureDefinitionNeed?,
  evidenceOrCausalPatternLocator?,
  nonAdmissibleUse
}

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:

Structure kindStructural characteristic cue or relationAffected Q-Bundle slotRelation grounding noteNon-admissible use
ModuleInterfaceStructureStable interface specification plus substitution policy.Evolvability or replaceability.Replacement without global retesting.Open label as substitutability proof.
PlacementDeploymentStructureController placed near plant or edge-node locality.Latency, resilience, or jurisdictional compliance.Reduced communication delay and bounded data custody.Placement diagram as performance or regulatory acceptance proof.
InformationDataStructureState bearer, residence, provenance, and custody boundary.Observability, privacy, or auditability.Recoverable state lineage and bounded custody.Data schema as evidence sufficiency.
MaterialSpatialStructurePhysical separation, adjacency, or energy path.Safety, maintainability, or energy efficiency.Isolation, accessibility, or loss reduction.Geometry as safety proof.
ControlStructureObserver-controller-plant loop with rate envelope.Stability, controllability, or safety.Feedback and bounded actuation relation.Control diagram as proof.
TransformationFlowStructurePath crossing, bottleneck, buffer boundary, or waiting-line boundary.Latency, throughput, or resilience.Recoverable path, crossing, capacity, and valuation relation.Flow diagram or mathematical graph description as performance or causal proof.
SecurityTrustBoundaryStructureTrust boundary, privilege path, or untrusted-input crossing.Security, abuse resistance, or privacy.Reduced exposed authority and bounded trust crossing.Risk color or compliance label as security proof.
EvidenceAssuranceStructureEvidence package reused across variants.Assurance maintainability or release readiness.Explicit affected-structure and source-return boundary.Evidence-structure view as assurance verdict.
WorkMethodStructureMethod description, work plan, or work enactment relation with explicit exception path.Operability, auditability, or maintainability.Bounded repeatability and recoverable exception handling.Work-method diagram as work authorization or evidence sufficiency.

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.

ArchitectureCharacteristicQBundleClaim ::= {
  claimEpistemeRef: U.EpistemeRef,
  entityOfConcernRef:
    architectureBearingHolonRef | architectureRelationRef |
    selectedStructureRef | directStructuralRelationRef |
    structuralCharacteristicRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,
  claimScope?: U.ClaimScope, byValue,
  architectureClaimRef?: ArchitectureClaimRef,
  architectureStructuralViewRef?,
  architectureDescriptionRef?,
  structuralCHRRefs,
  affectedQBundleRefs,
  assertedParticipantRefs: {
    structuralCharacteristicRef,
    qBundleSlotRef
  },
  relationClaimPolarity:
    positive | negative | unresolved | candidateOnly,
  relationClaimKind:
    structuralCharacteristicRelevantToQBundleSlot |
    structuralCharacteristicConstrainsQBundleSlot |
    structuralCharacteristicPredictsQBundleSlot |
    structuralCharacteristicProxiesQBundleSlot |
    structuralCharacteristicCausalHypothesisForQBundleSlot |
    structuralCharacteristicEvidenceRelationForQBundleSlot,
  relationGroundingKind:
    modelBased | empirical | expertJudgement |
    sourceLineageOnly | SoTAActionLineage | causalModelBased | reportOnly,
  directRelationDisposition:
    noDirectRelationClaimed | admittedRelationAndOccurrence |
    missingGovernor,
  admittedRelationKindOrDeclarationRef?,
  obtainingRelationOccurrenceRefs?: FinSet(U.RelationRef),
  missingRelationParticipantRefs?,
  proposedPredicate?,
  affectedUse?,
  futureDefinitionNeed?,
  scopeOrScaleWindow?,
  viewpointRef?,
  qualifiers?,
  witnessExpectations?,
  admissibleSemanticChangeClasses?,
  bridgeOrLossBoundary?,
  admissibleUse,
  nonAdmissibleUse,
  evidenceOrCausalPatternLocator?
}

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:

AffectedArchitectureStructureNote:
  architectureClaimRef:
  affectedStructureKindRefs:
  affectedStructureRefs?:
  affectedArchitectureStructuralViewRefs?:
  acceptedOrSuspectedViewLoss?:
  sourceReturnCondition?:
  nextAdmissibleUse:

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.

InterfaceSignatureBoundaryNote ::= {
  phraseOrArtifactRef,
  apparentClaim:
    interface | signature | port | endpoint | connector | link |
    API | protocol | E.18 transformation-flow relation | E.18 transformation-flow path | mechanism reference,
  recoveredKind,
  claimPatternRefs,
  admissibleUse,
  nonAdmissibleUse
}

ModuleRelationBoundaryNote ::= {
  phraseOrArtifactRef,
  apparentClaim:
    module | component | package | platform | open architecture |
    recoveredModuleInterfaceSourceLabel |
    typed control-structure relation,
  moduleInterfaceRepairClaimCurrent?: yes | no,
  openOrPlatformClaimCurrent?: yes | no,
  selectedModuleInterfaceRelationRefs?,
  variationPointRef?,
  substitutabilityPolicyRef?,
  interfaceConformanceEvidencePatternRef?,
  changePolicyOrRelationRef?,
  consumerMigrationBoundary?,
  versionOrUpdateChannelRef?,
  secureDefaultOrHardeningBoundary?,
  claimPatternRefs,
  admissibleUse,
  nonAdmissibleUse
}

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.

ArchitectureMathLensUseBoundary:
  noMLUNeeded?: yes | no
  lensOneLine?:
    lensRef,
    structureClaimRef,
    preservedStructure,
    lostStructure,
    lensRelationKind,
    stopCondition,
    claimPatternRefs?

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:

Architecture problemCandidate mathematical lensPreserved structureTypical loss or stop
Hidden dependency or modularity.Typed graph, DSM, or hypergraph.Dependency, coupling, or clustering.Semantics, interface law, evidence, and work remain outside unless bridged.
Flow bottleneck.Transformation-flow structure, network flow, or queueing.Path, crossing, valuation, and capacity.Purpose, proof, causality, and safety remain non-architecture claims.
Control-rate mismatch.LCA, hybrid systems, assumption-guarantee relations, or control relations.Feedback participant meanings and scale or rate relations.Stability proof and safety proof remain outside the lens.
Cross-scope residual.Coarse-graining or renormalization-group-style lens.Preserved and lost structure across scale.Utility, causal-use claims, and selector authority remain outside unless separately grounded.
Extracted structure from traces.Epiplexity or MDL-style bounded-observer lens.Learnable structural regularity.Task relevance, assurance, and causal proof remain non-architecture claims.
Physical separation or spatial arrangement.Topology, geometry, or spatial graph lens.Adjacency, containment, separation, reachability, energy-transfer relation, or material-transfer relation.Safety proof, accessibility, regulatory acceptance, and causal-use claims remain outside unless separately grounded.
Composition relation.Category, open-systems, or compositional lens.Interface, composition, and coherence.Domain semantics remain outside unless bridged.

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

Tempting collapseC.30 repair
Bare architecture as free-floating selected claimRecover the actual subject-relation occurrences and exact A.22 structure, then either identify the obtaining ArchitectureRelation or keep candidate, expected, negative, or unresolved content in ArchitectureClaim. Also recover the exact described holon, structure kind, concern and admissible-use frame, effective reference scheme and ClaimScope when applicable, and the exact source, description, view, representation, publication-form, or other direct use of inspected material.
Architecture description as architectureKeep ArchitectureDescription as a C.2.1 episteme about one exact holon, obtaining ArchitectureRelation, or selected structure; keep specification use, representation, and publication separate.
Diagram, model, table, dashboard, or generated relation graph as architectureTreat it as publication form, description, view, source relation, or source-finding aid only when that relation is explicit.
Module diagram as all architectureUse C.30.ASV to recover structure kind; module structure and interface relation are only one structure family.
Transformation-flow structure or graph description as architectureUse E.18 for selected transformation-flow structure, path, and crossing records; use E.18.2 and C.29 for mathematical graph descriptions; use C.30.TFS-REL for the architecture-to-transformation-flow relation.
LCA diagram or control diagram as proofUse C.30.LCA for the control-structure view; use the applicable dynamics, temporal, causal, evidence, gate, safety, or assurance pattern for each separate claim.
Mathematical lens as architecture ontologyUse C.29; cite MathLensUseOutputRef only through an ArchitectureMathLensUseBoundary or C.29 lens record and state stop condition.
ADR as architecture decisionUse the project-side architecture decision pattern when a decision claim is being made; ADR is a publication form, not the decision.
Quality, score, or measurement term as architecture adequacyRecover the bearer through ArchitectureCharacteristicAssignment; then use C.25, C.16, A.17-A.19, or the exact characteristic or Q-Bundle pattern that defines or tests the claim. Use C.30 only for grounded architecture, selected-structure, or conditional description-use scope.
Architecture record as evidence, assurance, gate, work, or releaseAssign evidence, assurance, gate, work, or release claims to A.10, G.6, B.3, A.20, A.21, A.15, or the release locus named by value when a release claim is being made.
Architecture as agent, worker, controller, gate, or proofSplit the claim. If precise performed Work is meant, 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 architecture 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. Recover mechanism or control relations, permission, authority, responsibility, gate results, evidence, assurance, proof, and guarantees only through their own predicates or results. A local system-role kind or assignment may be a neighboring fact but neither acts nor establishes any of those stronger claims. Neither an ArchitectureRelation, its selected structure, nor ArchitectureClaim is an acting entity by wording alone.

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.

ArchitectureQuestionCard@Project:
  describedHolonRef: payment system
  claimScope: checkout-platform architecture use
  effectiveReferenceScheme: checkout-platform architecture terms
  architectureConcernCue: descriptionViewLoss or flowBottleneck
  sourcePhrase?: "architecture in this diagram"; unclear dependency between payment orchestration and fraud scoring
  questionDisposition: architectureClaimReady
  architectureRelationDisposition: actualRelationStillToRecover
  inspectedMaterialUse: publication form carrying possible architecture structural-view material
  inspectedMaterialUseRelationRefs: exact publication occurrence or representation relation when independently current
  selectedStructureKindRefs: FunctionalStructure, ModuleInterfaceStructure, TransformationFlowStructure
  firstArchitectureMove: recover the diagram as a publication face and create a minimal architecture structural-view note
  claimPatternRefs: C.30.ASV
  non-admissible overread: treating the diagram as architecture itself, evidence, assurance, gate passage, or decision

"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:

ArchitectureStructuralCharacteristicQBundleClaimLine:
  architectureClaimRef: ArchitectureClaimRef
  entityOfConcernRef: selected module-interface structure or its exact structural-characteristic referent
  effectiveReferenceScheme: module-interface and maintainability terms used by this claim
  structuralCharacteristicCueOrRef: coupling under module claim, admitted direct module relation, or interface relation as actually grounded
  affectedQBundleSlotRef: maintainability Q-Bundle slot
  relationClaimKind: structuralCharacteristicRelevantToQBundleSlot
  relationGroundingKind: sourceLineageOnly | SoTAActionLineage | modelBased, as actually grounded
  directRelationDisposition: noDirectRelationClaimed | admittedRelationAndOccurrence | missingGovernor
  admittedRelationKindOrDeclarationRef?: required only for admittedRelationAndOccurrence
  obtainingRelationOccurrenceRefs?: required only for admittedRelationAndOccurrence
  missingRelationParticipantRefs?, proposedPredicate?, affectedUse?, futureDefinitionNeed?: required only for missingGovernor
  evidenceOrCausalPatternLocator?: one selected PatternID locator: C.28, B.3, A.10, or G.6 when evidence sufficiency, causal-use, assurance, or safety-case claim is being made
  nonAdmissibleUse: causal proof, assurance, or direct relation by slogan

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

Tell-Show-Show rowGrounding
TellA project team says "architecture" while looking at a diagram, model, generated relation graph, ADR, or module list. C.30 asks which subject relations actually obtain, which A.22 structure is selected, whether the direct architecture relation obtains or the content is candidate or expected only, how the inspected material is being used, and what architecture move remains admissible.
Show: U.SystemA payment system, plant, vehicle, product platform, AI-agent system, or neural-network model has actual subject relations from which functional, flow, control, module-interface, information, placement, scale, work, evidence, or declared logical structures can be selected. When the C.30 predicate is satisfied, the exact selected structure stands in an ArchitectureRelation to that holon; a claim or publication about it is not the relation.
Show: U.EpistemeAn ArchitectureClaim, architecture description, model, view, generated relation graph, ADR-like note, safety-case view, or dashboard is an episteme or publication-side object. It can state or describe actual, negative, unresolved, candidate, or expected content and can participate in source or grounding relations, but it does not create the selected structure, ArchitectureRelation, evidence sufficiency, gate result, assurance case, or project decision.

Bias-Annotation

Lenses tested: Arch, Onto, Epist, Prag, Did, Gov. Scope: FPF architecture-description use over holons.

Bias riskMitigation
Module-diagram biasKeep module structure and interface relation as one structure family among several; use C.30.ASV and the module-and-interface repair pattern when a module or interface claim is being made.
Tool-model biasTreat notation, tool model, generated relation graph, diagram, and dashboard as description, specification-use, or publication forms unless an exact direct relation gives the source material a more specific use.
Check-only biasThe first output is an architecture question card plus action palette, not a checklist that only detects mistakes.
Assurance or gate biasArchitecture descriptions do not certify safety, evidence sufficiency, release, or gate passage; use the applicable pattern for each such claim.
Didactic-thinning riskSemantic repair preserves why the distinction matters: the pattern begins with the practitioner situation, payoff, stop condition, and first architecture move.

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

IDRequirementFailed-check repair
CC-C30-1 Grounded architecture name.A conforming use distinguishes actual subject relations and selected A.22 structure from candidate or expected content, identifies an obtaining ArchitectureRelation only when its predicate is satisfied, and gives every ArchitectureClaim one exact EntityOfConcern and effective reference scheme. It also names concern, admissible-use frame, and the exact source, description, view, representation, publication form, or other direct use of inspected material.Rewrite through ArchitectureQuestionCard@Project; recover the direct relation, retain modal content only in the claim, or demote the phrase to Plain recognition wording.
CC-C30-2 No U.Architecture.The pattern use does not mint or rely on a root U.Architecture.Recover the exact A.22 structure and direct ArchitectureRelation, or keep candidate or expected content in a claim and use the pattern that defines or tests any other claim.
CC-C30-3 EntityOfConcern and Description-episteme boundary plus specification-use separation.Actual subject relation, selected structure, ArchitectureRelation, claim, description, view, representation, publication occurrence, publication form, carrier, decision, evidence, and Work stay distinct.Recover the exact object doing each job; a description, specification use, diagram, list, file, or publication creates no subject-side architecture fact.
CC-C30-4 Exact description subject.Every architecture description has one exact C.2.1 EntityOfConcern—holon, obtaining ArchitectureRelation, or selected structure—and effective U.ReferenceScheme; architecture-claim refs remain optional content or trace.Recover the exact subject and scheme, or split the description from the bounded architecture claim.
CC-C30-5 View and publication boundary.The same description episteme is U.View only through an independently obtaining E.17.0 conformance relation to one exact viewpoint; representation, publication occurrence, form, carrier, and publication currentness remain separate.Apply C.30.AD, E.17.0, C.29, and E.24.PUB to the exact objects; remove any view membership inferred from authoring, query, bundle, diagram, file, rendering, or publication.
CC-C30-6 Small output before heavy record.Ordinary use may stop once one next architecture move and the applicable pattern for any separate claim are clear; use ArchitectureQuestionCard@Project only when the result must be retained, compared, or handed on.Remove needless card or full-record expansion, or explain which persistence or full-mode trigger is present.
CC-C30-7 Structure-kind boundary.Structural-view claims apply C.30.ASV; module, function, flow, control, work, evidence, scale, and decision claims do not collapse into C.30.Name the structure kind, state the structural view if needed, or use the pattern that defines or tests the separate claim.
CC-C30-8 Characteristic assignment.Quality, measure, score, metric, modularity, and ility wording recovers its bearer and the applicable characteristic pattern before use.Add ArchitectureCharacteristicAssignment, or keep the phrase as ordinary recognition wording rather than a C.30 claim.
CC-C30-9 Non-architecture claim kind.For each evidence, assurance, causal, gate, work, decision, publication-use authority, mathematical-lens, measurement, or release claim, name its kind and the FPF pattern that defines or tests it.Keep the C.30 record limited to architecture and selected-structure adequacy.
CC-C30-10 Useful action.The repaired wording leaves a surviving admissible action: name the architecture claim, recover the exact use of inspected material, state an architecture structural view, add a source or reliance relation, add a SourceReturnCondition, or apply the FPF pattern that defines or constrains the claim kind being made.Restore that action, or classify the phrase as reduced-use cue, quote-only wording, blocked transfer, or incomplete rewrite.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
Architecture-as-documentA document, diagram, table, generated relation graph, or dashboard is treated as the architecture or as what makes ArchitectureRelation obtain.Recover the representation and publication objects, exact claim episteme, selected structure, and actual direct relation separately; a carrier creates none of their subject-side facts.
Publication-unit architecture driftOne publication unit mixes architecture description, evidence claim, gate decision state, decision note, and work authorization under one architecture heading.Name the exact ArchitectureRelation or modal ArchitectureClaim content, keep description, view, and publication objects separate, and use the applicable patterns for evidence, gate, decision, and work claims. The publication heading creates no selected structure or subject-side relation.
Module-diagram takeoverArchitecture is reduced to module structure or interface relation.Recover the structure kind, use C.30.ASV, and use the module-and-interface repair pattern when the full module claim is current.
Tool-model lock-inA notation or tool model becomes the source of architecture truth.Recover FPF architecture claim, structures, views, correspondence, and source-return condition.
Evidence launderingA published architecture description is used as evidence sufficiency.Assign the evidence relation or evidence claim to A.10 or G.6; C.30 keeps only the architecture claim, selected-structure, and conditional architecture-description-use boundary; the evidence relation stays with the evidence pattern.
Assurance or safety overreadArchitecture description or LCA diagram is used as assurance or safety case.Use B.3, A.10, G.6, C.30.LCA, or the exact safety or gate pattern according to the claim being made.
Risk color as architecture decisionA red, yellow, or green risk cell, risk matrix, or maturity score decides the architecture move or resource-allocation priority.Recover the structure kind under consideration, affected scope, loss, hazard or threat path, source or grounding relation, characteristic scale, comparator, and gate pattern; use the applicable patterns for architecture adequacy, evidence sufficiency, causal proof, assurance proof, resource-allocation reason, and gate-passage claims.
Causal sloganArchitecture property is said to cause a quality without a bounded claim or independently admitted relation grounding.Start with ArchitectureStructuralCharacteristicQBundleClaimLine; apply C.28 or the applicable evidence, causal-use, or assurance pattern, or use ArchitectureCharacteristicQBundleClaim when a durable bounded claim is needed. Name a direct relation only after its defining pattern identifies the participants and its predicate is satisfied.
Architecture-operation overreadReplacing a block, module, layer, protocol, cache, memory path, or flow relation is treated as improvement by label alone.Apply C.30.STRAT to source labels, then recover the changed structure kind, preserved structure, lost structure, source relation, affected characteristic, and pattern for any decision or evidence claim.
Sterile compliance rewriteThe text becomes well typed but no longer helps the practitioner act.Restore a concrete next architecture move, a retainable ArchitectureQuestionCard@Project when needed, or the applicable pattern for the separate claim.

Consequences

BenefitCost or trade-off
Actual architecture relations and modal architecture claims become separable from diagrams, publications, generated relation graphs, ADRs, module lists, and decisions.A conforming use recovers actual subject relations, selected A.22 structure, direct-relation disposition, exact claim EntityOfConcern and effective reference scheme, and the exact inspected-material use when relevant.
The pattern enables first-principles architecture reasoning without forcing full measurement, synthesis, assurance, or decision machinery.Some familiar architecture phrases become triggers for quick recovery rather than accepted claims.
Functional, flow, control, module structure, interface relation, information structure, placement structure, scale structure, work structure, evidence relation, and declared logical structures can coexist without one structure kind swallowing the rest.Use C.30.ASV to test structural-view adequacy when an explicit view application is needed.
C.29, E.18, LCA, module-and-interface repair, evidence, assurance, and gate patterns can define or test source and reliance claims used in architecture work without adding them to architecture ontology.Name the applicable pattern and the source or reliance relation whenever the use goes beyond C.30 architecture-claim, selected-structure, or conditional description-use scope.

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

Practice or source lineC.30 adoptionAction consequenceBoundary
FPF C.2.1, A.22, C.30.AD, and C.30.ASV multi-view architecture disciplineCurrent FPF separates actual subject relations, exact selected A.22 structure, direct ArchitectureRelation, bounded claim content, Description episteme, viewpoint, structural view, representation, publication, correspondence, grounding, and source return.Ask whether the actual relation obtains or the content is modal, then choose the next architecture move before opening heavier description and view records. When architecture-description or traceability use is current, recover correspondence, source pins, description-reliance relations, and source-return conditions.A tool, notation, model-use structure, view, description, file, list, or publication creates none of the subject-side relation, structure, or truth facts by form.
SEI views-and-beyond lineage plus current multi-view practiceKeep module, component-and-connector, runtime interaction, allocation, and placement as separate view pressures.Do not reduce architecture to module structure or interface relation; use C.30.ASV to test structural-view claims.View taxonomies are lineage and comparison support, not a second FPF ontology.
arXiv:2603.00601 code-space architecture relation-graph work and related code-agent architecture probing benchmarksAdapt partial-observability probing, typed edge rules, component-boundary rules, invariant-field semantics, uncertainty or unexplored-region reporting, and probe-as-intervention warning.A generated code relation graph can supply a source relation for an architecture description or structural view only with claim, source, uncertainty, relation semantics, and source return.Do not mint U.CodeSpace; do not treat probe or benchmark output as architecture adequacy, evidence sufficiency, assurance, or release.
Holon-architecture law-like constraint set from the architecture sourceAdopt Conway and mirroring as transformer-transformed correspondence pressure through C.32.CONWAY; use other law-like architecture lines only as recognition pressure for selected structures and architecture characteristics.For Conway or mirroring, recover transformer holon, transformed holon, changing relation, selected structures, affected characteristics, candidate gain, and candidate loss. For other law-like pressure, identify the selected structure and characteristic, then use the pattern that defines or tests the exact architecture, relation, measurement, selected-set, or decision claim.No law-like slogan is architecture adequacy, decision, evidence sufficiency, assurance, gate passage, or universal architecture ontology by itself.
GonzoML neural-network architecture corpus as source example for general architecture-operation languageAdopt practitioner architecture-operation language as general architecture material: structural substitution, relation retargeting, dataflow change, path-selection and gating, memory and cache placement, block and layer substitutions, MoE expert-selection, pruning, distillation, NAS, ablation, and compute, memory, and latency tradeoffs.Keep source labels as source labels through C.30.STRAT; after recovery, use the language for architecture-description and architecture-view recognition, transformation-flow-structure source relation, module-and-interface repair, scale characterization, candidate move guidance, and decision-context fields.Neural-network labels, benchmarks, ablations, pruning masks, search outputs, or distillation success do not become FPF ontology, architecture decision, evidence sufficiency, gate passage, assurance, or architecture adequacy by themselves.
Platform-engineering, MOSA, and open-systems practiceAdapt open-interface, platform extension-rule, substitution-policy, and conformance-expectation pressure as local architecture boundary discipline.For an open-interface or platform claim, name the local structure, interface, variation point, substitution policy, pattern for any conformance-evidence claim, migration boundary, update channel, and hardening boundary that change action.Platform design depends on project, organization, time, and place; there is no universal platform maturity scale or open-label proof.
ADR and architecture-knowledge-management practiceAdopt decision-memory pressure only as a project-side decision concern handled outside C.30.Treat ADR-like material as a publication or decision-description source relation until an architecture decision claim is being made.ADR is not the project decision itself and not a source of release authorization.

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:

ArchitectureDescriptionUseCard@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureDescriptionProjectUseRelationRef?: U.RelationRef defined by the pattern for the exact relation by which this description use concerns the Work
  architectureDescriptionRef?: U.EpistemeRef constrained to ArchitectureDescription
  entityOfConcernRef: exactly one of (
    describedHolonRef | architectureRelationOccurrenceRef | selectedStructureRef
  )
  effectiveReferenceScheme: U.ReferenceScheme, byValue
  architectureClaimRefs?: FinSet(U.EpistemeRef constrained to ArchitectureClaim)
  claimScope?: U.ClaimScope, byValue
  concernRefs?: FinSet(U.EntityRef)
  modelUseStructureRef?: U.StructureRef
  empiricalGroundingRelationRefs?: FinSet(U.RelationRef)
  descriptionPurpose:
  selectedStructureRefs: FinSet(U.StructureRef)
  structureKindRefs: FinSet(ArchitectureStructureKindRef)
  viewpointRefs?: FinSet(U.EpistemeRef constrained to U.Viewpoint)
  architectureStructuralViewRefs?: FinSet(U.EpistemeRef constrained to ArchitectureStructuralView)
  viewpointConformanceRelationRefs?: FinSet(EpistemeViewpointConformanceRelationRef)
  correspondenceClaimOrRelationRefs?: FinSet(U.EpistemeRef | U.RelationRef)
  sourceToUsePathRefs?: FinSet(U.RelationRef)
  sourceReturnCondition?:
  representationRefs?: FinSet(U.EntityRef)
  publicationOccurrenceRefs?: FinSet(EpistemePublicationRelationRef)
  publicationFormRefs?: FinSet(U.EntityRef)
  carrierRefs?: FinSet(U.EntityRef constrained to U.PresentationCarrier)
  specificationUseBoundary?:
  admissibleUse:
  nonAdmissibleUse:
  nextClaimPatternRef?: PatternRef

@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 ArchitectureRelation occurrence, 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.View membership 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

ForceTension
Useful description vs architecture overreadA good description guides architecture work, but it is not the architecture, an obtaining ArchitectureRelation, selected structure, decision claim, proof, or release authorization.
Multi-view richness vs exact episteme identitySeveral descriptions can be needed, but each keeps its exact claim graph, one EntityOfConcern, and effective U.ReferenceScheme; a description set does not blur those identities.
Viewpoint utility vs automatic view membershipA viewpoint helps a practitioner or practice inspect an architecture, but only the independently obtaining E.17.0 conformance relation makes the same episteme a U.View; a viewpoint label or bundle does not.
Viewpoint utility vs viewpoint-as-kind collapseViewpoints do not choose the selected structure kind. Use C.30.ASV, or the pattern for the particular structural view, to keep viewpoint conformance and structure-kind recovery separate.
Reuse vs freshnessA reused architecture description names its source-to-use path and applicable source or structure edition. A source-return condition is added only when stronger use must return to a named source or the exact defining or constraining ClaimGraph.
Specification-use vs representation and publicationA description can be used as a specification, but specification use is a bounded use of an episteme or publication; it is not the diagram, publication occurrence, publication form, carrier, architecture, or project Work.
Thin C.30 bridge vs full description mechanismC.30 defines the obtaining architecture relation and bounded architecture claim; C.30.AD defines the heavier description-use account only when durable description use is current.

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

ArchitectureDescriptionUseAccount:
  architectureDescriptionRef: U.EpistemeRef constrained to ArchitectureDescription
  claimGraphRef: exactly one C.2.1 ClaimGraph
  entityOfConcernRef: exactly one of (
    describedHolonRef | architectureRelationOccurrenceRef | selectedStructureRef
  )
  effectiveReferenceScheme: U.ReferenceScheme, byValue

  architectureClaimRefs?: FinSet(U.EpistemeRef constrained to ArchitectureClaim)
  selectedStructureRefs: FinSet(U.StructureRef)
  structureKindRefs: FinSet(ArchitectureStructureKindRef)

  claimScope?: U.ClaimScope, byValue
  concernRefs?: FinSet(U.EntityRef)
  modelUseStructureRef?: U.StructureRef
  empiricalGroundingRelationRefs?: FinSet(U.RelationRef)

  architectureStructuralViewRefs?: FinSet(U.EpistemeRef constrained to ArchitectureStructuralView)
  viewpointConformanceRelationRefs?: FinSet(EpistemeViewpointConformanceRelationRef)
  descriptionSetUseClaimRefs?: FinSet(U.EpistemeRef)
  correspondenceClaimOrRelationRefs?: FinSet(U.EpistemeRef | U.RelationRef)

  sourceEpistemeRefs?: FinSet(U.EpistemeRef)
  sourceViewRefs?: FinSet(U.ViewRef)
  sourceToUsePathRefs?: FinSet(U.RelationRef)
  sourceReturnCondition?
  freshnessClaimRefs?: FinSet(U.EpistemeRef)

  representationRefs?: FinSet(U.EntityRef)
  publicationOccurrenceRefs?: FinSet(EpistemePublicationRelationRef)
  publicationFormRefs?: FinSet(U.EntityRef)
  carrierRefs?: FinSet(U.EntityRef constrained to U.PresentationCarrier)
  specificationUseBoundary?
  publicationUseBoundary?
  admissibleUse
  nonAdmissibleUse

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 ArchitectureRelation occurrences; required, desired, expected, candidate, unresolved, or negative architecture content stays claim content;
  • selectedStructureRefs names the architecture-relevant structures being described, and structureKindRefs classifies those selected structures;
  • any cited ArchitectureStructuralView is the same description episteme admitted as U.View only 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;
  • admissibleUse and nonAdmissibleUse say 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:

workingConcernRef
-> exact viewpoint episteme
-> independently obtaining EpistemeViewpointConformanceRelation
-> the same ArchitectureDescription episteme admitted as U.View
-> exact entityOfConcernRef
-> selectedStructureRef and, when actual, ArchitectureRelationOccurrenceRef
-> optional ArchitectureClaimRef
-> ArchitectureDescriptionUseCard or multi-view description-set use claim
-> admissibleArchitectureMove or pattern needed for a separate claim

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 content:
  architectureDescriptionSetRef:
  usedArchitectureStructuralViewRef:
  usePurpose:
    orientation | comparison | implementationGuidance |
    assuranceInput | sourceUse | strongerUseReturn | declaredOther
  correspondenceClaimOrRelationRefs?: FinSet(U.EpistemeRef | U.RelationRef)
  sourceToUsePathRefs?: FinSet(U.RelationRef)
  sourceReturnCondition?
  admissibleUse:
  nonAdmissibleUse:
C.2.1 constitution:
  entityOfConcernRef: exactly one architectureDescriptionSetRef
  effectiveReferenceScheme: U.ReferenceScheme, byValue

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:

View useRequired FPF application
Function or functionality view[A.6.F](/generated/patterns/A.6.F) for function or functionality wording and [C.30.ASV](/generated/patterns/C.30.ASV) for the structural view.
Transformation-flow view[E.18](/generated/patterns/E.18) plus C.30.TFS-REL when the selected transformation-flow structure, path, crossing, valuation, or graph-shaped mathematical description is used by architecture.
Control or LCA view[C.30.LCA](/generated/patterns/C.30.LCA) when a control structure view is being used.
Module or interface view[A.6.M](/generated/patterns/A.6.M), signature or interface patterns, and [C.30.ASV](/generated/patterns/C.30.ASV) when module-interface structure is being used.
Mathematical-lens view[C.29](/generated/patterns/C.29) for lens-use result and preserved and lost structure; [C.30.AD](/generated/patterns/C.30.AD) only for the architecture-description use of the lens result.
Boundary, interface, or Markov-blanket view[A.1](/generated/patterns/A.1), [A.6.RSIR](/generated/patterns/A.6.RSIR), [A.6.P](/generated/patterns/A.6.P), [A.6.0](/generated/patterns/A.6.0), [A.6.5](/generated/patterns/A.6.5), [A.6.M](/generated/patterns/A.6.M), [A.6.F](/generated/patterns/A.6.F), [C.26](/generated/patterns/C.26), [C.26.3](/generated/patterns/C.26.3), and [C.29](/generated/patterns/C.29) according to the recovered claim; [A.6.B](/generated/patterns/A.6.B) only when the recovered object is L, A, D, or E statement classification inside a boundary package. [C.30.AD](/generated/patterns/C.30.AD) records only exact description identity, description-set use, cross-view correspondence, source-to-use path when a source is used, an applicable stronger-use return condition, freshness, representation, or publication use.
Evidence or assurance reuse viewUse [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), or the relevant evidence or assurance pattern for the non-architecture claim.
Architecture residual viewUse [C.30.ILC](/generated/patterns/C.30.ILC) for a cross-scope or interlevel architecture residual. C.30.AD records only the view episteme, its conformance, description-set use, correspondence to other views, and allowed use; add a source-use relation only when a source is actually used.
Multilevel-learning or frustration mathematical-lens view[C.29](/generated/patterns/C.29) when the view contains a recoverable level mapping or scale mapping and preserved structure and lost structure; [C.30.AD](/generated/patterns/C.30.AD) records only the architecture-description use of that lens result.
Residual-reducing candidate or optimization viewUse [C.32.MLAO](/generated/patterns/C.32.MLAO) for the residual-reducing multilevel candidate frame, [C.32](/generated/patterns/C.32) for the candidate architecture palette, [A.19.CPM](/generated/patterns/A.19.CPM) or [A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism) for comparison or selector-policy use, [C.18](/generated/patterns/C.18) and [C.19](/generated/patterns/C.19) for archive, front, or current-pool treatment, [G.5](/generated/patterns/G.5) for selected-set result declaration, and [C.11](/generated/patterns/C.11) for final local choice. Record with C.30.AD only the exact description identity, description-set use, cross-view correspondence, source-to-use path when used, applicable source-return condition, freshness, representation, publication use, or specification use.

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 content:
  architectureDescriptionSetRef:
  fromViewRef:
  toViewRef:
  correspondenceKind:
    sameDescribedHolon | sameArchitectureRelationOccurrence |
    sameSelectedStructure | refinement | abstraction | coarseGraining | projection |
    sourceDerived | conflict | declaredOther
  preservedStructureRefs?
  lostStructureRefs?
  directCorrespondenceRelationRefs?: FinSet(U.RelationRef)
  sourceToUsePathRefs?: FinSet(U.RelationRef)
  sourceReturnCondition?
  admissibleUse:
  nonAdmissibleUse:
C.2.1 constitution:
  entityOfConcernRef: exactly one architectureDescriptionSetRef
  effectiveReferenceScheme: U.ReferenceScheme, byValue

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 content:
  sourceEditionRefs:
  structureEditionRefs?
  modelOrToolEditionRefs?
  knownRefreshTrigger:
    sourceChange | deploymentChange | interfaceChange |
    controlRateChange | modelEditionChange | evidenceDecay |
    toolApiChange | regulatoryChange |
    incidentFinding | declaredOther | unknown
  admissibleUseUntil?
  sourceReturnCondition?
C.2.1 constitution:
  entityOfConcernRef: exactly one ArchitectureDescriptionRef
  effectiveReferenceScheme: U.ReferenceScheme, byValue

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.

ArchitectureDescriptionSpecificationUseAccount@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureDescriptionProjectUseRelationRef?: U.RelationRef defined by the pattern for the exact relation by which this specification use concerns the Work
  architectureDescriptionRef: U.EpistemeRef constrained to ArchitectureDescription
  sourceEpistemeRef?: U.EpistemeRef
  sourceViewRef?: U.ViewRef
  sourceToUsePathRefs?: FinSet(U.RelationRef)
  representationRef?: U.EntityRef
  publicationOccurrenceRef?: EpistemePublicationRelationRef
  publicationFormRef?: U.EntityRef
  carrierRef?: U.EntityRef constrained to U.PresentationCarrier
  declaredUse:
    coordination | implementationGuidance | procurement |
    verificationPlanning | assuranceInput | releaseInput |
    declaredOther
  claimPatternRefs?: FinSet(PatternRef)
  admissibleUse:
  nonAdmissibleUse:

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

Question after the architecture-description boundary is clearFPF application
Grounded architecture claim, selected structures, first architecture moveC.30
Recommended FPF pattern use after reading the descriptionE.11.PUR
Work-entry readiness or full-kit condition for intended architecture workA.15.5
Architecture or structure wording is still overloadedC.30.P
Architecture structural view or structure-kind and viewpoint relationC.30.ASV
Transformation-flow relation or graph description used by architectureC.30.TFS-REL and E.18
Control structure viewC.30.LCA
Cross-scope or interlevel architecture residual, conflict, or frustration in the described holonC.30.ILC
Multilevel-learning or frustration mathematical-lens result with recoverable level mapping or scale mapping and preserved structure and lost structureC.29 with the admitted C.29-local lens output
Residual-reducing candidate architecture moves, candidate palette, candidate front, shortlist, selected set, or optimization over candidatesC.32.MLAO for the residual-reducing frame, C.32 for the candidate palette, A.19.CPM or A.19.SelectorMechanism for comparison or selector-policy use, C.18 and C.19 for archive, front, or pool treatment, G.5 for selected-set result declaration, C.11 for final local choice, and measurement patterns named by value when those claims are being made
Generic description, view, viewpoint, publication, publication form, MVPK faceA.7, E.17.0, E.17.1, E.17.2, E.17, or C.2.P
Function or functionality wordingA.6.F
Module, interface, port, signature, or reusable structure relationA.6.M, a signature or interface pattern named by value, C.31, or C.31.RSA
Mathematical lens or preserved and lost mathematical structureC.29
Characteristic, scale, coordinate, score, or quality claimC.16.P, C.16, A.19, C.25, or the pattern that defines or tests the quality claim
Evidence, assurance, gate, work planning, performed work, local choice, project architecture decision, causal use, or releaseA.10, B.3, A.20, A.21, A.15.2, A.15.1, C.11, C.32.PAD, C.28, or the pattern for the particular release, admissibility, or other claim

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)

CaseC.30.AD treatment
"The architecture is documented in this view set."Treat the set as a package of separately identified architecture-description epistemes only if each has an exact claim graph, one EntityOfConcern, and effective U.ReferenceScheme. A member is a U.View only with its exact viewpoint episteme and independently obtaining E.17.0 conformance relation. The set is not the architecture, relation occurrence, or selected structure.
A transformation-flow graph expression is included in an architecture document.Use E.18 for graph, path, and crossing semantics and C.30.TFS-REL when the graph is used by architecture. C.30.AD records the exact description and its path from the source expression into that use; add a source-return condition only if a stronger use must return to the named source or exact defining or constraining ClaimGraph. The graph expression or rendering creates no actual transformation.
A model card claims deployment safety.Use C.30.AD only if the card publishes or represents a description episteme about an exact architecture-side object. Safety assurance uses B.3; evidence uses A.10; release uses A.21.
A generated code-agent relation graph shows modules and calls.Treat the graph as a generated representation or source publication. Recover observed, inferred, and unknown relations; use C.30.ASV or C.30.TFS-REL only when an exact architecture structural view or flow relation is being used. Generation and display establish neither relation occurrence nor view membership.
A multi-view description set has functional, deployment, control, and evidence-reuse views.Identify every description episteme separately, including its EntityOfConcern and scheme. Each cited view also names its exact viewpoint and obtaining conformance relation; an ArchitectureDescriptionViewUseClaim records set use without minting membership. Evidence-reuse claims do not stay inside C.30.AD.
A plant safety architecture description combines control, deployment, evidence, and operator-view material.C.30.AD records exact description identities, view conformance, description-set use, and correspondence among views. Use C.30.LCA for the control view and A.10, G.6, or B.3 for evidence or assurance. If a system-role assignment, F.6 Work attribution, authority, allocation, or responsibility is claimed, cite its separate direct relation; otherwise record the exact missing governor.
A product-line platform document reuses module-interface, variability, and deployment views across products.C.30.AD records exact description epistemes, architecture claims carried as content, structural views, and source-to-use paths for reused views. A source-return condition is added only when a product-specific use exceeds the declared reuse boundary. A.6.M normalizes module-interface claims and routes any proposed direct relation; C.31.RSA accounts reusable structure or bespoke residue only after structure refs and accounting frame are declared.
A multi-view architecture description says local optimization at one declared holon level creates frustration in another.C.30.AD records set use, correspondence, and each view use boundary. Use C.30.ILC for the residual; use C.29 only when the description contains a recoverable level or scale mapping with preserved and lost structure.
An operations model groups individual queues and interactions into three broad bands.Name the operating subject, the fine and coarse description structures, the grouping map, the distinctions preserved and lost, and the use of the three-band view. This establishes a coarser description, not three subject levels. Use C.30.STRAT, C.29, A.22, or C.30 only if their separate subject or model claims are needed and supported.
An architecture document compares residual-reducing candidate decompositions or optimization moves.Record with C.30.AD only the exact description or publication use of that comparison. Use C.32.MLAO for residual-reducing frames, C.32 for candidate palettes, A.19.CPM or A.19.SelectorMechanism for comparison and selector-policy use, C.18 or C.19 for archives, fronts, and current-pool treatment, G.5 for selected-set result declaration, and C.11 for final local choice. For a measurement claim, use the pattern that defines or tests the measured characteristic and result.
A review note, dashboard, or generated report describes gaps in an architecture description rather than the architecture itself.Treat the second description as its own U.Episteme and name its source, representation, publication, review, or evaluation relation directly. Keep the path to the first description and its EntityOfConcern visible without treating either description as architecture, residual, decision, or proof.

Bias-Annotation

BiasHow C.30.AD prevents it
Description-as-architecture biasArchitectureDescription is a C.2.1 episteme about one exact holon, architecture-relation occurrence, or selected structure; it does not become that object or create it.
View-as-structure biasThe same description episteme is a U.View only through an E.17.0 conformance relation that actually holds. Use C.30.ASV to test selected-structure adequacy; C.30.AD records set use and correspondence without inventing membership.
Publication-as-authority biasRepresentation, publication occurrence, publication form, carrier, dashboard polish, model-card form, or report label does not establish description truth, empirical grounding, evidence, assurance, gate, decision, work authorization, or release authorization.
Freshness-as-evidence biasA freshness claim bounds admissible use; it does not make the description evidence-sufficient or publication-current.
Semio-bias in architecture workUse C.30 for obtaining architecture relations, selected structures, and architecture claims. Open C.30.AD only when work must create, inspect, or rely on a description episteme with its own ClaimGraph, EntityOfConcern, and reference scheme.

Conformance checklist

CheckCondition to establishRepair if failed
CC-C30AD-1 Episteme identity.Every architecture description has one exact claim graph, one exact EntityOfConcern—holon, obtaining ArchitectureRelation occurrence, or selected structure—and an effective U.ReferenceScheme.Add the missing C.2.1 identity component or use C.30/A.22 until the subject-side object is recoverable.
CC-C30AD-2 Subject and holon recovery.The one EntityOfConcern is supplied directly. If it is an architecture-relation occurrence or selected structure, its participant trace recovers the exact holon without copying that holon into description identity; architecture-claim refs remain optional content or trace.Restore the exact EntityOfConcern and participant trace; remove derived identity from an optional architecture-claim field.
CC-C30AD-2a Traceable multi-view chain.The reader can recover the concern, viewpoint, conformance relation, same episteme as U.View, EntityOfConcern, selected structure, optional actual architecture relation, set use, and next architecture move. Add allocation, responsibility, source use, representation, publication, correspondence, project use, or stronger-use return only when it is current. Responsibility names its own predicate and participants or the missing governor; assignment and viewpoint establish neither responsibility nor authority.Add the missing object or relation, narrow the allowed use, or use the pattern that defines how to recover it.
CC-C30AD-3 Viewpoint and structure kind.Every asserted architecture structural view identifies the candidate episteme, exact viewpoint episteme, independently obtaining five-part E.17.0 conformance relation, selected structure, and structure kind.Use E.17.0 and C.30.ASV before relying on the view; a label, query, bundle, diagram, or publication is insufficient.
CC-C30AD-4 Correspondence and source use.Cross-view use names a correspondence claim or independently obtaining relation; source-derived or reused use names its source-to-use path; a source-return condition is present only when stronger use opens return to the named source or exact defining or constraining ClaimGraph.Add the missing claim or direct relation, or narrow the admissible use.
CC-C30AD-5 Representation and publication boundary.A diagram, rendering, publication occurrence or form, dashboard, card, file, or carrier is not treated as architecture, selected structure, U.View, truth, decision, evidence, assurance, gate passage, Work, authorization, or release.Use C.2.P, E.17, E.24.PUB, or the pattern for the actual representation, publication, source-use, or other non-description claim.
CC-C30AD-6 Specification-use boundary.Specification use names the description episteme or publication. Project locality additionally names one composite U.Work and a project-use relation that actually holds; separate non-description claims cite their applicable patterns.Add the description, Work, and use relation as needed, or keep the use non-project-specific.
CC-C30AD-7 Remaining architecture candidate use.Under the declared use boundary, the description still identifies the next architecture move, view repair, source repair, return condition, or pattern needed for a separate claim.Add that remaining use or reduce the account to source, representation, or publication use.
CC-C30AD-8 Coarse-graining boundary.A coarsening claim names the described subject, finer and coarser description structures, their mapping or correspondence, distinctions preserved and lost, and allowed use. It asserts no matching subject levels, parts, or relations without a separate subject-side basis.Add the missing description facts, narrow the use, or establish the needed subject relation through its own pattern.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
Description-as-architectureA document, diagram, model, graph, view set, or card is said to be the architecture or to create an obtaining architecture relation.Recover the exact holon, ArchitectureRelation occurrence, or selected structure; keep the episteme, representation, publication, and source-to-use relation distinct.
Viewpoint-as-structure-kind or view constructorA stakeholder, role, concern, viewpoint label, authoring template, query, or bundle is used as if it named the selected structure or granted U.View membership.Use E.17.0 for exact viewpoint conformance and C.30.ASV for selected structure and kind.
Multi-view fogMany views are listed, but their separate C.2.1 identities, conformance relations, selected structures, or correspondence cannot be recovered.Add the description and viewpoint references, conformance relations, selected structures, and correspondence claims or relations that actually hold.
Coarse model as subject hierarchyA grouped or lower-resolution description is treated as proof that the subject has the same levels, parts, or relations.State the description-side grouping, mapping, preserved and lost distinctions, and allowed use; establish any subject-side relation separately.
Specification-as-authorityA specification-looking description is used as Work, gate passage, decision, assurance, evidence, work authorization, or release authorization.Declare the specification use and use the pattern that defines or tests the other claim.
Freshness launderingA recently generated diagram is treated as adequate because it is current.Record the bounded freshness claim, source edition, and refresh trigger; do not treat currentness as adequacy, evidence, grounding, or assurance.
Architecture-documentation takeoverPractitioner guidance is dominated by diagrams, publications, and wording guards instead of architecture relations, structures, descriptions, and views.Keep C.30 about architecture and C.30.AD about descriptions and their use; use the relevant patterns for representation and publication.

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.

Practice or source lineSource-use relation and currentnessC.30.AD adoptionAction consequenceBoundary
FPF C.2.1, A.22, E.17.0, C.30, and C.30.ASV separate episteme identity, selected structures, direct architecture relations, architecture claims, and structural-view adequacy.Current internal definitions for the objects used by this pattern.Reuse these objects instead of importing a second architecture-description ontology.Disciplines C.30.AD:4.1, C.30.AD:4.1a, C.30.AD:4.2, CC-C30AD-1, CC-C30AD-3, and CC-C30AD-4: every description has one exact EntityOfConcern and scheme; every asserted view has exact viewpoint conformance; correspondence and source use are explicit.A description or view remains an episteme and does not become architecture, proof, decision, or release authority.
Views-and-Beyond and related architecture documentation practice treats views as stakeholder-relevant projections over architecture.Mature reference and lineage source for view-based architecture documentation; not used as a mandatory current catalog.Adopt view usefulness while requiring exact E.17.0 viewpoint conformance and structure-kind recovery through C.30.ASV; description-set use remains claim content or a separate relation that actually holds.Disciplines C.30.AD:4.1a, C.30.AD:4.2, and the multi-view worked case: a view remains useful for a working concern without becoming the selected structure or a U.View by label.No mandatory view catalog or local membership relation is imported, and view adequacy remains in E.17.0 and C.30.ASV.
E.17.0 and MVPK publication machinery in current FPF.Current internal FPF definitions and publication practices for views, viewpoints, publication occurrences, forms, carriers, and publication separation.Reuse generic view and publication machinery instead of minting architecture-local copies.Disciplines C.30.AD:4.1a, C.30.AD:4.5, CC-C30AD-5, and CC-C30AD-6: architecture-description identity and composition remain separate from representation, publication occurrence, form, carrier, and publication-currentness.C.30.AD specializes architecture-description use; it does not replace E.17.0, E.17.1, E.17.2, E.17, E.24.PUB, or C.2.P.
C4, arc42, ADR, model-card, and system-card practice makes architecture communication practical.Current practitioner-source family for familiar architecture publication and documentation forms.Admit these as possible source publications, view publications, decision-description publications, transparency publications, or specification-use records.Disciplines C.30.AD:4.5, worked cases, and anti-patterns: practitioners can use familiar forms while keeping source, representation, publication, description, architecture, evidence, gate, decision, work authorization, release authorization, and other non-description claims separate.Template, card, graph, or diagram quality is not architecture adequacy by itself.
Tool-generated architecture relation graphs and code-agent architecture probing expose useful but partial structure.Emerging practitioner practice for recovering architecture-relevant relations from code, models, and generated analyses; currentness depends on the analyzed edition and tool run.Treat generated graphs as representations or source-derived descriptions with observed, inferred, and unknown relation boundaries.Disciplines C.30.AD:4.3, C.30.AD:5, and CC-C30AD-4: a generated output can guide structure recovery and next architecture moves only through a named source-to-use path; stronger use activates the declared source-return condition.Generated relation coverage does not become an obtaining subject relation, U.View, proof, gate passage, safety assurance, or complete architecture.

Relations

  • Use C.2.1 to identify every architecture-description episteme.
  • Use C.30 for obtaining architecture relations, selected structures, and bounded architecture claims.
  • C.30.P normalizes overloaded architecture or structure wording before this pattern is used.
  • Use C.30.ASV to test architecture structural-view adequacy; only E.17.0 conformance admits the same episteme as U.View.
  • Use C.33 to 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.34 to test preservation or correspondence when comparing a description with another view, source model, generated output, candidate, or realized structure.
  • Use C.29 for a mathematical-lens or coarse-graining result, C.30.STRAT for level-word admission, and A.22 or C.30 for the separately supported subject structure or architecture relation. Description-side grouping establishes none of those subject claims by itself.
  • Use A.6.3.NAR for 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, and C.30.ILC for their named architecture-relation subcases.
  • Use C.32.P2S for 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, and E.24.PUB for generic EntityOfConcern, view, viewpoint, representation, publication occurrence, form, carrier, and MVPK machinery.
  • C.2.P normalizes source-expression, source-to-use, publication-form, and publication-currentness relation-set overreads.
  • Use E.11.PUR for recommended FPF pattern use after reading a description; C.30.AD records only the description-use boundary.
  • Use A.15.5 for 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.MOVE restores 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.AD Status: 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

ForceTension
Long asset life vs changing descriptionsThe built asset can retain identity while descriptions, model editions, sensor systems, representations, publications, and information uses change.
Many useful structures vs exact description identitySpatial, functional, flow, module, interface, placement, control, and information structures can all matter, but every description still has one exact C.2.1 EntityOfConcern and every selected structure keeps its own A.22 identity.
Exchange interoperability vs FPF relation meaningIFC and related exchange formats carry explicit object and relation data, but exchange content is source description until actual subject relations and selected structures are recovered under their direct owners.
Designation stability vs aspect dependenceA reference designation can make an object retrievable across descriptions while still depending on a declared structuring aspect, designation scheme, exact referent, and qualification window.
Auxiliary-view usefulness vs direct claim ownershipCost, schedule, operation, maintenance, sustainability, and energy views can guide architecture work; their characteristic measurement, Work, temporal-claim adequacy, causal use, evidence, assurance, and currentness claims still require C.16, A.15, C.27, C.28, A.10, B.3, and G.11.
Live coupling vs currentnessTelemetry and simulations can update a digital-twin description rapidly; freshness and fidelity still bound each claim made from it and do not create physical change.

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:

BuiltAssetArchitectureDescriptionUse@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  builtAssetDescriptionProjectUseRelationRef?: U.RelationRef governed by the exact description-use or work-use pattern
  architectureDescriptionRef: U.EpistemeRef constrained to ArchitectureDescription
  descriptionClaimGraphRef: U.ClaimGraphRef
  descriptionEntityOfConcernRef:
    exactly one builtAssetRef |
      ArchitectureRelation occurrence ref |
      selected U.Structure ref
  effectiveReferenceScheme: U.ReferenceScheme, byValue
  builtAssetRef: U.HolonRef
  architectureRelationOccurrenceRefs?: FinSet(U.RelationRef)
  architectureClaimRefs?: FinSet(U.EpistemeRef)
  selectedStructureRefs: FinSet(U.StructureRef)
  architectureStructuralViewRefs?: FinSet(U.EpistemeRef constrained to ArchitectureStructuralView)
  viewpointConformanceRelationRefs?: FinSet(EpistemeViewpointConformanceRelationRef)
  claimScope?: U.ClaimScope, byValue
  architectureConcernRefs?: FinSet(U.EpistemeRef)
  modelUseStructureRef?: U.StructureRef
  empiricalGroundingRelationRefs?: FinSet(U.RelationRef)
  referenceDesignationRelationRefs?: FinSet(U.RelationRef)
  assetInformationDescriptionRefs?: FinSet(U.EpistemeRef)
  digitalTwinDescriptionRefs?: FinSet(U.EpistemeRef)
  designRunSeparationUse?: BuiltAssetDesignRunSeparationUse, byValue
  sourceToUsePathRefs?: FinSet(U.RelationRef)
  sourceReturnCondition?:
  representationRefs?: FinSet(U.EntityRef)
  publicationOccurrenceRefs?: FinSet(EpistemePublicationRelationRef)
  publicationFormRefs?: FinSet(U.EntityRef)
  carrierRefs?: FinSet(U.EntityRef)
  descriptionFreshnessClaimRefs?: FinSet(U.EpistemeRef)
  publicationCurrentnessRelationRefs?: FinSet(U.RelationRef)
  admissibleUse:
  nextGoverningPatternApplicationRef:
  nonAdmissibleUse:

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.

Encountered descriptionFirst recoverArchitecture-description use
Spatial modelSpatial containment, placement, access, or separation structure under its direct relation pattern.Cite the exact description episteme, selected structure, viewpoint, and conformance occurrence for the exact built asset.
Functional or flow modelRequired or desired effect claims, functional structure, selected transformation-flow structure, ports, and interfaces under A.6.F, E.18, or C.30.TFS-REL; an actual transformation only under A.3.4.Keep required content, selected flow organization, actual change, and the description/view use distinct; record correspondence or positive co-reference only when its direct predicate obtains.
Product or equipment modelModule claim or admitted module relation, component, interface, allocation, or placement relations under A.6.M and their direct governing patterns.Keep the physical asset parts distinct from the description elements, representations, and publications that refer to them.
Control or operational modelExact selected control structure under C.30.LCA, together with direct control, measurement, Work, and currentness relations.Cite the control description/view without treating live values, a dashboard, or the LCA diagram as architecture adequacy or proof.
Cost, schedule, operation, maintenance, sustainability, or energy viewThe exact description episteme and selected structure; then any measurement-result episteme for a claimed Characteristic under C.16, operation or maintenance Work under A.15, positive temporal aspect under C.27.TA or action-guiding temporal claim under C.27, causal use of an intervention, maintenance action, simulation, telemetry change, or claimed effect under C.28, and evidence, reliance, or assurance under A.10 or B.3.Keep the description or view, measured Characteristic, Work, temporal aspect or claim, causal-use question and verdict, currentness boundary, evidence, and assurance distinct; cite its source-to-use path and G.11 validity or reopen condition.

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.

BuiltAssetReferenceDesignationUse:
  designationValue: local designation value, byValue
  referenceDesignationScheme: U.ReferenceScheme, byValue
  designatedEntityRef: U.EntityRef
  selectedAspectStructureRef: U.StructureRef
  designationOrReferenceRelationRef?: U.RelationRef
  qualificationWindow:
  correspondingEntityRef?: U.EntityRef
  correspondenceClaimOrRelationRef?: U.EpistemeRef | U.RelationRef
  admissibleUse:
  nonAdmissibleUse:

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:

  1. identify every source episteme used, its representation, and the publication occurrence, form, and carrier;
  2. recover the exact actual subject-relation occurrences and A.22 selected structures represented by the relation data being used;
  3. record the source-to-use path into the exact architecture description or view episteme;
  4. 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:

BuiltAssetDesignRunSeparationUse:
  designSideDescriptionRefs: FinSet(U.EpistemeRef)
  runSideDescriptionRefs: FinSet(U.EpistemeRef)
  designSideWorkOccurrenceRefs?: FinSet(U.EntityRef constrained to U.Work)
  runSideWorkOccurrenceRefs?: FinSet(U.EntityRef constrained to U.Work)
  telemetryEpistemeRefs?: FinSet(U.EpistemeRef)
  sourceToUsePathRefs: FinSet(U.RelationRef)
  descriptionFreshnessClaimRefs?: FinSet(U.EpistemeRef)
  publicationCurrentnessRelationRefs?: FinSet(U.RelationRef)
  designToRealizationCorrespondenceClaimOrRelationRefs?:
    FinSet(U.EpistemeRef | U.RelationRef)
  directCouplingRelationRefs?: FinSet(U.RelationRef)
  actualTransformationRefs?: FinSet(U.EntityRef constrained to U.Transformation)
  classificationBasis:
  admissibleCrossLifecycleUse:
  blockedMerge:

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.

Local anti-patternSymptomRepair
Design/run collapseA design description, realized asset description, telemetry episteme, operation or maintenance Work, and physical change are treated as one because a platform links or displays them together.Fill BuiltAssetDesignRunSeparationUse with the exact side-specific descriptions, Work, sources, and currentness refs; cite correspondence, coupling, or transformation only under its direct owner, or block the merged use.
Lifecycle view mergeOriginal design, as-built model, operation record, maintenance Work, and an alleged transformation are merged because one dashboard presents them as one lifecycle view.Keep each existing object and relation reference explicit; actual change enters only through A.3.4, and identity, parthood, evidence, assurance, or architecture adequacy is never inferred from co-display.

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

IDCheckRepair when absent
BA-1The exact built asset is recoverable, and every used architecture description has one exact ClaimGraph, one EntityOfConcern—built asset, obtaining ArchitectureRelation, or selected structure—and effective U.ReferenceScheme.Recover the asset under A.1, subject relations and architecture relation under C.30, selected structure under A.22, and description identity under C.2.1; do not derive the subject from an optional architecture-claim field.
BA-2Every asserted architecture structural view is the same exact description episteme whose selected-structure EntityOfConcern, structure kind, exact viewpoint, and independently obtaining E.17.0 conformance relation are named.Apply A.22, E.17.0, and C.30.ASV; do not use the file, bundle, dashboard, representation, publication, or current use as the structure or view constructor.
BA-3Every relied-on designation names its scheme, designated entity, selected aspect structure, qualification window, and exact designation/reference relation when one is claimed; design/realization correspondence remains a separate claim or relation.Recover the direct designation/reference owner and occurrence, or keep a bounded designation-use claim; never use repeated spelling as entity identity or parthood proof.
BA-4Exchange checking and architecture evaluation have different evaluated objects and governors; source episteme, representation, publication occurrence, form, carrier, actual subject relations, selected structures, and descriptions remain distinct.Keep description conformance with the exchange use; return relation truth, architecture adequacy, evidence, and assurance to their direct patterns.
BA-5Reused or live descriptions name source-to-use, source-return when stronger use needs it, description freshness, and publication-currentness objects appropriate to the exact claim.Apply G.11; do not turn freshness, synchronization, recent publication, or live data into grounding, truth, evidence sufficiency, or architecture adequacy.
BA-6Digital and physical objects retain direct kinds, identities, coupling relations, Work, and transformations; actual change is cited only with the full A.3.4 basis. Project-local use additionally names both exact composite Work and the obtaining project-use relation.Recover model, systems, epistemes, the exact composite U.Work, interfaces, coupling, actual changed referent and facts, and builtAssetDescriptionProjectUseRelationRef as the separately governed obtaining relation by which this description use concerns that Work before making identity, parthood, transformation, or project-locality claims.
BA-7Every used cost, schedule, operation, maintenance, sustainability, or energy view names exact description identity and, when asserted as a structural view, selected structure, viewpoint, and conformance; its characteristic, Work, temporal, causal-use, evidence, assurance, and currentness claims keep exact direct owners.Use C.16 for the measurement result, A.15 for Work, C.27.TA or C.27 for the exact temporal use, C.28 only when the view, telemetry, simulation, maintenance action, or claimed change is used causally, A.10 or B.3 for reliance or assurance, and G.11 for currentness; do not let the auxiliary view itself establish a causal effect, sustainability, acceptance, evidence, assurance, or architecture adequacy.
BA-8Every ISO 19650-based use names the exact part and edition, exact source-to-use path, used information or model edition, source-status reference date, validity window, refresh or source-return condition, and admissible and non-admissible use.Pin the exact published edition used; reopen this source-use locus when ISO status, the cited edition, information edition, or intended use changes. Do not silently substitute a draft or successor edition or import standard terminology as FPF ontology or authority.
BA-9Every declared use that crosses design-side and run-side material fills one BuiltAssetDesignRunSeparationUse with exact side-specific descriptions, Work when current, source and currentness refs, classification basis, admissible cross-lifecycle use, and blocked merge; correspondence, coupling, and transformation refs appear only when their direct predicates obtain.Fill the local carrier from already governed refs, or narrow or block the cross-lifecycle use. Do not restore a generic tag, infer identity or parthood from co-display, or treat telemetry, Work, correspondence, coupling, or a proposed effect as actual A.3.4 change.
BA-10A green twin, dashboard, exchange result, or release screen remains a cue unless an actual A.21 gate-decision relation is current; gate decision, release action, work-entry readiness, permission or grant act, performed Work, and a subject-release predicate remain distinct claims.Recover OperationalGate(profile), declared GateCheckRefs, GateDecision, and DecisionLogRef only for the actual gate relation. Route a release action or other performed Work to its exact A.15.1 occurrence, 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 subject-release claim to its named predicate and participants or A.6.RCD missing-governor; none is entailed by freshness, evidence, assurance, the display, or GateDecision=pass.

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

Source lineContribution used hereMutation of the patternPractitioner implication
ISO 19650-1:2018, Part 1: Concepts and principles and ISO 19650-3:2020, Part 3: Operational phase of the assets, official status checked 2026-07-31ISO 19650-1 contributes information-management concepts and principles for exchanging, recording, versioning, and organizing information across the whole built-asset life; ISO 19650-3 specifies information-management process and exchanges in the operational phase. Both cited editions are published, were last confirmed in 2024, and are marked by ISO as to be revised with draft successors under development.Adopt the exact whole-life and operational information-management discipline through source-to-use, edition, currentness, refresh, and admissible-use boundaries; do not import ISO terms as FPF U-kinds, relation truth, architecture adequacy, or authority.Cite the exact part and edition, used information or model edition, reference date, validity window, source-return or refresh condition, and admissible and non-admissible use; a draft or later edition never updates an existing use silently.
buildingSMART IFC 4.3.2 official documentationCurrent IFC exposes explicit object identities, relationship entities, decomposition, systems, processes, products, and aspect-specific schemas.IFC content enters through exact source epistemes, representations, publication objects, and source-to-use paths; relation data must be checked against actual subject relations before selecting FPF structures.Preserve useful machine-readable relation content without making an exchange schema, file, representation, or publication the built asset, relation truth, or FPF ontology.
buildingSMART IDS 1.0A current computer-interpretable specification can state and check expected IFC information.C.30.AD.BA:2.3 separates exchange-description checking from architecture evaluation and world-side relation truth.Passing an IDS check shows that declared information was delivered; it does not show that the architecture is adequate or that described relations obtain.
IEC 81346-1:2022Current reference-designation practice connects unambiguous retrieval to system structuring, aspects, objects, corresponding components, and relations between objects.The pattern uses an explicit scheme-expression-entity-structure use record, an exact direct designation/reference relation when one obtains, and a separate correspondence claim or relation when design object and realized component both matter.A stable code remains useful across descriptions without becoming universal identity, parthood proof, or an occurrence constructor.
Digital Twin Consortium AECO work and its current interoperability lineCurrent digital-twin practice emphasizes model fidelity, interoperability, physical and digital components, lifecycle use, and synchronization.C.30.AD.BA:2.4 assigns model, system, telemetry, simulation, Work, transformation, representation, publication, and currentness to their direct governors; when one use crosses design and run, BuiltAssetDesignRunSeparationUse classifies only exact existing refs on the two sides.Select the fidelity and freshness needed for the architecture use, fill the local design/run carrier only when the boundary is current, and never treat connection, co-display, or the local classification as architecture adequacy, identity, parthood, or actual change.
FPF A.1, A.22, C.30, C.30.AD, E.17.0, and C.30.ASVHolon identity, selected structure, direct architecture relation, bounded claim, description episteme, viewpoint, and structural-view conformance already have separate governing patterns.This pattern specializes their use for built assets rather than importing a built-environment upper ontology or a second description/view identity.The same method works for a building, plant, bridge, transport asset, or another engineered built holon.

Relations

  • Specializes: C.30.AD for 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, and C.30.LCA.
  • Uses description, view, representation, and publication patterns: C.2.1, A.7, E.17.0, E.17, E.24.PUB, and C.29.
  • Uses relation, naming, and currentness patterns: the exact direct designation/reference owner; A.6.P for precision repair; A.6.RCD only for a demonstrated missing reusable governor; A.6.REL only after a direct owner admits a relation and occurrence identity matters; F.18; and G.11.
  • Uses lifecycle information-management source discipline from: exact published ISO 19650-1:2018 and ISO 19650-3:2020 editions through source-to-use, edition, currentness, source-return, and admissible-use boundaries, without ontology or authority import.
  • Lowers design/run separation through: one local BuiltAssetDesignRunSeparationUse over exact C.2.1 descriptions, A.15 Work, source-use paths, G.11 currentness, 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.16 for characteristic measurement, A.15 for operation or maintenance Work, C.27.TA for positive temporal aspects, C.27 for action-guiding temporal-claim adequacy, C.28 when an intervention, maintenance action, simulation, telemetry change, or claimed effect is used causally, A.10 for evidence or material reliance, B.3 for assurance, and G.11 for currentness and reopen conditions.
  • Routes gate- and release-looking uses to: A.21 only for an actual gate-decision relation; otherwise the display remains a cue. Route a release action or other performed Work to A.15.1, 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 subject-release claim to its named predicate and participants or A.6.RCD missing-governor; none of these claims entails another.
  • Returns other claims to: A.3.4 and 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 as layer, level, tier, stack, ladder, rung, block, expert, cache, router, or gate that must go to C.30.STRAT before local architecture or structure assignment;
  • graph, flow, transformation-flow graph expression, control sketch, LCA diagram, ADR, dashboard, benchmark, source, or view being 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.22 directly.
  • If the use under repair is already ArchitectureOf@Context, use C.30 directly. If the use under repair is the full ArchitectureDescription@Context mechanism, use C.30.AD; use C.30 only 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.ASV or a named C.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@Context claim under C.30, a thin architecture-description bridge under C.30, or the full architecture-description mechanism under C.30.AD;
  • an ArchitectureStructuralView@Context or named C.30.* subcase;
  • a publication, view, face, PublicationUnit, carrier, dashboard, ADR, source document, or source-return relation under C.2.P or E.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.P or C.16;
  • a Q-bundle or quality-characterization claim under C.16.Q, C.25, or E.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 named C.30.* subpattern?

Forces

ForceTension
Ordinary engineering speech vs FPF kind recoveryEngineers need compact words such as architecture, structure, model, view, graph, module, layer, block, expert, cache, router, and gate; FPF claims need recovered kind, relation, source-use relation, and admissible use. C.30.STRAT governs the stratification-wording family and source-label family before C.30.P assigns any architecture or structure portion.
Architecture description vs architecture itselfDescriptions and views are useful, but they can be overread as the selected structure or architecture claim.
Structure generality vs architecture specificityA.22 gives selected structure; C.30 governs grounded architecture adequacy over selected architecture-relevant structures and admits only the thin architecture-description bridge when durable description use is being made. C.30.AD governs the full architecture-description mechanism. The repair must not collapse them.
Small first move vs heavy recordMost wording cases need one repair note and a subject pattern assignment, not a full architecture description.
Source and view usefulness vs project authorityA source, dashboard, graph, ADR, or view can guide architecture work without proving evidence, gate passage, decision authority, release permission, or work completion.
Cross-pattern consistency vs shadow registryArchitecture hosts should not carry duplicate trigger lists once C.30.P exists.

Solution

Repair architecture or structure wording by producing an architecture-structure repair note or an equivalent local rewrite.

Minimum fields:

ArchitectureOrStructureRepairNote:
  triggerSpan:
  boundedTextSpanOrPublicationUnit:
  encounteredFPFKindOrReference:
  candidateClaimUses:
  selectedClaimUse:
  sourcePublicationRelationSet?:
  relationClaimSlice?:
  functionOrFunctionalityClaim?:
  structureKindOrArchitectureQuestion?:
  characteristicOrQualityClaimSlice?:
  mathLensClaimSlice?:
  projectSideClaim?:
  relationFunctionClaimRef:
  repairedWordingOrDemotion:
  admissibleUse:
  nonAdmissibleUse:
  remainingReaderUse:
  disposition:

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

  1. Capture the trigger. Copy the architecture or structure wording and the sentence that uses it.
  2. 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.
  3. 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, apply C.2.P for source-use, source-currentness, and publication relations before assigning the architecture or structure claim.
  4. Choose the subject pattern for the architecture or structure use.
    • selected structure -> A.22;
    • ArchitectureOf@Context, selected architecture-relevant structure, or thin conditional ArchitectureDescription@Context bridge use -> C.30;
    • full ArchitectureDescription@Context mechanism -> 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, or gate -> C.30.STRAT before choosing the final subject pattern;
    • named C.30 subcase -> that subpattern.
  5. 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.
  6. State admissible and non-admissible use. Say what the reader may do with the repaired wording and what non-admissible adjacent interpretation is blocked.
  7. Stop C.30.P after assignment. Stop after the subject pattern or ordinary-prose demotion is named.

Subject pattern assignments

Recovered use, claim kind, or admissible-use boundarySubject pattern
selected structure, structural description, structure source-returnA.22
ArchitectureOf@Context, selected architecture-relevant structure, thin conditional ArchitectureDescription@Context bridge use, architecture question cardC.30
full ArchitectureDescription@Context mechanism, architecture-description multi-view set, architecture-description specification-use boundaryC.30.AD
architecture structural view, structure-kind view, hidden or lost structureC.30.ASV
transformation-flow graph expression, flow relation, architecture-to-transformation-flow relationC.30.TFS-REL when an architecture-to-transformation-flow relation claim is being made; otherwise E.18 or the subject pattern for the claim being made
architecture-synthesis wordingRecover the concrete claim kind, then use the architecture-synthesis routing note below.
control structure view, LCA sketch or control sketchC.30.LCA when an architecture control-structure view claim is being made
cross-scope conflict or frustration triageC.30.ILC when that question is being asked
source, publication, carrier, view, face, PublicationUnit, dashboard, ADR, documentation, source-returnC.2.P, E.17, E.17.0, or the publication or source-use pattern governing the claim
relation construction, basedness, source, base-dependence, evidence and relation-claim discrimination, endpoint compression, comparisonA.6.P or the A.6 specialization selected by the recovered claim
function, functional, functionality, effect, module, interface, or signature claimA.6.F, A.6.M, A.6 signature and slot pattern, or the retained module, interface, or signature specialization selected by the claim
stratification or source labels such as layer, level, tier, stack, ladder, rung, block, expert, cache, router, or gateC.30.STRAT; after recovery, use A.22, C.30, C.30.ASV, C.30.LCA, C.30.TFS-REL, A.6.M, A.6.F, E.18, C.16.P, C.29, or the pattern governing the recovered claim
mathematical lens, mapping, model, similarity, preserved-structure and lost-structure as mathematical-lens useC.29
characteristic, scale, metric, score, indicator, threshold, architecture score, quality coordinateC.16.P, then C.16, A.19, C.25, E.21, or the pattern governing the claim
quality-term or evaluative characterizationC.16.Q, C.25, E.21, or the characterization pattern governing the claim
evidence, proof, validation, witnessA.10 or the evidence pattern governing the claim
assurance, engineering justification, safety caseB.3 or the assurance pattern governing the claim
gate, admissibility, release, approvalA.20, A.21, release or admissibility pattern, or the gate pattern governing the claim
work, method, implementation, operation, change executionA.15, A.15.4, U.Method, U.MethodDescription, or the work or method pattern governing the claim
decision, choice, trade-off resultC.11 or the decision pattern governing the claim
causal-use or intervention claimC.28

Architecture-synthesis routing note:

  • Use C.32, C.32.MLAO, C.32.CONWAY, or C.32.FAIL when 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, or G.5 when the recovered claim is comparison-policy use, selector-policy use, local choice, or selected-set result declaration. When publication is current, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability.
  • Use C.18 or C.19 when 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.P begins 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

WordingRepair
"The architecture is the diagram."The diagram is a publication, carrier, source cue, architecture description rendering, or structural view. It is not the architecture itself. Apply C.2.P if a a source-publication relation set is being made, then C.30 or C.30.ASV only if the architecture claim or structural view is recovered.
"ArchitectureOf@PlantOps is defined over structures S1 and S2 under context C."Direct C.30; no C.30.P unless another selected structure, architecture-description use, structural-view use, source-return relation, or named C.30 subcase remains hidden.
"This ADR changed the architecture."Recover whether the ADR is a publication, decision record, document with named source-use relation, architecture-description update, work plan, or ordinary source. Use C.2.P, C.11, A.15, or C.30 when the corresponding claim kind is being made.
"The flow graph proves the architecture is safe."Flow graph expression and architecture-to-transformation-flow relation are not proof or safety assurance. Use E.18 and C.30.TFS-REL for flow relation, B.3 or evidence patterns for assurance, C.30 only for the grounded architecture claim or thin conditional architecture-description bridge, and C.30.AD when the full architecture-description mechanism is being used.
"The architecture score improved."Recover whether the sentence means grounded architecture adequacy, selected-structure characteristic and scale score, pattern-quality coordinate, Q-bundle, benchmark result, gate threshold, or ordinary comparison. Apply C.16.P before any score-based use.
"Functional architecture improved maintainability."Recover function or functionality use via A.6.F when hidden, then architecture structural view via C.30.ASV or quality or maintainability via C.16.P, C.16.Q, C.25, or quality pattern governing the claim.
"The module layer supports the architecture."Treat layer first as a source label and apply C.30.STRAT. Use C.30.P only for the architecture or structure portion after recovery; use A.6.M only if a module-interface relation is recovered, to C.30.LCA only if a control-layer relation is recovered, to C.2.P if this is a publication label or view label, to A.6.P if a basedness, source-use, evidence, or reliance relation is being made, or to ordinary source-label disposition.

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.

Practice sourceSource-use relation and currentnessWhat C.30.P adopts or adaptsFPF import boundary
ISO/IEC/IEEE 42010:2022 on architecture descriptions, architecture viewpoints, model kinds, and conformance requirements.Current standard and reference source for architecture-description and viewpoint separation.Disciplines direct use of C.30 and C.30.ASV; blocks diagram-as-architecture, model-as-architecture, view-as-architecture, and publication-as-architecture overread; disciplines CC-C30P-2, CC-C30P-3, and CC-C30P-4.Does not import 42010 terminology as FPF ontology; FPF still uses A.22, C.30, C.30.ASV, and named C.30.* patterns.
SEI "Documenting Software Architectures: Views and Beyond" practice line.Current reference and lineage source for documenting views for stakeholder use.Disciplines the source, publication, and view split in worked cases and keeps view artifacts useful without making them the selected structure.Does not make "view" a generic proof or decision record.
C4 model current practice for developer-friendly architecture diagrams over context, container, component, and code views.Current practice anchor for diagram usefulness and diagram limits.Disciplines the diagram, block, component, module, and layer examples: a diagram can be an entry or view publication, and source labels are recovered through C.30.STRAT before architecture or structure assignment.Does not make C4 levels, blocks, layers, or containers FPF structure kinds or mandatory architecture views.
arc42 current architecture documentation template practice.Current practice and reference source for architecture communication, constraints, decisions, and cross-cutting concerns.Disciplines the distinction between documentation template sections, source publications, decisions, architecture claims, and conditional architecture-description use.Does not let a documentation section, template heading, or dashboard become architecture authority by label.
ADR and MADR architecture decision record practice.Current practice and lineage source for decision-record separation; current empirical ADR work may refine template choice, but does not replace FPF decision ontology.Disciplines the ADR worked case and the assignment to C.2.P, C.11, A.15, or C.30: an ADR may record or motivate a decision; it is not automatically the architecture decision, work execution, or architecture itself.Does not import ADR label as gate, release, proof, or FPF decision authority.

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

CheckRequirement
CC-C30P-1The repair names the trigger span, encountered FPF kind or reference, selected use under repair, subject pattern, admissible use, non-admissible use, and remaining reader use.
CC-C30P-2A diagram, model, graph, dashboard, ADR, source, publication, view, face, PublicationUnit, file, carrier, or rendering is not treated as architecture or structure by appearance.
CC-C30P-3Direct A.22, C.30, C.30.ASV, or named C.30.* use applies the subject pattern directly when the selected-structure claim being made, architecture relation, architecture-description use, structural-view use, or named C.30 subcase is already recoverable.
CC-C30P-4Source-use, currentness, and publication-to-carrier relation recovery uses C.2.P before architecture or structure claim use when that relation set is being made.
CC-C30P-5Function-like, relation-like, mathematical-lens, characteristic and scale, quality, evidence, assurance, gate, work, decision, causal-use, release, and method claims are assigned to their subject patterns.
CC-C30P-6The repair does not mint U.Architecture, ArchitectureStructure, a generic architecture head, or mandatory architecture-repair record.
CC-C30P-7The subject architecture or structure pattern keeps its own invariant central and carries at most a thin pointer back to this pattern.
CC-C30P-8The repaired wording preserves one useful admissible reader use; type-correct but inert architecture wording is not recovered by value.

Common anti-patterns

Anti-patternSymptomRepair
Diagram-as-architectureA diagram, graph, dashboard, ADR, or generated view is said to be the architecture.Recover publication, carrier, view, or source-use relation and then apply C.30 or C.30.ASV only if the architecture claim or structural-view claim is being made.
Architecture-as-proofArchitecture wording carries evidence, assurance, causal proof, gate passage, release permission, or decision authority.Apply A.10, B.3, C.28, A.20, A.21, C.11, release, or the pattern governing the claim being made.
Function-as-default-architectureAny function, interface, module behavior, or source label such as block is treated as architecture.Use C.30.STRAT for source-label recovery where needed, then A.6.F, C.30.ASV functional-structure, C.30.TFS-REL transformation-flow structure relation, A.6.M module-relation repair, or quality pattern governing the claim.
Score-as-architectureA score, metric, benchmark, or quality coordinate is used as architecture adequacy.Apply C.16.P and the measurement named by value, characteristic-space, Q-bundle, pattern-quality, gate, or benchmark pattern.
Viewpoint-as-structure-kindA viewpoint label is used as if it selected structure kind.Use C.30.ASV; recover structure kind and viewpoint separately.
Repair registry duplicationA.22, C.30, C.30.ASV, or a named C.30.* host copies architecture or structure first-stage repair lists.Keep the subject invariant there and use one thin pointer to C.30.P.
  • E.10 catches 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.ARCH defines the shared wording-use recovery order and applicability row.
  • A.22 governs selected structure and structural views as structure.
  • C.30 governs grounded ArchitectureOf@Context adequacy and thin conditional ArchitectureDescription@Context bridge use.
  • C.30.AD governs the full architecture-description mechanism when ArchitectureDescription@Context is the EntityOfConcern under repair.
  • C.30.ASV governs architecture structural views.
  • C.30.STRAT governs 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.P recovers source, publication, view, face, PublicationUnit, carrier, and source-use disposition.
  • A.6.P repairs relation construction; A.6.F repairs function and functionality wording; A.6.M repairs module-relation and interface-specification wording.
  • C.16.P repairs characteristic-and-scale wording, and C.16.Q repairs quality-term or evaluative characterization wording before score or quality use.
  • C.29 governs 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.30 Status: 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

ForceTension
Source-language usability vs ontologyPractitioners need compact local words; a technical claim needs the actual object or relation, its participants or bearer, its scope, and its allowed use.
Pattern placement vs applicable ruleThis pattern sits under C.30 because architecture prose is the usual entry, but the recovered claim may belong to control, modules, flow, scale, publication, state, evidence, work, or decision.
Thin repair vs shadow registryOne shared cue table is useful; copied local trigger lists are not.
Known meaning vs detourWhen the current object or relation is already clear, use its pattern directly.
Precision vs actionA type-correct result is still a failure if the reader cannot see what to do next.

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:

StratificationSourceLabelRepairNote:
  sourceLabel:
  boundedTextSpan:
  recoveredObjectRelationOrClaim:
  actualParticipantsOrBearer?:
  sourceUseDisposition:
  patternRef?:
  repairedWordingOrDemotion:
  admissibleUse:
  stopOrReturnCondition:
  blockedOverread?:
  remainingReaderUse:
  disposition: direct-pattern-use | local-rewrite | ordinary-source-label |
    quote-only | reduced-use-cue | blocked-use | incomplete-rewrite

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

  1. Copy the sentence and label. Keep enough source context to tell what the sentence is doing.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Return to ordinary wording. Write the shortest sentence that preserves the recovered claim and names the next pattern only when its contribution matters.
  7. 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

Recovered meaningCommon source labelsWhat must become clearPattern to use
Control structurelayer, level, tier, sometimes gateThe obtaining control relation, what its participants do, any rate band or locality boundary, and a B.2.5 supervisor-subholon relation only when it obtains.C.30.LCA; use B.2.5, dynamics, temporal, evidence, assurance, or gate patterns only for their separate claims.
Selected structure or structural viewlayer, level, stack, block, viewThe selected, hidden, lost, or preserved structure; view selection; correspondence; source return; an ArchitectureClaim when claim content is needed; and a separate ArchitectureRelation only when that direct relation obtains.A.22, C.30, C.30.ASV, or the applicable C.30 subpattern.
Module, interface, or substitutionblock, cache, router, expert, sometimes layer or stackModule boundary, interface specification, substitutability relation, variation point, conformance relation, or reliance boundary.A.6.M; stop using C.30.STRAT once that relation is clear.
Function or transformation flowblock, expert, cache, router, gate, sometimes layerTransformation or effect, path selection, graph node, path or crossing, architecture-to-flow relation, or E.18 flow valuation.A.6.F, E.18, or C.30.TFS-REL.
Characteristic, scale, or mathematical lenslevel, tier, ladder, rung, layer, stack, blockCharacteristic and bearer, coordinate or value, scoring method, comparison criterion, scale window, resolution, coarse-graining, preserved or lost structure, lens-use result, and stop condition only where the claim needs them. State separately how the subject is mapped to a scale value; a scale or band does not by itself establish levels in the subject.C.16.P, the applicable characterization pattern, or C.29.
Episteme, publication, view, or source usestack, layer, section, view, cache, gateDescription episteme, publication unit, face, form, carrier, source-currentness or source-use relation, source-return condition, or ordinary publication label.C.2.P, E.17, or the pattern for the publication or source-use claim.
State, currentness, time, or dynamicscache, stable, level, readiness, sometimes gateBearer, state frame and values, validity window, currentness relation, dynamics, temporal aspect or rate band, authored temporal-claim adequacy, and reopen condition.A.19.SPR, A.3.3, C.27.TA, C.27, or the applicable state or temporal pattern.
Evidence, assurance, gate, work, decision, or causal usegate, proof, safety, decision, work, effect, or any label used as authorityEvidence path, assurance argument, constraint-validity record, gate decision, Work occurrence, decision record, causal-use record, and any limits imposed by the applicable pattern on that claim.A.10, G.6, B.3, A.20, A.21, A.15, C.11, C.28, or the applicable neighboring pattern.
Ordinary source-label non-useany source labelNo FPF claim remains after the sentence is read in context.No precision-restoration pattern; keep ordinary wording, quote it, reduce its use, or block reliance.

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

Source label familyRecovery discipline
layerDo not choose by the word. Test control structure; selected structure or structural view; module or interface; scale or mathematical lens; and publication or source-use meanings.
levelBefore relying on “X is at or above level L,” name the subject, 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 claim is asserted, proposed, assumed, or only illustrated. List order, a diagram row, first-then sequence, carrier section, curriculum, scale label, stage sequence, or coarse-grained view supplies none of these. Then test holon or aggregation use only when a named relation or structure pattern defines it; otherwise test characteristic or scale, ordinal classification, organization scope, Work scope, evidence scope, publication grouping, or ordinary source-label non-use.
tierTest deployment, service, organization, classification, aggregation, and publication meanings. When one of those claims is current, use the pattern that defines or tests it; tier itself is not the ontology.
stackTest signature or slot construction, relation set or relation chain, architecture or control arrangement, aggregation arrangement, virtualization arrangement, deployment arrangement, publication-section ordering, or ordinary source-label non-use. A stack is not architecture by itself.
ladder and rungTest ordinal or classification scale, declared maturity or readiness progression, C.28 causal-use ladder or rung, publication taxonomy, or ordinary source-label non-use. Do not use ladder wording for an undeclared progression scale.
blockTest module or interface, selected structure or structural view, function or transformation flow, mathematical lens or coarse-graining, evidence, causal use, gate, and decision meanings.
expertIn MoE-like prose, first test submodel, subholon, specialized transformation, path-selection relation, candidate-selection relation, ordinary wording, or source-label non-use. If claim-bearing wording still means only “role,” use E.10.ROLE; then recover independently any local system-role kind, separate System-classification judgment, obtaining assignment, performer System and complete Work-attribution basis, responsibility or authority relation, or another direct subject relation. Infer none from expert.
cacheTest module-interface, flow buffer or path, state or currentness, capacity characteristic, latency characteristic, memory characteristic, reuse characteristic, source-currentness, publication cache, temporal-aspect or rate-band claim, authored temporal-claim adequacy, or ordinary source-label non-use.
routerTest path selection, flow relation, transformation function or selection function, module-interface relation, candidate selection, decision, ordinary label, local system-role kind, separate System-classification judgment, obtaining assignment, or actual Work only when that exact claim is being made.
gateTest constraint-validity record or gate-decision record, gating function, path selection, flow relation, publication label, or ordinary source-label non-use. A source label gate is not gate passage.

Author-facing placement note

This subsection maintains the E.10.ARCH applicability row; it is not part of the ordinary project result.

  • semanticAreaBaseConcept is stratification wording and architecture-operation source labels.
  • semanticArea is the Part-F row-set for layer, level, tier, stack, ladder, and rung, plus block, expert, cache, router, and gate when they appear before their technical meaning is known.
  • semanticAreaSenseFamily is source-label wording for stratification, ordering, aggregation, and architecture-operation recognition. It is not a topic, workstream, or pattern grouping.
  • ontologicalNeighborhood is 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

WordingRepair
The module layer is stable.Keep layer as a source label until the sentence reveals a module or interface relation, scale or comparison, publication or view, state, dynamics, or temporal claim. Use only the matching pattern: for example A.6.M, C.16.P, C.29, C.2.P, A.19.SPR, A.3.3, C.27.TA, or C.27.
The expert routes the token.In mixture-of-experts prose, first test submodel or subholon, specialized transformation, path selection, architecture-to-flow relation, candidate selection, ordinary wording, or non-use. Only an unresolved claim-bearing use of role opens E.10.ROLE; any system-role kind, classification, assignment, performer, Work, responsibility, or authority claim must then obtain independently.
The cache proves the architecture scales.Split three questions: what cache names, whether an evidence or assurance relation exists, and what measurable scale or lens-use claim is being made. Use A.6.M, A.6.F, E.18, state or temporal patterns, C.16.P, C.29, A.10, B.3, or G.6 only for the branch that is actually present.
The LCA upper layer guarantees safety.First decide whether layer names a control relation. If so, C.30.LCA records the relation, participant meanings, rate band, and relevant locality or model-use boundary. Safety, evidence, assurance, dynamics, temporal, and gate claims remain separate.
The architecture description places service logic in the application layer.Recover the description's declared viewpoint or model-kind convention and what application layer means there. It may be a useful grouping in the description. State separately any claim that the described system itself has an obtaining layer, dependency, module, control, or flow relation; neither the diagram position nor architecture-description conformance establishes that world-side claim.
Our operating model has strategic, coordination, and execution levels.If these are only headings or work areas, keep them as local labels. Before claiming levels in an organization or practice, say what the three areas are, how they are ordered or mapped, when that ordering applies, and whether it is asserted, proposed, assumed, or only illustrated. Slide order, a curriculum, or a first-then flow establishes none of this.
This gate selects the winning architecture.A neural-network gate or router uses A.6.F or E.18; a project gate decision uses A.20 or A.21; candidate selection uses G.5 or C.11. The label alone decides none of these.

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:

  1. cache may name a state-bearing module, interface arrangement, flow buffer, or ordinary source label; the sentence does not yet decide which;
  2. proves requires an actual evidence relation or assurance argument; otherwise lower that wording;
  3. scales requires a characteristic and bearer, comparison or scale construction, architecture scale-preference claim, or mathematical-lens use.

A retained note can remain compact:

StratificationSourceLabelRepairNote:
  sourceLabel: cache
  boundedTextSpan: “The cache proves the architecture scales.”
  recoveredObjectRelationOrClaim: cache meaning unresolved; proof and scale are separate claims
  sourceUseDisposition: keep cache as a source label until its relation or bearer is known
  patternRef?: A.6.M, A.6.F, E.18, A.19.SPR, or A.3.3 for the cache;
    C.16.P, C.29, or C.31.ASAP for scale; A.10, B.3, or G.6 for proof or assurance
  repairedWordingOrDemotion: “Identify what ‘cache’ names here, which scaling claim is being made, and what evidence supports it.”
  admissibleUse: start the three-way investigation
  stopOrReturnCondition: return to the source for the missing cache meaning, scaling basis, or evidence; use the direct pattern once that branch is recovered
  blockedOverread?: the source's proof-and-scale claim remains unsupported while its cache subject, scaling basis, and evidence are unresolved
  remainingReaderUse: state the smallest result for each recovered claim, or keep ordinary source wording
  disposition: reduced-use-cue; direct-pattern-use only for branches that become current

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

Template elementU.System illustrationU.Episteme illustration
Source-label cueA neural-network source says an expert block sits above a router layer.A publication note says a cache layer keeps a diagram or view current.
Recovery resultThe words stay source labels until module, function, path-selection, flow, or selected-structure facts become clear.The words stay source labels until publication, view, state, currentness, temporal, or ordinary non-use facts become clear.
Next moveUse A.6.M, A.6.F, E.18, C.30.TFS-REL, G.5, or C.11 only for the recovered claim.Use C.2.P, E.17, A.19.SPR, A.3.3, C.27.TA, or C.27 only for the recovered claim.

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

IDCheck
CC-C30STRAT-1The source word remains a source label until an object, relation, claim, or ordinary non-use is recovered.
CC-C30STRAT-2The result names the bounded sentence, recovered meaning, any actual participants or bearer needed by the claim, repaired wording, allowed use, next action, and stop or return condition; an optional blocked overread passes F.19's plausible-reader test.
CC-C30STRAT-3No universal kind is minted for layer, level, tier, stack, ladder, rung, block, expert, cache, router, gate, or stratification.
CC-C30STRAT-4The recovered meaning selects the applicable rule; the label and C.30 placement do not.
CC-C30STRAT-5A known object or relation uses its pattern directly, without a restoration detour.
CC-C30STRAT-6Several claims compressed into one sentence are separated; they are not forced under one label or invented common head.
CC-C30STRAT-7Other patterns keep at most a thin pointer here and do not copy the cue table.
CC-C30STRAT-8The engineer gets the shortest usable sentence or compact note; E.10.ARCH routing coordinates remain author-facing.
CC-C30STRAT-9A consequential level claim names the subject, says what is being ordered, compared, grouped, or mapped and how, states when the claim applies, and marks it as asserted, proposed, assumed, or illustrative. No list, diagram row, first-then order, carrier section, curriculum, scale label, stage sequence, or coarse-grained description supplies that claim by form.
CC-C30STRAT-10A label is treated as a designation in one bounded source use. Any model, viewpoint, standard, or local-vocabulary meaning is preserved in that use without becoming a universal kind or relation.
CC-C30STRAT-11An architecture-description element is distinguished from the architecture or other world-side subject it describes; any claimed subject relation is stated and tested separately.
CC-C30STRAT-12Controlled-language repair is used only when ambiguity changes reader action. It shortens or splits the sentence without deleting clear subject-specific terminology or choosing ontology from an approved-word list.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
Source label as ontologylayer, block, expert, cache, or gate is treated as a kind by name.Recover the actual object or relation, or keep ordinary source wording.
C.30 takeoverEvery structure-like word is treated as an architecture claim.Choose from the recovered meaning; use the rule for the actual control, module, flow, scale, publication, state, evidence, work, or decision claim.
Standard-label overreachA standard or popular model uses layer or level, so its local convention is treated as a universal subject structure.Preserve the convention inside its declared source use; state and test any wider object, relation, mapping, or architecture claim separately.
Controlled-language purgeA preferred-word rule deletes a clear domain term or replaces it with formal apparatus although no reader action was at risk.Keep the term; repair only the ambiguity that changes use, using the shortest direct sentence.
Level by layoutA list, vertical diagram, first-then flow, carrier section, curriculum, scale label, stage sequence, or coarse-grained description is treated as a subject stratification.Keep the wording local, or name the subject, say what is being ordered, compared, grouped, or mapped and how, state when the claim applies, and mark it as asserted, proposed, assumed, or illustrative; then use the pattern that defines or tests that claim.
Local trigger fanoutC.30.LCA, A.6.M, C.31, or another pattern copies this label catalogue.Keep one thin pointer here and the other pattern's own invariant there.
Expert-as-role false positiveexpert in mixture-of-experts prose becomes a system-role kind, assignment, performer, Work, responsibility, or authority by word alone.First test submodel, transformation, path selection, candidate selection, or ordinary non-use. If a claim-bearing use of role remains, use E.10.ROLE; admit each system-role, classification, assignment, performer, Work, responsibility, authority, or other relation only when it independently obtains.
Gate-as-decision false positiveA gating function, UI label, or source word becomes gate passage.Use A.20 or A.21 only for actual constraint-validity or gate-decision claims; otherwise use the applicable function, flow, publication, or ordinary-label result.

Consequences

BenefitTrade-off or mitigation
Local labels remain usable without becoming root kinds.The reader pays a recovery cost only when the word carries a technical claim; ordinary prose closes immediately.
One cue table replaces copied local catalogues.Other patterns need accurate thin pointers and must still state their own invariants.
A compressed sentence no longer smuggles several claims under one word.The repair may name several applicable patterns, but only for branches that the sentence actually contains.

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.

Current source or practiceBy-value decisionContribution carried into this patternLimit and receiving loci
ISO 704:2022, Terminology work — Principles and methodsCurrent published terminology-work standard checked 2026-08-22. Adapt: distinguish objects, concepts, definitions, and designations before standardizing a term; do not require a terminological entry for every ordinary sentence.Treat layer, level, gate, and their neighbours first as designations in a bounded source use. Recover the object, relation, or claim before choosing a technical pattern.A designation is not the thing or claim it helps name. Applied in recovery steps 2-4, the cue table, CC-C30STRAT-1/10, and the standard-label anti-pattern.
ISO/IEC/IEEE 42010:2022, Architecture descriptionCurrent published architecture-description standard checked 2026-08-22. Adopt narrowly: distinguish an entity's architecture from an architecture description and recover the viewpoint or model-kind convention used by the description. Reject: using this standard as a system ontology, architecting Method, or proof that a described layer exists in the world.When a label occurs in an architecture description, recover first what the description element means in its declared model or viewpoint; state separately any world-side structure or relation the sentence claims.Architecture-description conformance is not architecture truth. Applied in recovery steps 3-5, the architecture-description worked case, the level-claim boundary, and CC-C30STRAT-11.
ASD-STE100 Issue 9 (2025), Simplified Technical English and its scope explanationCurrent maintained controlled natural language checked 2026-08-22. Adapt: use short direct sentences and disambiguate a word when misunderstanding changes action; preserve subject-specific nouns and verbs. Reject: applying its controlled dictionary as a universal FPF vocabulary or deleting clear domain terms by lexical rule.Keep the cheap exit and shortest direct repair; split compressed claims; preserve an already clear source-local technical term.Controlled-language conformance cannot choose ontology and is not needed for every prose use. Applied in recovery steps 2 and 6, CC-C30STRAT-8/12, and the controlled-language-purge anti-pattern.
Current FPF E.10, E.10.ARCH, F.18, F.19, and the direct subject patternsCurrent local architecture. Adopt: F.19 ordinary rewrite, E.10 cues, ontology-first recovery, direct source-local naming, and return to the pattern that defines or tests the recovered claim.One short repair states recovered meaning, allowed use, next action, stop or return condition, and any blocked overread justified through F.19; author-facing routing stays out of ordinary project work.This composition is the novel FPF synthesis. It must be reopened when a selected external source or a direct subject pattern supplies a better low-burden repair. Applied throughout Solution, Grounding, checklist, and Relations.

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.

ArchitectureStructureKindTriage@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureStructuralViewProjectUseRelationRef?: U.RelationRef, only when a named pattern defines this project-use relation and the occurrence obtains
  architectureClaimRef?: U.EpistemeRef constrained to ArchitectureClaim
  architectureRelationOccurrenceRef?: ArchitectureRelationRef
  describedHolonRef?: U.HolonRef
  candidateViewEpistemeRef?: U.EpistemeRef
  exactViewpointRef?: U.ViewpointRef
  viewpointConformanceRelationRef?: EpistemeViewpointConformanceRelationRef
  claimScope?: U.ClaimScope, byValue
  effectiveReferenceScheme?: U.ReferenceScheme, byValue
  modelUseStructureRef?: U.StructureRef
  candidateStructureKindRefs: FinSet(ArchitectureStructureKindRef)
  smallestUsefulStructureKindRefs: FinSet(ArchitectureStructureKindRef)
  selectedStructureRefs?: FinSet(U.StructureRef)
  claimPatternRefs?: FinSet(PatternRef), if another claim is being made
  admissibleArchitectureMove:
  stopCondition:

@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

ForceTension
View usefulness vs view overreadViews make architecture discussable, but a useful description episteme, diagram, or publication form can be mistaken for architecture, selected structure, view membership, proof, or decision.
Structure kind vs viewpointA structure kind classifies selected structure; one exact viewpoint episteme states the rules under which the same candidate episteme is a view. They often appear together but are not the same object.
TEVB template reuse vs architecture-specific structureE.17.2 distinguishes four useful authoring positions but supplies no current family or viewpoint references. Only a materialized project-local declaration supplies exact reusable U.ViewpointRef values; architecture-specific structure kinds are defined beside them and alter neither the resolved P editions nor declaration membership.
Small triage vs full view recordMany cases need only the structure kind under consideration and next architecture use; the full description-plus-conformance record is justified only when it changes action.
Multi-view correspondence vs single-view shortcutArchitecture work often needs relations among functional, flow, control, module, information, work, evidence, scale, and placement views; one favored diagram cannot carry all claims.
Hidden structure vs practical compressionA useful view omits something; omitted structure becomes a problem only when subsequent action relies on it.

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.

ArchitectureStructuralView ::= ArchitectureDescription & U.View & {
  viewEpistemeRef: U.EpistemeRef,
  claimGraph: exactly one C.2.1 ClaimGraph,
  entityOfConcernRef: selectedStructureRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,

  selectedStructureRef: U.StructureRef,
  relatedStructureRefs?: FinSet(U.StructureRef),
  structureKindRef: ArchitectureStructureKindRef,

  viewpointRef: U.ViewpointRef,
  viewpointConformanceRelationRef: EpistemeViewpointConformanceRelationRef,
  concernRefs?: FinSet(U.EntityRef),

  describedHolonRef?: U.HolonRef,
  architectureRelationOccurrenceRefs?: FinSet(ArchitectureRelationRef),
  architectureClaimRefs?: FinSet(U.EpistemeRef constrained to ArchitectureClaim),
  claimScope?: U.ClaimScope, byValue,
  modelUseStructureRef?: U.StructureRef,
  empiricalGroundingRelationRefs?: FinSet(EpistemeEmpiricalGroundingRelationRef),

  recordPatternLocator,
  selectedRelationKindRefs?,
  selectedConstraintRefs?,
  selectedInvariantRefs?,
  selectedOperationDescriptionRefs?,
  selectedDynamicsDescriptionRefs?,
  viewConstruction:
    directDescription | projection | query | extraction |
    coarsening | correspondenceSlice | sourceReturnSlice,
  structuralAspectDescriptionRef?: U.EpistemeRef,
  hiddenOrLostStructure,
  structureKnowledgeState?:
    declared | observed | inferred | generated | simulated |
    extracted | hypothesized | unknownRegionPresent,
  correspondenceClaimOrRelationRefs?: FinSet(U.EpistemeRef | U.RelationRef),
  sourceToUsePathRefs?: FinSet(U.RelationRef),
  workRelianceRelationRefs?: FinSet(U.RelationRef),
  sourceReturnCondition?,

  representationRefs?: FinSet(U.EntityRef),
  publicationOccurrenceRefs?: FinSet(EpistemePublicationRelationRef),
  publicationFormRefs?: FinSet(U.EntityRef),
  carrierRefs?: FinSet(U.EntityRef constrained to U.PresentationCarrier),
  admissibleUse,
  nonAdmissibleUse
}

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.

ArchitectureStructureKindRef ::= one of {
  FunctionalStructure,
  TransformationFlowStructure,
  ControlStructure,
  ModuleInterfaceStructure,
  RuntimeInteractionStructure,
  PlacementDeploymentStructure,
  InformationDataStructure,
  SecurityTrustBoundaryStructure,
  ConstraintRequirementStructure,
  MaterialSpatialStructure,
  DeclaredLogicalStructure,

  WorkMethodStructure,
  AllocationResponsibilityStructure,
  EvidenceAssuranceStructure,
  ScaleEvolutionStructure,
  OtherDeclaredStructureKind
}

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.ReferenceScheme when 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.

ArchitectureStructureKindTriage@Project ::= {
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work,
  architectureStructuralViewProjectUseRelationRef?: U.RelationRef, only when a named pattern defines this project-use relation and the occurrence obtains,
  architectureClaimRef?: U.EpistemeRef constrained to ArchitectureClaim,
  architectureRelationOccurrenceRef?: ArchitectureRelationRef,
  describedHolonRef?: U.HolonRef,
  candidateViewEpistemeRef?: U.EpistemeRef,
  exactViewpointRef?: U.ViewpointRef,
  viewpointConformanceRelationRef?: EpistemeViewpointConformanceRelationRef,
  claimScope?: U.ClaimScope, byValue,
  effectiveReferenceScheme?: U.ReferenceScheme, byValue,
  modelUseStructureRef?: U.StructureRef,
  architectureConcernCue?,
  sourcePhrase?,
  inspectedDescriptionOrViewRef?: U.EpistemeRef,
  candidateStructureKindRefs: FinSet(ArchitectureStructureKindRef),
  smallestUsefulStructureKindRefs: FinSet(ArchitectureStructureKindRef),
  selectedStructureRefs?: FinSet(U.StructureRef),
  hiddenOrLostStructureCueRefs?,

  admissibleArchitectureMove:
    inspect | split | relate | downgrade | nameApplicablePattern | stop |
    otherDeclared,
  claimPatternRefs?: FinSet(PatternRef),
  nonAdmissibleOverread?,
  stopCondition
}

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:

Functional -> FunctionalStructure
Flow -> TransformationFlowStructure
Control -> ControlStructure
Module -> ModuleInterfaceStructure
Method and work -> WorkMethodStructure
Allocation and responsibility -> AllocationResponsibilityStructure
Evidence -> EvidenceAssuranceStructure
Scale -> ScaleEvolutionStructure
Security -> SecurityTrustBoundaryStructure

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."

ArchitectureCandidateStructuralDescription:
  CandidateSetOrArchiveRef:
  CandidateRef:
  DescribedHolonOrArchitectureRelationRef:
  SelectedStructureOrStructureKindRef:
  CandidateDescriptionEpistemeRef:
  ExactViewpointRef?:
  ViewpointConformanceRelationRef?:
  AffectedCharacteristicRef:
  CorrespondenceOrLossRef?:
  NextQuestionPatternLocator:

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:

  1. constitutes exact L through obtaining EpistemeConstitutionRelation(G_L, K_L, R_L);
  2. places one local declaration claim block inside exact G_L, retrieved by ordinary familyDesignator = f_arch under R_L;
  3. states the exact target-kind compatibility condition and a finite non-empty set of exact U.ViewpointRef members;
  4. resolves every retained reference under R_L to one exact P already admitted under E.17.0; and
  5. 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:

ArchitectureViewpointFamilyTemplate ::= {
  catalogueConstitution: <G_L, K_L, R_L>,
  catalogueEpistemeRef: L,
  catalogueLocator: <editionDesignator(L), f_arch>,
  targetKindCompatibilityCondition: exact criterion that candidate E has recoverable C.2.1 identity and EntityOfConcern(E) is one selected U.Structure, stated by value or by ClaimGraph reference,
  viewpointRefs: {
    r_architecture_structure,
    r_architecture_correspondence,
    r_architecture_source_return,
    r_architecture_decision_affected_structure
  },
  resolutions: {
    resolve_R_L(r_architecture_structure) = P_architecture_structure,
    resolve_R_L(r_architecture_correspondence) = P_architecture_correspondence,
    resolve_R_L(r_architecture_source_return) = P_architecture_source_return,
    resolve_R_L(r_architecture_decision_affected_structure) = P_architecture_decision_affected_structure
  },
  optionalReaderDesignators: {
    d_architecture_structure,
    d_architecture_correspondence,
    d_architecture_source_return,
    d_architecture_decision_affected_structure
  },
  importedReferenceProvenance?: {
    <editionDesignator(L_source), sourceFamilyDesignator, exactSourceViewpointRef>
  }
}

ArchitectureStructureKindViewRecordBinding ::= {
  catalogueEpistemeRef: L,
  catalogueLocator: <editionDesignator(L), f_arch>,
  structureKindRef: ArchitectureStructureKindRef,
  allowableViewpointRefs: FinSet(U.ViewpointRef),
  candidateViewRecordSetRef,
  allowedViewConstructionModes,
  requiredConformanceRuleRefs,
  requiredCorrespondenceClaimOrRelationRefs?,
  sourceReturnRequirement?,
  claimPatternRefs: FinSet(PatternRef)
}

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.

Seed structure kindStructural viewMinimum record fields beyond common ASV fieldsFirst boundary
FunctionalStructureFunctionalStructureViewfunctionalBehaviorClaimRefs, requiredOrDesiredEffectClaimRefs?, actualTransformationRefs?, selectedTransformationFlowStructureRefs?, functionalElementClaimRefs?, transformerSideFillerRefs?, candidateBearerRefs?, input-condition refs, output-condition refs, functional-port refs, capability refs, dependency refs, allocation refs, correspondence refsRequired or desired content stays a claim; use A.3.4 only for independently actual transformations, and use capability, work, module-allocation, or requirement patterns when those claims are being made.
TransformationFlowStructureTransformationFlowStructureViewtransformationFlowStructureRef, pathSliceRefs, crossingRefs, valuationRefs, mathematicalDescriptionRefs?Use E.18 and C.30.TFS-REL for selected transformation-flow structure, transformation-flow path, or crossing input; use E.18.2 and C.29 for mathematical graph descriptions; use C.28 for causal claims.
RuntimeInteractionStructureRuntimeInteractionStructureViewruntime elements, connectors and protocols, event topology and message topology, failure boundaries and latency boundariesUse temporal, failure, evidence, or assurance patterns when runtime claims exceed structure.
ModuleInterfaceStructureModuleInterfaceStructureViewmodule claim or admitted relation refs, interface specs, admissibility conditions, substitutability policy or change policyUse A.6.M to repair the module claim and identify the admitted interface or relation separately when those claims are being made.
PlacementDeploymentStructurePlacementDeploymentStructureViewallocation-to-site refs or environment refs, network locality or physical locality, jurisdiction constraints or safety constraintsUse temporal, evidence, law-domain, regulatory, or safety patterns when claims of those non-placement kinds are being made.
InformationDataStructureInformationDataStructureViewstate bearer and residence refs, schema refs, semantic refs, persistence locus, provenance relation, custody relation, source-return conditions, privacy constraintsUse evidence, privacy, or source-return patterns when those claims are being made.
SecurityTrustBoundaryStructureSecurityTrustBoundaryStructureViewprotected asset or effect refs, trust boundary refs, untrusted input refs, privilege or authority refs, data-flow and control-flow refs, attack exposure refs, abuse or misuse path refs, secure-default or hardening boundary, supply-chain or update-channel refs, detection-response boundary refs when the corresponding claim is being madeGives a first security-architecture move before evidence, assurance, gate, risk-score, or compliance proof.
ControlStructureControlStructureViewcontrol-participant refs, declared control-rate refs, observer, estimator, controller, planner, and supervisor relations, feedback refsUse C.30.LCA, dynamics, temporal, causal, evidence, and assurance patterns when those claims are being made.
ConstraintRequirementStructureConstraintRequirementStructureViewrequirement refs, constraint refs, and invariant refs, affected structure refs, admissibility conditionsRequirements shape structures; use the applicable requirement, gate, evidence, causal, or decision pattern for those claims.
MaterialSpatialStructureMaterialSpatialStructureViewgeometry, adjacency, containment, energy flow or material flow, safety separationPhysical separation is not safety proof; use the applicable safety, evidence, dynamics, or causal pattern for those claims.
DeclaredLogicalStructureLogicalStructureViewlocal logical relation class, relation constraints, correspondence to functional structures, module structures, runtime structures, and data structuresCovers logical architecture without making logical a universal ontology token.

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:

Classifier value defined outside C.30.ASVASV useFull semantics and applicable patterns
WorkMethodStructureMethod arrangement or work arrangement changes the architecture move.A.15 keeps MethodDescription, one exact U.WorkPlan, and dated U.Work occurrences separate; use the applicable pattern for any exception-handling, launch, or gate claim. Do not turn a work-method diagram into work authority.
AllocationResponsibilityStructureExact responsibility relations or enactor-allocation relations change the architecture move.Preserve each admitted direct responsibility predicate and occurrence through the view. Keep the System, local system-role kind, separate System-classification judgment, assignment, enactor relation, organization relation, actual Work basis, concern or affected-party relation, authority, ownership, stewardship, and responsibility distinct. Recover owner, steward, and stakeholder from the claim they make and use the corresponding direct ownership, governance, stewardship, concern, affected-party, participation, responsibility, authority, or ordinary-label route. Use E.10.ROLE only when the source wording actually uses unresolved claim-bearing role. Return the exact missing-governor for a required relation rather than treating an org chart, title, assignment, or Work as that relation.
EvidenceAssuranceStructureEvidence reuse or assurance arrangement changes affected structure or source return.Use A.10, G.6, or B.3 for evidence sufficiency or assurance verdict; ASV only names the structure and loss boundary.
ScaleEvolutionStructureScale window, replacement or change policy, trajectory reference, or coarse-graining changes the architecture move.Use C.29, C.16, temporal, source-return, or decision patterns for scale, characterization, or selection claims.
OtherDeclaredStructureKindA local structure kind is declared because none of the seed or externally defined values fits.Name its definition, selected-structure admission test, relation families, applicable patterns, and effective reference scheme when local meaning depends on one; do not mint a root kind by label alone.

Minimum useful seed examples:

Structure kindMinimal exampleFalse interpretationPattern for the first non-ASV claim
FunctionalStructureCapability, required or desired effect claim, or separately actual transformation allocation.Purpose truth, requirement satisfaction, or a required effect treated as actual change.A.6.F, A.3.4 only for actual transformation, capability, work, or requirement pattern when that claim kind is being made.
TransformationFlowStructureTransformation-flow path, crossing, valuation, or selected transformation slice.Whole architecture or causal proof.E.18, C.30.TFS-REL, E.18.2, C.29, or C.28 when selected structure, graph description, transformation-flow path, crossing, mathematical-lens, or causal-use claim kind is being made.
ControlStructureController, observer, plant, feedback, or rate relation.Stability, safety, or assurance proof.C.30.LCA, temporal, dynamics, causal, evidence, or assurance pattern when that claim kind is being made.
ModuleInterfaceStructureModule relation, interface spec, or substitutability boundary.Module tree as all architecture.A.6.M module-relation repair, conformance evidence, or decision pattern when that claim kind is being made.
InformationDataStructureState bearer, residence, provenance, and custody.Database label.Evidence, privacy, or source-return pattern when that claim or reliance use is being made.
SecurityTrustBoundaryStructureTrust boundary, untrusted input, privilege path, or attack exposure.Security proof, risk score, or compliance label.Evidence, assurance, gate, C.24 agentic tool-use relation or call-planning relation, C.16, C.25, or C.30.LCA when that security, evidence, assurance, gate, tool-use, measurement, quality, or control claim kind is being made.
MaterialSpatialStructureSeparation, adjacency, containment, or energy path or material path.Safety proof or geometry as architecture truth.Safety, evidence, dynamics, or causal pattern when that claim kind is being made.
DeclaredLogicalStructureLocal logical relation class with correspondence to other structures.Universal logical architecture ontology.Use the applicable correspondence, function, module, runtime, or data pattern for the relation or claim.
Minimal SecurityTrustBoundaryStructureView fields:
SecurityTrustBoundaryStructureView ::= {
  architectureStructuralViewRef:
  protectedAssetOrEffectRefs:
  trustBoundaryRefs:
  untrustedInputRefs:
  privilegeOrAuthorityRefs:
  dataFlowOrControlFlowRefs:
  attackExposureRefs:
  abuseOrMisusePathRefs:
  secureDefaultOrHardeningBoundary:
  updateOrSupplyChainChannelRefs:
  detectionResponseBoundaryRefs?:
  claimPatternRefs:
    A.10 | G.6 | B.3 | C.28 | A.20 | A.21 |
    C.16 | C.25 | C.24 agentic tool-use relation or call-planning relation when tool authority is being claimed | C.30.LCA when a control relation is being claimed
  admissibleUse:
  otherClaimBoundary:
    compliance, risk-score, assurance, checklist-security, and zero-trust claims use the applicable evidence, assurance, risk, gate, or security pattern
}

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:

SafetyLossControlStructureNote:
  lossOrHarm:
  hazardOrUnsafeState:
  unsafeControlActionOrMissingControl:
  controlledProcessOrPlantRef:
  controlConstraintRef:
  feedbackOrObservabilityBoundary:
  timingOrRateBoundary:
  operationalDesignScopeOrMisuseScope:
  foreseeableMisuseRefs?:
  architectureStructureKindRefs:
    ControlStructure | ConstraintRequirementStructure |
    SecurityTrustBoundaryStructure | InformationDataStructure |
    EvidenceAssuranceStructure
  claimPatternRefs:
    A.3.3 dynamics, C.27 temporal or rate,
    C.28 causal-use, A.10 or G.6 evidence,
    B.3 assurance, A.20 or A.21 gate
  nonAdmissibleUse:
    not safety proof, not safety-case verdict, not regulatory acceptance

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.Transformation only 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 TransformationFlowStructure under 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.System or 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.

FunctionalStructureViewUse ::= {
  architectureStructuralViewRef: U.EpistemeRef constrained to ArchitectureStructuralView,
  functionalElementClaimRefs?: FinSet(U.EpistemeRef),
  sourceFunctionWordingRefs?,
  functionalBehaviorClaimRefs?: FinSet(U.EpistemeRef),
  requiredOrDesiredEffectClaimRefs?: FinSet(U.EpistemeRef),
  actualTransformationRefs?: FinSet(U.TransformationRef),
  selectedTransformationFlowStructureRefs?: FinSet(U.StructureRef constrained to TransformationFlowStructure),
  transformerSideFillerRefs?: FinSet(U.SystemRef),
  candidateBearerRefs?: candidate system refs; explicit gap refs,
  capabilityRefs?,
  inputConditionRefs?,
  outputConditionRefs?,
  functionalPortRefs?,
  functionalDependencyRefs?,
  allocationRefs?,
  correspondenceClaimOrRelationRefs?,
  nonFunctionClaimNotes?,
  flowRelationRefs?,
  moduleInterfaceClaimOrRelationRefs?,
  admissibleUse,
  nonAdmissibleUse
}

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.

Composability:
  "A and B can be assembled under interface X."
  recoveredRelationOrRecordKind: ModuleAllocationRelation | InterfaceSpecification
Quality compositionality:
  "The assembled whole preserves safety, latency, or reliability."
  recoveredRelationOrRecordKind: QBundleSlot | structuralCharacteristicQBundleInputSlot | structuralCharacteristicCausalHypothesisForQBundleSlot | structuralCharacteristicEvidenceRelationForQBundleSlot(A.10 evidence relation only when evidence provenance is the claim being made)
Non-admissible:
  successful assembly is not quality propagation

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:

Source wordingRecover
"This function is implemented by that module."FunctionToModuleAllocationRef or the allocation or relation record named by value.
"This flow crosses that runtime boundary."FlowToRuntimeInteractionCorrespondence.
"This evidence covers the replacement."EvidenceReuseToAffectedStructure; assign sufficiency or verdict to A.10, G.6, or B.3.
"This requirement constrains that structure."RequirementToStructureConstraint or a constraint record named by value.
"This scale window changes the structure kind."ScaleWindowToStructureKindCorrespondence; assign scale-lens claims to C.29 when those claims are being made.

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:

SourceReturnAction:
  returnTo:
    sourceStructure | sourceEpisteme | sourceView | sourceTrace |
    sourceCorpus | sourceModel | sourceEvidence | sourcePublication
  because:
    hiddenRelation | lostConstraint | coarsenedScale |
    ambiguousExtraction | staleEdition | crossViewMismatch |
    lawDomainOrRegulatoryUse | assuranceOrDecisionUse
  nextSourceReturnAction:
    inspect | split | downgradeUse | addCorrespondence |
    openNeighborPattern | stop

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:

Runtime degradation slice:
  selected structure kinds:
    RuntimeInteractionStructure
    ControlStructure
    InformationDataStructure
    PlacementDeploymentStructure
    EvidenceAssuranceStructure
  first architecture move:
    recover runtime interaction topology, control relation or failover relation,
    state custody, placement relation, locality relation, evidence relation, and observability relation
  nonAdmissibleUse:
    deployment diagram as runtime proof,
    observability dashboard as evidence sufficiency,
    green indicator value as gate authority or release authority

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:

CPS and plant architecture first recovery:
  MaterialSpatialStructure:
    physical separation, adjacency, energy path or material path
  ControlStructure:
    controller, plant, observer, supervisor, control rate
  InformationDataStructure:
    sensor data semantics, provenance, custody, source return
  PlacementDeploymentStructure:
    locality, environment, jurisdiction, safety separation
  EvidenceAssuranceStructure:
    evidence reuse boundary and affected structures
first architecture move:
  relate physical separation, sensor data semantics, control rate,
  placement boundary, and evidence reuse
correspondenceOrLossLine:
  record which separation, data, control-rate, placement, or evidence-reuse
  relation is preserved by the slice and which structure is hidden or lossy
stop condition:
  no P&ID, LCA diagram, or safety case is treated as the architecture

Chiplet or device architecture. A packaging diagram or interconnect sketch may involve several structure kinds:

Chiplet and device architecture first recovery:
  MaterialSpatialStructure:
    packaging, adjacency, thermal path, energy path
  TransformationFlowStructure:
    interconnect topology, data flow path, energy flow path, or signal flow path
  ModuleInterfaceStructure:
    interface specification, protocol, conformance boundary
  PlacementDeploymentStructure:
    physical locality, substrate, host environment
first architecture move:
  separate interconnect topology, packaging path, thermal path, or energy path,
  interface specification, and evidence boundary and conformance boundary
correspondenceOrLossLine:
  record the preserved relation among interconnect, physical package,
  interface, and placement, plus any benchmark or packaging-view loss
stop condition:
  no packaging diagram or benchmark becomes performance, safety,
  evidence, or gate proof by appearance

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:

Organization and operating-model architecture first recovery:
  AllocationResponsibilityStructure:
    direct responsibility relation occurrences and enactor-allocation boundary;
    if the responsibility predicate is unavailable, exact missing-governor
  WorkMethodStructure:
    repeatable work method and exception-handling relation
  InformationDataStructure:
    information custody, state residence, provenance
  EvidenceAssuranceStructure:
    evidence reuse, approval, audit trail, source return
first architecture move:
  relate the exact responsibility and enactor-allocation relations, work repeatability,
  information custody, and evidence reuse
correspondenceOrLossLine:
  preserve the direct responsibility relation and its actual participants;
  record separately any local system-role kind and any System-classification judgment,
  assignment, enactor relation, complete actual-Work basis, concern or affected-party relation,
  information, and evidence structures,
  plus any org-chart or work-method-diagram loss
stop condition:
  no org chart or work-method diagram is treated as the architecture, decision,
  evidence sufficiency, or assurance verdict

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:

Evidence reuse across product variants:
  structureKindRef: EvidenceAssuranceStructure
  structuralFeature:
    evidence package shared across module variants
  affectedQBundleSlot:
    assurance maintainability or release readiness
  architectureMove:
    name affected structures, variant boundary, hidden view losses,
    and source-return condition
  claimPatternRefs:
    A.10, G.6, or B.3 for evidence sufficiency or assurance verdict
  nonAdmissibleUse:
    evidence-structure view as 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:

Organization service architecture first recovery:
  describedHolonRef: service organization or service-delivery system
  candidateStructureKindRefs:
    WorkMethodStructure:
      method arrangement, work-plan boundaries, exception handling, and performed-work records
    AllocationResponsibilityStructure:
      admitted direct responsibility relations and their participant split, enactor-allocation relations,
      escalation relations, and separately any local system-role kind,
      System-classification judgment, and obtaining assignment;
      use missing-governor when the source says responsibility but no direct predicate is admitted
    InformationDataStructure:
      ticket state, customer record custody, dashboard source, and source-return condition
    EvidenceAssuranceStructure:
      audit trail, service-level evidence relation, assurance claim, and gate or release record only when those claims are being made
  C30ASVBoundary:
    ASV names selected structure and view boundary; staffing decision, work authority, evidence sufficiency, assurance, and service-quality claims use their applicable patterns

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:

AI-agent architecture first recovery:
  RuntimeInteractionStructure:
    model-tool-memory-planner-evaluator-human topology
  InformationDataStructure:
    memory scopes, data custody, provenance, retention,
    context-window relation and source-return relation
  SecurityTrustBoundaryStructure:
    untrusted content channels, prompt-injection or instruction boundary,
    tool authority, secret-bearing contexts, memory custody crossing and data custody crossing,
    output handling, supply-chain or update channel
  ModuleInterfaceStructure:
    tool specs, API specs, and interface specs and substitutability limits
  EvidenceAssuranceStructure:
    eval harness, human approval, evidence decay, incident feedback
admissibleArchitectureMove:
  split runtime interaction, information, security boundary, module-interface, and evidence-assurance claims before relying on the diagram
correspondenceOrLossLine:
  record the preserved relation among runtime topology, information custody,
  security boundary, module-interface, and evidence-assurance structures,
  plus any diagram or evaluation-harness loss
claimPatternRefs:
  C.30.TFS-REL when an E.18 flow relation is being used,
  A.6.M module-relation repair for tool, API, or interface relation claims,
  A.10, G.6, or B.3 when evidence or assurance reliance is being claimed,
  C.24 agentic tool-use relation or call-planning relation, E.16, A.20, or A.21 when tool-call, autonomy, constraint, or gate authority is being claimed
stop condition:
  ASV contains only the structural-view record; evidence sufficiency, assurance, gate, autonomy, and tool-call authority claims use their applicable patterns

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

Tell-Show-Show rowGrounding
TellA practitioner looks at an architecture "view" and asks whether it is functional, flow, control, module-interface, information or data, placement, scale, work, evidence, or declared logical structure. C.30.ASV turns that question into structure-kind triage or a full description-plus-conformance record.
Show: U.SystemA plant, vehicle, software system, product platform, AI-agent system, or neural-network model can require several structural descriptions over the same exact subject-side architecture. One module view does not exhaust the system architecture, and one flow graph does not prove work, evidence, safety, or release.
Show: U.EpistemeA diagram, model, generated relation graph, ADR, dashboard, SysML view, or C4 diagram may express or publish a description episteme. That same episteme is an architecture structural view only when exact C.2.1 identity, selected structure, structure kind, exact viewpoint, obtaining E.17.0 conformance relation, hidden and lost structure, correspondence, source or reliance relation, and admissible use are recoverable.

Bias-Annotation

Lenses tested: Arch, Onto, Epist, Prag, Did, Gov. Scope: architecture structural-view claims over holons.

Bias riskMitigation
Module-view biasMake module-interface one structure kind, not the default meaning of architecture.
Viewpoint-kind conflationKeep selected structure kind, exact viewpoint episteme P, catalogue L, local family declaration, exact U.ViewpointRef, candidate description E, and conformance relation separate.
TEVB mutation biasReuse only exact references from a materialized project-local TEVB declaration when their resolved P rules fit; do not treat E.17.2's template or a VF.TEVB.ENG spelling as a current family value.
Check-only biasEvery failed conformance check gives a repair action or use of an applicable pattern.
Didactic-thinning riskThe pattern starts with triage and action, not taxonomy alone.

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

IDRequirementFailed-check repair
CC-ASV-1 Structure target.Every architecture structural view has one exact selected U.Structure as its C.2.1 EntityOfConcern.Name and constitute the selected structure under A.22, or keep the inspected episteme or publication as an architecture question input that does not yet claim to be a structural view.
CC-ASV-2 Structure kind.Every architecture structural view names structureKindRef.Use ArchitectureStructureKindTriage@Project; if no structure kind changes action, keep the text as ordinary prose or a source note.
CC-ASV-3 Exact episteme and subject trace.The view preserves one exact claim graph, one selected-structure EntityOfConcern, effective U.ReferenceScheme, and the subject trace to the exact holon and any obtaining ArchitectureRelation; optional architecture claim, ClaimScope, empirical grounding, and model-use structure remain separate.Restore the exact episteme identity and subject trace, or identify a new description before relying on it; do not derive identity from an architecture-claim field or context bundle.
CC-ASV-4 Viewpoint conformance.The candidate episteme and exact viewpoint episteme satisfy the fixed five-part E.17.0 predicate, and viewpointConformanceRelationRef names the participant-determined obtaining occurrence. A bundle or viewpoint label is only discovery support.Apply E.17.0. If the predicate does not obtain, keep a structural description or triage result and do not call it U.View.
CC-ASV-5 Lost structure.The view names hidden or lost structure, especially for query, extraction, coarsening, or publication uses.Add a one-line hidden-structure note or lost-structure note, or narrow the admissible use so omitted structure is not relied on.
CC-ASV-6 Correspondence.Cross-view claims are carried by exact correspondence claims or independently established obtaining relations, not by prose, shared packaging, or graph adjacency alone.Add a correspondence claim or direct relation, or stop at a single-view statement without a cross-view consistency claim.
CC-ASV-7 No representation or publication collapse.A diagram, model, table, dashboard, generated relation graph, ADR, publication occurrence, form, or carrier is kept separate from the view episteme and selected structure.Name the exact description episteme, any C.29 representation, and the E.24.PUB occurrence, form, and carrier separately; claim U.View only when E.17.0 conformance obtains.
CC-ASV-8 No single-view architecture.If a decision uses an architecture view, it names the affected structures and views, not only one favored diagram.Add affected structure and view refs, or narrow the decision to the single view's admissible use.
CC-ASV-9 No proof overread.The view does not stand in for empirical grounding, evidence, safety proof, causal proof, gate decision, or work record; each such claim needs its own obtaining relation and applicable pattern.Use EpistemeEmpiricalGroundingRelation, A.10, G.6, B.3, A.20, A.21, or C.28 for the applicable claim, or mark it unsupported; do not add more ASV fields as a substitute.
CC-ASV-10 Relation or correspondence record named by value.Every cross-reference names the exact kind, claim, relation, or record: selected structure, structure kind, viewpoint, conformance occurrence, correspondence claim or relation, allocation record, bridge record, evidence relation, publication relation when publication is current, interface specification, or applicable record kind named by value.Replace the ambiguous reference with the object that actually carries the claim, or split the sentence into separate objects.
CC-ASV-11 Source return.When compression, extraction, coarsening, evidence reuse, publication, or many-to-many allocation hides distinctions, SourceReturnCondition is present.Add one source-return trigger, or narrow the view's admissible use so omitted distinctions are not used for action, assurance, causal use, law-domain review, regulatory review, or reopening.
CC-ASV-12 Architecture-name recovery.Every <X>Architecture phrase recovers exact selected structure, <X>StructureKind, or a declared local relation or claim.Rewrite the phrase through ArchitectureStructureKindTriage@Project; if no relation is being claimed, keep the name as Plain prose and do not let it carry ontology.
CC-ASV-13 Useful action.The repair leaves a surviving admissible architecture move: inspect, split, relate, downgrade, generate candidates, state a structural description or view, add correspondence, add source return, use the applicable pattern, or stop.Restore one move, or classify the phrase as reduced-use cue, quote-only wording, blocked transfer, or incomplete rewrite.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
Module diagram as architecture viewOne module-interface diagram is treated as the whole architecture or as a U.View by appearance.Use structure-kind triage; keep module-interface as one structure kind and apply exact E.17.0 conformance only when view membership matters.
Viewpoint as structure kindVP.Functional, VP.ModuleInterface, or another viewpoint is used as if it were the selected structure kind.Recover ArchitectureStructureKindRef; keep its binding to an exact viewpoint episteme separate.
Structure kind as viewpointFunctionalStructure or ControlStructure is treated as if it were already an admitted viewpoint P.Keep structure-kind classification separate; when viewpoint reuse is needed, resolve one exact U.ViewpointRef from a materialized local catalogue declaration to exact P and test E.17.0 conformance.
Publication-face collapseA diagram, model, table, dashboard, generated relation graph, ADR, or C4 view is treated as the view episteme.Recover description episteme, representation, and E.24.PUB occurrence, form, and carrier separately; use ArchitectureStructuralView only if exact conformance obtains and the view changes action.
Single-view decisionA decision uses one architecture view as if it covered all affected structures.Name affected structures and view refs, or narrow the decision to the single view's admissible use.
Lost-structure silenceExtracted, generated, coarsened, or compressed views hide distinctions but still justify action.Add hidden structure and lost structure and source-return condition, or narrow admissible use.
Proof overreadThe structural view is used as evidence sufficiency, safety proof, causal proof, gate decision, or work record.Use the applicable evidence, assurance, causal, gate, or work pattern and keep ASV only to view adequacy.
Risk color as security architectureA red, yellow, or green risk cell, risk matrix, maturity score, or compliance color stands in for SecurityTrustBoundaryStructure or resource-allocation priority.Recover protected asset or effect, trust boundary, untrusted input, privilege or authority relation, data flow or control flow, abuse or misuse path, and the evidence named by value, assurance, measurement, causal, gate, selection, or allocation claim kind if that claim is being made; do not treat ordinal risk color as security architecture adequacy, resource-allocation priority, or gate passage.
Taxonomy without actionThe text classifies a view but does not say what changes in practice.Add admissibleArchitectureMove or stop at Plain recognition wording.

Consequences

BenefitCost or trade-off
Architecture views become exact description epistemes over selected structures, not diagrams by appearance.A conforming use states C.2.1 identity, selected structure, structure kind, exact viewpoint, obtaining conformance relation, and admissible use.
Project-local TEVB reference reuse does not enlarge either template.Architecture-specific structure-kind bindings add one explicit record when their coverage matters; every reused viewpoint reference retains its exact materialized catalogue and member provenance and grants no view membership.
Functional, flow, control, module-interface, placement, information, runtime, work, evidence, scale, material, and logical structures can be separated.Some familiar names require triage before they can carry FPF claim kinds.
Failed checks produce repair actions rather than only classification objections.The checklist is longer than a pure taxonomy, but it is more useful for action.

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.

Practice or source lineC.30.ASV adoptionAction consequenceBoundary
FPF C.2.1, A.22, E.17.0, C.30, and C.30.ADUse exact episteme identity, selected-structure discipline, direct viewpoint conformance, architecture relation, and architecture-description boundaries together.ASV records require one primary selected structure as EntityOfConcern, effective scheme, structure kind, exact viewpoint, obtaining conformance relation, correspondence when used, and admissible use.A view remains the same episteme about selected structure; no context field, authoring route, or suffix creates it.
Dyad v3 physical-system modeling and analysisAdopt its current integration of physical models, control analysis, SciML surrogates, calibration, and deployment from one source, with both textual and schematic editing.A generated or edited description still states viewConstruction, selected structure, hidden and lost structure, and a source-return condition when action relies on the description.Executability, simulation, generation, or tool presentation does not create the source episteme, viewpoint-conformance relation, selected structure, evidence sufficiency, gate passage, or assurance.
UAF, ArchiMate, C4, and multi-view architecture practiceAdapt viewpoint-library and lightweight diagram communication pressure. C4 contributes communication and zoom pressure only.C4-like, UAF-like, and ArchiMate-like diagrams can represent or publish ASV epistemes only when exact description identity, EntityOfConcern, structure refs, structure kind, viewpoint conformance, and publication relations are explicit.Do not import their layer, viewpoint, enterprise taxonomies, structure-kind adequacy, evidence sufficiency, or architecture decision claim without recoverable FPF objects and relations.
Systems security engineering, secure-by-design, SSDF, and CSF-style practiceAdopt security as architecture-side structure when trust boundaries, authority, untrusted input, secure defaults, hardening, update channels, and detection and response boundaries change action.Use SecurityTrustBoundaryStructure before evidence, assurance, gate, risk score, or compliance proof.A security framework, checklist, risk color, or control catalog is not security architecture adequacy, evidence sufficiency, assurance, or gate passage by itself.
Theory of Code Space, arXiv:2603.00601 and related code-agent architecture relation-graph probingAdopt partial-observability, typed relation discovery, invariant discovery, uncertainty reporting, and externalized architecture relation graphs as ASV practice source.Treat an externalized code-agent relation graph as a diagnostic description, representation, or ASV publication only with observed, inferred, or unknown observation value, evidence pointers, unexplored regions, typed relation semantics, and source-return conditions.Do not mint U.CodeSpace; do not treat probe JSON, cognitive-model publication, dependency-F1 result, or diagnostic relation graph as architecture adequacy, internal belief proof, agent authority, safe-code-change authority, assurance, or release authority.
GonzoML neural-network architecture discussionsAdopt practitioner operation language for architecture views: block substitution, relation retargeting, dataflow changes, memory placement or cache placement, path-selection or gating, MoE expert-selection, pruning, distillation, NAS, ablation, and compute, memory, or latency tradeoffs.Use those phrases as recognition cues for changed structure kind, flow relation, module-interface claim kind, security or trust boundary, data-custody relation, preserved and lost structure, affected characteristic, source relation, and the applicable decision or evidence pattern.Neural-network labels, benchmarks, ablations, pruning masks, block, layer, router, cache, or state labels, or search outputs do not become FPF ontology, architecture decisions, evidence sufficiency, gate passage, assurance, or architecture adequacy by themselves.

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.30 Status: 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:

ControlStructureViewNote ordinary minimum:
  controlledHolonRef:
  selectedControlStructureRef?:
  structureGap?:
  selectedControlRelationRef:
  controlRelationParticipantRefs:
  feedbackClosureState: closed | oneWay | unclear
  nextPatternUseRef?:
  stopCondition:

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.5 supervisor-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.5 already 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 TransformationFlowStructure values 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:

ControlStructureViewNote:
  architectureRelationOccurrenceRef?: ArchitectureRelationRef
  architectureClaimRef?: U.EpistemeRef constrained to ArchitectureClaim
  describedHolonRef?: U.HolonRef
  selectedControlStructureRef?:
  structureGap?:
  controlledHolonRef:
  selectedControlRelationRef:
  controlRelationParticipantRefs:
  feedbackClosureState: closed | oneWay | unclear
  controlLayerRelationRef?:
  rateBandRef?:
  observationBoundaryRef?:
  actuationBoundaryRef?:
  feedbackBoundaryRef?:
  externalityBoundaryRef?:
  stratificationRepairRef?:
  nextPatternUseRef?:
  admissibleUse:
  nonAdmissibleUse:
  stopCondition:

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.

InterLayerControlRelationNote:
  upperLayerAssumptionRefs:
  lowerLayerGuaranteeRefs:
  observationConditionRefs:
  actuationAuthorityRefs:
  latencyBoundRefs?:
  rateEnvelopeRefs?:
  violationFallbackRefs:
  admissibleUse:
  nonAdmissibleUse:

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.

ControlStructureView ::= ArchitectureDescription & U.View & {
  viewEpistemeRef: U.EpistemeRef,
  claimGraph: exactly one C.2.1 ClaimGraph,
  entityOfConcernRef: selectedControlStructureRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,
  selectedControlStructureRef: U.StructureRef,
  structureKindRef = ControlStructure,

  viewpointRef: U.ViewpointRef,
  viewpointConformanceRelationRef: EpistemeViewpointConformanceRelationRef,
  concernRefs?: FinSet(U.EntityRef),

  describedHolonRef?: U.HolonRef,
  architectureRelationOccurrenceRefs?: FinSet(ArchitectureRelationRef),
  architectureClaimRefs?: FinSet(U.EpistemeRef constrained to ArchitectureClaim),
  claimScope?: U.ClaimScope, byValue,
  modelUseStructureRef?: U.StructureRef,
  empiricalGroundingRelationRefs?: FinSet(EpistemeEmpiricalGroundingRelationRef),
  controlledHolonRef: U.HolonRef,

  selectedControlRelationRefs: FinSet(U.RelationRef),
  controlRelationParticipantRefs: FinSet(U.EntityRef),
  observationRelationRefs?: FinSet(U.RelationRef),
  actuationRelationRefs?: FinSet(U.RelationRef),
  referenceProvisionRelationRefs?: FinSet(U.RelationRef),
  feedbackRelationRefs?: FinSet(U.RelationRef),
  controlLayerRelationRefs?: FinSet(U.RelationRef),
  rateBandRefs?: FinSet(RateBandRef),
  interLayerControlRelationRefs?: FinSet(U.RelationRef),
  supervisorSubholonRelationRefs?: FinSet(U.RelationRef),

  participatingSystemRefs?: FinSet(U.EntityRef constrained to U.System),
  localSystemRoleKindRefs?: FinSet(U.KindRef),
  systemRoleClassificationJudgmentRefs?: FinSet(U.RelationRef),
  assignmentRows?: FinSet({
    assignmentSpeciesRef: U.RelationKindRef constrained under U.SystemRoleAssignment,
    assignmentOccurrenceRef: U.RelationRef constrained to an obtaining occurrence of assignmentSpeciesRef
  }),
  actualControlWorkRefs?: FinSet(U.EntityRef constrained to U.Work),
  actualControlWorkAttributionRefs?: FinSet(U.RelationRef constrained to obtaining performedUnderAssignment relations),

  observationBoundaryRefs?: FinSet(BoundaryRef),
  actuationBoundaryRefs?: FinSet(BoundaryRef),
  feedbackBoundaryRefs?: FinSet(BoundaryRef),
  externalityBoundaryRefs?: FinSet(BoundaryRef),
  transformationFlowPathSliceRefs?: FinSet(PathSliceId),

  stratificationRepairRefs?: FinSet(C30STRATRepairRef),
  sourceToUsePathRefs?: FinSet(U.RelationRef),
  downstreamPatternUseRefs?,
  representationRefs?: FinSet(U.EntityRef),
  publicationOccurrenceRefs?: FinSet(EpistemePublicationRelationRef),
  publicationFormRefs?: FinSet(U.EntityRef),
  carrierRefs?: FinSet(U.EntityRef constrained to U.PresentationCarrier),
  admissibleUse,
  nonAdmissibleUse,
  sourceReturnCondition?
}

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:

SafetyLossControlStructureNote:
  lossOrHarm:
  hazardOrUnsafeState:
  unsafeControlActionOrMissingControl:
  controlledProcessOrPlantRef:
  controlConstraintRef:
  feedbackOrObservabilityBoundary:
  timingOrRateBoundary:
  operationalDesignScopeOrMisuseScope:
  foreseeableMisuseRefs?:
  architectureStructureKindRefs:
    ControlStructure | ConstraintRequirementStructure |
    SecurityTrustBoundaryStructure | InformationDataStructure |
    EvidenceAssuranceStructure
  claimPatternUseRefs:
    A.3.3 dynamics, C.27.TA temporal aspect or rate, and C.27 authored temporal-claim adequacy,
    C.28 causal-use, A.10 or G.6 evidence,
    B.3 assurance, A.20 or A.21 gate
  nonAdmissibleUse:
    not safety proof, not safety-case verdict, not regulatory acceptance

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.

Source labelFPF recovery
Plant or controlled holonU.Holon whose state evolves; reusable state-evolution claims use [A.3.3](/generated/patterns/A.3.3).
Regulator or controllerRecover the regulation or control relation and its participant meaning. If control Work is claimed, recover the exact performer System through A.13 and admit the Work independently through A.15.1 with its enacted Method. Add an assignment occurrence and F.6 only when the control account expressly consumes precise assignment-bound attribution. Add local classification only when relied on; assignment supplies none.
PlannerRecover the exact reference-provision, planning, or other direct relation. A planning System and planning Work are separate; for a plan, authority, or allowed-region result, use its own pattern.
Observer or estimatorRecover the observation or estimation relation and participant meaning. If observation or estimation Work occurred, 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 when precise assignment-bound attribution is expressly consumed; a reading or evidence result remains separate.
SupervisorRecover the exact supervision or [B.2.5](/generated/patterns/B.2.5) supervisor-subholon relation. Use separate patterns for any constraining Work, policy change, authority, responsibility, gate, or control-mode change.

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

ArchetypeWithout C.30.LCAWith C.30.LCA
SystemA plant, controller, or supervisor diagram is treated as if the drawing itself established the controlled system's behavior.The controlled system, controller, observer, planner, supervisor, boundaries, rate bands, actual control relations, and selected control structure remain separately recoverable.
EpistemeA control-description publication is read as structure, U.View, or proof because it uses familiar control labels.The exact description episteme has one selected-structure EntityOfConcern; it is a view only through exact E.17.0 conformance. Representation, publication, and proof-like claims stay separate.

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, or stack label can hide whether it names a control relation, rate band, aggregation, scale, organization, Work scope, evidence scope, deployment, or publication section. Repair with C.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

IDCheckWhy it matters
CC-LCA-1A conforming full description or view has one C.2.1 identity whose EntityOfConcern is one exact selected control structure; the described and controlled holons and any actual ArchitectureRelation remain separately recoverable.Prevents a free-floating diagram, claim, or unspecified relation set from becoming structure or episteme identity.
CC-LCA-2A conforming use records the direct control relations and participant meanings present: for example, reference provision, regulation or control, observation or estimation, plant or controlled-holon participation, or supervision. Systems, classifications, assignments, Methods, Work, and F.6 attribution are separate optional facts.Keeps the view useful without making a label, kind, assignment, or description act.
CC-LCA-3Layer, level, tier, or stack wording enters only with a recovered direct control relation, inter-layer relation, rate band, or B.2.5 supervisor-subholon relation. An assignment alone is insufficient.Prevents generic stratification wording from standing in for control structure.
CC-LCA-4A claimed U.View names the exact viewpoint episteme and independently obtaining EpistemeViewpointConformanceRelation; bundle membership, viewpoint label, authoring, query, diagram, and publication are insufficient.Keeps structural description and view membership distinct.
CC-LCA-5Use the relevant patterns to state or test stability, safety, dynamics, temporal-aspect or rate-band structure, authored temporal-claim adequacy, causal use, empirical grounding, evidence, gate, and assurance claims.Prevents LCA-as-proof.
CC-LCA-6Use B.2.5 only to state or test the supervisor-subholon feedback relation it defines.Keeps a cited feedback relation distinct from stability, safety, evidence, gate, and assurance claims.
CC-LCA-7Use E.18 to identify and test any transformation-flow path slice used by the control view. The slice is not the control structure or actual transformation itself.Keeps transformation-flow and LCA relations distinct.
CC-LCA-8C.29 or mathematical-lens use is opened when LCA is transferred across domains or used for prediction, reusable explanation, or assurance input.Preserves mathematical-lens use and representation boundaries.
CC-LCA-9The record states admissible use, non-admissible use, and source-return condition; representation, E.24.PUB publication occurrence, publication form, and carrier remain separate.Prevents narrowed recognition or publication from becoming unchecked reliance.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
LCA-as-proofThe text says the control stack proves safety, stability, or gate readiness.Keep the control view and use the relevant dynamics, evidence, assurance, gate, or safety pattern for each proof or claim named by value.
Control-layer-as-generic-levelLayer, level, tier, or stack is used without a direct control relation, inter-layer relation, rate band, or B.2.5 supervisor-subholon relation.Apply C.30.STRAT; use C.30.LCA only after a control-specific relation is recovered.
Agentive episteme, kind, or assignmentA policy, model, dashboard, local system-role kind, assignment, or architecture note is said to watch, decide, plan, or adapt.Recover the direct control relation and participant meanings. For actual action, recover the exact performer through A.13 and admit the U.Work occurrence independently through A.15.1. Add assignment and F.6 only when precise assignment-bound attribution is expressly consumed; keep publication, source-to-use, work-reliance, authority, responsibility, gate, safety, and evidence relations separate.
Transformation-flow and LCA substitutionA transformation-flow graph expression is treated as control architecture, or an LCA diagram is treated as the transformation-flow graph expression.Recover both exact selected structures and description epistemes separately; use E.17.0 only for actual viewpoint conformance.
Hidden rate claimMulti-rate control is named, but rate adequacy is not checked.Add rateSeparationClaimRefs?; use C.27.TA for temporal-aspect or rate-band claims and C.27 for authored temporal-claim adequacy.

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

SoTA and practice sourceWhat it contributesFPF adoption stancePractitioner implication
Anderson, Doyle, Low, and Matni, "System Level Synthesis" (Annual Reviews in Control, 2019).Structured controller-synthesis practice treats closed-loop responses, constraints, locality, and distributed implementation as explicit synthesis variables and implementation relations rather than as a box-and-arrow guarantee.Adopt and adapt: use SLS as current control-structure pressure for explicit control-participant meanings, direct relations, locality, rate, and implementation boundaries; do not import SLS proof claims into C.30.LCA.A distributed-control diagram can start a control-structure description; for stability or robust-performance claims, use the relevant dynamics or control-proof pattern.
Ames, Coogan, Egerstedt, Notomista, Sreenath, and Tabuada, "Control Barrier Functions: Theory and Applications" (ECC, 2019).Safety-critical control separates a controller structure from a safety property and the mathematical certificate or enforcement method used for that property.Adopt and adapt: keep safety wording visible as a neighboring safety or proof claim, not as control-view adequacy.When a sentence says the supervisor or controller makes the plant safe, keep the control description and use the relevant safety, dynamics, evidence, or assurance pattern to state and test that claim.
Rawlings, Mayne, and Diehl, Model Predictive Control: Theory, Computation, and Design, 2nd ed. (2017).Planner and regulator distinctions, receding horizon, constraint, update period, and model-boundary distinctions are current MPC structure cues.Adopt as control vocabulary: recover direct control relations and participant meanings, rates, model boundaries, and constraints; add Systems, classifications, assignments, Methods, and Work only when independently current. Handle temporal or rate claims under C.27.TA, authored temporal adequacy under C.27, and dynamics under A.3.3.A multi-rate or MPC-style note names relation participants, rate bands, and model boundaries before claiming adequacy.
Leveson and Thomas, STPA Handbook (2018), as systems-theoretic safety-control practice.Safety analysis treats unsafe control actions, feedback, process models, constraints, and losses as control-structure-relevant distinctions.Adopt and adapt: allow safety-loss control-structure notes, while keeping safety-case verdicts and evidence sufficiency outside C.30.LCA.A loss-control diagram can organize the description; it does not close the safety case.
FPF C.2.1, A.22, C.30, C.30.AD, E.17.0, and C.30.ASV.These patterns separate selected control structure, architecture relation, architecture claim, description episteme, viewpoint episteme, conformance occurrence, described holon, and controlled holon.Bind ControlStructureView to one selected U.Structure and viewpoint conformance; recover every control relation through the pattern that defines it.A control view can coordinate several relations without becoming the architecture, relation occurrence, or proof.

Relations

  • Builds on C.30 for direct architecture relations and selected-structure adequacy, C.30.AD for description identity and use, E.17.0 for direct viewpoint conformance, and C.30.ASV for structural-view adequacy.
  • Uses A.22 for exact structure identity and structure-kind discipline.
  • Coordinates with C.30.STRAT when 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.5 for 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.3 for dynamics or stability, C.27.TA for temporal-aspect or rate-band structure, C.27 for authored temporal-claim adequacy, C.28 for 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:

"Optimization at the component scope breaks the wider holon."
"We added modularity, but integration exceptions grew."
"Local agent autonomy conflicts with the control or policy scope."
"At one scale window the architecture is stable; at the next, bespoke bridges appear."
"The team optimizes latency, but the evidence or assurance scope becomes unrepairable."
"We may need to add, split, or mediate a declared holon level, declared scope, control layer, interface grammar, work scope, or evidence scope, but it is not clear which architecture move is admissible."

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, and environment labels 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.

CrossScopeArchitectureResidualTriageRecord@Context ::= {
  describedHolonRef,
  architectureConcernCue,
  intendedArchitectureUse,
  claimScopeRef?: U.ClaimScope,
  qualificationWindowRef?,
  boundedModelUseStructureRef?,

  declaredHolonLevelRefs?: FinSet(DeclaredHolonLevelRef),
  declaredScopeRefs: FinSet(AggregationScopeRef | DeclaredSystemLevelRef |
                            ControlLayerRef | WorkEvidenceScopeRef |
                            OrganizationScopeRef | SystemEnvironmentScopeRef |
                            RateBandRef | ScaleWindowRef |
                            PublicationSectionRef | OtherDeclaredScopeRef),
  structureKindRefs: FinSet(ArchitectureStructureKindRef),

  interlevelConflictDescription?,
  conflictCarrierRefs?:
    FinSet(ConstraintRef | ObjectiveRef | AdmissibilityConditionRef |
           TempoRef | ResourceAllocationRef | InformationTransferRelationRef |
           AssuranceRequirementRef | OtherDeclaredConflictCarrierRef),
  localScopeOptimizationClaim?,
  widerScopeOptimizationClaim?,
  conflictingConstraintRefs?,
  conflictingCharacteristicRefs?,
  conflictingQBundleRefs?,

  symptom,
  crossScopeResidualDescription,
  crossScopeResidualLocusKind:
    hiddenCoupling | interfaceException | controlRateConflict |
    scaleWindowLoss | evidenceReuseFailure | regulatoryBespokeResidue |
    workMethodException | dataSemanticDrift |
    placementJurisdictionConflict | securityTrustBoundaryBreak |
    otherDeclared,
  frustrationResidualBefore?,
  complexityGrowthPressure?,
  localRepairAttempted?,
  whyLocalRepairInsufficient?,

  firstAdmissibleArchitectureMove:
    splitDeclaredHolonLevel | mergeDeclaredHolonLevel |
    splitDeclaredScope | mergeDeclaredScope |
    splitDeclaredSystemLevel | mergeDeclaredSystemLevel |
    addMediator | addInterfaceGrammar | addControlLayer |
    addEvidenceScope | addWorkMethodScope | changeAllocation |
    exposeHiddenCoupling | acceptBoundedException |
    applyD3D4 | applyC28 | noArchitectureMove,

  triggeredPatternLocators?,
  admissibleNextMove,
  stopCondition,
  sourceReturnCondition?
}

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:

Claim kind being madeSubject pattern to apply
measurement or characteristic claim[C.16](/generated/patterns/C.16) or the characteristic pattern that defines or constrains the characteristic under evaluation
scale window, RG relation, coarse-graining relation, preserved structure, lost structure, or conflict residual slope[C.31.ASAP](/generated/patterns/C.31.ASAP) when an architecture scale-preference claim is being made; use [C.29](/generated/patterns/C.29) when mathematical-lens use is being claimed
multilevel learning or frustration mathematical-lens use with recoverable level mapping or scale mapping[C.29](/generated/patterns/C.29) with MLU.Description@MultilevelLearningFrustration
candidate generation or residual-reducing candidate architecture moves[C.32.MLAO](/generated/patterns/C.32.MLAO) when the residual-reducing multilevel frame is current; [C.32](/generated/patterns/C.32) for the candidate palette; [G.5](/generated/patterns/G.5) when selected-set result declaration is current; [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 when publication is current; [C.11](/generated/patterns/C.11) when final local choice is current; [C.32.PAD](/generated/patterns/C.32.PAD) when a project architecture decision is current
final local choice[C.11](/generated/patterns/C.11)
causal outcome claim[C.28](/generated/patterns/C.28)
evidence or assurance[A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), or [G.6](/generated/patterns/G.6)
ethical conflict description, mediation, or decision use[D.3](/generated/patterns/D.3) for the interlevel ethical conflict description; [D.4](/generated/patterns/D.4) for mediation and decision use of that description

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.

CueAdmissible architecture moveNon-admissible overread
Component optimization breaks integrationexpose hidden coupling; add interface grammar; change allocationTreat local performance as whole-holon adequacy.
Modularity reduces local work and increases exceptionsaccept bounded exception; revise module boundary; add work scope or evidence scopeAverage exceptions into a modularity score without declared scope, comparator, and measurement relation.
Local autonomy conflicts with control scopeadd control layer; change allocation; apply [C.30.LCA](/generated/patterns/C.30.LCA)Treat autonomy label as causal or safety proof.
Evidence reuse hides source lossadd evidence scope; add source-return condition; apply [A.10](/generated/patterns/A.10) or [G.6](/generated/patterns/G.6)Treat reused evidence as automatically valid in the wider scope.
A scale window changes the residualapply [C.31.ASAP](/generated/patterns/C.31.ASAP), with [C.29](/generated/patterns/C.29) when scale-lens use is being madeTreat two observations as a universal scale law.
A frustration lens with recoverable level mapping or scale mapping makes candidate moves comparableuse [C.29](/generated/patterns/C.29) for lens adequacy; use [C.32.MLAO](/generated/patterns/C.32.MLAO) and [C.32](/generated/patterns/C.32) when a residual-reducing candidate palette is current; use [G.5](/generated/patterns/G.5) only when selected-set result declaration is currentTreat an unassigned or same-scope structure conflict as RG mathematics or frustration mathematics, or treat an interlevel residual without recoverable mapping as a global optimizer, proof, or selected architecture.

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

ArchetypeWithout C.30.ILCWith C.30.ILC
Holon levelsA residual across component, system, episteme, publication-use, control, environment, or product-line scopes is called generic complexity.The affected declared holon levels or declared scopes, the level-bearing structure, the residual, and the first architecture move are named.
Episteme as described holonA diagram, measurement note, or conflict memo has its own structure, but a second description about it is interpreted as if it already selected a repair.The episteme can be the described holon; the description of that episteme remains separate from decision, evidence, measurement, selection, or mediation and is governed by the subject pattern when those claims are being made.

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, or scope sounds precise but no declared holon level or declared scope exists. Repair through declaredHolonLevelRefs or declaredScopeRefs.
  • 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.29 supplies 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.16 or 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.MLAO and C.32; use G.5 only 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

IDCheckWhy it matters
CC-ILC-1A conforming use names describedHolonRef, the architecture concern, intended use, ClaimScope or qualification window when each changes the result, and any independently selected bounded model-use structure actually relied on.Keeps the triage grounded without narrowing architecture to systems or making a generic context field supply locality.
CC-ILC-2A conforming use names declared holon levels or declared scopes, not only level, layer, scope, or scale prose.Prevents pseudo-level and pseudo-scope reasoning.
CC-ILC-3A conforming use names the selected structure or structure kind that carries, separates, or relates the declared levels or scopes affected by the residual.Keeps the residual interlevel rather than merely a same-level, same-scope, or unassigned conflict between structures.
CC-ILC-4A conforming use records conflict carriers, local repair attempted, and why local repair was insufficient when a conflict or local repair is claimed.Prevents premature synthesis and repeated local fixes.
CC-ILC-5A conforming use states one first admissible architecture move or noArchitectureMove.Makes the output action-guiding without candidate generation.
CC-ILC-6Evidence, assurance, measurement, causal, ethical, selection, scale, RG, coarse-graining, mathematical-lens, and residual-reducing candidate-set claim kinds use their subject patterns.Prevents triage from becoming proof, lens adequacy, mediation, synthesis, or selection.
CC-ILC-7If a source-return condition is needed, the record states what hidden or lost distinction triggers return to the source.Protects compressed and extracted views.
CC-ILC-8The stop condition is visible.Prevents the triage pattern from expanding into a hidden prescribed sequence.
CC-ILC-9If multilevel learning or frustration is used as mathematics, the record names C.29, MLU.Description@MultilevelLearningFrustration, the recoverable level mapping or scale mapping, and preserved structure and lost structure; if residual-reducing candidate moves form a candidate set being used, the record names C.32.MLAO and C.32; if the retained-set result is being declared, it names G.5; if that result is made available to an audience, it names E.17 for a source-backed publication face and source return and E.24.PUB for the publication occurrence and audience availability.Preserves the useful multilevel optimization line without importing ontology, proof, or a hidden selector.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
Generic complexity bucketEverything becomes complexity or interlevel conflict.Name declared holon levels or declared scopes, level-bearing structure, residual, and first architecture move.
Structure conflict as interlevel conflictTwo structures are in tension, but no declared holon level, scale window, or coarse-graining relation is recoverable.Use C.30, C.30.ASV, D.3, D.4, C.28, evidence, assurance, or decision patterns as applicable; use C.30.ILC only when the conflict is across declared levels or scopes.
Frustration-as-ontologyFrustration is treated as a new FPF kind, psychological state, physics kind, biology kind, assurance score, or proof.Keep frustration as an entry label; recover FrustrationResidual, conflict carriers, residual-bearing locus, and subject patterns for C.29, evidence, assurance, causal, mediation, or synthesis claims when those claim kinds are being made.
Optimization-as-global-proofA local optimization claim is treated as proof that the whole architecture optimizes one global objective.Record local and wider-scope claims separately; use C.29 only for an admissible mathematical lens with recoverable level mapping or scale mapping and use candidate-generation, comparison, or decision patterns for synthesis and selection.
Measurement-first conflictThe team starts measuring before declaring what is in conflict.Run ILC triage first; apply C.16 or the characteristic pattern governing the characteristic under evaluation only when the measured characteristic is under evaluation.
Risk color as cross-scope decisionA red, yellow, or green risk cell, risk matrix, or maturity score decides the cross-scope architecture move or resource-allocation priority.Recover declared holon levels or declared scopes, structure kind under considerations, the residual, the loss, hazard, or threat relation, selected source, evidence, or relation interpretation, characteristic scale, comparator, gate pattern, and first admissible architecture move; do not treat ordinal risk color as architecture adequacy, evidence sufficiency, causal proof, assurance proof, resource-allocation priority, or gate passage.
Mediation-only conflictA structural residual is treated as ethical mediation with no architecture move.Use D.3 only when an interlevel ethical conflict needs a description and D.4 only when that description is being mediated or used in a decision.
Hidden candidate generationThe residual immediately spawns many designs.State the first admissible move; apply C.32.MLAO and C.32 only when residual-reducing candidate work is being claimed, and apply G.5 only when selected-set result declaration is current.
Scope word without scope recordThe text says level, layer, scale, or scope without a declared field.Recover the declared holon level or declared scope named by value, or demote the phrase to ordinary recognition.

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

SoTA and practice sourceWhat it contributesFPF adoption stancePractitioner implication
Scenario-based architecture trade-off practice, with ATAM-like reasoning used here as lineage and practice source for concern, scenario, sensitivity point, and trade-off recognition rather than as a decision or evidence method.Architecture work often starts from cross-concern and cross-scope trade-offs rather than one local measurement result.Adopt and adapt: use the conflict cue for triage, require declared holon levels or scopes, level-bearing structure, and subject patterns for final selection, evidence, assurance, and gate passage.A residual can start an architecture move without becoming a decision, proof, or safety case.
Vanchurin, Wolf, Katsnelson, and Koonin multilevel learning and frustration line, plus the Akhtyrchenko, Katsnelson, and Ustyuzhanin 2026 MSPD paper as selected source pressure rather than full-literature ranking.Local optimization at one declared holon level, scope, or level-bearing structure relation can create persistent residual in another; frustrated optimization and MSPD-like reasoning can be candidate mathematical lenses when a level mapping or scale mapping is recoverable.Adopt and adapt: C.30.ILC uses this line for architecture triage only. C.29 with MLU.Description@MultilevelLearningFrustration carries mathematical-lens adequacy with preserved structure and lost structure; no U.Frustration, universal architecture metric, physics or biology ontology transfer, global optimizer proof, causal proof, assurance proof, or ethical-mediation takeover.First recover holon levels or scopes, level-bearing structure, conflict carriers, residual-bearing locus, local repair, and the first architecture move. Apply C.29 only when the lens mapping is being claimed; apply C.32.MLAO and C.32 only when residual-reducing candidate work is current; apply G.5 only when selected-set result declaration is current.
Control and cyber-physical systems practice.Local autonomy, feedback, supervisor relations, and rate separation can create cross-scope conflict.Reuse through C.30.LCA, B.2.5, C.27, and A.3.3; do not let ILC carry control proof.A control conflict is governed by control-structure or dynamics patterns only when those claims are being made.
FPF source-return and semantic-coarsening discipline.Compressed views and reusable records can hide distinctions that matter in a wider scope.Adopt: add sourceReturnCondition? when hidden distinctions carry the residual.A bounded exception or source-return trigger may be the correct first move.

Relations

  • Builds on C.30 and C.30.ASV for grounded architecture, selected-structure, and structural-view adequacy.
  • Uses A.22 for structure and structural-view discipline.
  • Coordinates with C.30.TFS-REL, C.30.LCA, A.6.F, and A.6.M when the residual concerns flow, control, function, allocation, module, or interface structure.
  • Applies C.16 or the characteristic pattern that defines or constrains the characteristic under evaluation for measurement or characteristic claims.
  • Applies C.29 with MLU.Description@MultilevelLearningFrustration only when multilevel learning or frustration is used as a mathematical lens with recoverable level mapping or scale mapping and preserved structure and lost structure; applies C.31.ASAP for architecture scale-preference claims and C.29 for mathematical-lens claims when scale, RG, coarse-graining, preserved structure, lost structure, or scale-window adequacy is being claimed.
  • Applies C.32.P2S when residual triage must continue through problem-to-structure architecturing; applies C.32.MLAO for residual-reducing multilevel candidate frames and C.32 for candidate palettes; applies G.5 only when selected-set result declaration is current.
  • Applies C.11 for final local choice, C.28 for causal outcome claims, 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.

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 actual ArchitectureRelation, exact selected architecture structure, exact structural-view or description episteme, or bounded architecture claim to one selected TransformationFlowStructure under E.18 or one selected TransformationFlowStructureNetwork under E.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.

ArchitectureTransformationFlowStructureRelation:
architectureRelationOccurrenceRefs?:
architectureClaimRefs?:
selectedArchitectureStructureRefs?:
architectureStructuralViewRefs?:
architectureDescriptionRefs?:
architectureUseConcernRefs?:
claimScope?: U.ClaimScope, byValue
effectiveReferenceScheme?: U.ReferenceScheme, byValue
modelUseStructureRef?: U.StructureRef
empiricalGroundingRelationRefs?:

functionalStructureViewRefs?:
functionalElementClaimRefs?:
functionalBehaviorClaimRefs?:
requiredOrDesiredEffectClaimRefs?:
actualTransformationRefs?:
transformerSideFillerRefs?:
candidateBearerRefs?:
inputConditionRefs?:
outputConditionRefs?:
functionalPortRefs?:

transformationFlowStructureViewRefs?:
transformationFlowStructureRef?:
transformationFlowStructureNetworkRef?:
networkCrossFlowRelationRowRefs[]?: E.18.NET NetworkCrossFlowRelationRowRef
networkArchitectureUseBranch?: namedContainingHolon | explicitInterHolon
containingHolonRef?:
containingArchitectureRelationRef?:
containingArchitectureClaimRef?:
participatingHolonRefs[]?:
participatingArchitectureRelationRefs[]?:
participatingArchitectureClaimRefs[]?:
noNetworkBearerHolonAsserted?:
transformationFlowUnfoldingStructureRef?:
selectedPathOrSliceRefs?:
crossingBundleRefs?:
flowValuationRefs?:

mathematicalDescriptionRefs?:
mathLensUseRefs?:
correspondenceClaimOrRelationRefs?:
sourcePublicationOrEditionRef?:
representationRefs?:
publicationOccurrenceRefs?:
publicationFormRefs?:
carrierRefs?:
extractionOrProbeLocusRef?:
relationObservationClassRef?:
unexploredRegionRefs?:
hiddenRelationStructureReturnCondition?:
admissibleUse:
stopOrReturnCondition:
nonAdmissibleUse?:

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

ForceTension
Transformation-flow relation vs architecture takeoverOne E.18 TFS, one E.18.NET network, or a selected path or crossing can be essential, but none becomes all architecture ontology or an unnamed characteristic bearer.
Functional view vs transformation-flow viewA functional structure view may need a transformation-flow relation, but a required effect, path, crossing, valuation, or mathematical description is not a functional element or actual transformation by itself.
Structure precision vs work/change overreadE.18 gives selected structure, path, and flow-valuation objects; actual transformation, Work occurrence, and work results remain outside this record unless their own patterns admit those claims.
No-hidden-scalarization vs architecture scoringE.18 set-return and no-hidden-scalarization discipline can inform architecture reasoning, but it does not become a general architecture score.
Small relation vs unneeded non-architecture apparatusA project often needs one use record, not a full C.29 lens card, evidence relation, assurance case, or decision record.
Flow-structure-owner stability vs C.30 integrationAn actual architecture relation, selected structure, structural view, or conditional architecture-description use needs a trace to E.18 for one TFS or E.18.NET for one network without rewriting either owner as generic architecture adequacy theory.

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.

ArchitectureTransformationFlowStructureRelation minimum:
  architectureLocusRef: exactly one actual ArchitectureRelation,
    selected architecture U.Structure, exact description/view episteme,
    or bounded ArchitectureClaim used by this question
  flowLocusRef: exactly one E.18 TFS, E.18.NET network,
    unfolding, member-local path/slice/crossing, or valuation
  requiredOrDesiredEffectClaimRefs?: claim content only
  actualTransformationRefs?: only with complete A.3.4 basis
  networkArchitectureUseBranch?: one complete branch from section 4.4a
  admissibleUse:
  stopOrReturnCondition:
  nonAdmissibleUse?:

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;
  • PathId or PathSliceId;
  • CrossingBundleRef;
  • flow valuation over the U.Transfer relation;
  • 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:

  • functionalBehaviorClaimRefs and requiredOrDesiredEffectClaimRefs remain C.2.1 claim content under their requirement, architecture, capability, method, functional-view, or other direct owner;
  • actualTransformationRefs cite 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;
  • selectedTransformationFlowStructureRefs cite 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.

FunctionTransformationFlowRelationNote:
functionalStructureViewRef:
functionalElementClaimRef?:
functionalBehaviorClaimRefs?:
requiredOrDesiredEffectClaimRefs?:
actualTransformationRefs?:
selectedTransformationFlowStructureRefs?:
transformerSideFillerRef?:
candidateBearerRef?:
inputConditionRefs?:
outputConditionRefs?:
functionalPortRefs?:
transformationFlowStructureViewRef?:
architectureTransformationFlowStructureRelationRef:
pathOrSliceRef?:
crossingBundleRef?:
correspondenceClaimOrRelationRefs?:
preservedStructure:
lostOrHiddenStructure:
sourcePublicationOrEditionRef?:
extractionOrProbeLocusRef?:
relationObservationClassRef?:
unexploredRegionRefs?:
hiddenRelationStructureReturnCondition?:
admissibleUse:
stopOrReturnCondition:
nonAdmissibleUse?:

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

Claim kind being madeGoverning pattern to apply
Work occurrence or work resultA.15.1 for the occurrence; A.15 for Method/Work alignment; the governing work-result or P2W relation for those claims
Gate decisionA.21
Evidence claimA.10 or G.6
Assurance claimB.3
Causal flow or intervention claimC.28
Mathematical-lens useC.29
Architecture description or view adequacyC.30 or C.30.ASV
Function-like wordingA.6.F
Interface, signature, or module compatibilityA.6.M module-and-interface repair plus A.6.5 slot discipline, with A.6.0 only when a signature declaration is being made
Architecture decisionthe project-side architecture decision pattern when the corresponding claim is being made

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.

  1. Named containing-holon use. Set networkArchitectureUseBranch=namedContainingHolon. Name exactly one containingHolonRef and one actual containingArchitectureRelationRef whose selected structure is the same exact network. containingArchitectureClaimRef is optional claim/trace content. Keep all participating arrays and noNetworkBearerHolonAsserted absent. Member TFS values and their Work, valuations, boundaries, actual transformations, and direct relations remain independently governed.
  2. Explicit inter-holon use. Set networkArchitectureUseBranch=explicitInterHolon. Put at least two exact distinct holons in participatingHolonRefs[]. Add exactly the actual participatingArchitectureRelationRefs[] and bounded participatingArchitectureClaimRefs[] 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 set noNetworkBearerHolonAsserted=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:

functionalStructureViewRef: exact view episteme about required effects and dependencies
functionalElementClaimRefs?: not used; no filled functional-element claim is current
functionalBehaviorClaimRefs?: required-effect claim `authorize payment`
requiredOrDesiredEffectClaimRefs?: required-effect claim `authorize payment`
actualTransformationRefs?: not used; no A.3.4 actual change is claimed
selectedTransformationFlowStructureRefs: exact selected payment-authorization TFS
transformerSideFillerRefs?: not used
candidateBearerRefs?: not used
inputConditionRefs?: not used
outputConditionRefs?: not used
functionalPortRefs?: not used
transformationFlowStructureViewRef: exact description/view episteme about the selected E.18 structure, path, crossing, or flow valuation
transformationFlowStructureRef: TransformationFlowStructure@PaymentAuthorization
selectedPathOrSliceRefs: path slices used for the architecture claim
correspondenceClaimOrRelationRefs: bounded claim that the required effect corresponds to the flow path
stopOrReturnCondition: stop at the bounded correspondence claim; open actual transformation, Work, evidence, gate, or decision use only through its direct predicate
nonAdmissibleUse?: flow diagram as functional architecture itself

Filled use record:

ArchitectureTransformationFlowStructureRelation:
architectureRelationOccurrenceRefs: exact obtaining CheckoutService architecture relation
architectureClaimRefs: bounded CheckoutService architecture claim when current
selectedArchitectureStructureRefs: exact selected request-handling and payment-authorization structure
architectureStructuralViewRefs: exact CheckoutRuntimeFlow view episteme
architectureDescriptionRefs: not used; durable description adequacy is not being evaluated here
functionalStructureViewRefs: exact CheckoutRequiredEffects view episteme
functionalElementClaimRefs: not used
functionalBehaviorClaimRefs: required-effect claim `authorize payment`
requiredOrDesiredEffectClaimRefs: required-effect claim `authorize payment`
actualTransformationRefs: not used
selectedTransformationFlowStructureRefs: TransformationFlowStructure@Checkout-v3
transformerSideFillerRefs: not used
candidateBearerRefs: not used
inputConditionRefs: not used
outputConditionRefs: not used
functionalPortRefs: not used
transformationFlowStructureViewRefs: exact PaymentAuthorizationPath description/view episteme
transformationFlowStructureRef: TransformationFlowStructure@Checkout-v3
selectedPathOrSliceRefs: PathSlice@request-to-payment-authorization
crossingBundleRefs: not used
flowValuationRefs: not used
mathematicalDescriptionRefs: not used
correspondenceClaimOrRelationRefs: claim that required effect `authorize payment` corresponds to the E.18 path slice; this is correspondence, not identity or actual change
sourcePublicationOrEditionRef: model or generated-graph edition when the flow relation was extracted from one
extractionOrProbeLocusRef: path-slice extraction or code-agent probe locus when current
relationObservationClassRef: observed, inferred, or unknown relation class when current
unexploredRegionRefs: not used
hiddenRelationStructureReturnCondition: reopen if mathematical-description edition, path slice, relation observation class, or required-effect declaration changes
admissibleUse: inspect whether the functional structure view depends on the E.18 path slice and whether an architecture split or correspondence claim is needed
stopOrReturnCondition: stop at the bounded architecture-to-flow correspondence and reopen when its source, path, observation class, or required-effect declaration changes

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.3 rather 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

Tell-Show-Show rowGrounding
TellA practitioner sees one TFS or several connected TFSs and wants to use that flow structure in an architecture question. C.30.TFS-REL makes them name the exact TFS or network and exact architecture locus; for a network, they choose one containing holon/relation or the exact participating holons and relations/claims. The result is one usable trace or an exact stop, not an architecture relation inferred from the diagram.
Show: U.SystemA software system, plant, AI agent, neural network, vehicle, or supply chain may have transformation-flow structure. A diagram or mathematical description can inform architecture reasoning about that structure without carrying the required-effect, actual-transformation, or other non-flow claims named in C.30.TFS-REL:4.3.
Show: U.EpistemeA mathematical graph description, generated relation graph, code-agent probe, neural-network diagram, dashboard, or architecture note is an episteme, representation, view, or publication. It can support the transformation-flow use only when exact E.18 TFS or E.18.NET network, the selected network architecture branch when applicable, edition/plane/context pins, correspondence, any relied-on row locator, hidden relation-structure return condition, and admissible use are recoverable.

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.

Bias riskMitigation
Structure-or-description-as-architecture biasDirect architecture relations and bounded claims stay with C.30, descriptions with C.30.AD, representations with C.29, mathematical descriptions with E.18.2, math-lens uses with C.29, and structural views with C.30.ASV/E.17.0.
Function-flow/change collapseRequired functional content, selected transformation-flow structure, and actual A.3.4 transformation remain separate. Functional and flow structures are related, not identical by default.
Non-flow claim overreadThe relation table assigns non-flow claim kinds to their governing patterns.
Mathematical overreadMathematical-lens use of a graph or valuation is governed by C.29.
Check-only biasConformance checks include repair actions and stop conditions.

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

IDRequirementFailed-check repair
CC-C30TFR-1 Flow-structure object.The record names the exact E.18 TFS, E.18.NET network, path, slice, crossing, or flow valuation object it uses.Add the exact E.18 or E.18.NET reference named by value, or use C.30 or C.30.ASV without this record.
CC-C30TFR-2 Architecture locus.The record names an actual ArchitectureRelation, exact selected architecture structure, exact ArchitectureStructuralView or ArchitectureDescription episteme, or bounded ArchitectureClaim.Add the exact architecture relation/structure/episteme/claim as the selected use requires; otherwise keep the TFS or network claim with E.18 or E.18.NET, the mathematical-description claim with E.18.2, or the math-lens-use claim with C.29.
CC-C30TFR-3 Functional, required, flow, and actual-change separation.Required/desired behavior and effect remain claim content; selected TFS remains structure; an actualTransformationRef appears only with the complete A.3.4 changed-referent, boundary, conditions, before/during/after, and continuity/reidentification basis. Functional and flow structure co-reference is explicit rather than assumed.Repair through FunctionTransformationFlowRelationNote; split the required claim, selected structure, and actual transformation; add correspondence or positive selected-structure co-reference only when its predicate is governed.
CC-C30TFR-4 No architecture takeover.The selected transformation-flow structure, network, mathematical description, or use record is not treated as generic architecture ontology or all architecture structure kinds.Assign actual architecture relations, selected architecture-relevant structures, bounded claims, or description use to C.30/C.30.AD and keep this pattern to the architecture-to-transformation-flow trace.
CC-C30TFR-4a Network architecture branch.A network use selects exactly one branch. The containing branch has one exact holon and actual architecture relation whose selected structure is the exact network. The inter-holon branch has at least two exact holons, exactly the actual architecture relations and bounded claims this question uses, no containing fields, and noNetworkBearerHolonAsserted=true; a singular participant ref never implies a containing architecture.Complete one branch, remove or reroute a conflicting architecture-side ref, add a participant only when the current question relies on it, or keep the network claim under E.18.NET without architecture use.
CC-C30TFR-4b Named characteristic bearer and representation boundary.Every architecture characteristic claimed or used remains on an exact named holon, actual architecture relation, selected structure, view/description episteme, bounded claim, or other governed bearer; no graph, representation, mathematical description, publication, or network record becomes that bearer.Name the exact bearer under C.30 or its direct owner; demote the visible object to representation, description, or publication use.
CC-C30TFR-4c Member-local, unfolding, and row-reference boundary.Every path, slice, crossing, valuation, required effect, or actual transformation named with a network remains bound to its exact owning member TFS and local positions, participants, or bindings; a network-aware unfolding selects the same network through its E.18.3 locator; every NetworkCrossFlowRelationRowRef resolves exactly one row in a current record for that network without replacing the obtaining relation occurrence.Restore the member-local binding or network-locator match; repair or remove a row locator that resolves zero or several rows or points to another network; keep occurrence truth with its direct governor.
CC-C30TFR-5 Work boundary.Establish any Work occurrence through A.15.1 and any work-result claim through its governing predicate.Keep the selected TFS, network, path, or slice as the flow-structure reference used by that claim; use A.15 for Method/Work alignment.
CC-C30TFR-6 Evidence, assurance, and gate boundary.Establish any evidence-sufficiency, assurance, gate-decision, or release-permission claim through its direct governing application and result.Apply A.10, G.6, B.3, A.20, A.21, or the release locus named by value.
CC-C30TFR-7 Causal and mathematical boundaries.Causal or intervention claims and mathematical-lens claims are assigned to C.28 and C.29.Apply those governing patterns or narrow the record's admissible use.
CC-C30TFR-8 Pin and scalarization boundary.Edition, context, and plane pins plus no-hidden-scalarization claims remain E.18-governed.Add E.18 pin and set-return references or remove the comparison or selection claim.
CC-C30TFR-9 Hidden relation return.Extracted, generated, coarsened, or partial relation graphs or flow diagrams state the source publication or edition, extraction or probe locus, relation observation class, unexplored regions, and hidden relation-structure return condition when hidden distinctions affect action.Add the missing relation-structure fields or narrow the admissible use.
CC-C30TFR-10 Useful action.The repair leaves a remaining use: name the selected TFS, path, or crossing; choose the containing or inter-holon branch for a selected network; add correspondence; return to source; assign the claim being made to a governing pattern; or stop.Restore that use, or classify the phrase as reduced-use cue, quote-only wording, blocked transfer, or incomplete rewrite.
CC-C30TFR-11 Lowering and currentness.The record states the smallest changed locus when E.18 TFS semantics or pins, E.18.NET network identity or relations, selected network branch or architecture loci, a relied-on row locator, relation observation class, correspondence, hidden relation-structure return, or related governing boundary changes.Update the affected TFS/network reference, branch, architecture locus, or row locator; narrow admissible use; keep subject claims with their direct owners; lower the record; or block architecture-to-transformation-flow use.

C.30.TFS-REL:8 - Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
Structure-as-architectureThe E.18 selected transformation-flow structure is called the whole architecture.Use C.30 for the actual architecture relation, selected structure, or bounded claim; C.30.AD for description; keep this record only for the transformation-flow use.
Unnamed network as architecture bearerA connected network or its graph is assigned maintainability, capability, responsibility, agency, production, required effect, or actual transformation without one containing holon/relation or explicit participating holons.Select the named-containing-holon or explicit inter-holon branch, restore every characteristic to a named bearer, and keep graph/record outside architecture identity.
Graph-description-as-functional-architectureA graph-shaped mathematical description or diagram is treated as functional architecture, functional element, or actual change.Split functional claim, selected TFS, actual transformation, mathematical description, representation, and publication; add correspondence when needed.
Flow-as-work-logPath or slice wording is treated as Work occurrence.Assign occurrence or result claims to A.15 or P2W and keep E.18 to selected structure, path, slice, or valuation.
Crossing-as-gate-resultA crossing relation is treated as gate passage.Assign gate-decision claims to A.21 and keep crossing relation under E.18.
Valuation-as-scoreA flow valuation is used as a generic architecture score.State E.18 valuation and set-return discipline; assign measurement, characterization, selection, or candidate-set claims to C.16 or an admitted governing pattern.
Generated relation-graph proofA code-agent relation graph or probe output is used as proof of architecture understanding or safety.Recover source publication/codebase edition, extraction/probe locus, observation class from {observed, inferred, unknown}, unexplored regions, hidden structure, and direct evidence or assurance application.
Prompt-data-tool flow as authority proofA prompt, data, or tool-flow diagram is treated as permission for tool action or proof that authority is safe.Keep it as a transformation-flow use or E.18.2 mathematical description. Route a selected SecurityTrustBoundaryStructure view through C.30.ASV; route agentic tool-use and call planning to C.24, autonomy-budget enforcement to E.16, and gate or release claims to A.20 or A.21 when those exact claim kinds are being made.

C.30.TFS-REL:9 - Consequences

BenefitCost or trade-off
E.18 TFS paths, crossings, valuations, and E.18.NET network structure become usable across actual architecture relations, selected architecture structures, exact structural views, and conditional descriptions without merging owners.Every use names the exact architecture locus. A network use also names either one containing holon/relation or all exact participating holons and needed relations/claims, and keeps every characteristic on a named bearer.
Required functional content, transformation-flow structure, and actual transformation stay separable.Concise "the diagram is the architecture/change" prose is repaired before it carries an FPF claim.
Non-flow claim kinds are assigned to their governing patterns.More governing patterns are named when practitioners try to overuse the diagram, mathematical expression, or selected structure.
The E.18 selected-structure boundary stays narrow.Generic architecture adequacy remains outside E.18.

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

Practice or reference lineC.30.TFS-REL adoptionAction consequenceBoundary
E.18 one-TFS discipline and E.18.NET network disciplineAdopt E.18 as owner of one TFS, paths, crossings, and valuations; E.18.NET as owner of one selected network, member-local references, and exact cross-member relations.Name the exact TFS or network, then add only the exact C.30 architecture locus and selected network branch.Neither flow-structure owner becomes generic architecture or architecture-description ontology.
ISO/IEC/IEEE 42010:2022 and multi-view architecture practiceAdapt view and correspondence discipline to architecture-to-transformation-flow reliance.Transformation-flow views relate to actual architecture relations, selected structures, exact structural views, or conditional descriptions through C.30, C.30.AD, C.30.ASV, and correspondence claims/relations.Architecture views do not become proof, evidence, gates, decisions, required-effect realization, or actual transformation.
MBSE and SysML v2 view and relation practiceAdapt model-derived flow views and path views as descriptions derived from a model publication or edition.A model-derived flow description states model edition, selected structure, hidden/lost structure, and admissible use.Tool models and queries do not override FPF E.18, C.30, A.3.4, or E.17.0 relations.
Neural-network dataflow and GonzoML architecture-operation corpusAdopt practitioner recognition for block replacement, path selection, memory/cache placement, MoE expert selection, pruning, distillation, ablation, and compute/memory/latency tradeoffs.Keep source labels with C.30.STRAT until exact values are recovered; C.30.TFS-REL applies only when recovered flow structure changes the architecture move.Benchmarks, ablations, pruning masks, or search outputs do not become evidence, assurance, gate passage, actual transformation, or architecture decision by themselves.
Theory of Code Space and arXiv:2603.00601 code-agent relation graph probingAdapt relation graphs with observation class from {observed, inferred, unknown} and partial-observability warnings.Generated code relation graphs can be used only with typed relation semantics, source/codebase edition, extraction/probe locus, unexplored regions, and hidden-relation return condition.Do not mint U.CodeSpace; probe output is not internal belief proof, architecture adequacy, assurance, or release evidence/claim.

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:

ModularityVectorLite:
  describedHolonRef:
  architectureQuestion:
  intendedArchitectureUse:
  claimScopeRef?: U.ClaimScope
  qualificationWindowRef?:
  architectureClaimRef?:
  selectedStructureRefs:
  structureKindRefs:
  threeLiveCharacteristicsAtMost:
  observedProblem:
  repairDirection:
  relatedClaimPatternLocatorsIfClaimed:
  nonAdmissibleOverread:
  stopCondition:

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

ForceTension
Fast architecture repair vs measurement admissibilityPractitioners often need the next modularity move before a full measurement template exists.
Characteristic plurality vs scalar pressureDifferent modularity interpretations have different subjects, scales, evidence, declared measurement or comparison basis, subject-pattern needs, and risks; one score hides that plurality.
Useful proxy vs proxy substitutionA cheap share, count, or graph interpretation can guide local repair, but it may become a false quality, evidence, or decision claim.
Module-interface view vs broader structureModularity can involve functions, flows, control, work, evidence, data, placement, or scale, not only modules.
Local repair vs cross-case useA local diagnosis can stop at report-only use; cross-case comparison needs an exact subject assertion and predicate under C.16, C.25, and G.2. Use G.5 only when selected-set result declaration is current and C.11 for local choice. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability. Each source pattern remains only a locator.
Complexity pressure vs complexity ontologyResidual pressure and growth signals are useful, but complexity is not one commensurable architecture characteristic.

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.

ModularityVectorLite:
  describedHolonRef:
  architectureQuestion:
  intendedArchitectureUse:
  claimScopeRef?: U.ClaimScope
  qualificationWindowRef?:
  architectureClaimRef?:
  selectedStructureRefs:
  structureKindRefs:
  threeLiveCharacteristicsAtMost:
    - characteristicRef:
      characteristicScaleRef?:
      evidenceRefs?:
      comparisonBasisRef?:
      currentCue:
      repairDirection:
      claimUseClass:
      forbiddenOverread:
  observedProblem:
  relatedClaimPatternLocatorsIfClaimed:
  stopCondition:

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

ModularityVectorLite:
  describedHolonRef: ProductPlatform@FieldPumpFamily
  architectureQuestion: which structural repair would reduce field-replacement and certification burden?
  intendedArchitectureUse: choose the next modularity repair for field service and procurement
  claimScopeRef?: field-service and procurement architecture claims
  qualificationWindowRef?: 2026Q2
  architectureClaimRef?: ArchitectureOf@PumpControllerPlatform
  selectedStructureRefs: PumpControllerModuleInterfaceStructure, PumpControllerEvidencePackageStructure
  structureKindRefs: ModuleInterfaceStructure, EvidencePackageStructure
  threeLiveCharacteristicsAtMost:
    - characteristicRef: InterfaceStandardizationShare
      currentCue: controller ports are named by the same API family, but three field variants still require adapter-specific wiring.
      repairDirection: narrow the interface grammar and name the allowed variation before counting the interface as standardized.
      claimUseClass: local repair cue
      forbiddenOverread: the public API label is not substitutability or procurement suitability.
    - characteristicRef: SubstitutabilityWidth
      currentCue: two alternate controller boards pass the bench test, but only one has the required thermal envelope and connector constraints.
      repairDirection: state the substitution conditions and the exception before using the alternative count.
      claimUseClass: report-only proxy until C.16 or selection use is being made
      forbiddenOverread: the alternate-board count is not a selection result.
    - characteristicRef: EvidenceReuseShare
      currentCue: electrical-safety evidence is reused, while environmental evidence is recreated per enclosure variant.
      repairDirection: split reusable evidence package from variant-specific evidence and add source-return condition.
      claimUseClass: local repair cue with possible evidence-package use
      forbiddenOverread: reused evidence is not assurance sufficiency.
  observedProblem: the team says the platform is modular because interfaces are public and evidence is reusable, but field replacement and certification still create variant-specific work.
  relatedClaimPatternLocatorsIfClaimed: A.6.M for the module-interface relation; C.31.RSA if report-only share becomes reusable-structure accounting; A.10 or B.3 only if an exact evidence-use or assurance-use assertion is being made.
  stopCondition: stop at local repair until measurement basis, comparability basis, and any selection or assurance use are declared by their subject patterns.

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:

ClassUseBoundary
DirectCharacteristicA C.16-governed characteristic can be named with subject, scale, unit or unitless interpretation, declared measurement basis, comparability basis, and repair action.It is not automatically a score or decision selector.
CompositeCharacteristicDescriptionThe head is a bundle or description with sub-slots, such as function-module alignment or flow-boundary alignment.Do not pretend the bundle is one raw measure.
LensBackedCharacteristicThe head depends on a model description or mathematical lens, such as compression or RG or coarsening lens.Apply C.29 for lens use that changes action.
TemporalOrScaleCharacteristicThe head depends on time window, repeated instance, scale variable, aggregation scope, or source-return condition.Apply C.31.ASAP for architecture scale preference, C.27 for temporal adequacy, and C.18.1 or C.19.1 when scale-law or general BLP preference claims are being made.
CausalUseSensitiveCharacteristicThe interpretation is used to claim effect or intervention success.Apply C.28 before relying on the claim causally.
ReportOnlyProxyThe interpretation is only a local diagnostic or communication aid.State forbidden overread and the subject pattern needed for any beyond-local-repair 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:

MeasurementHeadMapping:
  sourceHead:
  knownMeasureFamilyOrPractice:
  fpfCharacteristicKind:
  scaleType:
  unitPolicy:
  declaredBasisNeeded:
  requiredEvidence:
  evidenceRelationRefs?:
  evidenceProvenanceRelationRefs?:
  sourceRelationRefs?:
  evidenceClaimAbsentBecause?:
  commonFalseUse:
  nonAdmissibleUse:
  repairAction:
  relationFunctionClaimRef:

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:

ModularityCharacteristicCard:
  characteristicRef:
  subjectRef or relationSubjectTuple:
  characteristicClass:
  scaleRef:
  unitInterpretation:
  declaredBasisRef:
  comparabilityBasisRef:
  requiredEvidence:
  evidenceRelationRefs?:
  evidenceProvenanceRelationRefs?:
  sourceRelationRefs?:
  evidenceClaimAbsentBecause?:
  proxyRisk:
  auditQuestion:
  nonAdmissibleUse:
  repairAction:
  relatedClaimPatternLocators:

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.

Characteristic headIntended characteristic interpretationTypical scale or value formDeclared measurement or comparison basisDefect signalRepair directionEscalation trigger
InternalCohesionDensityDensity of typed relations inside a proposed module.ratio or graph-derived valuetyped dependency graph or DSMproposed module has insufficient typed internal dependency basissplit the proposed module, move relations, or reclassify as component relationcomparison, clustering, or publication use
ExternalCouplingDensityCross-boundary dependencies per module or interface.ratio or distributiontyped dependency graph, interface graph, integration defectshidden external dependencies dominate module boundaryexpose dependency, revise interface spec, split context, or accept bounded exceptionintegration risk, assurance, or release claim
InterfaceAlphabetSizeCount or entropy-like variety of interface types.count or entropy-like valueinterface registrytoo many interface variants erase modular benefitreduce variants, introduce interface grammar, split context, or document exceptionplatform grammar, candidate selection, or publication use
InterfaceStandardizationShareShare of interfaces conforming to declared specifications.ratio or percentageconformance tests and specificationsstandardization is low where reuse needs itdefine or narrow standards, add conformance tests, or stop at local exceptioncross-case comparison, certification, or procurement decision claim
InterfacePublicnessOpenness, publication, and vendor-neutrality value.ordinal or categorystandards, API specs, licensing, access termsopen label lacks substitutability relation, substitution policy, conformance expectation, or interface specificationrecover interface spec, substitution policy, and conformance expectationopen-architecture claim, procurement decision claim, or publication claim
SubstitutabilityWidthNumber or diversity of compatible alternatives for a slot or interface.count or diversity valueapproved implementations, vendors, testsonly one viable implementation existsrepair interface spec, loosen unnecessary coupling, or mark single-source exceptioncompetition, platform, or decision claim
ModuleTypeReuseRateInstances per module type or template.ratio or countproduct-line records, bills of material, template recordsreuse is claimed only by repeated namingdefine module type, allowed variation, and measurement basiscross-case reuse or product-line publication
TemplateCompressionGainDescription saving from template plus parameters compared with instance-by-instance descriptions.ratio or bits under declared methodcorpus or model-description methodcompression erases safety, law-domain, or source distinctionsadd source-return condition, split template, or apply C.29lens-characteristic or effect claim, publication, or decision use
FunctionModuleAlignmentCharacteristicFunctional elements and module relations align without unmanaged many-to-many exceptions.vector, ordinal, or bundle descriptionfunctional view and module relation recordsallocation hides many-to-many exceptionssplit function from module claim, revise allocation, or add correspondencecandidate decomposition or quality-composition claim
FlowModuleBoundaryAlignmentCharacteristicFlow topology crosses declared interfaces rather than hidden channels.vector, ordinal, or bundle descriptiontransformation-flow structure refs and interface refsflows bypass declared module boundariesexpose crossing, revise interface, or apply C.30.TFS-REL for the architecture-to-transformation-flow relation claimpublication or assurance claim about the architecture-to-transformation-flow relation
ControlStructureSeparationCharacteristicControl responsibilities, rates, and boundaries are explicit enough for the architecture move.ordinal or vectorLCA or control description and temporal adequacy basiscontrol relation is hidden inside module labelapply C.30.LCA, C.27, A.3.3, or B.3 when a control, temporal, dynamics, or assurance claim kind is being madestability, assurance, or gate use
HiddenCouplingDiscoveryRateHidden dependencies discovered after integration or change.ratedefect and change recordsdependencies appear lateexpose side channel, revise interface spec, add sentinel, or reopen boundaryintegration risk, repeated release, or assurance claim
CrossBoundaryChangeReachHow many modules, views, or work items a local change touches.distributionchange-impact recordslocal change travels farther than claimedsplit relation, add interface grammar, revise allocation, or source returnrelease, decision, or comparison claim
WorkRepeatabilityShareDelivery, operation, or test work under repeatable method descriptions.ratiowork records and method descriptionswork repeats as bespoke effortmove repeated work into MethodDescription or accept exceptionwork planning, evidence reuse, or scale use
EvidenceReuseShareEvidence package items reused across instances or contexts.ratioevidence graph and validity contextevidence is recreated or mis-scopedmove repeated evidence into reusable evidence or assurance packagecertification, safety-case, or assurance claim
RegulatoryBespokeResidueOne-off regulatory or acceptance content not covered by reusable structures.ratio or ordinalsafety, approval, or regulatory recordseach instance needs new regulatory argumentisolate residue, add reusable evidence package, or keep bounded exceptionsafety case, approval, or publication claim
LearningTransferCoefficientImprovement transfer from one instance or run to subsequent instances.slope or elasticityrepeated work data and learning curve recordsimprovement claim hides time or causal assumptionsapply C.27 for temporal adequacy and C.28 for causal usecausal, benchmark, or scale-preference use
BespokeResidueShareShare of structure not covered by reusable templates or rules.report-only share unless C.16 measurement basis is declaredRSA description and exception registerresidue is hidden under reuse scoreuse C.31.RSA and source-return conditionaccounting, comparison, or decision claim
RGFlowStabilityStability of characteristic vector across declared coarse-graining scopes.vector or ordinaldeclared multi-scope architecture graphscoarse-graining hides lower-scope hazardsapply C.29 for lens use and C.31.ASAP when an architecture scale-preference claim is being madeRG, scale, or lens transfer use
ExceptionCurveSlopeChange in one-off exceptions over a scale variable.slopeexception records against scale variableexceptions grow with scaleapply C.31.ASAP or accept bounded exceptionscale preference, publication, or decision claim

Claim-scoped residual heads

C.31 uses residual heads only as qualitative repair cues. These heads do not create one complexity characteristic.

HeadMeaningRelated claim pattern locator and assertion requirementRiskRepair direction
ComplexityGrowthPressurePressure to add, split, mediate, or stabilize a declared aggregation scope, interface grammar, control relation, evidence scope, work-method scope, abstraction scope, or source-return condition.C.30.ILC, C.31.ASAP when an architecture scale-preference claim is being made, G.5, C.11treating more apparatus as progressname the pressure and the repair direction; use set-return or decision patterns when the corresponding claim is being made
FrustrationResidualPersistent cross-scope residual after local repair.C.30.ILC, C.29-local cross-scope lens claimturning a lens-backed interpretation into proofkeep as residual cue or apply C.29 or C.30.ILC
ConflictResidualSlopeResidual grows or shrinks over declared scale variable, scale window, or coarse-graining scale.C.31.ASAP, C.29, C.27, C.18.1, C.19.1treating two points as universal lawdeclare window, lens-use boundary, and measurement basis or stop at report-only
DeclaredScopeAdditionCostAdded work, evidence, change-policy, latency, observability, accountability, or interface cost from a new declared aggregation or control scope.C.16, C.31, C.30.LCAignoring the cost of added structureidentify cost bearer and apply the measurement pattern if used for comparison
BespokeResidueGrowthOne-off exceptions grow with deployment spread, regulation, or project repetition.C.31.RSA, C.31.ASAP when an architecture scale-preference claim is being madeassuming all bespoke work is badsplit useful exception from repairable residue
InterfaceAlphabetGrowthInterface variants grow faster than reuse, substitutability, or integration payoff.A.6.M, C.31premature standardizationadd platform grammar, split context, or accept bounded variation
SourceReturnCostFrequency or cost of returning from a compressed, indexed, coarse, extracted, or accounting view to source-side structure records.C.29, source-return discipline, A.10over-compressionadd source-return condition or reduce compression
ControlNestingDepthRiskNested control relations create latency, accountability, observability, stability, or assurance cost.C.30.LCA, C.27, B.3, A.3.3LCA-as-proofapply control, temporal, assurance, or dynamics subject patterns when the corresponding claim is being made

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.

HeadProxy riskAudit question
ExternalCouplingDensityTeams hide dependencies instead of reducing them.Did integration failures or source-return events fall?
InterfaceStandardizationSharePremature standardization blocks useful variation.Did exception slope or workarounds rise?
InterfacePublicnessOpen label without substitutability.Are alternative implementations actually viable under declared conditions?
TemplateCompressionGainCompression erases safety, law-domain, or source distinctions.Did source-return events or bounded exceptions rise?
EvidenceReuseShareReused evidence becomes stale or mis-scoped.Does evidence remain valid in the new context?
RGFlowStabilityCoarse-graining hides lower-scope hazards.Are source-return conditions triggered?

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, or C.11 changes 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

Bias riskC.31 repair
Scalar biasRefuse one modularity score unless scoring method and comparability basis are declared.
Measure-first biasStart with ModularityVectorLite and repair direction before C.16-heavy fields.
Interface-publication biasTreat public interfaces as only one possible basis for substantiating substitutability.
Proxy biasAdd ProxyRisk and AuditQuestion to every decision-facing card.
Complexity umbrella biasKeep residual heads claim-scoped and apply scale, RG, or lens subject patterns when those uses are being made.
Source-label biasTreat software, neural-network, chiplet, safety-case, product-line, block, layer, expert, cache, router, and gate labels as source examples until C.30.STRAT and the subject pattern recover the FPF characteristic subject, structure, scale, and admissible use.

Conformance Checklist

IDCheck
CC-C31-1Ordinary use starts with ModularityVectorLite, three characteristics under evaluation at most, observed problem, repair direction, and stop condition.
CC-C31-2Each characteristic head under evaluation is classified as DirectCharacteristic, CompositeCharacteristicDescription, LensBackedCharacteristic, TemporalOrScaleCharacteristic, CausalUseSensitiveCharacteristic, or ReportOnlyProxy.
CC-C31-3A decision-facing or publication-facing head has MeasurementHeadMapping, C.16-compatible fields, and a required evidence relation, evidence-provenance relation, source relation, or explicit evidence-claim-absent reason before it is relied on.
CC-C31-4Each characteristic row states at least one repair action or exact subject assertion named by value with its predicate and non-semantic pattern locator.
CC-C31-5Report-only proxies state forbidden overread and do not establish beyond-local-repair use.
CC-C31-6Proxy-risk and audit-question fields are present for decision-facing cards.
CC-C31-7Complexity, residual, and growth heads remain claim-scoped cues; apply C.29, C.31.ASAP when an architecture scale-preference claim is being made, C.27, C.28, C.16, C.25, C.30.ILC, C.31.RSA, G.5, or C.11 when the corresponding claim kind is being made.
CC-C31-8No C.31 text treats modularity as a single quality proof, assurance proof, gate result, causal proof, or architecture decision.
CC-C31-9Any score discloses scoring method, codomain, polarity, characteristic basis, comparability basis, and use boundary through the subject pattern.
CC-C31-10SoTA seeds for DSM, modularity-index, empirical modularity, platform, evidence-reuse, Conway and mirroring, Amdahl, queueing, coordination-overhead, information-hiding, abstraction-leakage, or Goodhart and Campbell proxy-risk sources are converted into pattern-local G.2 rows before C.31 uses them for practitioner guidance being relied on.
CC-C31-11Source labels such as block, layer, expert, cache, router, or gate use C.30.STRAT before they become C.31 characteristic subjects, scale cues, repair actions, or proxy-risk rows.
CC-C31-12A vector, card, or report-only proxy states a lowering or reopen condition when proxy audit worsens, measurement or comparability basis changes, evidence relation, evidence-provenance relation, or source relation becomes stale, characteristic head changes, or a related subject pattern changes.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
ScalarModularityScoreA single score claims architecture quality.Replace with ModularityVectorLite, disclosed scoring basis and subject pattern, or report-only boundary.
UntypedMeasureListA table of heads appears without characteristic, scale, declared measurement basis, or repair action.Classify heads and create C.16-compatible cards only where the recovered claim needs them.
MeasurementBeforeRepairThe practitioner is asked for full measurement before one useful move exists.Start with three characteristics under evaluation and repair direction.
OpenInterfaceEqualsModularInterface publication is treated as modularity.Apply relation repair through A.6.M and characterize only the interface or substitutability head under evaluation.
ComplexityAsOneCharacteristicAlgorithmic cost, graph-connectivity cost, policy and approval cost, evidence-maintenance cost, and cognitive cost are averaged.Keep residual heads claim-scoped and apply lens or measurement patterns when those uses are being made.
ProxyBecomesValueA report-only proxy becomes a beyond-local-repair claim.State forbidden use and use the subject pattern before relying on that claim.

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 or practiceCurrentness or lineage useAdopt and adapt for C.31Rejected overreadPractitioner implication
DSM and dependency-structure practice (https://dsmweb.org/design-structure-matrix-dsm/; https://dsmweb.org/introduction-to-dsm/)Mature and still-used architecture-analysis practice for dependency representation, clustering, and compact dependency communication.Adopt typed dependency analysis as a possible declared measurement or comparison basis for specific C.31 heads such as InternalCohesionDensity, ExternalCouplingDensity, InterfaceAlphabetSize, and HiddenCouplingDiscoveryRate.A dependency matrix is not architecture, proof, complete modularity, assurance, or decision by itself.A dependency graph helps only after dependency kind, subject, scale, repair direction, and non-admissible use are declared.
Cabigiosu and Camuffo, "Measuring Modularity" (https://doi.org/10.1109/TEM.2016.2614881)Published modularity-measurement source used as measure-plurality lineage, not as a universal current scoring rule.Adopt the result that modularity measures answer different engineering or management questions; adapt it into Characteristic plurality vs scalar pressure, MeasurementHeadMapping, and proxy-risk fields.One measure family is not universal modularity adequacy and does not settle architecture quality.The practitioner asks which characteristic changes action before choosing any measure family.
Jung and Simpson modularity indices for DSM-based assessment (https://pure.psu.edu/en/publications/new-modularity-indices-for-modularity-assessment-and-clustering-o/)Product-architecture and DSM-index lineage for index choice, clustering, and assessment variation.Use as evidence that index choice depends on architecture type, dependency kind, and measure purpose; adapt by requiring characteristic, scale, measurement basis, comparability basis, and forbidden overread.One modularity index is not FPF architecture quality, architecture adequacy, or decision authority.Index use requires declared structure, dependency type, scale, and non-admissible overread before publication, comparison, or decision use.
MOSA and open systems practice (https://www.cto.mil/sea/mosa/; https://www.cto.mil/wp-content/uploads/2025/03/MOSA-Implementation-Guidebook-27Feb2025-Cleared.pdf)Current engineering and acquisition practice family for modular interfaces, conformance, severable components, replacement, and supplier diversity.Adopt the pressure to make interface standards, conformance, substitutability, and supplier-diversity relations explicit; adapt by applying A.6.M before C.31 characterizes InterfacePublicness, SubstitutabilityWidth, or related heads, and by applying G.5 or C.11 to supplier-set selection or procurement decision use when that use is being made.Open, public, platform, API, conformance, or supplier-diversity label is not modularity, procurement suitability, or a beyond-local-repair claim by itself.Open-system conformance and substitution claims may change C.31 repair only after the module-interface relation is repaired; procurement and other beyond-local-repair uses require their subject pattern.
Platform and product-line engineering practice (https://tag-app-delivery.cncf.io/fr/whitepapers/platform-eng-maturity-model/; https://www.sei.cmu.edu/library/variability-in-software-product-lines/; https://arxiv.org/abs/2605.21353)Mature product-line variability lineage plus current platform-engineering maturity-model and current SPLE-review cues; used for variability-slot, extension-rule, reuse, and exception-residue characteristic discipline.Adopt variability slots, extension rules, template records, product-line records, allowed variation, and exception-residue tracking as possible C.31 characteristic subjects or declared measurement bases.A platform or product-line label is not modularity value, reusable-structure proof, architecture scale-preference evidence, procurement suitability, or decision authority.The practitioner names which characteristic changes action: interface standardization, module-type reuse, template compression, bespoke residue, exception curve, or the subject pattern for a beyond-local-repair claim being made.
Conway and mirroring, information-hiding, effective-interface, and abstraction-leakage lineageSocio-technical and interface-boundary sources used as holon-architecture lineage, not as software-only ontology.Keep the source meaning in ordinary language. State only the correspondence claims that obtain: organization Systems and relations; system-role classifications and assignments; enactor relations; division of work; and dated Work whose exact actual performers are recovered through A.13 and which A.15.1 independently admits. Add assignment and F.6 refs to a reusable record only when it or the receiving use expressly represents precise assignment-bound attribution; keep module-interface structures separate. Infer none from the lineage phrase.Team boundary, delivery unit, documented interface, assignment, or abstraction label is not module boundary, Work occurrence, substitutability, modularity quality, or decision by itself.The practitioner separates organization relations, work or procedure organization, any Work chain, explicit interface, implicit dependency, and modularity characteristic before claiming improvement.
Amdahl, queueing, and coordination-overhead laws (https://www.cs.cmu.edu/~18742/papers/Amdahl1967.pdf; https://arxiv.org/abs/1306.3302; https://arxiv.org/abs/2603.20654)Mature mathematical law and queueing lineage plus current extension sources for communication, synchronization, and scalable-workload-fraction limits.Adopt serial fraction, synchronization, communication overhead, WIP, waiting, bottleneck, and partitionability as possible C.31 defect signals; apply C.29, E.18, or C.30.TFS-REL when mathematical speedup or flow claims are being made.More modules, teams, services, flow branches, processors, accelerators, or work partitions are not improvement by count.A module split is evaluated by changed characteristics and bottlenecks, not by decomposition count.
Goodhart and Campbell proxy-pressure laws and holon-architecture trade-off disciplineGeneral proxy-risk and trade-off lineage for architecture characteristic use.Adopt vector and trade-off discipline plus proxy-risk discipline: no single modularity score, reusable share, benchmark, or index establishes value or beyond-local-repair use without the subject pattern for that use.One declared measure value, benchmark, reusable-share number, or modularity index is not architecture value or decision authority.The practitioner states which characteristic changes action and which proxy overread is blocked before comparison or decision.
Architecture-operation language, with neural-network and software-system discussions as source examples, including the GonzoML architecture-operation intakeCurrent practitioner-language source for replacement, selection, pruning, distillation, ablation, block substitution, memory or cache placement, gating, routing, and architecture search; not used as a standard.Adopt operations as recognition cues for structure, relation, flow, scale, or candidate-set repair under consideration; keep block, layer, expert, cache, router, and gate as C.30.STRAT source labels until the FPF characteristic subject, relation kind, scale, and admissible use are recovered.Block, layer, expert, cache, router, gate, benchmark, ablation, pruning, or distillation label is not an FPF characteristic by default.The operation points to a possible characteristic; it does not name the characteristic until the FPF kind, subject, scale, and admissible use are recovered.

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

PatternRelation
C.30.STRATRecovers source labels such as layer, level, tier, stack, block, expert, cache, router, and gate before C.31 uses any recovered characteristic subject, scale cue, repair action, or proxy-risk row.
A.6.MRepairs module-interface relations before C.31 characterizes modularity.
C.31.RSAGoverns reusable-structure accounting, bespoke residue, and report-only shares.
C.31.ASAPGoverns architecture scale-preference claims after C.31 names the scale-sensitive characteristic, scale variable or window, and repair direction.
C.16, A.17, A.18, A.19Govern characteristic, scale, coordinate, score, unit, comparability, and measurement admissibility.
C.25Governs broader quality-family Q-Bundles when modularity is used in a quality claim.
C.30 and C.30.ASVGovern architecture claims and structural views that supply C.31 subjects.
C.33, C.34, and C.35Use these patterns for captured-structure adequacy, lost-structure adequacy, preservation adequacy, correspondence adequacy, generated-carrier adequacy, or discovered-carrier adequacy around modularity and reusable-structure material. C.31 remains the pattern for modularity, reuse, proxy-risk, report-only, and characteristic use.
C.30.ILCGoverns cross-scope residual and frustration recognition when architecture move triage is being made.
C.29Governs mathematical-lens use such as compression, RG, epiplexity, or graph-lens transfer.
C.27, C.18.1, C.19.1Govern temporal and set-dynamic claims such as learning transfer, exception slope, and scale-window movement.
C.28Governs causal-use claims.
A.10, B.3, A.20, A.21Govern evidence, assurance, gate, safety, and release claims.
C.32.P2SUses C.31 modularity and reusable-structure characteristics when problem pressure must continue into candidate synthesis, decision, realization, and actual-structure feedback; C.31 still governs only characteristic and report-only modularity use.
G.2, G.5, C.11Define SoTA-basis, set-selection, and local-decision predicates. Candidate-generation or architecture-synthesis claims stay outside C.31 unless an exact current assertion satisfies the predicate or constraint whose defining ClaimGraph is located through G.5, C.11, or a named architecture-synthesis pattern description; C.31 records only modularity or reusable-structure characteristic use and report-only boundaries.

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:

ReusableStructureTriage:
  describedHolonRef:
  reuseQuestion:
  deploymentBoundary?:
  intendedAccountingUse:
  claimScopeRef?: U.ClaimScope
  qualificationWindowRef?:
  architectureClaimRef?:
  structureRefs:
  structuralAspectRefs?:
  accountingRelationRefs:
  evidenceRefs:
  whereReusableStructureCurrentlyLives:
  whereBespokeResidueCurrentlyGrows:
  residueRefactoredInto:
    template | interfaceSpecification | methodDescription |
    workStructure | evidencePackage | assuranceArgumentStructure | otherDeclared
  residueAcceptedAsBoundedException:
  sourceReturnCondition?:
  relatedClaimPatternsIfClaimed:
  stopCondition:

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

ForceTension
Reuse visibility vs false proofReusable loci should be visible, but a share is not proof of quality, assurance, or architecture adequacy.
Accounting convenience vs heterogeneous structureTemplates, interface grammars, work methods, and evidence packages do not automatically share one unit.
Residue repair vs useful exceptionSome bespoke residue should be refactored; some should remain a bounded exception.
Compression vs source returnAccounting can summarize structure, but downstream action may require return to source-side records.
Local triage vs cross-case comparisonA local report-only share can guide repair; comparison needs declared scale, unit interpretation, admissible comparability relation, and comparator admission named by value.
Reuse value vs reuse costMore reusable structure can increase interface cost, evidence decay, or loss of needed variation.

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

ReusableStructureAccountingDescription@Context:
  accountingBasisRef:
  structureRefs: FinSet(U.StructureRef)
  structuralAspectRefs: FinSet(StructuralAspectDescriptionRef)
  reusableStructureSlots:
  bespokeResidueSlots:
  hiddenOrResidualUncertaintySlots:
  slotBasisRefs?:
  admissibleAggregationRuleRef?:
  reportOnlyShares?:
  sourceReturnCondition?:
  admissibleUse:
  nonAdmissibleUse:

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:

S_function
S_flow
S_control
S_type
S_interface
S_scale
S_work
S_evidence
S_changePolicy
S_unique
S_crossScopeUnique
H_residual

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

ReusableStructureShare:
  report-only share over declared structureRefs and structuralAspectRefs
  under accountingBasisRef; not an architecture amount

BespokeResidueShare:
  report-only share under accountingBasisRef

HiddenOrResidualShare:
  report-only uncertainty or residue interpretation under accountingBasisRef

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:

total-described-structure under accountingBasisRef:
  reusable slots
  bespoke residue slots
  hidden or residual uncertainty slots

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:

SituationRepair direction
Repeated delivery work contains structure that is not explicit in the work or method description being used.Move repeated structure into MethodDescription, work structure, or reusable work relation.
Repeated interface exceptions are handled one by one.Add or revise interface grammar, variability slots, or substitution policy under A.6.M.
An undocumented dependency crosses module or view boundaries.Expose the dependency, revise boundary, add correspondence, or add source-return condition.
Evidence is recreated for each instance.Move repeatable evidence into an evidence package, assurance argument record, or validity-context note.
Regulatory or safety-case residue remains one-off.Split reusable argument structure from context-specific exception; apply B.3 or G.6 for assurance or safety-case reliance.
Compression hides needed distinctions.Reduce compression, add source-return condition, or apply C.29 for lens-governed compression or reduction claims.
Bespoke residue protects necessary local variation.Keep it as a bounded exception with admissible use and non-admissible use.

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:

Reuse move may improveCheck what may worsen
Template reuseLoss of needed variation, hidden local exception, or stale source-return condition.
Interface grammarInterface relation cost, conformance work, change cost, migration cost, or substitution constraint.
Work-method reuseContext mismatch, extra handoff cost, slower local response, or hidden work exception.
Evidence-package reuseEvidence decay, validity-window mismatch, missing context witness, or assurance overread.
Assurance-argument reuseWeakest-link dependency, certification-window mismatch, or unexamined regulatory exception.
Compression or lens-backed accountingLost source distinction, observer-budget dependency, or C.29 stop-condition breach.
Bespoke-residue reductionReduced resilience, local-fit loss, or new hidden coupling.

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:

A regulated product line has reusable component templates and a reusable test package.
Each customer delivery still repeats approval work and bespoke integration exceptions.

ReusableStructureTriage:

describedHolonRef: product-line delivery system
reuseQuestion: which selected structures are reused and where does bespoke residue grow?
deploymentBoundary: regulated customer deployments
intendedAccountingUse: decide the next reusable-structure repair
claimScopeRef: reusable-structure accounting for regulated delivery
qualificationWindowRef: 2026Q3 regulated-delivery review window
architectureClaimRef: C.30 architecture claim for the product-line delivery system and its selected delivery structures
structureRefs:
  component template structure
  interface grammar structure
  evidence package structure
  delivery work structure
accountingRelationRefs:
  reuse, exception, and bespoke-residue relations for the named deployments
evidenceRefs:
  deployment, approval, integration-exception, and reusable-test-package records
whereReusableStructureCurrentlyLives:
  component template structure
  reusable test package
  interface grammar for standard variants
whereBespokeResidueCurrentlyGrows:
  customer-specific approval work
  integration exceptions outside interface grammar
  local evidence witnesses not covered by reusable package
residueRefactoredInto:
  workStructure + evidencePackage + interfaceSpecification
residueAcceptedAsBoundedException:
  customer-specific regulatory clause with declared non-admissible reuse
sourceReturnCondition:
  return to deployment evidence and regulatory exception record before assurance or gate use
relatedClaimPatternsIfClaimed:
  `A.10` and `G.6` for evidence validity; `B.3` for assurance reliance; `A.6.M` for interface grammar; `C.16` if comparison is being made
stopCondition:
  report-only accounting unless comparator admission, evidence validity, and assurance validity are declared

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:

A team reports that 85 percent of its architecture is reusable because most screens use one shared template.
The template makes many local exceptions necessary for product teams and side-channel integrations.

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:

A model architecture replaces a repeated attention block with a hybrid SSM-attention block.
The benchmark improves, but cache placement, memory access, and ablation evidence change.

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

Bias riskC.31.RSA repair
Reuse-good biasDo not treat more reusable structure as automatically better. Ask what repair, cost, or source-return condition follows.
Share-proof biasDo not let ReusableStructureShare prove modularity, quality, or any outside-RSA use named in the claim-use boundary.
Hidden-unit biasDo not sum templates, interface variants, work items, and evidence packages without a declared accounting basis.
Residue-bad biasDo not treat every bespoke exception as waste. Some residue is a bounded exception that preserves local fit or safety.
Evidence-reuse biasDo not count evidence reuse without validity context and source-return condition.
Compression biasDo not let accounting hide distinctions needed for action, assurance, causal use, law-domain review, regulatory review, or subsequent decision reopening.

Conformance Checklist

IDCheck
CC-C31.RSA-1The text starts from ReusableStructureTriage unless an accounting basis and structure refs are already named.
CC-C31.RSA-2Any accounting description names accountingBasisRef, structureRefs, structuralAspectRefs, reusable slots, bespoke residue slots, residual uncertainty slots, admissible use, and non-admissible use.
CC-C31.RSA-3Report-only shares are marked report-only unless every outside-RSA use being made and named in the claim-use boundary is governed by its governing pattern.
CC-C31.RSA-4No text treats RSA as proof of modularity, quality, or any outside-RSA use named in the claim-use boundary.
CC-C31.RSA-5Heterogeneous slot labels are not summed unless a declared accounting basis and aggregation rule make the operation admissible.
CC-C31.RSA-6Each bespoke residue interpretation states a repair direction, bounded-exception condition, source-return condition, or governing-pattern application.
CC-C31.RSA-7Evidence reuse and assurance reuse apply A.10, B.3, or G.6 when validity, assurance, or safety-case reliance is being claimed.
CC-C31.RSA-8RSA does not duplicate the C.31 characteristic taxonomy; it uses C.31 only when a modularity characteristic under evaluation, such as bespoke residue, evidence reuse, or residual uncertainty, must govern the accounting interpretation.
CC-C31.RSA-9Source-return condition is present when accounting hides action-relevant source distinctions.
CC-C31.RSA-10Outside-RSA comparison, ranking, selection, gate use, or decision use names comparator admission named by value such as CG-Spec, ComparatorSetRef, or a comparator-governing reference named by value; otherwise the RSA share remains report-only.
CC-C31.RSA-11The RSA note names reopen or lowering conditions for source distinction change, accounting-basis change, structure-edition change, implicit-interface change, comparator change, evidence or assurance decay, downstream reliance, repeated bounded exception, and reuse move side effects when those conditions are needed for the record.
CC-C31.RSA-12Source labels such as block, layer, expert, cache, router, gate, or pruning mask use C.30.STRAT before they become structureRefs, structuralAspectRefs, accounting-basis fields, repair actions, or source-return conditions.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
ArchitectureAmountA reusable share is treated as an amount of architecture.Restate as report-only share under one declared accounting basis.
ResidueIsWasteAll bespoke residue is marked bad.Split repairable residue from bounded exception.
HeterogeneousPseudoSumTemplates, interface variants, work items, evidence packages, and exceptions are summed as if they shared one unit.Declare accounting basis or keep the decomposition qualitative.
EvidenceReuseAsAssuranceEvidence reuse share is treated as assurance.Apply A.10, B.3, or G.6 for validity and assurance reliance.
RSAAsC31DuplicateRSA repeats every modularity characteristic.Keep RSA to reusable loci, bespoke residue, residual uncertainty, report-only shares, and source-return conditions.
NoSourceReturnAccounting hides source distinctions used by downstream action.Add sourceReturnCondition or narrow admissible use.

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 or practiceCurrentness or lineage useAdopt and adapt for C.31.RSARejected overreadGoverning-pattern use and action consequence
C.25 Q-Bundle discipline inside FPFLanded FPF-local governing discipline for quality-family claims.Adopt separation of scope, measures, mechanisms, windows, evidence, and admissible use. In C.31.RSA this changes ReusableStructureShare: the share is report-only accounting under declared accountingBasisRef until the relevant outside-RSA use is governed by its governing pattern.A reusable-structure share does not replace the underlying Q-Bundle, description, evidence relation, or decision record.Apply C.25 and C.16 when reuse becomes a quality claim or measurement claim; the practitioner may report a share locally but must not use it as proof without the governing pattern for that use.
ISO/IEC/IEEE 42010:2022 architecture-description, viewpoint, model-kind, and correspondence discipline (https://www.iso.org/standard/74393.html; https://www.iso-architecture.org/ieee-1471/cm/)Current international standard and conceptual-model source for architecture-description and view discipline for this source-use decision.Adopt explicit architecture description, source view, viewpoint, model-kind, correspondence, and conformance pressure. In C.31.RSA this changes source-return use: reusable-structure accounting names the structure refs, source view or architecture-description refs, correspondence refs, and source-return condition before any cross-view share is used.A view, diagram, model kind, or correspondence label is not the reusable structure itself and does not make a share comparable, admissible for decision use, or assurance-bearing.Apply C.30, C.30.ASV, or E.17.0 when source views or architecture descriptions are being used; RSA may count only after the selected structure refs and accounting basis are recoverable.
Modular Open Systems Approach (MOSA) and open-system acquisition or engineering practice (https://www.cto.mil/sea/mosa/; https://www.cto.mil/wp-content/uploads/2025/03/MOSA-Implementation-Guidebook-27Feb2025-Cleared.pdf)Current engineering and acquisition practice family for modular interfaces, conformance, replacement, and supplier-diversity pressure.Adopt the pressure to make reusable interface, conformance, substitution, and supplier-diversity structure explicit. In C.31.RSA this changes interface reuse: reusable interface accounting remains report-only until A.6.M has repaired interface grammar, substitution policy, version or change policy, conformance work, source or evidence relation, and the supplier-diversity relation when that relation is being made.Open interface label, API label, platform label, or supplier-diversity goal is not reusable structure, procurement suitability, assurance, gate passage, or decision authority by itself.Apply A.6.M for interface grammar, substitution policy, version or change policy, conformance expectations, source or evidence relation, and supplier-diversity relation before RSA comparison or decision use; use G.5 or C.11 for supplier-set selection or procurement decision use when that use is being made.
DSM, dependency, and product-architecture practice, including Eppinger and Browning DSM lineageMature architecture-analysis lineage still used for dependency and product-architecture reasoning; lineage, not a complete current standard.Adopt typed dependency structures as possible source for reusable loci and bespoke-residue diagnosis. In C.31.RSA this changes dependency use: dependency counts, partitions, and clusters become candidate source fields only when declared structureRefs, structural aspects, and accounting basis are present.Dependency count, cluster count, or DSM modularity score is not architecture amount, quality proof, or decision verdict.Apply C.16 and C.31 for characteristic and scale admissibility; apply C.29 when graph, partition, compression, or C.29 lens-use result changes action.
Goodhart and Campbell proxy-pressure lawsGeneral proxy-risk lineage for report-only shares, reuse scores, and benchmark-like accounting.Adopt proxy-risk discipline for reusable-share use. In C.31.RSA this changes share use: a reusable-structure share remains report-only until the relevant outside-RSA use is governed by governing patterns.Reusable-share improvement, coverage improvement, or benchmark improvement is not value, assurance, evidence sufficiency, gate passage, or architecture decision by itself.Apply C.16, C.25, G.5, C.11, or the evidence and assurance patterns before a reuse number can guide selection or reliance.
System-evolution, information-hiding, and effective-interface lineageGeneral holon-architecture lineage for reusable structure that changes over time and hides variation-prone structure.Adopt evolution and hidden-change discipline. In C.31.RSA this changes residue interpretation: reusable loci, bespoke residue, hidden interface behavior, source-return conditions, and bounded exceptions are reopened when the structure edition, accounting rule, implicit interface, or reliance relation changes.One-time reusable-share accounting is not sustainable fitness; a stable-looking interface or template does not prove future substitutability.Reopen or lower the RSA result when hidden variation, implicit dependency, source distinction, or continuing adaptation changes the accounting meaning.
Software product-line engineering and variability-management practice, including Pohl, Boeckle, and van der Linden lineage plus current product-line and variability work (https://www.sei.cmu.edu/library/variability-in-software-product-lines/; https://arxiv.org/abs/2605.21353)Mature product-line variability lineage plus current SPLE-review cues for variability slots, product-line reuse, platform extension rules, and reuse-rule discipline.Adopt variability-slot and reuse-rule pressure. In C.31.RSA this changes product-line use: reusable structure may be located in template, interface, work, evidence, and exception loci, and bespoke residue must name repair direction, bounded exception, or source-return condition instead of being averaged into one share.Product-line label, shared code base, feature model, or platform name is not enough to infer reusable structure or architecture scale-preference evidence.Apply A.6.M for platform claims or interface claims, C.31.ASAP for architecture scale preference, and C.11 or G.5 for choice or candidate-set use.
GSN Community Standard v3 and assurance-case reuse and safety-case reuse practice (https://scsc.uk/gsn; https://arxiv.org/abs/2506.11023)Current assurance-case standard family plus current formalization work for this source-use decision; assurance validity remains context-sensitive.Adopt the distinction between reusable assurance argument structure, reusable evidence structure, and context-specific validity witnesses. In C.31.RSA this changes evidence and assurance reuse: reuse remains accounting until evidence validity, safety-case use, or assurance reliance is governed by its own pattern.Evidence reuse share or assurance-argument template reuse does not infer assurance, safety-case success, gate passage, or release permission.Apply A.10 and G.6 for evidence validity and safety-case use, and B.3 for assurance reliance; add source-return condition and validity-window check before reliance.
Architecture-operation language, with neural-network and software-system discussions as source examples, including the GonzoML architecture-operation intakeCurrent practitioner-language source for structural substitution, gating, memory placement, cache placement, routing, ablation, pruning, distillation, and architecture search; not used as a current standard by itself.Adopt the recognition that replacement and search expose reusable and bespoke structural loci. In C.31.RSA this changes architecture-operation use: source labels such as block, layer, expert, cache, router, gate, or pruning mask remain source labels until C.30.STRAT and the governing pattern for the claim being made recover structureRefs, aspect refs, accounting basis, repair actions, and source-return conditions.Block, layer, expert, cache, router, gate, benchmark, ablation, pruning mask, or distillation success is not RSA slot ontology, architecture decision, evidence sufficiency, gate passage, assurance, or architecture adequacy by itself.Apply C.30.STRAT first where source-label recovery is needed, then C.30 or C.30.ASV for architecture claim and structural view, C.30.TFS-REL for flow changes, C.29 for mathematical-lens or compression claims, A.10 or G.6 for benchmark or evidence use, and C.28 for causal claims.

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

PatternRelation
C.30.STRATRecovers source labels such as layer, level, tier, stack, block, expert, cache, router, gate, and pruning mask before RSA uses recovered reusable loci, bespoke-residue loci, accounting-basis fields, repair actions, or source-return conditions.
C.31Supplies modularity characteristics under evaluation; RSA does not duplicate the characteristic taxonomy.
A.6.MSupplies module-interface relation repair for reusable interface and platform-grammar claims.
C.30 and C.30.ASVSupply architecture claim and structural-view context for the structures being accounted over.
C.16, A.17, A.18, A.19Govern measurement, scale, unit, comparability, score, and characteristic admissibility when RSA shares are used beyond report-only.
C.25Governs broader quality-family bundles when reusable structure is used in a quality claim.
A.10, B.3, G.6Govern evidence, assurance, and safety-case reliance.
C.29Governs compression, epiplexity, RG, or other mathematical-lens claims when accounting depends on a lens.
C.27, C.28, C.31.ASAP, C.18.1, C.19.1Govern temporal, causal, architecture scale-preference, scale-law, and BLP claims derived from residue growth or reuse movement.
C.32.P2SRSA rows may supply reusable structure, bespoke residue, evidence reuse, or source-return pressure to an architecturing flow. Candidate synthesis, selected-set result declaration, and architecture decisions remain outside RSA.
G.5, E.17, E.24.PUB, C.11Use G.5 for selected-set result declaration, E.17 for a source-backed publication face and source return, E.24.PUB for the publication occurrence and audience availability, and C.11 for local decision. Candidate synthesis stays with C.32; RSA defines or tests none of these uses.

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:

ScaleClaimTriage:
  architectureAlternativeSetRef:
  describedHolonRef:
  claimScopeRef:
  selectedContextSliceRefs:
  modelUseStructureRef?:
  scaleVariableRef:
  scaleWindowRef:
  claimedPreferenceUnderScale:
  slopeEvidenceRef, scaleProbeEvidenceRef, or noProbeReason:
  expectedStableOrImprovingStructure:
  exceptionGrowthRisk:
  sourceReturnCondition:
  relatedClaimGovernanceIfClaimed:
  stopCondition:

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

ForceTension
Fast architecture choice vs scale evidencePractitioners often need a scale-aware preference before a full scale study exists.
Reusable structure vs useful exceptionReuse can improve scale behavior, but some bespoke residue is justified by safety, law-domain, mission, or context constraints.
Platform label vs scale mechanismA platform or product-line name does not say which variability slots, extension rules, exception curve, or refactor trigger makes scale behavior better.
Coarse view vs source distinctionsCoarse-grained architecture descriptions can expose stable structure, but they can also hide lower-scope hazards.
Preference guidance vs selection authorityA scale preference can inform a candidate set or decision, but selection and choice remain with their governing patterns.
Architecture scope vs method BLPArchitecture scale amenability resembles BLP, but C.31.ASAP governs architecture alternatives and selected structures, not general method-family policy.

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:

  1. a declared architecture alternative set, described holon, exact U.ClaimScope, and relevant A.2.6 U.ContextSlice membership;
  2. a declared scale variable or scale window;
  3. a claimed preference under scale;
  4. slope evidence, scale-probe evidence, or a no-probe reason;
  5. 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:

ScaleClaimTriage:
  architectureAlternativeSetRef:
  describedHolonRef:
  claimScopeRef:
  selectedContextSliceRefs:
  modelUseStructureRef?:
  architectureClaimRef?:
  scaleVariableRef:
  scaleWindowRef:
  claimedPreferenceUnderScale:
  slopeEvidenceRef?:
  scaleProbeEvidenceRef?:
  noProbeReason?:
  expectedStableOrImprovingStructure:
  exceptionGrowthRisk:
  sourceReturnCondition:
  admissibleUse:
  nonAdmissibleUse?:
  relatedClaimGovernanceIfClaimed:
  stopCondition:

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:

Scale variableReading
N_unitsrepeated units or instances
N_scopeCountaggregation scopes, coarse-graining scopes, or typed LCA control scopes
N_sitesdeployments, sites, markets, or jurisdictions
N_interfaceTypesdistinct interface grammar variants
N_requiredTransformationKindsdistinct transformation kinds in the selected functional-structure view
N_flowRelationKindsflow-relation or crossing variants in the selected flow-structure view
N_moduleTypesmodule type library size
N_workRepetitionsdelivery, operation, or test repetitions
N_supplierOrVendorClassessubstitutability or vendor class dimension
N_regulatoryInstancesapproval, safety, or certification repeats
freedomOfActionallowed design, search, or control variation

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:

ArchitectureScaleAuditRecord@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureScaleAuditProjectUseRelationRef?: U.RelationRef governed by the exact audit-use or work-use pattern
  architectureAlternativeSetRef:
  claimScopeRef:
  selectedContextSliceRefs:
  modelUseStructureRef?:
  scaleVariableRefs:
  scaleWindowRef:
  ArchitectureSlopeVector:
  IsoScaleParityNote?:
  ASAPWaiverReason?:
  ArchitectureHeuristicDebt?:
  BespokeResidueRegisterRef?:
  SourceReturnCondition:
  admissibleUse:
  nonAdmissibleUse?:
  relatedClaimGovernanceIfClaimed:
  stopCondition:

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.

OutputMeaning
ArchitectureSlopeVectorSlopes for reusable structure, interface variation, flow stability, control stability, work repeatability, bespoke residue, exception growth, and learning transfer.
IsoScaleParityNoteComparison under equalized scale budgets where possible; if parity is not possible, the loss is named.
ASAPWaiverReasonDeclared reason for not choosing the scale-amenable alternative.
ArchitectureHeuristicDebtReport-only note for knowingly accepting a locally hand-engineered solution with less scale-amenable slope profile under the declared scale window.
BespokeResidueRegister@ProjectPattern-local exception inventory with expiry or refactor triggers.
ScaleWindowDeclared range where the preference claim holds.
SourceReturnConditionCondition for returning from a compressed, coarse, extracted, indexed, or accounting representation to source-side structural evidence, source records, or a related source or evidence record with higher declared validation boundary.

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

ASAPWaiverReason:
  deontic constraint
  safety or law-domain boundary
  scale-probe overturn
  assurance infeasibility
  context-specific bounded exception

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:

Scale symptomPossible architecture moveBoundary
interface variants grow without payoffreduce interface alphabet or introduce interface grammarA.6.M governs interface relation repair.
product-line or platform variants lack explicit variation pointsintroduce variability slots or extension rulesPlatform label alone is not scale-preference evidence.
one aggregation scope hides lower-scope hazardssplit the declared aggregation scope or architecture boundaryC.29 supplies lens-use fields only when coarse-graining is mathematical-lens use.
repeated work contains reusable structurereplace bespoke work with a method templateWork and method claims go to A.15, A.15.1, or A.15.4 when those claims are being made.
regulatory or safety residue remains local and repeatedisolate regulatory residue or safety-specific exception registerEvidence, assurance, and gate claims go to A.10, B.3, G.6, or A.21.
coarse representation loses safety, semantic, or source distinctionsreturn to lower-scope source-side evidence or narrow the scale windowSource-return condition is mandatory.

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

ArchetypeWithout C.31.ASAPWith C.31.ASAP
Product-line platformPlatform name is treated as scale-preference evidence.Variability slots, extension rules, exception curve, and refactor triggers are declared before preference use.
Neural architecture block libraryReusing blocks is treated as reusable architecture by itself.The alternative set names scale variable, interface grammar variants, exception growth, and source-return condition.
Safety or certification reuseReusable evidence package is counted without validation boundary.Evidence reuse remains tied to source-return; A.10, B.3, or G.6 govern evidence validity, assurance reliance, or safety-case use when those claims are being made.
Cross-scope residualA frustration or complexity label is treated as scale mathematics.C.31.ASAP names the scale window and residual slope; C.29 records the lens-use fields if the mathematical-lens use is being claimed.

Filled triage slice

ScaleClaimTriage:
  architectureAlternativeSetRef: product-line platform alternative vs bespoke customer-specific variants
  describedHolonRef: the regulated deployment platform and its site-specific variants
  claimScopeRef: preference claim for 5 to 40 named regulated deployment sites inside the current qualification boundary
  selectedContextSliceRefs: the named site, jurisdiction, and qualification-window slices admitted by that claim scope
  modelUseStructureRef?: absent; no independently selected bounded-model-use structure changes this use
  scaleVariableRef: N_sites
  scaleWindowRef: 5 to 40 regulated deployment sites inside the current qualification window
  claimedPreferenceUnderScale: platform alternative is preferred if interface variants and approval exceptions grow slower than bespoke variants
  slopeEvidenceRef, scaleProbeEvidenceRef, or noProbeReason: scale-probe evidence from six deployments; no universal scale law claimed
  expectedStableOrImprovingStructure: interface grammar, reusable test package, deployment work template
  exceptionGrowthRisk: jurisdiction-specific clauses and side-channel integrations may grow faster than sites
  sourceReturnCondition: return to exception register, interface variant log, and deployment evidence before publication, selected-set, assurance, or decision use
  relatedClaimGovernanceIfClaimed: C.31 for the characteristic; C.31.RSA for reusable-structure share; C.16 or A.19 for comparison; G.5 or G.9 for selected-set use; C.11 for local decision; A.10, B.3, or G.6 for evidence or assurance
  stopCondition: stop at local scale-preference guidance unless comparator admission, evidence validity, and decision or selected-set governance are present

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

Bias riskC.31.ASAP correction
Platform label biasPlatform or product-line wording names a possible source context, not scale-preference evidence. Recover variability slots, extension rules, exception curve, refactor triggers, and source-return condition.
Modularity-means-scalability biasA module count, interface count, or reusable-structure share is not a scale preference. Use C.31 and C.31.RSA first, then C.31.ASAP only when scale variable and scale window are named.
Debt inflation biasA locally hand-engineered solution is called debt without checking deontic, safety, law-domain, mission, assurance, or scale-probe waiver reasons.
RG proof biasRG, coarse-graining, fixed-point, or universality wording is treated as scale-preference proof. Use C.29 for lens recovery and keep scale preference in C.31.ASAP.
Selection launderingThe scale-preference claim is used as if it selected the architecture. Use G.5, G.9, or C.11 for selected-set or choice claims.

Conformance Checklist

IDRequirementPurpose
CC-C31.ASAP-1A C.31.ASAP use being made names the architecture alternative set, described holon, exact U.ClaimScope, relevant A.2.6 U.ContextSlice membership, scale variable or scale window, and claimed preference under scale.Prevents generic "scales better" and generic-context wording.
CC-C31.ASAP-2ScaleClaimTriage names slope evidence, scale-probe evidence, or a no-probe reason.Prevents preference claims without declared evidence or no-probe reason.
CC-C31.ASAP-3Expected stable or improving structure and exception-growth risk are stated.Keeps the pattern about architecture structure rather than scale vocabulary.
CC-C31.ASAP-4Source-return condition is present when any compressed, coarse, extracted, indexed, or accounting representation drops source-side distinctions.Prevents unsafe coarse descriptions.
CC-C31.ASAP-5Waiver reason is one of deontic constraint, safety or law-domain boundary, scale-probe overturn, assurance infeasibility, or context-specific bounded exception.Prevents false debt labels.
CC-C31.ASAP-6ArchitectureHeuristicDebt remains report-only unless a decision, risk, work, evidence, assurance, or selected-set record is being used under its governing pattern.Prevents shadow project authority.
CC-C31.ASAP-7Platform, product-line, modularity, reuse, open-interface, RG, and coarse-graining labels do not establish scale preference by themselves.Blocks source-label overread.
CC-C31.ASAP-8Mathematical-lens claims name C.29 output fields; C.31.ASAP governs only the architecture scale-preference side.Keeps C.29 and C.31.ASAP distinct.
CC-C31.ASAP-9Comparison, selected-set, local choice, evidence, assurance, gate, work, or release claims name the governing pattern.Prevents scale preference from becoming selection or assurance.
CC-C31.ASAP-10SoTA rows mutate at least one solution line, checklist item, boundary, relation, or worked slice.Keeps source use non-decorative.
CC-C31.ASAP-11Project-local audit use names both projectWorkOccurrenceRef and architectureScaleAuditProjectUseRelationRef; a residue register remains retrieval-only unless its own governed direct relation to the exact composite Work is cited.Prevents an @Project suffix, work reference, or borrowed audit relation from fabricating locality.
CC-C31.ASAP-12When an ACS criterion row and an ASAP preference are both current, each is separately referenced and neither substitutes for the other.Keeps criterion admission and alternative preference distinct.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
ModularThereforeScalableThe text says modular or platform architecture scales without scale variable, window, slope evidence, or exception curve.Add ScaleClaimTriage or downgrade to C.31 characteristic cue.
GenericScaleAuditAudit fields appear with no architecture alternative set or preference use.Return to ScaleClaimTriage; remove audit apparatus until preference use is being made.
AllExceptionsAreDebtAny non-scale-amenable choice becomes debt.Test waiver reasons and keep justified bounded exceptions out of ArchitectureHeuristicDebt.
RGAsScaleProofCoarse-graining or RG wording is used as a scale-preference claim.Apply C.29 for lens use and C.31.ASAP for preference claim; require source-return condition.
ShareAsScalePreferenceEvidenceReusableStructureShare or BespokeResidueShare is used to prefer one alternative.Keep the share report-only in C.31.RSA until scale variable, window, and admissible comparison are declared.

Consequences

Positive consequenceCost or trade-off
Scale preference becomes inspectable before selection or decision.The practitioner must name a scale variable and window instead of relying on a label.
Platform and product-line claims gain usable refactor triggers.Some source language becomes only a recognition cue until variability slots and exception curves are declared.
C.29 lens use stays useful without turning into scale proof.RG claims and coarsening claims need preserved and lost structure plus source-return condition.
Report-only debt notes remain bounded.Decisions or risk records must use their governing patterns when reliance use is being made.

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

Source familySource-use relationC.31.ASAP contributionPractitioner use
Software product-line and variability-management practice (https://www.sei.cmu.edu/library/variability-in-software-product-lines/; https://arxiv.org/abs/2605.21353)Mature variability lineage plus current SPLE-review cues.Adopt variability slots, product-line reuse, exception inventory, and refactor triggers as architecture scale-preference fields.Treat a product-line label, shared code base, feature model, or platform name as a cue. Before preferring the product-line alternative, name the scale window, variability slots, exception curve, and source-return condition.
Product-platform and modular product-architecture practice (https://link.springer.com/article/10.1007/s00163-023-00427-1; https://arxiv.org/abs/2510.11089)Current engineering-design source line for modular product architecture, assembly orientation, product-family reuse, and manufacturing-aware modularity.Adopt the product-family commonality and variety trade-off as an architecture scale-preference pressure: reusable structure needs declared variation points, interface rules, assembly or realization constraints, exception curve, and source-return condition.Treat a product-platform name, common-module count, or modular-product label as a cue; establish any module-interface or manufacturing claim separately. Before preferring a product-platform alternative, state which product-family variation is scaled, which structure remains stable, and which assembly, safety, law-domain, or mission exception is allowed.
Platform-engineering maturity practice (https://tag-app-delivery.cncf.io/fr/whitepapers/platform-eng-maturity-model/)Current platform-practice source for platform service set, extension-rule, substitution-policy, and maturity-pressure claims.Adapt platform practice into extension-rule, substitution-policy, conformance-expectation, and exception-growth checks.Treat platform maturity as a source cue until the architecture scale variable and exception behavior are declared. Establish any architecture selection or reusable-structure claim through its own pattern.
C.19.1 BLP in FPFFPF-local preference discipline for general scale-amenable methods.Specialize the preference idea to architecture alternatives, selected structures, scale variables, and architecture slope vector.Use C.19.1 for method-family policy and C.31.ASAP for architecture scale preference; selector policy and decision records remain with their governing patterns.
C.29 RG and coarse-graining lens use in FPFFPF-local mathematical-lens discipline.Require scale window, coarse-graining rule, preserved structure, lost structure, and source-return condition when RG-like architecture scale reasoning is being claimed.Use MLU.Description@RGArchitecture or MLU.Description@MultilevelLearningFrustration only when the lens changes the next admissible use. Establish any physical-RG, scale-proof, causal-proof, assurance, or selected-architecture claim through its own source basis and governing pattern.

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, and C.29; uses A.1.1 only when a selected BoundedModelUseStructure changes the receiving interpretation.
  • Coordinates with: A.6.M for module-interface relation repair; C.30, C.30.ASV, C.30.LCA, and C.30.ILC for architecture and selected-structure questions; C.33, C.34, and C.35 when scale-amenability material needs captured-structure adequacy, lost-structure adequacy, preservation adequacy, correspondence adequacy, or generated-carrier adequacy before candidate use; C.32.P2S when scale-amenability pressure must continue through problem-to-structure architecturing; C.32.ACS when the pressure is represented as a distinct project criteria row; C.32 when scale preference informs candidate architecture generation; A.19.CPM when it supplies one input to explicit comparison; A.10, B.3, and G.6 for evidence and assurance reliance; G.5, G.9, and C.11 for selected-set, parity, and choice claims.
  • Boundary: C.31.ASAP governs architecture scale-preference claims. C.32.ACS governs criteria-set and criteria-row construction; A.19.CPM governs explicit comparison. C.31, C.31.RSA, C.29, C.18.1, C.19.1, G.5, G.9, and C.11 govern 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, or C.30.STRAT is 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:

"The functional structure is clear, but module allocation and placement change the trade-off."
"One platform proposal improves reuse and worsens evidence or control burden."
"A search or workshop produced options; which selected structures and architecture characteristics do they change?"
"We need a candidate palette with structurally different architecture configurations before choosing one."
"The architecture of the team or tool that changes the target holon no longer fits the target architecture."

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 obtaining ArchitectureRelation, its selected U.Structure, and any separate ArchitectureClaim; [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:

CandidateArchitecturePalette@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureSynthesisProjectUseRelationRef?: U.RelationRef resolving to the exact synthesis-use or work-use relation
  architectureQuestionCardRef?: C.30 ArchitectureQuestionCard@Project ref when that exact card is the intake
  describedHolonRef:
  architectureClaimRef?: C.30 ArchitectureClaimRef when a durable actual, candidate, required, desired, or expected claim is current
  currentArchitectureRelationRefs[]?: exact obtaining C.30 ArchitectureRelation refs only
  currentSelectedStructureRefs[]?: the U.Structure participants of those obtaining relations
  synthesisQuestion:
  intendedPaletteUse:
  claimScopeRef?: U.ClaimScope
  boundedModelUseStructureRef?: A.1.1 BoundedModelUseStructure, only when its organization changes synthesis
  architectureSynthesisFrameRef?:
  selectedStructureContributionRows:
    - structureKindRef:
      selectedStructureRef?:
      contributionToSynthesis:
      constraintOrAffordance:
      relationFunctionClaimRef:
      sourceReturnCondition?:
  architectureCharacteristicCriteriaSetRef?:
  architectureCharacteristicCriteriaRowRefs:
  qBundleRefs?:
  characteristicImprovementCycleRef?:
  architectureIdealityPressureRef?:
  scaleAmenabilityPolicyRef?:
  functionBearerFeasibilityRef?:
  candidateArchitectureConfigurations:
    - candidateId:
      candidateName:
      selectedStructureChanges:
        - structureKindRef:
          selectedStructureRef?:
          changeMade:
          relationFunctionClaimRef:
      affectedArchitectureCharacteristicRefs:
      affectedCriteriaRowRefs?:
      architectureCharacteristicEvalResultRefs?:
      qBundleRefs?:
      expectedArchitectureGain:
      knownArchitectureLoss:
      constraintFit:
      preservedStructure:
      lostOrHiddenStructure:
      sourceCueRefs?:
      sourceSideReferent?:
      sourceReturnCondition:
      nextUse:
  tradeoffFrontOrArchiveRef?:
  evolutionWindowRef:
  architectureInfluenceCorrespondenceRef?: C.32.CONWAY frame or exact pair-row ref
  paletteStopCondition:

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

ForceTension
Decision pressureTeams want one answer before the alternatives are explicit.
Candidate pluralitySeveral plausible variants may be useful for different reasons.
Source richnessSource cues can suggest candidate work without establishing the architecture claim.
Compression riskA short palette can hide source distinctions needed later.
Neighboring claim patternsFront, G.5 result declaration, publication availability, local choice, evidence, assurance, and decision claims are admissible only through patterns for the next questions after the architecture content is shaped.

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:

  1. 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.
  2. 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 through E.10.ROLE. For each required function, name at least one admissible bearer under the declared constraints.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

ArchitectureCharacteristicImprovementLoop@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureSynthesisProjectUseRelationRef?: U.RelationRef resolving to the exact synthesis-feedback or work-use relation
  describedHolonRef:
  currentArchitectureCharacteristicPressureRefs:
  architectureCharacteristicCriteriaSetRef?:
  architectureCharacteristicCriteriaRowRefs?:
  synthesisQuestion:
  candidatePaletteRef:
  architectureCharacteristicEvalResultRefs?:
  changedSelectedStructureRefs:
  improvementClaimPatternLocator: C.32.ACS | C.32.ACE | C.31 | C.25 | C.16 | C.16.P | C.31.ASAP | other pattern for the next question
  nextSynthesisQuestion?:
  sourceReturnCondition:
Synthesis positionTypical selected structureWhat it contributesFirst pattern for the next question
Functional demandFunctionalStructureA.6.F-recovered functional demands, dependencies, constraints, and candidate bearer pressure.[C.30.ASV](/generated/patterns/C.30.ASV), [A.6.F](/generated/patterns/A.6.F), C.30.TFS-REL when flow relation is current.
Constructive bearerModuleInterfaceStructure, material, manufacturing, or component relation.Candidate modules, interface grammar, substitutability, variation slots, and fabrication burden.[A.6.M](/generated/patterns/A.6.M), [C.31](/generated/patterns/C.31), [C.30.ASV](/generated/patterns/C.30.ASV).
Placement and localityPlacementDeploymentStructure or MaterialSpatialStructure.Location, latency, access, environment, maintenance, and source-return burden.[C.30.ASV](/generated/patterns/C.30.ASV), domain pattern when current.
Control and flowControlStructure and TransformationFlowStructure.Feedback, supervisor relation, rate, flow relation, crossing, and transformation relation.[C.30.LCA](/generated/patterns/C.30.LCA), [E.18](/generated/patterns/E.18), C.30.TFS-REL, [C.27](/generated/patterns/C.27) when timing is current.
Method, Work, local-kind or assignment, information, and evidenceMethod and Work structures; relations among local system-role kinds, classifications, or assignment structures; direct allocation or responsibility relations; information and evidence structures.Prospective enactment burden, independently established responsibility, data custody, evidence reuse, assurance pressure, and source return.[E.10.ROLE](/generated/patterns/E.10.ROLE) for unresolved wording; A.2 and A.2.1 for recovered kind, classification, or assignment; A.15 and F.6 only for actual Work; the admitted direct domain predicate or exact missing governor for responsibility; [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), [C.25](/generated/patterns/C.25), and [C.31](/generated/patterns/C.31) when those claims are current.

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.

Architecture-change kindConstructive useMinimum repair against overread
configurationSynthesisCoordinate several selected structures into one candidate architecture configuration.State the selected-structure contribution rows and architecture characteristics before claiming improvement.
functionalAllocationChangeChange the candidate A.6.F bearer or the module, Method, Work, local kind, separate System-classification judgment, assignment, control, or other structures that constrain its functioning.Keep the functional predicate and bearer distinct from every neighboring structure; unresolved “role” wording goes through [E.10.ROLE](/generated/patterns/E.10.ROLE).
functionBearerFeasibilityRepairRepair a candidate whose functional structure names a required function that no admitted bearer can bear under module, placement, resource, control, or evidence constraints.Add or change an A.6.F bearer, split the function, change placement or resource access, change the direct control or responsibility relation, reduce the functional demand, or reject the candidate.
functionBearerConsolidationTransfer a required function onto an existing selected structure, remove a support bearer, or propose one more general bearer for several functions.State the functions transferred, the bearer removed or generalized, the affected architecture characteristics, the lost options, and the BLP scale window or waiver when scale advantage is claimed.
structuralSubstitutionReplace one selected structure with another candidate structure.State what is preserved and what is lost.
relationRetargetingChange an affected relation endpoint, direct responsibility relation, system-role assignment, dependency relation, admissible-use boundary, or source-return relation.Name the relation kind and its actual predicate before using the change in a candidate; if a needed responsibility predicate is absent, record the exact missing governor.
architectureInfluenceCorrespondenceSynthesisCoordinate candidate structures when an independently typed architecture or other source constrains transformed-side architecture content for a changed referent.Open [C.32.CONWAY](/generated/patterns/C.32.CONWAY); name the changed referent and any independently grounded A.3.4 transformation separately; name each typed influence source by kind and its exact direct relation when an influence occurrence is asserted, otherwise keep the pressure synthesis-local with its missing-governor, unresolved-grounding, or false-predicate disposition; for each actual architecture side keep the exact C.30 holon, obtaining ArchitectureRelation, and selected U.Structure visible, and keep modal content in ArchitectureClaim; then prepare influence-source-side, transformed-side, joint, or bounded-mismatch candidates with affected architecture characteristics, expected gain, known loss, source-return condition, and pattern for the next question.
decompositionOrAllocationChangePropose reallocation of a module, future assignment condition, Work boundary, evidence relation, data custody, control relation, or variation slot across structures; retarget responsibility only through its direct domain predicate.State the proposed boundary, participant conditions, prospective object, and migration burden. Do not create an assignment or Work occurrence from candidate wording; return the exact missing governor when the needed responsibility relation has no current predicate.
placementOrDeploymentChangeChange locality, deployment, material placement, installation, or maintenance access.Name the affected structure and the latency, access, source-return, or environment burden.
flowOrControlVariantChange transformation flow, control depth, rate band, feedback boundary, or mediator relation.State the timing, control, observability, or accountability burden created by the change.
interfaceGrammarChangeNarrow, split, widen, or stabilize an interaction boundary.Apply [A.6.M](/generated/patterns/A.6.M) when module-interface relation repair is current.
declaredScopeOrHolonLevelChangeSplit, merge, add, or remove a declared holon-level reference, declared scope, evidence scope, work-method scope, or aggregation scope.Name the affected reference, use [C.30.STRAT](/generated/patterns/C.30.STRAT) when the wording is only a stratification term, and use [B.2](/generated/patterns/B.2) only when whole reidentification is current.
boundedExceptionKeep a residual because removing it costs more than it buys now.State the exception, reopen trigger, and next subject pattern if later source use or decision use expands.

Didactic mini-slices. Use these as examples of the kind of work C.32 expects, not as domain-specific templates.

SituationFirst C.32 stepCandidate repair
A sterilization function is placed in a shared field module, but the field placement has no power and no certified evidence relation for that heat cycle.Keep the functional demand separate from the module and placement structures.Add a local certified bearer, split the function into pre-field and field steps, change placement, or reject the shared-module candidate.
An ML functional graph includes retrieval, planning, and action, but no module-interface relation or direct domain predicate carries evidence-refresh responsibility or admissible-use control.Treat the graph as functional structure and recover module-interface, evidence, control, admitted-System, and responsibility relations separately.Add a retrieval service and an admitted evidence-refresh responsibility relation with actual participants, add a supervisor relation, narrow model-interface behavior, return the exact missing governor, or reject the candidate.
A Method family says the review function is automated, but A.6.F identifies no bearer and no direct responsibility predicate identifies who is responsible for exceptions.Recover the Method structure and A.6.F function bearer first. Keep any admitted Systems, local kinds, separate System-classification judgments, assignments, actual Work with its F.6 attribution, responsibility relation, and evidence structure separate.Propose an assignment condition only in truthful plan or candidate content; cite a direct exception-responsibility relation or exact missing governor; split the Method step, change evidence scope, or keep the automation as source cue. Use a full Work chain only after performance.

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.

Grounded working caseSynthesis questionC.32 candidate workStop condition
Regulated product family with growing field exceptionsHow should functions, module interfaces, placement, and evidence scope be configured so substitutability and certification burden stay acceptable?Prepare candidates that narrow interface grammar, split the family by evidence scope, change placement responsibility, or keep a bounded exception with source return.Stop at palette unless G.5 selected-set result declaration, publication availability, assurance, or architecture decision is current.
Built-asset digital-twin handover where a method-defined digital-twin view hides source lossWhich selected structures do the digital-twin dimensions actually describe, and which source-return obligations must survive maintenance use?Prepare candidates that split information view, add source-return scope, retarget maintenance responsibility, or change module and placement structure.Stop before built-asset architecture-description, MVPK publication-face, or A.10 evidence-relation claims unless C.30.AD.BA, E.17, E.24.PUB, or evidence patterns are current.
Emergency-department triage arrangement whose local desk is fast but hospital-wide escalation is brittleHow should admitted Systems, local system-role kinds or classifications, future assignment conditions, procedure and Method structure, control, direct responsibility, evidence, and any actual Work with its F.6 attribution be configured so speed does not erase escalation adequacy?Prepare candidates that retarget responsibility only through an admitted direct predicate, state a possible mediator assignment as plan or candidate content rather than an occurrence, split triage scope by patient class, or adjust evidence capture; use the exact missing governor when needed.Stop before ethical mediation, evidence, staffing decision, assignment occurrence, or performed Work unless those claims are current.
AI-agent review setup where local autonomy conflicts with policy scopeHow should control, module-interface, evidence-refresh, and work-method structures be configured so autonomy and policy conformance stay jointly acceptable?Prepare candidates that add supervisor relation, narrow model interface behavior, change evidence refresh cadence, or alter work-method responsibility.Stop before safety, release, gate, or causal claims unless their subject patterns are current.
Method family whose reusable template speeds authoring and slows reviewHow should Method structure, authored-section structure, review evidence, admitted Systems, possible future assignment conditions, and direct review-responsibility relations be configured so repeatability does not create hidden review residue?Prepare candidates that split Method variants, add review evidence scope, change a planned assignment condition, retarget responsibility through its direct predicate or record the exact missing governor, or accept bounded local Method residue.Stop before Method governance, curriculum decision, assignment occurrence, performed Work, description use, or publication-face use unless the pattern for the next question is current.

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.

LensLikely driftRepair
GovA candidate, front member, generated option, or workshop consensus is treated as selected, authorized, accepted, published, or current.Stop at the palette and use the pattern for the next claim; candidate wording creates none of those relations.
ArchOne visible structure, source diagram, functional graph, or organizational arrangement is treated as the architecture.Ground the exact holon and architecture question, then coordinate only the selected structures and characteristics that actually change the candidate.
Onto-EpistA description artifact, claim, model, role-shaped label, or proposed structure is treated as an obtaining architecture relation or world-side structure.Keep the holon, obtaining relations, selected structures, modal claim content, source artifact, and candidate change distinct; use each direct subject pattern.
PragThe palette becomes a dossier or exhaustive search although two to five useful alternatives would support the next use.Keep the smallest useful set of selected-structure contribution rows, keep one row per candidate, and add richer evidence only when it changes the next architecture use.
DidFormal records or software examples obscure the constructive move for another field.Lead with the ordinary move—structures changed, gain, loss, constraint fit, source return, next use—and use unlike grounded cases; keep the richer record optional.

Conformance Checklist

IDRequirementPurpose
CC-C32-1The use names one synthesis question, described holon, intended palette use, and the current architecture relations and selected structures that change the question; ClaimScope or a bounded model-use structure is added only when action-changing.Keeps the palette local without a generic context premise.
CC-C32-2The selected-structure contribution rows name the smallest useful set of selected structures and subject patterns and state what each contributes.Prevents one-structure optimization from masquerading as synthesis.
CC-C32-3Architecture characteristics and any quality bundles are named before candidate comparison.Keeps functional demand distinct from architecture trade-offs.
CC-C32-4Each candidate configuration names selected structure changes, expected gain, known loss, and constraint fit.Makes the candidate actionable.
CC-C32-5Compressed, generated, or view-derived candidates carry a source-return condition.Keeps later source-use or decision-use claims tied to recoverable sources.
CC-C32-6Archive, front, pool-treatment, G.5 result declaration, publication availability, local choice, and decision uses have named patterns for the next questions.Keeps synthesis separate from downstream receiving claims.
CC-C32-7Worked slices show what changes in practice across multiple selected structures.Keeps the pattern constructive.
CC-C32-8If an independently typed source constrains transformed-side architecture content for a changed referent, C.32.CONWAY is opened before Conway, mirroring, or inverse-Conway language is used as guidance; the source kind, its exact obtaining direct relation or precise provisional disposition, and both exact C.30 architecture sides or modal claims are named without inferring acting, Work, or transformation facts.Keeps influence-source and transformed-side content distinct while making correspondence synthesis constructive.

Common Anti-Patterns and How to Avoid Them

Architecture trade-off failures

Anti-patternRepair
Local structure win hides other-scope loss. A module split, control placement, evidence scope, or direct responsibility-relation change helps one concern while worsening another architecture characteristic.Rebuild the selected-structure contribution rows and record the gained and lost characteristics before comparison; do not infer responsibility from a team label or assignment.
Function and architecture characteristic collapse. The candidate is argued from user-visible function while evolvability, coupling, cohesion, latency, evidence burden, or another architecture characteristic remains unnamed.Recover the function through A.6.F or the structural-view pattern, then name the architecture characteristic separately.
Function without feasible bearer. A functional architecture, workflow, Method step, or searched graph asks for a function but A.6.F identifies no bearer that satisfies the functional predicate under the relevant module, resource, placement, control, evidence, local-kind, classification, or assignment constraints.Repair the bearer claim before admitting the candidate.
No real trade-off. Only one configuration is visible, or alternatives differ only by description.Generate structurally different candidates, or state why the project work is not architecture synthesis and use the subject pattern.
Description artifact stands in for candidate content. A diagram, ADR, view, dashboard, benchmark output, or digital-twin view is the visible work product, but the selected structures and architecture-characteristic trade-off are still missing.Keep the visible work product with its description-use, C.29 mathematical-lens, benchmark, publication, or source-use pattern and recover candidate content before C.32 use.
Front member treated as durable optimum. A front member, local winner, or benchmark leader is used as if the evolution window will stay fixed.Record evolution window, source-return condition, and retained alternatives under the exact C.18 or C.19 predicates; use G.5 only to declare a selected-set result from those alternatives. If the result is published, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability.
Software-source overfit. A software architecture source supplies a useful architecture-change idea, but the described holon is not a software system.Translate only the change over selected structures and characteristics; do not import the software ontology.
Architecture-influence source omitted. The candidate architecture for a changed referent cannot be built, tested, deployed, certified, or evolved under the current architecture, Work, communication, method, tool, deployment, evidence, selected-structure, or other source, but that source's exact kind and influence status are hidden.Open C.32.CONWAY; recover the source kind and either its exact obtaining direct relation or the precise provisional disposition, keep the acting System, any local system-role kind or assignment, Work, changed referent, and any actual transformation distinct, and prepare influence-source-side change, transformed-side change, joint change, and bounded mismatch as candidate alternatives or comparison inputs.
Method-defined dimensions lose their semantics. A BIM, digital-twin, or view-method dimension already carries method-defined structure, constraint, cost, schedule, use-phase, or maintenance semantics, but the synthesis text keeps only the dimension name or dimension count.Preserve the method semantics and map them to selected structures, constraints, characteristics, and source-return conditions.
Ideality shortcut. Fewer bearers, fewer modules, or one universal module is only a candidate direction until functions, architecture characteristics, scale window, safety, admissibility, and losses are named.Keep it as one candidate and expose those missing tests before comparison.

More repair cues

Repair cueSymptomFirst repair
SingleStructureSynthesisOne structure is optimized and the result is called the architecture.Write the selected-structure contribution rows and name the architecture characteristics before admitting the candidate as C.32 work.
UserFunctionAsArchitectureCharacteristicThe user-visible function is treated as the architecture quality being optimized.Recover the functional demand through A.6.F or C.30.ASV; then name the architecture characteristic or quality bundle separately.
FunctionNoFeasibleBearerA functional architecture names a required function, but no bearer satisfies the A.6.F predicate under the relevant System, module, Method, resource, placement, control, evidence, local-kind, classification, or assignment constraints.Repair with functionBearerFeasibilityRepair: add or change the bearer, split the function, change placement or resource access, change control relations, reduce the demand, or reject the candidate. A kind or assignment never becomes the bearer by form, and any responsibility claim remains a separate direct predicate or exact missing governor.
DescriptionFormAsArchitectureAn architecture-description artifact is treated as the architecture because it is the most visible representation.Keep the visible work product under C.30.AD, C.30.ASV, E.17, E.24.PUB, C.29, or source-use governance as applicable; recover described holon, selected structures, candidate architecture change, and characteristic bundle before admitting any C.32 candidate.
BenchmarkWinnerAsArchitectureA comparison result is treated as architecture selection.Treat the result as comparison input or as source material for an A.10 evidence relation when that claim is current; admit a C.32 candidate only after selected structure, architecture-change kind, gain, loss, and pattern for the next question are recovered.
MethodDimensionSemanticsLostA BIM, digital-twin, or architecture-view method supplies dimensions, but C.32 use keeps only the dimension name or dimension count and loses the method's structure, constraint, schedule, cost, use-phase, or maintenance semantics.Preserve the source method semantics, then map each method-declared dimension to selected structures, constraints, preserved and lost structure, architecture characteristics, and source-return condition.
ArchitectureInfluenceMismatchOne independently typed source is incompatible with transformed-side architecture content needed for the changed referent, or the source's influence status is still provisional.Open C.32.CONWAY; recover the changed referent, each source's exact kind and obtaining relation or precise provisional disposition, both exact C.30 architecture sides or modal claims, and any separately grounded acting, Work, method-side or direct method-use relation, A.3.4 transformation, or E.18 flow facts through their subject patterns; generate candidates that change the influence-source side, the transformed side, both sides, or a bounded mismatch. Use C.29 only if structural similarity is claimed.
ShortlistByNameA set is called shortlist before the result fields required by G.5 exist.Keep it as a local palette or open G.5.
UniversalBearerAsArchitectureA universal module, general substrate, or existing resource is treated as better architecture by name.Create a C.32 candidate that names functions transferred to the bearer, bearer count change, coupling change, evidence burden, control burden, safety and admissibility boundary, and BLP scale window or waiver if scale advantage is claimed.
SourceCompressionNoReturnA candidate hides source distinctions.Add a source-return condition or demote the item to a source cue.

Consequences

Positive consequenceCost or trade-off
Candidate architecture configurations are visible before local choice or decision.Losses and constraint fits must be named earlier.
Architecture-characteristic improvement is handled as iterative architecture work.Each iteration must say which characteristic pressure changed, which selected structures were changed, which reading or feedback is admissible as synthesis input, and what source-return condition opens the next synthesis question.
Multi-structure synthesis is reviewable.The practitioner must keep functions, modules, placement, control, work, evidence, and other selected structures distinct when they matter.
Architecture characteristics and quality bundles are recorded as comparison inputs for the pattern for the next question.The palette may need characteristic repair through C.25, C.31, C.16, or later comparison handling through A.19.CPM, C.11, A.19.SelectorMechanism, or G.5 when those claims are being made.
Holonic architecture breadth is preserved.Examples and candidates must name the described holon and selected structures instead of using domain defaults as unstated selected structures.
Source cues can inform architecture work without importing source-domain ontology.Source-side expressions require recovery of referent, selected structure, architecture-change kind, and source-return condition.
Downstream G.5 result declaration and architecture-decision work stay cleaner.The team must open the pattern for the next question when it wants to declare a selected-set result, publish it to an audience, make a local choice, or decide the project architecture.
Evolutionary and search practices are usable without hidden single-winner optimization.The palette may need retained alternatives even when one candidate looks convenient.

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 to inspectSource-use class and why it matters hereTransfer into C.32Where this contribution appears in C.32Blocked overread
Architecture synthesis and quality-attribute optimization: Di Pompeo and Tucci 2023 (https://arxiv.org/abs/2301.07516), ATRAF 2025 (https://arxiv.org/abs/2505.00688), and current FPF C.32.HCS, C.32.ACS, C.32.ACE, C.25, C.31, C.16Current comparison input plus current FPF authority: quality attributes and architecture characteristics compete, and multi-objective treatment gives the architect a trade-off view instead of one scalar winner.Adapt: make candidate configurations name ACS criteria rows and Q-Bundle slots before comparison, and use ACE evaluation results as feedback for the next synthesis question only through the pattern for that question.CandidateArchitecturePalette@Project includes architectureCharacteristicCriteriaSetRef?, architectureCharacteristicCriteriaRowRefs, qBundleRefs?, affectedCriteriaRowRefs?, architectureCharacteristicEvalResultRefs?, constraintFit, and tradeoffFrontOrArchiveRef?; Problem separates functional demand from architecture characteristics.A user function, metric, benchmark, scalarized score, evaluation result, or apparent improvement is not architecture synthesis, comparison, project architecture decision, or improvement-cycle closure.
DSM, multiple-domain matrix, and current DSM modularization research, including Jiang and Luo 2026 (https://arxiv.org/abs/2604.28018)Current research comparison with established DSM lineage: modularization is useful, while LLM-based DSM work also exposes divergence between functional priors and structural objectives.Adapt: use DSM or clustering as one candidate-generation and inspection source; recover selected structures, structural objective, and engineering semantics before treating the result as architecture-synthesis material.Solution adds selectedStructureContributionRows; candidate work coordinates functional, constructive, placement, control, work, information, and evidence structures rather than accepting a cluster as architecture.A cohesive cluster, graph partition, or generated modularization is not architecture adequacy by itself.
Current FPF architecture kernel: A.22, C.30, C.30.ASV, C.30.ILC, C.31, C.31.ASAP; architecture source section 15.3Current internal authority: obtaining architecture relations connect an exact described holon to selected structures for a named architecture question and use.Adopt: use SoTA and domain sources only after recovering described holon, synthesis question and use, current architecture relations, selected-structure contribution rows, architecture criteria rows, selected structure changes, gain, loss, and pattern for the next question.CandidateArchitecturePalette@Project requires selectedStructureContributionRows, architecture-characteristic criteria rows, selected structure changes, constraintFit, preserved and lost structure, source-return condition, and nextUse; worked cases cover heterogeneous holon kinds.Diagrams, source expressions, software-system templates, and platform proposals remain source cues until the described holon, selected structures, architecture criteria, gain, loss, and pattern for the next question are recovered.
ISO 42010:2022 architecture-description standard (https://www.iso.org/standard/74393.html)Current normative comparison: it distinguishes architecture, description, view, viewpoint, concern, correspondence, and model kind, while leaving architecture itself outside the standard's subject.Adopt narrowly: treat architecture-description artifacts as source cues or description material until a candidate selected-structure change is recovered.C.32 fields distinguish source cues, source-side referents, selected structures, and architecture characteristics. For description or view repair, use C.30.AD or C.30.ASV; for publication, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability.An architecture-description artifact or publication face is not a candidate architecture by itself.
Ford, Parsons, Kua, and Sadalage, Building Evolutionary Architectures, 2nd ed.; overview at https://evolutionaryarchitecture.com/ and O'Reilly page https://www.oreilly.com/library/view/building-evolutionary-architectures/9781492097532/Current practitioner comparison: guided incremental change makes affected architecture characteristics and feedback visible.Adapt: add reversible first steps where useful, affected criteria rows, ACE evaluation results, source-return triggers, a next synthesis question, and no source-term takeover.Solution and SoTA rows state that source-side fitness-function practice is represented through exact C.32.ACE evaluation-program assertions over ACS rows; candidate rows can name affectedCriteriaRowRefs?, architectureCharacteristicEvalResultRefs?, next synthesis question, and source-return condition; measurement claims use the exact C.16 predicate.Evaluation results need an exact comparison, local-choice, or other preference-use assertion before they affect preference or start the next synthesis iteration.
Shaw and Petre, Design Spaces and How Software Designers Use Them (https://arxiv.org/abs/2407.18502); Cortellessa, Diaz-Pace, Di Pompeo, Tucci, Towards Assessing Spread in Sets of Software Architecture Designs (https://arxiv.org/abs/2402.19171)Current research comparison: design-space work distinguishes structural alternatives from objective-space scores.Adapt: preserve a candidate palette when one scalar winner would hide structurally different alternatives; distinguish objective-space signals from selected-structure differences.Retain candidate plurality until G.5, C.11, or a C.32.PAD project architecture decision relation is current; each candidate must name selected structure, architecture-change kind, gain, loss, and hidden or preserved structure.A Pareto front, score, spread indicator, or generated set does not select the architecture and does not replace architecture-space inspection.
MOSA and open-system engineering from C.31.RSA (https://www.cto.mil/sea/mosa/; https://www.cto.mil/wp-content/uploads/2025/03/MOSA-Implementation-Guidebook-27Feb2025-Cleared.pdf); product-line variability and product-platform practice from C.31.RSA and C.31.ASAP (https://www.sei.cmu.edu/library/variability-in-software-product-lines/; https://arxiv.org/abs/2605.21353; https://link.springer.com/article/10.1007/s00163-023-00427-1; https://arxiv.org/abs/2510.11089); information-hiding lineage carried by C.31.RSACurrent standards and practice comparison plus information-hiding lineage: the sources expose interface conformance, substitution, variability, extension, exception, assembly, and hidden-change pressures.Adapt as candidate prompts: change the interface grammar, substitution policy, variation slot, evidence scope, exception boundary, or bearer only when the current architecture question needs it.C.32 adds interfaceGrammarChange, declaredScopeOrHolonLevelChange, and boundedException as architecture-change kinds; the product-family worked case prepares interface-grammar change, evidence-scope split, and bounded exception as candidate alternatives.Before a candidate is preferred, use C.31.RSA for reusable-structure accounting, scale preference to C.31.ASAP, interface grammar to A.6.M, comparison to C.16 or A.19, and selected-set or local-decision use to G.5 or C.11.
TRIZ ideality, Ideal Final Result, technical-system evolution regularities, and current FPF C.19.1 BLPHistorical heuristic lineage plus current FPF discipline: older ideality language suggests useful candidate moves; BLP supplies the current scale-amenability rule.Use as lineage and adapt only as a candidate prompt: transfer a function to an existing bearer, remove support bearers, use available resources, or try a more general bearer; judge the resulting candidate under current FPF rules.C.32 adds architectureIdealityPressureRef?, scaleAmenabilityPolicyRef?, and functionBearerConsolidation; repair cues require function-bearing, affected architecture characteristics, losses, scale window, and BLP scale window or waiver when scale advantage is claimed.An ideal-final-result slogan, fewer modules, or one universal module is not architecture adequacy, scale adequacy, or project architecture decision.
NAS survey line: Elsken, Metzen, and Hutter 2019 (https://www.jmlr.org/papers/v20/18-598.html); multi-objective differentiable NAS 2025 (https://arxiv.org/abs/2402.18213); hardware-aware NAS 2024 (https://arxiv.org/abs/2404.12403); Sutton's Bitter Lesson (https://www.incompleteideas.net/IncIdeas/BitterLesson.html) and scaling-law practiceCurrent ML research and practice comparison: functional graph search works under performance, resource, hardware, and transfer constraints.Adapt: treat functional architecture as one selected structure and require bearer feasibility across module, deployment, resource, control, information, and evidence structures before comparison.C.32 adds functionBearerFeasibilityRef?, functionBearerFeasibilityRepair, and didactic slices where a functional graph or method step fails because no bearer can carry it under current constraints.A neural cell graph, function graph, benchmark winner, or scale curve is not holonic architecture adequacy unless selected structures and bearers are recovered.
Conway's law, mirroring, DORA loosely coupled teams (https://dora.dev/capabilities/loosely-coupled-teams/), and Team Topologies key concepts (https://teamtopologies.com/key-concepts)Current practitioner comparison with historical lineage: these sources expose co-evolution and coordination pressure between organizational and technical structures without supplying a universal causal law.Adapt: treat team, Work, responsibility, Method, toolchain, deployment, communication, evidence, and selected structures through their exact kinds; assert a direct influence relation only when its predicate is satisfied. Use inverse Conway only to generate a candidate change to selected influence-source structures.C.32 adds architectureInfluenceCorrespondenceRef? and architectureInfluenceCorrespondenceSynthesis; use C.32.CONWAY for the synthesis-local frame or an exact pair row. Keep both architecture sides or modal claims, changed referent, any local system-role kind, classification or assignment, Work, module-interface, evidence, and mathematical-lens claims distinct.Influence-source change, transformed-side change, joint change, and bounded mismatch remain candidate alternatives or comparison inputs. Architecture influence alone establishes no acting System, Work, or actual transformation.
MAAD 2025 (https://arxiv.org/abs/2507.21382) and LLM-assisted ADD 2025 (https://arxiv.org/abs/2506.22688)Current research comparison: generated alternatives are practical, while the studies retain knowledge, trade-off, evaluation, and human-oversight limits.Adapt: use AI outputs to widen candidate space, then recover source-side referent, selected structure, architecture-change kind, gain, loss, source-return condition, and pattern for the next question before palette admission.C.32 Problem and Solution treat generated outputs as source cues; sourceCueRefs? and sourceSideReferent? prevent generated text from carrying an architecture-adequacy authority relation.A generated blueprint, evaluation report, benchmark, or agent consensus is not an authority relation for architecture adequacy, evidence sufficiency, assurance, gate passage, or decision.

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.30 for the exact described holon, obtaining ArchitectureRelation occurrences, their selected U.Structure participants, and separately identified ArchitectureClaim content; 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.ILC when a residual starts the candidate work; C.32.MLAO when residual-reducing multilevel framing is being used; C.32.CONWAY when exact influence-source and transformed-side architecture content must be co-synthesized without inferring acting, Work, or transformation facts; C.32.FAIL when a candidate needs repair before explicit comparison, selection, local choice, or decision; C.32.ACE when candidate eval results are needed before later comparison or selection; C.33 when a source, description, view, decision record, eval report, handoff, or realized observation captures only part of selected structure; C.34 when candidate or source structures need preservation adequacy or correspondence adequacy; C.35 when generated or discovered carriers need admission support before candidate palette use; C.29 when mathematical-lens use is being claimed.
  • Patterns for the next questions: A.19.CPM for explicit comparison claims, A.19.SelectorMechanism for set-returning selection claims, G.5 for selected-set result declaration, C.18 and C.19 for archive, front, or pool-treatment policy, C.11 for fixed local choice, C.30.AD for architecture-description work, E.17 for a source-backed publication face and source return, E.24.PUB for the publication occurrence and audience availability, and C.32.PAD for project architecture decisions.
  • P2S docking: C.32.P2S uses 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.MWA when 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.

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.

ProblemToStructureArchitecturingFlowCard@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to an individual admitted under U.Work
  architecturingFlowCardProjectUseRelationRef?: U.RelationRef whose predicate is stated in the cited architecturing-use or work-use pattern
  flowId:
  describedHolonRef:
  architectureQuestion:
  intendedArchitectureUse:
  claimScopeRef?: U.ClaimScope
  qualificationWindowRef?:
  transformationFlowStructureRef?: exact independently selected E.18 structure used by this flow
  architectingSystemRef?: U.EntityRef constrained to U.System
  architectingAssignmentSpeciesRef?: U.RelationKindRef constrained under U.SystemRoleAssignment
  architectingSystemRoleAssignmentRef?: U.RelationRef constrained to U.SystemRoleAssignment, naming the obtaining occurrence when an assignment claim is current

  firstPatternLocator:
  problemPressure:
    acceptedProblemCardRef?: U.EpistemeRef resolving to one exact C.22.2 ProblemCard
    actualProblematicForRelationRef?: U.RelationRef resolving to one exact C.22.PFR occurrence, only when an actual Problem is independently current

    pressureKind:
    problemPressureSignalRefs?:
    sourceUseRecordRefs?:
    architectureConcernRefs?:
    currentStopOrReturnReason?:
  architectureContent:
    architectureQuestionCardRef?: U.EpistemeRef resolving to one exact C.30 ArchitectureQuestionCard@Project
    architectureClaimRefs[]?: exact C.30 ArchitectureClaimRefs
    currentArchitectureRelationRefs[]?: exact obtaining C.30 ArchitectureRelation refs

    candidateStructureKindRefs:
    selectedStructureRefs?:
    expectedStructureRefs?:
    actualStructureRefs?:
    architectureCharacteristicRefs:
    architectureCharacteristicCriteriaSetRef?:
    qBundleRefs?:
    candidateSynthesisRef?:
  structuralInformation:
    unknownStructure:
    selectedStructure:
    expectedStructure:
    actualStructure:
    capturedInDescriptionsOrDecisions:
    handedToMethodsOrWork:
    latentOrHiddenStructure:
    lostStructure:
    strongerStructureInspectionReturnCondition:
  decisionAndWorkDocking:
    candidateSetOrPaletteRef?:
    selectedSetRef?:
    architectureDecisionRef?:
    adrProjectionRef?:
    methodDescriptionRefs?:
    workPlanRefs?:
    readinessRefs?:
    performedWorkRefs?: refs to independently identified U.Work occurrences when performance is current
    performedWorkAttributionRefs?: refs to obtaining F.6 performedUnderAssignment relations only when the flow or receiving use expressly represents attribution

    actualTransformationRefs?:
    workToChangeRelationRefs?: Work-to-change relations that actually obtain
    workToChangeRuleRefs?: refs to applicable rules in the cited patterns, or to local claims selected under A.6.RCD disposition 2
    productionWorkClaimRefs?:
    entityIdentityInceptionClaimRefs?:
    productionCompletionClaimRefs?:
  architectureInfluenceCorrespondence?:
    changedReferentRef:
    actualTransformationRef?: U.EntityRef constrained to U.Transformation, only when independently grounded under A.3.4
    influenceSourceRows[]?: asserted influence facts only
      influenceSourceRef:
      influenceSourceKindRef:
      exactInfluenceRelationRef: U.RelationRef to a relation that actually obtains and has a declared predicate
      influencePatternLocator:
    influenceSourceArchitectureMaps[]?:
      influenceSourceHolonRef:
      influenceSourceArchitectureRelationRef?: exact obtaining C.30 ArchitectureRelation ref
      influenceSourceArchitectureClaimRef?: exact C.30 ArchitectureClaimRef for modal content
      influenceSourceSelectedStructureRefs:
    transformedHolonRef:
    transformedArchitectureRelationRef?: exact obtaining C.30 ArchitectureRelation ref
    transformedArchitectureClaimRef?: exact C.30 ArchitectureClaimRef for modal content
    transformedSelectedStructureRefs:
    correspondenceFrameOrPairRowRef: C.32.CONWAY synthesis-local frame or exact pair-row ref
  feedback:
    evalProgramRefs?:
    evalResultRefs?:
    actualStructureDescriptionRefs?:
    measurementRefs?:
    operationOrUseObservationRefs?:
    functionalCharacteristicImplications?:
    freshnessOrDecaySignalRefs?:
    returnOrRepairForNextQuestion:
      c32NextSynthesisExit?
      c32PadOrAdaDecisionRepairOrSupersessionExit?
      e23ImprovementCycleRef?
      g11CurrentnessRefreshRef?
      e18TransformationFlowRefreshRef?
      c18C19ArchiveFrontPoolUpdateRef?
      c30DescriptionOrViewLossRepairRef?
  patternForNextClaim:

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

ForceTension
Structure-first architectureArchitecture uses obtaining relations between an exact described holon and selected structures for a named architecture question and use; the flow is not reducible to documents, labels, stages, tools, or a generic context participant.
Structural uncertaintyArchitecturing often starts before structure kinds, bearers, interfaces, allocations, or variation points are known.
Characteristic trade-offArchitecture characteristics compete; optimizing one can damage another or hide Goodhart pressure behind a metric.
Candidate pluralityUseful architecture work keeps structurally different alternatives alive until comparison, selected-set, local choice, or architecture decision becomes the current question.
Realization gapSelected and expected structures do not become actual structures by decision, model, description, or matching labels. Before claiming an actual structure, establish the domain work, actual changes, work-to-change facts, and the facts that make the subject-side structure obtain.
Architecture-influence constraintOne typed Work, communication, tool, method, deployment, evidence, selected-structure, or architecture-side source can enable or block the transformed-side architecture content needed for the changed referent without thereby becoming an actor or transformation participant.
Description lossViews, descriptions, decision records, method descriptions, and eval reports capture only part of the structural content needed for later use.
Evolution and feedbackOperation, use, telemetry, inspection, evaluation, decay, and new sources can reveal the next question. The practitioner then uses the matching pattern: C.32 for synthesis, C.32.PAD or C.32.ADA for repair or supersession, E.23 for improvement, G.11 for currentness refresh, E.18 for transformation-flow slice-local refresh, C.18 or C.19 for archive, front, and pool update, or C.30.AD or C.30.ASV for architecture-description or structural-view loss.

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.

  1. 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 ProblemCard episteme when it becomes the accepted input. If an actual Problem is claimed, cite an independently obtaining C.22.PFR ProblematicForRelation; 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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 through E.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.
  6. 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.CPM for explicit comparison, A.19.SelectorMechanism for set-returning selection, C.18 and C.19 for archive, front, and pool policy, G.5 for selected-set result declaration, and C.11 for a fixed local choice. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability.
  7. Make a project architecture decision through C.32.PAD when 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.
  8. 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, and E.24.PUB as applicable.
  9. 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. Add performedWorkAttributionRefs only 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.
  10. 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. Use A.15.1 for each dated work occurrence and A.3.4 for 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 under A.6.RCD disposition 2. Use separate local A.15.PROD claims 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.
  11. Observe, inspect, measure, and evaluate subject-side U.Structure values whose declared substrate and selected relation organization are recovered under A.22 from 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. Use C.30 to name an obtaining ArchitectureRelation only when its exact holon, selected-structure participant, and predicate are satisfied; keep candidate, required, desired, expected, negative, or unresolved architecture content in an exact ArchitectureClaim. Use C.30.AD or C.30.ASV for actual-structure descriptions or views, C.32.ACE for eval programs and eval results, C.16 for measurement, and C.25 for Q-bundles. Use E.23 when repeated improvement method is current, G.11 when currentness, telemetry, edition, freshness, or decay orchestration is current, E.18 for transformation-flow slice-local refresh, C.18 or C.19 for archive, front, and pool updates, C.32.PAD or C.32.ADA for decision repair or supersession, C.32 for new synthesis, and C.30.AD or C.30.ASV for 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.

P2SUnfoldingStructureBlock:
  unfoldingStructureRef: U.StructureRef resolving to the selected CGUS or local architecture-facing structure block
  problemPressureRef: U.EpistemeRef resolving to a C.22.2 ProblemCard or another architecture-pressure episteme whose claim has been checked with the cited pattern
  selectedOrUnknownStructureRefs[]:
  architectureContentLoci[]:
  structuralUncertaintyLoci[]:
  candidateSynthesisLoci[]:
  decisionLinkageRef?:
  realizationWorkLinkageRef?:
  actualTransformationRefs[]?:
  workToChangeRelationRefs[]?: Work-to-change relations that actually obtain
  workToChangeRuleRefs[]?: refs to applicable rules in the cited patterns, or to local claims selected under A.6.RCD disposition 2
  productionWorkClaimRefs[]?:
  entityIdentityInceptionClaimRefs[]?:
  productionCompletionClaimRefs[]?:
  actualStructureFeedbackRef?:
  e18TransformationFlowUnfoldingRefs[]?:
  descriptionRefs[]?:
  nextReceivingAction: next action supported by the problem-to-structure result; apply a decision, description, Work, transformation, production, or feedback pattern when its claim is current
  stopOrReturnCondition: reopen when the problem, constraints, candidate structure, or actual feedback changes
  blockedOverread?: include only when F.19's plausible-reader test justifies this exact blocked reading

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.

ArchitectureUnfoldingStructureUse@Project:
  kind: dependent architecture-use relation record under C.32.P2S, C.30, and adjacent architecture patterns
  projectWorkOccurrenceRef: U.EntityRef constrained to the exact composite U.Work that is an explicit participant in this use relation
  architectureQuestionCardRef?: U.EpistemeRef resolving to one exact C.30 ArchitectureQuestionCard@Project
  architectureBearingHolonRef: U.EntityRef resolving to the exact described holon
  architectureRelationRefs[]?: exact obtaining C.30 ArchitectureRelation refs
  architectureClaimRefs[]?: exact C.30 ArchitectureClaimRefs for affirmative, negative, unresolved, candidate, required, desired, or expected content
  unfoldingStructureRef:
  architectureStructureUseKind:
    transformationFlow |
    methodWork |
    control |
    narrativePublication |
    evidenceAssurance |
    referenceCurrentnessRefresh |
    otherDeclared
  architectureViewpointRef?:
  affectedSelectedStructures[]:
  architectureCharacteristicRefs[]:
  acceptedLosses[]:
  methodOrWorkLinkageRefs[]?:
  architectureDecisionRef?:
  architectureDescriptionRefs[]?:
  architectureUseReturnCondition:
  repairOrSupersessionCondition:

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.

Pressure cue or source-practice rowRisk in P2S useRepair
Description-first pressure cueA view, model, diagram, ADR-like record, dashboard, or memo starts to carry architecture, decision, and work authority at once.Recover selected structures and current use. Use C.30.AD or C.30.ASV for description adequacy, C.32.PAD for decisions, C.32.ADR for projections, and A.15-family patterns for work claims.
Single-winner pressure cueA score, workshop favorite, generated candidate, or apparent best alternative hides structurally different candidates.Restore candidate plurality through C.32; keep archive, front, pool, selected-set, comparison, local-choice, or decision use with its applicable pattern.
Eval-shaped practice row or signalA metric, benchmark, source-practice fitness-function term, eval result, or telemetry event is treated as the characteristic or the decision.Recover characteristic, bearer, scale, eval program, measurement, and receiving use. Use C.32.ACE, C.16, C.25, and then the applicable comparison, selected-set, local-choice, or decision pattern.
Architecture-influence basis hiddenDesired transformed-side architecture content is stated without asking which typed Work, communication, tool, method, deployment, evidence, selected-structure, or architecture-side source constrains it.Open C.32.CONWAY; keep the changed referent and any actual transformation separate, recover both exact C.30 architecture sides or their modal claims, name every influence source by kind and either its exact obtaining direct relation or precise provisional disposition, and prepare influence-source-side, transformed-side, joint, and bounded-mismatch candidates.
Work-shaped pressure cueA schedule, task list, method recipe, performed-work record, shared assembly occurrence, or completion label is treated as the architecturing flow, an actual transformation, a composite transformation, or proof that selected structure is actual.Keep the A.15-family distinctions intact. The P2S card may cite Work occurrences, independently grounded changes, Work-to-change relations and their rules, separate local A.15.PROD claims, and actual-structure facts only when they obtain; common work or chronology supplies none of the stronger claims.

Conformance Checklist

CheckPass condition
CC-C32P2S-1The card names the exact problem claim or pressure, described holon, architecture question and intended use, first pattern to use, and at least one architecture-relevant structure or unknown-structure slot; scope, window, and selected transformation-flow structure are named only when material.
CC-C32P2S-2Each architecture use keeps the exact described holon, obtaining C.30 ArchitectureRelation occurrences and their selected-structure participants, and any affirmative, negative, unresolved, candidate, required, desired, or expected ArchitectureClaim content separate; no description or publication record carries the architecture by itself.
CC-C32P2S-3Architecture characteristics are separate from functional demands, measurements, eval programs, eval results, Q-bundles, comparison rules, and decisions.
CC-C32P2S-4The structural-information slots in the P2S card record unknown, selected, expected, actual, captured, handed-off, latent or hidden, lost, and returned structure when those slots are live.
CC-C32P2S-5Use C.32 for candidate synthesis and the applicable patterns for comparison and selection. The P2S card does not choose a winner by score or prose preference.
CC-C32P2S-6When a project architecture decision is current, use C.32.PAD; for an ADR-like publication, use C.32.ADR and the applicable publication patterns.
CC-C32P2S-7Use A.15-family patterns for Method, MethodDescription, work-plan, readiness, and performed-work claims. Identify every actual transformation under A.3.4. For every claimed Work-to-change link, cite the relation and the pattern or local A.6.RCD claim used to check it. Keep production-work, entity-identity-inception, and production-completion as separate local A.15.PROD claims. The P2S card carries refs and expected structure effects only.
CC-C32P2S-8For measurement, Q-bundle, mathematical-lens, eval, improvement, G.11 currentness refresh, and E.18 transformation-flow slice-local refresh claims, use C.16, C.25, C.29, C.32.ACE, E.23, G.11, or E.18 as applicable.
CC-C32P2S-9Architecture-influence cases keep the changed referent, any actual A.3.4 transformation, both exact C.30 architecture sides or modal claims, every influence source's exact kind and obtaining direct relation or precise provisional disposition, and the C.32.CONWAY synthesis-local frame or exact pair row separately recoverable.
CC-C32P2S-10The pattern use covers at least one actual-structure feedback route that checks subject-side U.Structure values recovered under A.22 from obtaining relation occurrences, applied constraints, invariants, or other selected-organization facts. It also checks architecture-characteristic results and relevant functional-characteristic or capability implications through operation, use, inspection, measurement, eval result, telemetry, decay, stronger-structure inspection return, or decision-repair trigger.
CC-C32P2S-11Selected and expected structures, methods, plans, models, decisions, descriptions, evaluation results, publications, and transfers remain distinct from actual structures and actual transformations. Resemblance does not establish conformance. Shared work, adjacency, common referents, or one flow establishes neither transformation composition nor partlessness.
CC-C32P2S-12The PumpSkid 7 replay independently identifies mounting, wiring, connection, and commissioning-related changes; cites exact assembly and commissioning work plus the work-to-change relations and their declared predicates; separates entity-identity inception from later historically indexed production completion; and routes actual-structure description, architecture-characteristic evaluation, and return without fabricating conformance or one composite transformation.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
Description stopThe project stops after producing a view set, diagram, ADR-like record, or architecture description even though no candidate structure, decision, realization, or feedback path is recoverable.Return to step 2 or 5. Name selected or unknown structures, architecture characteristics, and the next pattern to use: C.30, C.30.ASV, C.32, or C.32.PAD.
Relation index P2SThe P2S artifact lists neighboring patterns but does not tell the architect what to do from pressure to subject-side actual structures recovered from facts that actually obtain.Write the P2S method's positive Plain action sequence in the card: pressure, structural uncertainty, candidates, retention or selection, decision, descriptions, method and work handoff, Work, actual changes, subject-side actual structures, feedback, and a return selected for the next question.
Eval-as-decisionAn eval result, score, metric, telemetry event, or dashboard value selects the architecture.Use C.32.ACE for the eval, C.16 for measurement, and C.25 for composite quality; ask what selected structure, accepted loss, counter-characteristic, or functional implication worsened; then use comparison, selected-set, local-choice, or C.32.PAD if selection or decision is current.
Hidden architecture-influence basisThe transformed-side candidate is designed as if no typed Work, communication, tool, method, deployment, evidence, selected-structure, or architecture-side source constrains it.Open the architecture-influence branch and C.32.CONWAY; recover every source's exact kind and obtaining direct relation or precise provisional disposition, then add candidate families that change the influence-source side, transformed side, both, or a bounded mismatch while keeping actor, Work, changed-referent, and transformation facts separate.
Lost structure left silentThe description, decision, method handoff, or eval report compresses away distinctions needed for later work.Fill the P2S structural-information slots: what is captured, handed off, latent or hidden, lost, and what stronger-structure inspection return condition restores the selected or expected structure needed by the next claim.
Work-pattern takeoverP2S prose starts authorizing Work occurrences or replacing method, readiness, WorkPlan, or separate assertion or record epistemes about performed work.Keep P2S as architecture carry-through. Use A.15-family patterns for method and work claims and keep in the P2S card only references plus expected selected-structure effects.
Selected structure treated as actualA decision, model, description, view, evaluation result, or matching label is used as proof that the selected structure obtains.Recover the subject-side U.Structure under A.22 from its declared substrate and obtaining relation occurrences, applied constraints, invariants, or other selected-organization facts. Use C.30 ArchitectureRelation only when its holon and selected-structure participants satisfy the obtaining predicate; keep modal content in ArchitectureClaim. Keep descriptions and evaluations separate, and use the relevant patterns to test conformance.
Common work treated as one composite transformationMounting, wiring, connection, or commissioning changes are merged because one assembly work occurrence, selected configuration, or time interval contains them.Identify every actual transformation independently under A.3.4; cite direct work-to-change facts; return the exact missing-governor blocker if the receiving claim needs transformation composition.

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 source to inspectWhy this source is load-bearing hereAdopt, adapt, or reject dispositionTransfer into C.32.P2SBlocked overread
ISO/IEC/IEEE 42010:2022 architecture-description standard (https://www.iso.org/standard/74393.html)Current architecture-description practice separates architecture, description, concern, viewpoint, view, model kind, and correspondence.Adopt the separation of architecture and description; adapt it through the exact description, view, ADR, and publication predicates located in C.30.AD, C.30.ASV, C.32.ADR, E.17, and E.24.PUB; reject any takeover of FPF holon and selected-structure ontology.P2S step 8 and CC-C32P2S-2 keep descriptions, views, and ADR-like records as captured structural content or publication forms with exact neighboring subject assertions.A description, view, diagram, or publication carrier is not the architecture, the project architecture decision, or performed work.
Ford, Parsons, Kua, and Sadalage, Building Evolutionary Architectures, 2nd ed. (https://www.oreilly.com/library/view/building-evolutionary-architectures/9781492097532/)Best current practitioner line for guided incremental change over declared architecture characteristics with feedback from eval practice.Adopt guided evolutionary change and feedback; adapt source-practice fitness-function practice into C.32.ACE eval programs and C.16 measurement over C.32.ACS rows; reject treating eval success as a decision.P2S step 11, the eval-shaped practice row, and CC-C32P2S-8 require architecture characteristics, eval exits, feedback, stronger-structure inspection return, and next-action triggers selected for the current question rather than one-time design settlement.A source-practice fitness-function name, metric, or passing eval result is not the architecture characteristic, decision, or proof of realized structure.
Richards and Ford, Fundamentals of Software Architecture, 2nd ed. (https://www.oreilly.com/library/view/fundamentals-of-software/9781098175504/) and Ford et al., Software Architecture: The Hard Parts (https://www.oreilly.com/library/view/software-architecture-the/9781492086888/)Current practitioner sources for architecture characteristics, trade-offs, risk, coupling, cohesion, and difficult architecture decisions.Adopt characteristic and trade-off discipline; adapt software-system examples to holons and selected structures; reject software-only module reduction.P2S steps 2, 7, and 11 plus CC-C32P2S-3 separate functional demand from architecture characteristics, require accepted-loss visibility, and feed realized functional implications back without confusing kinds.A list of qualities, trade-off discussion, or rationale text is not candidate synthesis or decision adequacy by itself.
Architecture synthesis and multi-objective quality-attribute optimization, including Di Pompeo and Tucci 2023 (https://arxiv.org/abs/2301.07516) and ATRAF 2025 (https://arxiv.org/abs/2505.00688)Current research line for competing quality attributes, multi-objective trade-offs, and architecture candidate evaluation.Adopt candidate plurality and trade-off front inspection. Use the FPF patterns that define comparison, selected-set result declaration, local choice, and decision; reject a scalar score or generated winner as sufficient grounds for selection.P2S steps 5 and 6, the single-winner pressure-cue row, and CC-C32P2S-5 keep candidate plurality and require explicit comparison, selection, selected-set result declaration, local choice, and decision predicates after C.32 candidate synthesis; publication remains a separate sequence.A Pareto front, scalar score, optimization run, or generated winner does not select the architecture.
DSM, multiple-domain matrix, modularization, and dependency-structure practice; inherited C.32 source-anchor row for Jiang and Luo 2026 (https://arxiv.org/abs/2604.28018), epiplexity structural-information line (https://arxiv.org/abs/2601.03220), and C.31.RSA structure-accounting rowsStrong engineering-design line for inspecting dependency, coupling, modularity, learnable structural content, and structural loss; the inherited C.32 row also warns that functional priors and structural modularization objectives can diverge.Adopt DSM, MDM, and epiplexity as structure-inspection lenses; adapt them through C.29 lens refs and structural-information slots; reject matrix, cluster, compression, or epiplexity result as architecture adequacy.P2S steps 3 and 5 and CC-C32P2S-4 let the card cite DSM, MDM, graph, epiplexity, coarse-graining, equivalence, or morphism claims while recording preserved and lost structure.A cluster, matrix, graph, compression, or epiplexity result is not architecture adequacy or a decision without recovered selected structures and a route to the next applicable pattern.
Conway correspondence, mirroring, DORA loosely coupled teams (https://dora.dev/capabilities/loosely-coupled-teams/), and Team Topologies (https://teamtopologies.com/key-concepts)Current socio-technical architecture practice shows that typed Work, communication, tool, method, deployment, evidence, selected-structure, or architecture-side sources can enable or block transformed-side architecture content and independent change.Adopt co-synthesis of the influence-source and transformed sides; adapt through C.32.CONWAY; reject organization labels, communication diagrams, architecture relations, claims, or structures as acting Systems or direct transformation participants.The P2S architecture-influence branch, Show C, and CC-C32P2S-9 require exact C.30 architecture sides or modal claims, an independently typed influence source and direct relation, the changed referent, and any actual A.3.4 transformation as separate objects.Organization labels, team diagrams, or communication patterns do not settle transformed-side architecture content, acting identity, Work attribution, or transformation participation; they enter only through their exact kinds and direct relations.
NASA Systems Engineering Handbook decision and trade-study practice (https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf), Michael Nygard's ADR practice (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions), MADR 4.x (https://adr.github.io/madr/), and C.32.ADR source-anchor rowsNon-software domains often publish architecture choices as trade studies, engineering memos, review records, or certification rationale rather than Markdown ADR files; ADR practice supplies compact status, context, decision, options, consequences, links, and update conditions.Adopt record-function discipline; adapt carrier form to project domain through the predicates and publication forms defined in C.32.ADR, E.17, and E.24.PUB; reject ADR file form as mandatory or authoritative by itself.P2S step 8 and the Relations boundary treat decision records by section function and reader use: project architecture decisions require an exact C.32.PAD assertion, while record projection uses the C.32.ADR description.ADR file form is not mandatory and does not create a second decision authority.
FPF C.18, C.19, E.23, and G.11 with NQD, OEE, improvement, telemetry, freshness, and decay practiceModern architecturing happens under evolution; retained alternatives, stepping stones, feedback, and decay affect the next synthesis question.Adopt archive, front, pool, improvement, telemetry, freshness, and decay distinctions; adapt them as exits to the next applicable pattern; reject G.11 refresh state or archive state as architecture choice.P2S steps 6 and 11 record archive, front, and pool refs, improvement-loop refs, telemetry, actual-structure observations, decay, stronger-structure inspection return, and return or repair refs selected for the next question without merging the meanings defined by their patterns.Archive membership, improvement-loop status, telemetry, or freshness signal does not decide architecture by itself.

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.1 and A.1.SCR for an existing system boundary, A.15.6 for project system-of-interest designation and intended-system separation, A.1.STM when the missing outside-to-inside dependency must be located, C.22.2 for problem-side recovery, C.30, C.30.AD, and C.30.ASV for grounded architecture, architecture-description adequacy, and structural-view adequacy, C.33, C.34, and C.35 for structural-information capture, preservation, and generated or discovered carrier adequacy inside the flow, C.32 for candidate architecture synthesis, C.32.HCS, C.32.ACS, and C.32.ACE for characteristic starter heads, project criteria rows, and eval programs, C.25 for Q-bundles, C.31 family patterns for modularity, reusable structure, and scale preference, C.29 for mathematical-lens use when claimed, E.17 for a source-backed publication face and source return, and E.24.PUB for the publication occurrence and audience availability.
  • Uses: A.22.CGUS for 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, and A.3.4 when architecture pressure concerns transformation-flow or bounded change; C.30.ILC, C.32.MLAO, and B.2 family patterns when cross-scope, interlevel, interlayer, meta-holon, emergence, or reidentification pressure changes the candidate frame; C.32.CONWAY when co-synthesis of exact influence-source and transformed-side architecture content is current; C.32.FAIL when 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, and C.11 for comparison, selection, archive, front, pool policy, selected-set result declaration, and local choice; C.32.PAD, C.32.ADR, and C.32.ADA for project architecture decision, ADR-like projection, and decision adequacy; C.30.AD for architecture descriptions; A.6.3.NAR for architecture-mediated narrative renderings; E.17 for source-backed publication faces and source return; E.24.PUB for publication occurrences and audience availability; A.15, A.15.1, A.15.2, and A.15.5 for method, performed work, work plan, and readiness; A.3.4 for each actual bounded change; the pattern for the predicate, or A.6.RCD, for Work-to-change claims and blockers; A.15.PROD for separate local production-work, entity-identity-inception, and production-completion claims; C.16, C.25, C.29, C.32.ACE, E.23, G.11, and E.18 for 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.22 from obtaining facts, and then to feedback. C.33, C.34, and C.35 deepen 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.

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:

"The source catalogue has hundreds of quality names; which few heads should we inspect first?"
"The source calls this a review practice or method; what described holon, method-side structure, work family, and system-role side are actually under pressure?"
"A system-role assignment, organization, built asset, or evidence workflow has reliability-like pressure, but the bearer and scale are unclear."

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:

ArchitectureBearingFamilyCharacteristicStarterPack@FPF:
  architectureBearingFamilyRef:
  describedHolonRef?:
  presentationCarrierRef?:
  starterPackUse:
  recoveryPatternRefs?:
  typicalSelectedStructureRefs:
  starterCharacteristicHeads:
    - architectureCharacteristicHead:
      usualBearerOrSelectedStructureRefs:
      likelyQBundleBoundary?:
      firstProjectQuestion:
      usualNextQuestionPatternRef:
  nonUniversalCaution:
  criteriaRowPatternRef: C.32.ACS

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

ForceTension
Broad cataloguesStandards, textbooks, and local sources offer many possible quality names.
Project attentionA project needs a small first set of draft criteria rows, not a catalogue.
Bearer recoveryThe same head can recur across admitted holon families and adjacent structures, but the family, bearer, scale, and any needed source-label recovery can change.
Software-source overfitMature software sources are useful but overfit to code modules, services, and operations if copied.
Q-Bundle boundaryMany -ility heads are composite quality families, not one architecture characteristic.

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:

  1. 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.
  2. List a small set of starter characteristic heads that often matter for that family.
  3. For each head, name likely bearers or selected structures, not only a quality word.
  4. Record likely C.25 Q-Bundle boundaries when a head is usually composite.
  5. State a first project question that helps the practitioner decide whether the head belongs as a draft row in the project criteria set.
  6. Hand the resulting starter heads to C.32.ACS; do not optimize or measure inside HCS.

Built-in starter packs

Architecture-bearing family or recovered source labelTypical selected structuresStarter heads to inspect firstLikely C.25 boundary
Engineered system, product family, or built assetmodule, component, placement, deployment, maintenance access, control, information, evidence, manufacture, operationreliability, availability, maintainability, safety, latency, locality, access, substitutability, evidence reuse, source-return cost, scale amenabilityavailability, safety, maintainability, resilience, security
Method-side family or source "practice" after A.3.1/A.15 recoverymethod relation structure, method descriptions, work-product structures, local-kind requirements and assignment requirements kept distinct, evidence records, teaching or work-instruction sequence, review structure, exception-handling structurerepeatability of enactment, teachability, transferability, reviewability, exception growth, evidence reuse, change reach, and ordinary work burden; kind substitutability only through A.2.7, with assignment continuity or Work coverage stated separatelyteachability, review quality, reliability of method enactment
Role-word, team, organization, or changing-holon case after the applicable recoveryUse E.10.ROLE only for unresolved claim-bearing role wording; A.2/C.3 and A.2.7 only for a local system-role kind, a separate System-classification judgment, or a relation among kinds; A.2.1 only for an assignment species or occurrence; A.14 only when a changing-holon question is current. Otherwise use the direct relation, architecture, organization, representation, function, responsibility, availability, staffing, Work-coverage, or ordinary non-use route actually recovered.Carry only the exact or explicitly provisional head into ACS: for example coordination load, independent change, testability, deployability, control separation, decision latency, evidence custody, kind substitutability, assignment continuity, holder replacement, staffing, Work coverage, availability, or responsibility. Infer no branch from another.team performance, organizational effectiveness, reliability of service delivery
Discipline or cultural-evolution case after C.20/C.36 recoverydiscipline holon, collective systems, method and work families, local system-role kinds and assignments, canon or memory epistemes, publication structures, review records, evidence relations, succession of systems in assignments, recognition and selection regimesnorm transfer, correction latency, coherence of enacted methods and work, evidence reuse, learning reach, variant containment, source-return cost, continuity of needed contributionscultural quality, discipline health, trustworthiness
AI-agent setup, model-supported workflow, or information systemmodel boundary, tool boundary, retrieval service, supervisor relation, evidence refresh relation, deployment placement, action interfacefunction-bearer fit, observability, evidence refresh, policy controllability, latency, resource load, interface grammar burden, rollback, benchmark transfer risksafety, trustworthiness, robustness, usefulness
Evidence-bearing assurance or certification work arrangement after A.10/A.15 recoveryevidence packages, claim scopes, audit trails, inspection work, certification mechanisms, evidence-provenance entries, source-currentness relation records, method descriptions, system-role assignments, direct responsibility relationsevidence reuse, traceability, source-return cost, inspection latency, certification burden, scope stability, mechanism visibility, change reachassurance-case quality, certification-work quality, compliance-work quality

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

CheckRequired result
CC-HCS-1The architecture-bearing family is named; when it is not itself an admitted holon family, the described holon or the source-bearing episteme or publication context for a description-side family is named, together with any recovery-pattern refs actually used.
CC-HCS-2Starter heads are paired with likely bearers or selected structures.
CC-HCS-3Q-Bundle boundaries are marked when the head is composite.
CC-HCS-4Software-derived heads are generalized only after the source label is resolved to an architecture-bearing family and the bearer and scale are recoverable.
CC-HCS-5Before project optimization, measurement, comparison, or selection, starter heads are either handed to C.32.ACS for project-row admission or kept as source catalogue wording.
CC-HCS-6Catalogue, benchmark, or dashboard cues that look mature answer the proxy-resistance question or remain source catalogue wording.

Common failures and repairs

FailureSymptomRepair
CatalogueAsStarterPackHundreds of terms are copied into the project.Choose the holon family and keep only first heads that can change the next narrowing into project criteria rows.
SoftwarePackOverfitCode-module terms are used for a method, role, practice, culture, or tradition without resolving the source label and rebinding bearer and scale.Recover the described holon or the source-bearing episteme or publication context for a description-side family; name any recovery pattern actually used, then rebind bearer and scale or demote the head to source catalogue wording.
FunctionalHeadAsArchitectureHeadA domain function is used as the starter architecture characteristic.Keep the function as functional demand; name the architecture characteristic that makes it sustainable.
QBundleHeadAsScalarMaintainability, trustworthiness, or teachability is treated as one row.Composite quality family work belongs to C.25 before ACS chooses any slot.
CatalogueCueAsStarterHeadCatalogue maturity, benchmark performance, or dashboard cleanliness is used to admit a starter head without a rebound bearer, likely scale, Q-Bundle boundary, or first ACS question.Keep the signal as source-looking catalogue, benchmark, or dashboard cue, ask what architecture concern worsened or disappeared, and carry the head forward only with a rebound bearer, likely scale, Q-Bundle boundary, and first ACS question.

Consequences

ConsequenceBenefitCost
Criteria-row narrowing starts from architecture-bearing family.The practitioner is not forced to read a giant catalogue first.Starter packs must be maintained as FPF architecture practice grows.
Cross-family generalization is disciplined.Software sources can inform starter packs without importing software ontology or admitting source labels as holon kinds.Every reuse must re-identify the family, bearer, and scale; record a recovery pattern only when a source label needed recovery.
ACS remains project-specific.HCS does not overload project criteria construction.The project still must do ACS work before optimization.

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 to inspectWhy this source is load-bearing hereTransfer into HCSConcrete HCS mutationBlocked overread
ISO/IEC 25010:2023 (https://www.iso.org/standard/78176.html) and SQuaRE quality-model practiceCurrent standard source for ICT product quality vocabulary; useful as a stable catalogue reference, not as FPF ontology.Use quality-model terms as source catalogue wording that must be rebound to the admitted holon family or recovered architecture-bearing family.Starter-pack rows separate starter heads, likely bearers or selected structures, any source-label recovery actually needed, and likely C.25 boundaries.An ICT product quality-model characteristic is not automatically a project criterion, holon ontology, scale row, eval program, or admission of a source label as a holon kind.
Richards and Ford, Fundamentals of Software Architecture, 2nd ed. (https://www.oreilly.com/library/view/fundamentals-of-software/9781098175504/)Current practitioner source for architectural characteristics, trade-offs, scope, and limiting the working set before measurement or governance.Keep the recurring-head idea, but generalize it only by rebinding family, bearer, and scale.HCS requires the architecture-bearing family, likely bearers, likely selected structures, a recovery-pattern ref only when needed, and first project questions before ACS criteria-row construction.Software architecture characteristic groupings cannot be copied into methods, roles, cultures, practices, built assets, or evidence workflows named by source wording without recovery and rebinding.
Ford, Parsons, Kua, and Sadalage, Building Evolutionary Architectures, 2nd ed. (https://www.oreilly.com/library/view/building-evolutionary-architectures/9781492097532/) and Software Architecture Metrics (https://www.oreilly.com/library/view/software-architecture-metrics/9781098112226/)Current practitioner line for guided change, architecture characteristics, and metric or eval work after quality goals are named.Put HCS before metrics and eval programs: it supplies starter heads, then ACS chooses project rows and ACE defines eval programs when needed.HCS stop condition explicitly ends at starter heads, likely bearers, likely Q-Bundle boundaries, and first project questions for ACS.A metric, dashboard, imported fitness-function name, or imported eval-program name is not a starter pack, project criterion, architecture-characteristic eval program, or architecture decision.
Current FPF C.25, C.30, C.32.ACS, C.32.ACE, and C.16Local rules for Q-Bundles, grounded architecture, project criteria rows, eval programs, and measurement.Use HCS only for starter packs; use the named pattern for each stronger claim.HCS relations and conformance rows name C.25 for composite quality families, C.30 for selected-structure recovery, ACS for criteria rows, ACE for eval programs, and C.16 for measurement.A starter head is not a Q-Bundle, selected structure, measurement method, eval result, comparison rule, declared selected-set result, published selected set, local choice, or project architecture decision.

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.ACS project criteria-set construction, including scale rows and use classes when the project later needs them; C.32.P2S when starter heads are needed before the architecturing flow can bind project criteria, candidate synthesis, eval, and refresh.
  • Uses: C.25 when a starter head is composite; C.30 and C.30.ASV when the selected structures are not yet recoverable.
  • Boundary: HCS is not a catalogue, measurement pattern, Q-Bundle pattern, optimization method, or architecture decision pattern.

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:

"Maintainability matters, but which bearer and scale make it an architecture criterion here?"
"We can optimize only a few rows; which characteristics drive optimization and which guard against loss?"
"Architecture around a Method, local system-role kind, separate System-classification judgment, assignment, AI workflow, or built asset has trustworthiness or teachability pressure; what is the exact characteristic bearer and which Q-Bundle slot or ACS row is current?"

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.

ArchitectureCharacteristicCriteriaSet@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureCriteriaProjectUseRelationRef?: U.RelationRef governed by the exact criteria-use or work-use pattern
  describedHolonRef:
  architectureUseRef:
  holonFamilyStarterPackRef?:
  sourceCatalogueRefs?:
  draftProjectCriteriaRows:
    - architectureCharacteristicRef:
      sourceHeadOrStarterPackRef?:
      bearerOrSelectedStructureRefs:
      rowClaimScopeRef: U.EntityRef referencing one U.ClaimScope
      selectedContextSliceRefs:
      modelUseStructureRef?:
      effectiveReferenceScheme:
      referencePlane?:
      qualificationOrEvaluationWindow:
      endpointShape: singleCharacteristic | qBundle | qBundleSlot | sourceVocabularyOnly
      qBundleRef?:
      architectureQuestion:
      scaleFormRef:
      polarity:
      useClass: optimizationIndicator | monitoredGuardrail | contextOnly
      currentReadingRef?:
      targetBandOrStopCondition?:
      readingMethodRefOrNoReadingReason:
      evalProgramRefs?:
      proxyRisk:
      protectedCounterCharacteristicRefs:
      receivingUseRef:
      sourceReturnCondition:
  optimizationIndicatorRowRefs:
  monitoredGuardrailRowRefs:
  contextOnlyRowRefs?:
  improvementCycleRef?:
  reopenCondition:

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

ForceTension
Catalogue breadth vs project attentionMany quality names are available, but a project needs a small criteria set for the next improvement cycle.
Holon recurrence vs bearer rebindingCharacteristic heads can recur across holon families or declared holon levels, but each project row must bind the project bearer and scale.
Optimization indicator vs guardrailA row can drive optimization, protect against loss, or only provide context. These uses must not collapse.
Architecture characteristic vs functionFunctional adequacy constrains synthesis, but functional characteristics are not architecture criteria by name.
Q-Bundle richness vs row useComposite quality families belong to C.25, while ACS admits rows or slots for architecture work.
Eval program vs criterionAn eval program can read or compare rows, but it is not the row and not the project criterion.

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:

  1. 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 BoundedModelUseStructure only when it independently changes that row's interpretation.
  2. Start from a C.32.HCS starter pack when the project has no draft criteria rows yet. Use source catalogues only as input, not as the criteria set.
  3. 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.
  4. 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.
  5. 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.
  6. Classify remaining admitted rows as monitoredGuardrail or contextOnly. A guardrail protects against a loss caused by optimizing another row; a context-only row helps interpretation but does not drive optimization now.
  7. 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.
  8. Reference C.32.ACE only after the row exists and an eval program is needed for current characterization, candidate comparison, monitoring, or preparing inputs for A.19.SelectorMechanism.
  9. 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:

ArchitectureCharacteristicImprovementRow@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureCriteriaProjectUseRelationRef?: U.RelationRef governed by the exact improvement-row-use or work-use pattern
  criteriaRowRef:
  rowClaimScopeRef: U.EntityRef referencing one U.ClaimScope
  selectedContextSliceRefs:
  modelUseStructureRef?:
  effectiveReferenceScheme:
  referencePlane?:
  qualificationOrEvaluationWindow:
  useClass:
  currentArchitectureReadingRefOrQualitativeState:
  evalResultRefs?:
  intendedArchitectureChangeDirection:
  candidateSelectedStructureChangeRefs?:
  expectedGain:
  protectedLosses:
  observedReadingAfterChange?:
  nextSynthesisTrigger?:
  stopContinueOrSourceReturnCondition:

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.22 and E.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

RequirementRequired result
CC-ACS-1The criteria set names the described holon, architecture use, and receiving use; every row names its exact U.ClaimScope, relevant A.2.6 U.ContextSlice membership, effective reference scheme and plane, and qualification or evaluation window.
CC-ACS-2Source catalogue, HCS starter pack, draft project criteria rows, optimization indicators, monitored guardrails, and context-only rows remain distinct.
CC-ACS-3The ordinary optimization core is three to five rows, or the text states why more are needed.
CC-ACS-4Each row names a bearer or selected structure. A characteristic without a bearer is not admitted as an architecture criteria row.
CC-ACS-5User function, architecture characteristic, Q-Bundle, scale row, reading, eval program, and eval result remain separate.
CC-ACS-6Any composite quality family belongs to C.25; ACS may reference the Q-Bundle or one declared slot.
CC-ACS-7Each optimization row names proxy risk and protected counter-characteristics before it is used in C.32, C.32.MLAO, C.32.ACE, or E.23.
CC-ACS-8Eval-program construction belongs to C.32.ACE and is not used as criteria rows.
CC-ACS-9The criteria set does not compare, select, publish, decide, certify, or carry an architecture-adequacy claim by itself.
CC-ACS-10A project-local criteria set or improvement row names both projectWorkOccurrenceRef and the obtaining architectureCriteriaProjectUseRelationRef for that exact record; the suffix or either reference alone asserts no locality.
CC-ACS-11A criteria row remains distinct from its referenced characteristic or Q-Bundle slot, scale, predicate, measurement result, eval program, eval result, and receiving decision object.
CC-ACS-12modelUseStructureRef appears only when an independently selected BoundedModelUseStructure changes the row interpretation; it never replaces row claim scope or context-slice membership.
CC-ACS-13A scale-sensitive ACS row names the exact characteristic or Q-Bundle slot, bearer, scale form, and use class; any preference between alternatives over a scale window is separately governed by C.31.ASAP.

Common failures and repairs

FailureWorking symptomRepair
CatalogueCopyAsCriteriaSetA project imports a long list of ilities and treats the list as architecture guidance.Use HCS for starter heads, then build ACS rows, mark optimization indicators, and keep guardrails and context-only rows separate.
TooManyOptimizationIndicatorsDozens of rows drive optimization at once.Keep the few rows that change the next synthesis step; demote the rest to monitored guardrails or context-only rows.
FunctionGoalAsArchitectureCriterionA user-visible function is used as the architecture optimization criterion.Recover the function through A.6.F; then name the architecture characteristic that makes the function sustainable.
QBundleDuplicatedAsScaleSetMaintainability, availability, security, teachability, or trustworthiness is treated as one ACS row when the truth depends on several typed slots.Open C.25, construct or reference the Q-Bundle, then select only the relevant slot for ACS use. Keep any report-only proxy outside the criteria row unless its bearer, scale, proxy risk, and receiving use are declared.
EvalProgramAsCriterionA test, monitor, source-side fitness function, benchmark, dashboard, or eval result is named as the criterion.Name the characteristic row first; eval-program construction belongs to C.32.ACE and measurement claims belong to C.16.
BearerCarryoverWithoutRebindingAn engineered-system row is copied to architecture around a Method, local system-role kind, separate System-classification judgment, assignment, or cultural-evolution case without changing the exact bearer, predicate, scale, or admissible use.Return to HCS only if the described holon family changed. Otherwise stay in ACS and rebind the row to the actual bearer and selected structure; a Method, kind, or assignment is not forced into a holon family.
LocalGainHidesCounterLossA candidate improves one row while worsening evidence burden, control burden, source-return cost, or functional adequacy.Add monitored guardrail rows and open E.13 when proxy-to-value drift appears before comparison or next synthesis.
ReadingAsDecisionA better reading is treated as the selected architecture.Keep the reading as feedback. Use A.19.CPM for explicit comparison, A.19.SelectorMechanism for set-returning selection, C.11 for local choice, 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.
ContextLabelAsRowScopeA domain, team, project, or bounded-context label is used as if it delimited every criterion row.Bind each row's exact U.ClaimScope, selected A.2.6 context slices, scheme and plane, and window; add a selected model-use structure only when it changes interpretation.

Consequences

ConsequenceBenefitCost
Architecture optimization gets declared criteria.C.32 and C.32.MLAO can use multi-criteria language without unnamed criteria.The project must admit and type rows before synthesis or optimization claims.
The 300-to-3 problem is handled by staged admission.Broad catalogues inform the project without serving as the project criteria set.Some familiar qualities must be guardrails or context rows.
Anti-Goodhart guardrails are explicit.Optimization can protect functional adequacy and other architecture concerns.A single convenient score cannot govern choice by itself.
Measurement and eval stay clean.C.16 and ACE keep readings, eval programs, and eval results separate from criteria.Some eval programs require additional receiving-pattern work before they can drive action.
Q-Bundle structure stays clean.Composite quality families keep their C.25 structure.ACS cannot shortcut a composite family into one scalar row.

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 to inspectWhy this source is load-bearing hereTransfer into ACSConcrete ACS mutationBlocked overread
FPF source presentation ТриПрототипаТриОшибки (2022-03-26)The presentation distinguishes eval from test and requires characteristic cards, scale procedures, fair comparison, explicit indicatorization, hard constraints, optimization goals, and risk signals.Put characteristic rows and use classes before any ACE eval program or explicit comparison.ACS row shape carries use class, scale form, current reading or no-reading reason, proxy risk, protected counter-characteristics, receiving use, and source-return condition.An eval, test, dashboard, score, or hard constraint is not the architecture characteristic or project criterion by itself.
ISO/IEC 25010:2023 (https://www.iso.org/standard/78176.html) and SQuaRE quality-model practiceCurrent standard source for product quality vocabulary and measurement context.Use standards as source catalogue material that must be rebound to the described holon, bearer, scale, and use class.ACS separates source catalogue, HCS starter pack, draft project criteria rows, optimization indicators, monitored guardrails, and context-only rows.A standard quality-model characteristic is not automatically an FPF project criterion, scale row, eval program, or holon ontology.
Richards and Ford, Fundamentals of Software Architecture, 2nd ed. (https://www.oreilly.com/library/view/fundamentals-of-software/9781098175504/)Current practitioner line treats architecture characteristics as criteria for success, trade-off analysis, scope, and governance.Criteria rows must be admitted and typed before synthesis, residual optimization, measurement, or governance claims.ACS rows supply the criteria consumed by C.32, C.32.MLAO, and later patterns for the next questions.A broad architecture-characteristic list is not a project criteria set.
Ford, Richards, Sadalage, and Dehghani, Software Architecture: The Hard Parts (https://www.oreilly.com/library/view/software-architecture-the/9781492086888/)Mature practitioner line for least-worst trade-offs among competing architecture characteristics.Keep explicit protected losses; explicit comparison belongs to A.19.CPM when comparison is being made.ACS requires use class, proxy risk, protected counter-characteristics, and downstream comparison boundary.No single criterion or local gain may dominate without naming the losses it can hide.
Ford, Parsons, Kua, and Sadalage, Building Evolutionary Architectures, 2nd ed. (https://www.oreilly.com/library/view/building-evolutionary-architectures/9781492097532/), Software Architecture Metrics (https://www.oreilly.com/library/view/software-architecture-metrics/9781098112226/), and C.32.ACECurrent practitioner line for guided change and repeatable eval over architecture characteristics.Restore source-side fitness-function wording as eval programs over declared ACS rows.Row shape has evalProgramRefs? and names ACE as the eval-program subject pattern after the row exists.An eval program or metric is not a characteristic kind, project criterion, selected architecture, or decision.
Current FPF C.25 and E.13Local receiving law for composite quality families and proxy-for-value drift.Keep Q-Bundle structure and proxy repair outside ACS while carrying the needed links.Row shape includes endpointShape, qBundleRef?, proxyRisk, and protectedCounterCharacteristicRefs; proxy drift requires E.13.A composite quality family is not one scalar row, and a convenient indicator is not the declared architecture concern.
ATAM lineage and ATRAF 2025 (https://arxiv.org/abs/2505.00688)Mature and current architecture-evaluation practice binds quality attributes to scenarios, trade-offs, sensitivity points, risks, and repeated refinement.Admit a quality word as a project row with bearer, scale, polarity, counter-characteristics, and receiving use before it affects synthesis.Explicit comparison belongs to A.19.CPM; composite quality bundles belong to C.25; ACS retains row preparation.Scenario analysis and trade-off vocabulary do not compare or choose candidates until the receiving comparison, selection, choice, or decision pattern is being used.

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, and E.23; uses A.1.1 only when a selected BoundedModelUseStructure changes one row's interpretation.
  • Receiving uses: C.32.P2S problem-to-structure architecturing flow, C.32 candidate synthesis, C.32.MLAO multilevel residual work, C.32.CONWAY correspondence frames, C.32.FAIL repair cues, C.32.ACE eval programs, A.19.CPM comparison inputs, A.19.SelectorMechanism selection inputs, C.11 local choice inputs, inputs for selected-set result declaration under G.5, source-backed publication-face and source-return inputs under E.17, publication-occurrence and audience-availability inputs under E.24.PUB, and architecture-decision inputs for C.32.PAD.
  • Starter-pack boundary: Use C.32.HCS when the project needs a holon-family starting set before criteria rows exist.
  • Q-Bundle boundary: Use C.25 when 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.ASAP when 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.ACE when 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.16 when a reading, coordinate, unit, threshold, score, or cross-case comparability claim is made.
  • Structural-information boundary: Use C.33 or C.34 when 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. Use C.35 only as generated-carrier admission support or discovered-carrier admission support before C.32 or ACS receives a criteria-bearing claim.
  • Proxy boundary: Use E.13 when an optimization indicator, score, eval result, or dashboard state begins to replace the declared architecture concern.
  • Synthesis boundary: Use C.32 after criteria rows exist and the next useful work is to synthesize candidate selected-structure changes.
  • Decision and publication boundary: Use A.19.CPM for comparison, A.19.SelectorMechanism for selection, C.11 for choice, G.5 for selected-set result declaration, and C.32.PAD for an 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.

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:

"We have criteria rows; which eval reading shows how candidate A and candidate B compare under the same parity frame?"
"The monitor is useful, but is this a reading, a test failure, or a decision input?"
"Two methods, roles, system variants, or AI workflows need fair comparison against the same architecture characteristics."

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.

ArchitectureCharacteristicEvalProgram@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureEvalProgramProjectUseRelationRef?: U.RelationRef governed by the exact eval-program-use or work-use pattern
  claimScopeRef: U.EntityRef referencing one U.ClaimScope
  selectedContextSliceRefs:
  effectiveReferenceScheme:
  referencePlane?:
  evaluationWindow:
  inputProjectionRefs:
  evaluatedCriteriaSetRef:
  evaluatedCriteriaRowRefs:
  evaluatedQBundleSlotRefs?:
  evaluatedCandidateRefs?:
  evaluatedBearerOrSelectedStructureRefs:
  evalPurpose: characterizeCurrentArchitecture | compareCandidates | monitorEvolution | prepareSelection | triggerNextSynthesis
  evalQuestion:
  parityFrameRef:
  evalScope: singleCriterion | coupledCriteria | qBundleSlice | variantPortfolio | holisticUseSlice
  evalOperation: measurement | simulation | benchmark | scenarioWalkthrough | test | monitor | expertReview | evidenceAudit
  triggerMode: onePass | batchComparison | continual | onChange | manualOnDemand
  resultForm: reading | band | rank | dominanceRelation | tradeoffFront | qualitativeState | evidenceFinding
  runContext: designTime | laboratory | pipeline | production | workReview | decisionPrep
  measurementOrObservationMethodRefs:
  methodDescriptionRefs?:
  evaluationWorkRefs?: FinSet(U.EntityRef constrained to U.Work)
  evaluationWorkAttributionRefs?: FinSet(U.RelationRef constrained to obtaining performedUnderAssignment relations)
  evaluationOperationApplicationRefs?: subject-pattern relation or A.6.1 application references
  evaluationResultRefs?: typed result references accepted under the definition and test for each result
  uncertaintyAndMissingDataPolicy:
  proxyRisk:
  protectedCounterCharacteristicRefs:
  comparisonPolicyRef?:
  receivingUseRef:
  refreshOrRetireCondition:

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

ForceTension
Variant learningCandidate architectures may be valuable even when they lose the selection being made.
Fair comparisonEval results are useful only when context, budgets, windows, units, and missing-data treatment are explicit.
Trade-off pressureImproving one architecture characteristic can worsen another.
Automation valueFrequent automated evals reveal drift early, but their results can be overread.
Error preventionSome eval operations are tests, yet error checking must not replace variant comparison.
EvolutionA useful eval can expire when the source-currentness relation, environment, declared holon-level ref, or scale window changes.

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:

  1. Reference the evaluated ACS criteria set, evaluated rows, and any Q-Bundle slots.
  2. State the eval purpose: current characterization, candidate comparison, portfolio-frontier work, post-change impact measurement, monitoring, or trigger for the next synthesis pass.
  3. Name the candidates, bearers, and selected structures being evaluated.
  4. Establish one exact U.ClaimScope, the relevant A.2.6 U.ContextSlice membership, effective U.ReferenceScheme and reference plane, evaluation window, input projections, resource budget, units, admissible observation or evidence inputs, and missing-or-unknown policy. Record their parity requirement in parityFrameRef; the parity-frame record does not replace those bindings.
  5. Choose eval scope: one criterion, coupled criteria, one Q-Bundle slice, a candidate portfolio, or a holistic use slice.
  6. Choose eval operations. Use measurement, simulation, benchmark, scenario walkthrough, monitor, review, or evidence audit according to the claim. Use test only 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 the U.Work occurrence and enacted Method. Add evaluationWorkAttributionRefs only 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.
  7. 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.
  8. 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.
  9. State the receiving use: C.32 synthesis input, C.32.MLAO residual input, E.23 improvement feedback, A.19.CPM comparison input, A.19.SelectorMechanism selection input, C.11 choice input, input for a selected-set result declared under G.5, or architecture-decision input for C.32.PAD. For publication input, distinguish E.17 source-backed face and source return from the E.24.PUB publication occurrence and audience availability.
  10. 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

RequirementRequired result
CC-ACE-1Every eval references declared ACS rows or C.25 Q-Bundle slots.
CC-ACE-2Every eval names evaluated candidates, bearers, or selected structures.
CC-ACE-3Purpose, parity frame, scope, eval operation, trigger mode, result form, and run context are explicit.
CC-ACE-4Measurement claims require C.16; composite quality claims require C.25.
CC-ACE-5Proxy risk, missing-data policy, and protected counter-characteristics are named before a receiving synthesis, comparison, or selection pattern uses the eval result.
CC-ACE-6Source-side "fitness function" wording is not used as the FPF object name in the record.
CC-ACE-7A check or test is admitted only as one eval operation when an expectation or hard constraint is being inspected.
CC-ACE-8The eval result does not select, decide, certify, or carry an architecture-adequacy claim by itself.
CC-ACE-9A project-local program names both projectWorkOccurrenceRef and architectureEvalProgramProjectUseRelationRef; the suffix or either reference alone asserts no locality.
CC-ACE-10The record separately identifies any reusable Method, MethodDescription, planned evaluation, dated evaluation Work, actual operation application, and typed result that the use needs; evalOperation or resultForm supplies none of those occurrences or identities.
CC-ACE-11Every actual evaluation use binds one exact U.ClaimScope, relevant A.2.6 U.ContextSlice membership, effective reference scheme and plane, evaluation window, and input projections; evalScope, runContext, and parityFrameRef do not replace them.

Common failures and repairs

FailureSymptomRepair
SourceFitnessTermAsFPFObject"Fitness function" is written as the object under work.Rewrite as ArchitectureCharacteristicEvalProgram@Project and name evaluated rows, candidates, parity frame, eval operations, and receiving use.
EvalAsCriterionA benchmark, monitor, or test is named as the architecture characteristic.Return to ACS; name the criterion, bearer, scale, proxy risk, and protected counter-characteristics before writing the eval.
TestModeAsEvalWholeThe team only asks whether one candidate passes while the work question is variant comparison.Keep the test for the hard constraint, then add eval result forms that compare candidates or expose the trade-off front.
UnfairComparisonCandidates are compared under different budgets, evidence windows, environments, or missing-data rules.Rebuild the parity frame or record the result as unusable for selection.
ResultAsDecisionA rank, score, pass, or dashboard reading selects the architecture.Treat the result as source material for an A.10 evidence relation when an evidence claim is current, or as comparison input when comparison is current. Use A.19.CPM for explicit comparison, A.19.SelectorMechanism for set-returning selection, C.11 for local choice, 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.
SingleIndicatorGoodhartWork improves one optimized indicator while an unmeasured architecture concern worsens.Limit optimized indicators, add protected counter-characteristics, and open E.13 when proxy-to-value drift appears.
LosingVariantAsErrorA candidate that lost a planned eval is recorded as a mistake.Record it as a variant result unless an expectation caused unplanned rework; keep useful learning in the variant archive.
ProgramAsRunOrResultThe ACE record is said to execute, measure, evaluate, or produce the result, or one generic resultRef hides the result kind.Recover each exact evaluator through A.13 and let A.15.1 independently admit the evaluation U.Work. Add an attribution ref only when the record expressly represents precise assignment-bound attribution; missing or failed F.6 leaves the Work intact. Add an operation application only when it independently obtains, and identify the typed result under the applicable pattern; keep the ACE record as the evaluation framing record.

Consequences

ConsequenceBenefitCost
Evals are typed evaluations over declared criteria.Variant comparison can proceed without collapsing criteria, readings, and decisions.The team must write the parity frame before using the result in a pattern for the next question.
Expectation-failure tests remain one eval operation when their expectation is declared.Error prevention remains available without replacing optimization.Some pass-fail dashboards can no longer drive decisions by themselves.
Losing variants remain useful.Architecture exploration keeps stepping stones and source-space learning.The variant archive needs deliberate upkeep.
Proxy and counter-characteristic risks are explicit.Goodhart pressure is visible before eval results drive work.More rows may remain monitored as guardrails rather than optimized.

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 to inspectWhy this source is load-bearing hereTransfer into ACEConcrete ACE mutationBlocked overread
FPF source presentation ТриПрототипаТриОшибки (2022-03-26)Separates variant, prototype, candidate, stake, solution, error, eval as variant comparison, and testing as error checking; also requires fair comparison and indicator selection.Make eval a typed architecture evaluation over declared candidates and criteria.test is admitted only as one evalOperation when expectation failure or hard-constraint checking is current; parity frame and result form are mandatory.A test, check, or pass-fail result is not the whole eval program, not the criterion, and not the decision.
Ford, Parsons, Kua, and Sadalage, Building Evolutionary Architectures, 2nd ed. (https://www.oreilly.com/library/view/building-evolutionary-architectures/9781492097532/)Current practitioner source for incremental architecture governance and feedback under source-side fitness-function terminology.Restore the source term to FPF eval programs over ACS rows, Q-Bundle slots, candidate structures, and parity frames.ACE record names evaluated rows, purpose, scope, eval operation, trigger mode, result form, run context, receiving use, and refresh or retire condition.Fitness-function wording is not imported as the FPF object name or as a new architecture characteristic kind.
Software Architecture Metrics (https://www.oreilly.com/library/view/software-architecture-metrics/9781098112226/)Current practitioner source for metric categories and governance practice after quality goals are named.Carry metric-cadence distinctions as eval-program fields, not as criteria rows.ACE distinguishes scope, trigger mode, result form, run context, method refs, and refresh or retire condition.A metric, dashboard, rank, or score is not a project criterion, selected architecture, or architecture decision.
Ford, Richards, Sadalage, and Dehghani, Software Architecture: The Hard Parts (https://www.oreilly.com/library/view/software-architecture-the/9781492086888/)Mature practitioner source for objective definitions, trade-off analysis, and least-worst choices under competing characteristics.Require declared criteria rows and protected counter-characteristics before synthesis, comparison, or selection uses eval results.ACE rows carry proxy risk, protected counter-characteristics, and receiving use before result-driven action.A better reading or rank does not authorize comparison, selection, choice, G.5 selected-set result declaration, actual publication, or decision by itself.
Goodhart and proxy-risk line, plus current FPF E.13Optimized proxies can detach from the declared architecture concern.Keep proxy repair in E.13 while ACE records the risk before result use.ACE requires proxy risk and protected counter-characteristics; proxy drift requires E.13.An eval result cannot replace the declared architecture concern.
Current FPF C.16, C.25, E.23, A.19.CPM, A.19.SelectorMechanism, G.5, E.17, E.24.PUB, and C.11Existing patterns for the next questions for measurement, Q-Bundles, repeated improvement, comparison, selection, selected-set result declaration, publication, and local choice.Keep ACE as the eval-program framing and typed-result dispatch boundary.Use C.16 for measurement validity and readings, C.25 for composite quality, E.23 for improvement feedback, A.19.CPM for comparison, A.19.SelectorMechanism for set-returning selection, G.5 for selected-set result declaration, E.17 for a source-backed publication face and return to source, E.24.PUB for an actual publication occurrence and availability, and C.11 for local choice. Accept each actual typed result only under the definition and test for that result.ACE does not validate measurement, define every eval result, define Q-Bundles, compare, select, declare a selected-set result under G.5, publish it to an audience, choose, or decide.

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, and A.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.P2S actual-structure feedback and next-synthesis repair, C.32 candidate synthesis, C.32.MLAO residual optimization, C.32.CONWAY correspondence frames, C.32.FAIL repair, A.19.CPM comparison, A.19.SelectorMechanism selection, C.11 local choice, selected-set result declaration under G.5, source-backed publication-face and source-return work under E.17, publication-occurrence and audience-availability work under E.24.PUB, and architecture-decision work for C.32.PAD.
  • Measurement boundary: Use C.16 when a reading, coordinate, unit, threshold, score, uncertainty, or cross-case comparability claim is made.
  • Structural-information boundary: C.33, C.34, and C.35 can supply captured structure, lost structure, preservation adequacy, generated-carrier context, or discovered-carrier context for an eval only after C.32.ACS, C.16, or C.25 has 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, and C.35 do not define eval programs.
  • Q-Bundle boundary: Use C.25 when the evaluated item is a composite quality family.
  • Test boundary: Use test only as an eval operation for a declared expectation or hard constraint. Error recognition and architecture-synthesis repair use C.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.CPM for explicit comparison, A.19.SelectorMechanism for set-returning selection, C.11 for local choice, G.5 for selected-set result declaration, and C.32.PAD for 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.

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 Correspondence Plain 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:

  1. 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;
  2. name exact acting and performance facts only when current;
  3. name each influence source with its kind and direct influence relation;
  4. for an exact reusable row, select one pair of obtaining C.30 ArchitectureRelation occurrences 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 exact ArchitectureClaim instead;
  5. 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.4 or A.3.4.P for the bounded change and changed referent.
  • A.12 for acting-side externalization, A.13 for exact actual-performer recovery, A.15.1 for independent dated-Work admission and distributed-performer forms, A.2.1 for an exact assignment occurrence when separately claimed, F.6 for a later performedUnderAssignment(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.M for module-interface repair.
  • C.32.ACS for current architecture-characteristic criteria rows and C.25 for any composite Q-Bundle and exact slot used by the trade-off.
  • C.29 and the project-selected structural-equivalence pattern for structural similarity.
  • A.19.CPM for explicit comparison and A.19.SelectorMechanism for set-returning selection.
  • G.5 for selected-set result declaration; E.17 for a source-backed publication face and source return; E.24.PUB for the publication occurrence and audience availability; C.18 and C.19 for archive, front, or pool-treatment policy.
  • C.11 for fixed local choice and C.32.PAD for 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:

ArchitectureInfluenceTransformedArchitectureCorrespondenceFrame@Project:
  intendedCorrespondenceUse: prepare architecture candidates for independent field-module replacement
  claimScopeRef?: product-family module-change architecture claims
  synthesisQuestion: which source-side, product-side, joint, or bounded-mismatch change can support independently replaceable field modules?
  changedReferentRef: ProductFamilyFieldModuleBoundary@2026Q3
  influenceSourceSelectedStructureMap[]:
    - influenceSourceHolonRef: ManufacturingCertificationSystem@Plant-A
      influenceSourceArchitectureRelationRef: C.30 ArchitectureRelation(ManufacturingCertificationSystem@Plant-A, BatchLineSharedEvidenceStructure@Current)
      influenceSourceArchitectureClaimRef?: omitted — the obtaining relation and current structure are enough for this use
      structureKindRef: BatchAndEvidenceResponsibilityStructure
      selectedStructureRef: BatchLineSharedEvidenceStructure@Current
      contributionToCandidatePressure: may prevent independent field-module replacement
      architectureCharacteristicPressure: provisional independent-change pressure
      relationFunctionClaimRef: C.30 plus A.22
      sourceReturnCondition: missing-governor — recover the direct architecture-influence kind and predicate
  transformedHolonRef: ProductFamily@Current
  transformedArchitectureRelationRef: C.30 ArchitectureRelation(ProductFamily@Current, FieldModuleBoundaryStructure@Current)
  transformedArchitectureClaimRef?: omitted — the obtaining relation and current structure are enough for this use
  transformedSelectedStructureMap[]:
    - structureKindRef: ModuleBoundaryStructure
      selectedStructureRef: FieldModuleBoundaryStructure@Current
      requiredStructureContribution: permit independent field-module replacement
      architectureCharacteristicPressure: provisional independent-change pressure
      relationFunctionClaimRef: C.30 plus A.22
  correspondenceClaims[]:
    - correspondenceId: BatchEvidence-to-FieldModulePressure
      influenceSourceArchitectureRelationRef: C.30 ArchitectureRelation(ManufacturingCertificationSystem@Plant-A, BatchLineSharedEvidenceStructure@Current)
      transformedArchitectureRelationRef: C.30 ArchitectureRelation(ProductFamily@Current, FieldModuleBoundaryStructure@Current)
      influenceSourceSelectedStructureRef: BatchLineSharedEvidenceStructure@Current
      transformedSelectedStructureRef: FieldModuleBoundaryStructure@Current
      correspondenceUse: prepare candidates; no exact pair row asserted
      pressureDirection: batch and evidence arrangements may constrain module independence
      provisionalArchitectureCharacteristicHeads[]: independent change for field modules
      receivingUsePatternLocator: C.32.ACS
      sourceReturnCondition: missing-governor — recover the direct influence kind and predicate
  candidateArchitectureConfigurations[]:
    - candidateRef: SourceSideChange@CellAndEvidenceStructures
    - candidateRef: TransformedSideChange@FieldModuleBoundary
    - candidateRef: JointChange@CellEvidenceAndModuleBoundary
    - candidateRef: BoundedMismatch@ExplicitExceptionCost
  evolutionWindowRef: ProductFamilyModuleChange@2026Q3
  evidenceRefs?: current batch-line evidence-structure and field-module boundary records
  nextQuestionPatternLocator: C.32.ACS

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:

ArchitectureInfluenceTransformedArchitectureCorrespondenceFrame@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureCorrespondenceFrameProjectUseRelationRef?: U.RelationRef defined by the exact synthesis-use or work-use pattern
  synthesisQuestion:
  intendedCorrespondenceUse:
  claimScopeRef?: U.ClaimScope
  changedReferentRef:
  actualTransformationRef?: U.EntityRef constrained to U.Transformation, only when A.3.4 independently admits the bounded change of changedReferentRef
  performerRows[]?:
    actingSystemRef: U.EntityRef constrained to U.System; for performance, this is the exact actual performer recovered through performerA13CoreBasisRef
    performerA13CoreBasisRef?: required with workOccurrenceRef; cites the exact local kind and criterion, classification, same obtaining assignment, scope, working situation, window, and adequate core evidence
    workOccurrenceRef?: U.EntityRef constrained to U.Work, independently admitted by A.15.1 when performance is claimed
    actingSystemRoleAssignmentRef?: U.RelationRef constrained to U.SystemRoleAssignment, include when an obtaining assignment is separately represented and require the same A.13 assignment when attribution is represented
    performedUnderAssignmentRelationRef?: U.RelationRef governed by F.6, include only when this row expressly represents precise assignment-bound attribution; omit otherwise; missing or failed F.6 leaves workOccurrenceRef intact
    actorSideOrWorkToChangeRelationRefs[]: exact U.RelationRef values required by the current claim
  influenceSourceRows[]?: asserted influence facts only
    influenceSourceRef:
    influenceSourceKindRef:
    exactInfluenceRelationRef: U.RelationRef
    influencePatternLocator:
  influenceSourceSelectedStructureMap[]?:
    influenceSourceHolonRef:
    influenceSourceArchitectureRelationRef?: exact obtaining C.30 ArchitectureRelation ref
    influenceSourceArchitectureClaimRef?: exact C.30 ArchitectureClaimRef for actual, candidate, required, desired, or expected content not carried by an obtaining relation
    structureKindRef:
    selectedStructureRef:
    contributionToCandidatePressure:
    architectureCharacteristicPressure:
    relationFunctionClaimRef:
    sourceReturnCondition?:
  transformedHolonRef:
  transformedArchitectureRelationRef?: exact obtaining C.30 ArchitectureRelation ref
  transformedArchitectureClaimRef?: exact C.30 ArchitectureClaimRef for actual, candidate, required, desired, or expected content not carried by an obtaining relation
  transformedSelectedStructureMap[]:
    structureKindRef:
    selectedStructureRef?:
    requiredStructureContribution:
    architectureCharacteristicPressure:
    relationFunctionClaimRef:
    sourceReturnCondition?:
  evolutionWindowRef:
  evidenceRefs?:
  architecturePairRowRefs[]?: ArchitectureInfluenceTransformedArchitectureCorrespondenceRow@Context refs
  correspondenceClaims[]?: synthesis-local compound claims that have not yet met the exact-row assertion threshold
    correspondenceId:
    influenceSourceArchitectureRelationRef?:
    influenceSourceArchitectureClaimRef?:
    transformedArchitectureRelationRef?:
    transformedArchitectureClaimRef?:
    influenceSourceSelectedStructureRef?:
    transformedSelectedStructureRef:
    correspondenceUse:
    pressureDirection:
    affectedArchitectureCharacteristicRefs[]?: current C.32.ACS criteria-row refs; exact C.25 Q-Bundle slot refs when composite
    provisionalArchitectureCharacteristicHeads[]?: plain discovery cues pending C.32.ACS/C.25; never criteria refs
    expectedArchitectureGain?:
    knownArchitectureLoss?:
    preservedStructure?:
    lostOrHiddenStructure?:
    receivingUsePatternLocator:
    sourceReturnCondition:
  candidateArchitectureConfigurations[]:
    candidateRef:
    influenceSourceSideChange?:
    transformedArchitectureChange?:
    coordinationChange?:
    expectedArchitectureGain?:
    knownArchitectureLoss?:
    evolutionWindowRef?:
    receivingUsePatternLocator?:
    sourceReturnCondition?:
    stopOrEscalationCondition?:
  c29LensOrStructuralEquivalenceRef?:
  nextQuestionPatternLocator:

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

ForceTension
Domain action vs architecture influenceA system can act while its architecture or another selected structure influences the candidate; neither fact entails the other.
Performance detail vs candidate synthesisExact system-role assignment and dated Work matter when performance is claimed, but candidate architecture work must not invent them from an influence diagram.
Exact influence vs useful local frameA local compound correspondence can guide candidate synthesis before a reusable episteme about an obtaining exact relation can be asserted.
One pair vs recursive networkOne architecture pair can qualify a network reading, but the pair is neither the network nor a cross-flow relation by citation.
Desired transformed architecture vs source-side constraintThe transformed architecture may need a structure the current influence-side arrangement cannot sustain.
Evolution windowA correspondence that works now can fail when either selected architecture, the direct relation, or the changed referent changes.

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

  1. Name the domain action and changed referent. Identify changedReferentRef independently. Add actualTransformationRef only 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.
  2. Add acting and performance facts only when claimed. Every precise actual performer is one exact U.System recovered through A.13. Claimed performance requires one exact dated U.Work independently 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 admitted U.SystemRoleAssignment species under A.2.1 and F.6 performedUnderAssignment(W, RA) only when this frame or its receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; then compare S with RA.HolderSystemSlot. F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves the Work intact. Use A.15.1 CC-A15.1-17 when several systems jointly perform the top-level Work or when the use instead needs a parent Work with separately performed child occurrences.
  3. 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.
  4. Select one architecture pair. For an exact row, name one obtaining influence-source C.30 ArchitectureRelation and one obtaining transformed-side C.30 ArchitectureRelation, with each exact holon and selected-U.Structure participant. 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 exact ArchitectureClaim and the pair in the synthesis frame; do not assert an exact pair row.
  5. 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.ACS criteria rows and any declared C.25 Q-Bundle slots that make this trade-off real.
  6. 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.
  7. Use C.29 only for structural-similarity claims. A correspondence row does not establish homomorphism, equivalence, or architecture adequacy.
  8. 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

ArchitectureInfluenceTransformedArchitectureCorrespondenceRow@Context <: U.Episteme:
  entityOfConcernRef: exactArchitectureInfluenceOrCorrespondenceRelationOccurrenceRef
  entityOfConcernKindRef: exactArchitectureInfluenceOrCorrespondenceRelationKindRef
  relationFunctionClaimRef: subject pattern of that exact relation kind and occurrence
  influenceSourceArchitectureRelationRef: one exact obtaining C.30 ArchitectureRelation
  influenceSourceHolonRef: the exact architectureBearingHolonRef participant of influenceSourceArchitectureRelationRef
  influenceSourceSelectedStructureRef: the exact selectedArchitectureStructureRef participant of influenceSourceArchitectureRelationRef
  influenceSourceArchitectureClaimRef?: exact C.30 ArchitectureClaimRef when the current use also needs claim content about that same holon, relation, or structure
  transformedArchitectureRelationRef: one exact obtaining C.30 ArchitectureRelation
  transformedHolonRef: the exact architectureBearingHolonRef participant of transformedArchitectureRelationRef
  transformedSelectedStructureRef: the exact selectedArchitectureStructureRef participant of transformedArchitectureRelationRef
  transformedArchitectureClaimRef?: exact C.30 ArchitectureClaimRef when the current use also needs claim content about that same holon, relation, or structure
  changedReferentRef: exact independently identified referent of the current change
  actualTransformationRef?: U.EntityRef constrained to U.Transformation, only when A.3.4 independently admits the bounded change of changedReferentRef
  performerRows[]?:
    actingSystemRef: U.EntityRef constrained to U.System; for performance, this is the exact actual performer recovered through performerA13CoreBasisRef
    performerA13CoreBasisRef?: required with workOccurrenceRef; cites the exact local kind and criterion, classification, same obtaining assignment, scope, working situation, window, and adequate core evidence
    workOccurrenceRef?: U.EntityRef constrained to U.Work, independently admitted by A.15.1 when performance is claimed
    actingSystemRoleAssignmentRef?: U.RelationRef constrained to U.SystemRoleAssignment, include when an obtaining assignment is separately represented and require the same A.13 assignment when attribution is represented
    performedUnderAssignmentRelationRef?: U.RelationRef governed by F.6, include only when this row expressly represents precise assignment-bound attribution; omit otherwise; missing or failed F.6 leaves workOccurrenceRef intact
    actorSideOrWorkToChangeRelationRefs[]: U.RelationRef
  additionalInfluenceSourceRows[]?:
    influenceSourceRef:
    influenceSourceKindRef:
    exactInfluenceRelationRef: U.RelationRef
    influencePatternLocator:
  affectedArchitectureCharacteristicRefs[]: current C.32.ACS criteria-row refs; exact C.25 Q-Bundle slot refs when composite
  evolutionWindowRef:
  correspondenceUse:
  expectedArchitectureGain:
  knownArchitectureLoss:
  receivingUsePatternLocator:
  sourceReturnCondition:
  networkCrossFlowRelationRowRef?: E.18.NET NetworkCrossFlowRelationRowRef

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.

Correspondence repair rowUseMinimum repair against overread
changedReferentRecoveryThe story names a team, line, tool, method, or organization but not what changes.Identify the exact continuing changed referent; when actual change is asserted, identify its A.3.4 U.Transformation; keep actor-side and Work-to-change relations separately governed.
performerRecoveryA source is said to build, design, repair, or operate.Recover each exact actual performer through A.13 and let A.15.1 independently admit the dated U.Work; add the exact A.2.1 assignment, F.6 performedUnderAssignment occurrence, and holder-equality check only when this frame or receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment. Add direct actor-side or Work-to-change relations separately; use A.15.1 CC-A15.1-17 when several systems perform.
influenceSourceRecoveryAn architecture or structure is said to shape a candidate.Name its exact kind and direct influence relation; otherwise keep it as a candidate cue.
architecturePairRecoveryTwo architectures are compared or linked.Apply the direct relation pattern. With no kind/predicate, return missing-governor; with unresolved facts, keep the pair synthesis-local and name the missing grounding; with a false predicate, assert no occurrence; with a satisfied predicate, name the exact obtaining occurrence and pair.
inverseConwayRetargetingThe desired transformed architecture is sound, but the current source-side arrangement cannot sustain it.Change selected influence-source structures and record migration cost, new burden, and stop condition.
transformedArchitectureRetargetingThe source-side arrangement is fixed or too expensive to change in the current window.Change the transformed architecture candidate and record the lost desired property or exception.
jointCorrespondenceSynthesisNeither side alone can carry the architecture characteristic.Change both sides and record preserved structure, lost structure, and coordination burden.
boundedCorrespondenceMismatchA mismatch is tolerable for now.State exception cost, bounded-use limit, source-return condition, and reopen trigger.

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

Grounded working caseActing and performance factsInfluence-source and architecture-pair factsCandidate workStop or return
Product family and manufacturing systemThe product referent and bounded A.3.4 transformation are identified independently when actual change is claimed. The admitted manufacturing and certification Systems jointly perform dated architecturing Work, each through its basis: A.13 first, independent A.15.1 Work admission second, and F.6 afterward only for precise assignment-bound attribution; the direct Work-to-change relation remains separate.One obtaining C.30 ArchitectureRelation connects the manufacturing-and-certification holon to its shared batch-line evidence structure; another connects the product-family holon to its current field-module structure. A Plant-A domain declaration defines the influence predicate between those exact occurrences, and current case facts satisfy it. Neither architecture-bearing holon nor architecture relation is inferred to be a performer.Prepare manufacturing-cell change, product-module split, joint change, and bounded batch exception.Stop at candidate preparation. Handle product choice or architecture decision under C.11 or C.32.PAD; factory Work authorization through its direct authority or permission relation or an A.20/A.21 gate; and certification evidence or assurance through A.10 or B.3.
Organization designing and operating a service platformEach acting team or organization is used through its admitted U.System identity; any actual design or operations Work points to its basis: A.13 first, independent A.15.1 Work admission second, and F.6 afterward only for precise assignment-bound attribution.Communication, deployment, test, and approval structures influence one service-platform architecture pair through their direct relations.Prepare a service-boundary, platform-mediation, or bounded-coordination-cost change. If responsibility retargeting is proposed, name the exact responsibility predicate and old and proposed participants; otherwise mark that branch missing-governor instead of calling it a team or test role change.Stop before an organization-redesign decision or authority claim and apply the exact predicate and test for that claim. Use G.5 for selected-set result declaration and C.32.PAD for an architecture decision. When publication 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.
Review method influencing authored work productsThe method description does not act. When review is performed, recover every precise performer's A.13 core and independently admit the review Work under A.15.1; add F.6 only when precise assignment-bound attribution is current, and state any Work-to-change relation separately.The review-method or evidence structure influences the authored-section architecture through its exact method-use, evidence-scope, or project influence relation.Add a prospective exception-assignment requirement and evidence scope, change the Method step, change the work-product structure, or reject the automation candidate.Stop before method-governance or publication claims. For method use, apply the direct predicate and the pattern that defines and tests it. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability. Use G.5 only when selected-set result declaration is current.
Instructional system changing learner capabilityEach instructor or instructional organization is used through its admitted U.System identity; any actual teaching Work points to its basis: A.13 first, independent A.15.1 Work admission second, and F.6 afterward only for precise assignment-bound attribution.Curriculum, feedback, and evidence structures influence the architecture claim about the changed learner-capability referent; they do not become the learner or the performer by influence.Prepare curriculum, a prospective feedback-assignment requirement, evidence scope, or bounded-cohort candidates.Stop before educational policy, evidence-sufficiency, or ethical-mediation claims; state them under the exact policy predicate, A.10, or D.4 respectively.
AI-agent toolchain changing project work productsAn admitted execution System performs any actual tool-call or authoring Work through its basis: A.13 first, independent A.15.1 Work admission second, and F.6 afterward only for precise assignment-bound attribution.Toolchain control and evidence-refresh structures influence the transformed work-product architecture through exact relations; the toolchain architecture itself does not act.Add supervision and refresh, change task decomposition, or keep bounded autonomy with source return.Stop before safety, gate or release, or assurance claims; state them under the exact safety predicate, A.20/A.21, or B.3 respectively.
Exact positive, distributed-performer, and network-local slice. In one Plant-A domain framework, PlantArchitectureInfluenceRelations-v3 defines BatchEvidenceArchitectureConstrainsModuleArchitecture(sourceArchitectureRelation, transformedArchitectureRelation, evolutionWindow). Its first participant is the obtaining C.30 ArchitectureRelation(ManufacturingCertificationSystem@Plant-A, BatchLineSharedEvidenceStructure@Current); its second is the obtaining C.30 ArchitectureRelation(ProductFamily@Current, FieldModuleBoundaryStructure@Current). Both occurrences are explicitly individuated under A.6.REL because this domain predicate uses them as participants. Plant-A facts satisfy that predicate over ProductFamilyModuleChange@2026Q3, so BatchEvidenceConstrainsFieldModules-17 is the exact obtaining influence occurrence and the EntityOfConcern of BatchEvidence-to-FieldModules-Row-17. This case-local predicate and occurrence do not mint a universal Conway relation.

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

Failure modeC.32.CONWAY repair action
Architecture-as-actorReplace the acting architecture with the exact U.System. When performance is claimed, recover every precise performer's A.13 core and independently admit the Work under A.15.1; add F.6 only when precise assignment-bound attribution is current, and state any actor-side or Work-to-change relation separately. Keep architecture relation, claim, holon, and selected structure as separately related influence-side objects.
Influence-as-performanceRemove system-role-kind, assignment, Work, performer, or transformation-participation inferences that came only from influence. Establish those facts independently or leave them absent.
Changed referent or transformation omittedIdentify the exact continuing referent; when actual change is claimed, identify its A.3.4 U.Transformation; keep actor-side and Work-to-change relations under their subject patterns before deciding which architecture content is transformed.
Performer without Work basisWhen performance is claimed, recover every precise performer's A.13 core and independently admit the Work under A.15.1; add F.6 only when precise assignment-bound attribution is current, and add only the other direct relations used by the claim. Use A.15.1 multiple-performer forms when needed.
Influence source without governorApply the direct relation pattern. With no kind/predicate, keep the correspondence synthesis-local and return missing-governor; with unresolved facts, name the grounding boundary; with a false predicate, remove the influence occurrence.
Architecture-bearer equality with an actor inferredKeep the influence-source holon and acting system unequal unless independent actor and architecture-bearer facts establish equality.
Transformed-side-only inverse ConwayIf the text says inverse Conway but changes only the transformed architecture, name the exact influence-source selected structure that must change or stop using the inverse-Conway claim.
Source-side change without transformed pressureIf an organization, method, line, or toolchain is reorganized without one transformed architecture and characteristic under pressure, return to the direct Work or organization-design use.
One-sided optimizationPrepare source-side change, transformed-side change, joint change, and bounded mismatch candidates before claiming the correspondence has been constructively handled.
Pair treated as networkKeep the exact pair row as one qualified reading; use E.18.NET for network identity, members, and exact cross-flow relations.
Network citation treated as relation admissionGround the exact relation participants in member-flow positions and make the E.18.NET composite locator name that same citing current record and exactly one cross-flow row; otherwise remove networkCrossFlowRelationRowRef. A locator for one record does not qualify another record's citation.
Mirroring treated as adequacyKeep the statement as candidate pressure or use C.29 when structural similarity or preservation is claimed.
Software-practice overfitWhen the changed referent is a product family, manufacturing system, school, hospital, or another admitted non-software holon, transfer only the selected-structure correspondence and affected characteristics; do not import software-service or team ontology. A method-family or method-description label alone does not make the named object a U.Holon; if the case uses a method-related holon, identify that exact holon and admit it independently under its direct kind-admission pattern.
Static correspondenceReopen when either architecture, selected structure, relation occurrence, changed referent, or evolution window changes.

Conformance Checklist

IDRequirementFailed-check repair
CC-C32.CONWAY-1changedReferentRef is independently identified; any claimed actual bounded change has one A.3.4 actualTransformationRef, while actor-side and Work-to-change relations retain their direct governors.Recover those exact objects and relations or keep the change description provisional.
CC-C32.CONWAY-2Every claimed actor is an admitted U.System; every claimed work-facing assignment names an occurrence and its declared A.2.1 species. The occurrence's holder matches the separately named acting System; the species defines the local assigned-kind domain, predicate, applicability, participant meanings, and occurrence identity.Add the System, species, and assignment occurrence or remove the acting or assignment claim.
CC-C32.CONWAY-3Claimed performance has every exact actual performer recovered through A.13 and exact dated Work independently admitted through A.15.1. An exact A.2.1 assignment, F.6 performedUnderAssignment(W, RA) occurrence, and S = RA.HolderSystemSlot appear only when precise assignment-bound attribution is expressly represented; missing or failed F.6 leaves Work intact. Direct actor-side or Work-to-change relations remain separate, and several performers use A.15.1 CC-A15.1-17 forms.Restore the independent performer and Work basis; add attribution only for a consuming claim, or remove the unsupported performance or attribution claim.
CC-C32.CONWAY-4Every influence source retains its exact kind and direct obtaining occurrence; influence entails no actor, system-role kind or assignment, Work, changed-referent, or transformation-participation fact.Apply the direct predicate: a missing kind or predicate returns missing-governor, unresolved facts stay provisional, and a false predicate removes the occurrence; delete inferred acting facts.
CC-C32.CONWAY-5One exact pair row names two obtaining C.30 ArchitectureRelation occurrences, each exact holon and selected-U.Structure participant, the changed referent, exact obtaining influence or correspondence occurrence, admitted relation kind, direct predicate and governor, and a satisfied affirmative case. Modal architecture content remains an ArchitectureClaim in the frame.Complete the satisfied actual pair; otherwise keep only the synthesis-local frame and state modal status, missing-governor, unresolved grounding, or false predicate exactly.
CC-C32.CONWAY-6Equality between an architecture bearer and an actor is recorded only from independent facts.Separate the refs and remove equality inference.
CC-C32.CONWAY-7The two project-use fields retain their exact Work identity and direct use-relation meaning.Add both facts when project use is claimed or keep @Project retrieval-only.
CC-C32.CONWAY-8Each comparison-ready candidate states source-side change, transformed-side change, expected gain, known loss, evolution window, pattern for the next question, source-return condition, and stop; a first-pass candidate head is visibly outside comparison.Complete the candidate before comparison or keep only its candidateRef as a first-pass head.
CC-C32.CONWAY-8aEvery affectedArchitectureCharacteristicRefs[] value resolves to a current C.32.ACS criteria row and, when composite, the exact C.25 Q-Bundle slot; a local discovery cue appears only in provisionalArchitectureCharacteristicHeads[] and supports no comparison, selection, or decision.Resolve the governed ref, move the cue to the provisional-head field and use C.32.ACS/C.25, or remove the stronger claim.
CC-C32.CONWAY-9Structural-similarity claims use C.29 or the selected structural-equivalence pattern.Remove similarity entailment or apply the direct pattern.
CC-C32.CONWAY-10A network record cites the pair only as a qualified reading; any networkCrossFlowRelationRowRef names that same exact current citing record, resolves exactly one row there, and its independently grounded occurrence and endpoint bindings agree with this pair. The singular locator qualifies no other record citation.Remove the network link or repair the citing record, occurrence, and ordered endpoint-binding locator.
CC-C32.CONWAY-11Source-return and evolution-window conditions are present.Add the changed values and reopen trigger.

Common Repair Cues

Repair cueSymptomFirst repair
ArchitectureActsAn architecture, method, toolchain, organization chart, or episteme builds, decides, repairs, or performs.Start with the domain action; name the exact system and Work when current, then state architecture influence separately.
InfluenceSourceUntypedA source “shapes” the candidate without kind or relation.Apply the subject pattern: recover kind/predicate or return missing-governor; if facts are unresolved, keep a candidate cue; if false, remove the occurrence; if satisfied, name the obtaining occurrence.
ChangedReferentHiddenThe pair is named but the object or claimed actual transformation is not.Identify the continuing changed referent and, when current, the A.3.4 U.Transformation; keep direct participation and Work-to-change relations separate.
PerformerBasisMissingA performer is named without its A.13 core, independently admitted dated Work, or the F.6 relation required by a precise assignment-bound attribution.Apply A.12 to separate acting and changed sides; recover every precise performer's A.13 core; independently admit the Work under A.15.1; add F.6 only when the receiving claim needs precise assignment-bound attribution; and use the CC-A15.1-17 form when several systems perform.
TransformedArchitectureNoSourceFitThe desired architecture cannot be sustained by the current influence-side structures.Open source-side retargeting, transformed-architecture retargeting, joint change, and bounded mismatch as alternatives.
InverseConwayNoSourceChangeThe text says inverse Conway but names no selected influence-source structure change.Name that exact structure, affected characteristic, migration burden, loss, and pattern for the next question or drop the inverse-Conway claim.
SourceChangeNoTransformedPressureA source-side organization, method, line, or toolchain change has no transformed architecture characteristic under pressure.State the change under its direct Work or organization-governance predicate until the architecture pair is current.
CoordinationCostHiddenVisible coupling falls while Work, evidence, approval, manufacturing, or operational coordination rises elsewhere.Name the exact influence source and relation carrying that pressure; add candidates that expose the shifted cost.
MirroringNoExceptionTestMirroring is used without preserved or lost structure, an exception, or an evolution window.Keep it as diagnostic pressure or use C.29 for the declared lens.
PairFlattenedIntoNetworkOne architecture pair is called the entire transformation-flow network.Restore E.18.NET identity and keep the pair as one optional qualified reading.
BoundedMismatchHiddenA known mismatch is kept without cost or trigger.Record bounded use, exception cost, source return, and reopen trigger.

Consequences

Positive consequenceCost or trade-off
Architecture influence can guide synthesis without granting agency.Actor, Work, changing, and influence relations must be grounded separately.
Exact pair rows can be reused across current network records.Each reuse must preserve pair, relation occurrence, qualification window, and claim scope.
Inverse-Conway work produces explicit candidate changes and bounded mismatches.Some familiar “transformer architecture” shorthand must be expanded into several facts.
Changed referent and transformed architecture stay recoverable.A useful local frame may remain below exact-row assertion when the governor is missing or case facts remain unresolved.
Network recursion remains with E.18.NET.One pair row cannot stand in for the whole network or its cross-flow relations.
Candidate architectures are checked against source-side production, testing, maintenance, evidence, and evolution arrangements.Changing the influence-source side can be expensive; an attractive transformed-side candidate may therefore be rejected for the current evolution window.
Organization, Work, method, tool, and module claims are routed to their subject patterns instead of being hidden in an architecture-pair result.This separation may require the practitioner to follow several separately governed exits before comparison. Mirroring supplies candidate pressure, not architecture adequacy; use C.29 when the claim is structural similarity or preservation.

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 to inspectWhy this source is load-bearing hereTransfer into C.32.CONWAYConcrete C.32.CONWAY mutationBlocked overread
Melvin Conway, How Do Committees Invent? (https://www.melconway.com/Home/Committees_Paper.html)Original source for pressure between communication arrangements and the structure of designed systems.Treat communication and organization architecture as influence on candidates.influenceSourceRows[] and the exact pair row name the source architecture, transformed architecture, selected structures, relation occurrence, and changed referent.The organization or its architecture is not inferred to be the acting system; candidate pressure is not a universal Conway relation.
MacCormack, Rusnak, and Baldwin 2012 mirroring hypothesis (https://doi.org/10.1016/j.respol.2012.04.011) and Colfer and Baldwin 2016 exceptions survey (https://www.hbs.edu/ris/Publication%20Files/16-124_7ae90679-0ce6-4d72-9e9d-828872c7af49.pdf)Empirical and theory line for product-architecture and organization-architecture mirroring and exceptions.Use mirroring as a correspondence hypothesis over selected structures and an evolution window.Failure and conformance rows require affected characteristics, exceptions, source return, and C.29 for structural-similarity claims.Mirroring does not establish adequacy, actor equality, relation occurrence, or an entire network.
DORA loosely coupled teams, last updated 2025-10-20 (https://dora.dev/capabilities/loosely-coupled-teams/)Practitioner line tying architecture, team independence, testing, deployment, and coordination load.Treat those arrangements as typed influence sources when they constrain a service architecture candidate.Candidate forms expose source-side retargeting, transformed-side retargeting, joint change, and bounded mismatch.Team autonomy or work-transfer counts do not identify actors, Work, or an architecture-influence occurrence without their direct facts.
Team Topologies key concepts (https://teamtopologies.com/key-concepts)Organization-design family for fast flow, interaction modes, cognitive load, platform teams, and evolving boundaries.Use team types and interaction modes as candidate influence sources, not acting kinds.Influence-source rows retain exact source kind and relation; candidate rows retain migration cost, burden, and evolution window.Team-topology vocabulary creates neither a system-role kind or assignment nor Work, module relation, authority, or decision claims.
Current FPF A.12, A.2.1, A.15.1, F.6, A.3.4, A.3.4.P, E.18, E.18.NET, A.6.M, C.29, C.30, C.32, C.32.MLAO, and C.32.FAILCurrent ontology for acting Systems, declared system-role-assignment species and their obtaining occurrences, Work, performed-under-assignment attribution, bounded transformation, flow structures and networks, module repair, lens use, architecture relations and claims, candidate synthesis, residual reduction, and failure repair.Recover participants and relations before using Conway wording.Performer rows, influence rows, the C.30 pair assertion, network-qualified reading, and receiving-pattern exits are separately checkable.No root Conway kind, universal correspondence relation, acting architecture, modal architecture promoted to actuality, or bypass around decision, Work, evidence, or network selection.

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.32 for candidate architecture synthesis; C.30 for exact described holons, obtaining ArchitectureRelation occurrences, selected U.Structure participants, and modal ArchitectureClaim content; A.3.4 and A.3.4.P for the continuing changed referent and actual bounded transformation; A.12 for acting-side externalization; A.13 for exact actual-performer recovery; A.15.1 for independent dated-Work admission and distributed-performer forms; A.2.1 for assignment occurrence identity when separately represented; F.6 for a later performedUnderAssignment(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.REL when this episteme consumes occurrence identity; E.18 for one TFS; and E.18.NET for network identity and exact cross-member relations. F.6's holder projection only compares equality with the already recovered performer.
  • Uses: C.32.ACS for current architecture-characteristic criteria rows; C.25 for composite Q-Bundles and their declared slots; C.32.MLAO for a cross-scope residual; C.32.FAIL for a correspondence repair failure; C.29 when structural similarity, preservation, mapping, or equivalence is claimed; and A.6.P.WMR and A.6.RCD when a required direct relation cannot be recovered.
  • Patterns for the next questions: A.19.CPM for explicit comparison, A.19.SelectorMechanism for set-returning selection, G.5 for selected-set result declaration, E.17 for a source-backed publication face and source return, E.24.PUB for the publication occurrence and audience availability, C.18 and C.19 for archive, front, or pool treatment, C.11 for fixed local choice, C.32.PAD for architecture decisions, A.10 for evidence, B.3 for assurance, A.20 or A.21 for gate or release claims, and the direct method, Work, or organization-governance patterns when those claims are current.
  • Network boundary: an ArchitectureInfluenceTransformedArchitectureCorrespondenceRow@Context may be cited as one qualified reading in architectureCorrespondenceRowRefs[]; 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.P2S may 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.

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:

"The local architecture improvement made another scope worse."
"The platform helps product teams but grows evidence exceptions."
"Local agent autonomy conflicts with the control or policy scope."
"The method template speeds authoring and slows review."
"A graph, residual vector, or Pareto front can inform comparison only after selected structures, residuals, losses, and the pattern for the next question are declared; it is not the architecture."

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.

MultilevelArchitectureResidualOptimizationFrame@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  residualOptimizationFrameProjectUseRelationRef?: U.RelationRef defined by the exact synthesis-use or work-use pattern
  describedHolonRef:
  optimizationQuestion:
  objectiveBasisRefs:
  claimScopeRef?: U.ClaimScope
  residualTriageRef:
  declaredHolonLevelRefs?:
  declaredScopeRefs:
  selectedStructureRefs:
  residualBearingLoci:
  candidatePaletteRef:
  architectureCharacteristicCriteriaSetRef?:
  architectureCharacteristicCriteriaRowRefs:
  qBundleRefs?:
  evolutionWindowRef:
  dynamicFrontOrArchiveRef?:
  nqdOrOeeSupportRef?:
  steppingStoneRefs?:
  architectureIdealityPressureRef?:
  scaleAmenabilityPolicyRef?:
  functionBearerFeasibilityRef?:
  architectureInfluenceCorrespondenceRef?: C.32.CONWAY frame or exact pair-row ref
  residualReducingCandidates:
    - candidateRef:
      selectedStructureChanged:
      affectedLevelOrScope:
      affectedArchitectureCharacteristicRefs:
      affectedCriteriaRowRefs?:
      architectureCharacteristicEvalResultRefs?:
      residualReduced:
      newBurden:
      preservedStructure:
      lostOrHiddenStructure:
      sourceReturnCondition:
  comparisonInputRefs?:
  receivingOperationPatternRef?:
  c29LensOutputRef?:
  metaHolonTransitionRef?:
  stopCondition:

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

ForceTension
Local fitA candidate may help one scope while harming another.
Optimization languageObjective, residual, front, and matrix language sounds decisive before the claim is typed.
Declared-level recognitionLevel and scope words are useful only after they are declared as holon-level refs or scope refs, or restored as stratification terms through C.30.STRAT before selected-structure use.
Candidate actionResidual triage must turn into candidate changes when repair work is being performed.
New burdenEvery residual-reducing candidate change creates another cost or loss.

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:

  1. Start from a C.30.ILC-compatible residual triage.
  2. Name the affected declared holon-level refs or declared scope refs and the selected structures that carry the residual.
  3. Name the architecture-characteristic criteria rows and any Q-Bundle slots that make the residual worth reducing.
  4. Create or reference a C.32 candidate palette.
  5. For each candidate, state the residual it reduces, the selected structure changed, and the criteria rows affected.
  6. State the new burden, loss, exception, or source-return load created by that candidate.
  7. 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.
  8. Stop at the frame, or name the pattern for the next question when a later claim is current: use A.19.CPM for explicit comparison, A.19.SelectorMechanism for set-returning selection, G.5 for selected-set result declaration, C.11 for local choice, C.32.PAD for an architecture decision, C.30.AD for architecture-description work, and C.29 for mathematical-lens use. For publication, use E.17 for a source-backed face and return to source, then E.24.PUB for 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.

Candidate change familyUse whenRepair it provides
splitScopeOne scope carries incompatible tempo, functional demand, constraint, or admissibility condition.Separates the conflict and names coordination cost.
mergeScopeMediation creates more burden than separation saves.Removes unnecessary boundary and names coupling risk.
addMediatorDirect cross-scope dependency is brittle.Adds mediation and names mediator failure mode.
addControlStructureRate, feedback, policy, or supervisor conflict persists.Adds or changes control relations, states timing burden, and names any direct control-responsibility predicate with actual participants; if none is admitted, records the exact missing governor instead of inferring responsibility from the control structure.
addInterfaceGrammarVariation grows through unmanaged interface variants.Names allowed variation, conformance expectation, and exception risk.
repairFunctionBearerGapA residual-reducing functional change has no feasible bearer at the affected declared holon-level ref or scope ref.Adds or changes an admitted bearer, splits the function, changes placement, resource access, or control relations, or rejects the candidate. Any responsibility change uses its direct domain predicate or exact missing governor.
addEvidenceScopeReusable candidate bearer lacks reusable evidence scope.Makes evidence maintenance part of the candidate; A.10 evidence-relation validity or sufficiency claims belong to A.10 when they are current.
addWorkMethodScopeRepeated work remains bespoke because method structure is missing.Transfers repeated work into method structure and names review or training burden.
repairArchitectureInfluenceCorrespondenceThe residual is carried by mismatch between one exact typed influence-side architecture source and transformed-side architecture content for the changed referent.Open C.32.CONWAY; keep the changed referent and any actual A.3.4 U.Transformation separate, then prepare candidate alternatives that change the influence-source side, change the transformed side, change both, or keep a bounded mismatch.
acceptBoundedExceptionEliminating the residual costs too much now.Records exception, source-return condition, and reopen trigger.

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

Grounded working caseResidual-bearing locusResidual-reducing candidatesStop condition
Regulated product family where shared platform reduces engineering work but grows certification exceptionsProduct-variant scope against family evidence scope; module-interface and evidence-scope structuresAdd reusable evidence scope; narrow interface grammar; keep bounded exception for one variantStop before assurance, G.5 selected-set result declaration, publication availability, or decision unless those claims are current.
Clinical triage arrangement where local intake speed increases downstream escalation missesIntake scope against hospital escalation scope; proposed triage Systems, procedure or Method structure, escalation relation, and optional kind or assignment requirements kept distinctPropose a mediator System or relation, split triage scope by patient class, and state any assignment requirement as plan or decision content. Retarget responsibility only through an admitted direct predicate or record the exact missing governor. Only after performance occurs, recover every precise performer's A.13 core and independently admit the Work under A.15.1; add F.6 only when precise assignment-bound attribution is current, and add a Work-to-change relation only when that predicate independently obtains.Stop before ethical mediation or staffing decision unless D.3, D.4, or the receiving staffing-decision pattern is current.
AI-agent review setup where local agent quality improves while policy violations increaseAgent task scope against policy-control scope; control and evidence-refresh structuresAdd supervisor relation; narrow model-interface admissibility; change evidence refresh cadenceStop before safety, gate, release, or causal claims unless their subject patterns are current.
ML inference workflow where the searched functional graph improves quality and exceeds edge-device resource limitsFunctional graph against deployment and resource scopes; module-interface, placement, and resource structuresSplit the function, change deployment placement, add a resource bearer, or reject the candidate for this evolution windowStop before release, benchmark, G.5 result declaration, or publication claims unless the definition and test for each current claim are applied.
Method family where template reuse accelerates authoring and creates review residueAuthoring scope against review scope; method-structure and authored-section structuresSplit method variants; add review-evidence scope; accept bounded local method residueStop before method governance, MVPK publication-face governance, or project decision unless the pattern for the next question is current.
Built-asset maintenance program where digital-twin abstraction hides lower-scope source lossAsset-family scope against maintenance activity scope; reference-designation, information, and maintenance-Method or plan structuresAdd source-return scope; split the information view; retarget maintenance responsibility only through its admitted direct predicate or record the exact missing governor. Introduce actual maintenance Work only through its basis: A.13 first, independent A.15.1 Work admission second, and F.6 afterward only for precise assignment-bound attribution.Stop before built-asset architecture-description, publication-face, or A.10 evidence-relation claims unless their subject patterns are current.

Residual And Trade-Off Failure Modes

Failure modeC.32.MLAO repair action
Local improvement shifts the residual elsewhereRecord the scope and selected structure that improved, the scope and selected structure that worsened, and the new burden created.
Universal optimizer is assumedTreat optimization as bounded residual reduction over declared holon-level refs or declared scope refs, with comparison inputs, pattern for the next question, and stop condition.
Proxy result substitutes for comparison or choice claimWhen a score, vector, graph partition, front, DSM, or C.29 lens output is used to prefer a candidate, name the selected structures, preserved structure, lost structure, architecture characteristic, and pattern for the next question.
Level or scale word is not typedRecover level, layer, tier, scope, and scale wording through E.10.ARCH, C.30.STRAT, and C.16.P as applicable; recover BOSC, MHT, MET, MFT, and emergence-family wording through E.10 and B.2.P before declaring holon-level refs, scope refs, scale windows, B.2 whole reidentification, or C.32.MLAO residual claims.
Software-source overfitTreat software examples as domain lineage; admit other holons only after selected structures and affected scopes are recoverable.
Lossless repair is assumedEvery residual-reducing candidate names the new burden it creates.
Front member is treated as durable optimumA front member is an archive or front relation under an evolution window, not a durable architecture optimum.
Stepping stone is erased too earlyKeep retained stepping stones visible through C.18 or C.19 when they preserve future residual-reduction reach.
Architecture-influence residual is hiddenA residual between one typed influence-side architecture source and transformed-side architecture content must open C.32.CONWAY; keep the changed referent and any actual transformation separate, and prepare influence-source-side, transformed-side, joint, and bounded-mismatch candidates as comparison inputs or downstream candidate alternatives.
Ideality is used as optimumTreat ideality as direction for candidate generation, not as an adequacy claim that a bearer may be removed.
Universal bearer is admitted without scale windowA general bearer still needs declared criteria rows, scale window, safety and admissibility boundaries, and an eval result when the claim depends on a reading.
Functional graph has no feasible bearerA functional architecture that lacks feasible bearers is an unfit candidate, not an optimized architecture.

Conformance Checklist

IDRequirementPurpose
CC-C32.MLAO-1The use starts from a recoverable residual triage.Prevents premature optimization.
CC-C32.MLAO-2Affected declared holon-level refs or declared scope refs and selected structures are named.Keeps multilevel wording reviewable.
CC-C32.MLAO-3Each candidate names residual reduced, architecture characteristic affected, and new burden.Prevents one-sided optimization.
CC-C32.MLAO-4Comparison inputs, comparison results, selection results, and choice results name their pattern for the next question.Keeps C.32.MLAO from performing comparison, selection, or choice locally.
CC-C32.MLAO-5Lens-backed claims use C.29 when mathematical-lens use is being claimed.Keeps mathematical adequacy outside this pattern.
CC-C32.MLAO-6Source-return condition is present when compression hides distinctions.Keeps later source-use or decision-use claims tied to recoverable sources.
CC-C32.MLAO-7Evolution window, dynamic front or archive relation, and any NQD or OEE support are typed as retention or generation support only.Blocks static-optimum and selector overread.
CC-C32.MLAO-8Influence-source and transformed-side architecture content stay distinct through exact C.30 holon, obtaining-ArchitectureRelation, selected-structure, or modal-ArchitectureClaim refs; the changed referent and any actual A.3.4 transformation stay separate; C.32.CONWAY is used when correspondence candidates are being prepared.Preserves kind distinction among architecture content, influence, Work, actual transformation, and structural similarity.

Common repair cues

Anti-patternSymptomRepair
LocalEvalAsWholeArchitectureOne scope improves or one eval result is better, and the whole architecture is called better.Return to residual triage; name improved and harmed scopes, selected structures, criteria rows, and residual-bearing locus before framing residual-reducing candidates.
ProxyResultAsPreferenceRuleA residual vector, score, graph, front, dashboard reading, or lens output is used to prefer a candidate before the selected structures and lost structure are recovered.Recover the selected structures and lost structure, interpret the result as a diagnostic signal or lens output; comparison belongs to A.19.CPM, local choice to C.11, set-returning selection to A.19.SelectorMechanism, and selected-set result declaration to G.5.
ParetoFrontAsDecisionA front is treated as selected architecture.Use G.5 for selected-set result declaration, C.11 for local choice, A.19.SelectorMechanism for set-returning selection, 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.
StaticOptimumClaimA current residual-reducing candidate is called optimal without an evolution window.Add evolution window, source-return condition, reopen trigger, and the pattern for the next question result that actually produced the preference.
ArchitectureInfluencePairCollapseThe influence-source and transformed-side architecture content, changed referent, or actual transformation are treated as one object.Open C.32.CONWAY; recover each exact C.30 architecture side, the typed influence relation, the changed referent, any actual A.3.4 transformation, the residual-bearing locus, candidate alternatives, and any C.29 structural-similarity claim before residual framing.
LevelWordsNoLevelsText says level or scope without declared refs.Use C.30.STRAT for stratification-term recovery or B.2.P for whole-reidentification wording, then return to residual triage before candidate framing.
OptimizationNoLossCandidates show only gains.Add new burden, known loss, or bounded exception.
IdealityNoBurdenA candidate removes a bearer or support function but does not name lost function, coupling, evidence, control, or source-return burden.Use C.32 and C.31; name function-bearing transfer, characteristic changes, and BLP scale window or waiver if scale advantage is claimed.
FunctionNoBearerAtScopeA functional change reduces one residual but no admitted bearer can carry it at the affected scope under resource, placement, control, or evidence constraints.Add or change the bearer, split the function, change placement, resource access, or control relations, reduce the demand, or reject the candidate. Any responsibility claim uses its direct predicate or exact missing governor.

Consequences

Positive consequenceCost or trade-off
Residual-reducing architecture candidates are made explicit.The practitioner must name the affected levels or scopes, selected structures, residuals, preserved structure, lost structure, new burdens, and the pattern for the next question for any comparison or choice claim. Use C.30.STRAT or B.2.P first when level wording or whole-reidentification wording is not yet typed.
Optimization language is usable without carrying architecture adequacy.No scalar selector or architecture decision is available by wording alone.
Holonic breadth is preserved.Non-software cases must still recover their selected structures and patterns for the next questions.
Residual triage and candidate framing stay distinct.The team may need both C.30.ILC and C.32.MLAO.
Compressed representations can guide action.Source-return triggers must be visible.

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 to inspectWhy this source is load-bearing hereTransfer into C.32.MLAOConcrete C.32.MLAO mutationBlocked overread
Current FPF architecture residual, criteria, eval, comparison, and level-recovery line: E.10, E.10.ARCH, C.30.STRAT, B.2.P, B.2, C.30.ILC, C.32.ACS, C.32.ACE, A.19.CPM, A.19.SelectorMechanism, C.11, G.5, C.29, C.31, C.31.ASAP, and architecture source section 15.3Current local law for interlevel and cross-scope architecture residuals. C.32.MLAO starts only after residual triage; use the applicable patterns to recover criteria, eval, stratification terms, whole reidentification, comparison, selection, choice, and selected-set result declaration.Require C.30.STRAT recovery when stratification wording is ambiguous and B.2.P recovery when BOSC, MHT, MET, MFT, or emergence wording is ambiguous. Before residual-reducing candidates enter comparison, selection, choice, or selected-set result declaration, require declared holon-level refs or scope refs, selected structures, criteria rows, residual-bearing loci, preserved and lost structure, eval result refs when used, comparison inputs, and the pattern for the next question.MultilevelArchitectureResidualOptimizationFrame@Project requires residual triage, declared holon-level refs or declared scope refs, selected structures, architecture-characteristic criteria rows, residual-bearing loci, residual-reducing candidates, optional C.29 lens-output ref, comparison input refs, pattern for the next question ref, and stop condition.Same-scope structure conflict, generic complexity wording, untyped criteria, eval-result overread, untyped stratification terms, untyped BOSC or MHT triggers, local comparison work, local selection work, and untyped optimization phrases require the exact subject predicates before C.32.MLAO admits the frame.
Vanchurin, Wolf, Katsnelson, and Koonin, Towards a Theory of Evolution as Multilevel Learning (https://arxiv.org/abs/2110.14602); Wolf, Katsnelson, and Koonin, Physical foundations of biological complexity (https://arxiv.org/abs/1803.09975); Akhtyrchenko, Katsnelson, and Ustyuzhanin, Directing Open-Ended Evolution ... via Multi-Scale Path Divergence, submitted 2026-06-12 (https://arxiv.org/abs/2606.17091)Current source line for multilevel residual and scale-dependent frustration as a mathematical lens. The 2026 MSPD paper is current because it makes scale-dependent frustration explicit and computable while still being a lens over a substrate.Use frustration and multiscale divergence as optional C.29-backed lens outputs for residual-bearing loci across declared holon-level refs or declared scope refs.C.32.MLAO adds c29LensOutputRef?, residual-bearing locus, preserved and lost structure, comparison input refs, and pattern for the next question ref so any comparison has its pattern for the next question named.Source-domain ontology stays outside architecture; a scalar output must be interpreted as pressure, loss, or residual over selected structures before a receiving comparison or choice pattern can use it.
Evolutionary architecture: Ford, Parsons, Kua, and Sadalage, Building Evolutionary Architectures, 2nd ed. (https://www.oreilly.com/library/view/building-evolutionary-architectures/9781492097532/)Current practitioner architecture line for guided incremental change over declared architecture characteristics, affected selected structures, and feedback from source-side fitness functions.Residual-reducing candidates must name the new burden they introduce and the stop or reopen condition; source-side fitness-function practice is restored as ACE eval programs over ACS criteria rows.Candidate-family table includes bounded exception, evidence scope, interface grammar, control structure, and work-method scope; consequences require new burden, source-return triggers, and receiving use for eval results.A local eval improvement needs an architecture interpretation before a comparison, selection, or choice pattern for the next question can use it.
TRIZ ideality and laws of technical-system evolution, read with C.19.1 BLPOlder heuristic line: systems tend toward more useful function with less cost, harm, and support apparatus; BLP supplies FPF scale-amenability discipline for general bearers.Use ideality and scale amenability to generate residual-reducing candidates, not to select them.Frame adds architectureIdealityPressureRef? and scaleAmenabilityPolicyRef?; Solution adds ideality and BLP discipline; anti-pattern table adds IdealityNoBurden.Removing a part, consolidating functions, or choosing a universal bearer is not residual reduction unless selected structures, characteristics, new burden, and scale boundary are declared.
Multi-objective and hardware-aware NAS: Elsken, Metzen, and Hutter 2019 (https://www.jmlr.org/papers/v20/18-598.html); Sukthanker et al., v3 revised 2025-02-04 (https://arxiv.org/abs/2402.18213); Sinha et al. 2024 (https://arxiv.org/abs/2404.12403)Current architecture-search line where functional graph candidates are judged against hardware, latency, cost, and transfer constraints; useful as a general co-design lesson beyond ML.Residual-reducing candidates that change functional structure must also name feasible bearers at affected scopes.Frame adds functionBearerFeasibilityRef?; Solution adds functional-bearer feasibility discipline; candidate-family table adds repairFunctionBearerGap.A functional graph, resource score, or Pareto member is not residual reduction if no admitted bearer can carry the function.
Architecture trade-off practice and Software Architecture: The Hard Parts (https://www.oreilly.com/library/view/software-architecture-the/9781492086888/)Best current practitioner line for no-best-practice architecture decisions and explicit trade-off analysis in hard architecture problems.Frame each candidate as residual reduced plus burden created, not as a universal best answer.Candidate rows require residualReduced, newBurden, preservedStructure, and lostOrHiddenStructure; final choice requires C.11 or C.32.PAD.A trade-off scenario, ranking, or preferred decomposition is not a decision inside C.32.MLAO.
DORA loosely coupled teams, last updated 2025-10-20 (https://dora.dev/capabilities/loosely-coupled-teams/), DORA trunk-based development (https://dora.dev/capabilities/trunk-based-development/), and Team Topologies key concepts (https://teamtopologies.com/key-concepts)Current socio-technical practice for independent change, testing, deployment, small batches, dependency reduction, and fast flow. It is load-bearing because many residuals concern organization relations, proposed Systems or assignments, ordinary work or procedure organization, actual Work, direct responsibility relations, and coordination structures, not only software modules.Admit organization, local-kind, separate System-classification, assignment, responsibility, coordination, Method, plan, and actual-Work residuals only when their selected structures, direct predicates, affected scopes, and modal or actual status are recoverable.Worked cases include clinical triage, AI-agent review, and a Method family; candidate families include mediation, Method or plan scope, interface grammar, and control structure.Organization-design observations enter C.32.MLAO only after mapping to Systems and relations. Assignment supplies no responsibility, capability, function bearing, or Work, and observations supply no module, evidence, assurance, or decision claims.
Design-space and architecture-spread research: Shaw and Petre 2024 (https://arxiv.org/abs/2407.18502); Cortellessa et al. 2024 (https://arxiv.org/abs/2402.19171)Current research showing that useful alternatives need a design-space or architecture-space view, not only objective-space scores.Preserve plural residual-reducing candidates when residuals shift differently across structures or scopes.The frame preserves candidate plurality as C.32 input; use G.5 for selected-set result declaration. Use spread, diversity, or objective-space output only after naming the architecture differences it reveals.Candidate preference still depends on declared architecture characteristics, losses, and a pattern for the next question.
C.18 archive and front stewardship plus C.19 explore-exploit governanceCurrent FPF pattern line for open-ended search, NQD, OEE, archive, front, pool treatment, and stepping-stone retention.Treat NQD and OEE as generation and retention support for residual-reducing candidates, not as architecture selection.Frame fields add dynamicFrontOrArchiveRef?, nqdOrOeeSupportRef?, steppingStoneRefs?, and evolutionWindowRef; Solution adds dynamic optimum discipline.Archive membership, front membership, retained stepping stone, or pool treatment is not architecture adequacy or decision.
Conway's law, mirroring, DORA loosely coupled teams, Team Topologies, and current C.32.CONWAYCurrent practice line for residuals where one typed Work, communication, tool, method, deployment, evidence, selected-structure, or architecture-side source no longer fits the transformed-side architecture content needed for the changed referent.Treat architecture-influence correspondence mismatch as a residual-reducing synthesis problem, not as actor identity, Work attribution, transformation participation, or transformed-side architecture settlement.Frame field architectureInfluenceCorrespondenceRef? points to C.32.CONWAY; candidate-family table adds repairArchitectureInfluenceCorrespondence; Solution keeps the two exact C.30 architecture sides, changed referent, actual transformation when claimed, and influence relation separate while preparing influence-source-side, transformed-side, joint, and bounded-mismatch candidates.A correspondence residual is repaired only after the shifted burden, affected structures, characteristic pressure, exact influence basis, and exception cost are named.

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.ILC for residual triage, C.32 for palettes, C.32.ACS for architecture-characteristic criteria rows, C.32.ACE for eval programs and eval results, C.29 for mathematical-lens use when claimed, A.19.CPM for explicit comparison, A.19.SelectorMechanism for set-returning selection, C.11 for local choice over an existing option set, G.5 for selected-set result declaration, C.19.1 for scale-amenability preference claims, and C.31 or C.31.ASAP for characteristic or scale-preference claims.
  • Uses: E.10.ARCH and C.30.STRAT when stratification terms hide the recovered neighborhood; E.10 and B.2.P when BOSC, emergence-family, MHT, MET, MFT, boundary-crossing, or promotion-like wording hides the claim kind; B.2 when the candidate creates, reidentifies, splits, joins, or changes the relevant whole after existing-whole explanations are insufficient; C.32.CONWAY when 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.CPM for explicit comparison, A.19.SelectorMechanism for set-returning selection, G.5 for selected-set result declaration, C.11 for fixed local choice, C.30.AD for architecture-description work, E.17 for a source-backed publication face and source return, E.24.PUB for the publication occurrence and audience availability, and C.32.PAD for project architecture decisions.
  • P2S docking: C.32.P2S uses 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.

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: PracticeArchitectureSynthesisFromSeveralStructures Plain-name: build one usable practice architecture from several structures that do not line up one-for-one Type: Method-description pattern under C.32 Status: 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.32 when 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.ILC and C.32.MLAO when 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.

  1. 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.
  2. 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.
  3. 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

ForceTension to hold
One answer vs several structuresThe decision needs a coherent account, while the useful structures may remain non-isomorphic.
Actual practice vs prospective designObtaining Work offers dated evidence; a possible-future practice needs a truthful realization and later-test account instead.
Precision vs readable entryExact kinds and relations prevent false claims; notation-first prose can make the Method unusable to the practitioner who needs it.
Candidate breadth vs proportional effortThe first source layout is rarely enough; an unlimited candidate search can delay the decision without changing it.
Local gain vs moved burdenOne structure can improve while another inherits cost, delay, evidence burden, loss of control, or unresolved residual.
Project choice vs cultural changeA project can deliberately choose or change an arrangement; distributed generation, transmission, selection, retention, and loss are different claims.
Reusable Method vs domain fillingThe action sequence transfers across domains; actual domain Methods, institutions, evidence, constraints, and cases remain with the receiving domain.

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Reidentify a whole when needed. Use B.2 when 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.
  7. 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.
  8. 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:

Current architecture question:
Entry: obtaining practice / possible-future practice
Representative occurrence or prospective anchor:
Useful result at stake:
Selected structures and the relations used:
Practice-description correspondences and losses:
Genuinely different alternatives:
Main conflict and any moved residual or burden:
Alternative that changes the current decision:
Source-return or later-test condition:

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:

  1. one domain DPF;
  2. independently maintained sibling DPFs;
  3. direct use of FPF plus exact domain sources; and
  4. 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.

LensLikely driftRepair
GovThe synthesis is treated as a decision, authorization, accepted product boundary, published result, or current practice.State the next use and apply the separate decision, publication, acceptance, or currentness pattern only when that claim is current.
ArchOne source stack, lifecycle, matrix, or preferred view becomes the architecture.Select only structures that change the question; recover their relations and correspondences; retain non-isomorphism.
Onto-EpistA model, description, row, level label, or future design is treated as the practice or an obtaining relation.Name the subject and participant kinds, distinguish obtaining from prospective, and state what each description preserves and loses.
PragThe synthesis becomes a large mandatory dossier or a relation inventory no decision uses.Start with the short result; add a view or formal check only when it changes the current decision or prevents a demonstrated overread.
DidFormal notation and specialist ontology appear before the working situation and first useful result.Use ordinary case language first, give nearby plain glosses for necessary FPF terms, and keep symbolic assurance optional.

Conformance Checklist

CheckPassing observation
CC-MWA-1 — Recognizable useThe opening names a current decision that needs one answer across several structures, plus an ordinary non-use boundary.
CC-MWA-2 — Truthful entryThe synthesis explicitly chooses obtaining or possible-future practice. An obtaining entry has representative performed Work; a prospective entry has an intended-use or plan anchor, realization condition, and later-test condition without fictitious Work.
CC-MWA-3 — Subject before layoutThe subject and participant kinds are recoverable before source rows, levels, or positions are interpreted.
CC-MWA-4 — Candidate differenceAlternatives differ by decision use or unlike-case failure, not merely wording or picture layout; when NQD is current, novelty, use-value, and diversity remain distinct.
CC-MWA-5 — Relation recoveryEvery relation used in the answer is stated by value and supported through its defining or constraining pattern when material. Order is not overlap; overlap is not parthood; co-use is not Method composition.
CC-MWA-6 — Practice-description separationPractice wholes and relations remain distinct from descriptions, models, views, and coarse-graining; important preserved and lost distinctions are stated.
CC-MWA-7 — Whole reidentificationA Method, Work, System, Discipline, or selected structure is reidentified when the old whole cannot carry the claim.
CC-MWA-8 — Conflict and moved burdenThe main conflict is named and every claimed local improvement states any material residual or burden moved elsewhere.
CC-MWA-9 — Conditional product branchThe four product arrangements are compared when product identity is current and omitted when it is not; the comparison itself selects no product.
CC-MWA-10 — Deliberate/distributed distinctionProject choice and intervention remain distinct from cultural generation, transmission, recognition, selection, retention, and loss.
CC-MWA-11 — Usable resultA cold reader can recover the short synthesis, the decision-changing alternative, the next use, and the stop or reopen condition without reading symbolic assurance first.
CC-MWA-12 — Unlike groundingAt least two unlike cases test the Method, and a prospective case is used whenever the candidate claims it can synthesize possible-future practice.

Common Anti-Patterns and How to Avoid Them

Anti-patternWhy it failsRepair
Copy the source stackPrinted order can be chapter order, explanation order, Method order, Work order, subject grouping, or nothing architectural.Name the subject and recover each relation before retaining a structure.
Fictitious representative WorkA proposed practice acquires false evidence and false actuality.Use an intended-use case, WorkPlan, or other prospective account; state realization and later-test conditions.
One view set for every practiceA convenient template becomes a universal ontology and imports irrelevant work.Always keep the identity-and-relation check; add other structures only when they change the decision.
Synonyms as alternativesSeveral names hide one unchanged organization and create false diversity.State what decision, relation, or unlike-case result differs; merge candidates that differ only by labels.
Local win, invisible burdenThe apparent improvement exports cost, delay, evidence, control, or residual to another structure.Name the receiving scope and compare the moved burden with the claimed gain.
Product comparison everywhereThe Method becomes framework-product design even when practice architecture is the only question.Open the four-option branch only when product identity is current.
Product comparison nowhereA live field or maintenance boundary is hidden inside a favored architecture.Compare the four arrangements and pass the result to the applicable product decision.
Model equals practiceA view or matrix is treated as a world-side whole or relation.State the described subject, model use, correspondence, and preserved and lost distinctions.
Project choice equals cultural successA deliberate intervention is taken as proof of later recognition, spread, selection, or retention.Keep the project claim and each cultural-change claim separate; use C.36 for the latter.
Notation as the first resultThe account becomes precise but unusable to the practitioner who must act on it.Lead with the short prose synthesis; retain notation only where it catches a real ambiguity or supports a later check.

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.

Source lineContribution and limitDecision and transfer into this pattern
ISO/IEC/IEEE 42010:2022, current architecture-description standardDistinguishes the architecture of an entity from an architecture description and supports concerns, viewpoints, model kinds, and correspondences. It explicitly does not specify an architecting Method and is not a system or practice ontology.Adopt narrowly: keep subject, architecture, description, view, and correspondence distinct. Reject: treating standard conformance or a view set as the practice architecture. Carried into actions 2, 4, and 5 and CC-MWA-3/5/6.
Grootenboer and Edwards-Groves, The Theory of Practice Architectures (2024), and Olney and Wood, learning-design practice study (2023)Current practice-research line showing that professional practice is shaped across multiple sites and material-economic, cultural-discursive, and social-political arrangements. It gives a strong empirical antidote to procedure-only accounts, but its three media are one theory's selected structures rather than universal FPF kinds.Adopt: multi-site, enabling/constraining, and empirical-practice attention. Adapt: recover the actual Method, Work, subject, description, capability/provider, and cultural relations needed by the case. Reject: importing the three media as a mandatory universal view set. Carried into Forces, Grounding, action 4, and the limited-scope bias.
Alter, Work System Theory (2013), established work-system lineProvides a practitioner-readable way to examine participants, activities, information, technologies, products/services, customers, environment, infrastructure, and strategy together rather than reducing work to IT or a process chart. Its fixed framework is valuable for recognition but does not distinguish every FPF Method, Work, description, capability, and cultural relation.Adapt as recognition lineage: start from useful Work and its result and look beyond one technical structure. Reject: treating the nine elements as a complete or mandatory practice ontology. Carried into Problem frame, actions 1–2, and obtaining cases.
Bartolomei et al., Engineering Systems Multiple-Domain Matrix (2012), with DSM/DMM lineageOrganizes source-side node classes in diagonal blocks and relation types within and between those classes in off-diagonal blocks; it supports tagging, storing, retrieving, and analyzing engineering-system information. It is engineering-modeling lineage, not current authority for practice ontology, and its source categories are not universal FPF kinds.Adopt as lineage: make the source-side class and relation type visible when several structures are compared. Adapt: recover each exact receiving relation or correspondence, state what it preserves and loses, use ordinary prose first, and add a matrix only when it helps the decision. Reject: row alignment, matrix membership, or visual clustering as a world-side relation. Carried into actions 3–7 and the layout/model anti-patterns.
Current FPF A.3.1, B.1.5, A.15.1, B.2, C.30, C.30.AD, C.30.ILC, C.32, C.32.MLAO, and C.36Supplies the maintained distinctions among Method, performed Work, whole reidentification, architecture, description, conflict, candidate synthesis, moved residual, and cultural change.Adopt and compose: these patterns provide the exact tests used by the eight actions. C.32.MWA adds the obtaining/prospective discriminator, several-structure synthesis, conditional product comparison, and one readable result; it does not redefine the neighboring kinds or relations.

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.1 for Method identity, B.1.5 for Method order/composition and Work enactment distinctions, A.15.1 and F.6 for actual performed Work and attribution when claimed, B.2 for whole reidentification, C.30 and C.30.AD for architecture and architecture-description distinctions, and C.36 for cultural-change relations.
  • Coordinates with: base C.32 for general architecture candidate synthesis; C.17 and C.18 only when NQD generation, novelty/diversity, archive, or front claims are current; C.30.STRAT before accepting level, layer, tier, stack, or similar source wording; and C.30.ILC plus C.32.MLAO when a conflict, residual, or moved burden needs its own treatment.
  • Provides a result to: E.4.PFAD when several practice structures change a framework-architecture answer; E.4.DPF when those structures change DPF identity, scope, pattern organization, first use, or use of named results; E.4.DPF.DA when package adequacy needs the resulting two-way sequence-versus-simultaneity evidence; and E.23.CDI only when target-practice architecture must be recovered or compared before capability development.
  • Does not replace: the direct domain sources and Methods, E.4 product-family decisions, explicit comparison or selection, project architecture decision, E.24.PUB publication occurrence and availability, evidence or assurance, or the currentness and refresh patterns.

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:

"This looks modular, but changes still cross hidden dependencies."
"The model is called a module, but the interface is weak."
"The platform promise hides exception growth."
"The search picked a winner, but the alternatives and losses disappeared."
"The graph looks convincing, but we cannot say which architecture object it repairs."

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:

ArchitectureRepairCue@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureRepairCueProjectUseRelationRef?: U.RelationRef defined by the exact repair-use or work-use pattern
  symptom:
  describedHolonRef:
  architectureClaimRef?:
  architectureConcern:
  intendedRepairUse:
  claimScopeRef?: U.ClaimScope
  qualificationWindowRef?:
  architectureObjectUnderStress:
  selectedStructureRef?:
  sourceCueRef?:
  failureEvidenceRefs:
  blockedOverread:
  firstPatternLocator:
  repairAction:
  sourceReturnCondition:
  stopCondition:
  escalationIfCurrent:

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.

symptom -> architecture object under stress -> blocked overread -> first subject pattern -> repair action -> stop or escalation

Use C.32.FAIL for that conversion. It does not mint a local ontology of failure kinds.

Forces

ForceTension
Fast recognitionPractitioners need short warning cues while the repair object is still unclear.
Object recoverySource expressions and domain habits can hide the architecture object under stress.
Repair localityThe first useful repair action should change architecture handling, not open a broad audit.
Neighboring claim patternsEvidence, assurance, gate, release, selection, and decision claims may be nearby but governed elsewhere.
Cue inflationWarning rows can multiply without improving repair unless admission requires a concrete repair action.

Solution

Convert the warning cue into an ArchitectureRepairCue@Project. Work in six steps:

  1. State the symptom in ordinary practitioner language.
  2. 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.
  3. State the blocked overread that would lead the team astray.
  4. Name the first subject pattern for the architecture object or lens relation.
  5. Propose the smallest repair action that changes architecture handling.
  6. 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:

Repair familySymptomArchitecture object under stressFirst repair actionStop or pattern for the next question
Weak module-interfaceA source-side bearer is called a module because it has a convenient boundary.Candidate module-interface relation and selected structure boundary.Recover interface behavior, admissible-use boundary, change policy, and interface-conformance witness.Stop at repaired interface cue; module-interface structure claims belong to A.6.M, C.30.ASV, or C.31 when current.
False platformA reusable-structure promise hides variation pressure and local exceptions.Variation structure, substitution policy, evidence scope, and exception boundary.Recover variation slots, substitution rules, substitution-conformance checks, and exception-growth trigger.Cross-scope residual work belongs to C.32.MLAO when current.
Hidden single winnerA comparison or generation result is treated as selected architecture.Candidate palette and retained alternatives.Rebuild the C.32 palette with candidate gain, loss, preserved structure, hidden structure, and source-return condition.State explicit comparison under the A.19.CPM predicate, set-returning selection under A.19.SelectorMechanism, selected-set result declaration under G.5, local choice under C.11, and a project architecture decision under C.32.PAD. For publication, state the E.17 source-backed face and source return separately from the E.24.PUB occurrence and audience availability.
Proxy result or description as authorityA score, graph, residual vector, generated output, architecture-description artifact, or MVPK publication face is used to accept or prefer an architecture candidate before the selected structure and pattern for the next question are named.Candidate architecture claim and selected-structure relation hidden behind the proxy, description, or visible result.Recover the selected structure, source-side referent, view relation, or lens-output relation first. Use C.29 for lens output, C.30.ASV or C.30.AD for view or description use, A.19.CPM for comparison, C.11 for local choice, A.19.SelectorMechanism for set-returning selection, and G.5 for selected-set result declaration. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the occurrence and audience availability.Stop when the visible work product only orients repair; evidence claims belong to A.10 and assurance claims belong to B.3.
Coordination cost displaced by responsibility changeA change in ordinary work organization or a responsibility relation improves local flow while pushing coordination into module interfaces, shared test, evidence, approval, or deployment structures.Team or organization System and its relations; coordination relation; module-interface, evidence, deployment, Method or plan structure; and, only when current, local kind, separate System-classification judgment, assignment, enactor relation, and actual Work network.Recover the shifted coordination cost and the structure under stress. If responsibility retargeting is claimed, name its direct predicate, old and proposed participants, and occurrence identity or return missing-governor; then decide whether the architecture repair belongs to C.32.CONWAY, A.6.M, or C.32.MLAO.Route unresolved role wording through E.10.ROLE. Keep ordinary work organization, Method or plan structure, local kind, separate System-classification judgment, assignment, enactor relation, dated Work, and responsibility as separate branches under their subject patterns.
Temporal or control couplingNamed parts need brittle timing or control coordination.Temporal relation, control relation, and affected work or evidence relation.Recover the timing or control constraint and ask whether a candidate architecture change affects the selected structure.Temporal adequacy claims belong to C.27, control or mechanism placement claims belong to the governing mechanism pattern, and flow-structure claims belong to E.18 when current.
Evidence jumpThe team asks for more evidence before naming the architecture repair.Architecture object whose evidence relation may be stale, misplaced, or bearer-dependent.Name the architecture repair first, then record the A.10 evidence relation, source-currentness relation, bearer, scope, and decision-use boundary.Evidence relations belong to A.10, assurance to B.3, and gate or release claims to A.20 or A.21 when those patterns are current.
Generated output as authorityA generated architecture-looking output is treated as carrying an authority relation for architecture adequacy.Source cue, generated description, candidate selected structure, and evaluation boundary.Treat the output as a source cue; recover source-side referent, selected structure, architecture-change kind, gain, loss, and human review boundary.Use C.32 for candidate generation and C.30.AD for generated-description use. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the occurrence and audience availability.
Single-structure synthesisOne selected structure is improved and called the architecture synthesis.Synthesis structure map and architecture characteristic bundle.Use C.32; name the other selected structures that must be coordinated and the architecture characteristics that make the trade-off real.Stop at repaired C.32 palette, or open C.32.MLAO if the failure crosses scopes.
User function as architecture characteristicA user-visible function is treated as the architecture quality being optimized.Functional demand, architecture characteristic, and quality bundle boundary.Recover the function through A.6.F or C.30.ASV; then name the architecture characteristic or C.25 quality bundle separately.Stop before comparison until function and characteristic occupy distinct fields.
Function with no feasible bearerA function graph, workflow, use case, method step, or neural cell graph names a required function that no admitted bearer can perform under the current constraints.Functional demand, candidate bearer set, module-interface relation, placement or deployment relation, resource access, control relation, and evidence burden.Use C.32. Possible first repairs include adding or changing a bearer, splitting the function, changing placement or resource access, changing control responsibility, reducing demand, or rejecting the candidate.Stop before comparison, G.5 selected-set result declaration, publication availability, assurance, or decision claims.
Static optimumA front member or local winner is treated as durable optimum.Evolution window, pattern for the next question result, front or archive relation, and reopen trigger.Add evolution window, source-return condition, and pattern for the next question; keep C.18 and C.19 as retention or pool policy only.Use A.19.CPM for comparison, A.19.SelectorMechanism for set-returning selection, C.11 for local choice, G.5 for selected-set result declaration, and C.32.PAD for an architecture decision. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the occurrence and audience availability.
Ideality shortcutFewer bearers or fewer modules is treated as architecture improvement by itself.Function-bearing allocation, selected structure count, and architecture characteristic bundle.Recover the function-bearing transfer; name the removed or generalized bearer, the functions still carried, the new burden, and lost structure.Use C.32; use C.31, A.6.F, A.6.M, and C.19.1 when their claims are current.
Universal bearer as adequacy shortcutA universal module or general substrate is treated as architecture adequacy or scale adequacy by itself.Scale-amenability claim, module-interface relation, evidence burden, control burden, and safety or admissibility boundary.Treat universality as a candidate; require BLP scale window or waiver when scale advantage is claimed and record coupling, evidence, control, and source-return effects.Stop before G.5 selected-set result declaration, actual publication, assurance, release, or decision claims unless patterns for the next questions are current.
Mismatch between architecture influence and transformed-side structureAn influence-source architecture is collapsed with transformed-side architecture content, a desired transformed-side structure is paired with no compatible influence-source arrangement, or an architecture or selected structure is treated as the changing actor.The exact changed referent; each influence-source-side and transformed-side obtaining C.30 ArchitectureRelation or modal ArchitectureClaim; and the direct architecture-influence or correspondence occurrence only when independently governed and obtaining.Open C.32.CONWAY; recover the two exact architecture sides, the direct influence kind and predicate or missing-governor, and then prepare influence-source-side, transformed-side, joint, or bounded-mismatch candidates. Add acting systems, assignments, Work, and actual transformation only through their subject patterns when those claims are current.Use A.6.M only for module-interface repair, C.29 only when structural similarity is claimed, and E.18.NET only for an independently selected network; a C.32.CONWAY frame or exact pair row is neither an actor, network, nor cross-flow occurrence.

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

Failure modeC.32.FAIL repair action
Warning name without repair actionA warning row is useful only when it names the architecture object under stress and the first repair action. Otherwise keep the warning name out of the pattern.
Architecture repair skipped for evidence or assuranceEvidence may be needed, but the first repair action is still to name the architecture object under stress and the candidate change. Evidence and assurance claims belong to their subject patterns after that.
Decision jumpA repair cue does not select an architecture. Rebuild the candidate palette or residual frame before G.5 selected-set result declaration, actual publication, choice, or decision work.
Source expression substitutes for architecture objectA source term, method word, benchmark result, or generated output starts recovery; it does not govern the architecture claim until selected structures and characteristics are named.
Software-source overfitSoftware and AI sources can supply strong repair actions, but the action must be translated to selected structures of the described holon.
Description carrier substitutes for repairArchitecture descriptions and publication faces can make the problem visible, but they do not repair architecture unless the selected architecture object under stress and repair action are named.
Function and characteristic collapseUser functions and architecture characteristics must occupy distinct fields before comparison or repair.
Function without bearerA functional architecture is only a candidate when admissible bearers are recoverable under current constraints.
Ideality used as deletion admissibilityIdeal final result wording is a generation pressure; deleting a bearer is admissible only after function bearing, lost structure, new burden, and architecture characteristics are named.
Universal bearer admitted by nameA universal module or general substrate must be treated as a candidate bearer under BLP scale-window discipline and declared architecture-characteristic criteria rows.
Conway wording without correspondence repairConway, mirroring, or inverse-Conway wording is useful only when it opens C.32.CONWAY and names the changed referent, each exact obtaining C.30 architecture relation or modal claim, the direct influence relation and its truthful disposition, affected architecture characteristics, candidate form, gain, loss, and pattern for the next question. Architecture influence supplies no actor, assignment, Work, actual transformation, network membership, or cross-flow relation.

Conformance Checklist

IDRequirementPurpose
CC-C32.FAIL-1The cue states a recognizable symptom in practitioner language.Keeps the pattern usable at first contact.
CC-C32.FAIL-2The described holon, architecture claim when current, architecture concern and intended repair use, architecture object under stress, failure evidence, and any material scope or qualification window are named.Prevents source wording or a generic context field from replacing object recovery.
CC-C32.FAIL-3The blocked overread is stated in one sentence.Makes the failure precise enough to repair.
CC-C32.FAIL-4The first subject pattern is named.Keeps architecture, lens, work, evidence, assurance, and decision claims distinct.
CC-C32.FAIL-5The repair action changes architecture handling.Prevents warning-only rows.
CC-C32.FAIL-6The stop condition or pattern for the next question is named.Keeps the cue lightweight and composable.
CC-C32.FAIL-7New cue rows name the architecture object, first repair action, and stop or pattern for the next question.Prevents warning-bank inflation.

Common repair cues

Anti-patternSymptomRepair
WarningNameOnlyA memorable warning name does not change the next repair action.Add the architecture object, blocked overread, subject pattern, and repair action, or remove the row.
EverythingIsFailureCueAny architecture worry is admitted as a C.32.FAIL cue.Admit only recurring failures that change the first architecture repair action.
AuditPromptAsPatternThe row says to measure, review, or audit.Demote it unless it names the architecture object and repair action first.
EvidenceAsRepairMore evidence is treated as the repair.Name the architecture repair first; evidence may follow under its own pattern.
DecisionInsideRepairCueThe cue says which architecture to choose.Local choice belongs to C.11; project architecture decision belongs to C.32.PAD after the candidate repair is available.
DescriptionCarrierAsRepairA diagram, report, dashboard, or publication face is treated as the repair.Use C.30.AD for description use, E.17 for a source-backed publication face and source return, and E.24.PUB for the publication occurrence and audience availability. Keep dashboard, report, or generated-carrier use under its source-use or publication relation. Keep C.32.FAIL only if an architecture object under stress and repair action are named.
FunctionAsQualityA function such as teach, compute, certify, or regulate is treated as the architecture characteristic.Recover the function under A.6.F and name the separate architecture characteristic or quality bundle.
FunctionalGraphNoBearerA functional graph, workflow, or method structure names a required function that no admitted bearer can perform under the module, placement, resource, control, or evidence constraints declared for the case.Use C.32; add or change bearer, split function, change placement or resource access, change control responsibility, reduce demand, or reject the candidate.
IdealityAsAdequacyShortcutThe phrase ideal architecture, no modules, or fewer parts is used as architecture adequacy by itself.Convert it into a C.32 candidate and name function bearing, lost structure, new burden, architecture characteristics, and pattern for the next question.
UniversalBearerAsAdequacyClaimA universal module, general substrate, or existing resource is used as better architecture because it can carry more functions.Use C.19.1 only when scale advantage is claimed. Otherwise recover module-interface, coupling, evidence, control, safety, admissibility, and source-return effects before stating an explicit comparison under A.19.CPM, local choice under C.11, set-returning selection under A.19.SelectorMechanism, or selected-set result declaration under G.5. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the occurrence and audience availability.
ConwayNameAsRepairA warning row says Conway, mirroring, or inverse Conway but gives no architecture repair.Open C.32.CONWAY; name the changed referent, the exact influence-source-side and transformed-side C.30 architecture relations or modal claims, the direct influence kind/predicate/occurrence or truthful stop, affected characteristics, candidate form, gain, loss, and pattern for the next question. Keep actors, assignments, Work, actual transformation, and any E.18.NET network or cross-flow occurrence with their subject patterns.

Consequences

Positive consequenceCost or trade-off
Failure recognition produces repair action.Many tempting warning rows are rejected.
Repair stays near the architecture object under stress.The team may need to postpone evidence, assurance, or decision work.
Source expressions can be used as cues without carrying ontology.Each cue must recover the described holon and selected structure.
C.32 candidate repair stays separate from final selection.Selected-set result declaration, actual publication, or choice requires the pattern for the next question.
Generated or tool-derived architecture material can widen discovery.Generated material must still recover source-side referent, selected structures, architecture-change kind, gain, loss, and human review boundary before candidate use.

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 to inspectWhy this source is load-bearing hereTransfer into C.32.FAILConcrete C.32.FAIL mutationBlocked overread
Current FPF architecture kernel: C.30, C.30.AD, C.30.ASV, C.31, C.32, C.32.MLAO, plus A.6.P and E.10Current local law for architecture objects, source-expression recovery, and candidate repair. It prevents failure names from becoming ontology.Treat a failure cue as repair-entry material until described holon, selected structure, object under stress, and subject pattern are recovered.ArchitectureRepairCue@Project now requires architectureObjectUnderStress, blockedOverread, firstPatternLocator, repairAction, and sourceReturnCondition.A warning name, source expression, or domain habit is not an architecture kind.
Parnas information hiding (https://doi.org/10.1145/361598.361623), MOSA and open-systems practice (https://www.cto.mil/sea/mosa/), product-line and platform practice, and the current C.31 source lineStrong architecture lineage for stable boundaries, hidden variation, replacement policy, and interface conformance.Repair weak-module and false-platform cues by restoring interface behavior, variation slots, substitution policy, conformance expectation, and bounded exceptions.Repair table rows for Weak module-interface and False platform; worked cases A and B.Module wording, platform promise, or published interface text does not establish modularity, substitutability, or architecture adequacy.
ISO 42010:2022 architecture-description practice (https://www.iso.org/standard/74393.html), plus C.30.AD, C.30.ASV, E.17, and E.24.PUBCurrent standard and FPF line for distinguishing architecture, architecture description, view, viewpoint, concern, model kind, correspondence, and publication face.Treat architecture-description artifacts and publication faces as description or publication material until selected-structure repair is recovered.Repair row Proxy result or description as authority; fields for sourceCueRef? and firstPatternLocator; worked cases D and E.A description artifact or publication face is not architecture adequacy, evidence sufficiency, or project architecture decision.
Evolutionary architecture practice (https://www.oreilly.com/library/view/building-evolutionary-architectures/9781492097532/), DORA loosely coupled teams, last updated 2025-10-20 (https://dora.dev/capabilities/loosely-coupled-teams/), DORA trunk-based development (https://dora.dev/capabilities/trunk-based-development/), and Team Topologies key concepts (https://teamtopologies.com/key-concepts)Current practitioner line for changeability, small batches, independent change, dependency reduction, and fast flow.Use change pain, coordination load, and flow bottlenecks as cues for selected-structure stress while keeping organization relations, local kinds, separate System-classification judgments, assignments, enactor relations, ordinary work or procedure organization, actual Work, independently typed influence sources, transformed-side architecture content, module-interface structures, and direct responsibility relations distinct.Repair rows Coordination cost displaced by responsibility change, Temporal or control coupling, and Mismatch between architecture influence and transformed-side structure; field sourceReturnCondition; stop rule before decision work.Fast-flow evidence can guide architecture repair only after it is interpreted as stress on named selected structures; it neither makes an architecture act nor establishes a direct influence or responsibility relation.
Software Architecture: The Hard Parts (https://www.oreilly.com/library/view/software-architecture-the/9781492086888/), design-space practice (https://arxiv.org/abs/2407.18502), architecture-spread research (https://arxiv.org/abs/2402.19171), and C.18 and C.19 open-ended search governanceStrong current line for hard trade-offs, dynamic candidate fronts, retained stepping stones, and preserving structurally different alternatives instead of hiding them behind one score.Repair hidden-single-winner and static-optimum cases by rebuilding candidate palette content before selected-set result declaration, actual publication, local choice, or architecture decision.Repair rows Hidden single winner and Static optimum; fields for preserved and lost structure through the C.32 palette; receiving requires A.19.CPM, A.19.SelectorMechanism, G.5, E.17, E.24.PUB, C.18, C.19, C.11, and C.32.PAD.A score, Pareto front, generated winner, retained stepping stone, or workshop favorite is not a selected architecture.
TRIZ ideality and laws of technical-system evolution, with C.19.1 BLPOlder heuristic line for useful-function consolidation and removing unnecessary bearers, plus FPF scale-amenability discipline for general bearers.Repair ideality and universal-module shortcuts by turning them into typed C.32 candidates.Repair rows Ideality shortcut and Universal bearer as adequacy shortcut; anti-pattern rows IdealityAsAdequacyShortcut and UniversalBearerAsAdequacyClaim.Ideality, fewer parts, or one universal module is not architecture adequacy, scale adequacy, assurance, release, or project architecture decision.
Multi-objective NAS, hardware-aware co-design, scaling-law practice (https://www.jmlr.org/papers/v20/18-598.html, Sukthanker et al. v3 revised 2025-02-04 at https://arxiv.org/abs/2402.18213, Sinha et al. 2024 at https://arxiv.org/abs/2404.12403), and C.19.1 BLPCurrent ML architecture line makes functional graph search, resource constraints, hardware constraints, and scale-amenability visible as architecture-synthesis pressure.Repair cases where a functional architecture or universal bearer is admitted without feasible bearers, scale window, or affected characteristics.Repair row Function with no feasible bearer; anti-pattern row FunctionalGraphNoBearer; worked Show-F.A functional graph, neural architecture, benchmark result, or scale curve is not architecture adequacy, assurance, release, or project architecture decision.
MAAD submitted 2025-07-28 (https://arxiv.org/abs/2507.21382), LLM-assisted ADD submitted 2025-06-27 (https://arxiv.org/abs/2506.22688), and model-card or evaluation-drift practiceCurrent AI-assisted architecture work makes generated alternatives common, while also making evaluation boundary, hallucination, drift, and human oversight concerns that must be declared.Treat generated outputs and model behavior records as source cues; recover source-side referent, selected structure, architecture-change kind, gain, loss, review boundary, and evidence-decay boundary.Repair rows Weak module-interface, Evidence jump, and Generated output as authority; worked cases A and D.A generated or model-bearing artifact does not carry an architecture-adequacy authority relation, evidence sufficiency, assurance, or gate passage.

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.32 for candidate palette repair; C.32.CONWAY for 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.30 and C.30.AD for architecture relation, claim, and description boundaries; C.30.ASV for architecture structural views; C.31 for module and interface architecture; C.32.MLAO for cross-scope residual repairs; C.29 for mathematical-lens use; E.17 and E.24.PUB for publication-face boundaries; and A.6.P, E.10, and E.10.ROLE for source-expression and role-word recovery.
  • Coordinates with: A.6.F when function and architecture-characteristic wording is mixed; A.6.M for module-interface repair; C.19.1 for 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.RCD missing-governor, when that direct route is absent. Use E.10.ROLE only for unresolved claim-bearing role wording. Ordinary work or procedure organization may remain ordinary. It also coordinates with A.10 and B.3 for evidence or assurance, A.20 and A.21 for gate or release, C.18 and C.19 for archive or pool treatment, C.27 for temporal adequacy, E.18 for transformation-flow structure, C.32.P2S for reopened carry-through, A.19.CPM for comparison, A.19.SelectorMechanism for set-returning selection, G.5 for selected-set result declaration, E.17 and E.24.PUB for publication, C.11 for local choice, and C.32.PAD for project architecture decisions.
  • Patterns for the next questions after the repair cue: A.10 for evidence claims, B.3 for assurance claims, A.20 or A.21 for gate or release claims when those claims are being made, A.19.CPM for explicit comparison, A.19.SelectorMechanism for set-returning selection, G.5 for selected-set result declaration, E.17 for a source-backed publication face and source return, E.24.PUB for the occurrence and audience availability, C.11 for local choice, and C.32.PAD for 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.

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:

"We have three candidate architecture configurations; which one becomes the project decision?"
"The candidate improves maintainability but worsens evidence reuse; what is the accepted trade-off?"
"Developers need to know which architectural style, method, or pattern use is now required."
"The architecture decision must say which structure is fixed by this decision and which refinement remains open."
"The ADR cannot be written yet because the decision relation is not clear."

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:

ArchitectureDecisionRelation@Project:
  decisionId:
  projectWorkOccurrenceRef: U.EntityRef constrained to exact composite U.Work
  projectSystemOfInterestRef?: U.EntityRef constrained to one independently admitted existing U.System
  intendedProjectSystemClaimRef?: U.WorkPlan, decision, system-description, or other claim episteme ref before identity inception
  systemOfInterestKindRef?: U.KindRef resolving to one exact local system-role kind
  systemOfInterestClassificationRef?: U.RelationRef resolving to the exact classification judgment for projectSystemOfInterestRef under systemOfInterestKindRef
  systemOfInterestAssignmentSpeciesRef?: U.RelationKindRef constrained under U.SystemRoleAssignment
  systemOfInterestAssignmentOccurrenceRef?: U.RelationRef constrained to an obtaining occurrence of systemOfInterestAssignmentSpeciesRef, with actual participants, applicability, extent, and projectSystemOfInterestRef as holder recoverable
  decisionSubjectRef:
  describedHolonRef:
  decisionQuestion:
  intendedDecisionUse:
  claimScopeRef: U.ClaimScope
  decisionWindowRef:
  candidateBasisRefs:
  comparisonOrSelectionRefs?
  structuralInformationLensUseRefs?
  holonTransitionOrBOSCTriggerRefs?
  architectureInfluenceCorrespondenceRef?: C.32.CONWAY frame or exact pair-row ref
  transformationFlowStructureNetworkRef?: exact independently selected E.18.NET TransformationFlowStructureNetwork@Context ref
  projectNetworkSelectionResultRef?: exact C.2.1 result episteme whose EntityOfConcern is transformationFlowStructureNetworkRef
  architectureTransformationFlowStructureRelationRef?: exact C.30.TFS-REL use/trace ref when architecture uses that network
  selectedArchitectureOptionRefs:
  selectedStructureEffects:
    - structureKindRef:
      selectedStructureRef:
      decisionEffect:
      relationFunctionClaimRef:
  architectureCharacteristicTradeoffs:
    - architectureCharacteristicRef:
      criteriaRowRef?
      expectedGain:
      acceptedLoss:
      evalResultRef?
      guardrailRef?
  rationaleRefs:
  rejectedOptionRefs:
  consequenceRows:
  architectureDescriptionRefs:
  methodUseInstructions:
    - methodDescriptionRefOrPatternRef:
      expectedStructureEffect:
      intendedPerformerSystemRef?: U.EntityRef constrained to U.System
      intendedPerformerKindRef?: U.KindRef
      intendedPerformerClassificationRef?: U.RelationRef resolving to an exact classification judgment
      currentPerformerAssignmentSpeciesRef?: U.RelationKindRef constrained under U.SystemRoleAssignment
      currentPerformerAssignmentOccurrenceRef?: U.RelationRef constrained to an obtaining occurrence of currentPerformerAssignmentSpeciesRef, with actual participants, applicability, extent, and intendedPerformerSystemRef as holder recoverable
      intendedAssignmentRequirementRef?: plan, policy, or decision-content ref stating a prospective assignment requirement; does not assert an assignment, commitment, or permission occurrence
      actualImplementationWorkRef?: U.EntityRef constrained to U.Work
      actualImplementationWorkAttributionRef?: U.RelationRef constrained to one obtaining F.6 performedUnderAssignment relation, only when the instruction expressly represents attribution
      responsibilityRelationRef?: U.RelationRef resolving to an independently obtaining admitted domain relation
      responsibilityMissingGovernor?: exact A.6.RCD result when responsibility is required but no predicate is admitted
      authorityRelationRef?: U.RelationRef resolving to an independently obtaining admitted domain relation
      authorityMissingGovernor?: exact A.6.RCD result when authority is required but no predicate is admitted
      permissionRelationRef?: U.RelationRef resolving to an independently obtaining admitted domain relation
      permissionMissingGovernor?: exact A.6.RCD result when permission is required but no predicate is admitted
      commitmentRelationRef?: U.RelationRef resolving to an independently obtaining admitted domain relation
      commitmentMissingGovernor?: exact A.6.RCD result when commitment is required but no predicate is admitted
      workBoundaryRef:
      readinessOrGateExitRef?
  architectDeveloperSplit:
    decisionFixedStructureRefs:
    openRefinementScopeRefs:
    sourceReturnCondition:
  publicationProjectionRef?
  evidenceOrAssuranceExitRefs?
  governanceExitRefs?
  reopenConditions:
  supersedesDecisionRefs?
  status:

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

ForceTension
Candidate pluralitySeveral candidate configurations can be valid under different trade-offs, while project work needs one current direction or a bounded exception.
Trade-off visibilityArchitecture characteristics compete; a decision that hides accepted losses cannot be responsibly executed or reopened.
Structure and method couplingThe decision must govern actual or modal structure content for the described or transformed-side holon and may also prescribe developer methods intended to produce or preserve those structures.
Work splitStructures fixed by the decision and refinement left open must be separated without severing source return.
EvolutionA decision must close enough work for now while staying reopenable when context, eval readings, or candidates change.
Publication pressureTeams often want an ADR file before the decision relation is recoverable.

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:

  1. Name the composite project U.Work participant 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 existing U.System or 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. Route SystemOfInterestRole source wording through E.10.ROLE; establish every Work, change, and use fact through its own predicate and pattern. A decision designation proves no compound project-selection truth; return missing-substrate[project-selection-conjunction] when that stronger truth is required.
  2. Cite the candidate basis. Use C.32 for the candidate palette, C.32.MLAO for residual-reducing multilevel candidate frames, C.32.CONWAY when an influence-source architecture and transformed-side architecture content shaped the candidate, and C.32.FAIL for 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.
  3. Cite comparison or selection input only when it exists. Use A.19.CPM for explicit comparison, A.19.SelectorMechanism for set-returning selection, G.5 for selected-set result declaration, and C.11 for local choice. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability.
  4. State the selected architecture option or bounded exception. Name the affected selected structures and the subject pattern for each structure claim.
  5. Record the architecture-characteristic trade-off. Use criteria rows from C.32.ACS, eval results from C.32.ACE, measurement support from C.16, Q-Bundles from C.25, modularity or scale support from C.31, and C.29 structural-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.
  6. 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.
  7. Bind the decision to architecture descriptions. Use C.30.AD for architecture-description adequacy and C.30.ASV for selected-structure view adequacy. A diagram, model, file, or view can describe the decision basis; it does not become the decision relation.
  8. 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, and C.24 according to the live claim.
  9. 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? through B.2.P claim-kind recovery or B.2 whole reidentification instead of leaving a generic level note.
  10. Choose a publication projection only after the decision relation is clear. Use C.32.ADR for ADR-like projection, E.17 for a source-backed publication face and source return, and E.24.PUB for the publication occurrence and audience availability.
  11. 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.
  12. 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:

ArchitectureDecisionRelation@OrderFlow:
  decisionId: OrderFlowArchitectureDecision-2026Q3
  projectWorkOccurrenceRef: ProductFamilyQ3OrderArchitectureWork, exact admitted composite U.Work
  decisionSubjectRef: order-integration architecture for product-family Q3
  describedHolonRef: product-family order-flow system
  decisionQuestion: which candidate architecture should guide Q3 order-flow implementation?
  intendedDecisionUse: direct the Q3 implementation work while preserving the stated refinement boundary
  claimScopeRef: order-flow architecture for ProductFamilyQ3OrderArchitectureWork
  decisionWindowRef: accepted for Q3 implementation; reopen on a listed trigger or superseding decision
  candidateBasisRefs: [C32CandidatePalette:order-flow-2026-06]
  selectedArchitectureOptionRefs: [event-carried integration with payment exception]
  selectedStructureEffects:
    - structureKindRef: module structure
      selectedStructureRef: order events between service modules
      decisionEffect: preserve service substitutability, accept added event-schema governance
      relationFunctionClaimRef: C.30.ASV
  architectureCharacteristicTradeoffs:
    - architectureCharacteristicRef: substitutability
      criteriaRowRef: C.32.ACS order-flow substitutability criterion
      expectedGain: service replacement without order-flow rewrite
      acceptedLoss: additional schema-version coordination
      guardrailRef: version-skew eval band
  methodUseInstructions:
    - methodDescriptionRefOrPatternRef: event-schema change method
      expectedStructureEffect: compatible event schemas across service modules
      intendedPerformerSystemRef: the named service-team System intended by the project decision
      intendedPerformerKindRef: ServiceTeamDeveloperSystemRole
      intendedPerformerClassificationRef: the separate classification judgment, when it obtains
      intendedAssignmentRequirementRef: decision content requiring a suitable service-team assignment before implementation Work
      workBoundaryRef: schema refinement left open inside the event boundary fixed by the decision
  architectDeveloperSplit:
    decisionFixedStructureRefs: [event boundary, payment exception]
    openRefinementScopeRefs: [schema fields inside approved event boundary]
    sourceReturnCondition: return to PAD when refinement changes event boundary or version-skew band
  holonTransitionOrBOSCTriggerRefs?: [B.2.P: no new operational whole claimed for team-local schema refinement]
  structuralInformationLensUseRefs?: [C.29: event-flow view compresses deployment and rollout structure; source-return keeps model refs recoverable]
  publicationProjectionRef?: C.32.ADR:order-flow-adr
  reopenConditions: [payment latency guardrail crossed, schema-version coordination cost guardrail crossed]
  status: acceptedForDeveloperWork

When a filled field changes, repair the smallest declaration or claim record that carries the changed content:

Changed filled fieldImmediate repair locus
candidateBasisRefs or selectedArchitectureOptionRefsUse [C.32](/generated/patterns/C.32), [C.32.MLAO](/generated/patterns/C.32.MLAO), comparison or selection inputs, then update PAD before ADR projection.
projectSystemOfInterestRef?, intendedProjectSystemClaimRef?, systemOfInterestKindRef?, systemOfInterestClassificationRef?, systemOfInterestAssignmentSpeciesRef?, or systemOfInterestAssignmentOccurrenceRef?Use A.15.6 for actual-versus-intended designation and the compound-selection stop, C.3/A.2 for the exact local kind and its separate classification judgment, and A.2.1 for the directly declared assignment species and its separately obtaining occurrence. Route unresolved role wording through [E.10.ROLE](/generated/patterns/E.10.ROLE). Keep every independently obtaining Work, change, and use fact; remove any reference the decision alone was being used to prove.
architectureInfluenceCorrespondenceRef?Use C.32.CONWAY. Keep a frame for modal or unresolved sides and cite an exact pair row only for the already obtaining direct occurrence and its exact C.30 architecture-relation participants.
transformationFlowStructureNetworkRef?, projectNetworkSelectionResultRef?, or architectureTransformationFlowStructureRelationRef?Use E.18.NET for exact network identity, A.15.6/C.2.1 for the project-question judgment, and C.30.TFS-REL for architecture use. Update or remove only the affected refs; do not copy or repair network members, relations, constraints, endpoints, or use frame inside PAD.
selectedStructureEffectsRepair the architecture claim or selected-structure view in [C.30](/generated/patterns/C.30), [C.30.AD](/generated/patterns/C.30.AD), or [C.30.ASV](/generated/patterns/C.30.ASV); then update PAD consequences.
architectureCharacteristicTradeoffsRepair [C.32.ACS](/generated/patterns/C.32.ACS), [C.32.ACE](/generated/patterns/C.32.ACE), [C.25](/generated/patterns/C.25), [C.16](/generated/patterns/C.16), or comparison input before relying on the decision.
methodUseInstructions or architectDeveloperSplitRepair Method, plan, intended-System, local-kind, separate System-classification, assignment, actual-Work, readiness, and work-boundary claims through their subject patterns. Route unresolved role wording through [E.10.ROLE](/generated/patterns/E.10.ROLE); use [A.15](/generated/patterns/A.15), [E.8](/generated/patterns/E.8), [E.11.PUR](/generated/patterns/E.11.PUR), or [C.24](/generated/patterns/C.24) only for the claim that pattern defines, constrains, or tests.
holonTransitionOrBOSCTriggerRefs?Use [B.2.P](/generated/patterns/B.2.P) for wording and claim-kind recovery; use [B.2](/generated/patterns/B.2) only when the decision depends on whole reidentification.
structuralInformationLensUseRefs?Use [C.29](/generated/patterns/C.29) to state which structure is preserved, compressed, hidden, or recoverable; return to source when the accepted loss changes.
publicationProjectionRef?Repair only the projection through [C.32.ADR](/generated/patterns/C.32.ADR), the source-backed publication face and source return through [E.17](/generated/patterns/E.17), and the publication occurrence and audience availability through [E.24.PUB](/generated/patterns/E.24.PUB); do not rewrite the decision by template pressure.
reopenConditions or supersedesDecisionRefs?Update PAD and the active ADR-like projection; old decisions remain historical unless a governed archival policy says otherwise.

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

Risk handledHow C.32.PAD handles it
Record-before-decision driftThe pattern requires ArchitectureDecisionRelation@Project before ADR-like publication projection.
Description-as-decision driftArchitecture descriptions remain C.30.AD objects; PAD records the decision relation that may cite them.
Metric-winner driftEval readings and metrics can inform trade-offs but do not select or decide by themselves.
Method-structure collapseMethod-use instructions and intended target structures are both recorded and kept distinct.
Work-split lossStructures fixed by the decision, refinement scopes left open, and source-return conditions are explicit.
Evolution lock-inSupersession and reopen conditions are part of the decision relation.

Conformance Checklist

RequirementRequired result
CC-PAD-1The exact composite project U.Work participant, decision subject, described holon, decision question, intended decision use, ClaimScope, and decision window are explicit.
CC-PAD-2The decision cites candidate basis from C.32 or a named receiving candidate pattern, or states why no candidate-set question is live.
CC-PAD-3The selected architecture option or bounded exception is named.
CC-PAD-4Affected selected structures are named with subject pattern refs.
CC-PAD-5Architecture-characteristic trade-offs, accepted losses, and guardrails are recorded.
CC-PAD-6Architecture-description refs, method-use instructions, and performed-work boundaries remain distinct.
CC-PAD-7The architect-developer split, source-return condition, and reopen conditions are recorded.
CC-PAD-8Triggered holon-transition or BOSC boundary pressure cites B.2.P or B.2, and structural-information loss or compression cites C.29.
CC-PAD-9ADR-like publication, evidence, assurance, gate, comparison, selection, selected-set result declaration, audience publication, local choice, and work claims exit to their patterns for the next questions.
CC-PAD-10Any project system-of-interest ref denotes one independently admitted existing U.System; a pre-inception intended referent stays in claim content. SystemOfInterestRole wording is recovered through E.10.ROLE; any local kind, separate classification judgment, and separately obtaining A.2.1 assignment are cited independently. Decision designation, kind, classification, assignment, and direct facts neither entail one another nor establish the missing compound project-selection truth.
CC-PAD-11Any network ref resolves to one independently selected E.18.NET structure, its project-question judgment stays in a separate C.2.1 episteme, and architecture use docks through C.30.TFS-REL. A PAD decision, network record, C.32.CONWAY frame, or exact pair row creates no member, cross-flow occurrence, influence occurrence, architecture relation, or actual structure effect.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
ADRBeforeDecisionRelationThe team starts from an ADR template and fills prose before the selected option, trade-off, and work consequences are recoverable.Draft ArchitectureDecisionRelation@Project first; then use C.32.ADR only as publication projection.
CandidateWinnerByMetricOne score, benchmark, or eval reading is treated as the architecture decision.Use C.32.ACS, C.32.ACE, C.16, and A.19.CPM; decide only after trade-offs and accepted losses are recorded.
StructureOnlyDecisionThe decision names a target structure but gives no Method-use or work-boundary instruction for the Systems intended to realize it.Add Method-description or pattern-use refs, intended System, optional local kind and independently optional classification judgment, any current assignment species and occurrence or prospective assignment requirement without conflating them, work boundary, readiness exit, and expected structure effect. Add responsibility, authority, permission, or commitment only under its independent direct predicate or exact missing governor. If actual Work is claimed, recover each exact performer through A.13 and let A.15.1 independently admit the U.Work. Add an F.6 ref only when precise assignment-bound attribution is expressly consumed; its absence or failure leaves the Work intact.
MethodOnlyDecisionThe decision says which style, pattern, or tool to use but not which target structures it is expected to produce or preserve.Name the intended selected structures and architecture-characteristic trade-offs; use C.30, C.30.ASV, or C.32 if the structure is not recoverable.
FrozenArchitectureDecisionThe decision has no source-return or reopen condition.Add eval guardrails, source-currentness return, architecture-influence/transformed-side fit trigger, or supersession rule.
LensOrQBundleAsDecisionAuthorityA view, structural-information lens, measurement row, Q-Bundle, or eval reading is treated as if it selected the architecture.Use the exact subject predicate for the source: C.29 for lens use, C.25 for Q-Bundle, C.16 for measurement, C.32.ACE for eval, and PAD for the actual decision relation.
GovernanceByImplicationTeams are expected to follow the decision, but no readiness, gate, evidence, assurance, or governance exit is named.Add the exact pattern for the next question refs; do not import those statuses into PAD.
ProjectSelectionOrRoleByDecisionA PAD field is treated as proof that a project selected a System, or that the System gains a kind, classification, or assignment because the decision names it.Keep the decision designation and every direct fact; recover role wording through E.10.ROLE, apply A.15.6, A.2, and A.2.1 independently, and return missing-substrate[project-selection-conjunction] when the compound truth is needed.
NetworkOrInfluenceByCitationA cited network record, C.32.CONWAY frame or pair row, or PAD decision is treated as a network member, cross-flow occurrence, architecture-influence occurrence, performer, or actual structure effect.Restore the exact E.18.NET network and direct relation patterns, use C.30.TFS-REL for architecture use, and keep expected structure effect modal until C.30 independently establishes the actual architecture relation.

Consequences

ConsequenceBenefitCost
The architecture decision relation to exact composite project work is explicit before publication.ADRs, design memos, and governance files can describe a recoverable decision rather than inventing one.The architect performs decision work before publication work.
Structure and method are coupled without collapsing.Developers can see both intended architecture structures and required methods.The decision record needs enough detail to avoid empty method instructions.
Trade-offs and accepted losses are recorded.Later teams can reopen the decision under changed characteristics instead of guessing the original rationale.Decisions may look less tidy because loss is visible.
Architect-developer split is stated.Team refinement can proceed without losing source return.Architecture governance must maintain split and reopen conditions.

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 to inspectWhy this source is load-bearing hereTransfer into PADConcrete PAD mutationBlocked overread
ISO/IEC/IEEE 42010:2022 official standard (https://www.iso.org/standard/74393.html; IEEE page https://standards.ieee.org/ieee/42010/6846/)Current official source for architecture-description requirements; it explicitly scopes itself to AD structure and expression, not architecting methods or the architecture itself.Keep architecture descriptions as description objects and use PAD for the decision relation that may cite them.PAD has architectureDescriptionRefs, selected-structure effects, and source-return conditions rather than treating a view, viewpoint, file, or model as the decision.ISO 42010 architecture-description structure does not replace C.32 synthesis, A.15 method work, or PAD decision relation.
Michael Nygard, Documenting Architecture Decisions (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)Practitioner source for small, statused records that preserve context, decision, and consequences across time.Use context, decision, status, consequences, and supersession as publication-relevant decision-description fields.PAD requires status, consequences, and supersession or reopen conditions before ADR projection.ADR records are not the architecture decision relation with its exact project-work participant and do not by themselves ground selected structures.
MADR 4.x (https://adr.github.io/madr/)Current ADR practice with options, outcome, status, links, and confirmation pressure.Require candidate basis, outcome, decision status, links to related decisions, and confirmation or eval exits.PAD separates candidate basis, selected option, consequence rows, method-use instruction, and reopen conditions.MADR's broad "any decision" use is not imported as FPF architecture-decision ontology.
Ford, Parsons, Kua, and Sadalage, Building Evolutionary Architectures, 2nd ed. (https://www.oreilly.com/library/view/building-evolutionary-architectures/9781492097532/)Current practitioner source for guided incremental architecture change and source-side fitness-function wording.Treat eval support as C.32.ACE inputs and reopen conditions, not as the decision itself.PAD requires eval refs, guardrails, and reopen conditions when evolutionary feedback guides the decision.Fitness-function terminology is not imported as an FPF object name.
Ford, Richards, Sadalage, and Dehghani, Software Architecture: The Hard Parts (https://www.oreilly.com/library/view/software-architecture-the/9781492086888/)Current practitioner source for trade-offs, least-worst choices, and architecture characteristics under uncertainty.Make accepted losses and protected counter-characteristics mandatory decision content.PAD records architecture-characteristic trade-offs, rejected options, accepted losses, and consequences.A trade-off discussion does not replace candidate synthesis, comparison, evidence, or governance.
NASA Systems Engineering Handbook, decision analysis and trade-study practice (https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf)Non-software engineering source for alternatives, selection criteria, assumptions, limitations, recommendation, impacts, and final decision documentation.Generalize PAD beyond software ADR practice by requiring candidate basis, selection criteria or comparison refs, assumptions or accepted losses, impacts, and decision-maker commitment.PAD carries candidateBasisRefs, comparisonOrSelectionRefs?, trade-offs, consequence rows, status, and reopen conditions for engineering decisions such as fixtures, vehicles, built assets, or methods.NASA trade-study process is not imported as FPF architecture ontology and does not by itself decide the architecture.
Conway and Team Topologies source line, mediated through C.32.CONWAYIndependently typed influence-source architecture and transformed-side architecture content can constrain candidate fit without making either architecture an actor.Use a synthesis frame for modal or unresolved sides and an exact pair row only for one already obtaining direct influence occurrence over two obtaining C.30 architecture relations.PAD may cite architectureInfluenceCorrespondenceRef? and reopen when that qualified fit changes.The frame, pair row, architecture relations, claims, systems, assignments, Work, actual transformation, network, and decision remain separate; citation proves none of their world-side relations.
Current FPF A.15.6, A.2, A.2.1, E.18.NET, and C.30.TFS-RELExisting FPF subject patterns for project Work and system-of-interest designation, role interpretation and assignment, selected recursive transformation-flow networks, persistent project-network judgments, and architecture use of those networks.Let PAD cite already established objects needed by the decision while keeping their identity and truth with those subject patterns.PAD adds optional system, intended-system-claim, role-assignment, network, project-network-result, and architecture-flow-use refs plus explicit return conditions.A decision designation establishes no compound project-selection truth; a network, record, or citation creates no member or direct relation occurrence.
Current FPF A.15, E.8, E.11.PUR, C.30, C.30.AD, C.32, C.32.ACS, C.32.ACE, C.32.ADR, and C.32.ADAExisting FPF ontology for actual and modal architecture content, method descriptions, pattern use, architecture descriptions, candidate synthesis, evals, publication projection, and adequacy evaluation.Keep PAD narrow: decision relation after candidate synthesis.Relation and conformance rows send neighboring claims to their subject patterns.PAD does not duplicate FPF architecture, method, publication, evidence, assurance, or pattern-form doctrine.

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, and C.31.ASAP.
  • Comparison and selection boundary: Use A.19.CPM for comparison, A.19.SelectorMechanism for set-returning selection, G.5 for selected-set result declaration, and C.11 for local choice. 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. PAD records the architecture decision relation with its exact composite project-work participant after those inputs are sufficient.
  • Description boundary: C.30.AD and C.30.ASV govern architecture-description and selected-structure view adequacy. PAD may cite those descriptions but does not replace them.
  • Structural-information boundary: C.33, C.34, and C.35 may 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.ADR to project an ArchitectureDecisionDescription@Project into ADR-like form, E.17 for a source-backed publication face and source return, and E.24.PUB for the publication occurrence and audience availability.
  • Adequacy boundary: C.32.ADA evaluates 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.6 for composite project Work, actual-versus-intended System designation, independent Work, change and use facts, project-network judgment, and missing-substrate[project-selection-conjunction]. E.10.ROLE recovers SystemOfInterestRole wording; use A.2 and A.2.1 separately 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.NET to identify the selected network, its members, obtaining cross-flow occurrences, constraints, endpoints, and use frame; C.30.TFS-REL defines architecture use; C.32.CONWAY is 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, and C.24 govern method descriptions, work plans, readiness, pattern-use recommendations, and agentic tool-use work.
  • Evidence, assurance, and gate boundary: A.10, B.3, and A.21 govern evidence relations, assurance calculus, and gate profiles when those claims are current.

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:

"The project decision is made; now we need an ADR that future developers can use."
"The record must show options, decision, rationale, consequences, and confirmation without becoming the decision itself."
"This is not a software project; can a trade-study memo play the ADR role?"
"The ADR package must link to architecture views without duplicating the whole architecture description."
"A future team must know when this decision is superseded or violated."

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:

ArchitectureDecisionRecordProjection@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureDecisionRecordProjectUseRelationRef?: U.RelationRef governed by the exact record-use, publication-use, or work-use pattern
  projectionId:
  architectureDecisionRelationRef:
  architectureDecisionDescriptionRef:
  publicationCarrierRef:
  publicationScopeRef:
  intendedReaderRefs:
  status:
  sectionFunctionRows:
    - sectionFunction:
      sectionHeadingOrCarrierSlot:
      sourceDecisionSlotRefs:
      requiredReaderUse:
      omittedByDesign?
      sourceReturnCondition?
  architectureDescriptionRefs:
  methodAndWorkRefs:
  confirmationOrEvalRefs:
  supersedesRecordRefs?
  supersededByRecordRef?
  updateOrReopenCondition:
  publicationUseRefs?

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

ForceTension
Reader economyThe record should be short enough to use, but not so short that decision content disappears.
Section variationADR templates and engineering memos differ, while the decision functions must remain recoverable.
Publication and decision separationThe record publishes a description of the decision; it does not become the decision relation.
Architecture and method couplingA record often needs to cite both target structures and required developer methods.
EvolutionSupersession, violation detection, and update conditions must be visible without making the record a governance system.
Cross-domain useSoftware ADR practice must generalize to other holon kinds without importing software-only assumptions.

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:

  1. 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.
  2. Cite the decision relation and decision description. If the record cannot cite them, draft them first.
  3. 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.
  4. Map section functions to headings or carrier slots. Use local headings if needed, but keep the function rows recoverable.
  5. Carry the candidate basis. Record candidate options from C.32 or the reason no candidate-set question is live. Do not invent options in the ADR after the decision.
  6. Carry the decision outcome. State the selected architecture option, bounded exception, or supersession relation from PAD.
  7. Carry rationale, accepted losses, and consequences. Include architecture-characteristic trade-offs and guardrails, not only benefits.
  8. 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.
  9. 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.
  10. Carry publication and source-return boundaries. Use E.17, E.24.PUB, and C.30.AD for publication-face and architecture-description claims.
  11. 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.

Section functionWhat the record must let the reader recover
Identity and statusRecord id, title, status, date or version, relation to superseded or superseding records.
Problem frame and decision questionThe bounded architecture question, described holon, context, and current reader use.
Forces and architecture characteristicsThe architecture characteristics, constraints, concerns, and trade-offs that made the decision nontrivial.
Candidate optionsCandidate options, rejected options, bounded exception, or stated reason no candidate-set question is live.
Decision outcomeThe selected architecture option and affected selected structures.
RationaleWhy this outcome is acceptable now, including accepted losses and protected guardrails.
ConsequencesExpected effects on structures, methods, teams, costs, risks, evidence, operation, and later change.
Method-use instructionRequired style, pattern use, method description, or work practice, when the decision changes developer work.
Work splitProspective allocation or instruction content through the plan, policy, commitment, permission, decision, responsibility, authority, or other direct relation that actually states it; otherwise the exact missing governor. Also show readiness or gate exits and the source-return condition. Professional titles are audience cues, not ownership predicates.
Confirmation or eval exitHow the decision can be checked, evaluated, monitored, or found violated.
Publication boundaryLinks to architecture descriptions, views, evidence, assurance, and source material without making the ADR the source object.

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

Risk handledHow C.32.ADR handles it
Template-first writingThe record starts from a PAD decision relation and section functions, not from a blank template.
Publication-as-decision driftThe ADR projection cites the decision relation and remains a publication object.
Architecture-copy driftArchitecture descriptions are cited through C.30.AD; the record carries only decision-relevant references.
Method prose driftMethod-use instruction is typed through A.15, E.8, or E.11.PUR when live.
History lossStatus and supersession are record functions; old records stay recoverable unless governed archival policy says otherwise.
Software-only overreadADR-like projection is generalized by section function and reader use, not by software tool convention.

Conformance Checklist

RequirementRequired result
CC-ADR-1The record cites an ArchitectureDecisionRelation@Project or states the equivalent accepted decision relation by value.
CC-ADR-2The record's publication carrier, intended readers, scope, and status are explicit.
CC-ADR-3Section functions are mapped to headings or carrier slots.
CC-ADR-4Problem frame, forces, candidate options, outcome, rationale, consequences, confirmation or eval exit, and supersession or update condition are recoverable.
CC-ADR-5Method-use instruction and work split are included when the decision guides developer work.
CC-ADR-6Architecture descriptions, views, evidence, assurance, gate, method, work, and publication claims exit to their subject patterns.
CC-ADR-7The record does not create new candidate options, new architecture-description adequacy, or new evidence authority by prose.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
BlankTemplateADRA template is filled with plausible prose but no PAD relation can be cited.Draft or recover ArchitectureDecisionRelation@Project with C.32.PAD; then project it into the record.
ArchitectureDescriptionDumpThe ADR copies diagrams, views, or model text and the decision outcome is hard to find.Keep the record small; cite architecture-description refs and restore decision outcome, rationale, consequences, and work effects.
OptionsInventedInRecordThe ADR lists options that were not part of candidate synthesis or accepted decision basis.Use C.32, A.19.CPM, or PAD; update the decision relation before updating the record.
MethodInstructionHiddenInRationaleA decision requires developers to change their practice, but the instruction is buried in rationale prose.Record the prospective content through the exact plan, policy, commitment, permission, decision, responsibility, authority, or other direct relation that states it, with Method refs, intended Systems, expected structure effect, and readiness or gate exit; otherwise return its exact missing governor. Do not manufacture a current assignment or performed Work. If performance later occurs, recover every precise performer's A.13 core and independently admit the Work under A.15.1; add F.6 only when precise assignment-bound attribution is current, and add only the other direct relations that independently obtain.
NoConfirmationPathFuture teams cannot tell whether the decision still holds or has been violated.Add confirmation, eval, guardrail, source-return, or supersession condition; use the receiving evaluation or governance pattern.
PackageOrderAsGovernanceThe latest file by number is treated as active without explicit status or supersession.Add package map or status fields; make active, proposed, superseded, and related relations explicit.

Consequences

ConsequenceBenefitCost
ADR is a publication projection.Records stay readable while decision authority remains in PAD.Authors must maintain the relation between record and decision.
Section functions are stable even when headings vary.Software ADR, engineering memo, and certification rationale can be compared by function.Local templates must be mapped rather than copied blindly.
Method and work effects are visible.Developers can act on the decision instead of only reading rationale.Records may need exact method refs and work-split refs.
Supersession is explicit.Future readers can distinguish history from current decision.Record packages need simple upkeep.

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 to inspectWhy this source is load-bearing hereTransfer into ADR projectionConcrete ADR mutationBlocked overread
Michael Nygard, Documenting Architecture Decisions (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)Foundational practitioner source for small decision records with context, decision, status, and consequences.Preserve the small-record and future-reader practice.C.32.ADR requires status, context, decision outcome, consequences, and supersession or reopen condition.The ADR record is not the decision relation or the architecture description.
MADR 4.x (https://adr.github.io/madr/)Current Markdown ADR practice with options, outcome, status, links, and confirmation.Use options, outcome, links, and confirmation as section functions rather than fixed FPF ontology.Required section functions include candidate options, decision outcome, confirmation or eval exit, and package links."Any decision" scope is not imported as architecture-decision kind expansion.
ISO/IEC/IEEE 42010:2022 official standard (https://www.iso.org/standard/74393.html; IEEE page https://standards.ieee.org/ieee/42010/6846/) with the 42010 companion site as secondary reading (https://iso-architecture.org/42010/)Current official source for architecture descriptions, viewpoints, views, correspondence, and rationale.Keep architecture views as cited description refs inside the ADR projection.ADR rows carry architectureDescriptionRefs and publication boundary instead of copying view content wholesale.A 42010 architecture description is not an ADR projection and not a PAD relation.
2026 ADR violation-detection research (https://arxiv.org/abs/2602.07609)Recent research shows explicit decisions are easier to check, while implicit deployment or organization knowledge remains weak.Make confirmation, violation-detection scope, and non-code source refs explicit.ADR section functions require confirmation or eval exit, source-return condition, and method or deployment refs when live.LLM-detectability is not evidence, assurance, or gate passage.
Current FPF E.8, E.17, E.24.PUB, A.15, A.10, B.3, C.30.AD, and C.32.PADExisting FPF patterns define or constrain pattern form, publication, method work, evidence, assurance, architecture description, and decision relation.Keep ADR projection thin and typed.The record maps section functions while every neighboring claim retains its exact predicate, defining or constraining ClaimGraph, and non-semantic pattern locator.ADR projection does not duplicate pattern language, MVPK, method, evidence, assurance, gate, or description doctrine.
NASA Systems Engineering Handbook, decision analysis and trade-study practice (https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf) plus domain certification-rationale practice where governed locallyNon-software engineering decisions are commonly recorded through trade studies, engineering memos, review records, safety cases, or certification rationale. NASA supplies a concrete source for alternatives, criteria, assumptions, recommendation, impacts, and decision documentation.Generalize by record function and reader use rather than by Markdown file convention.publicationCarrierRef can be a memo, trade-study record, certification rationale, or design-review record, while section functions still recover problem frame, options, outcome, rationale, consequences, confirmation, source return, status, and supersession.Non-software carrier form does not change the PAD decision relation or section functions.

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, and C.32.ADA.
  • Decision boundary: Use C.32.PAD for the project architecture decision relation. C.32.ADR publishes an ArchitectureDecisionDescription@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, or C.35 only 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.AD and C.30.ASV for architecture-description and view adequacy. ADR carries refs and reader-use slices, not full description authority.
  • Pattern and method boundary: Use E.8 when the published object is an FPF pattern, E.11.PUR for pattern-use recommendation, and A.15 for method and work claims.
  • Publication boundary: Use E.17 and E.24.PUB for MVPK face, publication carrier, and publication-use claims not specific to architecture decisions.
  • Evaluation boundary: Use C.32.ADA for decision adequacy; use C.32.ACE, C.16, A.10, B.3, or A.21 for 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.

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:

"The decision is written, but can developers actually use it?"
"The ADR looks complete; is the architecture decision itself adequate?"
"Which part is weak: candidate basis, trade-off, method instruction, work split, or publication projection?"
"We need a scale like E.21, but for architecture decisions rather than pattern quality."
"Do not average the decision; tell us what must be repaired."

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:

ArchitectureDecisionAdequacyEvaluation@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureDecisionEvaluationProjectUseRelationRef?: U.RelationRef governed by the exact evaluation-use or work-use pattern
  evaluationId:
  claimScopeRef: U.EntityRef referencing one U.ClaimScope
  selectedContextSliceRefs:
  effectiveReferenceScheme:
  referencePlane?:
  evaluationWindow:
  decisionQuestionInputProjectionRef:
  evaluatorSystemRef?: U.EntityRef constrained to U.System
  evaluatorSystemRoleKindRef?: U.KindRef
  evaluatorSystemRoleClassificationJudgmentRef?: U.RelationRef
  evaluatorAssignmentSpeciesRef?: U.RelationKindRef constrained under U.SystemRoleAssignment
  evaluatorAssignmentOccurrenceRef?: U.RelationRef constrained to U.SystemRoleAssignment
  evaluationWorkRef?: U.EntityRef constrained to U.Work
  evaluationPerformedUnderAssignmentRef?: U.RelationRef constrained to one obtaining F.6 performedUnderAssignment relation
  evaluationOperationApplicationRefs?: subject-pattern relation or A.6.1 application references
  adequacyResultEpistemeRef?: U.EpistemeRef
  declaredUse:
  architectureDecisionRelationRef:
  architectureDecisionRecordProjectionRef?:
  coordinateValues:
    - coordinateRef:
      value: 0|1|2|3|4|5
      valueLabel: absent|namedOnly|partiallyExpressedForDeclaredUse|sufficientlyExpressedForDeclaredUse|wellExpressedForDeclaredUse|exceptionallyExpressedForDeclaredUse
      adjacentValueRationale:
      evidenceOrSourceRefs?
      repairPatternRef?
      repairInstruction:
  strongestBlockingCoordinates:
  noAveragePolicy: true
  stopCondition:
  reevaluationTrigger:

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

ForceTension
Decision complexityOne architecture decision carries candidate, structure, characteristic, method, work, publication, and evolution content.
Declared useA decision can be adequate for discussion and inadequate for developer work or governance.
Repair focusReview must point to the smallest repair locus, not produce a general complaint.
No averageA strong rationale cannot compensate for absent work split or missing source-return.
Kind precisionEval results, evidence, assurance, gates, and publication records must stay distinct from adequacy evaluation.
EvolutionThe evaluation must expose reopen and supersession weakness before the decision becomes stale.

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.

ValueLabelArchitecture-decision adequacy meaning
0absentThe coordinate is not expressed for the declared architecture-decision use.
1namedOnlyThe coordinate is named or implied, but cannot support reliance, action, evaluation, or repair.
2partiallyExpressedForDeclaredUseThe coordinate is present but incomplete, fragile, misplaced, or too narrow for the declared use.
3sufficientlyExpressedForDeclaredUseThe coordinate can support the declared use in the current project, with limits visible.
4wellExpressedForDeclaredUseThe coordinate has clear refs, boundaries, source-return, and repair path for likely project changes.
5exceptionallyExpressedForDeclaredUseThe coordinate is well expressed and transferable across another team, later slice, or adjacent holon kind with minimal recovery work and no hidden neighbor loss.

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:

CoordinateValueLabelShortRationale
<ADA coordinate><0..5><E.21 label><why the lower adjacent value would understate the expressed content; why the higher adjacent value would overstate it, or for 5 what makes 4 too weak and what would lower or reopen>

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.

CoordinateWhat is evaluatedRepair when weak
BoundedDecisionQuestionRecoverabilityDecision subject, described holon, exact U.ClaimScope, relevant A.2.6 U.ContextSlice membership, effective reference scheme and plane, evaluation window, status, and decision question can be recovered; a selected BoundedModelUseStructure is named only when it independently changes interpretation.Repair the exact missing decision-subject, scope, slice, or model-use-structure assertion using C.32.PAD, A.2.6, or A.1.1.
CandidateBasisAndSelectionTraceabilityCandidate palette, residual frame, comparison, selection, selected set, or reason no candidate-set question is live is recoverable.Repair the missing candidate, comparison, or selection assertion using the exact applicable content in C.32, C.32.MLAO, A.19.CPM, A.19.SelectorMechanism, G.5, or C.11.
AffectedStructureAndDescriptionAdequacyAffected selected structures, views, architecture descriptions, correspondence, structural-information lens uses, and source-return are recoverable.Repair the exact missing structure, description, correspondence, or lens-use assertion using C.30, C.30.ASV, C.30.AD, A.6.F, A.6.M, or C.29.
ArchitectureCharacteristicTradeoffAdequacyArchitecture characteristics, criteria rows, Q-Bundles, eval readings, accepted losses, and guardrails are explicit.Repair the exact missing characteristic, criterion, reading, loss, or guardrail assertion using C.32.ACS, C.32.HCS, C.25, C.32.ACE, C.16, C.31, or C.31.ASAP.
MethodAndWorkDockingAdequacyMethod-use instructions, exact intended or acting Systems, Work boundaries, readiness, and expected structure effects are usable. Intended assignment requirements remain modal; actual assignment and F.6 attribution are required only when the instruction or evaluation expressly consumes precise assignment-bound attribution. Responsibility remains independently governed.Repair the exact missing MethodDescription, Method, A.13 performer basis, A.15.1 Work fact, optional direct assignment species and F.6 attribution, responsibility predicate or missing governor, readiness, or expected-effect assertion using A.15, A.15.1, A.15.2, A.15.5, E.8, E.11.PUR, A.6.RCD, or C.24.
ArchitectDeveloperSplitAdequacyArchitect-owned structures, developer-owned refinement, holon-transition or BOSC-triggered boundary refs, and source-return condition are explicit.Repair the exact split or claim-kind assertion using C.32.PAD, A.15, or B.2.P; use B.2 only when whole reidentification is triggered.
PublicationProjectionAdequacyADR-like or other publication projection carries the needed section functions for the declared readers.Use C.32.ADR for the exact projection, E.17 for a source-backed publication face and source return, and E.24.PUB for the publication occurrence, form, carrier bearing, audience, and availability.
EvidenceEvalAndGateExitAdequacyEval, evidence, assurance, gate, or institutional-governance assertions are named only when live, with their exact predicates and subject-pattern locators.Repair the exact assertion using C.32.ACE, C.16, A.10, B.3, A.21, or the named institutional-governance content.
EvolutionAndReopenConditionAdequacyReopen, supersession, stronger-source return, and changed-context triggers are clear.Repair the exact reopen, supersession, archive/front, improvement, or source-currentness assertion using C.32.PAD, C.32.FAIL, C.18, C.19, or E.23.
TransformerTransformedCorrespondenceAdequacyRequired correspondence between transformer-side and transformed-side structures is present when the decision depends on it.Repair the exact correspondence, Method/Work, Transformation, or flow-structure assertion using C.32.CONWAY, A.15, A.3.4, A.3.4.P, or E.18.
NonOverreadAndSubjectAssertionAdequacyThe decision, description, publication, Method, eval, evidence, assurance, and gate claims remain distinct subject assertions with exact defining or constraining ClaimGraphs.Repair the exact overread, relation, wording, or name using A.7, A.6.P, E.10, F.18, or the subject pattern for the unresolved question.
ConsequenceAndRepairGuidanceAdequacyConsequences, accepted losses, weak coordinates, and next repair instructions are actionable for the declared use.Repair the exact missing consequence, projection function, or coordinate assertion using PAD, ADR, or the coordinate-specific subject pattern.

Use-specific stop conditions

Declare the use before scoring. Common uses:

Declared useOrdinary stop condition
Internal architecture discussionEvery triggered coordinate is evaluated; 0 absent coordinates block reliance, and values below 3 sufficientlyExpressedForDeclaredUse name the patterns or sources that must be repaired.
Ready for architecture reviewNo triggered coordinate below 3 sufficientlyExpressedForDeclaredUse; candidate basis, trade-off, affected structures, work split, and reopen condition are strong enough for reviewers to inspect by value.
Ready for developer work or implementation commitmentEvery triggered coordinate is at least 4 wellExpressedForDeclaredUse unless a governing project decision explicitly declares a lower diagnostic floor and says the result is not an implementation commitment.
Ready for ADR-like publicationPublication projection, section functions, status, source-return, and supersession are at least 4 wellExpressedForDeclaredUse; if the record will guide developer work, use the developer-work floor too.
Ready for governance enforcementEvery triggered coordinate is at least 4 wellExpressedForDeclaredUse; enforcement status requires a separate current gate, evidence-use, assurance, or governance result.

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

ArchitectureDecisionAdequacyEvaluation@OrderFlow:
  declaredUse: readyForDeveloperWork
  claimScopeRef: OrderFlow developer-work readiness for the named decision and release slice
  selectedContextSliceRefs: OrderFlow service, named product-family release, and current developer-work window slices
  effectiveReferenceScheme: OrderFlow architecture decision scheme edition 4
  referencePlane: selected architecture and developer-work commitment
  evaluationWindow: review session 2026-07-31
  decisionQuestionInputProjectionRef: PAD decision relation plus its declared-use and source-return fields
  evaluatorSystemRef: ArchitectureReviewService-4
  evaluatorAssignmentSpeciesRef: ArchitectureReviewerAssignment
  evaluatorAssignmentOccurrenceRef: ArchitectureReviewerAssignment-6
  evaluationWorkRef: DecisionAdequacyEvaluationWork-12
  evaluationPerformedUnderAssignmentRef: performedUnderAssignment(DecisionAdequacyEvaluationWork-12, ArchitectureReviewerAssignment-6)
  adequacyResultEpistemeRef: DecisionAdequacyResult-12
  architectureDecisionRelationRef: PAD:order-flow-event-integration
  architectureDecisionRecordProjectionRef: ADR:order-flow-event-integration
  noAveragePolicy: true
  stopCondition: every triggered coordinate >= 4 wellExpressedForDeclaredUse
  strongestBlockingCoordinates:
    - MethodAndWorkDockingAdequacy
    - ArchitectureCharacteristicTradeoffAdequacy
  result: repairBeforeUse
CoordinateValueLabelShort rationale and repair
BoundedDecisionQuestionRecoverability4wellExpressedForDeclaredUseSubject, holon, exact claim scope and selected slices, scheme and plane, window, status, and question are clear; 5 would need transfer evidence across another product-family slice.
CandidateBasisAndSelectionTraceability4wellExpressedForDeclaredUseCandidate palette and selected option are cited; 5 would need another team to replay the selection without local recovery.
AffectedStructureAndDescriptionAdequacy4wellExpressedForDeclaredUseModule and information structures plus C.30.ASV refs are usable; 5 would need a worked cross-team source-return case.
ArchitectureCharacteristicTradeoffAdequacy3sufficientlyExpressedForDeclaredUseSubstitutability gain and latency loss are named, but guardrail eval rows are incomplete; repair through [C.32.ACS](/generated/patterns/C.32.ACS), [C.32.ACE](/generated/patterns/C.32.ACE), [C.25](/generated/patterns/C.25), and [C.16](/generated/patterns/C.16).
MethodAndWorkDockingAdequacy2partiallyExpressedForDeclaredUseThe ADR says "use events" but lacks a MethodDescription, exact acting System, readiness boundary, and expected structure effect. It also expressly requires accountable implementation under ServiceTeamAssignment while supplying neither the exact species/current occurrence nor an F.6 attribution for the already claimed Work. Repair those separate PAD and A.15 assertions; a Work-only instruction would not incur the attribution gap.
ArchitectDeveloperSplitAdequacy3sufficientlyExpressedForDeclaredUseThe acting systems and their Work split are clear, but the developer-side schema-refinement instruction lacks a source-return threshold. If responsibility is part of the decision, cite its admitted direct predicate, participants, applicability, and identity or return its exact missing governor; repair the exact PAD assertion and, if level pressure is real, the exact B.2.P or B.2 assertion.
PublicationProjectionAdequacy4wellExpressedForDeclaredUseADR section functions are mapped; 5 would need a replayed package-update or supersession case.
EvidenceEvalAndGateExitAdequacy3sufficientlyExpressedForDeclaredUseEvaluation and gate continuation conditions are named but not replayable enough for developer commitment; repair the exact predicates and assertions located through [C.32.ACE](/generated/patterns/C.32.ACE), [C.16](/generated/patterns/C.16), [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), or [A.21](/generated/patterns/A.21) as triggered.
EvolutionAndReopenConditionAdequacy4wellExpressedForDeclaredUseReopen triggers cover latency and schema-version pressure; 5 would need an executed supersession slice.
TransformerTransformedCorrespondenceAdequacy3sufficientlyExpressedForDeclaredUseToolchain and product-structure correspondence is locally stated; repair through [C.32.CONWAY](/generated/patterns/C.32.CONWAY) if it becomes load-bearing for work organization.
NonOverreadAndReceivingPatternAdequacy4wellExpressedForDeclaredUseDecision, ADR, method, eval, and gate claims are handled under their subject patterns; 5 would need a near-miss showing avoided overread.
ConsequenceAndRepairGuidanceAdequacy4wellExpressedForDeclaredUseConsequences and repair loci are actionable; 5 would need transfer evidence across another holon kind.

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

Risk handledHow C.32.ADA handles it
Record completeness as adequacyADR projection is one coordinate, not the whole evaluation.
Average-score driftCoordinate values are not averaged; weak coordinates drive repair.
Generic review proseEach weak coordinate names a governing repair pattern.
Gate confusionADA does not approve, certify, assure, or pass a gate.
Hidden method failureMethod and work docking has its own coordinate.
Evolution blindnessReopen, supersession, and source-return have explicit coordinates.

Conformance Checklist

RequirementRequired result
CC-ADA-1Declared use and stop condition are written before evaluation.
CC-ADA-2The evaluated decision relation and optional ADR projection are cited.
CC-ADA-3Every coordinate is scored 0 absent through 5 exceptionallyExpressedForDeclaredUse or marked notTriggered with a grounded reason.
CC-ADA-4Every value has adjacent-value rationale, not only a number.
CC-ADA-5No coordinate values are averaged or converted into one global score.
CC-ADA-6Weak coordinates name repair pattern refs and repair instructions.
CC-ADA-7Evidence, assurance, gate, measurement, eval, publication, Method, Work, and pattern-quality claims remain distinct subject assertions and cite their exact defining or constraining ClaimGraphs.
CC-ADA-8A project-local ADA record names both projectWorkOccurrenceRef and architectureDecisionEvaluationProjectUseRelationRef; the evaluated decision's relation, the suffix, or either field alone asserts no locality.
CC-ADA-9A local evaluator kind and a System-classification judgment use separate optional refs and neither requires an assignment. Actual evaluation first recovers the evaluator through A.13 and names independently admitted A.15.1 Work. Assignment species, occurrence, and F.6 refs are optional and appear only when the ADA record or receiving use expressly represents precise assignment-bound attribution; a missing or failed relation leaves the Work intact. An operation application and result episteme remain separate. Kind, classification, assignment, Work, attribution, responsibility, application, and result imply none of the others.
CC-ADA-10Every evaluation binds one exact U.ClaimScope, relevant A.2.6 U.ContextSlice membership, effective reference scheme and plane, evaluation window, and input projection; the declared-use label and coordinate table do not replace them.

Common Anti-Patterns and How to Avoid Them

Anti-patternSymptomRepair
DecisionAdequacyAverageStrong rationale and readable ADR produce a high average despite absent method docking.Remove the average; use weakest triggered coordinates to choose repair.
ADRCompletenessAsDecisionAdequacyThe record has all headings, so the decision is treated as adequate.Evaluate PAD relation, method docking, trade-off, source-return, and reopen conditions separately.
ReviewCommentWithoutRepairPatternThe reviewer says "unclear" or "not enough detail" without a target repair pattern.Assign the weak coordinate to C.32.PAD, C.32.ADR, A.15, C.30.AD, C.32.ACS, or another exact subject pattern.
GateByScaleA value of 4 or 5 is treated as approval or certification.Keep ADA as evaluation; use A.21, A.10, B.3, or governance patterns for gate, evidence, assurance, and enforcement claims.
NotTriggeredAsConvenienceA difficult coordinate is marked not triggered to close the review.Require a declared-use reason and receiving-pattern boundary; otherwise score it and repair.
MethodDockingSkippedThe decision is adequate for architecture discussion but then used to direct developer work.Re-declare use as developer-work readiness and evaluate method docking, work split, and publication handoff.
SystemRoleLabelAsEvaluatorA reviewer system-role kind, assignment, or ADA record is treated as the performer of evaluation.Recover the exact admitted evaluator System through A.13 and let A.15.1 independently admit the dated evaluation Work. Add assignment species, occurrence, and F.6 only when precise assignment-bound attribution is expressly represented. Keep any responsibility relation, result episteme, and operation application separate.
ContextLabelAsEvaluationScopeA project, domain, or bounded-context label stands in for the evaluation boundary.Bind the exact U.ClaimScope, selected context slices, scheme and plane, evaluation window, and decision-question input projection.

Consequences

ConsequenceBenefitCost
Adequacy is coordinate-based.Review can point to exact repairs instead of vague approval or rejection.Evaluation takes longer than reading a record once.
Declared use controls stop condition.A decision can be adequate for one use and inadequate for another without contradiction.Teams must state intended use before scoring.
No average is allowed.Weak but critical coordinates stay visible.Some dashboards and summaries need redesign.
Explicit repair conditions and subject-pattern locators are mandatory.Review results become actionable.Reviewers must recover the exact missing assertion and the pattern description containing its definition or constraint.

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 to inspectWhy this source is load-bearing hereTransfer into ADAConcrete ADA mutationBlocked overread
Current FPF E.21 scale disciplineExisting FPF pattern for declared-use evaluation, exact 0 absent through 5 exceptionallyExpressedForDeclaredUse labels, complete coordinates, adjacent-value rationale, and no averaging.Reuse the value domain and evaluation discipline for architecture decisions without copying pattern-quality coordinates.ADA requires declared use, complete coordinate set, E.21 value labels with adjacent rationale, no average, and use-specific stop conditions.E.21 pattern-quality status and coordinates are not architecture-decision adequacy.
C.32.PAD and C.32.ADRPAD and ADR define the decision relation and publication projection being evaluated.Make relation adequacy and projection adequacy separate coordinates.ADA can say a PAD relation is usable while ADR projection needs repair, or the reverse.A complete ADR does not make the decision relation adequate.
ISO/IEC/IEEE 42010:2022 official standard (https://www.iso.org/standard/74393.html; IEEE page https://standards.ieee.org/ieee/42010/6846/) with the 42010 companion site as secondary reading (https://iso-architecture.org/42010/)Current official source for architecture descriptions, viewpoints, views, correspondence, and rationale; the companion site is used only as secondary reading.Add coordinates for affected structure, architecture-description adequacy, and source-return.ADA identifies C.30.AD and C.30.ASV as subject-pattern locators for weak description assertions.Architecture-description adequacy does not decide or approve the architecture.
Ford, Parsons, Kua, and Sadalage, Building Evolutionary Architectures, 2nd ed. (https://www.oreilly.com/library/view/building-evolutionary-architectures/9781492097532/)Current practitioner source for architecture feedback and incremental change under eval-like mechanisms.Add evolution, reopen, guardrail, and confirmation coordinates.ADA checks reopen and eval exits before a decision is used for long-running work.Source-side fitness-function wording is not imported as ADA object naming.
Ford, Richards, Sadalage, and Dehghani, Software Architecture: The Hard Parts (https://www.oreilly.com/library/view/software-architecture-the/9781492086888/)Current practitioner source for trade-off analysis under competing characteristics.Add architecture-characteristic trade-off adequacy and accepted-loss repair.ADA identifies ACS, ACE, C.16, C.25, C.31, or C.31.ASAP as subject-pattern locators for the exact weak trade-off assertion.Trade-off discussion is not an assurance claim or governance approval.
2026 ADR violation-detection research (https://arxiv.org/abs/2602.07609)Recent research shows explicit, code-inferable decisions are easier to check than implicit deployment or organization decisions.Add confirmation, source-return, method, deployment, and organization refs to adequacy checks when live.ADA scores confirmation and method docking separately and blocks hidden organizational knowledge from passing as ready.Automated violation detection is not proof, evidence, assurance, or gate passage.

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, and E.21; uses A.1.1 only when a selected BoundedModelUseStructure changes 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.PAD to repair the decision relation and C.32.ADR to repair ADR-like publication projection.
  • Description and structure boundary: Use C.30, C.30.AD, and C.30.ASV for architecture claim, description, and view adequacy.
  • P2S docking: Use C.32.P2S when 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, and C.24 for 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, and C.31.ASAP for 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.

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:

"This view is useful, but what structure does it actually capture?"
"The ADR says what was decided; which selected structures and hidden losses does it leave behind?"
"The code-agent map found dependencies and invariants; can we rely on them for architecture work?"
"The neural-network architecture review names attention, cache, router, and pruning; what FPF structures are recoverable?"
"The operation observation shows the real system diverged; what actual structure is visible enough to return to synthesis?"

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:

StructuralInformationAdequacyNote@Context:
  architectureClaimRef?:
  describedHolonRef:
  architectureConcern:
  intendedArchitectureUse:
  claimScopeRef?: U.ClaimScope
  qualificationWindowRef?:
  selectedStructureRefs:
  selectedSourceStructureRefs?:
  sourceDescriptionOrViewRefs?:
  narrativeRenderingRefs?:
  constraintGovernedUnfoldingStructureRef?:
  decisionOrRecordCarrierRefs?:
  realizedStructureObservationRefs?:
  capturedSelectedStructure:
  expectedButUncapturedStructureHypothesis?:
  lostOrHiddenStructure:
  compressionOrAbstractionMode?:
  observerOrBudgetBoundary?:
  relationObservationClass?:
  typedRelationSemantics?:
  unexploredRegionRefs?:
  sourceLabelRecoveryRef?:
  mathematicalLensUseOutputRef?:
  measurementOrEvalRefs?:
  adequacyEvidenceRefs:
  admissibleUse:
  nonAdmissibleUse:
  missingStructureReturnCondition:
  nextClaimOrRuleRef?:
  receivingClaimKind:

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

ForceTension
Useful carriers vs overreadA small carrier can guide architecture work, but it cannot carry every selected structure, decision, evidence, or work claim.
Capture vs lossArchitecture use often depends as much on what was lost or hidden as on what was captured.
Cheap first note vs full recordMany cases need one note before a full architecture description, view correspondence record, measurement, or eval result.
Observer boundaryCode agents, learned representations, probes, and epiplexity-like lenses expose structure under observation and budget limits.
Source label pressureDomain labels are useful recognition cues but must be recovered into selected structure, relation, bearer, characteristic, and the next claim plus the rule or test it needs.
EvolutionThe captured structure can decay when source publication edition, realized structure, environment, bearer, or holon level changes.

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:

  1. Name the architecture claim or pre-claim, described holon, architecture concern, intended use, and any ClaimScope or qualification window that changes the adequacy judgment.
  2. 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, or C.32.P2S.
  3. Name the carrier, selected source structure, description, view, narrative rendering, decision record, eval report, method handoff, generated relation graph, or realized observation being used.
  4. State the captured selected structure in relation terms: relations, constraints, invariants, allocations, compositions, variation classes, operations, dynamics refs, or preserved organization.
  5. 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.
  6. 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.
  7. Add observer or budget boundary when the carrier comes from a bounded observer, learned representation, probe, relation graph, or epiplexity-style lens.
  8. 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.
  9. 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.
  10. 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

BiasHow C.33 counters it
Carrier completeness biasRequire captured selected structure, expected but uncaptured structure, lost or hidden structure, admissible use, and non-admissible use before relying on the carrier.
Metric biasTreat entropy, epiplexity estimate, benchmark score, dashboard value, dependency F1, and invariant F1 as readings only when C.16 or C.32.ACE has opened that claim.
Source-label ontology biasKeep source labels such as layer, router, cache, expert, pruning, distillation, block, DSM cluster, and architecture-search result as labels until C.30.STRAT, C.30.TFS-REL, A.6.M, C.31, C.32, or another pattern defines the selected structure and relation.
Observer-belief biasRecord observation class, confidence, active-passive gap, budget boundary, and unexplored regions for agent-produced or probe-produced carriers. Do not infer internal belief, safe change, or assurance from a map.
Decision-memory biasTreat ADR-like records as decision descriptions and method expectations. Use C.32.PAD or C.32.ADR for decision and projection claims, and use C.33 only for what structural content the record carries or loses.

Conformance checklist

CheckPass condition
CC-C33-1The note names the described holon, architecture concern and intended use, selected structure refs or structure kinds, carrier or observation being used, any evidence supporting an adequacy or insufficiency conclusion, and any material ClaimScope or qualification window.
CC-C33-2Captured selected structure is stated as relations, constraints, invariants, allocations, compositions, variation classes, operations, dynamics refs, or preserved organization.
CC-C33-3Expected but uncaptured structure and lost or hidden structure are stated when the next use depends on them.
CC-C33-4Observer or budget boundary is present for agent-produced, learned, probed, epiplexity-style, or maps derived from a named source publication, source model, or source codebase.
CC-C33-5Each current mathematical-lens, measurement, eval, decision, evidence, assurance, gate, release, method, work, or publication claim uses the pattern that defines or tests it.
CC-C33-6Admissible use, non-admissible use, missing-structure return condition, the next claim or question, and its required rule or test are named.

Common Anti-Patterns and How to Avoid Them

Anti-patternWhy it failsRepair move
Diagram as complete architectureThe diagram may show modules or links while hiding placement, runtime dependency, control authority, evidence structure, bearer constraints, or data custody.Write the C.33 note from the diagram: captured structure, missing structure, lost relation semantics, admissible use, and the condition that reopens the next dependent claim or question. Add its exact predicate and assertion identity only when that identity must travel independently.
ADR as realized structure proofA decision record can carry decision memory and method expectation without showing what was built or how it behaves.Use C.32.PAD or C.32.ADR for the decision claim; use C.33 only for the structural content and loss carried by the record; state realization claims using the exact architecture or evidence predicate and cite the pattern that defines or tests it when that reference is needed.
Narrative as complete architectureA narrative can preserve a route through selected structures while hiding placement, alternatives, measurements, interfaces, or realized structure.Use A.6.3.NAR for the structure-to-narrative rendering relation and C.33 for captured and lost selected structure before architecture reuse.
Code-agent graph as safe-change authorityA graph can expose observed and inferred relations while leaving unknown regions and hidden invariants.Add observation class, confidence, unexplored regions, and non-admissible use. Use the patterns that define the safe-change, assurance, gate, and release checks when those claims are current.
Metric as structural adequacyA score, entropy value, epiplexity estimate, benchmark trace, or dependency F1 is a reading only under the applicable measurement or eval rule.Keep it as lens or reading context until C.16, C.25, or C.32.ACE defines what is measured and how it may be used.
Neural label importTerms such as attention, SSM, router, expert, cache, pruning, distillation, and NAS can hide several structure kinds and characteristics.Recover the selected structure kind, relation, bearer, affected characteristic, preserved structure, lost structure, and the next architecture claim plus the rule or test it needs before using the label in architecture work.

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

Source or practice lineAdopt, adapt, or rejectConcrete C.33 locus changedBoundary and currentness
Finzi et al., From Entropy to Epiplexity, arXiv:2601.03220Adapt observer-bounded structural information.Adds observerOrBudgetBoundary?, strengthens hidden-structure and compression guidance, and supports the warning that recoverable structure is observer-bound.Epiplexity is not an architecture characteristic, proof, selector, evidence, assurance, decision, or realized-structure observation by itself. Reopen the note when observer budget, source publication edition, or downstream use changes.
Cao et al., Multi-Relational Structural Entropy, arXiv:2405.07096Adapt relation heterogeneity and graph structural-information pressure.Strengthens typedRelationSemantics?, relation-kind recovery, and measurement or eval routing.A graph entropy value requires C.16 and C.32.ACE when measured or evaluated; it does not establish architecture adequacy.
Sapunov, Theory of Code Space, and ToCS code-agent architecture-map practiceAdopt the partial-observability and belief-probing lessons; adapt them beyond software code agents.Adds relationObservationClass?, confidence class, active-passive gap, unexplored regions, invariant return to the named architecture source map or the rule that defines the invariant claim, and non-overread of JSON probes and benchmark scores.A probe, JSON output, dependency F1, invariant F1, active-passive gap, or benchmark score is not architecture adequacy, evidence sufficiency, safe-change authority, assurance, gate passage, or release authority. Reopen when the probed codebase, architecture source map, or observation budget changes.
GonzoML neural-network architecture intakeAdapt practitioner operation labels into FPF recovery steps.Adds neural source-label recovery for block substitution, dataflow change, routing, gating, cache, memory, pruning, distillation, NAS, ablation, and affected characteristics.Source labels and results do not become FPF ontology or adequacy. Recover selected structure, relation, bearer, affected characteristic, loss, and the next architecture claim plus its required rule before architecture use.

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, and C.32.
  • Uses: C.29 when a mathematical lens exposes or compresses structure; C.16, C.25, and C.32.ACE when 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, and F.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:

"These two diagrams look equivalent; what relation is actually preserved?"
"The model query and the architecture view should correspond; what was lost in projection?"
"The generated graph matches the module graph; is the semantic relation the same?"
"This candidate preserves dataflow but changes control authority."
"The neural architecture replacement keeps shape but changes routing and memory placement."
"The narrative order preserves the architecture trade-off; what selected source structure is still same enough for this use?"

The first useful output is StructuralPreservationAdequacyNote@Context:

StructuralPreservationAdequacyNote@Context:
  selectedSourceStructureRefs:
  selectedTargetStructureRefs:
  architectureClaimRef?:
  mappingMode:
    exactEquivalence | isomorphism | homomorphism | correspondence |
    projection | abstraction | coarsening | simulationRelation |
    nearSameness | declaredOther
  preservedRelationsOrConstraints:
  preservedInvariantsOrCompositions?:
  lostStructure:
  relationTypeSemantics?:
  relationObservationClass?:
  directionality:
  scopeOrScaleWindow?:
  lensUseOutputRef?:
  correspondenceRecordRef?:
  constraintGovernedUnfoldingStructureRefs?:
  admissibleUse:
  nonAdmissibleUse:
  preservationLossReturnCondition:
  nextClaimOrRuleRef?:
  receivingClaimKind:

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

ForceTension
Equivalence vs useExact equivalence is rare and often unnecessary; the declared use decides how much preservation is enough.
Formal rigor vs practitioner actionFormal mapping modes help only when preserved and lost structure are named in architecture terms.
Shape vs semanticsTwo graphs, views, or diagrams can have the same shape while their relation types differ.
Compression vs lossProjection, abstraction, coarsening, and simulation relations make work possible by dropping structure. In a chain from selected source structures to architecture, architecture description or view, and narrative or framework carrier, preservation must be checked relation by relation rather than claimed as one global sameness.
Cross-context reachA mapping across teams, source traditions, tool models, or holon levels needs the applicable Bridge predicate and conformance test when substitution or transfer is claimed.

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:

  1. Name the selected source structures and selected target structures. Do not start from labels, diagrams, or tool objects alone.
  2. Name the intended architecture use: view correspondence, candidate comparison, structure recovery, generated-output admission, realization check, eval support, decision repair, or another receiving claim.
  3. Choose the weakest mapping mode that is adequate for the use. Use exactEquivalence only when empty loss is justified.
  4. State preserved relations or constraints in domain and FPF terms. Include relation-type semantics when edge or link meaning changes the use.
  5. State lost structure, hidden structure, directionality, and scope or scale window.
  6. Cite C.29 only when a mathematical object, graph match, functor, invariant, entropy, or formal mapping is being used as a lens.
  7. Cite C.30.ASV, C.30.AD, or their correspondence records when the relation is view or architecture-description correspondence.
  8. Cite A.6.3.NAR when 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.
  9. Cite F.9 or F.15 when the claim crosses bounded contexts, source traditions, or later conformance strengthening.
  10. 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

BiasHow C.34 counters it
Shape-equivalence biasRequire relation-type semantics, preserved structure, and lost structure. Same nodes or edges are not enough.
Formalism-laundering biasKeep graph isomorphism, morphism, functor, entropy, or simulation wording as lens or mapping support until the architecture use, preserved structure, and loss are declared.
Symmetric-equivalence overclaimRequire directionality and scope. A projection, abstraction, simulation relation, or coarsening often licenses one direction only.
Semantic-loss hidingMake lost control authority, allocation, bearer semantics, placement, timing, confidence, or source-tradition meaning explicit before the mapping is reused.
Bridge-bypass biasHandle cross-context substitution, source-tradition transfer, and later conformance strengthening under F.9 or F.15 instead of letting C.34 authorize the transfer alone.

Conformance checklist

CheckPass condition
CC-C34-1Source and target structures are named before the mapping claim.
CC-C34-2Mapping mode is selected and is not stronger than the declared use needs.
CC-C34-3Preserved relations or constraints and lost structure are both stated.
CC-C34-4Relation-type semantics, observation class, directionality, and scope are present when they affect use.
CC-C34-5Each current mathematical-lens, view, description, Bridge, conformance, candidate-synthesis, measurement, eval, decision, evidence, assurance, gate, release, or work-authorization claim uses the pattern that defines or tests it.
CC-C34-6Admissible use, non-admissible use, preservation-loss return condition, the next claim or use, and its required rule are named.

Common Anti-Patterns and How to Avoid Them

Anti-patternWhy it failsRepair move
Edge-isomorphism overreadIsomorphic graphs can preserve shape while changing edge meaning, relation observation class, or use.Record relation-type semantics, preserved relation, lost relation, and non-admissible use.
Semantic-loss hidingA projection or coarsening can look clean because it drops exactly the structure that the next decision needs.Name lost structure and preservation-loss return condition before comparison, decision repair, or candidate admission.
Exact-equivalence overclaimExact equivalence is stronger than most architecture uses need and is often false.Choose the weakest adequate mapping mode: correspondence, projection, abstraction, coarsening, simulation relation, or near-sameness when that is enough.
Generated graph proof overclaimA generated graph can match labels or topology while hiding dynamic wiring, confidence, or unexplored regions.Use C.34 only for the preservation claim; handle generated-carrier admission under C.35, and apply the rules that define evidence, assurance, gate, or release claims when those claims are current.
Narrative-order equivalence overclaimA narrative can preserve a useful path through selected source structure while dropping alternatives, relation semantics, measurements, or directionality.Record the weakest adequate correspondence, preserved structure, lost structure, directionality, and non-admissible use; use A.6.3.NAR for the narrative rendering relation.
Formal lens launderingA morphism, functor, entropy value, or graph match sounds rigorous but may be local to a mathematical object.Handle lens use under C.29; use C.34 only after preserved structure, lost structure, mapping mode, and architecture use are stated.
Bridge-governance bypassA cross-context or cross-tradition mapping can preserve local structure while losing local sense.Use F.9 for the bridge and F.15 for later regression or conformance strengthening before substitution is relied on.

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

Source or practice lineAdopt, adapt, or rejectConcrete C.34 locus changedBoundary and currentness
Yang et al., Structural Equivalence in Subgraph Matching, arXiv:2301.03161Adapt structural-equivalence and symmetry discipline.Strengthens mappingMode, the weakest adequate mapping rule, and the warning against label or shape overread.Subgraph structural equivalence does not define holon architecture equivalence outside declared structures and use. Reopen when the source graph, target graph, or use changes.
Fong and Spivak, Seven Sketches in Compositionality, arXiv:1803.05316Adapt applied category-theory preservation language through C.29.Keeps morphism, functor, sketch, and composition vocabulary tied to preserved structure, lost structure, mapping mode, and architecture use.Older source is lineage and still useful as applied compositional practice, but it does not become the default FPF architecture ontology.
Multi-view architecture and MBSE query and view practiceAdopt the ordinary need for view correspondence, projection, query, and coarsening.Adds view and description cases plus requires C.30.AD and C.30.ASV.View output or query output is not architecture and not realized structure. Reopen when viewpoint, query rule, model edition, or described structure changes.
Sapunov, ToCS, and code-agent architecture-map practiceAdapt partial-observation preservation discipline.Adds relation observation class, inferred edges, unexplored regions, confidence, and active-passive gap as preservation-lowering conditions.A code-agent map, JSON probe, dependency F1, invariant F1, or active-passive gap does not prove architecture equivalence, safe change, assurance, gate passage, or release readiness.
GonzoML neural-network architecture intakeAdapt neural architecture operation language.Adds dataflow, routing, memory placement, cache placement, resource boundary, block substitution, and affected-characteristic checks for neural structure substitution.Neural labels, ablations, pruning masks, distillation success, or benchmark gains remain source cues until selected structures, preserved relations, lost relations, and the next architecture claim plus its required rule are recovered.

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, and F.9.
  • Uses: C.16, C.25, and C.32.ACE when 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, and F.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:

"The LLM generated an architecture diagram; can it seed synthesis?"
"The DSM clustering suggests modules; is this a candidate architecture yet?"
"The MBSE query produced a view; does it describe an obtaining structure or only propose one?"
"NAS found a Pareto point; what architecture claim can use it?"
"A graph grammar transformed the model; what preservation and bearer boundary must be checked?"

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:

Result: <exact result relied on>
Organization: <what already obtains or is only proposed>
Next-use condition: <one condition still required>
Limit and return: <forbidden overread and where to return>

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:

StructuralSynthesisDiscoveryAdequacyNote@Project:
  resultRef:
  organizationConcern:
  nextArchitectureUseAndCondition:
  forbiddenOverreadOrReturn:
  resultKindAndIdentityRule?:
  admissibleUse?:
  unresolvedConditions?:
  representationRef?:
  representedObjectRef?:
  publicationFormRef?:
  publicationOccurrenceRef?:
  presentationCarrierRef?:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  structuralSynthesisAdequacyNoteProjectUseRelationRef?: U.RelationRef under a named architecture-use or work-use predicate when that relation identity is material
  groundedArchitectureQuestionRef?:
  resultBranch?: transformation | discovery | generative-proposal
  generationOrDiscoveryMethodRef?:
  generationOrDiscoveryWorkRef?: U.EntityRef constrained to U.Work
  generationOrDiscoveryWorkAttributionRefs?: refs to obtaining F.6 performedUnderAssignment relations only when the note or receiving use expressly represents attribution
  workToTransformationOrProductionClaimRefs?:
  transformationBranch?:
    exactSourceObjectRefs:
    exactResultObjectRefs:
    transformationTraceRef:
    preservedStructure:
    lostStructure:
    actualTransformationRefs?:
  discoveryBranch?:
    observationOrExtractionBasis:
    observedInferredUnknownStatus:
    coveredRegion:
    unexploredRegion:
    uncertainty:
    validation:
  generativeProposalBranch?:
    constraintRefs:
    proposedOrganizationContent:
    knownOmissions:
    validationNeeds:
    declaredBaselineComparison?:
      exactBaselineObjectRefs:
      preservedStructure:
      lostStructure:
  obtainingConstraintGovernedUnfoldingStructureRef?: exact A.22.CGUS reference only
  sourceLabelRecoveryRef?:
  obtainingStructureRefs?: exact A.22 U.Structure references only
  modalArchitectureClaimRef?: C.30 ArchitectureClaimRef or C.2.1 ClaimAddress to its exact claim
  candidateAdmissionCondition?:
  bearerOrRealizationBoundary?:
  obtainingRealizedHolonStructureRefs?: exact positive A.22 references only
  measurementOrEvalReturnRefs?:
  bearerFeasibilityQuestionRef?:
  nextClaimOrRuleRef?:
  receivingClaimKind?:

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

ForceTension
Discovery value vs authority overreadGenerated and discovered outputs widen the candidate space, but cannot select, decide, prove, or realize architecture by themselves.
Result, proposal, obtaining structure, and representationClaim-bearing result, modal architecture proposal, obtaining A.22 structure, represented object, representation, publication form or occurrence, and presentation carrier have different identities; include only the distinctions on which the architecture use relies.
Search quality vs architecture adequacyA Pareto point, benchmark score, archive member, or cluster objective can guide synthesis only through the evidence required by its actual branch and the concrete rule for the next synthesis claim.
Model transformation vs preservationGraph grammars and model transformations can return useful results, but transformation rules, exact source and result objects, trace, preserved structure, and lost structure matter only in the transformation branch.
Bearer feasibilityA function or relation found by search matters architecturally only when an admitted bearer can carry it under constraints.
Reusable generator boundaryOne-case generated output stays with C.35 and its declared next use; reusable-generator or mechanism-suite claims require the patterns that define or constrain those claims.

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:

  1. Write the sentence or four lines. If they let the receiver act safely, stop.
  2. When the obtaining-versus-proposed distinction affects use, identify the exact C.30 ArchitectureClaim or 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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:

Result: MedicalDeviceProposal-7.
Organization: a proposed device organization; its constituents and relations do not yet obtain.
Next-use condition: C.32 may use it after the missing safety constraint and bearer question are explicit.
Limit and return: do not read the proposal or diagram as A.22 structure or decision; return to the claim when either gap changes.

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

BiasHow C.35 counters it
Output authority biasRequire only the readable minimum before another architecture claim relies on the result: exact result, actual or proposed organization, next-use condition, and forbidden overread or return. Add representation, publication, branch, or other detail only when the use depends on it.
Pareto-point admission biasTreat a Pareto point, benchmark score, archive member, or search trace as a candidate input cue until its branch-specific basis and the concrete candidate-use rule are named.
Reusable-generator collapseKeep one-case output admission in C.35; handle reusable-generator, mechanism-suite, model-family, or production-pipeline claims with E.20, G.1, G.10, G.11, or another pattern that defines or constrains those claims.
Bearer-free synthesis biasRequire bearer or realization boundary before treating a discovered function, relation, or candidate form as architecturally feasible.
Eval substitution biasHandle eval programs and eval results under C.32.ACE; handle measurement under C.16; do not let good eval numbers act as candidate admission or decision authority.
Currentness freezeReopen when result identity or claim content, represented object or correspondence, source publication edition or source-use record, search space, query rule, validation trace, bearer constraints, realized structure, or eval return changes. A carrier-only change reopens C.35 only when availability or form changes the intended use.

Conformance checklist

CheckPass condition
CC-C35-1A sentence or four-line statement names 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. This is a conforming first result.
CC-C35-2An optional materialized note has the exact result as its EntityOfConcern and repeats the readable minimum. It adds identity, representation, publication, project-use, branch, Method, Work, attribution, bearer, evaluation, or next-claim fields only when the receiving use relies on them. Any present publication-form, publication-occurrence, or presentation-carrier reference names its truthful object; absent publication apparatus creates no field-filling duty.
CC-C35-3When branch evidence is relied on, exactly one branch is selected. Transformation supplies exact source and result objects, trace, preservation, and loss; discovery supplies observation or extraction basis, what is observed, what is inferred, what remains unknown, coverage, uncertainty, and validation; generative proposal supplies constraints, proposed organization content, omissions, and validation needs, with source and preservation only for an exact declared baseline.
CC-C35-4A positive structure reference passes all four A.22 discriminators. Otherwise the organization remains modal architecture-claim content, which C.32 may receive as candidate input without treating it as obtaining architecture.
CC-C35-5Bearer or realization detail appears only when the intended use relies on feasibility or realization; any such question uses the rule that defines or tests it.
CC-C35-6Any current archive, front, pool, publication, eval, measurement, mathematical-lens, decision, evidence, assurance, gate, release, Method, or Work claim uses its direct pattern; an absent claim creates no C.35 field-filling duty.
CC-C35-7The first result states the next-use condition and limit or return. An exact next-claim or rule reference is added only when the receiving action relies on reidentifying it independently.

Common Anti-Patterns and How to Avoid Them

Anti-patternWhy it failsRepair move
LLM output as architecturePlausible prose and a diagram may denote a modal architecture claim and its representation; neither supplies obtaining relation occurrences, an A.22 structure, bearer feasibility, decision, or realization.Recover the exact architecture claim or ClaimAddress, identify the diagram as a C.29 representation only when used, state the admission condition and return, and let C.32 consume the modal proposal without actualizing it. Use C.32.PAD and C.32.ADR for decision and ADR claims.
Pareto point as admissionA Pareto result records trade-off position under chosen criteria; its graph, table, or file is a neighboring representation or publication item, not architecture adequacy.Name the exact result and the current next-use condition. Add search space, criteria, constraints, bearer boundary, and eval return only when the candidate use relies on them; then handle that use under C.32.
One output as reusable-generator governanceA single generated artifact does not describe the method, mechanism suite, dataset, prompt policy, or refresh process that produced a reusable generator.Keep the one-case output in C.35 and open E.20, G.1, G.10, G.11, or another pattern that defines or constrains the reusable-generator claim.
Cluster as module architectureA cluster claim can expose co-change or dependency pressure while leaving functional-bearer semantics, interface substitutability, and obtaining relation occurrences unknown; its matrix or file does not settle that gap.Recover the exact cluster result, extraction basis, observed and inferred content, unknowns, coverage, uncertainty, validation, and any C.29 representation. Keep the inferred organization modal unless A.22 passes; handle modularity and reuse under C.31 and candidate use under C.32.
Transformation output as feasibility proofA graph grammar or model-transformation Method can return a useful claim and representation while proving neither an actual U.Transformation nor an obtaining A.22 result structure.Record the exact result, C.29 representation only when used, Method, Work and attribution when current, transformation trace, exact source and result objects, preservation, loss, and bearer boundary. Keep a proposed result organization in its architecture claim; cite A.22 only after its four discriminators resolve, and cite A.3.4 plus the Work-to-change or A.15.PROD claim for any actual change.
Bypassing eval and measurement governanceA search score, benchmark, ablation, or validation trace can look like proof of architecture quality.Handle readings under C.16, Q-bundle use to C.25, eval programs and eval results to C.32.ACE, and decisions to C.32.PAD.

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

Source or practice lineAdopt, adapt, or rejectConcrete C.35 locus changedBoundary and currentness
MBSE query and view generationAdapt query results as discovery while separating the claim-bearing result, represented object, representation, and publication-side availability.Adds query or extraction basis, separate observed, inferred, and unknown content, covered and unexplored model region, uncertainty, validation, and C.30.AD / C.30.ASV exits.Query or view output is not architecture, realized structure, or proof. Reopen when result identity, model edition, query rule, viewpoint, represented object, coverage, or relied-on availability changes.
Graph grammars and model transformationsAdapt rule-governed transformation as the transformation branch.Adds exact source and result objects, transformation trace, preserved structure, lost structure, and C.34 preservation exit.Grammar or transformation output does not prove adequacy, feasibility, or realization. Reopen when transformation rules, source object, result object, trace, or constraints change.
DSM, MDM, and modularization practice including Jiang and Luo, arXiv:2604.28018Adapt modularization and LLM-assisted DSM work as discovery.Adds extraction basis, observed dependencies, inferred clusters, unknown functional-bearer semantics, coverage, uncertainty, validation, and C.31 plus C.32 exits.Cluster, partition, or MDM slice is not candidate architecture adequacy. Reopen when relation matrix, covered region, modularity objective, functional prior, validation, or solution pool changes.
Multi-objective NAS and Sukthanker et al., arXiv:2402.18213Adapt multi-objective search as a generative-proposal source.Adds constraints, proposed neural organization, known omissions, validation needs, search criteria, bearer boundary, eval return, and C.32 admission condition.A Pareto point or neural graph is not holonic architecture adequacy. Preservation is claimed only against an exact declared baseline. Reopen when search space, constraints, criteria, hardware target, proposal content, or eval trace changes.
DSE, QD, OEE, NQD, and evolutionary architecture practice inherited through C.32Adapt retained alternatives and stepping-stone pressure as candidate-input practice.Strengthens candidate-generation input, result-use return, archive exit, front exit, pool-policy exit, and C.32 coordination.These practices do not make C.35 a second candidate-set admission rule. C.18, C.19, and G.5 define archive, front, and pool policy; C.32 defines candidate-palette admission.
AI-assisted architecture design and AI-assisted ADDAdapt generated decompositions, relation graphs, and decision proposals through the generative-proposal branch.Adds constraints, proposed organization or claim content, known omissions, source-label recovery, validation needs, and candidate-admission boundary.An LLM proposal, ADD suggestion, benchmark trace, or agent consensus is not decision authority, evidence sufficiency, realization, or architecture adequacy by itself.
Sapunov, Theory of Code Space, and code-agent architecture-map practiceAdapt partial-observability mapping through the discovery branch.Adds observation or extraction basis, separate observed, inferred, and unknown content, confidence, covered and unexplored regions, active-passive comparison, and validation.A code-agent map, JSON probe, benchmark score, dependency F1, invariant F1, or active-passive gap is not architecture adequacy, internal-state proof, safe-change authority, evidence sufficiency, gate passage, or release authority.
GonzoML neural-network architecture intakeAdapt neural architecture operation language as source-label recovery for discovery or generative proposals.Adds recovery for dataflow change, routing, gating, memory placement, cache placement, block substitution, pruning, distillation, NAS, ablation, and compute, memory, and latency trade-offs without choosing a branch by label.Neural-network labels, ablation gains, pruning masks, distillation success, and search outputs remain source cues until the branch-specific basis, bearer, affected characteristic, and next architecture claim plus its required rule are recovered.

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, and C.32.
  • Uses: C.34 when the transformation branch or an explicit baseline comparison must preserve selected source structure; C.33 when capture and loss in the output are the current issue; C.29 when a formal search, graph, entropy, category, or learned representation is being used as a mathematical lens.
  • Coordinates with: A.3.4 for each actual bounded change; A.15.1, A.2.1, and F.6 for performed generation or discovery Work; A.15.PROD and A.6.RCD for exact production or Work-to-change claims; C.36 when 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, and C.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: CulturalEvolutionEngineering Plain-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:

CulturalEvolutionCaseCard@Context:
  CaseRef:
  CaseScopeOrModelUseBoundary:
  CollectiveHolonOrDisciplineScope:
  VariantRefsOrDescription:
  TransmissionRecognitionSelectionOrMemoryRelations:
  MediationOrMeasurementRefs?:
  PublicationRefs?:
  CurrentEvolutionaryQuestion:
  ApplicablePatternRefs?:
  NextActionOrStop:

@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

ForceTension
Domain recognizabilityMusic, dance, medicine, science, engineering, and organizations need familiar words such as style, tradition, technique, school, canon, platform, and regime.
Ontological parsimonyThose words often name slot positions or bridges over existing FPF values rather than new root kinds.
Variant-set usefulnessOpen-ended search, archives, fronts, pools, and selected sets help keep evolving alternatives visible.
Cultural-evolution specificityVariant generation and retention alone do not name transmission, recognition, memory, canon, system-role assignment, method-family evolution, or mediation.
Intervention valueA project needs to change something: a generation relation, transmission relation, recognition relation, selection relation, memory relation, method family, work family, mediation architecture, measurement relation, work plan, performed work, or refresh relation.
Didactic economyThe first-use pattern must be readable without becoming a cultural-evolution textbook or a list of every possible overread.

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@Context keeps a multi-relation case together;
  • StyleTraditionTermBridgeTable@Context keeps a familiar local label connected to the recovered FPF value or relation;
  • CulturalEvolutionInterventionCard@Project retains 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.

StyleTraditionTermBridgeTable@Context:
  SourceLabel:
  SourceContext:
  RecoveredFPFValueOrRelation:
  ApplicablePatternRef:
  SenseCellRefs:
  BridgeRefs:
  AdmissibleUse:
  BlockedUse:
  CurrentnessCondition:

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.

CulturalEvolutionInterventionCard@Project:
  ProjectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  InterventionCardProjectUseRelationRef?: U.RelationRef, only when a named pattern defines this project-use relation and the occurrence obtains
  InterventionRef:
  CulturalEvolutionCaseRef:
  ProblemCardRef?:
  TargetedRelation:
  AffectedMethodFamilyRefs?:
  AffectedWorkFamilyRefs?:
  AffectedAssignmentSpeciesRefs?: U.RelationKindRef, each constrained under U.SystemRoleAssignment
  AffectedAssignmentOccurrenceRefs?: U.RelationRef, each constrained to U.SystemRoleAssignment and paired with its species
  AffectedCanonOrMemoryEpistemeRefs?:
  AffectedSelectionOrRecognitionRegimeRefs?:
  AffectedMediationSystemOrArchitectureRefs?:
  PublicationRefs?: refs to the exact E.17 source-backed face or E.24.PUB publication occurrence, publication form, presentation carrier, audience-declaration episteme, bounded-use-declaration episteme, or availability claim needed by this intervention
  VariantSetOrPortfolioRefs?:
  TransformationFlowStructureRef?: exact independently selected E.18 TransformationFlowStructure
  P2WCarryThroughRef?:
  WorkPlanRef?:
  InterventionSystemRoleKindRef?: U.KindRef resolving to one exact local system-role kind
  InterventionSystemRoleClassificationJudgmentRef?: U.RelationRef
  InterventionAssignmentSpeciesRef?: U.RelationKindRef constrained under U.SystemRoleAssignment
  InterventionAssignmentOccurrenceRef?: U.RelationRef constrained to U.SystemRoleAssignment
  PerformedInterventionWorkRef?: U.EntityRef constrained to U.Work
  PerformedInterventionWorkAttributionRefs?: refs to obtaining F.6 performedUnderAssignment relations only when the card or receiving use expressly represents attribution
  ActualTransformationRefs?:
  WorkToTransformationOrEffectClaimRefs?:
  MeasurementRefs?:
  EffectClaimOrRelationRefs?:
  RefreshRef?:

@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:

Current questionUse
Generic development or evolution wording still hides the changed or represented subject, continuity or membership, posture, direction or value basis, or direct owner.Use E.10.DEV first; return to C.36 only if the recovered claim is cultural-population or discipline-facing cultural evolution.
A bounded entity changes under conditions.A.3.4 U.Transformation.
A temporal aspect, currentness window, rhythm, cadence, or authored temporal claim is current.C.27.TA, C.27, or A.3.3 according to the claim.
An engineering project manages an evolving archive, front, current pool, selected set, edition lineage, or family of variants.C.18, C.19, G.5, G.11, and E.18.1.
A collective-holon or discipline-facing method, Work, system-role kind or assignment, canon, memory, recognition, selection, mediation, style, tradition, or intervention relation is current.C.36.

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, and C.29 when that claim is current. Loose style metaphor remains term and bridge work through F.17, F.18, and F.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:

StyleTraditionTermBridgeTable@Context:
  SourceLabel: "contemporary"
  SourceContext: festival choreography lab
  RecoveredFPFValueOrRelation: method family plus work family plus canon episteme plus recognition regime
  ApplicablePatternRef: C.36, F.17, F.18, F.9, A.3.1, C.20
  AdmissibleUse: compare variants inside this festival context and state what is being changed
  BlockedUse: treat the word as one root style kind across all dance contexts
  CurrentnessCondition: refresh when the festival, judging, pedagogy, or platform mediation changes

The bridge row is not enough when the project is changing the style ecology. Then write the case card:

CulturalEvolutionCaseCard@Context:
  CaseRef: festival-contemporary-2026
  CaseScopeOrModelUseBoundary: festival choreography lab and its short-video circulation scope
  CollectiveHolonRefs: choreographer collective, dancers, teachers, judges, platform-mediated audience
  RoleWordRecoveryRefs: E.10.ROLE recovery for dancer, choreographer, teacher, judge, and viewer in this festival case
  DirectParticipationOrPositionRelationRefs: festival-performance, choreography-contribution, teaching, judging, and mediated-viewing relations when their domain predicates obtain; otherwise the corresponding row is missing-governor
  SystemRoleKindRefs: omitted — the familiar dance labels do not establish local kinds without criteria
  SystemRoleClassificationJudgmentRefs: omitted — the familiar dance labels establish no classification judgment
  SystemRoleAssignmentSpeciesRefs: omitted — this family-level card asserts no assignment species
  SystemRoleAssignmentOccurrenceRefs: omitted — this family-level card asserts no assignment occurrence or performed Work; any later Work claim first recovers each exact performer through A.13 and lets A.15.1 independently admit the Work, adding A.2.1/F.6 only when precise assignment-bound attribution is expressly consumed
  WorkFamilyRefs: performance, rehearsal, teaching, judging, remixing, platform publication
  MethodFamilyRefs: floorwork method family, improvisation method family, duet-lift method family
  CanonOrMemoryEpistemeRefs: festival archive, teaching syllabus, exemplar video set
  SelectionOrRecognitionRegimeRefs: jury recognition, peer copying, platform recommendation, class adoption
  MediationSystemOrArchitectureRefs: short-video recommendation System
  PublicationRefs: festival programme form and published-video form under E.24.PUB
  MeasurementOrVisibilityRelationRefs: jury scores, replay counts, class adoption counts
  VariantSetRefs: choreography variants and teaching variants from the lab archive
  CharacteristicSpaceRefs: musical timing, body vocabulary, risk, teachability, audience recognizability
  LevelOrScopeRefs: festival scene, teaching network, platform circulation scope
  StyleOrTraditionTermRows: "contemporary" bridge row above
  CurrentEvolutionaryQuestion: change recognition and teaching methods without collapsing the style label into one root kind
  ApplicablePatternRefs: C.36, C.18, C.19, G.5, F.17, F.18, F.9, A.3.1, G.11
  RefreshRefs: refresh when platform mediation, judging, canon, or teaching adoption changes

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

If the current question is...Use...
method, technique, algorithm, practice, or developmental-machinery wording as a way of doing workA.3.1, A.3.2, A.15, and C.23 as applicable
discipline-level composition and comparisonC.20
term durability, naming restoration, or bridges across contextsF.17, F.18, and F.9
archive, front, Q-front, descriptor, distance, retained exploration value, or stepping-stone valueC.18
current pool treatment, exploration or exploitation policy, graduation, narrowing, or sunsetC.19
selector-facing retained set, shortlist, ranked shortlist, specialist handoff, abstain, or escalationG.5
refresh, deprecation, edition, source currentness, lineage, or currentness reportingG.11
generated or discovered structure-bearing carrier, architecture candidate, selected structure, architecture description, or architecture structural viewC.35 for carrier admission before candidate use; C.32 for candidate synthesis; and C.30, C.30.AD, or C.30.ASV for the direct architecture, description, or view question
new level, new holon, MHT, whole reidentification, model-use or scope reframe, supervisor-subholon feedback, cross-scope frustration residual, or interlevel ethical conflictkeep the C.36 cultural-evolution result and use A.1, B.2, B.2.P, B.2.5, C.30.ILC, C.29, D.2, D.3, D.4, or the applicable holon, System, architecture, mathematical-lens, or ethics pattern
local choice among already available optionsC.11; use C.36 separately only when generation, transmission, recognition, selection, retention, or loss across a practice or population is also current
problem-to-work carry-throughE.18.1
dynamics, temporal adequacy, or mathematical-lens useA.3.3, C.27, and C.29

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.

LensLikely driftRepair
GovA case card, project choice, intervention proposal, or observed population trend is read as authorization, responsibility, acceptance, or policy.Keep each project decision and authority claim with its direct pattern; C.36 records only the cultural relations and intervention distinctions actually current.
ArchOne platform, archive, genre tree, lifecycle, or dashboard is treated as the cultural architecture.Recover the relevant Methods, Work, subjects, memory epistemes, mediation, recognition, selection, measurement, and refresh relations; use architecture patterns only for actual architecture claims.
Onto-EpistA familiar label, publication, model, score, or intervention card becomes the practice, population, variant, relation, performed Work, or effect.Recover the object and relation under the applicable pattern; keep descriptions and records distinct from the subjects and occurrences they describe.
PragEvery optional card field is filled, while the project still cannot say what changes or what it will observe next.Start with the one-sentence case and open only fields whose identities change proposal, Work, effect, comparison, or return.
DidSpecialist evolutionary language or formal relation lists hide the recognizable project situation.Use ordinary language first, then add the smallest exact terms and pattern references needed to block a real overread.

Conformance Checklist

CheckPassing observation
CC-C36-1 — Recognizable caseThe text names the practice, population, collective, or Discipline boundary; the variants; the cultural-evolution relation currently at issue; and the next action or stop.
CC-C36-2 — Small first resultA cold reader can use the one-sentence case or small case card before encountering the assurance expansion. Optional fields appear only when their identities change a later claim.
CC-C36-3 — Recovered objectsFamiliar words such as culture, style, tradition, practice, platform, regime, and technique do not stand in for several unseparated FPF objects or relations.
CC-C36-4 — Project choiceA project decision or authorization is recorded through its direct pattern and is not offered as evidence of transmission, recognition, selection, retention, loss, intervention performance, or effect.
CC-C36-5 — Proposal, Work, and effectA proposed intervention, planned Work, performed Work, actual transformation, Work-to-change relation, and measured effect remain separate. Every asserted Work occurrence has exact A.13-qualified performers and independent A.15.1 admission. Assignment and F.6 refs appear only when the card or receiving use expressly represents precise assignment-bound attribution.
CC-C36-6 — Population observationObserved spread, popularity, persistence, or loss identifies its population, period, measurement, and relation; it neither authorizes the project nor proves the intervention caused the observation.
CC-C36-7 — MediationA platform, recommender, archive, publication, or provider is named by its actual kind and relation. Mediation does not become selection, value, authority, or cultural control by label.
CC-C36-8 — Separate effect testThe intervention's expected effect, observed value, measurement relation, and effect claim are recoverable separately; observing a value does not manufacture the effect.
CC-C36-9 — Neighbor boundaryArchive/front, pool, selected-set, local-choice, publication, architecture, currentness, transformation, Work, and mathematical-model claims use their direct patterns when current.
CC-C36-10 — Source and refreshEvery adopted SoTA move retains its stated limit and currentness trigger; a source label or newer date alone does not establish a cultural relation.
CC-C36-11 — Possible developmentWhen the question is how the practice may develop, the answer keeps more than one serious hypothesis and names an observation that would distinguish them. It uses B.5 and B.5.2 for hypotheses and consequences, A.3.3 only for a state-space-and-transition-law claim, and C.28 only when the current use relies on a causal claim. It uses A.15.7 for a next action during ongoing Work and C.11 only for an already formed bounded choice; otherwise experiment or probe design stays with the applicable DPF or field Method.

Common Anti-Patterns and How to Avoid Them

Anti-patternWhy it failsRepair
Project choice means population selectionA bounded decision says what the project chose, not what a practice or population later recognized or retained.Record the choice with C.11 or the applicable decision pattern; gather separate C.36 evidence for cultural relations.
Performed intervention means successWork can occur without producing the intended transformation or effect.Keep performed Work, actual change, Work-to-change relation, measurement, and effect claim separate.
Observed spread authorizes the interventionPopularity or persistence supplies neither authority nor a retrospective project decision.State the observation and its limits; use the direct authority or decision pattern for any authorization claim.
One platform controls cultureA mediating System can change visibility, transmission, or selection conditions without becoming the culture or proving control.Identify the System, architecture, mediation relation, scope, and observed consequence separately.
Archive or front equals cultural selectionRetention in an engineering set is not automatically social recognition, population selection, use, or canon formation.Use C.18/C.19 for archive, front, and pool treatment and C.36 only for separately supported cultural relations.
Popularity score equals valueVisibility and feedback can amplify variants while measuring neither practitioner value nor effect.Name the measurement and proxy relation; use E.13 and the applicable value/evidence patterns when reliance is current.
Local label becomes a root kindStyle, school, tradition, technique, or regime can hide different objects and relations across cases.Use the term bridge and recover the current FPF value or relation before relying on the label.
Card as permission or proofA case or intervention card is a working episteme; it performs no Work and asserts no effect by itself.Use it only to keep exact claims together, then apply the direct pattern for each decision, Work, transformation, effect, or publication claim.

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 or source familyAdopted FPF moveRejected overreadField or boundary changed
Brinkmann et al., Machine Culture, arXiv:2311.11388; DOI 10.1038/s41562-023-01742-2.Treat intelligent systems as possible mediators or generators of cultural variation, transmission, and selection.AI agents, recommenders, platforms, or toolchains are only external aids.MediationSystemOrArchitectureRefs, recognition and selection regimes, transmission, memory, and canon refs stay visible in CulturalEvolutionCaseCard@Context.
Czaplicka, Baumann, and Rahwan, algorithmic mediation and cumulative culture, arXiv:2410.00780; DOI 10.1098/rsif.2024.0686.Recover platform or algorithmic mediation by identifying the mediating System or architecture, any local system-role classification or direct participation relation, the recognition or selection relation, the measurement or visibility relation, and the actual scope or model-use boundary.platform regime becomes a root ontology or a mere publication label.MediationSystemOrArchitectureRefs, RecognitionOrSelectionRegimeRefs, and ApplicablePatternRefs identify the needed rule before platform wording is used.
Yaman, Tian, and Lindstrom, semantic knowledge and cultural evolution, arXiv:2510.12837; DOI 10.1073/pnas.2530750123.Keep method families, work families, characteristic spaces, canon or memory epistemes, and recognition regimes explicit.Culture is shared vocabulary, random variation alone, or a genre tree.MethodFamilyRefs, WorkFamilyRefs, CanonOrMemoryEpistemeRefs, and CharacteristicSpaceRefs are not optional decoration when semantic knowledge is the live claim.
Tchernichovski et al., editing constraints in cultural evolution, arXiv:2502.16694.Treat editing constraints as constraints on variant sets, characteristic spaces, and effect measurement.Style engineering is unconstrained idea generation or one scalar taste score.VariantSetRefs, CharacteristicSpaceRefs, and measurement or refresh exits must be named when a style intervention targets constraints; any claim that constraints actually changed still cites its exact A.3.4 and Work-to-change basis.
Marjieh et al., cultural-evolution mechanisms in experimental social networks, arXiv:2502.12847.Keep topology, selection, reproduction, social-learning, and mediation relations recoverable.Cultural evolution is one isolated innovation channel.CollectiveHolonRefs, local-kind and separate classification refs, any assignment-species and assignment-occurrence refs, RecognitionOrSelectionRegimeRefs, and mediation refs are kept together in the case card.
Lee et al., melody and rhythm coevolution, arXiv:2605.05982.Allow several feature-specific characteristic spaces inside one style or tradition case.A style label proves one monolithic trajectory.CharacteristicSpaceRefs may carry several feature spaces before selected-set or bridge claims rely on the label.
Gautheron et al., popularity feedback in cultural markets, arXiv:2602.09997.Keep popularity feedback, visibility, recognition, selection, and measurement relations explicit.Popularity or platform metrics are neutral evidence of value.RecognitionOrSelectionRegimeRefs, measurement refs, and ApplicablePatternRefs identify whether to use C.36, C.18, G.5, G.11, or an evidence pattern.
Current QD and open-ended-engineering rows, including the 2026 Quality-Diversity survey DOI 10.1016/j.swevo.2025.102240.Keep archives, fronts, current pools, selected-set result declaration, evaluator relations, generalization pressure, and refresh distinct from the cultural-evolution case. When publication is current, also keep the source-backed face and source return distinct from the publication occurrence and audience availability.C.36 absorbs archive, front, pool, selected-set, publication, or refresh semantics.Use C.18 for archive and front relations, C.19 for current-pool treatment, G.5 for selected-set result declaration, G.11 for currentness and refresh, 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. Use C.36 only for the cultural-evolution case.

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:

  1. 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.
  2. Classification shortcut. An A.2.4 intended first evidence-use classification is treated as evidence sufficiency or permission.
  3. Provenance shortcut. A source path, current carrier, or authentic publication is treated as a positive RelianceDisposition or receiving result.
  4. Decision shortcut. A selected row is treated as choosing, authorizing, permitting, or passing a gate without the direct receiving pattern.
  5. Composition shortcut. Several rows are treated as a collection, structure, integrated view, world model, or graph merely because one receiver reads them together.

Forces

ForceTension
Useful foregrounding vs visible lossA representation helps by emphasizing some distinctions, but the same emphasis can hide uncertainty, conditions, or alternative readings.
Cross-kind comparison vs direct authorityCandidate results may be diagrams, plans, records, views, or mathematical objects, while each keeps a different identity and obtaining rule.
Cheap orientation vs bounded relianceReversible inspection may need only a direct result and limit; consequential use may require an exact A.10 path and disposition.
Co-use vs invented wholeSeveral candidates may be needed for one action without forming a collection, structure, composite view, or unified world account.
Stable source vs changing actionThe same candidate can be selected for one action and declined for another because the relied-on claim and tolerated loss differ.
Clear decision support vs borrowed authorityThe account must help a decision without becoming the choice, gate, permission, authorization, assurance, or domain result.

Solution

Use one action spine:

  1. name the receiving System and exact action or decision;
  2. recover each candidate and its direct subject result;
  3. separate the direct subject result, optional first-use classification, bounded reliance, receiving result, and auxiliary facts;
  4. state what the candidate exposes or preserves and what it withholds, loses, transforms, or leaves uncertain;
  5. mark the row select, decline, or unresolved for the named use and give its return trigger;
  6. 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:

<receiving System> must <take this exact action or make this exact decision>.

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.

LayerWhat must be recoverableWhat it does not establish
Direct subject resultThe candidate's independently governed kind or result, its subject, and any exact representation, conformance, correspondence, transition, structure, collection, mathematical, plan, Work, or domain relation on which the selected claim depends.Intended evidence use, reliance, receiving decision, permission, gate passage, or authorization.
Optional A.2.4 first-use classificationWhen the candidate episteme is being used as evidence or as a status carrier, the exact episteme, target claim or status, scope, polarity or value, window, and intended use.Provenance, sufficiency, RelianceDisposition, assurance, permission, or receiving action.
A.10 bounded reliance, when materialThe exact relied-on claim, source and provenance path, premise, reference, decision-use, operation-argument, or other direct use relation, time/currentness boundary, bounded evidence use, unsupported attempted use, challenge when current, one current RelianceDisposition, and its reopen or stop condition.Claim truth, selector outcome, gate result, approval, permission, assurance, or Work authorization.
Receiving resultThe exact ChoiceResult, gate result, permission, authorization, acceptance, or domain result supplied by the pattern that defines or tests the receiving action.Candidate identity or evidence merely by mentioning the row.
Auxiliary factsLens, publication, form, carrier, repair, provenance, source, or rendering facts needed to interpret or recover the row.Any missing positive subject result, reliance, or receiving result.

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:

DispositionUse
selectThe required direct subject result is positive, every required reliance condition supports the exact bounded use, and the receiving result permits this candidate's stated contribution. Narrow the selected claim when A.10 says degrade; do not invent a second disposition vocabulary.
declineA required direct result is negative, the receiving result excludes the candidate, or the candidate's loss makes the attempted use inadmissible. State the retained weaker use, if any.
unresolvedA required identity, relation, currentness fact, reliance path, disposition, or receiving result is missing or ambiguous. Name what would reopen the row.

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:

Use-bounded representation-selection account:
  Receiving System and exact action or decision:
  Receiving-result governor and result:
  Candidate rows:
    - Candidate and direct subject result:
      Exact claim used:
      Intended first evidence use, if current:
      A.10 path, direct use relation, and RelianceDisposition, if current:
      Exposed or preserved:
      Withheld, lost, transformed, or uncertain:
      Disposition: select | decline | unresolved
      Return or reconsideration trigger:
  Action supported, declined, or blocked under the combined limits:

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:

  1. If an owning domain result already carries this same receiving use, embed the complete row claims and action boundary in that result.
  2. Otherwise retain the complete account as one ordinary C.2.1 episteme.
  3. 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

CaseC.37 disposition
One direct domain Method already selects one representation–operation configuration for the same one use and returns its limits, as RHY.5 does for rhythmic-representation choice.Use that Method and result; do not invoke C.37 for a duplicate account.
A candidate is called a view but EpistemeViewpointConformanceRelation(E,P) fails or cannot be evaluated.Decline it for the view-dependent use or mark that row unresolved. C.37 cannot grant U.View membership. Another independently positive direct basis may support a different row and claim.
A candidate is a mathematical graph or other mathematical object.First identify the object and obtaining subject relations under their direct patterns; then use C.29 for the explicit lens, mapping, preserved and lost structure, admitted use, and stop. C.37 neither admits the object nor makes the mapping obtain.
A candidate is an ordinary non-graph diagram.Identify its episteme and subject. Require an exact positive conformance, representation, correspondence, or domain result for the selected claim. Add A.10 when evidence is relied on. Publication, carrier, provenance, or C.2.P.DR repair cannot supply the missing basis or receiving result.
Several project, process, or case viewpoints concern one Work.Co-record them only when each can change the same exact action about that independently identified Work. A viewpoint for another action starts another account.

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.

CandidateDirect result, reliance, and receiving resultExposed and withheldDisposition and return
Workflow diagram in MethodDescription-MD5, edition 5A.3.2 identifies the episteme as a MethodDescription about Method-M2. A.2.4 may classify its intended evidence use. A.10 path P-MD5 carries the premise “edition 5 states the proposed MC7 action order,” its source/currentness window, direct decision-use relation, and RelianceDisposition=pass. The C.11 result alone selects or declines MC7.Exposes proposed sequence and handoff; withholds actual effort, achieved result, and future performer availability.select for proposed-way claims only; return if the edition, intended Method, path, or reliance window changes.
WorkPlan-WP4 trial itemA.15.2 identifies the schedule-of-intent episteme and its planned performer, interval, and capability conditions. A.2.4 may classify the intended use. A.10 path P-WP4 carries the premise “WP4 currently provides the named trial slot and conditions,” source/currentness, direct decision-use relation, and RelianceDisposition=pass. The C.11 result alone selects or declines MC7.Exposes a bounded trial slot and intended conditions; withholds actual occurrence, performance, and result.select for planned-trial feasibility only; return if the plan, performer, interval, capability condition, path, or disposition changes.
WorkRecord-W19 about actual Work-W19A.15.1 admits the dated Work independently; C.2.1 identifies the record episteme. A.2.4 may classify its intended use. A.10 path P-W19 carries the premise “W19 reports the stated rework and effort under the named earlier conditions,” its provenance and decision-use relation, and RelianceDisposition=degrade to that comparability-limited premise. The C.11 result alone selects or declines MC7.Exposes observed breakdown and effort under the earlier edition and conditions; withholds proof that MC7 fixes the breakdown or that WP4 will reproduce W19.select only for the narrowed comparability-qualified premise; return if the observed conditions, path, currentness, disposition, or relevance to MC7 changes.

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)

LensLikely driftRepair
OntologicalRepeated use of diagrams, tables, and records motivates a universal representation kind or relation.Keep each candidate under its direct kind and relation; C.37 governs only the one-use selection move.
EpistemicSelected means true, sufficient, or assured.State the exact claim, A.10 disposition when material, unsupported use, and any separately current B.3 assurance claim.
DecisionThe account itself appears to choose, permit, authorize, or pass a gate.Name the direct receiving-result governor and its actual result.
StructuralCo-used rows appear to form one integrated whole.Treat co-use as a shared action key only; open collection, structure, construction, or coherence claims separately.
DidacticA large form replaces the recognizable action.Start with one receiver, one action, and one row; add a field only when it changes selection or return.

Conformance Checklist

CheckPassing condition
CC-C37.1 One receiving useEvery row names the same receiving System and exact action or decision. Another action starts another account.
CC-C37.2 Direct exit testedThe account is absent when one direct pattern already supplies the complete one-result/one-use selection and limits.
CC-C37.3 Direct subject resultEach row identifies the candidate, subject, direct governor, and every positive relation required by the selected claim.
CC-C37.4 A.2.4 boundedFirst evidence-use or status-use classification is optional and never substitutes for provenance, reliance, or action authority.
CC-C37.5 A.10 boundedWhen evidence reliance is material, the exact claim, path, direct use relation, time/currentness boundary, bounded evidence use, unsupported attempted use, challenge when current, current RelianceDisposition, and reopen or stop condition are recoverable.
CC-C37.6 Receiving result separateThe direct choice, gate, permission, authorization, acceptance, or domain pattern supplies the action result.
CC-C37.7 Exposure and lossEach selected or declined claim states what is exposed or preserved and what is withheld, lost, transformed, or uncertain.
CC-C37.8 Honest dispositionEach row is select, decline, or unresolved; degrade narrows the selected claim rather than creating another row vocabulary.
CC-C37.9 Return visibleEvery row names the source or direct pattern and the condition that reopens selection.
CC-C37.10 Co-use boundedJoint use means only reliance by the same receiver for the same action; no collection, structure, view family, graph, or integrated world account is inferred.
CC-C37.11 One realizationThe complete claim group is embedded in an owning same-use result when one exists; otherwise it is one ordinary C.2.1 episteme, never both.
CC-C37.12 Assurance progressiveB.3 is opened only for an actual named assurance claim; reversible inspection carries no mandatory assurance burden.
CC-C37.13 No universal ontologyNo U.Representation, universal RepresentationOf, fixed representation taxonomy, master mediation route, or public account kind is introduced.

Common Anti-Patterns and How to Avoid Them

Anti-patternFailureRepair
Best representation overallA candidate is ranked without a receiver, action, exact claim, or tolerated loss.Start a one-use account and compare only claims that can change that action.
Evidence-use classification as warrantA.2.4 is treated as a positive reliance or authorization result.Add A.10 only when reliance is material and keep the direct receiving result separate.
Provenance as decisionA current source or authentic carrier is treated as selecting or permitting the action.Use provenance only inside the exact bounded path; require the direct choice, gate, permission, or domain result.
Publication as representation authorityA published diagram is accepted because it is available and readable.Recover the direct subject result, any exact conformance or correspondence, and the relied-on claim; E.24.PUB supplies availability only.
Co-use as compositionSeveral rows become a collection, structure, integrated view, or graph by adjacency.Keep independent rows; open C.13, A.22, E.17.0, C.29, or a domain integration pattern only for an additional named claim.
Duplicate accountAn owning domain result and a standalone C.37 episteme repeat the same one-use claims.Embed once when the owner exists; otherwise use one standalone ordinary episteme.
Cross-use carryoverA row selected for one decision is silently reused for tailoring, learning, maintenance, or another action.Start another account and re-evaluate direct result, loss, path, disposition, and receiving result.
Diagram-first ontologyA graph, table, card, or route shape decides what exists or what happened.Recover the direct object and relation first; then state the exact representation use or none.

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)

Source line and statusAdopted moveRejected overread
Dutilh Novaes, Formal Languages in Logic (2012), and Krämer, “Why notational iconicity is a form of operational iconicity” (2017), conceptual and diagrammatic-reasoning lineage already used by C.2.1Representation and notation can change what users can inspect, compare, calculate, or infer; each row therefore states exposure, loss, and bounded use.Reasoning affordance does not identify the represented subject, make a direct relation obtain, or authorize the receiving action.
W3C PROV-O Recommendation, 2013, stable provenance lineage used by A.10 and C.2.1Preserve exact source, entity, activity, and derivation distinctions when they are material to bounded reliance.Provenance alone is not truth, currentness, permission, assurance, decision, or evidence of actual use.
Decision Theory, Stanford Encyclopedia of Philosophy, stable baseline used by C.11Fix the chooser, option or action question, comparison basis, and explicit receiving result rather than ending with an informed-looking inventory.C.37 does not replace C.11 or turn every representation-selection question into one universal decision calculus.

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.1 for 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.4 for optional first evidence-use or status-use classification; A.10 for evidence-provenance and bounded reliance; and the direct choice, gate, permission, authorization, acceptance, or domain pattern for the receiving result.
  • Coordinates with: E.17.0 for view conformance, C.29 for mathematical-lens use, E.24.PUB for publication, A.6.3.RT for representation transitions, A.22 for selected structure, C.13 for construction and collection boundaries, and C.2.P.DR for 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

ForceTension
Familiar labels versus comparable contentsShort labels help search, but they hide unlike relations and burdens.
Completeness versus proportionalityEvery way must be complete enough for this decision without becoming a universal arrangement description.
Shared basis versus genuine differenceRows need the same result and parity questions while preserving the differences that make them real alternatives.
Possible future versus current factA useful candidate describes what could be arranged without asserting that capability, authority, Work, provision, or acceptance already obtains.
Comparability versus forced total orderSome ways remain incomparable, gated, or tied; one scalar can erase protected conditions and decision-reversing uncertainty.
Common Method versus domain ownershipResult-first formation transfers across domains, while specialist criteria, architecture, contracting, realization, and acceptance remain local.
Candidate formation versus choiceA well-formed finite set is necessary for C.11, but constructing the set does not choose or borrow the chooser's authority.

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

  1. 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.
  2. Recover available inputs and exact gaps. Use already-available subject and specialist results only where they fit the same question. Apply A.15.9 only 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.
  3. 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.
  4. 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.
  5. 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.CPM and A.19.SelectorMechanism only when evidence gates, partial orders, incomparability, abstention, or set-valued retention matter. Do not hide protected conditions inside an unexplained score.
  6. 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 apply C.11 for local choice. Its result may choose one way or a retained tie-set, reject the current set, probe again, or reroute. C.38 does not choose by implication and does not gain the chooser's authority.
  7. 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:

Current decision questionWhat to make visible
Same resultWhat exact result becomes available, to whom, under which acceptance condition?
How it could happenWhich proposed or available Agents, Work, Methods, Systems, values, and direct relations matter?
Fit and joiningWhich interfaces, configuration, integration, and enabling branches can reverse the choice?
RelianceWhich evidence, uncertainty, assurance, authority, and protected conditions matter?
ContinuationWhich support, maintenance, change, custody, recovery, and exit conditions remain?
ConsequencesWhich resources, capabilities, opportunity costs, and affected Systems change?
Premise statusWhat is supported now, merely proposed, or still unknown?

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:

  1. If a domain result already carries the complete same-use comparison and declares this specialization, keep it there rather than producing a second account.
  2. Otherwise retain one ordinary C.2.1 episteme about the one result-obtaining comparison, with a truthful EntityOfConcern and effective reference scheme.
  3. If a direct domain Method already returns the complete useful comparison more cheaply, use that Method and do not add a C.38 account.

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

Source labelRecover before comparisonDo not infer
buildSought result, proposed Work, Methods, performers, Systems, enabling branches, evidence, support, and exit needed by this decision.Internal capability, authorization, Work, or success.
buy or leaseExact proposed provision, transfer, access, custody, ownership, support, and acceptance relations inside the whole way.Purchase is the whole way or the result is available.
provider or outsourceProposed provider Work, supplied result, interfaces, evidence, responsibility, support, change, and exit boundaries.Provider label establishes capability, authority, service, delivery, or acceptance.
internalWhich Systems may perform which proposed Work under which support and capability premises.Employment or organizational location is an arrangement kind or capability proof.
reuseThe already-available System or result, fit, permitted use, adaptation, integration, evidence, support, and recovery.Prior existence proves present suitability or availability.
AI or automationThe Agent or tool's proposed contribution inside each way, plus capability, access, evidence, authority, stop, and recovery where needed.A performer species is a whole way or receives decision authority.
arrangement or optionThe complete-enough claim bundle for this one comparison and its premise modality.A new universal kind, selected Structure, architecture, or obtaining world-side relation.

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:

  1. One governed result, receiver, use, situation or configuration, horizon, acceptance basis, deciding System, and authority boundary are explicit.
  2. At least two materially different complete-enough ways seek that same result. Duplicate labels merge and material differences under one label split.
  3. 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.
  4. The same decision-changing parity questions are applied to every way; an omitted group is justified by irrelevance to this choice.
  5. A decision-reversing unknown remains a gap or probe. Protected conditions are not hidden inside one unexplained scalar.
  6. A.19.CPM or A.19.SelectorMechanism is used only when its evidence-gating, incomparability, abstention, or set-return contribution is actually needed.
  7. Only complete-enough whole ways enter the finite OptionSet; C.11 alone makes the local choice and emits the ChoiceResult.
  8. The truthful carrier rule prevents a duplicate episteme when an owning domain result already carries the complete comparison.
  9. A retained way names its first unsupported realization branch, but no realization or later Work is claimed by the comparison.
  10. 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.38 instead of moving to C.18 and C.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

ConsequencePractical effect
Truthful alternativesCandidate rows become whole ways to obtain the same result rather than a mix of labels and objects.
Earlier burden visibilityIntegration, evidence, support, capability, custody, consequence, recovery, and exit can change the choice before commitment.
Preserved modalityPlans and candidate rows do not fabricate current world-side relations.
Better choice inputC.11 receives a finite complete-enough OptionSet and visible gaps instead of being asked to repair its own candidates.
Domain autonomySubject Methods keep architecture, provision, contracting, acceptance, realization, and assurance.
Additional preparation costThe team must resolve familiar labels and ask comparable questions before scoring or choosing.
Bounded completenessThe parity basis is sufficient only for this decision and must reopen when a decision-changing premise changes.

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.10 for evidence and bounded reliance on actual premises; A.19.CPM and A.19.SelectorMechanism only for comparison mechanisms that are actually needed; and C.2.1 when a standalone comparison episteme must persist.
  • Hands to: C.11 only after a finite complete-enough OptionSet exists. C.11 owns choose, reject, probe-again, and reroute results.
  • Coordinates with: C.18 for open-ended generation or reframing; C.19 for pool policy; C.32 for architecture-candidate synthesis; A.22 and C.30 only 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.9 only for one missing or unqualified bounded result from another practice inside a way. Stay in C.38 when 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: CulturalEvolutionWordingUsePrecisionRestoration Plain-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, and G.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:

CulturalEvolutionWordingRecoveryLine:
  triggerSpan:
  wordingUse:
  sourceRef?:
  claimScope?:
  modelUseBoundary?:
  recoveredObjects?:
  recoveredRelations?:
  recoveredClaim:
  applicablePatternRefs:
  retainedSourceLabelUse?:
  admissibleUse?:
  blockedUse?:
  nextUseOrStop:

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

ForceTension
Local language usefulnessCommunities need familiar words such as style, tradition, scene, platform, canon, and technique.
FPF composabilityDownstream work needs the applicable Method, Work, discipline, episteme, bridge, archive, pool, selected-set, architecture, measurement, choice, or refresh rule without turning that rule into package-routing prose.
Source fidelitySome labels should remain visible because they are source terms or project terms.
Ontological economyThe same labels must not mint root U-kinds or local ontologies.
Precision vs readable actionThe repair must preserve distinctions that change truth or action without making the reader complete an ontological form before doing the work.
C.36 focusC.36 must remain a positive cultural-evolution pattern, not a wording-repair catalogue.

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.

  1. 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.

  2. 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.

  3. 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.
  4. 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.

  5. 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-governor instead of inventing a System-plus-relation construction. Do not introduce a holon-in-role value.

  6. 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.

  7. 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.

  8. 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@Context only 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.

Trigger useRecover firstApplicable patterns after recovery
generic development, evolution, evolved, progress, growth, adaptation, or lineagechanged or represented subject; needed continuity or membership; posture; any direction or value basis; direct owner; cultural or non-cultural boundaryE.10.DEV first; then C.36 or C.36.P only for a recovered cultural-evolution case, and E.10.MOVE only for a remaining independent trajectory or path ambiguity
style, tradition, genre, scene, school, or cultural lineageterm row or actual bridge; Method or Work family; canon or memory episteme; recognition relation; selected set; publication labelF.17, F.18, F.9, C.36, A.3.1, C.20, C.18, G.5, E.17, or E.24.PUB
practice, technique, developmental machineryMethod or MethodDescription; relations among Methods or a selected Structure of them; WorkPlan or dated Work; direct participation; local system-role kind or classification; assignment species or occurrence; relation between system-role kinds; bounded model-use structure or one of its direct relations; discipline position; evidence relation; quote-only wordingA.3.1, A.3.2, A.15.1, A.15.2, E.10.ROLE, A.2, A.2.1, A.2.7, A.1.1, A.10, C.20, or C.23
platform, platform regime, measurement regimemediating System or architecture; recognition, selection, measurement, visibility, publication, source-currentness, or direct model-use relation; bounded model-use structure; claim scope; ordinary project labelA.1, A.1.1, C.30, C.16, A.19, E.17, E.24.PUB, G.11, or C.36
MHT, level, boundary, feedback down, model-use or scope reframe, frustration, interlevel conflictnew holon or level; whole reidentification; System boundary; relation crossing a holon boundary; supervisor-subholon feedback; bounded model use or claim scope; cross-scope residual; mathematical-lens use; interlevel ethical conflictA.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
attractor, basin, stable styleloose style term or an actual dynamics, temporal, or mathematical-lens claimF.17, F.18, F.9, A.3.3, C.27, C.29, or C.36
archive, front, Q-front, current pool, portfolio, retained setarchive or front relation; pool-policy result; selected-set result declaration; publication relation; refresh relationC.18, C.19, G.5, E.17, E.24.PUB, G.11, or E.18.1

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:

CulturalEvolutionWordingRecoveryLine:
  triggerSpan: "platform changed the style"
  wordingUse: “platform” names the recommender and its visibility infrastructure
  claimScope: this circulation and teaching-cycle comparison
  recoveredObjects: short-video recommendation System; dance-variant set
  recoveredRelations: recommendation mediation; visibility; recognition; selection
  recoveredClaim: these relations changed which variants were copied and retained
  applicablePatternRefs: A.1, C.36, F.17, F.18
  retainedSourceLabelUse: keep "platform" as the source label for the recommender and visibility infrastructure
  admissibleUse: discuss how visibility and recognition changed retained dance variants
  blockedUse: treat platform as a root cultural kind or style as one global kind
  nextUseOrStop: use C.36 for the case; use C.18 or G.11 only if archive or refresh is next

"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)