#Human-Centric Working-Model

E.14 · Stable · Pattern · Part E - The FPF Constitution and Authoring Guides

#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

Use this pattern when FPF text needs to stay readable as one human working model while heavier mapping, logical, constructive, or empirical assurance remains recoverable underneath it.

#Keywords

• working model
• human-centric
• publication surface
• grounding
• assurance layers.

#Relations

#Content

#Use This When

Use this pattern when FPF text needs to stay readable as one human working model while heavier mapping, logical, constructive, or empirical assurance remains recoverable underneath it.

What goes wrong if missed. The working text either drifts into local jargon and slash labels or calcifies into proof machinery that practitioners cannot use in ordinary design, review, or management work.

What this buys. A working reader sees one small model first, while assurance readers can still recover mapping, logical, constructive, and empirical grounding without forcing that machinery back into the Working-Model vocabulary.

Ordinary route. Write the shortest practitioner sentence that names the governed object, the bounded claim, and the use it supports. If no assurance-bearing reliance question is current, let the reader stop there. When such a question is current, place only the needed Mapping, Logical, Constructive, or Empirical support underneath that same sentence and keep every cited value under its direct owner.

Not this pattern when. Do not use E.14 to decide whether a relation obtains, Work occurred, a result was constituted, evidence or assurance passes, a method applies, work is ready, a gate passed, or permission is current. Use the pattern that owns that exact claim. E.14 governs the human-first publication order and the recoverability of support; it supplies none of those domain results.

#Intent

Establish a single, human‑centric Working‑Model that practitioners can read, discuss, and evolve without exposure to formal machinery. Each statement declares an author's assurance posture (validationMode) and, when assurance is sought, attaches appropriate grounding through one or more assurance shoulders — Mapping, Logical, Constructive — and may additionally attach Empirical Validation as defined by the Trust & Assurance calculus. The posture and its supports justify or challenge the published claim; they create neither the governed value nor a world-side relation occurrence. Empirical Validation can accompany any posture and is required when the posture is postulate. Assurance shoulders sit beneath the Working-Model and never define its vocabulary.

Put bluntly: one model people work in; three assurance shoulders — plus empirical checks when the world is the judge.

#Problem Frame

Teams need one shared Working-Model to make decisions at speed. Historically this shared model either:

• drifts into jargon - different terms for one shared working-model value, slash-labels, partial overlaps; or
• calcifies into machinery - too formal for day-to-day design and review.

Both failure modes create friction between two audiences: (1) working users (engineers, programme managers, policy owners) who need a small, stable Working-Model text, and (2) assurance authors (ontologists, methodologists, auditors) who need proofs that the Working-Model text is sound.

E.14 resolves the impasse by separating concerns:

• A Working-Model layer: curated kinds and relations expressed in plain terms, governed by simple human rules.
• An Assurance stack beneath it - Mapping, Logical, Constructive - that carries the heavy arguments and accounts (concept alignment, direct relation semantics, construction-trace epistemes) and never leaks back into the Working-Model narrative.

This pattern dovetails with the framework's unification stance (small Working-Model text, rigorous foundations) and with the constructional-mereology discipline that sum, set, and slice provide inspectable accounts of independently grounded assembly, collection, and aspect facts. Those forms do not create a relation occurrence or decide whole identity. The Kernel stays minimal and meta-only.

#Problem

A reader may need to decide, design, review, or coordinate with FPF terms before they are ready to inspect mapping tables, constructive traces, evidence records, or proof arguments. If the working text exposes all of that machinery first, the model becomes unusable; if it hides the machinery completely, the model becomes arbitrary. E.14 keeps one human-facing Working-Model visible while making the assurance shoulders recoverable beneath it.

#Forces

1. Cognitive economy vs. semantic precision. Managers and engineers must navigate with a handful of names and relations; assurance authors must still check that each name has one intended governed value, each relation claim has the required direct basis, and identity conditions are explicit.

2. Speed of change vs. guarantees. The Working‑Model must accommodate rapid iteration; the Assurance stack must lag just enough to check, without blocking practical progress.

3. Parsimony vs. expressivity. The Working‑Model should not proliferate relation types or ad‑hoc categories; fine‑grained distinctions live in the Assurance layers and are shown only when they materially change a decision.

4. Downward grounding vs. upward contamination. Grounding must always flow down (Working‑Model → Mapping → Logical → Constructive). No dependence up is allowed: proofs and traces never dictate wording or layout in the Working‑Model.

5. Trans‑disciplinary unification vs. local dialects. The Working‑Model must reconcile different disciplines’ habits without erasing them; Mapping captures dialects, while the Working‑Model exposes a single usable choice.

6. Auditability vs. readability. Every Working‑Model statement must be auditable on request, yet day‑to‑day views hide the scaffolding unless summoned.

#Solution

#Human-Centric principles

#Recognition text and assurance text

Human-facing patterns also need EntityOfConcern stability across the two reading-order text blocks. The working reader should not meet one object in the recognition text and a different ontological kind in the assurance text. If the pattern distinguishes an EntityOfConcern, the interpretive or operational move applied to that object, and the wider review or work process around it, those distinctions should be made explicit rather than hidden behind stylistic noun-swapping.

Working-Model-first drafting therefore also means subject-domain-first drafting. If a pattern is meant to help with a real review, design, cultural, research, or operational problem, the recognition text should open from that problem-owning moment before internal taxonomy or package architecture. If a broader umbrella head and a narrower operative branch are both live, the pattern should state that stack plainly enough that a cold reader can tell what the umbrella names, what branch is current, what object is governed, what move is being carried, and what wider work remains outside.

Under F.18 local-first naming, the canonical pair here is recognition text and assurance text. The earlier provisional ...shell wording is retired. These names refer to two reading-order text blocks inside one pattern, not to new publication-face kinds or authority kinds.

For human-facing canonical patterns, Working-Model-first discipline should appear in a two-part reading order. The recognition text is the working text that a cold practitioner, manager, or researcher should be able to understand first: what situation this pattern is for, what it buys, what it is not for, and what ordinary mistake it helps prevent. The assurance text is the heavier text that carries declaration, object discipline, modeling lens, law, return conditions, and other assurance work.

The assurance text may justify, tighten, or audit the working text, but it must not silently replace or strengthen the recognition-text claim. Where episteme-publication-heavy or transform-heavy patterns need a compact ontological account, the assurance text should expose three things explicitly:

• the ontic target or EntityOfConcern;
• the modeling substrate or mathematical lens when one is load-bearing;
• the publication face or working text by which the claim is presented.

This is a reading-order rule rather than a demand that every reader consume the assurance text first. The point is to keep the human-facing Working-Model text primary while preserving a recoverable, auditable assurance text beneath it.

When empirical evaluation is current, keep the same reading order. The recognition text states the ordinary subject claim first. The assurance text keeps an intended evaluation in its exact U.WorkPlan, names the selected U.Method, and cites a separately constituted U.MethodDescription episteme only when the current plan, execution claim, or evaluation interpretation actually relies on that edition. It then identifies the exact dated evaluation U.Work, every admitted U.System that performed it, each exact obtaining U.RoleAssignment under which that system performed it for the attributed extent, and the actual enactsMethod relation. The system acts; a Working-Model, pattern, plan, method, method description, record, result, evidence path, provenance value, or assurance claim does not. Intended evaluation is not dated evaluation Work merely because the plan, criterion, method, description, or evidence is available.

E.14‑P.1 – Working‑Model first, stance explicit. ** Operate one Working-Model for all human-facing discussion. For each assertion, the author SHALL declare an assurance posture (validationMode) and choose the appropriate assurance shoulder(s): Mapping for term-to-governed-value alignment through the current Kind-CAL/Lang-CHR route; Logical for exact label meaning, scope, constraints, and limits; Constructive for an inspectable C.2.1 construction-trace account of independently grounded facts; and Empirical Validation for an exact domain-local result and its A.10 evidence-provenance or reliance relation plus any separately current B.3 assurance claim when observation is current. Each shoulder names its direct objects, scope, and qualification window. None creates the governed value, subject relation, work occurrence, or result it supports.

E.14‑P.2 – Downward‑only dependency. Information may flow from the Working‑Model down into any Assurance layer; no Assurance layer may impose vocabulary or shape back upward into the Working‑Model.

E.14‑P.3 – Small working text, big proof. The Working-Model exposes a minimal set of names (L-1/L-2 registers) and a compact family of relations used in everyday reasoning; the assurance text makes their meanings, direct basis, limits, and support inspectable below.

E.14‑P.4 – Human registers first. Terms in the Working‑Model are deliberately curated for human legibility (register‑badged, synonym‑aware). Synonym capture and language variance belong to Mapping; only the chosen canonical label appears in the Working-Model text.

E.14‑P.5 – Justification modes are explicit. Each Working‑Model relation declares validationMode ∈ {axiomatic, inferential, postulate}. axiomatic means that the author relies on one linked Constructive account for this assertion; inferential means that the author relies on a reasoned chain; postulate means that the assertion remains a pragmatic claim requiring Empirical Validation. validationMode is an assurance posture, not a world-side relation kind, identity test, or timelessness guarantee. Empirical Validation may also accompany inferential or axiomatic assertions. Mapping, Logical, Constructive, and Empirical assurance remain separate from the claim's direct ontology and from the currentness of every record involved.

E.14‑P.6 – Parsimony in the working text. No new Working‑Model relation types are introduced if the existing Logical label-meaning rules plus Constructive grounding suffice to capture the intended meaning.

E.14‑P.7 – Evidence is first-class claim grounding. When postulate is chosen, authors SHALL name the exact target claim, U.ClaimScope, qualification window, direct domain result and result episteme when current, and the A.10 evidence-provenance relation used for this bounded reliance. If an assurance claim is made or B.3's material-reliance threshold is met, the current B.3 assurance claim is separate and required for that assurance-bearing use. A pointer, stored record, provenance value, or assurance tuple alone supplies none of these facts.

E.14‑P.8 – Working-model-first is not explanation-thin. Human-facing parsimony does not license under-explained pattern prose. When a pattern claims a Working‑Model benefit, it SHALL still provide enough problem framing, rationale, and worked slices that readers can tell what the model clarifies, what remains on the assurance shoulders, and when a heavier review path is required.

#Layer Standard & Downward Flow (Working‑Model → Assurance)

This section defines what each layer is for, what it guarantees, and how a single Working‑Model statement is carried down.

#Working‑Model (what humans see)

Purpose. A small, curated graph of kinds and relations that a mixed team can read at a glance.

Elements.

• Kinds — one chosen concept per node (no slash‑labels).
• Relations — a short list intelligible to non‑specialists (e.g., Component‑of, Member‑of, Aspect‑of, plus a small number of cross‑disciplinary ties such as Interface‑of or Constituent‑of).
• Language register badges — labels shown in the Working-Model are L‑1 or L‑2; L‑3/L‑4 remain in Mapping as synonyms or symbols.

Obligations.

• Every Working‑Model edge and node is grounded downward (see below).
• The Working‑Model does not display constructor jargon, proof terminology, or evidence identifiers; those live in Assurance and are available on demand.

#Assurance-1: Mapping (from words to chosen governed values)

Purpose. Consolidate human labels from varied sources and bind them to the chosen governed values used on the Working-Model, including admitted U-kinds where kindhood is live.

Guarantee. For any Working-Model label, there exists a stable alignment to exactly one chosen governed value in the current scope; synonyms, abbreviations, locales, and registers are recorded here, not in the displayed Working-Model. Mapping primarily raises Concept-Bridge Assurance (CBA) by consolidating synonyms/registers and binding tokens/labels to the chosen governed value; calculus-level metrics live outside Part E.

Deliverable. A compact alignment table per scope that makes it obvious which one label the Working‑Model will show and which background source labels are recognized only as source wording.

(Rationale: Working teams speak many dialects; the Working‑Model speaks one. Mapping is the interpreter.)

#Assurance‑2: Logical (from Working‑Model relations to label semantics)

Purpose. Give each Working-Model relation one precise intended meaning and its admissible use cases, keeping the Working-Model vocabulary small.

Guarantee. A Working‑Model edge such as Component‑of or Aspect‑of carries one intended reading (transitivity/antisymmetry expectations, scope notes), sufficient for auditors to assess whether the use is legitimate in a given context.

Deliverable. A short set of label-meaning rules: “When an edge is labeled Component-of in the Working-Model text, it intends the direct structural reading whose exact participants, relation occurrence, construction rule, and identity conditions must be recovered before the assertion is accepted.” The Logical layer ties human labels to accepted meanings; it does not make the relation obtain. Calculus-level symbols are not used in E-patterns.

(Rationale: logical label alignment protects the small Working-Model text from relation proliferation while keeping meanings crisp.)

#Assurance-3: Constructive (from a structural claim to its inspectable construction account)

Purpose. Make the construction basis of a published structural claim inspectable without turning the assurance account into the relation or the whole.

Guarantee. One truthful construction trace names the exact whole, collection, or aspect; its participants; the direct relation occurrences that obtain; the applicable assembly, collection, or facet rule; and the direct identity or reidentification conditions. The same inputs under another assembly may form another whole, while a permitted constituent replacement may preserve the same whole. The trace decides neither case.

Deliverable. For a published structural assertion, link through tv:groundedBy to one current C.2.1 construction-trace episteme in the C.13 sum, set, or slice form and declare the author's validationMode=axiomatic posture. Creating, revising, publishing, or losing that trace changes the account or its availability, not the relation occurrence or whole identity. The trace edition, its warrants and evidence, and the temporal status of the described direct facts retain their own currentness.

(Rationale: constructive assurance makes the facts and identity tests behind ordinary part-whole talk inspectable; it does not substitute an author narrative for those facts.)

#Assurance-4: Empirical Validation (from claims to observed world)

Purpose. Make the empirical basis and bounded admissible use of one Working-Model claim inspectable without turning evidence, provenance, or an assurance record into the subject result.

Guarantee. Every empirical assurance use names the exact target claim, U.ClaimScope, qualification window, and direct result owner. When the claim depends on evaluation or measurement, it also names the exact dated Work, performer U.System, obtaining U.RoleAssignment, selected U.Method, any separately relied-on U.MethodDescription, actual direct participants or A.6.1 bindings, and the domain-local result plus its C.2.1 result episteme. A.10 supplies the exact evidence-provenance path and bounded reliance disposition; B.3 supplies any assurance claim. Those objects can support or qualify the Working-Model claim but create neither the subject fact nor one another.

Deliverable. Keep the ordinary Working-Model sentence first. Beneath it, expose only the exact result, work, provenance, currentness, and assurance relations that the current use consumes. Intended evaluation remains in U.WorkPlan until dated Work occurs. If a claim that evaluation Work first constituted the result episteme is separately current, A.15.PROD alone recovers that local entity-identity inception claim; no universal work-result, evidence-result, or production relation is implied. Expiry, evidence ageing, or changed source, method, calibration, result, qualification window, provenance, or assurance basis ends only the reliance that consumes that support and requires its direct owner to be re-evaluated. In B.3 terms Empirical Validation contributes on the LA shoulder; B.3 alone computes any effect on reliability R or claim scope G, and G cannot extend beyond the exact supported scope and qualification window.

#The downward grounding for a single Working-Model statement

Consider a Working‑Model arrow A –Component‑of→ B:

1. Mapping shows that the words A and B are the chosen labels for their kinds; it records background source labels without making them displayed Working-Model names.
2. Logical confirms that Component‑of in the Working-Model text means the structural reading with its ordinary mereological expectations; if the Working-Model text used Member‑of instead, Logical would similarly certify the intended reading and its boundaries.
3. Constructive links the published assertion to one current C.2.1 trace episteme that reports the exact participants, direct relation occurrences, applicable construction rule, and identity or reidentification conditions in a sum, set, or slice form. The author declares validationMode=axiomatic as the assurance posture. The direct relation and identity tests remain decisive; the trace and mode create neither.
4. Empirical Validation names the exact empirical claim and scope, the domain-local result and result episteme when current, the dated evaluation or measurement Work and actual bindings required by that result's direct owner, its qualification window, the A.10 evidence-provenance path, and any separately current B.3 assurance claim. Those objects support this bounded use; they do not create the result or make the structural relation obtain.

Together, these assurance shoulders and empirical evidence-use relation ground the human arrow without leaking their machinery upward. The Working‑Model remains simple; the Assurance stack carries the proof.

#Archetypal Grounding (System / Episteme)

Tell–Show–Show. The principle is stated once, then shown on a U.System case (structural) and on a U.Episteme case (knowledge‑bearing), in line with the authoring template.

#U.System — Working‑Model first, Constructive grounding available

• Publication (Working‑Model). Authors state structure using familiar relations (e.g., Impeller ut:ComponentOf Pump; Pump ut:ComponentOf Skid). Nothing else is required for readers to follow the design.
• Assurance (downward grounding). When higher assurance is sought, first recover the exact skid, parts, direct fastening, coupling, enclosure, terminal, flange, and seal occurrences, the applicable skid assembly rule, and the skid reidentification rule. Then link the published claim to one current C.2.1 sum trace that reports those facts and declare the assurance posture. The account remains below the Working-Model; order and time stay in their own relation families.
• Canonization move. Readers continue to see Working‑Model relations as the primary Working-Model text; the constructive story is supporting, not defining.

#U.Episteme - Working-Model first; Logical, Mapping, and exact empirical support as appropriate

• Publication (Working-Model). Authors connect meaning-bearing epistemes or publications using exact knowledge relations (for example, RepresentationOf or UsageOf) in the same human-oriented style.
• Assurance (downward grounding). Logical or Mapping assurance often suffices for interpretation and alignment. When observation is the right currency, name the exact target claim, scope and window, dated evaluation or measurement Work, performer system and obtaining assignment, enacted Method, any relied-on MethodDescription, actual direct participants or A.6.1 bindings, domain-local result and result episteme, A.10 evidence-provenance path, and any B.3 assurance claim. A record, provenance value, or assurance tuple is not the observation, Work, or result.
• Canonization move. Working-Model text remains the public form; the exact result and support chain stays available underneath without leaking method, record, or time semantics into the subject claim.

#Pump-vibration measurement: short recognition, exact assurance underneath

Recognition text. Pump-37 vibration at 09:00 was 2.1 mm/s with stated uncertainty 0.2 mm/s under the current inspection method. A maintenance reader can use that bounded statement and stop before the machinery below. It does not by itself say the pump passes a maintenance criterion, that work may start, or that any gate or permission is current.

Assurance text. Pump37InspectionPlan-E3 : U.WorkPlan had designated the intended measurement and selected PumpVibrationMeasurementMethod-E2 : U.Method; it cited PumpVibrationProcedure-E5 : U.MethodDescription only for the setup and calibration claims used by the plan. Dated Pump37VibrationMeasurement-2026-07-31T0900 : U.Work was performed by ConditionMonitoringSystem-7 : U.System under obtaining RA-ConditionMonitoring-7-E4, enacted that Method, and used exact C.16/A.6.1 bindings for Pump-37, the sensor indication, calibration coefficients, and returned measurement value.

C.16 owns the domain-local measurement result and C.2.1 identifies Pump37VibrationResult-E4, the episteme that states it under the exact Characteristic, Scale, unit, uncertainty, time stance, and interpretation basis. A.10 path Pump37MeasurementProvenancePath-E6 cites the calibration, Work, bindings, and source publications; B.3 assurance claim Pump37MeasurementAssurance-E2 qualifies only the stated use and window. Neither provenance nor assurance is the measurement result. No A.15.PROD claim is needed merely because the result episteme exists; open that pattern only if a separately current question asks whether the exact measurement Work first constituted that episteme.

What changes in practice. A reader sees the usable statement first, can inspect the exact work/result/support chain when reliance matters, and returns to the maintenance-criterion, readiness, gate, or permission owner if the next decision asks one of those different questions.

#Pattern lesson

The Working-Model layer remains the canonical publication face for authors and assurance readers. Mapping, Logical, Constructive, and Empirical assurance are purpose-selected shoulders beneath it. They preserve a short recognition route while keeping exact direct facts, work, local results, provenance, assurance, and currentness recoverable under their own governors.

#Bias-Annotation (what to watch for, and the counter-moves)

Reading reminder. Bias checks are conceptual reading aids; they never introduce notational or tooling mandates.

#Conformance Checklist (normative; author‑facing duties for thought and prose)

All obligations above are conceptual and apply to thought and prose; they introduce no notational or data‑processing requirements.

E — Conceptual Examples (no notation, no data handling)

1. Exact skid assembly -> “Component Of” For PumpSkid 7, recover the exact pump, frame, reservoir, valve set, and other constituents; the direct fastening, coupling, enclosure, terminal, flange, and seal occurrences that obtain; the applicable skid assembly rule; and the skid reidentification rule. The team may then publish each truthful Component Of claim and, when assurance is current, link it to one C.2.1 sum trace that reports that basis. The same parts unconnected or assembled differently do not thereby form PumpSkid 7. A permitted pump replacement may preserve PumpSkid 7. The direct relations and reidentification rule decide; the trace and axiomatic posture do not.

2. Exact collection memberships -> “Member Of” For a four-cartridge bank, identify the exact collection, its collection-identity rule, and each direct membership occurrence. A C.13 set trace can then report that construction for assurance. Parallel use, physical proximity, a list, or an author's gathering act does not license Member Of, does not imply Component Of, and does not make the bank an acting system.

3. Exact bearer, facet, and aspect -> “Aspect Of” For the thermal envelope of one reactor, identify the exact reactor bearer, the exact thermal-envelope aspect, the governed thermal facet, the direct Aspect Of occurrence, and the aspect's identity rule. A C.13 slice trace can report those facts. Selecting a view, naming a facet, carving a diagram, or choosing a time window creates no aspect occurrence and no independent system.

Notes across the examples • Everyday labels (Component Of, Member Of, Aspect Of) remain the only labels engineers need to see; direct relation facts make them true or false, and the linked construction account makes their basis inspectable. • Structural assertions use Constructive assurance under this pattern; epistemic assertions such as “Representation Of” or “Usage Of” use the direct logical or evidence relation appropriate to the claim.

F — Resulting Context (after you apply the pattern)

What improves

• One readable structural vocabulary. Teams can ask which exact relation obtains—component, member, aspect, or another direct kind—without exposing assurance machinery in ordinary work. Assurance readers can still recover the participants, direct relation facts, construction rule, and identity conditions behind a published assertion.
• Explicit identity tests. Input lists and traces do not decide identity. Different assembly relations can make the same listed inputs another whole; an admitted replacement can preserve one whole. Collections use their own identity rule and exact memberships; aspects use the exact bearer, facet, direct relation, and aspect identity.
• Layer harmony. Engineer-facing labels live at the same level as other relation names, while their warrants and construction accounts live one step below, keeping human language clean and the claim basis auditable.

What to watch

• Discipline for structural relation kinds. A published structural assertion is unsafe when its direct relation basis or identity test is missing, even if a trace or axiomatic flag exists. Conversely, forcing epistemic links to pretend they are structural over-physicalises knowledge claims; for those, a direct logical or evidence relation is the right currency.
• Author workload moves, not grows. Day-to-day model authors stay with working labels; specification authors must recover the direct relation occurrence and identity test and keep one current construction account when this publication policy requires it. The account supports review; it does not repair missing world-side facts.

Invariants you must preserve

• Parsimony of construction accounts. Use sum to report integrated assembly, set to report a governed collection, and slice to report an exact aspect. Do not treat them as generative acts or add forms for parallelism or time-slicing; order and time remain with their direct conceptual services.
• Relation-kind-specific justification. Structural claims require independently grounded direct relations plus an inspectable construction account under this policy; epistemic claims require their direct logical or evidence relations. Neither assurance route changes the governed relation kind.

Known consequences

• Stable queries, fewer surprises. Working labels retain one direct meaning across disciplines, while each published structural assertion can be followed to the facts and identity conditions reported in its construction account.
• Audit trail without jargon. Reviewers can follow a structural claim to its exact participants, direct relation occurrences, construction rule, identity conditions, and current trace edition while everyday collaborators keep using familiar relation names.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Quotable closer. “One layer to speak, three layers to justify—only when needed.”

#Rationale

Why Working-Model is canonical. FPF privileges human-oriented relations as the primary language and working representation for thinking and communication. This satisfies didactic primacy while preserving conceptual integrity: formal work serves the human layer, not the other way around. The canonical template and style principles institutionalise this choice without inviting notation lock-in.

Why grounding flows downward. Mapping, Logical, Constructive, and Empirical supports are assurance shoulders that sit beneath the Working‑Model claim. Authors select the shoulder(s) that fit purpose and risk: type/lexical alignment (TA), reasoned consequence (VA), constructive reconstruction (VA), and real‑world confirmation (LA). This keeps the Kernel small, avoids plane‑mixing, and provides a clear path to higher-assurance guarantees when warranted.

Why patterns teach before they tighten. The Tell‑Show‑Show requirement couples each universal rule with System/Episteme illustrations, reducing cognitive load and preventing premature formalism. It is the didactic mechanism that makes Human‑Centric Canonization practical across disciplines.

Why no notation talk in Core. Guard‑rails and the style guide prohibit tool jargon and notation dependence inside normative prose; meanings are given in words and mathematics, with any renderings treated as illustrative only. This preserves longevity and cross‑disciplinary portability.

#SoTA-Echoing

#Relations

Builds on:

• E.8 Authoring Conventions & Style Guide — section order, style principles, and mandatory safety subsections used here.
• E.7 Archetypal Grounding — the Tell‑Show‑Show rule applied in this pattern’s own Grounding section.
• C.2.3 Unified Formality Characteristic (F) — declares the F scale and ΔF moves for progressive rigor; Working-Model publications SHALL declare F and remain notation-agnostic.

Coordinates with.

• CT2R‑LOG — Working‑Model Relations & Grounding — label-meaning rules and tv:groundedBy Standard for edges grounded in Γₘ.
• Compose-CAL (Constructional Mereology) — supplies the sum, set, and slice forms for a C.2.1 construction-trace episteme about independently grounded structural facts; the trace does not define the Working-Model relation or its identity.
• E.10 Lexical Discipline & Stratification — ensures naming discipline and register hygiene when the human layer is published.

Constrains:

• All architectural patterns that publish relations SHALL present them in the Working-Model layer and MAY attach assurance only as needed, preserving relation-family separation and notational independence. (Template conformance as per E.8.)

Informs.

• Part F unification practices (context of meaning, bridges, fit levels) by reinforcing the preference for human‑readable labels with explicit alignment notes rather than silent formal substitutions.

#E.14:End

---

Last Updated: 2026-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)