#Transformer Constitution (Quartet)

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

Establish a single, substrate‑neutral way to say who acts, under which role, according to which description, by which capability, and what actually happened—without “self‑magic” and without blurring design‑time and run‑time. The pattern fixes the Transformer Quartet so all kernel and Γ‑patterns reuse the same four anchors. It builds directly on Holon‑Role Duality (A.2) and Temporal Duality (A.4) and is guarded by Strict Distinction (A.7) and Evidence Graph Referring (A.10).

#Keywords

• action
• causality
• change
• System-in-Role
• MethodDescription
• Method
• Work.

#Relations

#Content

#Intent

Establish a single, substrate‑neutral way to say who acts, under which role, according to which description, by which capability, and what actually happened—without “self‑magic” and without blurring design‑time and run‑time. The pattern fixes the Transformer Quartet so all kernel and Γ‑patterns reuse the same four anchors. It builds directly on Holon‑Role Duality (A.2) and Temporal Duality (A.4) and is guarded by Strict Distinction (A.7) and Evidence Graph Referring (A.10).

#Context

• Holonic substrate. FPF separates what things are (Holon → {System, Episteme, …}) from what they are being right now via roles. Only systems can bear behavioural roles and execute methods/work; epistemes are changed via their symbol carriers.
• Role as mask; behaviour as method/work. A role is a mask, not behaviour; behaviour is a Method (order‑sensitive capability) that may be executed as Work (dated occurrence).
• Design‑time vs run‑time. A holon’s states belong to disjoint scopes Tᴰ and Tᴿ; transitions are physically grounded by a system bearing TransformerRole.
• Evidence & carriers. Claims about outcomes must anchor to carriers (SCR/RSCR) and to an external evidencing transformer.

#Problem

Legacy phrasing (“actor / process / blueprint”) causes recurrent failures:

1. Self‑magic: “the system configures itself” (no external acting side, causality lost).
2. Plan = event: blueprint/algorithm reported as if execution happened.
3. Capability = result: possession of a method counted as evidence of work.
4. Episteme as doer: documents/models treated as actors.
5. Scope leak: design‑time and run‑time mixed; run traces lack carriers/method ties. A.2/A.4/A.7/A.10 collectively forbid these, but A.3 must give the canonical quartet that authors can apply consistently.

#Forces

#Solution — The Transformer Quartet

A.3 defines four anchors, tied together by Role Assignment (U.RoleAssignment) and aligned with Temporal Duality.

#The four anchors (terms & types)

1. Acting side: a system bearing TransformerRole — the only holon kind allowed to enact transformations (behavioural role). Canonical phrase: “system bearing TransformerRole”. Local shorthand: after explicit binding in the same subsection, you MAY write “Transformer” to denote that same system; re‑bind on context change and do not use shorthand where the domain already has a conflicting “transformer” term.

2. MethodDescription (design‑time description): protocol / algorithm / SOP / script — all are idioms of MethodDescription; they live in Tᴰ and are epistemes with carriers (SCR/RSCR).

3. Method (design‑time capability): order‑sensitive composition the system can enact at run‑time (Γ_method); it is not an occurrence.

4. Work (run‑time occurrence): dated execution producing state change and consuming resources (Γ_work); every Work isExecutionOf exactly one MethodDescription version and is performedBy exactly one performer (possibly a collective system).

Safe memory line: MethodDescription → (describes) Method → (executed as) Work. Roles are masks (A.2/A.7); methods/work are behaviour.

#Contextual Role Assignmnent (U.RoleAssignment) for transformations

Use the universal assignment to state who plays which role where and when:

U.RoleAssignment(
  holder  : U.System,          -- the acting system (bearer)
  role    : U.TransformerRole, -- behavioural role
  context : U.BoundedContext,  -- semantic boundary
  timespan?: Interval          -- optional validity window
)

• A role is local to context and time‑indexed.
• The same system may bear multiple roles if the context allows compatibility.
• For epistemes, the target of change is their symbol carriers; the acting side is still a system.

#Boundary & externality

Every transformation is modelled with two sides and an explicit U.Interaction boundary: acting (system bearing TransformerRole) and target (system being transformed, or the carrier of an episteme). There is no self‑doing; “self‑like” stories are handled by the reflexive split (regulator vs regulated subsystems) or by promoting a meta‑holon and keeping evidence external (A.12).

#Temporal alignment (A.4 bridge)

• MethodDescription lives in Tᴰ;
• Method is defined at design-time and executed as U.Work at run-time by a U.System with a valid U.RoleAssignment (window-aligned) and a live StateAssertion for an enactable RSG state;
• Work lives in Tᴿ;
• transitions Tᴰ → Tᴿ and Tᴿ → Tᴰ are grounded by executions of appropriate methods by an external transformer (e.g., fabrication or observation).

#Evidence Graph Referring

Each Work anchors to carriers and to the MethodDescription it instantiates; evidencing transformers are external (no self‑evidence). This sits in the EPV‑DAG and never in mereology.

#Didactic dictionary (safe mappings)

• “Process / Workflow / SOP / Algorithm” ⇒ MethodDescription (design‑time description).
• “Operation / Job / Run / Performance” ⇒ Work (run‑time occurrence).
• “Function (equipment spec)” ⇒ Method (or MethodDescription if purely textual).
• “Creator” (legacy) ⇒ Transformer (shorthand for system bearing TransformerRole after local binding).

#Illustrative scenarios (substrate‑neutral)

#Physical system — Cooling loop

PumpUnit#3 (system bearing TransformerRole) executes ChannelFluid (Method) as per centrifugal_pump_curve.ld (MethodDescription), producing run‑2025‑08‑08‑T14:03 (Work, 3.6 kWh; ΔT=6 K). Evidence goes to carriers in SCR; resource spend goes to Γ_work.

#Epistemic change — Proof revision

LeanServer (system bearing TransformerRole) edits proof_tactic.lean (carrier) per MethodDescription; lemma‑42‑check‑2025‑08‑08 is Work; the episteme (theorem) changes through its carriers; evidence is attributed to the external transformer.

#Reflexive maintenance — “calibrates itself”

Split into Regulator (calibration module, acting side) and Regulated (sensor suite, target) with an interaction boundary; credit evidence to the regulator; no self‑evidence.

#Conformance Checklist (normative)

CC‑A3‑0 - U.RoleAssgnment presence. Every claim that a holon “performs a transformation” MUST be backed by at least one RoleAssignment triple: U.RoleAssignment(holder: U.Holon, role: U.Role=TransformerRole, context: U.BoundedContext, timespan?). This is the canonical way to say who acts, in which role, where (semantically), and when. See A.2.1 for the universal U.RoleAssignment Standard and its invariants.

CC‑A3‑1 - External transformer discipline. The bearer of TransformerRole MUST NOT be the same model instance as the object‑under‑change within the same assignment. Self-modification is modelled via two U.RoleAssignments (same holder playing two roles) or via an explicit controller–plant split. This upholds Agent Externalization (A.12).

CC‑A3‑2 - Design–Run separation. U.MethodDescription (recipe, definition) is a design‑time artefact; U.Method (mask‑of‑work) and U.Work (executed work) are run‑time. It is non‑conformant to mutate a MethodDescription inside a Work log or to treat a Work as a MethodDescription. This enforces the kernel’s Temporal Duality (A.4) and the A.15 alignment.

CC‑A3‑3 - Boundary‑crossing evidence. A conformant transformation that changes a system’s state MUST reference the boundary effects it induces: interactions, flows, or state transitions attach to the target system’s boundary (per Γ‑defaults for additive, min/AND/OR folds). Conservation‑class effects MUST satisfy B‑invariants (e.g., B‑1 Conservation).

CC‑A3‑4 - Method ←→ Work traceability. Every U.Work MUST (i) name the U.Method it instantiates and (ii) trace the U.MethodDescription it claims to follow (versioned). If a deviation occurs, it MUST be logged as a policy override or exception path; silent drift is non‑conformant. (A.15 guards the vocabulary; Γ_work aggregates resource deltas.)

CC‑A3‑5 - Episteme as object‑under‑change. When the changed holon is an episteme (document, dataset, theory), the transformer is still a system; the episteme’s history MUST be recorded via PhaseOf (versioning) and ConstituentOf/PortionOf as appropriate (not via component trees). See A.14’s mereology firewalls and Γ_epist hooks.

CC‑A3‑6 - Units and measures for resource effects. Any resource consumption/production in U.Work MUST specify the measure μ and units (e.g., kg, J, bytes); “percentage” effects MUST be grounded in a PortionOf μ to be Γ‑aggregatable. (A.14 POR‑axioms; Γ_work usage.)

CC‑A3‑7 - Provenance minimum. For each U.RoleAssignment and U.Work, the following fields are REQUIRED: {authority?, justification?, provenance?} where justification: U.Episteme and provenance: U.Method/process evidence. This aligns with the kernel’s governance and B‑cluster lineage practices.

CC‑A3‑8 - Policy–Plan–Action separation for agentic cases. If the transformer bearer is agentic, the log MUST separate D.Policy → U.PlannedAction → U.Action (A.15/A.13), preserving where failure occurred (strategy, plan, or execution).

CC‑A3‑9 - Context‑local conflicts. Conflicts among roles (including TransformerRole) are only within the same bounded context; cross‑context differences are admissible if bridges are declared. Non‑conformance arises only when a context’s own incompatibility rules are violated. (A.2.1 U.RoleAssignment invariants.)

CC‑A3‑10 - Γ‑compatibility. Descriptions MUST be sufficient for the relevant Γ‑aggregations to run: Γ_method for recipe composition, Γ_work for resource deltas, Γ_sys for boundary integration, Γ_time for ordering. Each Γ flavour declares its A.14 hooks (Portion/Phase) and inherits B‑invariants.

#Consequences

Benefits

• Explainability by construction. Every transformative claim carries who/what/when/why/how via U.RoleAssignment + provenance fields; audits become mechanical rather than heroic. (B‑invariants and Γ tables do the heavy lifting.)
• No category errors. Keeping methods/roles out of mereology and enforcing design/run separation prevents the usual “process‑as‑part” and “version‑as‑component” mistakes. (A.14 + A.15.)
• Composable analytics. With measures and boundary folds explicit, cross‑scale proofs (Σ/Π/min/∧/∨) are predictable.
• Contextual pluralism without chaos. Divergent domain practices coexist as distinct bounded contexts with bridges; disagreements are localised and tractable.

Trade‑offs

• More declarations up‑front. U.RoleAssignment + units + policy/plan/action feels verbose, but yields deterministic Γ‑runs and reproducible audits.
• Discipline for “self‑modifiers.” Modellers must split controller vs plant or dual‑role the same carrier; this adds one line but avoids hidden identity conflations.

#Rationale (post‑2015 cross‑domain support)

Constructor theory (post‑2015). Our Transformer Principle mirrors constructor theory’s shift from dynamics to tasks: what transformations are possible vs impossible, and why. By making the transformer (constructor) an explicit bearer of a role and keeping recipes as MethodDescription, A.3 captures the core “tasks & constructors” distinction and aligns with constructor‑theoretic thermodynamics linking work, heat, and informational constraints. (Royal Society Publishing, arXiv, Constructor Theory)

Active inference & free‑energy mechanics (2017→). Where transformers are agentic, A.3’s policy–plan–action split and boundary‑centred accounting dovetail with active inference and free‑energy formulations of self‑organising systems (Markov blankets; Bayesian mechanics). This legitimises U.Objective/cost function links and makes design–run duality natural (prior vs posterior policies). (MIT Press Direct, PubMed, arXiv)

Provenance and FAIR packaging (2016→). Provenance minima in CC‑A3‑7 reflect FAIR principles (machine‑actionable reuse), RO‑Crate (methods+data+context packaged together), and operational lineage standards such as OpenLineage and ML Metadata (TFX) that treat artefacts, runs, and jobs as first‑class, with typed facets and versioning — exactly what enactment + Γ_work need. (Nature, researchobject.org, SAGE Journals, openlineage.io, GitHub, arXiv)

Together, these lines of work argue for explicit role‑bearing transformers, recipe/run separation, boundary‑grounded deltas, and traceable contexts — the four pillars that CC‑A3 enforces.

#Relations

A.7 Strict Distinction. A.3 operationalises A.7 by keeping object ≠ description ≠ observation: object = target holon; description = MethodDescription; observation/log = Work. Violations (e.g., treating a recipe as a part) are non‑conformant and usually surface as Γ failures.

A.12 Agent Externalization & External Transformer. A.3’s CC‑A3‑1 is the mechanical guard‑rail for A.12: even in self‑modification, the modelling split keeps the agent (transformer bearer) distinct from the object‑under‑change.

A.13 Agential Role. When the bearer is an Agent, A.3 defers identity and states management to Agent‑CAL (U.Agent, U.Intent, U.Action), while still requiring RoleAssigning + Γ compatibility. This is where policy/plan/action pipelines live.

A.15 Role–Method–Work Alignment. A.3 relies on A.15’s vocabulary guard‑rails (roles are not parts; methods are masks of work; specs are recipes). CC‑A3‑2/‑4 are enforceable precisely because A.15 fixes the naming discipline.

A.14 Advanced Mereology. A.3 consumes A.14’s PortionOf (for quantitative deltas) and PhaseOf (for versioning) and forbids role/recipe leakage into part–whole trees. Γ‑flavours declare which A.14 hooks they use.

B‑cluster (Γ‑sections). A.3 is executable only because Γ‑operators provide aggregation and invariants:

• Γ_sys enforces boundary folds and conservation;
• Γ_epist preserves document/data provenance and versioning;
• Γ_time orders work;
• Γ_method composes recipes;
• Γ_work accounts resource deltas; each inherits B‑invariants (e.g., B‑1 Conservation, B‑2 No‑Duplication).

Indexing to the glossary. Terms used here (TransformerRole, Work, Method, MethodDescription, PortionOf, PhaseOf, BoundedContext) remain exactly as defined in Annex A; see A.1/A.2/A.14/A.15 entries for lexical registers.

#A.3:End