#Working-Model Relations & Grounding (CT2R-LOG)

B.3.5 · Stable · Pattern · Part B - Trans-disciplinary Reasoning Cluster

#About this pattern

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

#How to use this pattern

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

Status: Stable Type: Pattern

At a glance. Use B.3.5 when a human-facing Working-Model relation such as ut:ComponentOf, ut:MemberOf, ut:PortionOf, or ut:AspectOf needs an assurance grounding relation without exposing constructive machinery as the public vocabulary.

Use this when. Use this pattern when a structural edge must remain readable to engineers and managers while its publication claim also carries an author-declared validationMode and a tv:groundedBy link to a current C.2.1 construction-trace episteme. The trace reports independently grounded construction facts for inspection; it creates neither the relation occurrence nor the identity of the whole.

What goes wrong if missed. The readable relation layer and the constructive proof layer collapse into each other: either authors lose usable relation names, or reviewers cannot reconstruct why a structural edge should be trusted.

What this buys. The alias-plus-grounding split: Working-Model relations stay canonical for communication, while CT2R-LOG carries the grounding channel and validation stance that E.24.UK can cite for structural U-kind admission.

Not this pattern when. Not this pattern when the current question is how to construct the trace (C.13), which mereology relation kind is intended (A.14), whether a new holon exists (B.2), or whether a candidate name deserves durable U-kindhood (E.24.UK).

One‑line summary. CT2R-LOG treats the everyday Working-Model relations— ut:ComponentOf, ut:MemberOf, ut:PortionOf, ut:AspectOf —as the public relation layer for structure, while linking each published structural claim to a construction-trace episteme and a declared tv:validationMode. Authors keep using a short list of relations; reviewers can inspect the direct facts, construction rule, and identity conditions reported by the trace without treating that account as their cause.

Provide a single, human-facing family of Working-Model relations as the public relation layer, with explicit hooks for (G) grounding and (R) reliability, without exposing constructor jargon or overloading day-to-day authors.

#Keywords

• grounding
• constructive trace
• working model
• assurance layer
• CT2R
• Compose-CAL.

#Relations

#Content

#Intent

Provide a single, human-facing family of Working-Model relations as the public relation layer, with explicit hooks for (G) grounding and (R) reliability, without exposing constructor jargon or overloading day-to-day authors.

What you get (manager/engineer view). The same relations you already know (e.g., ComponentOf) remain the public relation vocabulary.

What changes (auditor/ontologist view).

• Each published edge carries two additional commitments:

  1. tv:groundedBy → points to a reconstructible trace (e.g., Γ_m.sum) whenever the edge is structural.
  2. validationMode ∈ {axiomatic, inferential, postulate} → declares how the author justifies the assertion.

This is the alias‑plus‑grounding split: Compose‑CAL builds the trace; CT2R‑LOG declares the alias pattern and links it; Lang‑CHR supplies the labels.

#Problem Frame

B.3.5 exists where a readable Working-Model relation must remain usable by practitioners while assurance readers still need a grounding relation and declared validation stance. The EntityOfConcern is not a notation, trace file, or tool output. It is the relation-use discipline that keeps the public relation layer and assurance grounding layer distinct.

#Problem

Declared sub-relations of ut:PartOf (e.g., ComponentOf, MemberOf) are easy to use but not self-justifying: their declaration alone does not show which exact participants and direct relation occurrences obtain, which construction rule applies, or which identity or reidentification rule governs the whole. Conversely, exposing construction traces everywhere makes the graph unreadable to non-specialists.

We need: a stable public relation layer for relations and a mandatory, reconstructible grounding channel—plus a visible validation intent that downstream assurance can reason about.

#Forces

• Two audiences, one dial. Project managers want one relation family and stable views; assurance readers want an inspectable construction account with explicit direct facts and identity conditions.
• Parsimony constraint. The Kernel stays minimal; construction is outside the Kernel.
• Unification inside FPF. We already unify external vocabularies; the same discipline is applied internally so patterns that publish structural claims can reuse one three-form construction-account discipline and one readable relation façade without making that account a second ontology.

#Solution (thumbnail)

CT2R‑LOG introduces a two‑link discipline around each canonical edge:

1. Alias link (concept‑level). Working-Model relations (e.g., ut:ComponentOf) are the public names for their exact direct relation principles. tv:AliasOf may point from the public relation kind to that principle for comparison and reuse; the alias defines neither an occurrence nor a whole.

2. Grounding link (evidence‑level). Each edge instance carries tv:groundedBy:

   • MANDATORY for all published structural edges (sub-properties of ut:StructPartOf): the target is one current C.2.1 construction-trace episteme in the sum, set, or slice form. It names the exact participants, direct relation occurrences, applicable construction rule, and identity or reidentification conditions already grounded under their direct patterns. Set validationMode=axiomatic; postulate SHALL NOT be used for structural edges. Neither the link nor the mode makes those facts obtain.
   • Optional for epistemic edges (e.g., ConstituentOf, RepresentationOf): if no Γ_m trace is appropriate, attach an evidence object whose admissibility is governed by the declared validationMode ∈ {inferential, postulate} (assurance rules).

3. Validation flag (author intent). Every declared edge or aggregation rule carries tv:validationMode with one of:

   • postulate — pragmatic working claim backed by observations;
   • inferential — reasoned consequence (proof outline);
   • axiomatic — the author declares that one inspectable construction account is the assurance basis for the assertion. This is an assurance posture, not a species of world-side relation and not an identity or timelessness guarantee.

F–G–R alignment. F (the published relation claim): :PumpA ut:ComponentOf :Skid12. G (its inspectable grounding account): the assertion links to :trace_Γm_sum_456, a C.2.1 episteme about the exact direct construction facts. R (the author's declared assurance posture): tv:validationMode=axiomatic → one input to B.3.3's AssuranceLevel assessment; it does not alter F.

#Structural CT2R Typing-Grounding Unfolding Structure Block

When a constructive trace, working-model relation, and target kind or logical representation must be carried together across contexts, use this block or cite an equivalent A.22.CGUS specialization. The block is useful when the reader must see the passage from constructional material to a typed or logical claim without treating a readable relation label as proof.

StructuralCT2RTypingGroundingUnfoldingStructureBlock:
  unfoldingStructureRef: current StructuralCT2RTypingGroundingUnfoldingStructure record
  workingModelOrConstructiveRepresentationRef:
  targetKindOrLogicalRepresentationRef:
  bridgeRef?:
  constructiveTraceRef?:
  preservedStructure:
  lostOrCollapsedStructure:
  CL_or_CLk:
  admissibleReuse:
  blockedSubstitution:
  evidenceOrProofLinkageRef?:

unfoldingStructureRef names the current local structure record. StructuralCT2RTypingGroundingUnfoldingStructure is a local [A.22.CGUS](/generated/patterns/A.22.CGUS) U.Structure specialization whose block is governed by B.3.5 only for structural construction-to-typed/logical projection; the A.22-level relation to that narrower specialization, when needed, is specializedStructureRef? on the generic CGUS record. It is not a root U-kind, proof, empirical evidence, work plan, decision, or general ontology-return structure. [C.13](/generated/patterns/C.13) contributes constructive-trace loci; [C.3](/generated/patterns/C.3) contributes kind intent, extent, subkind, and bridge loci; neither creates separate authority for this block.

When an inadequate working account requires a general diagnostic return to the exact subject construction, use [A.7.1](/generated/patterns/A.7.1). That return may stop at a direct relation, role assignment, state/capability, work occurrence, holon recognition, or another subject owner without opening this structural CT2R specialization.

workingModelOrConstructiveRepresentationRef names the relation, trace, model, or representation being carried. targetKindOrLogicalRepresentationRef names the typed or logical target. bridgeRef and CL_or_CLk are mandatory when cross-context or kind-level movement is current. preservedStructure and lostOrCollapsedStructure state what survives the passage and what the published relation no longer carries. Evidence linkage remains with B.3 evidence and assurance governing patterns; proof linkage remains with the proof or mathematical governing pattern that is current. The unfolding block only makes the structure of the passage inspectable.

#Vocabulary & notation (normative)

• Working-Model relations (front‑stage). ut:ComponentOf, ut:PortionOf, ut:AspectOf are publication-grade sub-properties of ut:StructPartOf (structural); ut:MemberOf is a sub-property of ut:EpiPartOf (epistemic).

• Alias principle (lexical). tv:AliasOf links a public relation type to the exact direct relation principle whose reading it carries (for example, ComponentOf points to the direct structural-component principle). The alias supports comparison; it neither defines an occurrence nor says that a sum expression produced the relation.

• Grounding (per‑edge). tv:groundedBy on a published structural relation assertion MUST point to one current C.2.1 construction-trace episteme in the sum, set, or slice form (set validationMode=axiomatic). For epistemic assertions it MAY point to an evidence object or a logical proof under validationMode ∈ {inferential, postulate}. The target supports replay of the assertion's basis; it creates neither the direct relation occurrence nor whole identity.

• Trace family. Γ_m.sum, Γ_m.set, and Γ_m.slice are the only C.13 narrative forms used for structural grounding accounts here. Their claim content reports assembly, collection, or aspect facts already governed elsewhere; no temporal or workflow form is added.

• Validation flag. tv:validationMode ∈ {postulate, inferential, axiomatic} is required on every declared edge or aggregation rule; for structural edges postulate is disallowed.

#Archetypal Grounding - Running example

Story. A refinery team publishes :PumpA ut:ComponentOf :Skid12.

• Publication — Working-Model relation layer. They mint one edge with the Working-Model relation ComponentOf and declare the published edge's U.Formality (typically F≈F3, controlled narrative). Only the Working-Model relation is visible to readers.

• Constructive grounding (Γₘ). In the background, the published assertion links to :trace_Γₘ_sum_456, a C.2.1 episteme that names the exact pump and skid, the direct fastening, coupling, enclosure, terminal, flange, and seal occurrences that obtain, the applicable skid assembly rule, and the skid reidentification rule. An auditor replays that account to inspect the assertion's basis. The same listed parts under a different assembly can form another whole, while a permitted pump replacement can preserve Skid12; the direct relations and reidentification rule, not the trace or input list, decide.

• Assurance stance & R-lane. Because the assertion is linked to an inspectable construction account, authors set tv:validationMode=axiomatic. This records their assurance posture; it does not strengthen the direct relation, fix identity, or make either timeless. B.3.3 reads the flag together with the actual grounding, warrants, evidence, and their currentness to assess the appropriate R lane. F, G, and R remain orthogonal.

• Contrast (epistemic). When the same team asserts :MassFlowRepresentation RepresentationOf :FlowModel, they declare validationMode=postulate and attach a calibration dataset (Empirical Validation) instead of a Γₘ trace. The edge remains publishable, but reviewers record a lower-confidence stance, and B.3.4’s evidence ageing policy will decay its trust over time.

Result: one visible relation for engineers, two assurance references for reviewers.

#Author Standard (at a glance)

When you add or import a relation edge:

1. Pick a Working‑Model relation (ComponentOf/MemberOf/…); avoid raw ut:PartOf unless you are drafting meta‑level axioms.

2. Attach tv:groundedBy:

   • Structural? → must be a Γ_m trace ID.
   • Epistemic? → Γ_m trace or evidence object.

3. Declare tv:validationMode (postulate / inferential / axiomatic).

What managers see: nothing new in the graph picture. What auditors get: a reliable trail from every published edge back to a principled constructor or an evidence pack.

#Compatibility & cross‑references

• B.3.2 (LOG‑use). CT2R‑LOG supplies the places to hang proofs/evidence that B.3.2 formalizes.
• B.3.3 (Assurance levels). validationMode + presence/quality of tv:groundedBy are the inputs to compute AssuranceLevel (L0–L2).
• B.3.4 (Evidence ageing and currentness). A relation assertion, its construction-trace episteme, and the warrants or evidence used for it retain their own editions and currentness. validationMode=axiomatic does not freeze a trace or make described world-side facts timeless; changed participants, relations, rules, or identity conditions require direct reinspection.

#Rule‑set — CT2R‑LOG (conceptual, human‑first)

Intent (one line). Make Working-Model relations the canonical relation vocabulary for authors, while providing a clean, purpose-selected bridge to assurance through aliasing and grounding semantics; the bridge is required for published structural assertions under this pattern.

#Vocabulary & Roles (what the words mean in this pattern)

• Working-Model relation. A human-oriented statement an engineer would naturally write, using public relation kinds such as ut:ComponentOf, ut:PortionOf, ut:AspectOf, ut:MemberOf. This is the canonical public relation layer for structure for readers and reviewers in Part B. (Didactic primacy governs this choice.)

• Assurance Layer. Three complementary assurance modes an author MAY attach:

  • Constructive grounding: an inspectable account in one of the three C.13 forms (Γ_m.sum | Γ_m.set | Γ_m.slice). It names independently grounded participants, direct relation occurrences, the applicable construction rule, and identity or reidentification conditions. No formal notation is required, and the account does not create the relation it reports.
  • Logical grounding: a reasoned chain (think KD‑CAL style arguments) that shows why the relation follows from stated premises.
  • Mapping grounding: a relation-label alignment that shows the domain label truly denotes the intended Working-Model relation (Kind-CAL / Lang-CHR stance). These three assurance modes are complementary, not exclusive.

• Empirical Validation. How a published relation meets reality (observations, calibration scenarios). It lives beside, not inside, the relation. (See B.3 family.)

• Grounding vocabulary (tv:).

  • tv:AliasOf — declares that a Working‑Model relation is the canonical projection of a more general pattern (its “principle of use”).
  • tv:groundedBy — points to the author's grounding account (Constructive, Logical, or Mapping, as applicable). When a construction trace is recorded, it is a C.2.1 episteme with its own edition and currentness. The tv: namespace is part of the Core conceptual lexicon; it is notation‑agnostic and tool‑agnostic.

• tv:validationMode ∈ {postulate, inferential, axiomatic}. A declaration by the author of the confidence stance for a relation instance: postulate — a pragmatic working claim; inferential — a reasoned consequence; axiomatic — the author declares that a constructive account is the assurance basis for this assertion. The mode does not classify the world-side relation and guarantees neither identity nor timelessness.

Authoring note. This pattern defines meanings, not formats. The words above SHALL be used consistently and without reference to any specific notations or execution environments (Guard‑Rails: Notational Independence).

#Normative rules (MUST/SHALL clauses for thinking‑and‑writing)

S‑1 (Working-Model first). Authors SHALL publish structural claims in the Working-Model form (ut:*Of relations). This is the canonical relation vocabulary for human readers and cross-disciplinary teams. Assurance accounts remain below that public layer; this pattern separately requires a trace link for published structural assertions.

S‑2 (Alias declaration). If a Working‑Model relation follows a known general principle, the author SHOULD declare tv:AliasOf <Principle>, thereby making the intended use‑pattern explicit for reviewers and future readers. (This improves comparability without introducing extra formality.)

S‑3 (Grounding by mode). For every relation instance the author MUST set validationMode and follow the corresponding grounding stance:

• S‑3.a postulate. The author MAY omit Γ_m grounding; the relation stands as a pragmatic working claim within a stated scope. The author SHOULD supply brief empirical cues (where the claim tends to hold) to ease later validation. (Empirical Validation is tracked in B.3.)

• S‑3.b inferential. The author SHALL outline a reasoned chain (plain‑language steps) that makes the relation a consequence of previously admitted statements. No formal calculus is required in this pattern; the outline must be sufficient for a peer to follow. (Think KD‑CAL stance, conceptually.)

• S‑3.c axiomatic. The author SHALL provide a constructive grounding account in one of the Γ_m.sum | Γ_m.set | Γ_m.slice forms and SHALL link the published assertion to its current C.2.1 trace episteme with tv:groundedBy. A competent peer must be able to recover the exact participants, direct relation occurrences, applicable construction rule, and identity or reidentification conditions without introducing new primitives. The account supports inspection; it creates none of those facts.

• S-3.d Structural constraint. For published structural assertions, tv:groundedBy → Γ_m.* is REQUIRED and postulate MUST NOT be used. This is an assurance-publication requirement, not a rule that the trace or mode makes the direct relation obtain.

S-4 (Relation-kind sense-making).

• For structural subtypes of ut:StructPartOf (Component/Portion/Aspect), a published assertion requires one linked construction account and cannot use postulate (see S-3.d). The direct relation pattern still governs whether the occurrence obtains and how it is identified.

• For epistemic/constitutive links (e.g., representation, usage), constructive grounding is OPTIONAL in all stances; authors prefer inferential or postulate with empirical cues.

S‑5 (Order and time are not mereology). Authors SHALL NOT encode execution order, parallelism, or temporal slicing as part‑whole. Such concerns belong to Γ_method and Γ_time families and SHOULD appear as method/time statements adjacent to, not inside, Working‑Model structure. (This prevents conceptual leakage between planes.)

S‑6 (Unidirectional dependence). CT2R‑LOG may consume Compose‑CAL and KD‑CAL conceptually; it SHALL NOT redefine them. Meaning flows downward only (Kernel → Extention → Context → Instance).

S‑7 (Register discipline). When naming principles in tv:AliasOf, authors SHOULD use Tech/Plain twin labels where available and obey minimal‑generality and rewrite rules (LEX‑BUNDLE), so that aliases are recognisable across context of meaning.

S‑8 (No tool talk). Core prose MUST NOT introduce CI/CD terms, file formats, APIs, or machine‑oriented notations in place of concepts. If examples are needed, they MAY be plain‑language narratives or domain vignettes. (This pattern is conceptual by Standard.)

#Scope & Non‑Goals (to keep the plane clean)

• In scope. Canonical publication of relations for humans; alias‑to‑principle clarity; conceptual grounding stories; author‑declared validationMode; separation of structure vs order/time.

• Out of scope. Any machinery that executes checks; any binding to specific notations; any process/workflow mechanics; any discussion of file formats. (Those belong to tooling publications, pedagogy publications, and companion records; they SHALL NOT be imported by the Conceptual Core.)

• Edge placements. When a claim is chiefly about naming fit across Contexts, prefer Mapping grounding (Kind-CAL/Lang‑CHR stance). When it is chiefly about why it follows, prefer Logical grounding. When it is about what the whole is, from its parts, prefer Constructive grounding. (Authors MAY combine them.)

#Author’s working moves (micro‑playbook, notation‑free)

M‑1. State the relation in Working‑Model form (e.g., “Impeller ComponentOf Pump”). M‑2. Pick validationMode:

• For a non-structural claim that is still exploratory → choose postulate; add one-sentence scope and the empirical cues that would challenge it.
• If you’re justifying from known statements → choose inferential; list the 2–4 steps in plain language.
• If a published structural assertion requires the axiomatic assurance posture → link one short C.2.1 construction account and state the direct identity or reidentification rule it reports.

M‑3. Add tv:AliasOf only when a named direct relation principle helps reviewers recognize the intended reading (for example, ComponentOf points to the structural-component principle); do not alias the relation to the result of a constructor expression. M‑4. Keep order/time adjacent, not embedded: if you need “assembled in two parallel lines”, write that as a method/time statement next to the structure, not as a part‑of edge. M‑5. Stop when the reader can follow without guessing. This is the stopping rule for Quarter 2: clarity before formality. (Didactic primacy.)

#Bias-Annotation (auditable, human-first)

The purpose of this section is to make typical cognitive slips visible and name the counter-moves an author or assurance reader should apply in thought—not with tools. These biases are generic; the remedies point to neighboring FPF guard-rails and patterns.

Reader reminder. Bias audit is a reading aid. It never licenses tooling talk in Core; use the guard‑rails in Part E to keep semantics primacy and unidirectional dependence of layers.

#Conformance Checklist (normative, author-facing)

The following obligations regulate how to think and write CT2R content. They are notation‑agnostic and purely conceptual.

#Common Anti-Patterns and How to Avoid Them

#Consequences (benefits, trade-offs, mitigations)

Benefits

• Cognitive clarity for authors and readers. Working-Model relations remain canonical while assurance accounts stay beneath them; published structural assertions carry the required account without exposing it as the working vocabulary. CT2R preserves a path to higher assurance while keeping order and time outside structure.
• Progressive assurance without tooling commitments. The postulate → inferential → axiomatic assurance-posture progression lets teams raise assurance deliberately, matching their context and risk, in line with B.3.3’s maturity logic.
• Explicit fit management. Treating edge‑fit (CL) as a first‑class concern prevents silent over‑confidence: weak mappings visibly cap reliability of composed claims.
• Cleaner separation of concerns. Distinguishing collections from compositions and keeping sequence/time in Γ_method and Γ_time prevents recurrent category errors and preserves Γ‑algebra reviewability.

Trade‑offs & mitigations

• Extra prose discipline. Declaring validationMode and writing a short grounding narrative (when axiomatic) adds authoring effort. Mitigation: reuse local templates; keep narratives concise and Γ_m‑oriented by idea rather than notation.
• Temptation to stay “forever postulate.” Teams may stop at Working‑Model relations. Mitigation: use B.3.3’s subtypes/levels as a planning aid to decide where axiomatic or inferential grounding is worth the cost.
• Perceived conservatism. Acknowledging weak fit (CL) may lower effective reliability of otherwise strong parts. Mitigation: treat CL as a guide to improvement (reconcile terms, align units, verify declared links) rather than a punishment.

One‑line takeaway for managers. CT2R lets you talk in natural, domain‑meaningful relations while preserving a clear, optional path to formal grounding and empirical checking—so confidence can grow deliberately without dragging your model into tooling or syntax.

#Rationale (informative)

13.1 Why canonical‑first? CT2R-LOG treats the human-readable, task-appropriate relation (e.g., ut:ComponentOf) as the canonical publication form because that is what engineers and managers actually use to reason, decide, and communicate. The formal layers ground that form; they do not replace it. This is consistent with the authoring Standard in Part E (pattern template and style guide), which privileges clarity, purpose and didactics over premature formalism in the body text. Authors write for people first, then point to the kind of assurance they are invoking.

13.2 Why two tv: links—and why concept‑only? tv:AliasOf and tv:groundedBy name conceptual bridges from a public Working-Model relation to its direct principle and assurance account. They mandate no notation. They keep authors explicit about the relation reading, the support being invoked, and when that support must be current, without letting an alias, trace, or mode define the world-side occurrence.

13.3 Why a triad of validationMode? The triad {postulate, inferential, axiomatic} expresses staged formality compatible with the FPF stance on staged assurance: start with what the team can responsibly claim now, then move to stricter justification where risk or context demands it. That gives reviewers a shared vocabulary for the declared assurance posture of a claim without changing the canonical relation itself.

13.4 Why keep order/time out of mereology? CT2R‑LOG aligns with A.14’s firewall: structure (parthood) is distinct from order and temporal coverage. The former is published as ut:StructPartOf sub‑relations; the latter live in Γ_method / Γ_time and must not be smuggled into part‑trees. This separation avoids classic modelling failures (temporal smearing, pseudo‑components for quantities) and keeps reasoning crisp across the Γ‑family.

13.5 Why point to Γ_m.sum | set | slice (Compose‑CAL) for constructive grounding? The three C.13 forms—sum, set, slice—are sufficient to report the recurring construction accounts for integrated assemblies, collections, and aspects without expanding the kernel. They are not identity functions. A truthful account carries exact participants, direct relation occurrences, the applicable rule, and identity or reidentification conditions: the same inputs under another assembly can form another whole, while a permitted replacement can preserve one whole.

13.6 Why mental obligations rather than process mandates? Part E requires that patterns govern thinking and authoring; enforcement and automation, if any, are external concerns. CT2R‑LOG therefore states obligations as self‑contained cognitive checks: declare your mode; tell the constructive story only when you claim axiomatic strength; keep order/time in their places. This keeps the core specification evergreen and tool‑agnostic, as required.

#SoTA-Echoing

Constructive mereology, assurance-case practice, and model-based engineering all separate a readable working statement from the justification that supports it. B.3.5 carries that separation into FPF: relation names remain usable at the publication layer, while grounding and validation mode preserve the constructive or evidential basis needed for assurance.

#Relations

Builds on • A.14 Advanced Mereology — structural catalogue and the firewall that excludes roles/recipes and distinguishes Portion/Phase/Component/Constituent; CT2R‑LOG preserves these distinctions at publication time. • A.11 Ontological Parsimony (C‑5) — constructive grounding lives in a calculus; the kernel remains minimal. • B.1 Universal Γ — shared invariants and the placement of order/time in their respective Γ‑flavours. • Part E authoring rules — canonical pattern template and notational independence, which CT2R‑LOG explicitly follows.

Coordinates with • Compose-CAL (Γ_m) — supplies the three-form construction account for structural relation assertions; CT2R-LOG's tv:groundedBy points to a current C.2.1 trace episteme in the sum, set, or slice form without making that trace the relation or its identity rule. • A.22.CGUS / StructuralCT2RTypingGroundingUnfoldingStructureBlock — provides the local structural CT2R unfolding block when a constructive trace, working-model relation, target kind or logical representation, bridge, preserved structure, and loss must be inspected together; A.7.1 owns general diagnostic return to a subject construction. • KD‑CAL — provides the logical shoulder (inferential justification) when authors pick validationMode = inferential. • Kind-CAL / Lang-CHR — provide the mapping shoulder (kind and relation-label alignment) governing alias policies without altering Working-Model relations.

Constrained by • Notational Independence (E.5.2) — CT2R‑LOG refuses to prescribe formats, keeping all obligations conceptual.

Specialises / feeds • B.3.1–B.3.4 — supplies the publication discipline (Working-Model relations, declared relation kind and validationMode; F per C.2.3 where relevant) that B.3’s trust calculus expects; interacts with ageing and assurance-level assessments without changing the relations themselves.

Non‑relations No introduction of order/time — CT2R‑LOG does not define SerialStepOf / ParallelFactorOf / temporal phases; those belong to Method‑CAL and Sys‑CAL (TemporalPart) respectively.

#B.3.5:End

Last Updated: 2026-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)