C.29:4 - Solution - selected answer

C.29:4.1 - Construct and test the correspondence

1. State the working question. Name the quantity, relation, distinction or possibility that would change the next action. Recover the intended use and the precision or range it needs.
2. Choose a concrete mathematical object. Specify its elements, variables, relations, operations and constraints. Use the least costly adequate local theory or construction. A family name is a discovery cue; if no object is yet available, keep a candidate and name the next observation or construction.
3. Establish the correspondence. Say what each relevant element or operation represents and in what direction the inference is used. Distinguish an analogy, a fitted representation, a simulation and an exact structure-preserving map. State the assumptions, scale and context that the correspondence requires.
4. Determine what the correspondence preserves, omits or introduces. Identify the structure on which the intended result relies and any omitted distinction that could change it. Establish the preservation claimed for the needed operations. If the receiving domain adds objects or operations, determine which of their results answer the source question. C.29.1 constructs these comparisons, including cases with no loss of source distinctions and cases where a receiving solution has no source counterpart.
5. Do the mathematical work. Calculate, derive, construct or demonstrate the obstruction. For a missing computational formulation or procedure, use C.29.2; for an unsettled connection to an executing system, use C.29.3. Return the result through the correspondence to the working question. A statement that a queue “exposes bottlenecks” is not yet the bottleneck calculation.
6. Choose the resulting action and its limit. Use the result within its assumptions, collect a discriminating observation, compare a relevant rival, narrow the question or reject the representation. Test the material loss and changed premises. When another person or later use needs the account, retain the smallest sufficient record under :4.4.

C.29:4.1.1 - Transfer the result through the operations

A source operation or result is available, and you need to use it through another representation. Use C.29.1 - Mathematical Result Transfer to recover the operation and its permissions, compare performing then mapping with mapping then performing, and test whether choosing another represented source case changes the answer.

Its Solution constructs a transferable consequence, a justified bound or a specific repair of the correspondence. It also separates a receiving operation that gives a useful relaxation from one whose result can be realized as a source action. The reservation and route-cost entries in :7.1–:7.2 lead to its worked constructions.

C.29:4.1.2 - Construct a computation for the question

The needed answer is identified, but the available representation and operations do not yet explain how to obtain it. Use C.29.2 - Computational Formulation to select the distinctions retained in computational state, construct a procedure or solver formulation, establish the claimed result and estimate the cost that matters to its use.

Its Solution starts from either a question or available computational means. Worked cases develop an interpreter, a bounded root calculation, a memory-limited quantum-state representation, two questions about the same circuit, and a probability estimate. The result is a usable computation under stated conditions or the missing construction that prevents it.

C.29:4.1.3 - Realize the computation and read its result

A computation is available, but how a concrete system performs it is unsettled. Use C.29.3 - Computational Realization to connect input preparation, system actions and result interpretation, then compare the required result with the interpreted execution. For a design calculation, the comparison uses the supplied system model; a claim about an actual run uses its observations.

The result is a conditional realization, an interpreted result or a located failure in preparation, operation or readout. Digital, analog, stochastic and manual arrangements can enter through the same question. Its robot, analog addition and admission-card cases show repairs of range, scale and shared-state conditions. B.5.MPC coordinates these results with the physical account, mathematical construction and receiving action.

C.29:4.2 - Mathematical Lens Use Principle

A mathematical lens is useful for a stated question when its correspondence preserves the structure needed for an actual consequence and makes the material losses explicit. A proof under mathematical assumptions establishes that consequence inside the model. Reliance on the phenomenon additionally requires the correspondence and application conditions to hold; prediction and other model-bearing uses require their validation under :4.5a.

Plain phrases such as “what survives transfer” can guide recognition. For a used result, make the actual correspondence, preserved structure, loss and stopping condition recoverable. Include a blocked overread only when it passes F.19’s plausible-reader test.

C.29:4.2a - When mathematicalization pays

Introduce a representation when it changes what can be derived, compared, observed, constructed or ruled out for the working question. An adequate ordinary calculation may already supply the answer. If no useful consequence or next inquiry follows, keep ordinary prose or the domain result; no C.29 output is required.

C.29:4.2b - Discover a candidate from the working cue

Choose the row that fits the problem, or use a closer domain construction. The menu is informative; when a listed construction is used, its named mathematical elements and conditions must be supplied. The shared test is :4.1, not membership in this list.

For a constrained extremum or stationary construction, construct or reuse a family of allowed candidates and calculate the resulting change in the target quantity. Distinguish an improving candidate, a necessary stationary condition and a justified optimum; carry the resulting conclusion and its assumptions into the working question.

For a symmetry argument, follow the transformation through the problem’s data, conditions and required answer. Derive the transferred solution, restriction or obstruction to selection, and say which problem that consequence answers.

When a balance must be constructed or its boundary changes, C.29.BB identifies the additive quantity, included stores and crossing transfers. It combines compatible accounts and returns the total, a bound or the missing contribution.

For a first candidate, compare with ordinary prose, direct observation or the accepted domain model before a broader survey. When the question is a tradition-scale source synthesis, use G.2; C.29 needs only the candidate or rival relevant to this working question.

When expected information gain determines which observation to obtain, choose a feasible way to estimate it. If density approximations are used, allocate samples between fitting them and computing the expected gain. In high dimensions, consider reducing the parameter or observation space and account for the information lost by that reduction. Compare estimation cost and error with the distinction needed for the choice. Li, Baptista and Marzouk (2026) develop these sample-allocation and dimension-reduction choices.

C.29:4.2c - Bounded-observer structural-information lens

Use this subcase when a mathematical lens estimates, compresses, codes, compares, or otherwise exposes how much selected structure a bounded observer can recover from a description, relation trace, generated graph, model, or reusable-structure accounting result. Typical examples include MDL-like two-part codes, epiplexity-style extracted-structure estimates, compression-complexity comparisons, and information-functionals over relation graphs.

C.2.8 defines extractable structural information for the episteme, expressing form and observer under stated conditions. When this lens output is used to estimate that characteristic, state how its mathematical objects, admissible models, selected structure and resource bound correspond to those conditions. A comparison that uses an adequate domain method directly needs no mathematical lens.

For an epiplexity estimate, distinguish the selected model’s description length from the residual data description, the model-execution bound from estimation effort, and conditional model information from all familiar structure a reader can recover. Use the existing source, mapping, preserved/lost-structure and stop fields to state the correspondence. The formal model and its application conditions are explained in C.2.8:4.6; a numerical measurement claim also uses C.16.

Minimum record:

MathLensUse.StructuralInformationLensUse@Context:
  TargetPhenomenon:
  SourceEpistemeOrTraceRef:
  BoundedObserverRef or observerBoundary:
  CandidateMathObject:
  LensMappingMode:
  PreservedStructure:
  LostStructure:
  VisiblePayoff:
  ObservationBoundary?:
  PostulateBoundary?:
  SourceReturnCondition?:
  LensUseBoundaryValue:
  declaredLensUse:
  StopCondition:
  blockedLensOverread?:

When the target is a physical, organizational, or project-world situation, the record must say whether the structural-information claim is observational, postulated, simulated, or only a description-local compression. When the lens is used in architecturing, C.30 governs architecture as EntityOfConcern, C.30.ASV governs structural-view adequacy, C.30.AD governs architecture descriptions, and C.31 or C.31.RSA governs modularity or reusable-structure accounting. C.29 records only the declared lens use: what recoverable structure the mathematical lens makes visible, what it loses, and where that use stops.

C.29:4.2d - Architecture-local lens descriptions

Architecture work may use C.29-local descriptions for graph, flow, control, structural-information, RG or coarse-graining, and multilevel-learning or frustration lenses.

MLU.Description@RGArchitecture applies only when the use names a declared aggregation scope, scale variable or scale window, coarse-graining rule, preserved structure, lost structure, source-return condition, declared use, and stop condition. Include a blocked overread only when it passes F.19’s plausible-reader test. If the claim becomes a scale-preference claim, C.31.ASAP governs the architecture preference side; C.29 keeps the declared mathematical-lens use.

Minimum RG architecture description:

MLU.Description@RGArchitecture:
  TargetPhenomenon:
  CandidateMathObject:
  LensMappingMode:
  ScaleWindow?:
  CoarseGrainingRule?:
  PreservedStructure:
  LostStructure:
  VisiblePayoff:
  SourceReturnCondition?:
  declaredLensUse:
  NextLensUseAction:
  StopCondition:
  blockedLensOverread?:

For architecture work, a common RG-shaped candidate object is:

A_l = (Holons_l, FunctionalRelations_l, FlowRelations_l, ControlRelations_l,
       ModuleRelations_l, InterfaceSpecificationRefs_l, DependencyEdges_l,
       WorkMethodRefs_l, EvidencePackageRefs_l, QualifierRefs_l)

R_l : A_l -> A_{l+1}

InterfaceSpecificationRefs_l contains only governed U.EpistemeRef values that resolve independently identified InterfaceSpecification epistemes under the identifying rule located at A.6.M. The references, their resolution, and the specification content remain separate; changing a lens token or retargeting a reference does not edit the specification.

The index _l is a declared aggregation-scope index inside this C.29 lens, not a generic level, tier, layer, or ladder. Each use names the aggregation scope, the coarse-graining rule, the lost structure, and the source-return condition.

MLU.Description@MultilevelLearningFrustration applies only when the use names declared holon levels or declared scopes, a mapping between them, conflicting constraints or residuals, preserved structure, lost structure, and the nearest neighboring FPF pattern for any measurement, causal, evidence, assurance, work, selected-set, or decision claim.

Minimum multilevel-learning and frustration description:

MLU.Description@MultilevelLearningFrustration:
  TargetPhenomenon:
  CandidateMathObject:
  LensMappingMode:
  PreservedStructure:
  LostStructure:
  VisiblePayoff:
  declaredLensUse:
  NextLensUseAction:
  SourceReturnCondition?:
  StopCondition:
  blockedLensOverread?:

Declared lens use: triage, explanation, candidate generation, rival-lens comparison, scale-window reasoning, source-return triggers, and architecture-decision rationale only when the neighboring pattern defines or constrains any non-C.29 claim. Stop or return when the mapping, scale window, preserved structure, or source basis no longer supports the use. A causal-proof, assurance-score, or necessary-complexity-growth claim needs its own argument and source basis. Apply C.11, C.28, B.3, C.16, G.5, or the applicable stakeholder or ethics pattern when its respective non-C.29 claim is current. Include a project-wide-optimizer or other blocked overread only when it passes F.19’s plausible-reader test.

C.29:4.3 - Use boundary

Use C.29 for a consequential choice or transfer of mathematical representation. Ordinary equations, data structures and accepted domain models remain usable directly when no such issue is open. A separate causal, measurement, dynamics, semantic-bridge or other claim uses its subject pattern under :4.4.6.

Use structure-preserving representation in discoverability-bearing prose unless equivalence or identity is explicitly the justified mapping mode.

C.29:4.4 - Record the result for its receiving use

First complete or delimit the mathematical move in :4.1. Record its question, concrete object, correspondence, retained and lost structure, consequence and next action when another reader or later reliance needs them. Choose the smallest sufficient form below; a form does not replace a missing construction, derivation or observation.

One reliance rule. A conditional derivation, diagnostic comparison or reusable explanation may remain a MiniCard when it retains the same object, assumptions, correspondence, loss and narrow use, and its consequence is used to understand the model or choose the next inquiry. A FullCard is required when the result is relied on as an adequate model of the phenomenon for prediction, an operational or consequential decision, model adoption, benchmark or assurance input, Bridge-dependent reliance, or transfer as a reusable model to further cases. It then needs the applicability, rival and validation information relevant to that reliance. Publication or repetition of the same conditional explanation alone does not change its class.

Keep adequate existing domain/model documentation and refer to it; FullCard means a recoverable full account, not recopying that information into a blank form. Reassess the same rule whenever the intended use or reliance changes.

Application output classes:

Micro-template examples:

Architecture and P2W first-use slice:

MathLensUse.LensCandidateNote@ArchitectureP2W := {
  TargetPhenomenon: cooling-fixture deformation problem accepted as a problem-side distinction,
  ProblemStructureCue: heat-flow balance, boundary condition, interface reference plane, and deformation residual change the next architecture or method-choice question,
  CandidateLensFamily: boundary and variational heat-flow lens,
  CandidateMathObject?: temperature field with boundary-condition relation and optional energy functional,
  WhyThisLensCouldHelp: the lens can expose whether the useful distinction is a preserved heat-flow invariant, a boundary-condition mismatch, or a deformation factor outside the model,
  ExpectedVisiblePayoff: a net heat-flow imbalance would require stored-energy change; a balanced total alone would still leave the spatial gradient needed for the deformation question unresolved,
  ObservableOrControllableCue?: boundary temperatures, heat-flow observations, reference-plane assignment, deformation readout,
  NextLensUseAction: define the fixture control volume and heat paths; compare measured inflow and outflow, then obtain spatial temperatures and mechanical constraints before deriving deformation,
  OrdinaryRivalOrFallback: ordinary deformation narrative plus local measurement note,
  StopCondition: keep this as a candidate until the heat balance and temperature-to-deformation correspondence are specified; return to the deformation question when omitted gradients or constraints can change its answer,
  NextMathLensUseOutput: MathLensUse.OneLine or NeighborGoverningPatternNote
}

The heat balance is the proposed first mathematical operation. A formal vocabulary/law declaration uses A.6.0 only when that separate declaration is needed; carrying accepted problem-side distinctions into later work uses E.18.1. The receiving conditions are stated in :4.4.6.

MathLensUse.LensCandidateNote example := {
  TargetPhenomenon: slow Product-X team flow,
  ProblemStructureCue: waiting and work-in-progress look more important than individual task difficulty,
  CandidateLensFamily: queue or flow lens,
  CandidateMathObject?: single-server or multi-server queue candidate,
  WhyThisLensCouldHelp: arrivals, service time, WIP, and waiting time could expose the bottleneck,
  ExpectedVisiblePayoff: decide whether delay is arrival-rate, service-rate, batching, or WIP-boundary pressure,
  ObservableOrControllableCue?: arrivals, service time, wait time, WIP limit,
  NextLensUseAction: observe the variables before claiming queue adequacy,
  OrdinaryRivalOrFallback: ordinary process narrative without queue assumptions,
  StopCondition: stay with the candidate note until observations support queue adequacy; use the ordinary process narrative if the queue candidate does not change the next action,
  NextMathLensUseOutput: NoMathLensUseNeededNote or MathLensUse.OneLine after observation
}

MathLensUse.OneLine example := {
  TargetPhenomenon: Product-X backlog delay,
  CandidateMathObject: queue model over arrivals, service time, waiting time, and work in progress,
  LensMappingMode: representation,
  PreservedStructure: flow, bottleneck candidates, wait, WIP, service-rate pressure,
  LostStructure: motivation, priority politics, contractual duties, skill learning, quality of work,
  VisiblePayoff: identify whether delay is arrival-rate, service-rate, batching, or WIP-boundary problem,
  NextLensUseAction: observe arrivals, service, wait, and WIP; test one local WIP-limit or batching hypothesis,
  ObservationOrReadoutNeeded?: service-time and wait-time observations,
  OrdinaryRivalOrFallback: process narrative without queue assumptions,
  StopCondition: return to the process narrative or choose another lens when observations do not support the queue representation or its declared losses prevent the next action
}

Worked conditional queue comparison. A production manager asks whether speeding station A would raise the line’s output, or whether the next investigation should focus on B. Use an authored, stipulated case: identical jobs arrive at a_n = 10n minutes, starting with n = 0, and pass through A then B. Both stations have one server, first-come-first-served non-preemptive service, no failures or rework, and an unbounded intermediate queue in the model. For a finite run the same calculation applies while its actual buffer does not fill. Transfer time is zero. A takes 10 minutes per job; B takes 15. The line starts empty.

The mathematical object is a deterministic two-station tandem queue. A job represents one part; an arrival is its release to A; service is uninterrupted processing at the named station; a departure from A is the arrival at B. This preserves order, routing, occupied service time and interstation waiting. Variable product mix, stoppages, rework and finite-buffer blocking are omitted. The network correspondence and the importance of blocking are introduced in Wu’s queueing-network lecture, slides 9 and 23–24; the following deterministic numbers and derivation are constructed here.

A job can start only after it has arrived and the previous job has left that station. With previous departures initialized to zero, its departure times therefore obey:

d_A(n) = max(a_n, d_A(n−1)) + 10
d_B(n) = max(d_A(n), d_B(n−1)) + 15
d_A(−1) = d_B(−1) = 0

The recurrence gives d_A(n) = 10n + 10 and d_B(n) = 15n + 25: after its first arrival B remains occupied. The output spacing is 15 minutes, hence the long-run rate is 4 jobs/hour. The station-capacity bound is min(6, 4) = 4 jobs/hour, attained in this stipulated run. Latency is d_B(n) − a_n = 25 + 5n minutes. It keeps growing; the calculation supplies no finite steady-state mean delay.

Now halve A’s service time to 5 minutes while leaving the arrivals and B unchanged. The same recurrence gives d_A(n) = 10n + 5 and d_B(n) = 15n + 20. The rate is still 4 jobs/hour; each job’s latency falls by 5 minutes but still grows with n. The useful distinction is between a shorter initial traversal and a higher sustained output rate. The next inquiry is therefore to observe B’s service, interruptions and queue growth, and test whether its assumed restriction describes this line. An observed-output dashboard is the ordinary fallback and a complementary check; output counts alone do not derive the two station-change scenarios.

Use and return. This is a MiniCard-level conditional derivation and comparison, reusable with the same premises. It directs observation, not a capacity commitment about an unvalidated line. Actual prediction, equipment selection or operational reliance uses :4.4’s full applicable account and :4.5a’s validation. Keeping A’s original 10-minute service, if an omitted inspection adds 5 minutes to every B service, B’s service becomes 20 minutes: d_B(n) = 20n + 30, the rate is 3 jobs/hour and latency is 30 + 10n. Withdraw the 4-job/hour and 25 + 5n results. If finite storage instead blocks A, reconstruct the blocked-service recurrence before reusing the schedule.

MathLensUse.OneLine := {
  TargetPhenomenon,
  CandidateMathObject,
  LensMappingMode,
  PreservedStructure,
  LostStructure,
  VisiblePayoff,
  NextLensUseAction,
  ObservationOrReadoutNeeded?,
  OrdinaryRivalOrFallback,
  StopCondition
}

For MathLensUse.OneLine, VisiblePayoff says what the lens makes visible, such as a bottleneck, invariant, obstruction, incompatibility, loss boundary, or diagnostic split. NextLensUseAction says the now-bounded user-facing action, such as compute a local quantity, compare only inside a declared structure, run a validation slice, apply a neighboring pattern, keep the phrase as local metaphor, or remove the phrase from claim-affecting use. ObservationOrReadoutNeeded? names the missing observable, readout, assignment, outcome, validation slice, or scale point needed before the repaired line makes the stated action usable. OrdinaryRivalOrFallback says what the reader would use without this mathematical lens: ordinary prose, accepted local domain theory, direct measurement, a causal model, a queueing model instead of a quantum-like metaphor, an A.19 space declaration instead of C.29, or an F.9 bridge instead of category-like wording. If two mathematical lenses already change the next action at this cheap-output class, add one ordinary-language note about the disagreement and use MathLensUse.MiniCard or MathLensUse.FullCard before claiming a reusable rival-lens relation.

MathLensUse.LensCandidateNote := {
  TargetPhenomenon,
  ProblemStructureCue,
  CandidateLensFamily,
  CandidateMathObject?,
  WhyThisLensCouldHelp,
  ExpectedVisiblePayoff,
  ObservableOrControllableCue?,
  NextLensUseAction,
  OrdinaryRivalOrFallback,
  StopCondition,
  NextMathLensUseOutput
}

MathLensUse.LensCandidateNote is a cheap first-candidate lens selection note. Its successful next outputs are NoMathLensUseNeededNote, MathLensUse.OneLine, or a named neighboring subject-pattern note.

Do not use MathLensUse.OneLine with an empty CandidateMathObject. If the candidate object has not yet been named, use MathLensUse.LensCandidateNote first, keep ordinary prose, or write a NeighborGoverningPatternNote when a non-lens claim is being made.

Cheap stop: if the mathematical phrase does not affect any claim beyond orientation, do not use the full card. If the first honest output is NoMathLensUseNeededNote, that is a successful C.29 result, not an underfilled card.

C.29:4.4.1 - Output set and declared-use boundary

Use the single output/reliance rule in :4.4. The form states the mathematical account; a used empirical, causal, semantic-bridge, assurance or decision result additionally needs its subject-pattern basis in :4.4.6.

LensMappingMode, LensUseBoundaryValue, and declared lens use are separate fields.

LensMappingMode names construction, not permission. Typical local values include representation, abstraction, quotient, coarse-graining, embedding, homomorphism, isomorphism, functor-like transfer, simulation, and learned or fitted representation. A broad family name such as graph, field, category, geometry, quantum-like, variational, or Bayesian is only a prompt until the concrete construction and preserved structure and lost structure are named.

LensUseBoundaryValue declares only a limited lens-use boundary:

State the declared lens use in declaredLensUse and its stopping or return boundary in StopCondition. Elegance, familiarity, source prestige, and mapping type supply no substitute for that declaration. Include blockedLensOverread? only when it passes F.19’s plausible-reader test.

C.29:4.4.2 - From lens to local action

A consequence can direct a new observation, make a bounded comparison possible, expose a bottleneck or obstruction, or reject a candidate representation. State which of these happens and why. If the requested result is a plan, decision or other neighboring result, supply the mathematical consequence to that result under :4.4.6.

Worked local bottleneck: dense-state storage. A proposed dense pure-state representation for 50 qubits contains 2^50 complex amplitudes. At a stipulated 16 bytes per amplitude, its array alone requires 16 × 2^50 = 2^54 bytes, or 16,777,216 GiB. A 64 GiB implementation cannot hold it. Counting the representation’s elements and multiplying by storage per element identifies this bottleneck before implementation.

Recover the requested observable or property, then reconsider which structure must be represented. A restricted case, another representation or a justified approximation may change the resource demand; estimating each actual candidate’s storage and work can change the choice. When a particular representation change has been chosen, A.6.3.RT:4.1 supplies the conversion and preserved/lost-content check. Until a suitable domain algorithm is supplied, the present result is rejection of the dense implementation and a specific representation question. Ordinary storage arithmetic alone needs no lens card.

C.29:4.4.3 - No-lens entry: choosing a first candidate lens

Use this when the next lens-use action can benefit from a mathematical lens but no adequate mathematical object has been named. The output is MathLensUse.LensCandidateNote, not MathLensUse.OneLine and not a full card. State the ProblemStructureCue, choose one cheap CandidateLensFamily, say what it could make visible, name the ObservableOrControllableCue? when available, state the NextLensUseAction, compare it with the OrdinaryRivalOrFallback, and stop if no action changes. If the cue is still pre-articulation and no stable ProblemStructureCue can be named, do not mathematize it; preserve cue plurality through C.2.LS, A.16, A.16.1, B.4.1, B.5.2.0, or the relevant language-state pattern before applying C.29.

Use the single discovery menu in :4.2b. Compare one candidate with the ordinary fallback; broaden the search only when this comparison leaves a material question unresolved. Asking what can be observed or varied does not by itself require a measurement or experiment record; apply its subject pattern when constructing that result.

C.29:4.4.4 - First honest C.29 entry cases

For E.11-style first-entry recognition, distinguish the working entry case before choosing an output:

C.29:4.4.5 - False-positive bank and entry stops

An ordinary ODE in physics, a Markov kernel in local stochastic dynamics, a graph data structure, an A.19 distance/topology/order/embedding, a category-theoretic proof internal to its domain, or a one-off teaching metaphor needs no C.29 output merely because mathematics appears. The same applies to Markov-blanket wording used only to recognize a physical interface or boundary already recovered through its subject pattern.

Enter C.29 when a separate representation or transfer issue affects the result: unexplained waiting may need a queue construction; an important comparison may need a distance with explicit losses; transferring the same graph between contexts may need both mathematical correspondence and F.9 semantics. A learned representation used for scientific explanation needs :4.5a’s observation and validation conditions. A scale claim needs the applicable scale-law or preference argument in :4.4.6.

If the cue is still “something is off” and no stable structural question can be named, keep the language-state work open under :4.4.3. An inconclusive candidate, a rejected lens, an ordinary local answer and a receiving subject-pattern result are all useful stopping points.

C.29:4.4.6 - Subject-pattern boundary table

Use this table when the mathematical result contributes to a separately governed question. Name that question and the first receiving action; cite the existing result when it already supplies the needed basis.

CandidateMathObject names the mathematical object used in the representation. State its correspondence and preserved and lost structure in the accompanying account.

For a relation claim with clear participants and meaning, apply the current direct relation pattern’s rule and use its result. If the rule needs an unavailable case fact, identify that fact and leave the claim unresolved pending it. Use A.6.P when the relation or participant meaning remains unclear; use A.6.RCD only after recovery when no current direct predicate can state the needed claim. Explicitly identify an obtaining relation occurrence under its direct identity rule only when a receiving claim or operation must distinguish that occurrence.

Use A.6.0’s FormalSubstrate profile when a separate declaration of vocabulary, laws, imports and applicability is needed. Apply A.6.1 for mechanism import or realization of that declaration, and E.18.1 when accepted problem-side material needs the declaration carried into later work. The same mathematical object may be designated in several epistemes or uses; select the subject pattern for the actual object and claim.

C.29:4.5 - MathLensUse.Card@Context shape

The full card collects the account needed for a declared reliance under :4.4. MathLensUseOutputRef may reference any applicable C.29 output; its use does not require a FullCard. Local naming conditions are in :6.1a.

Read MathLensUse.Card@Context through three aspects:

MathLensUse.FullCard base fields:
MathLensUse.Card@Context := {
  TargetPhenomenon,
  entityOfConcernRef?,
  BoundedContext,
  CandidateMathObject,
  LensMappingMode,
  PreservedStructure,
  LostStructure,
  InvariantsExposed,
  LensBoundedPredictionOrDistinction?,
  LensUseBoundaryValue,
  declaredLensUse,
  StopCondition,
  blockedLensOverread?
}

Conditional fields apply only when the corresponding neighboring claim, claim-bearing use, or publication use is being made:

MathLensUse.FullCard conditional fields := {
  DynamicsRef?,
  TransitionLawRef?,
  ObservationMapRef?,
  ScaleWindow?,
  CoarseGrainingRule?,
  SourceReturnCondition?,
  PublicationUseClassification?,
  PrincipalRivalLens?,
  RivalLensSet?,
  RivalLensRelation?,
  ValidationUseOverlayRef?,
  LearnedLensOverlayRef?,
  BridgeRefSet?,
  CausalUseDisposition?,
  AssuranceUseDisposition?,
  ExportPolicyRef?
}

Plain card gloss. A useful mathematical lens says: what phenomenon is being seen, through which mathematical object, by what mapping, what survives, what is lost, what becomes visible, what lens-use boundary value and validation boundary make this use bounded, the now-bounded user-facing action, any justified blocked user inference, and where the lens stops.

C.29:4.5a - Conditional overlays

Apply overlays for the actual reliance selected in :4.4. A conditional calculation within a stipulated model still states and checks its mathematical assumptions; a claim that the model is adequate for the phenomenon additionally requires the validation account below. A learned representation needs the learned-lens information even when the exploration remains small.

MathLensUse.ValidationUseOverlay@Context :=
⟨
  ClaimUse,
  ValidationRegime,
  EvaluationSlice,
  ApproximationOrUncertaintyNote,
  KnownFailureCaseOrCounterexample,
  SensitivityOrRobustnessNote?,
  DomainOfApplicability,
  OutputChangeCondition?
⟩

Use the validation overlay for the FullCard reliance in :4.4: prediction about the phenomenon, an operational or consequential decision, adoption of a model, benchmark/assurance input, Bridge-dependent model reliance, or transfer as a reusable phenomenon model. This includes a scientific claim of model adequacy. A published explanation of a conditional derivation needs its derivation and assumptions, not an empirical-adequacy claim invented for it. LensUseBoundaryValue alone is insufficient for the stronger reliance. Keep the neighboring notions separate: verification is proof or formal checking under stated assumptions; validation is fit for a declared use and regime; calibration aligns model parameters or readouts with observations; explanation states why the lens makes a distinction intelligible. The C.29 output does not let any one of these four labels silently stand in for the others.

To evaluate a probabilistic prediction, choose a scoring rule appropriate to its forecast form. Use a proper rule when the score should favor reporting the assessed distribution without distortion in expectation. The Brier loss for binary events and logarithmic scores for predictive densities are examples. State which direction is better and compare forecasts against the same observations. Gneiting and Raftery (2007) explain these scoring choices.

MathLensUse.LearnedLensOverlay@Context :=
⟨
  DataOrTrainingRegime,
  ObservationMapRef,
  GeneralizationClaim,
  DiscretizationOrResolutionPolicy?,
  ValidationRegime,
  ApproximationOrUncertaintyNote,
  StopCondition
⟩

Use the learned-lens overlay when the mathematical object is fitted, learned, latent, simulation-trained, data-derived, a neural operator, a surrogate solver, an embedding, or a world-model representation.

For DataOrTrainingRegime, identify the data’s origin, what the collection includes and omits, how observations were collected and transformed, and the recommended uses and limitations. Use those facts to judge the proposed generalization or narrow it. Datasheets for Datasets supplies questions for recovering these conditions; select those relevant to the present use.

Use the following learned-lens stop variants when the declared use reaches the corresponding boundary. Include a separate guard only when it passes F.19’s plausible-reader test:

MathLensUse.CausalAbstractionCheck@Context :=
⟨
  LensMappingMode,
  InterventionStructureStatus ∈ {preserved, approximated, notClaimed},
  CounterfactualUseStatus ∈ {preserved, approximated, notClaimed},
  C28ApplicationRef?
⟩

This is not a first-class causal abstraction card. It is a lightweight check: when LensMappingMode is abstraction, quotient, coarse-graining, macro-model, or simulation, and declaredLensUse would include intervention, policy, counterfactual, or causal explanation, apply C.28 for causal-use question and verdict.

For causal explanation through a learned representation, state which variables and interventions correspond between the models, then compare their results under those interventions. For approximate agreement, specify the similarity measure, the distribution of evaluated interventions and the way similarities are aggregated. Decoding a variable from an activation shows that the decoder can recover it; a claim that the variable affects the model’s behavior needs the intervention comparison. Geiger et al. (2025), §§2.4, 3.2 and 3.6.3 develop these distinctions.

C.29:4.5b - Repair decision table