#Strict Distinction (Clarity Lattice)

Pattern A.7 · Stable Part A - Kernel Architecture Cluster

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:

#Keywords

• category error
• Object ≠ Description
• Role ≠ Work
• ontology.

#Relations

#Content

#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