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.