#Cluster A.V - Constitutional Principles of the Kernel

Preface node heading:cluster-a-v-constitutional-principles-of-the-kernel:16040

#Content

#Strict Distinction (Clarity Lattice)

#Intent

Provide a single, didactically clear lattice of distinctions that keeps models free from category errors. This pattern is the guard‑rail that prevents four recurrent confusions:

1. Role vs Function (mask vs behaviour),
2. MethodDescription vs Method vs Work (description vs capability vs occurrence),
3. Holon vs System vs Episteme (what can act and what cannot),
4. Episteme vs Carrier (knowledge vs its material signs).

It harmonizes A.12 (External Transformer), A.13 (Agential Role & Agency Spectrum), A.14 (Advanced Mereology), and A.15 (Role–Method–Work Alignment).

#Problem frame

• Holons (A.1) and systems. All holons are part/whole units; only systems can enact behaviour.
• Externalization (A.12). Every change is performed by a system bearing TransformerRole across a boundary; there is no “self‑magic”.
• Quartet backbone (A.3, A.15). We separate MethodDescription (description), Method (capability under a role), and Work (run‑time occurrence), with the system bearing TransformerRole as the acting side.
• Evidence (A.10). Knowledge claims are anchored via Symbol‑Carrier Register (SCR); epistemes never “act”, they are used by systems that act on their carriers.

Manager’s reading: if a sentence could be read as “the document decided” or “the process executed itself”, it violates A.7.

#Problem

When documents blur the above lines, three classes of defects appear:

1. Category collapse. People write “function/role/process” interchangeably; teams then disagree whether they are changing a plan, a capability, or reporting an actual occurrence.
2. Agency misplacement. Epistemes (documents, models) are treated as doers; collectives as raw sets; or a “holon” is used where only a system makes sense.
3. Audit failures. A MethodDescription is cited as if it were evidence; or Work has no anchors (no carriers, no time span), making trust impossible (B.3).

#Forces

#Solution — The Clarity Lattice (normative distinctions & safe vocabulary)

#Terminology (normative): orthogonal characteristics

• senseFamily — the categorical characteristic, used by F.7/F.8/F.9: {Role | Status | Measurement | Type‑structure | Method | Execution}. Rows must be sense‑uniform. • ReferencePlane — the referent mode per CHR: {world/external | conceptual | epistemic}. • I/D/S layer — the Intension/Description/Specification layer (E.10.D2). Not an I/D/S “plane” or "stance", and not a bare "layer". • DesignRunTag — the design vs run DesignRunTag. Not a temporal “plane” or "layer", and not a bare "stance". • PublicationSurface — the didactic projection of a Description/Specification into a bundle of views (ISO 42010 sense). Surfaces are not the thing described. Under L‑SURF, Core allows only PublicationSurface and InteropSurface tokens; faces SHALL be named …View / …Card / …Lane rather than inventing new …Surface kinds. The canonical didactic set for architectural patterns in FPF is: {PlainView (explanatory prose), TechCard (typed cards/IDs), NormsCard (TechCard profile for checklists/SHALL‑clauses), AssuranceLane (evidence bindings/lanes)}. Surfaces are orthogonal to I/D/S and to design/run. • Typed describing/formalising morphisms (I→D, D→S) — total morphisms that project along I/D/S (they are not mechanisms): Describe_ID : I → D (describe an intensional object into the world of descriptions; historical alias Publ_ID) and Specify_DS/Formalize_DS : D → S (refine a description into a specification). Composition Describe_IS := Specify_DS ∘ Describe_ID : I → S is allowed but both stages MUST remain visible and auditable. Laws (normative): (ID‑1) Non‑extensibility of content; (ID‑2) Identity & meaning‑preserving composition; (DS‑1) Monotonic refinement under ≤₍ref₎; (DS‑2) Pin editions & measurable anchors per MM‑CHR (C.16) via CHR‑Pins; (DS‑3) No retro‑effects.

A.7 establishes the following pairs and triplets. Use their names and scope exactly as below.

#Role vs Function (behaviour)

• Role (role‑object, mask). A contextual position a holon can bear (A.2, A.15). A role is not behaviour; it is the mask under which behaviour may be enacted. Example: Cooling‑CirculatorRole in a thermal loop.

• Function = behaviour = Method under a role. What a system actually does when bearing a role. In Transformer context, this behaviour is the Method (design‑time capability) that can be executed as Work (run‑time).

  • Safe rewrite for earlier “Holonic Duality (Substance ⧧ Function)”: Holonic Duality (Substance ⧧ Role). A U.System keeps its identity (substance) while switching roles; each role may entail a Method (behaviour) and its possible Work (occurrence).

Normative guard: Use “Role” for the mask; use “Method/Work” for behaviour/occurrence. Do not call the role itself a function.

#MethodDescription vs Method vs Work (design vs capability vs occurrence)

• MethodDescription — the description (algorithm / SOP / recipe / script) at design‑time. Anchored via SCR (A.10).
• Method — the order‑sensitive capability the system bearing TransformerRole can enact, composed with Γ_method (B.1.5). A Method is a timeless semantic capability; concrete values are bound at U.Work creation. Outside executions we refer to it via MethodDescription (see A.3.1 CC‑A3.1‑5/‑9; A.15 §2.2, §4.1).
• Work — the dated run‑time occurrence (what actually happened), with resource spend (Γ_work) and temporal coverage (Γ_time).

Normative guard: Never use MethodDescription as evidence of Work; never present Method as if it had happened.

#Holon vs System vs Episteme (who can act)

• System — the only holon kind that can bear behavioural roles and enact Method/Work.
• Episteme — cannot act; it is changed via its carriers by a system. Epistemes may bear non‑behavioural roles (e.g., ReferenceRole, ConstraintSourceRole).
• Holon — umbrella term; do not use it where only system is meaningful (e.g., “holon bearing TransformerRole” is invalid; write “system bearing TransformerRole”).

Normative guard: Behavioural roles (including TransformerRole) have domain = system. Epistemes may bear purely classificatory roles only.

#Episteme vs Symbol Carrier (SCR/RSCR)

• Episteme — the knowledge content (claim, model, requirement set).
• Symbol Carrier — the physical/digital sign that carries the episteme (file, volume, dataset item), tracked in SCR; remote sets in RSCR.
• Use: Evidence, provenance, and reproducibility address carriers; arguments and validity address epistemes.

Normative guard: When you say “we updated the spec”, detail which carriers changed (A.10).

#Collective vs Set, and MemberOf vs Component/Constituent/Portion/Phase (A.14)

• Set / Collection (MemberOf) — mathematical or catalog grouping; no joint behaviour implied.

• Collective System — a system with boundary and coordination Method (e.g., a team).

• Use relations correctly:

  • ComponentOf — mechanical/structural part in systems.
  • ConstituentOf — logical/content part in epistemes.
  • PortionOf — quantitative portion with conserved extensives.
  • PhaseOf — temporal part/state across a continuous identity.
  • RoleBearerOf — a system is the bearer of a Role.

Normative guard: If the grouping is expected to act, model a collective system (not a set) and provide its role and Method/Work.

#Operator alignment (names you MUST use)

• Γ_sys — composition of system properties (physical/systemic).
• Γ_method — composition of Method (order, branching).
• Γ_time — composition of Work histories and temporal parts.
• Γ_work — composition of resource spend and yields tied to Work. Do not track costs with Γ_method; costs (resources/yield) belong to Γ_work.

Normative guard: Avoid generic “process” for these operators. Reserve “process” for domain idioms; map internally to Method (design) and Work (run).

#I/D/S vs PublicationSurface (orthogonal, normative)

• I/D/S governs the model. What the thing is vs how it is described/tested lives in I/D/S (E.10.D2).
• PublicationSurface governs the didactic projection. How D/S are presented lives on PublicationSurface/InteropSurface only; concrete faces SHALL be PlainView / TechCard / InteropCard / AssuranceLane. Cards/views are conceptual views over D/S, not the intensional object and not symbol carriers; physical/digital carriers stay in SCR/RSCR (A.10).
• Surface field pins. When D/S are shown on TechCard, pin the minimal CHR‑Pins = {UnitType, ScaleKind, ReferencePlane, EditionId}.
• Bridge routing. Cross‑Context or cross‑plane reuse MUST cite Bridge id + CL; Φ(CL)/Φ_plane penalties route to R (trust) only; F/G invariant.

#Typed describing/formalising morphisms (I→D→S, normative)

What Describe_ID / Specify_DS mean in A.7. For any intensional object X ∈ I, describing X is the morphism application Describe_ID(X) : D (historical alias Publ_ID(X) in earlier drafts); formalising that description is Specify_DS(Describe_ID(X)) : S (alias Formalize_DS). The collapsed arrow Describe_IS(X) MAY be referenced, but implementations SHALL expose and audit both steps.

Invariants (restate of the A.6.2/A.6.3 laws, audit‑oriented):

1. Non‑extensibility (ID‑1). Describe_ID MUST NOT introduce new epistemic commitments. If a claim c is absent in X, it is absent in Describe_ID(X); any added structure is representational only (formatting, indexing, cross‑references).
2. Identity & meaning preservation (ID‑2). If f : X → Y is a meaning‑preserving map in I, then Describe_ID(f) is defined and preserves identity, and where meaningful composition exists, Describe_ID(f ∘ g) = Describe_ID(f) ∘ Describe_ID(g).
3. Monotonic refinement (DS‑1). If D₁ ≤₍ref₎ D₂, then Specify_DS(D₁) ≤₍ref₎ Specify_DS(D₂) (equivalently Formalize_DS(D₁) ≤₍ref₎ Formalize_DS(D₂)). Also D ≤₍ref₎ Specify_DS(D) holds when S merely adds testable structure.
4. Pinning of editions & anchors (DS‑2). Specify_DS/Formalize_DS MUST pin: edition id, unit/scale types, ReferencePlane, and measurable anchors (CG‑Spec/CHR). Pins are visible on TechCard/NormsCard faces and recorded in SCR; edition governance follows U.EditionSeries.
5. No retro‑effects (DS‑3). Applying Specify_DS yields a new S and new carriers (new SCR ids); earlier carriers remain valid in their scope; no retro‑mutation of prior I/D carriers.
6. Separation from Γ. Describe_ID/Specify_DS (Publ_ID/Formalize_DS in legacy text) do not compose with Γ_method, Γ_time, or Γ_work; I/D/S describing/formalising is not execution and accrues no resource/time semantics.
7. Ontology preservation. Describing any object (Calculus/Signature/Mechanism/…) via Describe_ID does not change its ontology; it yields a D/S projection by A.7 rules. Describing/formalising is not a subtype of mechanism; publishing to surfaces is handled separately in E.17 (MVPK).

#U.OutcomeSpec (promised outcome template: work‑only / result‑only / composite)

Engineers routinely use the word outcome (and often “result”, “deliverable”, “service delivered”) as a metonymy for different things:

• the work itself (“work for 5 minutes”, “provide support”, “process N requests”),
• the world state / artefact after work (“a hole exists”, “a hairstyle exists”, “a ticket is resolved”),
• or both (common in SLAs/SOWs: “do it within 20 min and produce the requested artefact”).

FPF keeps these distinct by introducing a single promise‑facing target object: U.OutcomeSpec.

#A.7:5.10.1 — Definition (normative)

U.OutcomeSpec is an Episteme that specifies the promised outcome template referenced by U.PromiseContent.promisedOutcomeSpecRef (A.2.3). It is the “content of what is promised” as a judgement target.

It MAY constrain:

1. delivery work — predicates over U.Work episodes (A.15.1), e.g., duration, step coverage, resources used, method constraint;
2. delivered state / artefact — predicates over the post‑state of affected referents (via U.Work.Δ / evidence anchors), e.g., geometry/appearance/correctness;
3. both (composite).

U.OutcomeSpec is not a U.Work episode and not the extensional delivered object. It exists so a promise clause can be evaluated without confusing spec with actuals.

Reference type.
OutcomeSpecRef ::= ObjectIdRef and MUST resolve to a U.OutcomeSpec.

#A.7:5.10.2 — Minimal structure (conceptual; normative constraints)

U.OutcomeSpec ::= {
  id: OutcomeSpecId,
  mode: OutcomeMode,                   // WorkOnly | ResultOnly | Composite

  // WorkOnly / Composite:
  workSpec?: {
    methodConstraintRef?: MethodDescriptionRef,   // optional: method is part of the promise (not “implementation detail”)
    workPredicateRef: EpistemeRef                 // predicate evaluated on U.Work facts/evidence (A.15.1)
  },

  // ResultOnly / Composite:
  resultSpec?: {
    describedEntityRef?: EntityRef,               // what thing’s post‑state matters (may be kind-labelled)
    statePlaneRef?: StatePlaneRef,                // where the predicate lives (A.7:3 pins)
    postConditionRef: EpistemeRef                 // predicate evaluated on post‑state (or evidence about it)
  },

  notes?: Text/Episteme
}

OutcomeMode ::= WorkOnly | ResultOnly | Composite

Mode completeness (normative).
mode=WorkOnly ⇒ workSpec present ∧ resultSpec absent
mode=ResultOnly ⇒ resultSpec present ∧ workSpec absent
mode=Composite ⇒ workSpec present ∧ resultSpec present

#A.7:5.10.3 — unitOfDelivery and countingRule mini‑schema (normative)

U.PromiseContent.unitOfDelivery (A.2.3) is an Episteme that states how delivered units are counted/measured. It is intentionally not a new “counting language”; it is a small record whose predicates are provided as ordinary epistemes.

A conforming unitOfDelivery SHOULD be representable by this mini‑schema:

unitOfDelivery ::= {
  unitLabel: Text,                       // e.g., "request", "minute", "case", "kWh"
  countingRule: {
    selectorRef: EpistemeRef,            // selects which U.Work episodes contribute (default: W✓ for the promise content)
    quantityRef: EpistemeRef,            // maps each selected Work → ℝ≥0 units (default: constant 1)
    aggregation: count | sum,            // count = Σ 1; sum = Σ quantityRef(work)
    dedupeKeyRef?: EpistemeRef,          // optional: prevents double counting (e.g., by ticketId/appointmentId)
    Γ_timePolicyRef?: PolicyIdRef        // optional: windowing policy id when non-trivial
  }
}

Default behaviour (normative). If unitOfDelivery is absent, delivered units default to |W✓(SC,T)| (one unit per accepted delivery work). If unitOfDelivery is present but omits either predicate, defaults apply: selectorRef := fulfilsPromiseContent(SC) and quantityRef := 1.

Measurement typing note (normative). When quantityRef denotes a measured characteristic (e.g., seconds, kWh, kg, requests), the characteristic’s scale/unit and measurement procedure MUST be explicit via the Characterization patterns (C.16 / C.25) (or an equivalent UTS definition) so that two parties cannot silently “count different things” under the same unitLabel.

#A.7:5.10.4 — Bridge to U.Work (normative invariants)

OUTSPEC‑INV‑1 (No metonymy).
promisedOutcomeSpecRef points to an OutcomeSpec, not to U.Work and not to an extensional delivered object. The actuals live on U.Work (A.15.1) and its evidence anchors.

OUTSPEC‑INV‑2 (Evaluability from work evidence).
All predicates referenced by workPredicateRef, postConditionRef, and unitOfDelivery.countingRule.* MUST be evaluable from U.Work facts and cited evidence (including U.Work.Δ state anchors / evidence carriers). They MUST NOT require introspecting the internal structure of the provider system unless that structure is itself exposed as evidence.

OUTSPEC‑INV‑3 (Counting coherence).
If unitOfDelivery is present, its countingRule MUST select only work episodes that are eligible to satisfy the promise content and MUST not silently double‑count (use dedupeKeyRef or a cited policy).

#A.7:5.10.5 — Canonical examples (didactic)

Example 1 — Work‑only (promise the work): “provide consultation for ≥5 minutes”.

OutcomeSpec(OS‑Consult‑5min) := {
  mode: WorkOnly,
  workSpec: {
    methodConstraintRef?: MD‑Consultation,
    workPredicateRef: E‑(duration(work) ≥ 5 minutes)
  }
}

unitOfDelivery := {
  unitLabel: "minute",
  countingRule: {
    selectorRef: E‑(work fulfils OS‑Consult‑5min),
    quantityRef: E‑durationMinutes(work),
    aggregation: sum
  }
}

Example 2 — Result‑only (promise the world state): “a hole of depth ≥ 1 m exists”.

OutcomeSpec(OS‑Hole‑1m) := {
  mode: ResultOnly,
  resultSpec: {
    describedEntityRef: kind(Hole),
    statePlaneRef: GeometryPlane,
    postConditionRef: E‑(depth(hole) ≥ 1 m ∧ location(hole) within SiteScope)
  }
}

unitOfDelivery := {
  unitLabel: "hole",
  countingRule: {
    selectorRef: E‑(work fulfils OS‑Hole‑1m),
    quantityRef: E‑1,
    aggregation: count,
    dedupeKeyRef: E‑holeId(work)         // prevents double counting when rework happens
  }
}

Example 3 — Composite (promise both): “hairstyle for the evening, produced within 20 minutes, by cut+style (not a wig)”.

OutcomeSpec(OS‑Hair‑Evening‑20min) := {
  mode: Composite,
  workSpec: {
    methodConstraintRef: MD‑CutAndStyle‑NoWig,
    workPredicateRef: E‑(duration(work) ≤ 20 minutes)
  },
  resultSpec: {
    describedEntityRef: kind(HairstyleOnClient),
    statePlaneRef: AppearancePlane,
    postConditionRef: E‑(looksLike(style="Evening") ∧ survivability(afterShower) ≥ acceptable)
  }
}

unitOfDelivery := {
  unitLabel: "session",
  countingRule: {
    selectorRef: E‑(work fulfils OS‑Hair‑Evening‑20min),
    quantityRef: E‑1,
    aggregation: count,
    dedupeKeyRef: E‑appointmentId(work)
  }
}

(Where E‑(…) denotes an Episteme/predicate defined in the relevant Context; this appendix does not introduce an expression language.)

#Archetypal Grounding (Tell–Show–Show; System / Episteme)

#System and Episteme example

System archetype — “Digital‑twin vs asset”.
Claim: The twin (episteme) does not “act”; the system bearing TransformerRole enacts Work on the asset; evidence binds to carriers.
Show: A maintenance MethodDescription (tech card) lives at design‑time; a Work record (assurance face) lists Γ_time, Γ_work, PathId and carrier ids for telemetry. The twin’s update is Work on the carrier, not the asset; CL^plane penalties are disclosed when twin–asset crossings are analysed.

Episteme archetype — “Peer‑review vs manuscript”.
Claim: A review is Work by a system (the reviewer) on carriers of an episteme (the manuscript).
Show: The MethodDescription is the review SOP; the Work cites carrier ids (file/edition) and the describedEntity episteme; arguments/rebuttals live on epistemes; acceptance gating lives in CAL, not in CHR cards.

#Didactic examples

Example 1 — Pump in a cooling loop

• Substance (system): Centrifugal pump P‑12.
• Role: Cooling‑CirculatorRole.
• MethodDescription: “Loop Circulation v3” (TechCard, anchored in SCR).
• Method: ordered capability: start → ramp → hold → stop (Γ_method).
• Work: run on 2025‑08‑09 10:00–10:45; energy ledger via Γ_work; log via Γ_time.
• Safe phrasing: “The system playing Cooling‑CirculatorRole (via the P‑12 control unit as Transformer) executed the Method described by MethodDescription, producing Work …”
• What not to write: “The pump’s function is the role” (role ≠ behaviour).

Example 2 — Standard document cited in a design

• Episteme: “Safety Standard S‑174”.
• Carriers: PDF (SCR id: scr://std/S‑174/2025‑07), printed volume (scr://print/S‑174/2e).
• Role: ReferenceRole in the valve selection activity.
• System bearing TransformerRole: design team’s selection service.
• MethodDescription: “Valve Selection SOP v5”.
• Method/Work: capability and dated selection session that used the standard; the episteme did not act.

Example 3 — Set vs team

• Set (MemberOf): {Alice, Bob, 3.14} — a collection; no behaviour implied.
• Collective system (team): boundary, coordination Method, supervision Work; can bear AgentialRole (A.13).
• Safe phrasing: “Team T plays Cooling‑MaintenanceRole and executed Work W…”

#Conformance Checklist (normative)

#Canonical rewrites (didactic library)

#Anti‑patterns (with fixes)

1. Role‑as‑behaviour — calling the role “the function”. Fix: Name the role + Method/Work pair explicitly.

2. Episteme‑as‑system — “the model routed traffic”. Fix: Name the system (or Transformer as a system bearing AgentialRole) that used the model; list carriers touched.

3. Triad everywhere — omitting Work entirely. Fix: Add the Work lane: timestamps, outcomes, Γ_time coverage.

4. Operator blur — using one “process operator” for everything. Fix: Choose among Γ_method, Γ_time, Γ_work, Γ_sys.

5. Set‑as‑collective — a MemberOf set “decides”. Fix: Model a collective system with coordination Method.

6. Unanchored evidence — citing ideas without carriers. Fix: Add SCR/RSCR ids; tie claims to carriers.

7. Holon/system drift — “holon maintains temperature”. Fix: Say system; reserve “holon” for neutral mereology.

8. Function/role swap in tables — columns labelled “Function” but entries are roles. Fix: Rename column to Role; add a separate Behaviour (Method/Work) column.

9. Process‑word leakage — domain “process” used as FPF operator. Fix: Add parenthetical mapping at first use (Method/Work).

10. Carrier/episteme swap — “we versioned the model” meaning a file was renamed. Fix: State whether the episteme content changed; if only a carrier was renamed, say so.

11. Publication‑as‑mechanism — modelling “publication” as if it were a Method/Mechanism. Fix: Separate describing/formalising (Describe_ID/Specify_DS) from publication (MVPK D/S→Surface). If there is operational toil (build, render, upload), model it as Work by a system on carriers; do not change the ontology of the described object or the D/S episteme being surfaced.

#Consequences

#SoTA‑Echoing (post‑2015 practice alignment)

• Digital Twins (ISO 23247, 2021→): separates the asset (system) from its digital representation (episteme) and prescribes governance of twins without attributing agency to the twin itself — matching A.7’s “episteme ≠ actor” and carrier discipline. Adopt.
• Observability (OpenTelemetry, 2019→2025): codifies semantic conventions as a publication layer over traces/metrics/logs; semantics live in descriptions, not exporters — echoing our PublicationSurface orthogonality. Adapt (terminology).
• Active Inference (2017→2024): separates a generative model (episteme) from actions by the agent (system), with explicit perception–action cycles — mirroring A.7’s “who can act” and stance separation. Adopt
• Constructor Theory (2016→): frames knowledge and work as possible transformations enacted by constructors (systems), not by informational states — reinforcing “episteme ≠ actor”. Adopt
• Quality‑Diversity (MAP‑Elites family, 2015→2024): archives are sets on typed spaces (descriptions) whose occurrences are runs; selection returns sets under lawful orders — consonant with A.7 and A.15’s set‑returning discipline. Adopt/Adapt.
• Refinement‑typed specs (2016→): modern stacks (e.g., Liquid Haskell, Dafny’s post‑2017 refinements, Rust’s uom type‑level units) treat formalization as monotonic refinement with pinned units/scales — echoing Formalize_DS and Surface field pins. Adapt (terminology; pinning discipline).

#Rationale (informal)

• Engineering cognition: Large programmes fail less from equations than from category slips (“process vs procedure vs execution”). A.7 eliminates these slips by a small, repeatable grammar.
• Compatible with ISO/BORO practice: Distinguishing artefacts (specs), capabilities (procedures), and occurrences (operations) mirrors established systems‑engineering discipline while keeping FPF’s holonic rigor.
• Didactic primacy: Managers can approve sentences by spotting five tokens: system bearing TransformerRole / Role / Method / Work / SCR.
• Why bring “PublicationSurface” into A.7? Strict Distinction already guards what a thing is (I) from how we describe/specify it (D/S). In practice, misreadings happen at the publication layer: cards and tables are mistaken for objects; governance words leak where physics/logic should stand. By making PublicationSurface explicit and orthogonal, A.7 closes that gap without entangling semantics with any tool or notation. This preserves C‑1 universality and P‑1 Cognitive Elegance, while giving E.8 a crisp home for multi‑face presentation rules.

#Relations

Builds on: A.1 (Holon), A.2 (Roles), A.3 (Transformer Quartet), A.10 (Evidence & SCR), A.12 (External Transformer), A.14 (Advanced Mereology), A.15 (Role–Method–Work Alignment).

• Constrains: A.13 (Agency sits on systems only; epistemes non‑behavioural), Part B operators (Γ_method/Γ_time/Γ_work/Γ_sys) and their choice points; publication is not a Γ‑operator.
• Extends: E.8 (Authoring conventions), E.10 (LEX‑BUNDLE incl. L‑SURF), Part F/G (UTS & CG‑Spec/CHR pinning), B.3 (Assurance routing), C‑cluster (selection/archives) — by enforcing I/D/S vs Surface orthogonality, System/Episteme separation, and typed I→D→S describing/formalising discipline (publication = D/S→Surface in E.17).
• Coordinates with: E.18 (E.TGA - GateCrossing / OperationalGate(profile)) for crossing visibility & publication gating, A.21/A.27 for check/pinning discipline, E.10 for lexical SD checks, and Part F (Bridges/CL) for explicit cross-Context identity — without embedding any notation dependence.

#Manager’s one‑page review (copy‑paste)

Approval sentence template

“The system bearing TransformerRole ⟨name⟩ plays ⟨Role⟩; it has Method ⟨M⟩ (from MethodDescription ⟨S⟩) and executed Work ⟨W⟩ on ⟨time⟩, anchored to ⟨SCR ids⟩; resources accounted via Γ_work.”

Five binary checks

1. Actor ban: No “actor” token; canonical phrasing present.
2. Clear trio: MethodDescription / Method / Work are all named (as applicable) and not conflated.
3. Right Γ: Γ_method for capability; Γ_time for occurrence; Γ_work for resources; Γ_sys for system properties.
4. Episteme handled: Epistemes do not act; carriers listed (SCR).
5. Group clarity: Acting group is a collective system, not a MemberOf set.

Diagram legend stub

• “process (domain)” ⇒ Method (design‑time) / Work (run‑time).
• Role column lists masks (e.g., Cooling‑CirculatorRole).
• Behaviour column shows Method/Work, not the role itself.

#A.7:End

#Universal Core Principle (C‑1)

“A principle that works in only one world is local folklore; a first principle architects every world.”

#Problem Frame

FPF aspires to be an operating system for thought that engineers, biologists, economists, and AI agents can all use without translation layers. That promise rests on the universality of its core primitives (U.Types). History is littered with “upper ontologies” that proclaimed universality yet smuggled in the biases of a single discipline; once deployed beyond their birthplace, they cracked or ballooned. Rule C‑1 turns “universal” from a marketing word into a measurable criterion: cross‑domain congruence.

#Problem

#Forces

#Solution — The Three‑Domain Falsification Test

Normative Rule (C‑1) A U.Type enters the kernel only if it is shown to play the same Role in at least three foundationally distinct domains.

Heterogeneity & QD‑triad guarantee (C‑1.QD). In addition to distinct domain‑families (choose from: Exact Sciences - Natural Sciences - Engineering & Technology - Formal Sciences - Social & Behavioural Sciences), the triad SHALL demonstrate quality diversity: (a) Hetero‑test. Each projection adds at least one non‑trivial DescriptorMap signal or Bridge path not subsumed by the other two (no aliasing by mere renaming). (b) QD evidence. Publish Creativity‑CHR / NQD‑CAL evidence for the triad: Diversity_P (set‑level) and its IlluminationSummary telemetry metric with ≥3 non‑empty cells and occupancyEntropy > 0 under the declared grid. (c) Policy disclosure. Declare the Context‑local QD_policy (binning/grid, kernel, time‑window) used to compute the telemetry metrics. (References: C.17 Diversity_P & illumination Summary as telemetry metric; C.18 U.DescriptorMap, U.IlluminationSummary.)

Implementation steps (Domain Families):

1. source domain‑families from the active F1‑Card (taxonomyRef/embeddingRef edition). The five coarse families {Exact, Natural & Life, Engineering & Tech, Formal, Social & Behavioural} are informative only; if used for pedagogy, publish an explicit mapping to the F1‑Card taxonomy. The triad gate is measured by MinInterFamilyDistance ≥ δ_family (per F1‑Card), not by labels alone.

2. Role‑Projection Records For each domain, author a short Role‑Projection tuple: {domain, indigenous term, Role, exemplar}. Example: {physics, "Free Energy", extremum driver, closed gas system}.

3. Congruence Check All three exemplars must satisfy the same abstract intent; superficial analogy is rejected.

4. Living Index Track the ratio

   $$ U\text{-Index}=\frac{\text{# kernel types lacking 3 projections}}{\text{# kernel types}} $$

   as a health signal; target ≤ 0.05 (not a bureaucratic gate).

Rule of thumb for busy managers: “One idea, three worlds. If you can’t point to the trio, park it in a Extention Pattern.”

#Archetypal Grounding (System / Episteme)

These juxtapositions give engineer‑managers an immediate sense of why each primitive is worth learning.

#Conformance Checklist

#Consequences

#Rationale

Deep research over the last decade shows structural homologies across domains:

• Free‑energy minimisation ↔ negative log‑likelihood ↔ Bayesian surprise (Friston 2023).
• Conservation laws in physics mirror budget balancing in economics (Rayo 2024).

By demanding three independent manifestations, FPF captures these convergences without privileging any single vocabulary. The principle operationalises Popperian falsifiability for universality: a concept that cannot survive a three‑domain cross‑examination is, by definition, not a first principle. This guards Pillars P‑1 (Cognitive Elegance) and P‑4 (Open‑Ended Kernel) simultaneously.

#Relations

#Known Uses

• Energy ↔ Budget ↔ Attention – Engineering teams reused U.Resource to reason about battery charge, project funds, and user‑attention minutes with one algebra, cutting integration effort by half (2024 pilot).
• Objective unification – An AI lab mapped loss functions, a bio‑lab mapped Darwinian fitness, and a factory mapped scrap‑rate all to U.Objective, enabling shared optimisation tooling.

These cases validated that the Three‑Domain Test is achievable in practice, not theoretical paperwork.

#Open Questions

1. Domain taxonomy stability – Should the five domain families be versioned as science evolves (e.g., quantum‑bio‑tech)?
2. Automated congruence checks – Can category‑theoretic tooling semi‑automate the functional‑role equivalence test?
3. Edge‑case hybrids – How are bio‑cyber‑physical chimera systems counted: a new domain or a composite projection?

#A.8:End

#Cross‑Scale Consistency (C‑3)

“The logic of a bolt must still be the logic of the bridge.”

#Context

FPF models reality as a nested holarchy: parts → assemblies → systems → supra‑systems; axioms → lemmas → theorems → paradigms. Designers and analysts must zoom freely without logical whiplash. Classical mereology and modern renormalisation theory both warn: if rules mutate across scales, predictions and audits collapse. FPF therefore mandates a single, scale‑invariant Standard.

#Problem

These pathologies derail safety cases and budget decisions across disciplines.

#Forces

#Solution — Invariant Quintet + Meta‑Holon Transition

#Invariant Quintet

Any aggregation operator Γ that claims FPF conformance MUST preserve these five invariants :

Mnemonic: S‑O‑L‑I‑D (Same - Order‑free - Location‑free - Inferior cap - Don’t‑regress).

Inter‑Layer Standard note When holons are composed as a Layered‑Control stack, each Planner ↔ Regulator pair MUST publish an inter‑layer Standard: {referenceSignal, guaranteedTrackingError, cycleTime}. Matni 2024 (https://arxiv.org/abs/2401.15185) prove such Standards satisfy COMM + LOC invariants, giving a constructive instance of the Quintet.

#Meta‑Holon Transition (MHT)

If empirical data show a true violation (e.g., redundancy raises WLNK limit), the modeller declares an MHT: the collection becomes a new holon tier, and the quintet applies anew at that scale .

#Archetypal Grounding

#Conformance Checklist

#Consequences

#Rationale

Post‑2015 evidence across domains

• Physics ‑ Renormalisation coherence echoes IDEM, COMM, LOC.
• Distributed data platforms rely on COMM + LOC for deterministic aggregations.
• Safety engineering ‑ Fault‑tree analyses hinge on WLNK; aviation failures (2018‑24) confirm its necessity.
• Lean improvement ‑ MONO underpins Kaizen: fix a bottleneck, never worsen the plant.

Packaging these insights as one memorisable quintet → Cognitive Elegance with formal bite.

#Relations

#Known Uses (2018‑2025)

• Spacecraft avionics ‑ Applying WLNK exposed a sub‑grade connector, saving a $40 M launch window.
• Global vaccine meta‑reviews ‑ COMM + LOC let five epidemiology teams merge data independently; results converged within 0.1 % effect size.
• Distributed ML training ‑ MONO guaranteed optimiser swaps never reduced accuracy, cutting iteration time by 20 %.

#Open Questions for expert panel

1. Order‑sensitive physics – Should quantum‑circuit folds live in a Extention Patterns with a relaxed invariant set?
2. Synergistic redundancy – Can WLNK be reframed using an “effective minimum” when true redundancy lifts the floor?
3. Didactic tooling – Which visual cues best alert non‑formal audiences to an approaching Meta‑Holon Transition?
4. Layer depth — In an LCA (layered control architectures, https://arxiv.org/abs/2401.15185) stack every Planner is external to its Regulator; should FPF limit the number of nested layers, or is indefinite chaining acceptable?

#A.9:End

#Evidence Graph Referring (C‑4)

“A claim without a chain is only an opinion.”

#Context

FPF is a holonic framework: wholes are built from parts (A.1, A.14), and reasoning travels across scales via Γ‑flavours (B.1). To keep this reasoning honest and reproducible, every published assertion must be anchored in concrete symbol carriers and well‑typed transformations performed by an external TransformerRole (A.12, A.15). Publication itself is the typed projection I→D→S (Publ_ID, Formalize_DS) per A.7 and is not execution; any physical/digital release, rendering, or upload is Work by an external transformer on carriers, cited in SCR.

Managers can read this as a simple rule of thumb:

Claim → (Proof or Test) → Confidence badge …where the proof/test is traceable to real carriers and to an external system/Transformer who executed an agreed method.

This pattern defines the Evidence Graph Referring Standard common to all Γ‑flavours (Γ_sys — formerly Γ_core, Γ_epist, Γ_method, Γ_time, Γ_work) and clarifies: (a) the difference between mereology (part‑whole; builds holarchies) and provenance (why a claim is admissible; does not build holarchies); (b) the run‑time / design‑time separation (A.4) across Role–Method–Work (A.15).

#Problem

Without a uniform anchor, models drift into five failure modes:

1. Weightless claims. Metrics or arguments appear in the model with no link to their symbol carriers (files, datasets, lab notebooks, figures).
2. Collapsed scopes. Design‑time method specs are silently mixed with run‑time traces; results cannot be reproduced because “what was planned” and “what actually ran” are conflated.
3. Self‑justifying loops. A holon attempts to evidence itself (violates A.12 externality), producing cyclic provenance and unverifiable conclusions.
4. Source loss during aggregation. As Γ combines parts, some sources “fall out”; later audit cannot reconstruct why a compound claim was accepted.
5. Temporal ambiguity. Time‑series are aggregated without interval coverage or dating source; gaps/overlaps invalidate comparisons and trend claims.

The business effect is predictable: confidence badges cannot be defended, cross‑scale consistency (A.9) is broken, and iteration slows because every review re‑litigates “where did this come from?”.

#Forces

#Solution — The Evidence Graph Referring Standard

The Standard is a small set of primitives applied uniformly, with manager‑first clarity and formal hooks for proof obligations.

#EPV‑DAG (Evidence–Provenance DAG).

A typed, acyclic graph disjoint from mereology. Node types: SymbolCarrier (a U.System in CarrierRole, A.15), TransformerRole (external Transformer, A.12), MethodDescription (design‑time blueprint of a method, A.15), Observation (a dated assertion/result), U.Episteme (knowledge holon). Edge vocabulary is small and normative: evidences, derivedFrom, measuredBy, interpretedBy, usedCarrier, happenedBefore (temporal), etc. Manager view: it is the “because‑graph”: every claim answers “because of these carriers, by this Transformer, using that method, then.”

#Anchors (two relations, two flavours).**

• verifiedBy — links a claim to formal evidence (proof obligations, static guarantees, model‑checking artefacts).
• validatedBy — links a claim to empirical evidence (tests, measurements, trials, observations). Both anchors terminate in the EPV‑DAG, not in the mereology graph.

#A.10:4.3 SCR / RSCR (Symbol Carrier Registers).

Every Γ_epist aggregation SHALL emit an SCR: an exhaustive register of symbol carriers materially used in the aggregate, with id, type, version/date, checksum, source/conditions and optional PortionOf (A.14) for sub‑carriers. Every Γ_epist^compile SHALL emit an RSCR: SCR specialised to a bounded context (vocabularies, units) with publication‑grade identifiers and hashes. Why this matters: it prevents “lost sources” during composition and underwrites reproducibility without mandating any specific tool.

#A.10:4.4 Scope alignment (A.4) across Role–Method–Work (A.15).

• Design‑time: MethodDescription lives here; methods are blueprints; anchors reference what would constitute proof or test.
• Run‑time: Work (actual execution) lives here; traces reference which MethodDescription they instantiate and record happenedBefore. Bridging edges are explicit (“this run trace instantiates that spec”), so scopes never silently mix.

#A.10:4.5 External TransformerRole (A.12).

The system that produces or interprets evidence is external to the holon under evaluation. If true reflexivity is essential, model a meta‑holon (A.12): the self‑updating holon becomes the object of a higher‑level external transformer (the “mirror”), restoring objectivity.

#A.10:4.6 Γ‑flavour hooks (how each flavour anchors).

• Γ_sys (formerly Γ_core): physical properties are anchored by measurement models, boundary conditions, calibration carriers, and dated observations.
• Γ_epist: always outputs SCR/RSCR; every provenance/evidence node resolves to an SCR/RSCR entry.
• Γ_method: order‑sensitive composition; at design‑time a Method Instantiation Card (MIC) states Precedes/Choice/Join and guards; at run‑time traces record happenedBefore and point to the MethodDescription they instantiate.
• Γ_time: temporal claims state interval coverage; Monotone Coverage (no unexplained gaps/overlaps) is required.
• Γ_work: resource spending and yield are evidenced by instrumented carriers (meters, logs) and their MethodDescriptions; keep resource rosters separate from SCR/RSCR.

Manager’s shortcut: If you can answer what carriers, which system, which method, when, the anchor is likely sufficient; if any of the four is missing, it is not.

#Archetypal Grounding

#Conformance Checklist

Manager’s audit (non‑normative, quick): For any claim, ask What carriers? Which system? Which method? When? If any answer is missing, A.10 is not satisfied.

#Consequences

#Rationale (SoTA alignment, reader‑friendly)

• Metrology & assurance. The requirement to name quantities, units, uncertainty, calibration carriers reflects long‑standing metrology practice and modern assurance cases: numbers are only comparable when their measurement models are stated.
• Knowledge provenance. The EPV‑DAG and SCR/RSCR embody post‑2015 best practices in provenance for knowledge artefacts: keep a complete, machine‑checkable trail from claims to carriers; separate provenance from part‑whole.
• Temporal reasoning. Monotone coverage (no unexplained gaps/overlaps) aligns with temporal knowledge graph practice and avoids “impossible histories.”
• Holonic parsimony. By drawing a firewall between mereology (A.14) and provenance, A.10 prevents semantic leakage and keeps the holarchy well‑typed.
• Role–Method–Work clarity. Anchoring explicitly rides on A.15: roles act via methods specified at design‑time and produce work observed at run‑time. This keeps agency, policy, and execution disentangled yet connected.

#Relations

• Builds on: A.1 Holonic Foundation; A.4 Temporal Duality; A.12 Transformer Externalization; A.14 Advanced Mereology; A.15 Role–Method–Work Alignment.
• Constrains / Used by: B.1 (all Γ‑flavours: Γ_sys, Γ_epist, Γ_method, Γ\_time, Γ_work); B.1.1 (Dependency Graph & Proofs).
• Enables: B.3 Trust Calculus (R/CL inputs, auditability); B.4 Canonical Evolution Loop (clean design/run bridges).

#Migration (practical and brief)

Apply these text edits:

1. Terminology

   • manifest → “Symbol Carrier Register (SCR)”; release manifest → “Release SCR (RSCR)”.
   • creator / observer (as internal evidencer) → TransformerRole (external).
   • “symbol register” (ambiguous) → “Symbol Carrier Register (SCR)”.
   • Keep resource rosters in Γ_work separate from SCR/RSCR.

2. Boilerplate inserts

   • In A.10 (this pattern): retain definitions of EPV‑DAG, SCR/RSCR, and the flavour‑specific anchors.
   • In B.1.3 (Γ_epist): add the Obligations — SCR/RSCR block (“Γ_epist^synth SHALL output SCR… Γ_epist^compile SHALL output RSCR…”).
   • In B.1.5 (Γ_method): ensure MIC is referenced (Precedes/Choice/Join, guards, exceptions) and run‑time traces reference the MethodDescription they instantiate.
   • In B.1.6 (Γ_work): say “resource rosters are not SCR/RSCR; anchor meter/log readings via EPV‑DAG.”

#A.10:End

#Ontological Parsimony (C‑5)

“Add only what you cannot subtract.”

#Context

The FPF kernel aspires to remain small enough to learn in a week yet broad enough to model engines, proofs and budgets alike. Unchecked growth of primitives—well‑known from earlier “enterprise ontologies”—bloats diagrams, stalls tooling and intimidates new adopters. C‑5 therefore demands minimal‑sufficiency: a new core concept enters the kernel only when all routes of composition, refinement or role‑projection fail to express it without semantic loss.

#Problem

Result: steep learning curves, fragile integrations, eroded trust in “first‑principles” promises.

#Forces

#Solution — Four‑Gate Minimal‑Sufficiency Protocol

A proposal to add a U.Type or core relation MUST clear all four gates before admission and survives under a Sunset Timer thereafter.

Lifecycle — Sunset Timer A cleared type enters the kernel provisionally with a timer (default = 4 quarters). If usage count remains zero at expiry, the type faces Sunset Review: delete, demote to Extention Pattern, or renew with fresh evidence.

Manager’s mnemonic: “Compose, Unique, Functional, Crisp — or sunset.”

#Archetypal Grounding

#Conformance Checklist

#Consequences

#Rationale

Cognitive science shows working memory tops out around 4 ± 1 unfamiliar chunks (Cowan 2021). Combining that with Gate discipline keeps kernel size tractable (≈ 40 primitives). Software metrics from lean DSLs (Rust traits, Kubernetes CRDs) reveal that compositional modelling reduces change propagation cost by ~30 %. The Sunset Timer borrows from Kubernetes feature gate “alpha/beta/GA” progression model — proved effective at pruning half‑baked APIs.

#Relations

#Illustrative Uses (2022 – 2025)

• Robotics CAL 2023 – U.LiDARSensor rejected (Gate G‑1 passed via role composition), saving three schema migrations.
• Green‑Finance CAL 2024 – U.CarbonCredit admitted provisionally, but Sunset Review (usage = 0) demoted it to sector pattern, avoiding kernel noise.
• Neuro‑informatics 2025 – U.ProvenanceChain accepted; by Q3 its heavy reuse in three patterns lifted timer and marked it established.

#Open Questions

1. Hard size cap — should the kernel enforce an absolute limit (e.g., 64 live types) beyond which any new entry forces retirement of an old one?
2. Semantic similarity tooling — can embedding models automate Gate G‑2 overlap detection reliably across domains?
3. Gate calibration — is default Sunset Timer (4 quarters) optimal for research‑oriented patterns with slower uptake?

#A.11:End

#External Transformer & Reflexive Split

#Intent & Context

The principle of causality is the bedrock of engineering and scientific reasoning: every change has a cause. In FPF, this translates to a strict architectural rule: no "self-magic." An action cannot happen without an actor. This pattern establishes the formal mechanism for modeling causality, ensuring that every transformation is attributed to an explicit, external agent.

This pattern operationalizes the Agent Externalization Principle (C-2). It builds directly upon:

• A.3 (Transformer Constitution): Which defines the core quartet of action: the Agent (who acts), the MethodDescription (the recipe), the Method (the capability), and the Work (the event).
• A.2 (Contextual Role Assignment): Which provides the universal syntax Holder#Role:Context for defining agents.

The intent of this pattern is twofold:

1. To mandate that every transformation is modeled as an interaction between a distinct Agent (playing a TransformerRole) and a distinct Target across a defined Boundary.
2. To provide a rigorous pattern, the Reflexive Split, for modeling systems that appear to act upon themselves (e.g., self-calibration, self-repair) without violating the principle of external causality.

#Problem

Without a strict rule of agent externalization, models become ambiguous and untraceable, leading to critical failures in design and audit:

1. Causality Collapse ("Self-Magic"): Phrases like "the system configures itself" or "the document updates itself" create a causal black hole. It becomes impossible to answer the question, "What caused this change?" This makes debugging, root cause analysis, and assigning responsibility impossible.
2. Audit Dead-Ends: An auditor tracing a change finds that the system is its own justification. There is no external evidence, no log from an independent actor, and therefore, no way to verify the integrity of the transformation. This is a direct violation of Evidence Graph Referring (A.10).
3. Hidden Dependencies: In a "self-healing" system, the healing mechanism (the regulator) and the operational part (the regulated) are modeled as a single monolithic block. This hides the critical internal dependency between them. A failure in the regulator might go unnoticed until the entire system collapses, because its role was never made explicit.

#Forces

#A.12:4. Solution

The solution is a two-part architectural mandate: (1) all transformations must be modeled with an external agent, and (2) apparent self-transformation must be modeled using the Reflexive Split.

#The Principle of the External Transformer

Every transformation in FPF is a U.Work event that is the result of an Agent acting upon a Target.

• The Agent: The agent is a Contextual Role Assignment of the form System#TransformerRole:Context. This is the cause, the "doer."
• The Target: The target is the U.Holon being changed. This can be another U.System or the symbol carrier of a U.Episteme.
• The Boundary: The agent and the target are always separated by a U.Boundary and interact through a U.Interaction.

Crucial Rule: The holder of the Agent's U.RoleAssignment cannot be the same holon instance as the Target.

holder(Agent) ≠ Target

This simple inequality is the core of the externalization principle. It constitutionally forbids self-magic.

#Reflexivity vs cross‑reference (normative note)

FPF distinguishes reflexive transformation from episteme‑level reference.
Reflexive cases (e.g., “self‑calibration”) MUST be modeled by the Reflexive Split (Regulator→Regulated) and remain within the world ReferencePlane.
When a claim refers to another claim/episteme, model it with epistemeAbout(x,y) and set ReferencePlane(x)=episteme. Such references do not perform transformations and MUST NOT be used to bypass the external‑agent rule. Evaluation of chains of episteme‑about relations MUST remain acyclic within a single evaluation chain; otherwise, abstain and request a split or external evidence.

#The Reflexive Split Pattern

So, how do we model a system that does act on itself, like a self-calibrating sensor? We use the Reflexive Split. We recognize that the system is not a monolith; it contains at least two distinct functional parts.

The Procedure:

1. Identify the Roles: Decompose the system's function into two distinct roles: the part that regulates and the part that is regulated.
2. Model as Two Holons: Model these two parts as two distinct (though possibly tightly coupled) U.System holons, even if they share the same physical casing.
3. Define the Internal Boundary: Model the interface between them as an internal U.Boundary with a defined U.Interaction (e.g., a data bus, a mechanical linkage).
4. Assign the Transformer Role: The regulating part becomes the holder of the TransformerRole. The regulated part becomes the Target.

Now, the "self-action" is modeled as a standard, external transformation that just happens to occur inside the larger system's boundary. Causality is restored, and the model becomes auditable.

Didactic Note for Engineers & Managers: The "Two Hats" Analogy

Think of the Reflexive Split like a manager who needs to review their own work. To do it properly, they must metaphorically wear "two hats."

• Hat 1: The Doer. They perform the task.
• Hat 2: The Reviewer. They step back, put on their "reviewer hat," and inspect the work as if it were done by someone else.

The Reflexive Split formalizes this. The "Doer" is the Regulated subsystem. The "Reviewer" is the Regulator subsystem, which plays the TransformerRole. By modeling them as two separate entities, we make the internal quality control loop explicit and prevent the logical error of a system magically grading its own homework.

#Archetypal Grounding

The principle of external causality and the Reflexive Split pattern are universal. They apply equally to physical systems, epistemic artifacts, and socio-technical organizations.

Key takeaway from grounding: These examples demonstrate that there is no such thing as self-action in a well-formed model. Every action, even an internal one, can and must be decomposed into an external interaction between a distinct agent and a distinct target. This makes the causal chain explicit and auditable in all domains.

#Conformance Checklist

To enforce the principles of externalization and causal clarity, all FPF models must adhere to the following normative checks.

#Consequences

#Rationale

The principle of externalization is not an arbitrary rule imposed by FPF; it is a distillation of foundational concepts from multiple rigorous disciplines.

• Cybernetics & Control Theory: As Ashby's Law of Requisite Variety and modern control theory (e.g., Matni et al., 2024) demonstrate, regulation is fundamentally an interaction across a boundary between a controller and a plant. Conflating the two hides the causal structure and makes stability analysis impossible. The Reflexive Split is the FPF's implementation of this core cybernetic principle.
• Physics (Constructor Theory): As discussed in A.3, Constructor Theory recasts physics in terms of what transformations are possible. A transformation is always performed by a "constructor" (our Transformer) on a substrate. The theory does not contain "self-constructing" substrates. FPF's externalist stance is fully aligned with this physical worldview.
• Philosophy of Science (Objectivity): The scientific method is built on the principle of external observation and verification. A theory cannot validate itself; its predictions must be checked by an independent experiment. The No Self-Evidence rule (CC-A12.5) is the direct implementation of this principle in the FPF's assurance calculus.
• Software Engineering (Dependency Inversion): The principle that high-level modules should not depend on low-level modules, but both should depend on abstractions, is a form of externalization. It enforces clean separation and makes systems more modular and testable. The explicit U.Boundary in our pattern serves the same architectural purpose as a well-defined interface in software.

By mandating externalization, FPF is not adding bureaucratic overhead. It is enforcing a set of first principles that are demonstrably essential for building complex systems that are understandable, auditable, and trustworthy.

#Relations

• Directly Implements: C-2 Agent Externalization Principle.
• Builds Upon:
  • A.1 Holonic Foundation: Provides the U.System and U.Episteme holons that act as agents and targets.
  • A.2 Role Taxonomy: Provides the Contextual Role Assignment (U.RoleAssignment) mechanism to define the Agent.
  • A.3 Transformer Constitution: Defines the TransformerRole that the Agent plays.
• Enables and Constrains:
  • A.10 Evidence Graph Referring: Provides the causal structure (who did what) that evidence must be anchored to.
  • B.2 Meta-Holon Transition (MHT): A Reflexive Split is often the first step in identifying an emergent supervisory layer that may later be promoted to a new meta-holon.
  • B.2.5 Supervisor-Subsystem Feedback Loop: This pattern provides the detailed architecture for the Regulator-Regulated interaction that the Reflexive Split reveals.

#A.12:End

#The Agential Role & Agency Spectrum

“Agency is not a kind of thing; it is a way some systems operate.”

#Intent & Context

The concept of "agency"—the capacity of an entity to act purposefully—is central to engineering, biology, and AI, yet it remains one of the most overloaded and ambiguous terms. Without a precise, falsifiable, and substrate-neutral definition, models of autonomous systems risk descending into "self-magic," where actions have no clear cause and accountability is lost.

This pattern builds directly upon the foundations laid in the FPF Kernel to provide that definition. A.1 established that only a U.System can be the bearer (holder) of behavioral roles. A.2.1 defined the universal U.RoleAssignment (Holder#Role:Context) as the canonical way to assign roles. A.3 and A.12 defined the TransformerRole and the principle of the external agent.

The intent of this pattern is to:

1. Formally define agency not as an intrinsic type of holon, but as a contextual Role Assignment.
2. Introduce a measurable, multi-dimensional spectrum of agency via a dedicated Characterization (Agency-CHR), moving beyond a simple binary "agent/not-agent" switch.
3. Provide a clear, didactic grading system that allows engineers and managers to assess and communicate the level of autonomy of any system in a consistent, evidence-backed manner.

#Problem

If agency is treated as a monolithic, intrinsic property or a mere label, four critical failure modes emerge, undermining the rigor of FPF:

1. Episteme-as-Actor: Models might incorrectly assign agency to knowledge artifacts (U.Episteme), leading to nonsensical claims like "the specification decided to update the system." This is a direct violation of Strict Distinction (A.7).
2. Type Inflation: Introducing a U.Agent as a new base type alongside U.System and U.Episteme would violate Ontological Parsimony (C-5) and create conflicts with the dynamic nature of roles. A system might act as an agent in one context and a passive component in another; a static type cannot capture this.
3. Unfalsifiable Claims: Without a measurable basis, "agency" becomes a subjective label. A team might call their system an "agent" for marketing purposes, but this claim has no verifiable meaning and cannot be audited, violating Evidence Graph Referring (A.10).
4. The Binary Trap: A simple "agent/not-agent" classification is too coarse. It fails to distinguish between a simple thermostat, a predictive cruise control system, and a strategic, self-learning robotic swarm, even though their cognitive capabilities differ by orders of magnitude.

#Forces

#Solution

FPF's solution is threefold: it defines an Agent via U.RoleAssignment (A.2.1), makes agency measurable with a dedicated Characterization, and provides a didactic summary via a graded scale.

#The Core Definition: Agent as a Contextual Role Assignment

An "Agent" in FPF is not a fundamental type. It is a convenience term (a Register 1 / Register 2 label) for a specific kind of Contextual Role Assignment (U.RoleAssignment):

Agent ≍ U.RoleAssignment(holder: U.System, role: U.AgentialRole, context: U.BoundedContext)

This means an Agent is simply a U.System that is currently playing an AgentialRole within a specific U.BoundedContext.

• No U.Agent Type: To be clear, there is no U.Agent base type in the FPF Kernel. This avoids type inflation and preserves the dynamic nature of roles.
• Epistemes Cannot Be Agents: As the holder must be a U.System, this definition constitutionally forbids U.Epistemes from being agents, preventing the "episteme-as-actor" category error.
• Canonical Syntax: The technical notation for an agent is System#AgentialRole:Context.

#The AgentialRole and its Specializations

• U.AgentialRole: This is the abstract U.Role that grants a U.System the capacity for goal-directed action within a context. It is the "license to act."
• Specialized Roles: More specific behavioral roles like TransformerRole and ObserverRole are considered specializations or sub-roles of AgentialRole. They describe what kind of agential action is being performed at a given moment.
  • A system playing TransformerRole is an Agent that is currently modifying another holon.
  • A system playing ObserverRole is an Agent that is currently gathering information. This creates a clean hierarchy: a Transformer is always an Agent, but an Agent is not always a Transformer (it could be observing, planning, or idle).

#Measuring Agency: The Agency-CHR and the Spectrum

Agency is not a binary switch; it is a multi-dimensional spectrum of capabilities. FPF models this using a dedicated pattern, Agency-CHR (C.9), which is a Characterization that attaches a set of measurable properties to a U.RoleAssignment.

The Agency-CHR profile is grounded in contemporary research (e.g., Active Inference, Basal Cognition) and includes the following key characteristics. Each is measured for a specific agent in a specific context and must be backed by evidence (A.10).

1. Boundary Maintenance Capacity (BMC): The ability of the system to maintain its structural and functional integrity against perturbations. (How robust is it?)
2. Predictive Horizon (PH): The temporal or causal depth of the agent's internal model. (How far ahead can it "see"?)
3. Model Plasticity (MP): The rate at which the agent can update its internal model (U.GenerativeModel) in response to prediction errors (U.Error). (How quickly can it learn?)
4. Policy Enactment Reliability (PER): The probability that the agent will successfully execute its chosen U.Method under operational conditions. (How reliably does it do what it decides to do?)
5. Objective Complexity (OC): A measure of the complexity of the U.Objective the agent can pursue, from simple set-points to abstract, multi-scale goals.

#Context-bounded task-family specialization claims

When work shifts to a new TaskFamily, describe the holder as acquiring context-bounded task-family specialization rather than as becoming more generally intelligent in the abstract. The same holder may carry different task-family specializations across different task families without becoming a new kernel type. Breadth across unrelated task families is not the governed claim here; the governed claim is time-to-usable specialization on the declared task family and work target under a named work-measure threshold, adaptation budget, and freshness or provenance basis.

Low-human-overlap or newly discovered task families remain admissible when the task family, evidence basis, and reuse window are explicit by value.

#The Agency Grade (Didactic Layer)

While the multi-dimensional Agency-CHR profile is essential for formal assurance, engineers and managers need a simpler, at-a-glance summary. The Agency Grade is a non-normative, didactic scale from 0 to 4 that synthesizes the CHR profile into an intuitive level of autonomy.

Crucial Distinction: The Agency-CHR profile is the normative evidence. The Grade is a pedagogical shortcut. An artifact cannot claim a grade without having a corresponding, auditable CHR profile to back it up.

#Archetypal Grounding

The universal pattern of agency, defined as a Contextual Role Assignment and measured by the Agency-CHR, manifests across all domains. The following table demonstrates its application to the FPF's two primary archetypes: a U.System and a collective U.System (a team), while explicitly showing why a U.Episteme cannot be an agent.

Key takeaway from grounding: This table makes the abstract model concrete. It shows that the FPF agency model can precisely differentiate between simple controllers and complex learning systems. It also reinforces the Strict Distinction principle: the ISO standard (U.Episteme) is a crucial justification (justification?) for the actions of an agent (like the DevOps team), but it is never an agent itself.

#Conformance Checklist

To ensure the agency model is applied rigorously and consistently, all FPF artifacts must adhere to the following normative checks.

#Consequences

#Rationale

This pattern's strength comes from its synthesis of contemporary, post-2015 research into a single, operational model.

• Grounded in Science: The move away from a binary, type-based view of agency towards a graded, spectrum-based model is directly aligned with modern research in Active Inference (Friston et al.), Basal Cognition (Fields, Levin), and evolutionary cybernetics. The Agency-CHR provides a direct, practical implementation of these ideas.
• Ontologically Sound: By defining an Agent as a Contextual Role Assignment, the pattern avoids the ontological pitfalls of creating a new base type. It fully embraces the FPF's core architectural principle of separating substance (holder) from function (role) within a context. This aligns with best practices from foundational ontologies (like UFO) and the principles of Strict Distinction (A.7).
• Pragmatic and Actionable: The pattern is designed for engineers and managers. The Agency Grade provides a quick communication tool, while the underlying Agency-CHR provides the detailed, auditable data needed for formal assurance and risk management. This duality satisfies both Didactic Primacy (P-2) and Pragmatic Utility (P-7).

In essence, this pattern does not invent a new theory of agency. It distills and operationalizes the emerging scientific consensus, packaging it into a rigorous, falsifiable, and practical tool for the FPF ecosystem.

#Relations

• Builds on:
  • A.1 Holonic Foundation: Establishes that only U.Systems can be bearers of behavioral roles.
  • A.2 Role Taxonomy: Provides the universal Contextual Role Assignment (U.RoleAssignment) mechanism.
  • A.12 External Transformer: The actions of an Agent are modeled using the external transformer principle.
• Coordinates with:
  • B.2 Meta-Holon Transition (MHT): A significant jump in the Agency-CHR of a collective can trigger an MHT.
  • B.3 Trust & Assurance Calculus: The Agency-CHR profile provides crucial inputs for assessing the reliability and safety of an autonomous system.
  • D.2 Multi-Scale Ethics Framework: The Agency Grade is used to determine the level of moral responsibility and accountability assigned to a system.
• Instantiates:
  • The Agency-CHR (C.9), which provides the formal definitions for the characteristics (BMC, PH, etc.).

#A.13:End

#Advanced Mereology: Components, Portions, Aspects & Phases

#Context — why an advanced mereology?

FPF’s holonic modelling relies on part–whole relations to build structural and conceptual holarchies (systems and epistemes). But U.Holon is not synonymous with “mereological whole”: some holons (notably Roles and Methods) are bounded identity‑bearing objects whose primary composition is handled by other algebras (A.2 role algebra; A.15 method/description graphs), not by partOf. Early drafts distinguished structural vs. conceptual parthood (e.g., ComponentOf, ConstituentOf) but practical modelling kept hitting two recurrent gaps:

1. Quantities vs. parts. Engineers routinely need “some of the fuel”, “the first 10 pages”, “a 30% subset of data”. This is not a component; it is a portion of a stuff‑like whole, governed by measures and conservation.

2. Change vs. replacement. Authors need to say “the prototype before calibration”, “v2 of the spec”, “shift 1 vs. shift 2 of the same run”. That is not a new whole; it is a phase of the same carrier across time.

This section introduces two normative sub‑relations of partOf that close those gaps and lock them to the rest of the kernel:

• PortionOf — metrical, measure‑preserving parthood of stuffs and other measurables.
• PhaseOf — temporal parthood of the same carrier across an interval.

It also restates guard‑rails that keep Roles and Methods (as intensional masks/ways‑of‑doing) outside mereology (A.15), while allowing their describing epistemes (e.g., U.MethodDescription, U.WorkPlan) to use ordinary episteme parthood and versioning like any other U.Episteme. It also clarifies how MemberOf fits (preview: collections are grounded constructively in C.13 Compose‑CAL via Γ_m.set; collective agency/composition is handled outside A.14 via B.1.7 Γ_collective and A.15, not via partOf).

Publication note (Working‑Model first). Read A.14 together with E.14 Human‑Centric Working‑Model and B.3.5 CT2R‑LOG: publish relations on the Working‑Model surface; when assurance is sought, ground downward. For structural claims that require extensional identity, use the Constructive shoulder via Compose‑CAL Γ_m (sum | set | slice); order/time stay outside mereology (Γ_time / Γ_method).

#Problem — what breaks without these distinctions?

If we only have “generic partOf” (plus Component/Constituent), four classes of errors appear:

1. Conservation errors. Treating “20 L of fuel from Tank A” as a component leads to nonsense: adding and removing such “components” does not respect quantities; Γ_sys proofs violate Σ‑balance.

2. Temporal smearing. Flattening “before/after”, or “v1/v2” into one timeless whole collapses history; Γ_time and Γ_method cannot justify order‑sensitive properties; audits cannot reproduce conditions.

3. Identity confusion. Modelling “new version” as “new component” either breaks identity (it is still the same holon evolving) or hides a Meta‑Holon Transition when identity really changes.

4. Role leakage. Functional/organisational roles sneak into part trees (“the PumpRole is part of the plant”), violating A.15 and making structural reasoning brittle.

#Forces

#Solution — extend the mereology catalogue, keep it clean

A.14 defines two additional sub‑relations of partOf and re‑affirms the firewall between mereology and the role/recipe layer:

1. PortionOf — for measured parts of a whole (stuffs and other extensives).
2. PhaseOf — for temporal parts of the same carrier.
3. No Roles/Methods in mereology. U.Role and U.Method are never parts (A.15). A U.MethodDescription is an Episteme and may be versioned/structured; that does not make the described U.Method a part.
4. MemberOf stays, but constructive aggregation and agency live elsewhere. MemberOf remains available to state collections and collectives; a collection‑as‑whole may be constructed via Γ_m.set (Compose‑CAL, C.13), while collective agency/composition is handled in B.1.7 Γ_collective and A.15 (not in A.14).

The classical pair ComponentOf (structural, discrete) and ConstituentOf (conceptual, logical/epistemic) remain as in the kernel; A.14 only clarifies how to tell them apart from Portion/Phase (§ 6).

#Formal cores (normative semantics)

#PortionOf — metrical part of a measurable whole

Intent. Capture “some of the same stuff/extent”, governed by a measure that adds up.

Applicability. Any U.Holon that carries an extensive measure μ on the chosen scope (examples: mass, volume, length‑of‑text, byte size, wall‑time budget).

Primitive. PortionOf(x, y) means: x is the same kind of stuff/content as y, but less.

Axioms (A14‑POR‑*)

• POR‑1 (Partial order). PortionOf is reflexive, antisymmetric, transitive on its domain.
• POR‑2 (Metrical dominance). If x ProperPortionOf y then 0 < μ(x) < μ(y) for the agreed μ.
• POR‑3 (Additivity on disjoint portions). If x ⟂ y (no overlap) and both PortionOf y, then μ(x ⊔ y) = μ(x)+μ(y) and x ⊔ y PortionOf y.
• POR‑4 (Kind integrity). x and y must share the same measure kind and unit (or a declared conversion).
• POR‑5 (Boundary compatibility). For physical wholes, the whole’s boundary encloses the union of its portions; cross‑boundary “leaks” are interactions, not portions.

Didactic tests. ✔ “5 kg from a 20 kg billet” — PortionOf. ✔ “Pages 1–10 of the report” — PortionOf (μ = page or token count). ✘ “The pump module of the plant” — ComponentOf, not PortionOf. ✘ “The Methods section of the paper” — ConstituentOf, not PortionOf.

#PhaseOf — temporal part of the same carrier

Intent. Capture “the same holon during a sub‑interval”, preserving identity through change.

Applicability. Any U.Holon that persists across time with a recognised carrier identity.

Primitive. PhaseOf(x, y) means: x is y restricted to a proper time interval.

Axioms (A14‑PHA‑*)

• PHA‑1 (Partial order). PhaseOf is reflexive, antisymmetric, transitive (on the same carrier).
• PHA‑2 (Coverage). The whole is the union of its maximal, non‑overlapping phases over its lifetime interval.
• PHA‑3 (No paradoxical overlap). Phases of the same carrier do not overlap in time; overlapping variants require PhaseOf on aspects or different carriers.
• PHA‑4 (Identity through change). Properties may vary between phases, but the carrier’s identity criteria hold continuously (e.g., same serial number, same legal identity, same theorem statement).
• PHA‑5 (Escalation to MHT). If identity criteria break (e.g., metamorphosis with new objectives), declare a Meta‑Holon Transition (B.2) rather than a PhaseOf.

Didactic tests. ✔ “PumpUnit#3 before calibration” — PhaseOf(Pump#3_pre, Pump#3). ✔ “Spec v2” — PhaseOf(Spec_v2, Spec), on the MethodDescription artefact. ✔ “Shift 1 of the same batch run” — PhaseOf(Work_shift1, Work). ✘ “Prototype vs. production unit” — likely different carriers; use ComponentOf/ConstituentOf or MHT per criteria.

#CT2R‑LOG & Compose‑CAL handshake (normative link)

• Structural claims published on the Working-Model surface SHALL be justified, when assurance is required, by a Constructive grounding narrative using Γ_m.sum | Γ_m.set | Γ_m.slice and linked with tv:groundedBy (see B.3.5; C.13).
• PhaseOf is temporal parthood; it SHALL NOT be grounded via Γ_m. Its assurance follows identity‑through‑time criteria (CC‑PHA‑1..3) and Γ_time ordering (B.1.4).
• MemberOf remains non‑mereological (CC‑MEM‑2). When modelling a collection‑as‑whole for assurance purposes, the constructive basis is Γ_m.set; no ComponentOf inferences follow from MemberOf.

#Choosing the right relation (decision table)

Firewall reminder. If your sentence is about who does what, how it is done, or what happened when (role/method/run), you are likely in A.15. If it is about the document/artifact as a carrier (its pages/sections/versions), you may still be in A.14 (Episteme mereology).

#Archetypal grounding (System / Episteme)

#Conformance Checklist & type guards (normative)

#Global firewall and scope

#PortionOf guards

#PhaseOf guards

#Anchoring & validation (normative)

Note. Property names and trace semantics are defined in the CT2R‑LOG / Compose‑CAL.

#CT2R‑LOG handshake (Working‑Model → Assurance)

#CT2R‑LOG handshake (Working‑Model → Assurance)

#Validation patterns (author’s decision procedure)

Step 0 — Firewall check. If your sentence is about who does what, how it is done (role/method), or what happened when (run/work), you are not in mereology; go to A.15 (Role–Method–Work). If it is about the carrier episteme (pages/sections/versions of an SOP/algorithm/spec), you may still be in A.14.

Step 1 — Is it measured stuff? If yes, pick PortionOf. Confirm μ is declared (CC‑POR‑1/2). Test additivity on a toy split (CC‑POR‑3). If flows cross a boundary, remodel as interactions, not portions (CC‑POR‑4).

Step 2 — Is it a discrete inside part? If yes, pick ComponentOf (physical) or ConstituentOf (conceptual). Do not use PortionOf here.

Step 3 — Is it the same carrier at a time slice? If yes, pick PhaseOf. Verify identity criteria and non‑overlap (CC‑PHA‑1/2/3). If criteria break, escalate to B.2 (CC‑PHA‑4).

Step 4 — Is it a membership statement? Use MemberOf only; avoid any part‑inferences (CC‑MEM‑2). If you need a collection as a whole, use C.13 (Γ_m.set) for constructive grounding. If you need collective action, defer to A.15.

Quick spot‑tests (repair kit).

#Interplay with Γ‑flavours (how these relations behave under aggregation)

#Consequences

Benefits

• Predictable composition. Σ‑additivity for portions and identity‑through‑time for phases make Γ‑proofs straightforward.
• History without confusion. Temporal slicing is explicit and audit‑ready; no paradoxical overlaps.
• Cleaner integration with roles and recipes. The firewall prevents “functional object” creep into structure.
• Compatibility with engineering practice. Mirrors product breakdown (components) vs functional breakdown (roles) vs material stocks (portions) vs versioning (phases).

Trade‑offs / mitigations

• Modelling energy. Authors must pick μ and declare units; provide a short μ‑catalog per project.
• More relation names. Two extra sub‑relations increase vocabulary; mitigated by the decision table (§ 6) and spot‑tests (§ 9).
• Escalation discipline. Deciding PhaseOf vs MHT requires judgement; A.14 provides criteria, and B.2 captures true re‑identification.

#Pedagogy aids (non‑normative)

Two‑minute checklist for reviewers

1. Do I see “process/workflow/policy/script” used to mean enactment? — then A.15. If it names a carrier episteme whose structure/version is being discussed, A.14 may apply.
2. Does every PortionOf have a declared μ and unit?
3. Do phases cover a lifetime without overlap for the same aspect?
4. Are any roles/recipes appearing as parts? If yes, stop and refactor.

#Patch map (where to touch in the working file)

1. Kernel - Holonic Mereology (§ A.1 → A.14) Add sub‑sections “PortionOf” and “PhaseOf” with axioms (POR‑1..5, PHA‑1..5). Move MemberOf note to a minimal semantics paragraph (no composition here).

2. A.15 (Role–Method–Work) Cross‑link firewall (CC‑A14‑0/0b) and reinforce that versioning uses PhaseOf only on MethodDescription/Work.

3. B.1.2 Γ_sys / B.1.3 Γ_epist / B.1.4 Γ_ctx/Γ_time / B.1.5 Γ_method / B.1.6 Γ_work Insert a one‑line “A.14 compliance” note: which A.14 sub‑relations each flavour relies on, as in § 10.

4. Examples & Annexes Refactor any “percentage as part” examples into PortionOf with declared μ; Split any overlapping histories into PhaseOf sequences.

Each edited heading should carry the badge “► decided‑by: A.14 Advanced Mereology”.

#Rationale (state‑of‑the‑art alignment, post‑2015)

• Metrical mereology advances (e.g., recent work on quantity‑based parthood and additivity) motivate PortionOf with explicit μ and Σ‑laws, preventing the classic “stuff as components” fallacy.
• Temporal parts & identity through change (renewed treatments in analytic metaphysics and formal ontology) motivate PhaseOf with coverage/non‑overlap and escalation when identity criteria fail.
• Engineering ontologies (BORO lineage, Core Constructional practice, ISO 15926 family) keep a strict separation between functional breakdowns (our Roles) and product breakdowns (our Components), with stock/consumable modelling (our Portions) handled by quantities, not by component trees.
• Knowledge artefact lifecycles in contemporary MBSE and open‑science workflows use explicit versioning (our PhaseOf) and provenance‑preserving composition (our ConstituentOf).
• The net effect is a minimal‑sufficient catalogue: two added sub‑relations close real modelling gaps while preserving parsimony, didactic clarity, and Γ‑compatibility across domains.

#A.14:End

#Role–Method–Work Alignment (Contextual Enactment)

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative

At a glance. This pattern is the entry-bearing alignment surface for engineer-managers when the real confusion is not "what component is this" but who is responsible, how the work is supposed to happen, when the plan lives, and what actually happened.

Start here when. The dominant ambiguity is role vs method vs schedule vs actual run, and the team keeps arguing about a "process" without separating recipe, plan, capability, and executed work.

First output. One explicit Role / Method / MethodDescription / WorkPlan / Work separation, plus one traceable chain from U.RoleAssignment through the governing method description to the actual or intended work surface.

Typical next owners. A.15.1 for dated execution, A.15.2 for schedule/baseline planning, A.15.3 for slot-filling plan items, B.5.1 for the simple lifecycle reading, F.11 when method/work vocabulary itself must be aligned across contexts, and F.17 when the result should land on a human-facing work sheet.

Common wrong escalations / reroutes. If the first honest artefact is still only a cue, reroute to A.16 / A.16.1; if the burden is boundary language or contract soup, reroute to A.6; if you only need one executed occurrence rather than the alignment frame, continue straight to A.15.1.

#Problem frame

In any complex system, from a software project to a biological cell, there is a fundamental distinction between what something is (its structure), what it is supposed to do (its role and specified capability), and what it actually does (its work). Confusing these layers is a primary source of design flaws, budget overruns, and failed projects. Teams argue about a "process" without clarifying if they mean the documented procedure, the team's ability to execute it, or a specific execution that happened last Tuesday.

This pattern provides the canonical alignment for modeling contextual enactment in FPF, serving as the ultimate implementation of the Strict Distinction Principle (A.7). It weaves together several foundational concepts into a single, coherent model of how intention becomes action:

• A.2 (Contextual Role Assignment): Provides the Holder#Role:Context structure for assigning roles.
• A.4 (Temporal Duality): Provides the strict separation between design-time and run-time.
• A.12 (External Transformer): Ensures that all actions are attributed to an external agent.

The intent of this pattern is to establish a normative, unambiguous vocabulary and set of relations for describing the entire evolution of an action, from the specification of a capability to its concrete, resource-consuming execution.

To keep plan-run separation explicit, this pattern references A.15.2 U.WorkPlan for schedules/calendars and A.15.1 U.Work for dated execution. Ambiguous terms like "process / workflow / schedule" are constrained by L-PROC / L-FUNC / L-SCHED (E-cluster): a workflow is a Method/MethodDescription, a schedule is a WorkPlan, and what happened is Work.

Terminology note (L-ACT). The words action/activity are not normative in the kernel. When a generic "doing" is needed, we use the didactic term enactment (not a type). Normative references must be to U.Method / U.MethodDescription / U.Work / U.WorkPlan. See lexical rules L-PROC / L-FUNC / L-SCHED / L-ACT.

#Problem

Without this formal framework, models suffer from a cascade of category errors:

1. Role-as-Part: A Role (e.g., AuditorRole) is incorrectly placed inside a structural bill-of-materials (ComponentOf), making the system's architecture brittle and nonsensical.
2. Specification-as-Execution: A MethodDescription (the "recipe") is treated as evidence that the work was done. This leads to "paper compliance," where a system is considered complete simply because its documentation exists.
3. Capability-as-Work: A team's ability to perform a task (Capability) is conflated with the actual performance of that task (Work). This obscures the reality of resource consumption and actual outcomes.
4. Work-without-Context: An instance of work is logged without a clear link back to the role, capability, and specification that governed it, making the work unauditable and its results impossible to reproduce.
5. Ambiguous "Process/Activity": The overloaded term "process" is used indiscriminately to refer to all of the above, creating a fog of miscommunication that paralyzes decision-making. Activity/action terms must be resolved via L-ACT to Method/MethodDescription (recipe), WorkPlan (schedule), or Work (run).

#Forces

#Solution

The solution is a stratified alignment that cleanly separates the design-time and run-time for contextual enactment. The bridge between these worlds is the U.RoleAssignment.

#The Core Entities: A Strict Distinction

FPF mandates the use of the following distinct, non-overlapping entities to model action. Using them interchangeably is a conformance violation.

A) Design-Time Entities (The World of Potential):

• U.Role: A contextual "mask" or "job title" (e.g., TesterRole). It specifies a function but is not the function itself.
• U.Method: The abstract way-of-doing inside a context (paradigm-agnostic; may be imperative, functional, logical, or hybrid).
• U.MethodDescription: A U.Episteme describing a U.Method (the SOP/algorithm/proof/recipe on a carrier).
• U.Capability: An attribute of a U.System that represents its ability to perform the actions described in a MethodDescription. This is the "skill" or "know-how."
• U.WorkPlan: An U.Episteme declaring intended U.Work occurrences (windows, dependencies, intended performers as role kinds, budgets) - see A.15.2.

B) The Bridge Entity:

• U.RoleAssignment: The formal assertion Holder#Role:Context that links a specific U.Holon to a U.Role within a U.BoundedContext. This holder-to-role assignment link is what "activates" the requirements associated with a role.

C) Run-Time Entity (The World of Actuality):

• U.Work: An occurrence or event. It is the concrete, dated, resource-consuming execution of a U.MethodDescription by a Holder acting under a U.RoleAssignment; capability checks are evaluated at run time against the holder. This is the only entity that has a start and end time and consumes resources.

Kinds of Work and the primary target Every U.Work SHALL declare a primaryTarget: U.Holon and a kind. Kinds:

• Operational - transforms a U.System or its environment.
• Communicative (SpeechAct) - transforms a deontic/organizational frame (e.g., commitments, permissions, approvals).
• Epistemic - transforms a U.Episteme (e.g., curating a dataset). The primaryTarget disambiguates enactment: what is being acted upon. Example: an approval is kind=Communicative, primaryTarget = Commitment(change=4711). A deployment is kind=Operational, primaryTarget = ServiceInstance(prod-us-eu-1).

Didactic Note for Managers: The "Chef" Analogy

This model can be easily understood using the analogy of a chef in a restaurant.

• ChefRole is the Role. It's a job title with certain expectations.
• A Cookbook (U.MethodDescription) contains the recipe for a Souffle. It's a piece of knowledge.
• The chef's skill in making souffles is their U.Capability. They have this skill even when they are not cooking.
• The restaurant's rulebook (U.BoundedContext) states that anyone in the ChefRole must have the Capability to follow the recipes in the cookbook.
• The actual act of making a souffle on Tuesday evening - using eggs and butter, taking 25 minutes, and consuming gas - is the U.Work.

Confusing these is like mistaking the cookbook for the souffle. FPF's framework simply makes these common-sense distinctions formal and mandatory.

#The Canonical Relations: Connecting the Layers

The entities are connected by a set of precise, normative relations that form an unbreakable causal chain. The following diagram illustrates this flow from the abstract context down to the concrete execution.

graph TD
    subgraph Design-Time Scope (Tᴰ)
        A[U.BoundedContext] -- defines --> B(U.Role)
        M[U.Method] -- isDescribedBy --> D[U.MethodDescription]
        Cap[U.Capability] -- supports --> M
        H(U.System as Holder) --> RB(U.RoleAssignment)
        B -- is the role in --> RB
        A -- is the context for --> RB
        A -- bindsCapability(Role,Capability) --> Cap
    end

    subgraph Run-Time Scope (Tᴿ)
        W[U.Work]
    end

    RB -- performedBy --> W
    W  -- isExecutionOf --> D

    style A fill:#e6f3ff,stroke:#36c,stroke-width:2px
    style B fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style Cap fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style M fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style D fill:#f8cecc,stroke:#b85450,stroke-width:2px
    style H fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    style RB fill:#dae8fc,stroke:#6c8ebf,stroke-width:3px,stroke-dasharray: 5 5
    style W fill:#ffe6cc,stroke:#d79b00,stroke-width:2px,font-weight:bold

• bindsCapability(Role, Capability): A U.BoundedContext asserts that a given Role requires a specific Capability. This is a design-time rule.
• isDescribedBy(Method, MethodDescription): A U.Method is formally described by one or more MethodDescriptions. This links the abstract way-of-doing to the recipe on a carrier.
• isExecutionOf(Work, MethodDescription): A specific U.Work is a run-time realization of a design-time MethodDescription. Capability checks are evaluated against the holder at run time.
• performedBy(Work, RoleAssignment): A U.Work is always performed by a specific Agent (a U.RoleAssignment). This links the action to the actor-in-context.

At run time, capability thresholds declared by the context/spec are checked against the holder; U.Work outcomes provide evidence for capability conformance.

This chain provides complete traceability: a specific instance of U.Work can be traced back to the U.MethodDescription that governed it, the U.Method it describes, and the Agent (Holder + Role + Context) that was authorized and responsible for its execution.

#Bounded specialization scouting and CheckpointReturn

When one human-plus-AI pair faces a new task family or candidate solution corridor, the governed work system may temporarily compose four distinct local roles inside the same dyad: a human-side UtilityOwnerRole, an AIScoutRole, an AISpecialistProbeRole, and a human-side CommitAuthorityRole. The payoff of the dyad is faster lawful specialization of the next move, not disappearance of the human decision surface.

For this bounded burden, the pair should declare one utility target first, enumerate heterogeneous candidate approaches that may satisfy that target, spend a bounded scout or probe budget before any committed route is chosen, and return one CheckpointReturn that compares the tested approaches rather than silently treating one successful probe as a committed rollout. A.15 owns this dyadic move and local role split only; it does not re-own the checkpoint-record semantics of C.24 or the budget/guard enforcement of E.16.

Every CheckpointReturn should carry:

• the declared utility target and current TaskFamily
• the candidate approaches actually tested
• the evidence observed on each tested approach, including progress toward the named work-measure threshold and important failure signals
• the budget already burned and the residual budget still available
• the recommended next action: continue probing, commit, narrow, hand off, or stop
• the exact commit trigger that would justify leaving the probe state

Low-human-overlap approaches remain admissible here only while they stay tied to the declared utility target, budget guard rails, and evidence basis by value.

#Archetypal Grounding

The Contextual Action Framework is universal. It applies identically to the modeling of physical engineering processes, knowledge work, and socio-technical systems.

Key takeaway from grounding: This side-by-side comparison reveals the power of the framework. A seemingly different activity like welding a car chassis and reviewing a scientific paper are shown to have the exact same underlying causal structure. Both involve a Holder (a system) acting in a Role within a Context, using a Capability described by a MethodDescription to produce a specific, auditable instance of Work. This universality is what allows FPF to bridge disparate domains.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for contextual enactment across engineering, operational, and knowledge-work settings.

Bias risks and mitigations:

• Governance bias (Gov): teams may over-treat role or approval surfaces as enough evidence that work happened. Mitigation: keep U.RoleAssignment, U.MethodDescription, U.WorkPlan, and U.Work distinct, and let only U.Work carry actuals and resource use.
• Architectural bias (Arch): modelers may pull roles or capabilities into structural part hierarchies because those diagrams are already present. Mitigation: preserve role and capability as contextual-functional entities, not parts.
• Epistemic bias (Onto/Epist): a documented recipe or schedule can be mistaken for proof of execution. Mitigation: require the traceability chain from U.RoleAssignment and U.MethodDescription to dated U.Work.
• Pragmatic bias (Prag): teams may keep using one overloaded "process" word because it feels faster. Mitigation: resolve "workflow / schedule / what happened" through U.Method / U.MethodDescription, U.WorkPlan, and U.Work.
• Didactic bias (Did): the chef analogy can make the pattern seem intuitive while hiding the need for explicit model links. Mitigation: pair the analogy with the canonical relations and checklist.

#Conformance Checklist

To ensure the integrity of action modeling, all FPF-compliant models must adhere to the following normative checks.

#Common Anti-Patterns and How to Avoid Them

• Role-as-part. Do not place U.Role or U.Capability inside structural partOf decomposition; keep them contextual and functional.
• Recipe-as-evidence. Do not treat a U.MethodDescription or SOP as proof that work occurred; record dated U.Work instead.
• Plan-as-actual. Do not let schedules, calendars, or intended assignments stand in for actual execution; use U.WorkPlan for intent and U.Work for actuals.
• Capability-as-work. Do not treat possession of a capability as if the task has already been performed; capability supports execution but is not execution.
• Approval collapse. Do not merge approval or authorization speech acts into the operational step they open; model them as distinct communicative U.Work when they change authority state.
• Process soup. Do not leave "process / workflow / activity" uninterpreted in load-bearing passages; resolve the word to method, plan, or work.

#Consequences

#Rationale

This pattern solves a problem that has plagued systems modeling for decades: the conflation of what a system is with what it does. Its rigor is not arbitrary but is grounded in several key intellectual traditions.

• Ontology Engineering: The pattern is a direct application of best practices from foundational ontologies (like UFO), which have long insisted on the distinction between endurants (objects like a U.System) and perdurants (events/processes like U.Work), and between intrinsic properties and relational roles. FPF makes these powerful distinctions accessible to practicing engineers.
• Process Theory: Formalisms like the Pi-calculus or Petri Nets model processes as dynamic interactions. The FPF Contextual Action Framework provides a higher-level, more semantically rich layer on top of such formalisms. The U.Work entity can be seen as an instance of a process, but FPF adds the crucial context of the Role, Capability, and MethodDescription that govern it.
• Pragmatism and Practice: The framework is deeply pragmatic. The distinctions it makes (e.g., between a MethodDescription and U.Work) are precisely the ones that matter in the real world of project management, compliance, and debugging. When a failure occurs, a manager needs to know: was the recipe wrong (MethodDescription), did the chef lack the skill (Capability), or did they just make a mistake this one time (U.Work)? This framework provides the vocabulary to ask and answer that question precisely.

By creating this clean, stratified alignment for enactment, FPF provides a stable and scalable foundation for all of its more advanced patterns, from resource management (Resrc-CAL) and decision theory (Decsn-CAL) to ethics (Norm-CAL).

#SoTA-Echoing

Claim 1. Best-known current workflow, digital-thread, and service-operations practice keeps recipe, plan, and execution separate.

Practice / source / alignment / adoption. Contemporary process modeling, service operations, and auditability practice after 2015 separates procedure, schedule, and executed occurrence because otherwise paper compliance becomes indistinguishable from completed work. In the manufacturing and peer-review slices above, this means a procedure or calendar never counts as the weld or the review itself. This pattern adopts that separation, adapts it through U.Method, U.MethodDescription, U.WorkPlan, and U.Work, and rejects the shortcut where one undifferentiated "process" object carries all three loads.

Claim 2. Best-known current accountability practice keeps actor-in-context explicit rather than attributing work to a role label or a document.

Practice / source / alignment / adoption. Contemporary governance, service delivery, and incident practice distinguishes accountable assignee, governing procedure, and actual run record because post-hoc review depends on knowing who acted, under what role, and under which method. In the slices above, that is why the robot or reviewer acts under U.RoleAssignment rather than the role or guideline acting on its own. This pattern adopts explicit actor-in-context attribution through U.RoleAssignment, adapts it to bounded-context semantics, and rejects anonymous work logs and role-as-part modeling.

Claim 3. Best-known current approval and execution practice treats communicative gate acts and operational acts as distinct kinds of work.

Practice / source / alignment / adoption. Contemporary release, compliance, and safety-critical practice separates approval, authorization, and review acts from the operational steps they permit because authority change and world change are not the same event. In the examples above, that means an approval is not the same work as a deployment or a weld. This pattern adopts that split, adapts it through communicative versus operational U.Work kinds, and rejects the collapse of approval into the thing being approved.

Local stance. The load-bearing SoTA claim for this pattern is practical and narrow: contextual enactment remains reviewable only when role, method, plan, and work stay distinct enough that audits can tell whether the problem was in the assignment, the recipe, the schedule, the capability, or the run itself.

Claim 4. Best-known current agentic work practice treats fast bounded specialization as a checkpointed scout/probe discipline rather than as a naked winner claim.

Practice / source / alignment / adoption. Contemporary agentic tool-use, adaptive workflow, and human-in-the-loop governance practice separates bounded exploration from committed rollout because a successful probe is not yet a lawful route choice. In the working moment above, that is why the pair returns one CheckpointReturn with candidate approaches, evidence, burned and residual budget, and a commit trigger rather than only a winner label. This pattern adopts checkpointed scout/probe discipline, adapts it through the dyad-local roles and CheckpointReturn, and rejects the shortcut where an early probe silently becomes a committed rollout.

#Relations

• Directly Implements: A.7 Strict Distinction.
• Builds Upon: A.2 (U.Role), A.2.1 (U.RoleAssignment), A.4 (Temporal Duality), A.12 (External Transformer).
• Is Used By / Provides Foundation For:
  • C.4 Method-CAL: Provides the formal definition of U.MethodDescription and the Gamma_method operator for composing them.
  • C.5 Resrc-CAL: Provides the U.Work entity to which resource consumption is attached.
  • B.1.6 Gamma_work: The aggregation operator for U.Work.
  • B.4 Canonical Evolution Loop: The entire loop is a sequence of U.Work instances that modify MethodDescriptions.
  • A.15.2 U.WorkPlan: plan-run split, baselines and variance against U.Work.
• Constrains: Any FPF pattern that models actions or processes must use this framework to be conformant. It serves as the canonical alignment for contextual enactment in the FPF ecosystem.
• Coordinates with: L-PROC / L-FUNC / L-SCHED (E-cluster) for lexical disambiguation of process / workflow / schedule.

#A.15:End

#U.Work

#Problem Frame

After we have agreed who is assigned (via Role assignment), what they can do (via Capability), and how in principle it should be done (via Method/MethodDescription), we still need a precise concept for what actually happened in real time and space.

That concept is U.Work: the dated run‑time occurrence of enacting a MethodDescription by a specific performer under a Role assignment, with concrete parameter bindings, resource consumption, and outcomes, anchored to a domain referent that actually changes (asset/product/dataset) — not merely the manipulation of records about that referent. Managers care about Work because it is the only place where cost, time, defects, and evidence are real. Architects care because Work ties plans and specs to accountable execution.

#Problem (what breaks without a clean notion of Work)

1. Plan/run confusion. Schedules and diagrams get mistaken for “the process,” so audits and KPIs become fiction.
2. Spec/run conflation. A method description (code/SOP) is reported as if it were an execution; conversely, logs are treated as recipes.
3. Who/when leakage. People and calendars are baked into specs; reuse and staffing agility collapse.
4. Resource dishonesty. Energy/money/tool wear are booked to methods or roles, not to actual runs; costing and sustainability metrics drift.
5. Mereology muddle. Teams hand‑wave over “sub‑runs,” retries, overlaps, or long‑running episodes; roll‑ups double‑count or miss work.

#Forces (what the definition must balance)

#Solution — define U.Work as the accountable, dated occurrence

#Definition

U.Work is a 4D occurrence holon: a dated run‑time enactment of a U.MethodDescription by a performer designated through a U.RoleAssignment, executed within a concrete U.System/SubSystem, inside a U.BoundedContext, that binds concrete parameters, consumes/produces resources, and leaves an auditable trace. Each U.Work is a morphism Δ on a declared state‑plane (StatePlaneRef), mapping ⟨pre‑state, inputs⟩ to ⟨post‑state, outputs⟩ for one or more affected referents.

Memory aid: Work = “how it went this time” (dated, resourced, accountable).

#Core anchors (conceptual descriptors; not a data schema)

When you describe a Work instance in a review, answer these prompts:

1. Window — start/end timestamps (and, where relevant, location/asset).
2. Spec — isExecutionOf → U.MethodDescription (the description actually followed; edition pinned if applicable).
3. Performer — performedBy → U.RoleAssignment (which holder#role:context acted).
4. Parameters — concrete values bound for this run (from the MethodDescription parameter declarations).
5. Inputs/Outputs — material/information artifacts read/written, products/services delivered.
6. Resources — energy, materials, machine time, money (the only place we book them).
7. Outcome — success/failure classes, quality measures, acceptance verdicts (map‑then‑compare per ComparatorSet under CG‑Spec; pin editions).
8. Links — predecessor/successor/overlap relations to other Work, and step/run nesting (if part of a bigger operation).
9. Context — the bounded context(s) under which this run is judged (normally inherited from the MethodDescription and RoleAssigning; see A.15 for cross‑checks).
10. Effect (Δ) — affected → {referent(s)} + pre‑state anchor and post‑state anchor (or a declared Δ‑predicate evaluated on evidence) on the declared state‑plane (StatePlaneRef).
11. System — executedWithin → U.System (the operational system/sub‑system accountable for the occurrence; mandatory).
12. Evidence & Telemetry (optional) — if the run feeds G.11 refresh or QD/OEE archives, cite PathId/PathSliceId and the active policy‑id used for illumination; do not elevate telemetry into dominance without CAL policy.

#Clear distinctions (the four‑slot grammar in action)

#Publication (MVPK guard‑rails for U.Work) — normative

Publication of U.Work across MVPK faces must be a typed projection that does not mutate intensional semantics (A.7; E.17). Concretely:

1. No new claims. Faces (PlainView / TechCard / InteropCard / AssuranceLane) SHALL NOT introduce properties beyond the U.Work intensional arrow; they project presence‑pins only (time window, performer, spec, parameter‑binding occurrence, resource ledger presence, acceptance verdict presence). Numeric/comparable content appears only with pins (see 4.4‑4.5 below); “signature” is banned on faces.
2. No Γ‑leakage. Faces MUST NOT smuggle Γ semantics (union/hull/overlap policy, budget algebra) into prose; whenever aggregation is shown, the face cites the Γ‑operator and policy‑id used. Compute totals outside the face per B.1; faces carry references, not implied Γ rules.
3. No I/O re‑listing. Per MVPK, faces do not duplicate intensional I/O lists. They show presence‑pins and anchors to carriers/lanes/editions only (E.17 §5.4).
4. Lawful orders (sets). Where a U.Work face presents any comparison or ranking across runs (e.g., acceptance classes, parity/benchmark inserts), the face must: (i) compare after mapping via a declared ComparatorSet; (ii) return sets (Pareto/Archive) when order is partial; (iii) forbid hidden scalarization/ordinal means (cf. G.9).
5. Comparator/Transport edition pins. Any numeric/comparable statement on a U.Work face MUST pin the CG‑Spec/ComparatorSet edition(s) and, where scale/plane conversion occurs, the UNM.TransportRegistry edition (Φ/Φ^plane policy‑ids). Cross‑context/plane crossings route penalties to R‑lane only (Bridge id + Φ) (cf. E.17; G.9).
6. Cross‑stance citations. Any citation whose stance differs from the citing U.Work face (different DesignRunTag, ReferencePlane, or CtxState.locus) MUST carry BridgeCard + UTS row (with locus/plane notes and CL routing).
7. No surrogate‑run creation. Faces MUST NOT synthesize “virtual runs” from reconstructed records alone; a face may reference only U.Work instances that meet Δ‑anchoring in §4.2/§8.

#Crossing visibility & stance tags (work publication discipline) — normative

• Stance. U.Work is a run-time occurrence (DesignRunTag = run). Any face that cites design-time artefacts (e.g., ComparatorSet, CG-Spec editions, TransportRegistryΦ) is making a cross-stance/cross-Context reference and therefore MUST publish a BridgeCard + UTS row and record Φ(CL)/Φ^plane policy-ids; penalties reduce R_eff only.
• Binding discipline. Launch values bind only here (occurrence). Plan-time proposals remain proposals; do not back-fill plan faces with run-time bindings. Pre/post state anchors bind here (pre at start; post at completion or at declared checkpoints).

#Work mereology (how runs form holarchies)

We adopt a 4D extensional stance for occurrences: a Work is identified primarily by its spatiotemporal extent and its execution anchors (spec used, performer, parameterization). This avoids double‑counting and keeps aggregation sound. FPF adapts insights from BORO/constructive ontologies to Work while staying practical.

#Parts and wholes of Work (design‑neutral, run‑time facts)

• Temporal‑part (TemporalPartOf_work). A proper time‑slice of a Work (e.g., the first 10 minutes of a 2‑hour run). Useful for monitoring and SLAs.
• Episode‑part (EpisodeOf_work). A resumption fragment after an interruption (same run identity if policy deems it one episode; see 5.5).
• Operational‑part (OperationalPartOf_work). A sub‑run that enacts a factor of the Method/Spec (e.g., “incision” run within “appendectomy” run), possibly overlapping with others in time.
• Parallel‑part (ConcurrentPartOf_work). Two sub‑runs that overlap in their windows, coordinated by the same higher‑level run.

Didactic rule: Method composition ≠ proof of Work decomposition. Sub‑runs often map to method factors, but retries, batching, pipelining, and failures make the mapping non‑isomorphic.

#Key relations among Work

• precedes/happensBefore — strict partial order on Work windows.
• overlaps — intervals intersect but neither contains the other.
• contains/within — one Work’s window contains another’s.
• causedBy/causes — pragmatic causal links (e.g., a rework caused by a failed inspection run).
• retryOf — a new Work instance re‑attempting the same MethodDescription with revised parameters.
• resumptionOf — a Work episode that continues an interrupted run (policy decides identity; see 5.5).

These relations are run‑time facts, not design assumptions.

#Operators for roll‑ups (Γ\time and Γ\work)

• Temporal coverage — Γ_time(S) For a set S of Work parts, returns a coverage interval set (union of intervals) or, when required, the convex hull [min t₀, max t₁]. Use union for utilization; use hull for lead time. Properties: idempotent, commutative, monotone under set inclusion.

• Resource aggregation — Γ_work(S) For a set S of Work parts, returns the aggregated resource ledger (materials, energy, time, money) with de‑duplication rules for shared/overlapped parts (context‑declared). Properties: additive on disjoint parts; requires overlap policy otherwise (e.g., attribute costs to the parent once, not to each child).

Manager’s tip: Pick the coverage operator that matches your KPI: union for machine utilization; hull for calendar elapsed; never mix silently.

#Identity of a Work (extensional criterion, pragmatically framed)

Two Work records refer to the same Work iff, in the relevant context:

• their time–space extent is the same (within declared tolerance),
• they link to the same MethodDescription,
• they have the same performer (U.RoleAssignment), and
• they bind the same parameters (or declared‑equivalent values).

If any of these differ (or the context declares equivalence absent), they are distinct Work instances (e.g., a retry).

#Interruptions, retries, resumptions (episode policy)

• Retry: new Work with its own window and parameters; link via retryOf.
• Resumption: same Work identity split into episodes if the context’s episode policy declares so (e.g., “power loss under 5 minutes keeps identity”).
• Rework: new Work caused by a failure in earlier Work; link via causedBy.

Why it matters: plans, costs, and quality stats depend on whether you treat a disruption as one episode or a new run. Declare the policy in the bounded context.

#Compositionality of effects (Δ)

For any Work with parts, the effect of the whole must be the rules‑declared composition of the effects of its parts plus any declared overheads/residuals. Composition must align with the overlap rules used by Γ_work (e.g., no double‑count of shared fixed costs, and consistent attribution of variable deltas).

#Archetypal grounding (parallel domains)

#Surgical case (overlap and episodes)

• Top run: Appendectomy_Case#2025‑08‑10T09:05–11:42.
• Spec: Appendectomy_v5 (MethodDescription).
• Performer: OR_Team_A#SurgicalTeamRole:Hospital_2025 (RoleAssigning).
• Operational parts: Incision (09:15–09:22), Exploration (overlaps with monitoring), Closure (11:10–11:35).
• Episode: brief power dip 10:02–10:07 → resumptionOf same run (per hospital policy).
• Γ_time: union for OR utilization; hull for patient lead time.
• Γ_work: totals consumables and staff time once (no double‑count for overlapping sub‑runs).

#ETL pipeline (parallelism and retries)

• Top run: ETL_Nightly_2025‑08‑11T01:00–01:47.
• Spec: ETL_v12.bpmn.
• Performer: ETL_Runtime#TransformerRole:DataOps_2025.
• Parallel parts: Extract_A ‖ Extract_B; Transform starts when either completes (overlap).
• Retry: Load failed at 01:36; retried with batch size ↓ — new Work linked via retryOf.
• Γ_time: hull for SLA, union for cluster utilization.
• Γ_work: sum compute minutes; attribute storage I/O once at the parent.

#Thermodynamic cycle (work as a path)

• Run: Carnot_Cycle_Run#2025‑08‑09T13:00–13:06.
• Spec: Carnot_Cycle_Spec (MethodDescription with Dynamics model).
• Performer: LabRig_7#TransformerRole:ThermoLab.
• Work identity: the path in state‑space traced during the interval; outputs: heat/work tallies.
• Γ_time: straightforward interval; Γ_work: integrates energy exchange; no “steps” required.

#Bias‑Annotation (as in E‑cluster)

• Lenses tested: Prag, Arch, Did, Epist.
• Scope declaration: Universal; temporal semantics and episode policy are context‑local via U.BoundedContext.
• Rationale: Gives FPF a clean, actionable notion of occurrence compatible with U.RoleAssignment / Role Enactment (A.2.1; A.15) and with 4D extensional thinking, so that costing, quality, and audit rest on runs, not on plans or recipes.

#Conformance Checklist (normative)

CC‑A15.1‑1 (Strict distinction). U.Work is a dated run‑time occurrence. It is not a U.Method (semantic way), not a U.MethodDescription (description), not a U.Role/RoleAssigning (assignment), and not a U.WorkPlan (plan/schedule).

CC‑A15.1‑2 (Required links). Every U.Work MUST reference: (a) isExecutionOf → U.MethodDescription (the spec followed; edition pinned), (b) performedBy → U.RoleAssignment (the assigned performer in context), and (c) executedWithin → U.System/SubSystem (the operational system accountable for the occurrence).

CC‑A15.1‑3 (Time window). Every U.Work MUST carry a closed interval [t_start, t_end] (or an explicitly marked open end for in‑flight work) and, where relevant, location/asset.

CC‑A15.1‑4 (Context anchoring & judgement). A U.Work MUST be judged inside a declared U.BoundedContext (the judgement context).

• By default, the judgement context is the context of the referenced MethodDescription.
• If performedBy references a RoleAssigning in a different context, there MUST exist an explicit Bridge (U.Alignment) or policy stating cross‑context acceptance. Otherwise, the Work is non‑conformant in that context.

CC‑A15.1‑4b (State‑plane anchoring). Each U.Work MUST declare a StatePlaneRef for its Δ‑judgement.

CC‑A15.1‑5 (RoleAssigning validity). The performedBy RoleAssigning’s timespan MUST cover the Work interval. If it does not, the Work is invalid or must be re‑judged in a context that allows retroactive assignments.

CC‑A15.1‑6 (Parameter binding). Parameters declared by the MethodDescription MUST have concrete values bound at Work creation/start and recorded with the Work. Defaults in the spec do not satisfy this requirement.

CC‑A15.1‑7 (Capability check). All capability thresholds stated by the Method/MethodDescription MUST be checked against the holder in performedBy at the time of execution (or at defined checkpoints). Violations must be flagged on the Work outcome.

CC‑A15.1‑8 (Acceptance criteria). Success/failure and quality grades MUST be determined by the acceptance criteria declared (or referenced) by the MethodDescription/CG‑Spec in the judgment context. The verdict is recorded on the Work.

CC‑A15.1‑9 (Resource honesty). All consumptions and costs (energy, materials, machine‑time, money, tool wear) SHALL be booked only to U.Work (not to Method, MethodDescription, Role, or Capability). Estimates may live in specs; actuals live in Work.

CC‑A15.1‑10 (Mereology declared). If a Work has parts, the chosen part relation(s) must be declared (temporal‑part, episode‑part, operational‑part, concurrent‑part). Ambiguous mixtures are forbidden.

CC‑A15.1‑11 (Γ_time selection). For any roll‑up, the judgement context MUST declare which temporal coverage operator applies: union (utilization) or convex hull (lead time). Silent mixing is prohibited.

CC‑A15.1‑12 (Γ_work aggregation). Aggregation of resource ledgers across Work parts MUST specify an overlap policy (e.g., “attribute shared machine‑time to parent only”) to prevent double‑counting.

CC‑A15.1‑13 (Identity & retries). A retry MUST be modeled as a new Work linked via retryOf. Interruptions that are treated as the same run must be modeled as episodes (resumptionOf) per a context‑declared episode policy.

CC‑A15.1‑14 (Concurrency & ordering). Overlaps and precedences among Work MUST use interval relations (overlaps, precedes, contains/within). Implicit “step order” claims are not admissible evidence.

CC‑A15.1‑15 (Cross‑context evidence). If a Work is to be accepted in multiple contexts (e.g., regulatory + operational), either: (a) re‑judge it in each context, or (b) provide Bridges that map acceptance criteria/units/roles; never assume cross‑context identity by name.

CC‑A15.1‑16 (Spec changes during run). If the MethodDescription version changes mid‑run, the Work MUST either: (a) split into episodes bound to respective specs, or (b) record an explicit spec override event in the judgement context. Silent substitution is forbidden.

CC‑A15.1‑17 (Distributed performers). If multiple RoleAssignings jointly perform the same top‑level Work (e.g., multi‑agent orchestration), the Work MUST either: (a) designate a lead RoleAssigning and list others as concurrent parts, or (b) be modeled as a parent Work with child Works per RoleAssigning.

CC‑A15.1‑18 (Logs ≠ Work by themselves). Logs/telemetry are evidence for a Work; they do not constitute a Work unless bound to (spec, performer, time window) and judged in a context.

CC‑A15.1‑19 (Affected referent). Each U.Work MUST name at least one affected referent (e.g., U.Asset, product/batch, dataset/document) via affected → {…}.

CC‑A15.1‑20 (State‑change witness). Each U.Work MUST carry either (a) explicit pre‑state/post‑state anchors on the declared state‑plane or (b) a Δ‑predicate that can be evaluated on evidence. Trivial “no‑op” runs MUST be flagged as such.

CC‑A15.1‑21 (World anchoring vs. record‑handling). A run whose only effect is copying/reformatting records does not qualify as U.Work unless the judgment context declares those records to be the product referent (e.g., data‑product manufacture).

CC‑A15.1‑22 (System anchoring). Each U.Work MUST declare executedWithin → U.System/SubSystem; if different from the asset of change, keep affected explicit.

CC‑A15.1‑23 (Compositionality of Δ). For composite Work, the parent effect MUST be the declared composition of child effects under the same overlap policy as Γ_work.

CC‑A15.1‑24 (No new claims on faces). MVPK faces for U.Work SHALL NOT add properties/claims beyond the intensional arrow; numeric/comparable content MUST include unit/scale/reference‑plane/EditionId pins; the term “signature” is banned on faces.

CC‑A15.1‑25 (No Γ‑leakage). Faces MUST reference Γ operators/policies by id when showing aggregates; they MUST NOT encode aggregation semantics in prose or imply defaults. Γ lives in Part B; faces carry pinned references only.

CC‑A15.1‑26 (No I/O re‑listing). Faces MUST NOT restate intensional I/O; publish presence‑pins and anchors only (per MVPK §5.4).

CC‑A15.1‑27 (Lawful orders; return sets). Any across‑run comparison presented on a U.Work face MUST use a declared ComparatorSet (map‑then‑compare), return sets when order is partial, and forbid hidden scalarization/ordinal means.

CC‑A15.1‑28 (Comparator/Transport pins). Any numeric/comparable acceptance or KPI on a U.Work face MUST pin ComparatorSet.edition, CG‑Spec.edition, and (where conversions occur) TransportRegistry.edition with Φ/Φ^plane policy‑ids; Bridge ids are mandatory for cross‑context/plane reuse; penalties → R only.

CC‑A15.1‑29 (Telemetry hooks, when applicable). If a Work instance feeds G.11 or QD/OEE portfolios, it SHALL cite PathId/PathSliceId and the active policy‑id in its evidence; illumination remains report‑only telemetry unless CAL explicitly promotes it.

#Temporal & Aggregation Semantics (normative operators & invariants)

#Temporal coverage Γ_time

• Input: a finite set S of Work instances or Work parts.

• Output: either (a) the union of their intervals, or (b) the convex hull [min t_start, max t_end]—as declared by context and KPI.

• Invariants:

  • Idempotent: Γ_time(S ∪ S) = Γ_time(S)
  • Commutative: order of elements irrelevant
  • Monotone: if S ⊆ T then coverage(S) ⊆ coverage(T) (for union) or hull(S) ⊆ hull(T) (for hull)

• Usage guidance:

  • Use union for utilization/availability (how much of the clock time the asset was actually busy).
  • Use hull for lead/cycle time (elapsed from first touch to last release).
  • Manager’s tip: Write the choice near the KPI; many disputes are just a hidden union‑vs‑hull mismatch.

#Resource aggregation Γ_work

• Input: a finite set S of Work instances or parts with resource ledgers.

• Output: an aggregated ledger (materials, energy, machine‑time, money, tool wear) with explicit overlap policy.

• Invariants:

  • Additivity on disjoint parts: if intervals/resources are disjoint by policy, totals add.
  • No double‑count: overlapping costs must follow the declared policy (e.g., count once at parent).
  • Traceability: each aggregated figure must be reconcilable to contributing Work IDs.

• Typical policies:

  • Parent‑attribution: shared fixed costs at parent; variable costs at children.
  • Pro‑rata by wall‑time: split overlaps by relative durations.
  • Driver‑based: allocate by a declared driver (e.g., CPU share, weight, priority).

#Cross‑context checks (MethodDescription ↔ RoleAssigning ↔ Work)

When a Work is recorded, perform these three quick checks:

1. Spec–Context Check. Does isExecutionOf refer to a MethodDescription defined in the judgement context (or bridged to it)?

   • If no, the Work is out‑of‑context; either change context or add a Bridge.

2. RoleAssigning–Context Check. Is performedBy’s RoleAssigning valid in the same context (or bridged)?

   • If no, the Work is unassigned for that context; remedy via a valid RoleAssigning or a policy exception.

3. Standard–Outcome Check. Do the Work’s inputs/outputs and metrics satisfy the acceptance criteria from the spec as interpreted in that context?

   • If no, the Work fails or is “conditionally accepted” per context policy.

Manager’s mnemonic: Context, assignment, Standard → CAC. Fail any → the Work is not acceptable here (perhaps acceptable elsewhere).

#Anti‑patterns (and the right move)

• “The log is the process.” Dumping telemetry without binding (spec, performer, context) → Not Work. Create a Work, link the log as evidence.
• Record‑only transforms. ETL/replication of records with no declared affected referent (product/dataset as product) → Not Work in this context; either declare the dataset as the product referent or move it to U.WorkPlan/operations‑support.
• Silent cross‑context acceptance. “Ops accepted it, so audit accepts it.” → Add a Bridge or re‑judge in audit context.
• Spec drift in mid‑run. Swapping SOP v5→v6 without recording → Split into episodes or record override.
• Budget on the method. Charging costs to Method or Role → Book only to Work; keep estimates in specs.
• Part ambiguity. Mixing retries, episodes, and operational parts with no declared relation → Choose and declare the part relation.
• Union/hull confusion. Changing KPI coverage silently between reports → Declare Γ_time policy per KPI.
• Double‑count in overlaps. Summing child and parent resource ledgers → Declare and apply an overlap policy.

#Migration notes (quick wins)

1. Backfill links. For existing logs, create Work records and attach isExecutionOf and performedBy.
2. Name the context. Pick the judgement context explicitly; add Bridges if multiple contexts must accept.
3. Publish the episode policy. Decide when an interruption keeps identity vs forces a new run.
4. Choose Γ_time per KPI. Put “union” or “hull” in the KPI definition; stop arguing in meetings.
5. Set an overlap policy. Write one sentence on how shared costs are allocated; apply consistently.
6. Pull plans out. Move calendars to U.WorkPlan; let Work record actuals.
7. Parameter blocks. Make parameters explicit and bind them at start; your root‑cause analyses will get 10× easier.

#Consequences

#Relations

• Builds on: A.1 Holonic Foundation; A.1.1 U.BoundedContext; U.System; A.2 U.Role; A.2.1 U.RoleAssignment; A.2.2 U.Capability; A.3.1 U.Method; A.3.2 U.MethodDescription.
• Coordinates with: A.15 Role–Method–Work Alignment (the “four‑slot grammar”); B.1 Γ (aggregation) for resource/time operators; E‑cluster lexical rules (L‑PROC/L‑FUNC).
• Informs: Reporting/KPI patterns; Assurance/evidence patterns (Work as the anchor for audits); Scheduling patterns (U.WorkPlan ↔ U.Work deltas).

#Didactic quick cards

• What is Work? How it went this time → dated, resourced, accountable.
• Four‑slot grammar: Who? RoleAssigning. Can? Capability. How? Method/MethodDescription. Did? Work.
• CAC checks: Context (judgement), assignment (valid RoleAssigning), Standard (acceptance criteria).
• Roll‑ups: Γ_time = union (utilization) or hull (lead time); Γ_work with a declared overlap policy.
• Episodes vs retries: same run split vs new run; write the policy.
• Resource honesty: actuals booked only to Work; estimates live in specs.

#A.15.1:End

#U.WorkPlan

#Context (plain‑language motivation)

Operations live on time. Even with perfect roles, abilities, and methods, nothing ships unless we decide when and by whom concrete runs should happen, under what constraints and budgets. Teams need a first‑class concept for plans and schedules that does not get confused with:

• the semantic “way of doing” (that is U.Method),
• the written recipe (that is U.MethodDescription),
• the actual execution (that is U.Work), or
• the state laws (that is U.Dynamics).

U.WorkPlan is that missing anchor.

#Problem (what breaks without WorkPlan)

1. “Workflow = schedule” conflation. Flowcharts or code are used as calendars; resource clashes and SLA misses follow.
2. Plan/run blur. Gantt bars or Kanban tickets are reported as if the work already happened; audits and costing degrade.
3. Spec/time leakage. People and calendars creep into MethodDescriptions; reuse and staffing agility collapse.
4. No variance model. Without planned baselines, deviations in time, cost, and quality cannot be explained or improved.
5. Structure entanglement. BoM and org charts get baked into “process” views; plans become brittle and unmaintainable.

#Forces (what we must balance)

#Solution — the U.WorkPlan as the time‑bound intention to execute Work

#Definition

U.WorkPlan is an U.Episteme that declares intended U.Work occurrences over a horizon, with planned windows, dependencies, intended performers (as role kinds or proposed RoleAssignings), resource budgets/reservations, and acceptance targets—within a U.BoundedContext.

Strict distinction (memory aid): Method = how in principle. MethodDescription = how it is written. WorkPlan = when, by whom in intent, under which constraints. Work = how it went this time.

#Plan Items (what a WorkPlan is made of)

A U.WorkPlan contains Plan Items (think: scheduled tasks/ops), each of which typically states:

1. Target Method/Spec — the Method to be enacted and the MethodDescription intended for enactment.
2. Planned window — e.g., earliest start/latest finish, timebox, recurrence (cron‑like), blackout periods.
3. Role requirements — role kinds required (not people), optional proposed RoleAssigning(s) if pre‑assignment is allowed in the context.
4. Capability thresholds — minimal abilities required of the performer (checked at run time).
5. Resource budgets/reservations — planned energy/materials/machine slots/money; reservations on assets.
6. Dependencies — precedence/overlap permissions; gates/approvals.
7. Acceptance targets — quality windows/SLA targets to be judged when Work completes.
8. Location/asset constraints — where the run is expected to take place.
9. Links to Service promises (if any) — external commitments that this plan aims to satisfy.

Didactic guardrail: No logs or actuals belong in a WorkPlan; no step logic or solver internals either—that’s the Method/Spec.

#Clear distinctions (lexical sanity for “schedule/process/workflow”)

L‑SCHED (lexical rule). In this document, words like schedule, calendar, rota, Gantt, plan point to U.WorkPlan unless explicitly redefined by a bounded context glossary.

#Plan mereology (composition of plans ≠ composition of methods or runs)

Keep three separations crystal‑clear:

• Method composition (design‑time semantics) → produces new Methods.
• Work composition (run‑time occurrences) → produces parent/child runs with overlaps/episodes.
• Plan mereology (epistemic structure) → organizes Plan Items for coordination (phases, sprints, shifts), with precedence and resource reservations.

Common relations among Plan Items:

• Precedes_pl / DependsOn_pl — start/finish constraints and gates.
• MayOverlap_pl / MutuallyExclusive_pl — allowed overlaps vs exclusive windows.
• Refines_pl — a child plan item tightens windows/budgets of a parent.
• Alternative_pl — planned alternatives (e.g., backup rig, backup team).

Didactic rule: A Plan Item does not force an identical Work shape; mapping is via fulfilment and variance (see §6).

#How WorkPlan meets Work (fulfilment & variance)

When reality happens, each U.Work may:

• Fulfil a Plan Item — link plannedAs → PlanItem.
• Partially fulfil — multiple Work instances share one Plan Item (e.g., split run), or one Work fulfils several Plan Items (e.g., consolidated batch).
• Deviate — execute with method/spec substitution, different window, different performer (still valid or policy‑exception).
• Be unplanned — Work with no Plan Item (emergency, ad‑hoc); must be labeled as such.

Variance dimensions the plan expects to report on:

• Schedule variance (Δt): early/late vs planned window.
• Cost variance (Δc): actual resource spend vs budget.
• Scope variance: different Method/Spec than planned (with justification).
• Quality variance: acceptance verdict vs target.
• Assignment variance: intended vs actual RoleAssigning.

Manager’s view: A plan that cannot report variance is a calendar picture, not a management tool.

#What a good WorkPlan states (review checklist)

Use this as a human‑readable checklist (not a rigid schema):

1. Horizon & cadence (e.g., “W36 surgeries, daily ETL”).
2. Plan Items with: target Method/Spec, planned windows, dependencies.
3. Role requirements (kinds) and intended assignments (optional, context‑lawful).
4. Capability thresholds and safety envelopes.
5. Resource budgets and reservations on assets.
6. Acceptance targets (SLA/quality windows).
7. Bridges if plan spans multiple contexts (operations ↔ audit/regulatory).
8. Baseline/version and change notes (so variance is attributable).
9. Policy pointers (episode policy, overlap policy for Work roll‑ups if needed for KPIs).
10. Exceptions path (how ad‑hoc/emergency work is planned post‑factum).

#Archetypal grounding (parallel domains)

#Hospital OR day plan (shift rota + cases)

• WorkPlan: OR_DayPlan_2025‑08‑12.
• Plan Items: Case#1 Appendectomy, Case#2 Hernia, with windows, Context assignments, and surgeon role kinds; anesthetist intended RoleAssigning provided.
• Budgets: OR time blocks, consumables envelopes.
• Fulfilment: Each surgery Work links to its Plan Item; variances computed (over‑run time, substitutions).

#Fab maintenance weekend (asset reservations)

• WorkPlan: Fab_Maintenance_W36.
• Plan Items: Tool_42 chamber clean, Tool_13 calibration; MutuallyExclusive_pl with production slots.
• Reservations: nitrogen, DI water, metrology window.
• Fulfilment: Actual clean Work happens earlier; variance logged as early with cost underrun.

#Data‑center rollout (multi‑context plan)

• WorkPlan: DC_Rollout_Phase‑2.
• Bridges: Ops context ↔ Security Audit context (different acceptance targets).
• Plan Items: Deploy Service A, Pen‑test A; dependencies across contexts.
• Fulfilment: Deployment Work passes ops targets; audit Work passes later—variance reported per context.

#Bias‑Annotation (as in E‑cluster)

• Lenses tested: Did, Prag, Arch, Epist.
• Scope declaration: Universal; meanings of windows/budgets/permissions are context‑local via U.BoundedContext.
• Rationale: Elevates planning/scheduling to a first‑class episteme that coordinates Methods, RoleAssignings, and Work without conflation.

#A.15.2:End

#SlotFillingsPlanItem

Tech-name: SlotFillingsPlanItem Plain-name: planned slot-fillings baseline item (planned baseline) Type: Architectural (A) Status: Stable Normativity: Normative (unless explicitly marked informative) Placement: Part A → A.15 (Work & WorkPlanning) Builds on: pattern template (E.8), U.WorkPlan (A.15.2), Work enactment discipline (A.15.1 / TGA), Context discipline (E.10.D1), MechSuiteDescription (A.6.7), conformance discipline (E.19), publication/view discipline (E.17; views are projections, not places of meaning) Used by: planned-baseline requirements from suites/kits; P2W (selection → WorkPlanning → WorkEnactment); Part G universalization Purpose (one line): provide a universal, context-explicit planned baseline that maps a slot-owner’s SlotKinds to planned fillers, to be consumed by Work enactment where launch values are finalized.

Minting notes (informative)

• Mint vs reuse: This pattern mints the kind name SlotFillingsPlanItem. It reuses existing Core terms and disciplines (e.g., U.WorkPlan.PlanItem, SlotKind/ValueKind/RefKind/refMode discipline, edition pinning, U.BoundedContext, and the P2W split between WorkPlanning and WorkEnactment).
• SlotFillingsPlanItem (kind name): keep the suffix PlanItem to preserve the WorkPlanning locus. Do not mint aliases like SlotBinding… (conflicts with the A.6.5 binding discipline) or SlotValue… (ambiguous owner/context).
• Anchor names: if any anchors in §4.2 are later materialized as formal field names, keep …_ref only for fields whose values are concrete RefKind handles, and keep …_id only for identifiers. Avoid introducing generic placeholders like SpecRef/PolicyRef/GateRef inside this pattern; prefer existing concrete ref kinds (or a dedicated DRR+LEX step).
• Row vocabulary: treat SlotFillingRow and PlannedFiller as internal names of this pattern unless/until a separate DRR+LEX step promotes them to shared tokens.

#Problem frame

FPF frequently needs to make reproducible, reviewable choices about what fills which conceptual slot (spec refs, policy refs, mechanism-instance refs, time selectors, evidence hooks, etc.) before any Work is enacted. These choices must be visible as a planned baseline for a concrete P2W slice (CG-frame / path slice / publication scope), and must remain distinct from run-time “actuals” and gate decisions.

However, absent a universal WorkPlanning artifact for “architecture-by-planned-slot-filling”, authors tend to hide these choices inside mechanism prose, CG/CN specs, ad-hoc cards, or informal checklists—making Part G patterns difficult to universalize and making Work audit trails ambiguous.

SlotFillingsPlanItem addresses this by defining a WorkPlan PlanItem kind whose job is to state, in one place and with explicit context, a mapping:

(Target slot owner, slot kind) → planned filler (ByValue | ByRef(), with edition pins when needed)

and to do so in a form that can be cited by Work enactment and by suite/kit contract pins, without collapsing into “execution” or “decision logging”.

#Problem (what breaks without it)

Without an explicit SlotFillingsPlanItem baseline, at least six failure modes recur:

1. Hidden slot ownership and meaning drift: a planned filler is stated without making explicit whose slot set is being filled, allowing silent reinterpretation of SlotKinds across kits/suites.

2. Plan/execution collapse: plan documents get “backfilled” with run-time values, so there is no stable planned baseline and no clean variance trail. WorkPlan explicitly warns against this.

3. Implicit time (“latest”) and implicit recency: planned claims about comparability or launch readiness omit an explicit Γ_time, which violates the time discipline (“no implicit recency”).

4. Edition ambiguity: references to methods/policies/specs are not edition-pinned where reproducibility requires it, or the plan mutates the edition vector instead of citing pinned editions (edition changes are crossings, not “plan edits”). A particularly harmful subtype is edition-key backfill: retroactively editing a previously used baseline so that an edition-key change looks like an innocent PlanItem edit (hiding the required GateCrossing witness and breaking audit traceability).

5. Crossing invisibility: cross-context/plane expectations (Bridge + policy ids) are not stated at plan time, so later gate crossings appear as “magic” rather than traceable expected constraints.

6. G-pattern fragmentation: each Part G pattern invents its own place to stash planned refs (method pick, comparator pick, QD archive config, etc.), blocking a clean “G.Core” universal layer and making modular reuse brittle.

#Forces (what we must balance)

• Strict distinction: planned baseline is not a run-time witness; launch values are finalized only in Work enactment.
• Context must be explicit: every normative claim/rule is context-bound; the PlanItem must carry its context rather than relying on file location or prose.
• Time must be explicit: no implicit “latest”; any plan that will be cited by comparability/launch checks needs an explicit Γ_time selector/rule.
• SlotKind meaning is stable: the plan may choose fillers, but must not reinterpret SlotKinds or smuggle new semantics into indices.
• Derived indices must not become “places of meaning”: projections like “planned spec refs” are useful, but must remain derivable from the authoritative rows.
• Conceptual, not procedural: no solver steps, no lints, no “data governance”; this is an epistemic object used by humans in review.
• Supports universalization: one PlanItem pattern must be usable across the whole of Part G, not just G.5.
• Integrates with suites/kits: suites may require a planned-baseline ref and may act as slot owners.

#Solution

#A.15.3:4.1 Definition

A SlotFillingsPlanItem is a kind of U.WorkPlan.PlanItem whose content is a planned slot-fillings ledger for a single slot owner, within an explicit P2W context.

It is a WorkPlanning baseline, intended to be:

• produced/approved in WorkPlanning,
• cited by downstream Work enactment (as planned baseline),
• compared against actual fillings (variance recorded in Work, not by rewriting the plan).

Normative note (I/D/Spec vs views): A SlotFillingsPlanItem is a Description-level planning episteme (a PlanItem). It MAY be projected into U.View (e.g., TechCard(SlotFillingsPlanItemRef)), but any view is strictly a projection and MUST NOT introduce additional claims or “shadow defaults”.

#A.15.3:4.2 Core conceptual descriptors (not a data schema)

A conformant SlotFillingsPlanItem SHALL provide the following description (names are indicative; the semantics are normative):

1. PlanItem core (from A.15.2) The PlanItem MUST remain a planning artifact: it may include assumptions, dependencies, constraints, expected artifacts, and notes; it MUST NOT contain run-time logs/actuals.

2. Target slot owner

   • target_slot_owner_ref : <concrete …DescriptionRef> (required) Identifies the owner of the SlotKind set being filled (e.g., a kit description or a suite description). The slot owner MUST be referenced as an edition-addressable Description episteme (a concrete …DescriptionRef such as MechSuiteDescriptionRef, …KitDescriptionRef, etc.), and MUST NOT be a mechanism U.Mechanism.IntensionRef (or any other intensional ref). A MechSuiteDescription MAY serve as a slot owner for this purpose. If the slot owner’s SlotKind interface is edition-sensitive (or expected to evolve), the reference MUST be edition-pinned (e.g., target_slot_owner_ref.edition) whenever the PlanItem is used as a reproducibility baseline.

3. Described entity and grounding (for “whose measurements/choices?”)

   • described_entity_ref : <concrete RefKind> (required) The referent is the described entity (C.2.3 role): the thing the planned baseline is about. It MUST NOT be silently conflated with a holon. (Example: a baseline can be about a width/measure while the grounding holon is a stool with that width.) Use a concrete RefKind of the described entity (e.g., U.HolonRef, U.MeasureRef, …). Do not mint a new generic EntityRef token inside this pattern.
   • grounding_holon_ref? : U.HolonRef (optional; required when the described entity is not itself a holon and a grounding holon is needed for plane/frame anchoring)
   • reference_plane? : ReferencePlane (optional; required when not unambiguously derivable from cited context artifacts such as CG-frame/spec pins)

4. Explicit planning context (no hidden context)

   • bounded_context_ref : U.BoundedContextRef (required)
   • cg_frame_ref? : CGFrameRef (recommended when the fillings feed CG legality/selection)
   • path_slice_id? : PathSliceId (recommended for P2W reproducibility)
   • publication_scope_id? : PublicationScopeId (recommended if the plan will be surfaced in publication-facing views) These anchors exist because context is mandatory for claims/rules in FPF-style authoring.

5. Explicit time selector (no implicit recency)

   • exactly one of:

     • Γ_time_selector : Γ_timeSelector (ByValue), or
     • Γ_time_rule_ref : Γ_timeRuleRef (RefKind) This MUST be present whenever the plan is intended to support comparability/launch-related downstream checks.

6. Expected guard pins (refs/expectations only; no gate decisions)

   • expected_usm_guard_pins : [USM.CompareGuard | USM.LaunchGuard] (ByValue; subset of {USM.CompareGuard, USM.LaunchGuard}) These lexemes are reserved for USM.Guards pins (gate-level surfaces), not for mechanism operator names. If USM.LaunchGuard is expected, the plan MUST include enough pins/refs to make that guard executable downstream (explicit Γ_time_*, pinned editions where needed, and evidence hook anchors). The PlanItem MUST NOT include outcomes for these guards and MUST NOT emulate gate decisions; it only records expectations and required anchors.

   • guard_owner_gate_ref? : <concrete OperationalGateRefKind> (refs only; required when expected_usm_guard_pins is non-empty unless unambiguously derivable) Identifies the gate that owns/aggregates GuardFail outcomes (via the GuardOwnerGateSlot discipline). This remains an expectation pin, not a decision log. (Use the concrete RefKind that addresses OperationalGate(profile) in A.21. If such a RefKind does not yet exist, treat this as a DRR+LEX item.)

7. Planned evidence anchors (pin refs only)

   • planned_evidence_pin_refs? : [<concrete …PinRef>…] These are anchors to where evidence will be placed or cited (typically SCR/RSCR pins; optionally other pin kinds explicitly allowed by the downstream guard regime), not the evidence itself.

8. The planned slot-fillings ledger (authoritative rows)

   • planned_fillings : [SlotFillingRow+] where:

     SlotFillingRow := ⟨ slot_kind, planned_filler, edition_pin? ⟩

     • slot_kind : SlotKind A SlotKind provided by the target_slot_owner_ref (the PlanItem MUST NOT reinterpret SlotKind meaning). Unless the slot owner explicitly declares the slot as multi-valued, each slot_kind SHALL appear at most once in planned_fillings.
     • planned_filler : PlannedFiller where: PlannedFiller := ByValue(value) | ByRef(ref : <concrete RefKind>) In ByRef(…), the ref MUST be of a concrete RefKind (e.g., …SpecRef, …PolicyRef, …MethodDescriptionRef); the PlanItem MUST NOT use an untyped/generic “Ref” / “RefKind” placeholder. The chosen filler MUST conform to the SlotSpec discipline of the slot owner (A.6.5-style: refMode ∈ {ByValue | <concrete RefKind>}). Changes to planned fillers are described using the A.6.5 verb discipline: ByValue content change (fill/assign/update) vs ref retargeting (retarget) vs ref resolution (resolve), never by “renaming the slot”.
     • edition_pin? : EditionId Required only when reproducibility depends on an edition and the planned filler cannot carry an edition pin directly (preferred: …DescriptionRef.edition on the ref itself). If both the planned filler ref and the row provide edition pinning, they MUST agree (mismatch ⇒ nonconformant). ByValue rows SHOULD NOT carry edition pins unless the pinned edition is explicitly tied to a cited external artifact (e.g., a referenced rule/policy/method description).

9. Derived indices (optional; never a second source of truth)

   • planned_spec_ref_index? : [<concrete …SpecRef>…]
   • planned_policy_ref_index? : [<concrete …PolicyRef>…]
   • planned_mechanism_instance_ref_index? : [<concrete …MechanismInstanceRef>…] If any of these are present, they MUST be derivable projections of planned_fillings; any mismatch is nonconformant. (These are categories of refs extracted from the authoritative rows, not an invitation to introduce new generic SpecRef/PolicyRef token-kinds.)

10. Expected crossing policy pins (refs only; no crossing witnesses)

• expected_crossing_policy_refs? : [⟨bridge_card_ref, phi_policy_id, psi_policy_id?, phi_plane_policy_id?, reference_plane(src,tgt)⟩ …] These communicate what the plan expects will be needed for crossings, without claiming that a crossing has occurred. bridge_card_ref is expected to pin a Bridge identity/channel (BridgeId + channel) and to be auditable via downstream CrossingBundle/UTS rows. This section states Bridge-only expectations; it MUST NOT introduce non-Bridge crossing mechanisms, and it MUST NOT embed CL/Φ/Ψ/Φ_plane tables (refs/policy-ids/pins only).

• expected_crossing_bundle_refs? : [CrossingBundleRef…] (optional) Permitted only when the plan is explicitly citing already-published CrossingBundle baselines (e.g., “fixed context constants”); otherwise, the PlanItem SHALL state only expected policy pins and allow the crossing witness to appear at the gate/work level.

11. Notes (didactic, non-normative)

• planned_filling_notes? Helpful narrative for reviewers; must not embed new claims that contradict the rows.

#A.15.3:4.2.1 Canonical skeleton (Show)

The following compact pseudo-record illustrates the intended canonical minimum: explicit context + explicit time + a few authoritative rows.

SlotFillingsPlanItem := ⟨
  kind = SlotFillingsPlanItem,
  target_slot_owner_ref = CHRMechanismSuiteDescriptionRef@edition(E_suite),
  described_entity_ref = U.HolonRef(H:described-entity), // or another concrete RefKind per C.2.3
  grounding_holon_ref = U.HolonRef(H:grounding-holon)?,  // when the described entity is not itself a holon
  bounded_context_ref = U.BoundedContextRef(BC:context),
  cg_frame_ref = CGFrameRef(CG:frame),              // optional but typical for G.* legality/selection
  path_slice_id = PathSliceId(P2W:slice),           // optional but typical for reproducibility
  Γ_time_selector = point(t0),                      // no implicit “latest”
  expected_usm_guard_pins = {USM.CompareGuard, USM.LaunchGuard},
  planned_evidence_pin_refs = [RSCR.PinRef(RSCR:evidence-anchor)],
  planned_fillings = [
    ⟨ slot_kind = CNSpecSlot, planned_filler = ByRef(CNSpecRef(CN:…@edition(E_cn))) ⟩,
    ⟨ slot_kind = CGSpecSlot, planned_filler = ByRef(CGSpecRef(CG:…@edition(E_cg))) ⟩,
    ⟨ slot_kind = ScoringMethodDescriptionSlot,
      planned_filler = ByRef(ScoringMethodDescriptionRef(M:…@edition(E_m))) ⟩
  ]
⟩

#A.15.3:4.3 Relation to Work enactment (planned baseline vs actuals)

• A SlotFillingsPlanItem is not a witness of FinalizeLaunchValues. Launch values (actuals) occur only in Work enactment, and their witness belongs in Work/audit surfaces, not in this PlanItem.

• Deviation at execution time is allowed, but it must be recorded as variance in Work, and the plan must not be rewritten to match the execution. When a Work enactment claims to follow a planned baseline, the Work MUST cite the SlotFillingsPlanItem in its Audit as the planned baseline reference, and MUST record any variance against it (rather than “backfilling” the plan). The baseline citation SHOULD be edition-addressable (i.e., the Work cites a stable PlanItem edition), so that later PlanItem revisions cannot erase what was actually planned. If the baseline needs to change (including any edition-pinned ref changes), author a new PlanItem edition (or a new PlanItem) and treat the difference as a planning change—not as a retroactive edit of the previously cited baseline.

#A.15.3:4.4 Relation to suites/kits

• Any suite/kit that requires a “planned baseline” may require and cite a reference to a SlotFillingsPlanItem via its contract pins; MechSuiteDescription explicitly provides a place for such a requirement.

#Variants

1. Suite-specialized PlanItem (Refinement) A suite may define XSuiteSlotFillingsPlanItem ⊑ SlotFillingsPlanItem with:

   • fixed target_slot_owner_ref = XSuiteDescriptionRef,
   • additional required rows (e.g., mandatory pinned CGSpecRef, CNSpecRef, suite-required mechanism instance refs),
   • additional required expected pins (guards, crossing policies).

2. Minimal vs crossing-aware variants

   • Minimal: includes only context + planned rows + time selector.
   • Crossing-aware: adds expected_crossing_policy_ref[] and explicit reference_plane.

3. Evidence-gated variant For workflows where USM.LaunchGuard is expected, require planned_evidence_pin_refs[] and explicitly pin the relevant edition set needed for the later guard.

#Non-goals

• Not a mechanism; it performs no operations and publishes no operator signatures.
• Not a …Spec; it is not an acceptance harness and does not replace CN-Spec or CG-Spec.
• Not a hiding place for acceptance thresholds: any threshold-like semantics MUST live in explicit Acceptance/Policy artifacts (and be referenced/pinned), not smuggled in as anonymous ByValue numbers.
• Not a gate log: it MUST NOT contain GateDecision / DecisionLog, and MUST NOT claim that a crossing occurred.
• Not a run-time witness: it MUST NOT contain FinalizeLaunchValues actuals.
• Not a publication surface: it may be projected to views, but it is not “the card” itself. Any view MUST be an explicit projection (e.g., TechCard(PlanItemRef)), and unchecked presentation drift is a known failure mode.

#When to use

Use SlotFillingsPlanItem whenever:

• a workflow will be enacted through P2W and you need a planned baseline for what fills a suite/kit’s slots;
• you must pin editions/time policies explicitly (e.g., legality gates, comparator sets, transport registries);
• you are refactoring/authoring Part G patterns and want a uniform place to record selected refs/policies/mechanism instances;
• you expect a LaunchGate or any guard-based eligibility check to be meaningful and traceable.

#Implementation notes

Informative authoring guidance (conceptual):

1. Choose one target_slot_owner_ref per PlanItem. If multiple slot owners are involved, author multiple SlotFillingsPlanItems (one per owner) to keep slot meaning unambiguous.
2. Fill rows by SlotKind, not by positional arguments or “index numbers”.
3. If any downstream reasoning may hinge on “now vs then”, supply Γ_time_selector or Γ_time_rule_ref explicitly.
4. Prefer edition-pinned references when the downstream step is intended to be reproducible across review cycles.
5. Use derived indices only as projections for reader convenience; never maintain them independently.
6. If a PlanItem has been cited as a baseline by a Work, do not “edit it in place” to match reality. Create a new PlanItem edition and let Work record variance and/or the required crossing witnesses.

#Archetypal Grounding (Tell–Show–Show; System / Episteme)

#Archetype 1: CHR suite planned baseline for lawful characterization

Tell. A team plans a characterization workflow over a CG-frame that uses a CHR mechanism suite. The suite requires an explicit planned baseline reference.

Show (failure without SlotFillingsPlanItem). The “plan” is implicit: it says “use the latest CG-Spec and the current best comparator; compute scores and launch” without an explicit Γ_time, without edition pins, and without a stable mapping from SlotKinds to chosen fillers. Review later cannot distinguish: (i) what was planned, (ii) what was executed, and (iii) what changed via a crossing / edition-key shift.

Show (repair with SlotFillingsPlanItem). A conformant SlotFillingsPlanItem:

• targets CHRMechanismSuiteDescriptionRef as the slot owner (and pins its edition if used as a reproducibility baseline),
• pins CNSpecRef and CGSpecRef (editions pinned where reproducibility requires),
• pins a ScoringMethodDescriptionRef.edition (e.g., a monotone scoring family) and/or a set-valued method family (e.g., conformal-style set predictions),
• declares Γ_time_selector = point(t0) (no implicit “latest”),
• declares expected_usm_guard_pins = {USM.CompareGuard, USM.LaunchGuard},
• includes evidence pin refs that will later be populated/used in Work enactment.

The resulting Work enactment cites this PlanItem as the planned baseline; any substitution (e.g., retargeting a method description ref) appears as Work variance (and, when relevant, as a crossing witness), not as a retroactive plan rewrite.

#Archetype 2: Archive/QD selection with edition-sensitive descriptors

Tell. A workflow plans to return an archive (quality-diversity style) rather than a single winner. The selection pipeline depends on descriptor maps and distance definitions that are edition-sensitive.

Show (failure without SlotFillingsPlanItem). Descriptor-map and distance-definition drift is discovered only after the fact: an “archive” is produced, but reviewers cannot reconstruct which descriptor edition and distance definition were assumed at planning time, and the published view/card becomes the de facto (and mutable) “source of truth”.

Show (repair with SlotFillingsPlanItem). A conformant SlotFillingsPlanItem:

• targets an archive-selection kit/suite as target_slot_owner_ref,
• pins DescriptorMapDescriptionRef.edition and DistanceDefDescriptionRef.edition (or their kit equivalents),
• states expected_usm_guard_pins = {USM.CompareGuard} (if no LaunchGate is expected yet),
• records expected crossing policy pins if descriptors are reused cross-context.

This prevents “silent” descriptor drift across iterations and makes Part G’s archive-related extensions composable rather than embedded in selector prose.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal.

#Conformance Checklist

#Common Anti‑Patterns and How to Avoid Them

#Plan-as-execution

A plan document says: “Use the latest CG-Spec and the current best comparator; compute scores and launch.” This is nonconformant because it omits explicit Γ_time, omits edition pins, collapses planning into execution, and provides no stable baseline for variance/audit.

#Anti-example: Edition-key change disguised as a plan edit (backfill)

A team executes Work while actually using CGSpecRef@edition(E2) (and/or ComparatorSetRef@edition(E2)), but the previously approved baseline PlanItem had pinned @edition(E1). Later, instead of recording variance and the required GateCrossing witness for the edition-key change, someone edits the baseline PlanItem “in place” to replace E1 → E2, and then claims “no variance; we followed the plan”.

This is nonconformant because it:

• collapses planning into execution (retroactive baseline editing),
• hides an edition-key change that is crossing-relevant,
• destroys reproducibility and breaks Work/Audit traceability.

Correct handling: keep the old baseline intact; record variance in Work and, where applicable, require the gate/work-level crossing witness (UTS/CrossingBundle + policy-id pins), or produce a new PlanItem edition as the new planned baseline for subsequent enactments.

#Consequences

#Rationale

This pattern exists to give WorkPlanning an explicit, citeable place to commit to “which artifacts will fill which slots” without collapsing into run-time state.

Keeping the baseline bound to exactly one slot owner makes SlotKind semantics checkable and prevents accidental cross-owner slot drift.

Treating indices as derived projections preserves a single source of truth (the rows) while still enabling human-friendly navigation or tooling acceleration.

Finally, by disallowing run-time witnesses (launch values, observed values, concrete Γ_time) the pattern enforces the plan/run split and keeps audit variance attributable to an explicit baseline rather than to shifting defaults.

#SoTA‑Echoing (informative)

This pattern aligns with post‑2015 practice in multiple traditions while deliberately staying notationally/tool independent.

• ISO/IEC/IEEE 12207:2017 — Adopt the separation between planning artifacts and execution artifacts plus baseline/change-control concepts; Adapt them into a lightweight, citeable PlanItem kind; Reject prescribing any specific process tooling as normative inside FPF.
• ISO 26262:2018 — Adopt the emphasis on traceability, change impact visibility, and preventing retroactive “paper compliance”; Adapt it into baseline immutability + variance reporting; Reject treating safety certification structure as a required envelope for all contexts.
• NIST SP 800-128 Rev.1 (2020) — Adopt baseline management and deviation recording as an audit primitive; Adapt by expressing baselines as epistemic, context-bound references rather than machine configuration states; Reject security-tooling prescriptions as a dependency of the conceptual model.
• Forsgren, Humble, Kim (2018), Accelerate — Adopt the empirical lesson that explicit change tracking and small, attributable deltas improve reliability; Adapt by making the baseline the anchor for fulfilment/variance; Reject any “one true pipeline” or vendor-specific operational recipe.
• Morris (2021), Infrastructure as Code (2nd ed.) — Adopt the desired-state vs observed-state distinction and the discipline of explicit declarations; Adapt by keeping declarations as plan-level epistemes rather than deployment manifests; Reject binding the model to any specific IaC syntax or platform.

#Relations

• Builds on / governed by:
  • A.15.2 U.WorkPlan — container + PlanItem discipline; baseline citeability.
  • A.6.5 slot discipline — SlotKind/RefKind hygiene and binding-time separation.
  • E.10.D1 Context discipline — explicit context/edition; no implicit “latest”.
  • E.18 / TGA — keeps FinalizeLaunchValues strictly in WorkEnactment; pin/guard discipline.
• E.17 / Publication discipline — views are projections; no new semantics on cards.
• Interacts with / complements:
  • A.6.7 MechSuiteDescription — suites may require the presence of a planned baseline ref/pin without embedding planned fillers or launch values.
  • A.15.1 Work / WorkEnactment discipline — fulfilment and variance are recorded downstream against this baseline.
  • C3.2-S-02 Time discipline — time selection policy may be pinned by ref; run-time Γ_time stays in Work evidence.

#A.15.3:End

#Language-State Transduction Coordination

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative

Plain-name. Language-state move coordination.

Start here when. Your first honest artefact is a cue, not yet a claim, requirement, method, or work record, and you need to name the next lawful move without pretending that one downstream owner has already taken over.

First output. A small typed move note or early preservation-to-routing note that names the source publication form, target publication form, target owner, and MVPK face where that face matters.

Typical next owners. A.16.1 for early preservation, B.4.1 for route publication, B.5.2.0 for cue-derived abductive prompting, later endpoint owners such as A.6.P, A.6.A, and A.6.Q, and A.16.2 when the right move is reopen/backoff/respecify/retire.

Common wrong escalations / reroutes. If history itself must be published as an accountable trajectory, reroute to A.16.0; if you are already doing slot-explicit semantic repair, reroute to A.6.P, A.6.Q, or A.6.A; if the publication target is a graph object in its own right, reroute to E.18.

#Problem frame

Once positions in the declared language-state U.CharacteristicSpace chart from C.2.2a are explicit, teams still need lawful move kinds for how governed U.Episteme publications change, narrow, reopen, or hand off across that chart. Those moves must not collapse into a second formality ladder, a generic workflow story, or an invisible sequence of owner replacements.

A single local move note is often enough. Only some cases need a full trajectory account. The coordination pattern therefore has to stand on its own while still remaining compatible with A.16.0 when lineage, branch structure, loss notes, or handoff history become governance-relevant.

#Problem

Without a dedicated coordination pattern, authors either misuse F0-F9, force every cue into anomaly/problem language too early, let reopen and backoff happen informally with no explicit guards, or over-wrap every local move in a meta-account that should have remained optional.

#Forces

#Solution

A.16 owns only lawful move kinds, their guards, and docking rules for how governed U.Episteme publications may be related across declared language-state positions. It does not own F, does not define the trajectory-account semantics itself, and does not define a rival graph calculus beside E.18.

A conforming move may be published as a local move note without any U.LanguageStateTransductionTrajectory wrapper. A.16.0 is used only when lineage, branch structure, loss notes, supersession, retirement, bridge-sensitive history, or owner handoff has governance value that should be published as an account in its own right.

Observation itself is a precursor condition typically published through B.4.1. A.16 move kinds begin once a cue is deliberately noticed, stabilized, route-published, reopened, formalized, operationalized, respecified, or retired under explicit move discipline.

#Owned move family

A.16 owns these move names, not the publication forms that may result from them. U.PreArticulationCuePack, RoutedCueSet, U.AbductivePrompt, and later endpoint-owned forms are publication forms under their own owners; they are not move kinds.

Here projection remains the move name, but its reading is tightened: it is route-bounded partialization. The resulting publication must be a typed publication form rendered on an existing MVPK face. Naming only the face is insufficient; naming only an untyped placeholder is insufficient.

respecify is intentionally narrower than semantic repair. In A.16, it may change framing scaffold, route contract, or facet-profile reading while preserving the broad family. Slot-explicit semantic rewrite and endpoint-local lexical repair remain with later owners such as A.6.P, A.6.Q, and A.6.A.

#Guard discipline

Move guards are stated over named facets from C.2.LS, together with witnesses, scope, and GammaTime selectors where needed. In practice this means explicit reference to AE (C.2.4), CD (C.2.5), LanguageStateAnchoringMode (C.2.6), and LanguageStateRepresentationFactorBundle (C.2.7), either facetwise or through one published facet profile. No move may be justified by vague prose such as "the idea matured" without naming what changed in articulation, closure, anchoring, representation, or route state.

#Docking discipline

After route, projection, formalize, or operationalize, the next lawful publication shall keep three layers distinct:

• the publication form now being issued (for example U.PreArticulationCuePack, RoutedCueSet, U.AbductivePrompt, or a form owned under a later owner);
• the owner that owns that form (A.16.1, B.4.1, B.5.2.0, A.6.P, A.6.A, A.6.Q, B.5.2, A.15, C.25, or another named owner);
• the MVPK face, when rendering matters, that carries that publication.

Naming only the owner is insufficient because owners are not forms. Naming only the face is insufficient because faces are not forms. A lawful move note states the owned publication form first, then the owner, then the face if the face matters.

#Effect-free versus work-requiring moves

Some formalize and operationalize moves are effect-free epistemic rewrites or publication-strengthening moves over already available grounds. Others require new measurements, experiments, instrumentation, execution, or other U.Work. When the latter happens, the move note shall expose the crossing or handoff explicitly; A.16 does not pretend that world-facing work occurred inside the language layer.

#Move-note threshold and path publication discipline

A typed local move note is sufficient when a small move or short move chain can be kept reconstructible without publishing extra lineage machinery.

Use A.16.0 only when at least one of the following is load-bearing:

• derivation, supersession, fork, merge, or retirement structure;
• a multi-move history whose compression would hide owner or authority changes;
• visible loss notes or reopen conditions spanning more than one move;
• responsibility handoff or bridge/viewpoint entry that depends on upstream history.

If the history itself must be published as a graph object, reuse E.18. A.16 owns move legality; A.16.0 packages trajectory accounts; E.18 owns graph-level path publication.

#Archetypal Grounding

Tell. A language-state move is not "the episteme became better". It is a typed transduction: articulation rose, closure narrowed, route plurality was published, one route was foregrounded, a framing scaffold was replaced, or a branch was lawfully retired.

Show (System). An operator alert note about a disturbance may go notice -> stabilize -> route -> operationalize, then later reopen when counter-evidence arrives, or retire one branch when a stronger successor route takes over.

Show (Episteme). An inquiry cue pack about a felt or trace-anchored discrepancy cue may go notice -> stabilize -> route -> projection -> formalize, or reopen -> sketchBackoff -> respecify if the chosen framing proves too strong.

#Bias-Annotation

The pattern biases authors toward explicit move-typing and away from folk stories such as "it naturally matured". That bias is intentional.

#Conformance Checklist

• CC-A.16-1 A.16 MUST NOT redefine F or publish a second formality ladder.
• CC-A.16-2 A conforming move note MAY stand alone; A.16.0 SHALL NOT be treated as mandatory wrapper syntax for every move.
• CC-A.16-3 Every move kind SHALL name its preconditions and postconditions over explicit language-state facets, route state, or authority state.
• CC-A.16-4 Publication form, owner, and MVPK face SHALL NOT be collapsed into one unnamed target.
• CC-A.16-5 Multi-route state inside one governed member SHALL NOT be confused with lineage fork across several successor members.
• CC-A.16-6 respecify SHALL NOT be used to hide slot-explicit semantic repair that belongs to later repair owners.
• CC-A.16-7 Retreat or retirement SHALL preserve, withdraw, or discard prior witnesses and authority explicitly.
• CC-A.16-8 Published path structures SHOULD reuse E.18 when a graph publication object is needed.
• CC-A.16-9 AuthorityState and EndpointAdmissionProfile reuse SHALL NOT be treated as new owners, new route-bearing forms, or substitutes for gate or work state.
• CC-A.16-10 A summarized multi-move publication SHALL keep intermediate owner transitions reconstructible; otherwise the case must reopen or publish richer history.

#Common Anti-Patterns and How to Avoid Them

• Trajectory-wrapper inflation. Do not wrap every local move in A.16.0. Publish a local move note unless history has its own governance value.
• Owner-as-form collapse. Do not write as if A.6.P, B.5.2, or A.15 were publication forms. Name the owned form and the owner separately.
• Form-face collapse. Do not treat an MVPK face as if it were the publication form itself. Name both when both matter.
• Irreversible maturity story. Reopen, sketch-backoff, respecify, and retirement are lawful moves, not failures of the trajectory discipline.
• Silent branch retirement. Do not let one route or branch disappear without a retirement or supersession note.
• Route/fork confusion. Several live routes in one RoutedCueSet are not yet a lineage fork.

#Consequences

The benefit is a clean owner for language-state transductions and a lawful place for both tightening and retreat without owner blur. The trade-off is more explicit move bookkeeping.

#Rationale

This separation keeps C.2.3 as the sole owner of formality while C.2.2a / A.19 define position semantics, A.16.0 packages only the history that deserves publication as an account, and A.16 defines move legality.

#SoTA-Echoing

Claim 1. Best-known current incident-response, exploratory design, and inquiry practice treats advance, backoff, reopening, and retirement as governed transitions rather than as one irreversible maturity climb.

Practice / source / alignment / adoption. Contemporary incident review, exploratory design, and inquiry practice after 2015 keeps rollback, reopen, and retirement explicit because otherwise later readers over-credit earlier weak forms. This pattern adopts explicit retreat and retirement, adapts them to typed publication forms, route states, and authority states, and rejects the still-popular shortcut where every change is narrated as one-way maturation.

Claim 2. Best-known current provenance, path-publication, and model-evaluation practice distinguishes a local transition note from a heavier published history object.

Practice / source / alignment / adoption. Contemporary provenance and evaluation practice separates lightweight transition marking from heavier account publication when branch structure, loss notes, or handoff history become governance-relevant. This pattern adopts that separation, adapts it through the A.16 / A.16.0 / E.18 split, and rejects both extremes: wrapping every move in a mandatory trajectory object and compressing a governance-relevant move history into one vague maturity sentence.

Local stance. The load-bearing SoTA claim for this pattern is narrow: lawful language-state movement needs typed move notes, explicit authority effects, and explicit retreat/retirement options, but it does not need a second ladder or a mandatory wrapper around every move.

#Relations

• Builds on: C.2.2a, C.2.LS, C.2.4, C.2.5, C.2.6, C.2.7, A.18, A.19.
• Coordinates with: A.16.0, A.16.1, A.16.2, B.4.1, B.5.2.0, A.6.P, A.6.A, A.6.Q, E.18.
• Constrains: language-state move publication and docking.

#Lawful Move Matrix

#Typical publication consequences

#Invariance reminder

A lawful move may change articulation, closure, representation, route, authority, or publication form, but it shall not silently rewrite owner boundaries. A move is not permission to retype a cue into any convenient owner.

#Worked Move Notes

#Incident-control move note

An operator alert note about a production disturbance may move:

notice -> stabilize -> route -> operationalize

The alert note does not need to become an anomaly statement immediately. It may first become a cue pack, then a routed cue set, and only then a typed operational form under the later owner.

#Inquiry move note

An inquiry cue pack about a model-vs-observation discrepancy may move:

notice -> stabilize -> route -> projection -> formalize

Later, if the selected framing over-commits, the lawful continuation may be:

reopen -> sketchBackoff -> respecify

#Retired branch

A routed cue set may initially keep both evaluative and abductive routes live. If later review shows the evaluative branch was unsupported, the lawful continuation is not silent disappearance but explicit retirement of that branch, while the abductive branch remains current.

#False-maturity leap to reject

The following is not lawful:

notice -> gate decision

unless explicit intermediate publication and owner transitions justify it. The trajectory discipline exists precisely to block such invisible leaps.

#Authoring and Review Guidance

#Author prompt

When naming a move, the author should say:

• what the source publication form is,
• what the target publication form is,
• which owner owns the target form,
• which MVPK face matters if rendering matters,
• which facet or route-state change justifies the move,
• what authority effect follows,
• and what remains invariant.

#Review prompt

A reviewer should ask:

• is the move a real transduction or just rhetorical relabeling?
• does the move preserve witnesses and route provenance appropriately?
• is route plurality being confused with lineage fork?
• did a later owner silently absorb the publication too early?
• if retreat or retirement occurred, was the authority drop made explicit?

#Integration reminder

When path publication becomes important as an object in its own right, move semantics stay in A.16, the optional history package stays in A.16.0, and the path publication object still belongs to E.18.

#Migration and Boundary Notes

#Migration from old formality-ladder talk

Older prose that narrates a cue as moving from "informal to formal" should be unpacked into the relevant A.16 move plus the relevant facet, route-state, and authority changes. A one-axis maturity story is not enough.

#Boundary reminder

If authors find themselves using A.16 to justify measurement legality, bridge substitution, endpoint ontology, or slot-explicit semantic repair, they have crossed out of this owner's scope.

#Move Package Discipline

Publish moves as small typed transduction notes rather than as narrative adjectives.

#Minimal move note

A conforming move note should name:

• the source publication form,
• the target publication form,
• the target owner,
• the move kind,
• the facet or route-state changes that justify the move,
• the authority effect,
• and the witnesses or traces that preserve continuity.

If those fields already make the move reconstructible, the note does not need A.16.0.

#Source and target must both be typed

"The episteme was refined" is insufficient. A.16 requires typed source and target forms so owner boundaries stay visible.

#Witness continuity

Keep continuity explicit when anchors, contrasts, traces, or exemplars survive. If continuity breaks, state the break directly rather than smoothing it over in maturity prose.

#Authority, Route Plurality, and Fork Law

The pattern is not just about movement; it is about lawful movement under explicit authority boundaries.

#Multi-route state versus lineage fork

A multi-route state means one governed member still keeps several downstream directions live inside one publication such as RoutedCueSet.

A lineage fork means separate successor members have already been published, each with its own authority, losses, and future handoff semantics.

The first is plurality inside one member. The second is explicit branching of lineage. Reviewers shall not treat them as the same thing.

#Four route / authority states

A governed publication after route work is usually in one of four states:

• open plurality - several downstream directions remain live;
• selected-but-not-owned - one route is preferred, but the publication is still in an early or seam owner;
• endpoint-owned - a later owner now carries the relevant publication and responsibility;
• retired / withdrawn - the publication or branch is no longer current and survives only as historical continuity.

Confusing these states is one of the main causes of premature endpoint language.

#AuthorityState extraction note

The four states above may be reused as AuthorityState, an extracted shared profile for corridor coordination and review.

That extraction does not create a new owner. It reuses the state vocabulary already owned here for later cross-references in B.4.1, B.5.2.0, A.6.P, A.6.Q, A.6.A, and A.15.

AuthorityState names authority posture after route work. It does not replace routeDecision, selectedRoute, routeAuthorityState, route-bearing publication ownership, gate state, or work-execution state. Any endpoint-owned state still names the downstream owner explicitly.

#Authority may rise, stay bounded, fall, or retire

A move may:

• raise authority, as when a routed cue becomes a lawful endpoint-owned form;
• keep authority bounded, as when a route-bearing publication clarifies one route without claiming endpoint ownership;
• lower authority, as when reopening or sketch-backoff withdraws prior closure or route force;
• retire authority, as when a branch or publication is explicitly withdrawn from current use.

The authority effect should be named as carefully as the move kind itself.

#Boundary to owner replacement

A.16 never authorizes a silent owner replacement. If a route crosses into A.6.P, B.5.2, A.15, C.25, or another endpoint owner, that owner and the owned publication form must be named explicitly. A.16 coordinates the crossing; it does not absorb the destination owner's semantics.

#EndpointAdmissionProfile extraction note

The corridor may later reuse an EndpointAdmissionProfile as a declarative host-derived profile for lawful handoff from language-state publications to later owners.

That profile is stated over already-owned conditions: declared language-state positions in C.2.2a, facet readings in C.2.LS and C.2.4-C.2.7, explicit route state in B.4.1, prompt-readiness in B.5.2.0, and witness or grounding conditions that are already visible in the publication chain.

EndpointAdmissionProfile decides whether handoff is lawful; it does not own the downstream publication form itself. A relation-like skeleton may therefore be admitted toward A.6.P; an explicit open question with rival-set may be admitted toward B.5.2.0; evaluative or action-inviting material may be admitted toward A.6.Q or A.6.A; executable docking may be admitted toward A.15.

No admission result makes a later owner optional. Tone, style, or mere apparent explicitness is never sufficient on its own; the relevant owner conditions still have to be named and met.

#Worked Failure and Recovery Cases

#Premature endpoint capture

A weak cue is observed and quickly described as if it were already a requirement. Under A.16, this is rejected because the move history is missing: the publication should first be noticed, stabilized, and route-published. The recovery is not to defend the over-strong label, but to reopen and publish the earlier route-bearing form.

#Silent route drift

A note begins as evaluative pressure but later starts driving work planning. If this shift is not published, the route drift remains invisible. A.16 requires either a new route-bearing publication, an explicit operationalization note, or an explicit handoff to a later owner.

#Lawful retreat after over-formalization

A note is formalized too early into a relation-like shape, but later review shows the anchors are still unstable. The correct continuation is not to leave the relation form in place and quietly reinterpret it. The correct continuation is reopen -> sketchBackoff, preserving what still holds and lowering the authority of what no longer does.

#Silent branch disappearance

A route-bearing publication originally kept two candidate routes live. Later text talks only as if one route ever existed. Reviewers should treat that as silent branch laundering unless the abandoned route was explicitly retired, merged, or shown never to have become its own branch.

#Form-owner-face collapse

A note says only the move publishes a Tech face or the move enters A.6.P and never names the actual publication form. That wording is non-conforming because it collapses three different layers into one phrase. The repair is to name the publication form first, then the owner, then the MVPK face if the face matters for rendering or review.

#Multi-Move Composition and Path Publication

#Compound move rule

Many published histories are short move chains such as notice -> stabilize -> route -> projection into U.AbductivePrompt, or endpoint-owned form -> reopen -> sketchBackoff -> route. A conforming publication may summarize such a chain only if the intermediate owner transitions remain reconstructible.

#Move-by-move authority reading

Read authority move by move. Later strengthening does not retroactively authorize earlier weak forms, and later retreat or retirement does not erase the fact that stronger authority once existed.

#A.16.0 threshold

When a move history acquires governance value of its own, publish it through A.16.0 rather than overloading one local move note with hidden lineage structure.

#E.18 threshold

When the history must be published as a path object in a graph sense, reuse E.18. A.16 still owns move semantics.

#Comparative Move Law and Boundary Tests

#Comparing move histories

Move histories may be compared across contexts only if the compared moves are typed by publication form, owner, and authority effect. Comparing one context's route -> projection chain to another context's cue -> requirement leap as though they were the same "formalization speed" is a category mistake.

#No maturity-ladder compression

A multi-move path shall not be redescribed as one generic climb in maturity, rigor, or readiness. The lawful comparison is over move kinds, facet shifts, route states, owner crossings, and authority effects.

#Boundary test for silent path laundering

If a later endpoint claim depends on prior move publications that are not visible anywhere in the publication chain, reviewers should assume silent path laundering until the missing move records are supplied. A.16 exists precisely to prevent such invisible transitions.

#Review Matrix for Integration Integrity

A reviewer can test an A.16 move or move chain with six questions:

1. Are the source and target forms typed? If not, the move is too vague.
2. Are owner and face kept distinct from the form? If not, the move collapses layers.
3. Is the authority effect explicit? If not, later owner boundaries will drift.
4. Is route plurality being confused with lineage fork? If yes, the history is being misread.
5. Are intermediate move publications suppressed in a way that changes the reading? If yes, the chain is over-compressed.
6. Has A.16 started to impersonate a later owner or a trajectory wrapper? If yes, the relevant later owner or A.16.0 threshold needs to be named explicitly.

This matrix keeps the integration layer narrow while still making its move semantics inspectable.

#A.16:End

#U.LanguageStateTransductionTrajectory - Optional trajectory-account normal form over the language-state U.CharacteristicSpace

Type: Architectural (A) Status: Draft Normativity: Normative unless marked informative

Plain-name. Language-state transduction trajectory.

Builds on. C.2.2a, A.16, A.19, E.17, E.18, E.10, F.18.

Used by. A.16.1, A.16.2, B.4.1, B.5.2.0, A.6.P, A.6.Q, A.6.A, F.9.1, E.17.1.

#Problem frame

In engineering, inquiry, operator, and management practice, teams sometimes need more than a local move note. When branch structure, supersession, retirement, handoff, bridge-sensitive loss, or multi-step owner change matters, readers need one place where the history of successive governed U.Episteme publications is made explicit.

Cue packs, routed cue sets, abductive prompts, typed route-bounded projection publications, partial normal forms, and later endpoint-bound records are publication forms that may appear in that history. They are not the raw disturbances, telemetry traces, model outputs, bodily tensions, or carrier documents that ground it.

What must remain intelligible is therefore not a myth that one unchanged object literally moves. What must remain intelligible is a lineage of successive governed U.Episteme publications, together with the load-bearing links among them, when that history itself has governance value.

#Problem

Without an explicit trajectory-account pattern for those heavier cases:

1. history is mistaken for generic workflow rather than for governed transduction over a declared language-state U.CharacteristicSpace;
2. early seam publications are confused with endpoint-owned forms;
3. forks, merges, route retirement, supersession, and route-sensitive loss become implicit and unverifiable;
4. every local move is either over-wrapped in ad hoc history prose or under-wrapped in a way that hides handoff and authority change;
5. bridge and viewpoint docking inherit under-described upstream history.

#Forces

#Solution

U.LanguageStateTransductionTrajectory is the optional trajectory-account normal form that records how successive governed U.Episteme publications are linked across position claims in the declared language-state U.CharacteristicSpace chart named in C.2.2a.

It does not define position semantics, move legality, or publication-face ontology by itself. Those remain with C.2.2a / A.19, A.16, and E.17 / E.18 respectively.

It answers the question: when history itself matters, which governed publication is current, which members precede or branch from it, which lawful moves relate them, which publication forms carry them, what was lost, and who now owns the next responsibility?

#Ontological subject and role lanes

In this cluster, keep six roles distinct:

• current governed member - the current U.Episteme publication under language-state governance;
• lineage links - explicit derivedFrom, supersedes, forkedFrom, mergedFrom, and retirement / no-successor links among governed members;
• grounds / witnesses - service disturbances, model-vs-observation discrepancies, traces, model outputs, bodily tensions, contrasts, or exemplars that justify the history;
• publication forms - cue packs, routed cue sets, prompt forms, typed route-bounded projection publications, partial normal forms, and endpoint-owned records through which lineage members are 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 artefacts that hold or render those publications.

A multi-route state inside one current governed member is not yet a lineage fork. It becomes a fork only when distinct successor members are published and given their own authority, losses, or handoff semantics.

A trajectory step may add a new lineage member, revise the current member, or relate several members through fork, merge, supersession, or retirement. It does not mean that the source phenomenon itself has moved through the language-state chart.

#Position-account discipline

The position read by this pattern is the slot-explicit claim defined in C.2.2a: a partial coordinate publication in the declared language-state U.CharacteristicSpace, where each basis slot publishes a ValueSet(slot), interval, or other admissible set-valued claim.

Early seam publications may leave some slots unknown or wide. That uncertainty is lawful only if it is explicit. A trajectory account therefore records the position claims of the current lineage member and, when needed, of the predecessor or sibling members that justify the move reading.

#Use threshold and core trajectory record

A single local A.16 move note is sufficient when no load-bearing branch, loss, handoff, or supersession structure needs publication.

Use U.LanguageStateTransductionTrajectory when at least one of the following is load-bearing:

• derivation, supersession, fork, merge, or retirement structure;
• multi-step loss notes or reopen conditions that would be hidden by a compressed move note;
• responsibility handoff whose legitimacy depends on upstream history;
• bridge or viewpoint entry that depends on upstream route, loss, or lineage structure.

A conforming trajectory account then keeps at least the following explicit:

• the current governed member;
• predecessor, sibling, or ancestor references when the current reading depends on lineage structure;
• the lineage link kind (derivedFrom, supersedes, forkedFrom, mergedFrom, retiredWithSuccessor, retiredWithoutSuccessor, or another explicitly typed link);
• the current position claim and any load-bearing predecessor position claims;
• the typed move or move sequence that relates them;
• the publication form currently carrying the governed member and, if it matters, the MVPK face carrying that form;
• the next intended owner or handoff state;
• any loss note, reopen condition, branch-specific authority note, or bridge-sensitive note that matters.

#Recorded move-family discipline

U.LanguageStateTransductionTrajectory records the governed A.16 move family: notice, stabilize, route, projection, formalize, operationalize, reopen, sketchBackoff, respecify, and retire.

The point is not that every account uses every move. The point is that forward movement, retreat, reframing, and explicit retirement belong to one governed family when that history is worth publishing.

Detailed move guards remain with A.16. A.16.0 records their use; it does not own them.

#Seam publication and face discipline

A trajectory account may refer to seam publications that remain upstream of endpoint ownership. In the current cluster these include:

• U.PreArticulationCuePack;
• RoutedCueSet;
• U.AbductivePrompt;
• partial normal forms already typed elsewhere;
• other explicitly typed upstream publications that preserve non-endpoint status.

These are not a second publication-face ladder. They are typed publication forms rendered, when necessary, on existing MVPK faces under E.17.

Untyped placeholders such as "route-bounded publication face" are non-conformant in a trajectory account unless the text also names the actual publication form and, separately, the MVPK face if face typing matters.

#Endpoint docking and responsibility handoff

A trajectory does not need to terminate in order to be useful. What matters is a visible docking milestone or responsibility handoff into an owner that is allowed to take the next contract.