A.6.1:5 - Archetypal Grounding

A.6.1:5.1 - Physical modeling: thermal connector operations

A physical-modeling team repeatedly uses a thermal connector operation family. The mechanism episteme declares named temperature and heat-flow argument and result meanings with their exact ValueKinds, connection operations, equality and conservation laws, application identity and extent rules, and admission conditions for unit compatibility and steady-state conduction. Applicability names a U.ClaimScope over the modeled systems, the use interval, selected CHR:ReferencePlane = conceptual for these model-side connector claims, and the steady-state conduction condition; a component port is a modeled participant or locus, not a CHR:ReferencePlane value.

One equation-based model can realize that declaration for simulation use. The modeled heater and pipe remain physical systems. Solver work, validation measurements, and a connection diagram remain work, evidence, and representation under their own patterns.

Practical payoff: another model can be compared against the same operation and law declaration without treating equation order, solver choice, or a diagram as mechanism identity.

A.6.1:5.2 - Clinical work: dose-adjustment operations

A clinical team declares a dose-adjustment mechanism over one common patient subject and one common dose-value domain. The headline fields and the heterogeneous operation positions connect as follows; every named ValueKind must already resolve under the effective reference scheme.

Admission conditions state which measurements and qualification intervals make one calculation admissible. Applicability names the patient-population U.ClaimScope, qualification interval, selected CHR:ReferencePlane (normally world for the patient-side use claim), and clinical conditions under which the declaration is used.

An exact claim-bearing clinical-protocol episteme is a U.MethodDescription only when it describes one admitted U.Method and satisfies A.3.2; its publication form and carrier remain separate. One clinician’s treatment occurrence is work only when the A.15.1 occurrence basis obtains. Exact laboratory measurement values may be bound as arguments of one admitted calculation application, while the measurement and evidence relations that warrant their use remain separate. The returned dose-range binding records only the range returned by that application. A prescription and any materialized result episteme require their own governing claims.

Practical payoff: protocol presentation, one treatment occurrence, and the declared calculation laws can change independently.

A.6.1:5.3 - Manufacturing: fixture selection

A machining team declares a fixture-selection mechanism. Its operations filter candidate fixtures, compare admissible loading envelopes, and return a non-dominated candidate set. Laws preserve units and the partial order over constraints. The admission predicate evaluates true only when current workpiece geometry, machine envelope, and measurement qualification interval are available.

The machinist’s setup method and the dated setup work remain separate. A fixture is a system. A selector implementation may realize the mechanism for a stated scope and interval.

Positive realization in plain terms. FixtureSelectorRuntime-12-E3 realizes exact mechanism episteme FixtureSelectionMechanism-E3 for Cell7FixtureSelection-Q3 during [2026-07-01T08:00Z, 2026-07-19T14:32Z). During that interval the independently identified runtime provided filterCandidates, compareLoadingEnvelopes, and returnNonDominatedSet; every admitted use required current workpiece geometry, the current machine envelope, and a current measurement-qualification interval; and its results preserved the declared unit and constraint-partial-order laws.

If a later claim needs this positive realization occurrence, its identity is <FixtureSelectionMechanism-E3, FixtureSelectorRuntime-12-E3, Cell7FixtureSelection-Q3, [2026-07-01T08:00Z, 2026-07-19T14:32Z)>. The interval is derived, not a fourth writable participant.

Runtime contrast. FixtureSelectorRuntime-12-FastPath-E4 : U.System exposes the same three operation names but accepts a loading-envelope comparison when MeasurementQualificationCurrent is false. It therefore bypasses one declared admission condition and does not realize FixtureSelectionMechanism-E3 for that scope, even if its returned candidate set happens to match E3 in one run. A missing audit-log segment for E3 instead reopens evidence and warrant under A.10. Without demonstrated cessation or bypass, that gap does not make the world-side realization predicate false or split its occurrence, although the project may have to withhold its positive assertion until warrant recovers. Demonstrated cessation followed by later restored conformity would create a later maximal-continuous realization occurrence.

Practical payoff: the team can replace the implementation without turning a scalar convenience score into the declared ordering law, and it can reject a look-alike implementation without rewriting the declaration.

A.6.1:5.4 - FPF scope and normalization declarations

A.2.6 scope operations and A.19 normalization operations may use the U.Mechanism declaration shape when their direct patterns need reusable operations, laws, admission conditions, and typed results. A.2.6 and A.19 retain their domain semantics. A.6.1 supplies the declaration and realization distinctions; it does not redefine scope or comparison.

Practical payoff: A.2.6 and A.19 remain the governing loci for scope and normalization meaning while reusing the mechanism declaration form.

A.6.1:5.5 - Publication operations

E.24.PUB may cite a mechanism declaration for operations that assemble, validate, and expose a publication package. The mechanism episteme declares those operations, laws, and admission conditions. The dated publication work, resulting publication use, information carrier, evidence, and currentness relations remain with their direct patterns.

Practical payoff: the declaration captures reusable publication-operation semantics while the released package and carrier retain their direct kinds.

A.6.1:5.6 - Reduced ordinary use

An engineer states, “this conversion is admitted only for values in the calibrated interval.” No later claim reuses an operation family, compares declarations, identifies an actual application, or refers to a realization occurrence. The direct sentence and its governing characteristic and measurement patterns are enough. No mechanism episteme is opened.

Practical payoff: precision grows only when a receiving use needs reusable mechanism identity or an exact application binding.

A.6.1:5.7 - Recognition evaluation: Pump #37

A project repeatedly evaluates the A.1 holon-recognition criterion. In ordinary language, one bounded evaluation act applies the selected criterion to Pump #37 and returns true, false, or unknown. For this replay, resolving HolonRecognitionMechanism-E1_Ref under its effective reference scheme returns exact mechanism episteme HolonRecognitionMechanism-E1; neither label nor suffix establishes an edition relation. That episteme has SubjectKind = U.Entity, RangedValueKind = RecognitionJudgmentValue, no separate ResultKind, and operation recognizeAdmittedHolonCandidate.

RecognitionJudgmentValue is one local finite U.Kind under C.3, used here as the operation’s RangedValueKind; its membership rule admits exactly true, false, and unknown. It is an operation-local kind, not a public U-kind or universal claim-status algebra. Candidate facts, evidence status, episteme-currentness values, and receiving-work dispositions use their direct kinds. The argument and result rows are A.6.1 declarations, not A.6.5 SlotSpecs.

For this exact mechanism episteme, the declaration-local designation, cardinality, and binding predicates are:

These predicate names are local to HolonRecognitionMechanism-E1; they do not admit public binding relation kinds. Pump_37_Ref can be type-correct without a binding: the candidate predicate is current only when the exact application actually uses its resolved referent under the candidate meaning. The same rule applies to each argument, and a result predicate is current only after the application returns that value.

For this mechanism episteme, ApplicationPredicate(P) holds only when bounded evaluation act P fixes exactly one value for every required argument above, applies recognizeAdmittedHolonCandidate from HolonRecognitionMechanism-E1, and returns exactly one RecognitionJudgmentValue. Its ApplicationExtentRule sets the maximal extent from the moment all required argument bindings are fixed and evaluation begins through the terminal judgment return. Its ApplicationIdentityRule reidentifies one application by <HolonRecognitionMechanism-E1, recognizeAdmittedHolonCandidate, independently grounded evaluation-act locus, maximal application extent>. A later invocation is another application even with the same bound values. A trace token or reused work label can designate an act but cannot merge the two.

For the worked case, Pump37RecognitionApplication-2026-07-21T100000Z designates the evaluation act that began at 10:00:00 and returned at 10:00:04. It used Pump_37_Ref -> Pump_37 : U.Entity, admitted kind U.System, A1-Holons-Criterion-E1_Ref, Pump37-Construction-Facts-E1_Ref, Pump37-Reidentification-Rule-E1_Ref, and Pump37-Interpretation-Basis-E1_Ref. The six argument-binding predicates have maximal continuous extents from 10:00:00 through the terminal return. A required fastening-relation fact could not be resolved during this act, so the bound values could determine neither satisfaction nor failure. The act returned unknown; the extent of recognitionJudgmentReturned(Pump37RecognitionApplication-2026-07-21T100000Z, unknown) is the terminal return event at 10:00:04 and does not begin earlier. The application did occur; Pump #37’s world-side satisfaction or failure did not change; and unknown is not an admission refusal.

If the project also claims that dated classification Work occurred, first recover the exact actual performer S : U.System through A.13 and let A.15.1 independently admit a separate Work occurrence W from its performance history, temporal extent, at least one obtaining enactsMethod -> U.Method relation, and at least one obtaining locally declared containing-system relation with its exact boundary. Add the same obtaining A.13 assignment RA and F.6 performedUnderAssignment(W, RA) only when this classification-work claim or its receiving use expressly consumes precise assignment-bound attribution; then check S = RA.HolderSystemSlot and assignment coverage. F.6 identifies neither assignment nor performer, and missing or failed F.6 leaves W intact. The candidate application binding above can establish Pump #37’s participation in the application; add a separate work-to-candidate or resource-use claim only when its declared predicate obtains, and add workContinuityPolicyRef only when an identity or segmentation question needs it. Any materialized classification-assertion or evaluation-result episteme remains under C.2.1. Evidence and assurance support or warrant its claim content through their own relations, and G.11 tests edition currentness. That result binding records only the returned recognition judgment. Work and episteme identity, evidence and warrant, world-side criterion satisfaction, and B.2 whole reidentification each remain independently governed.

Practical payoff: another evaluation can reuse the same typed operation while binding another candidate or basis, and evidence loss can change the returned value to unknown without rewriting the candidate or criterion.