#Human-Centric Working-Model

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

Establish a single, human‑centric Working‑Model that practitioners can read, discuss, and evolve without exposure to formal machinery.
Each statement declares a justification stance (validationMode) and, when assurance is sought, attaches appropriate grounding via one or more assurance shoulders — Mapping, Logical, Constructive — and may additionally attach Empirical Validation (evidence) as defined by the Trust & Assurance calculus. Empirical Validation can accompany any stance; it is required when the stance is postulate. Assurance shoulders sit beneath the Working‑Model and never define its vocabulary.

#Keywords

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

#Relations

#Content

#Intent

Establish a single, human‑centric Working‑Model that practitioners can read, discuss, and evolve without exposure to formal machinery.
Each statement declares a justification stance (validationMode) and, when assurance is sought, attaches appropriate grounding via one or more assurance shoulders — Mapping, Logical, Constructive — and may additionally attach Empirical Validation (evidence) as defined by the Trust & Assurance calculus. Empirical Validation can accompany any stance; it is required when the stance 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 & Context

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

• drifts into jargon—different terms for the same thing, 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 surface, and (2) assurance authors (ontologists, methodologists, auditors) who need proofs that the surface 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.
• A three‑rung Assurance stack beneath it—Mapping, Logical, Constructive—that carries the heavy arguments (concept alignment, relational semantics, generative traces) and never leaks back into the Working‑Model narrative.

This pattern dovetails with the framework’s unification stance (small Working‑Model surface, rigorous foundations) and with our constructional mereology commitments (sum/set/slice provide extensional identity), while keeping the Kernel minimal and meta‑only.

#Forces

1. Cognitive economy vs. semantic precision. Managers and engineers must navigate with a handful of names and relations; assurance authors must still certify that those names and relations are unambiguous and extensional.

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 surfaced 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 surface and assurance surface

Human-facing patterns also need governed-object stability across the two surfaces. The working reader should not meet one object in the recognition surface and a different ontological kind in the assurance surface. If the pattern distinguishes a governed object, 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 surface 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 surface and assurance surface. The earlier provisional ...shell wording is retired. These names refer to two reading-order surfaces inside one pattern, not to new publication-surface kinds or owner kinds.

For human-facing canonical patterns, Working-Model-first discipline should appear in a two-surface reading order. The recognition surface is the working surface 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 surface is the heavier surface that carries declaration, object discipline, modeling lens, law, reroute conditions, and other review burden.

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

• the ontic target or governed object;
• the modeling substrate or mathematical lens when one is load-bearing;
• the publication or working surface by which the claim is presented.

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

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 a justification stance (validationMode) and choose the appropriate assurance shoulder(s): Mapping (term↔kind alignment via Lang‑CHR / D‑Projection), Logical (CT2R alias semantics, scope/constraints), Constructive (Γₘ generative trace), and Empirical Validation (evidence via U.EvidenceRole in a declared U.BoundedContext).

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 surface, 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; precision and completeness are proved 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 on the Working‑Model surface.

E.14‑P.5 – Justification modes are explicit.
Each Working‑Model relation declares validationMode ∈ {axiomatic, inferential, postulate}.
axiomatic → Constructive grounding (Γₘ trace via tv:groundedBy); inferential → Logical grounding (reasoned chain, often KD‑CAL‑backed for epistemic ties); postulate → Empirical Validation (evidence bundle with scope and timespan). Empirical Validation (LA) may also accompany inferential or axiomatic claims as real‑world confirmation. Mapping contributes TA, Logical/Constructive contribute VA, and Empirical contributes LA (per the Trust & Assurance calculus; no calculus variables appear on the Working‑Model surface).

E.14‑P.6 – Parsimony at the surface. No new Working‑Model relation types are introduced if the existing Logical aliases plus Constructive grounding suffice to capture the intended meaning.

E.14‑P.7 – Evidence is a first‑class support. When postulate is chosen, authors SHALL attach an evidence pointer (Empirical Validation) appropriate to the claim and context, governed by U.EvidenceRole within a declared U.BoundedContext.

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 — terms appearing on the surface 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 callable on demand.

#Assurance‑1: Mapping (from words to kinds)

Role. Consolidate human labels from varied sources and bind them to the chosen kinds used on the Working‑Model.

Guarantee. For any Working‑Model label, there exists a stable alignment to exactly one kind; synonyms, abbreviations, locales and registers are recorded here, not on the surface. Mapping primarily raises Typing Assurance (TA) by consolidating synonyms/registers and binding tokens/labels to one chosen kind; 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 alternatives are tolerated in background sources.

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

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

Role. Give each Working‑Model relation a precise alias meaning and its admissible use‑cases, keeping the surface 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 alias rules: “When an edge is labeled Component‑of at the surface, it intends the structural reading that is later verified by construction.” The Logical layer is the Standard that ties human labels to accepted meanings (CT2R alias rules); it primarily contributes Verification Assurance (VA). Calculus‑level symbols are not used in E‑patterns.

(Rationale: logical aliasing protects the small surface from relation proliferation while keeping meanings crisp.)

#Assurance‑3: Constructive (from meanings to generative traces)

Role. Provide extensional guarantees by constructing the wholes, collections, and slices that Working‑Model relations speak about.

Guarantee. For structural edges, there exists a constructional narrative (e.g., sum, set, slice) that, if told, would recreate the whole from its parts or the aspect from its bearer; this makes identity and containment trackable and testable across scales.

Deliverable. A single generative story per structural link (axiomatic justification). For non-structural ties on the surface (e.g., epistemic links), Constructive may be absent; Logical/Empirical take the lead. Constructive contributes VA (extensional identity via Γₘ); for structural edges, tv:groundedBy MUST reference exactly one Γₘ trace.

(Rationale: constructional grounding turns everyday part‑whole talk into statements whose identity conditions are not left to taste.)

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

Role. Record when and where a Working‑Model claim meets reality.
Guarantee. Every empirical binding names a U.BoundedContext, a target claim/scope, and a timespan; staleness/refresh are managed per context policy.
Deliverable. A U.EvidenceRole binding (status‑only) anchored into the Evidence–Provenance chain. Empirical Validation contributes LA (raises empirical R and constrains G to its validated envelope).

#The downward grounding for a single surface 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 retains tolerated synonyms and symbols in the background.
2. Logical confirms that Component‑of on the surface means the structural reading with its ordinary mereological expectations; if the surface used Member‑of instead, Logical would similarly certify the intended reading and its boundaries.
3. Constructive exhibits the constructional narrative (e.g., a sum of parts resulting in B with A among them), which yields axiomatic justification for the structural edge, sets validationMode=axiomatic, and binds the edge via tv:groundedBy → Γₘ.sum|set|slice.
4. Empirical Validation records the evidence pointer and scope that make the claim auditable within its U.BoundedContext (required for postulate; optional reinforcement for other stances).

Together, these three 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 stronger assurance is sought, the same author narrates the constructive story of the whole as a composition of parts and, where appropriate, attaches a downward grounding to that narrative (sum / set / slice). The narrative remains concept‑level and notation‑neutral; order and time stay out of structure and are expressed in their own planes.
• Canonization move. Readers continue to see Working‑Model relations as the primary surface; the constructive story is supporting, not defining.

#U.Episteme — Working‑Model first; Logical/Mapping preferred; Empirical evidence as appropriate

• Publication (Working‑Model). Authors connect meaning‑bearing artefacts using knowledge relations (e.g., RepresentationOf, UsageOf) in the same human‑oriented style.
• Assurance (downward grounding). Here assurance typically flows to the Logical or Mapping shoulders (reasoned argument; type/lexical alignment). Empirical Validation is used where observation is the right currency (status‑only roles on epistemes); Constructive grounding is optional and used only where a structural interpretation is genuinely intended.
• Canonization move. Again, Working‑Model text is the public form; assurance is attached deliberately and separately, without leaking method or time semantics into structure.

6.3 - Pattern lesson (both cases) The Working‑Model layer remains the canonical publication surface for authors and reviewers; assurance layers (Mapping / Logical / Constructive) are opt‑in and used purposefully, with grounding flowing downwards from the Working‑Model to the appropriate shoulder. This presentation respects the authoring template’s Archetypal Grounding requirement and keeps notational choices illustrative rather than defining.

#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. Assembly from parts → “Component Of” A pump skid is agreed to be nothing over and above its pump, frame, reservoir, and valve set considered together. Because the whole is conceptually constructed from those parts, the team may safely speak of each part as Component Of the skid. The justification is the construction itself: if any listed part were removed, the very same skid would no longer exist as that whole. This keeps identity extensional and makes the engineer‑facing alias (“Component Of”) truthful rather than conventional.

2. Parallel elements gathered → “Member Of” A test rig has four identical cartridges used in parallel. The rig treats them as a conceptual gathering; membership is fixed by inclusion in that gathering, not by sequence or timing. Speaking of each cartridge as Member Of the rig’s cartridge bank is then licensed by the same gathering act. Engineers can keep saying “member,” while architects know the warrant is the underlying construction of the bank as a collection, not an accidental tagging.

3. Focused facet carved → “Aspect Of” When the team talks about the thermal envelope of a reactor, they are not multiplying entities; they are taking the already‑agreed reactor and conceptually carving out its thermal facet for focused reasoning. Calling that carve‑out an Aspect Of the reactor is justified because the aspect owes its identity to the parent and the chosen facet, and nothing else. This licenses disciplined talk about “boundary,” “interface,” or “envelope” without mistaking them for independent systems.

Notes across the examples • Everyday aliases (Component Of, Member Of, Aspect Of) remain the only labels engineers need to see; their truth is anchored by prior constructional choices.
• Structural links draw on Constructive grounding; epistemic links—like “Representation Of” or “Usage Of”—may instead rely on Empirical Validation (evidence bundles) or Logical grounding appropriate to the claim.

F — Resulting Context (after you apply the pattern)

What improves

• Single dial for containment. Teams can ask one plain question—“what is inside what?”—and trust that all structural talk reduces to shared constructional choices rather than ad‑hoc relation lists. Ontologists keep rigorous warrants without burdening day‑to‑day readers.
• Extensional identity by default. Wholes are the wholes they are because of the parts gathered; collections are the collections they are because of their members; aspects inherit identity from their parent and facet. This prevents silent drift when labels change.
• Layer harmony. Engineer‑facing aliases live at the same level as other relation names, while their warrants live one step below, keeping human language clean and the generative basis auditable.

What to watch

• Discipline at the structural tier. A structural link that lacks a constructional warrant is conceptually unsafe. Conversely, forcing epistemic links to pretend they are structural over‑physicalises knowledge claims; for those, evidence or argument is the right currency.
• Author workload moves, not grows. Day‑to‑day model authors stay with aliases; specification authors carry the burden of ensuring every structural statement really follows from a sum, a gathering, or a carve‑out. This is a conscious shift of complexity away from operations and into the pattern’s foundation.

Invariants you must preserve

• Parsimony of constructors. Build wholes by summing parts; build banks by gathering elements; focus facets by carving aspects. Do not invent extra generative acts for parallelism or time‑slicing; those concerns belong to other conceptual services.
• Two‑tier justification. Structural talk rides on construction; epistemic talk rides on evidence or proof. Keep the boundary sharp so that later reasoning (about reliability, compliance, or policy) remains clear.

Known consequences

• Stable queries, fewer surprises. Because aliases are backed by shared constructions, teams from different disciplines can interoperate without renegotiating meanings at hand‑off.
• Audit trail without jargon. Reviewers can trace every structural claim to a prior constructional choice, while everyday collaborators keep using familiar relation names.

#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 interface 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 stronger 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.

#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 artefacts SHALL declare F and remain notation-agnostic.

Coordinates with.

• CT2R‑LOG — Working‑Model Relations & Grounding — alias rules and tv:groundedBy Standard for edges grounded in Γₘ.
• Compose‑CAL (Constructional Mereology) — provides the constructive shoulder (Γₘ: sum | set | slice) used to ground structural edges.
• 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 plane 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