Delta Type Consumer

A change to a hole radius can travel through shape construction, intersections, patches, sampled points, and an export buffer. Each receiving stage knows a different part of that dependency. The intersection stage may know which pairs need reconsideration; the sampler may know which point records belong to a patch. Sending an accurate change description lets those receivers use their knowledge while retaining a complete computation whenever the description is insufficient.

The Base Derivatives Router architecture gives each stage that choice. Base computes the ordinary result from complete inputs. Optional derivative rules translate admitted input changes into output changes. One designated Router owns selection for that Base and returns an output delta with its work deferred. A following Router can inspect the family of that delta before requesting its complete value. Here derivative means change translation; it need not mean calculus or a small perturbation.

1 The component boundary

Write the ordinary stage as $B(x;k)$, with tracked inputs $x=(x_1,\dots ,x_n)$ and other configuration $k$. Every choice affecting the answer belongs in those semantic inputs: tolerances, ordering, random assignment, external data snapshots, and format settings included. The computation is deterministic for the captured inputs and implementation. Calling a setting fixed means fixed for this invocation. A later change to it must enter the next request or invalidate the relationship used for reuse.

One designated Router per Base is an ownership rule giving clients one incremental entry point. Several algorithms can satisfy that entry point; there is no uniqueness claim. A registry with zero derivative rules is valid: initialization and changed inputs can always use deferred full computation when their complete targets are well defined. Existing unchanged results can still use generic Reuse. Base itself contains no delta dispatch.

Figure 1 separates selection from the work it schedules.

For target tuple $x^{+}$ and configuration $k^{+}$, successful evaluation must satisfy $$\begin{array}{cc}\mathrm{Eval}(o)=B(x^{+};k^{+}),o={\mathrm{Route}}_B(\text{request}).& \hfill \text{(1)}\end{array}$$ The Router returns $o$, not the ordinary value on the right. A rule using old output additionally requires the coherent source relationship $y^{-}=B(x^{-};k^{-})$. Input baselines, old output, and source context must refer to that computation. Correct types or coincidentally equal numbers do not establish the relationship.

The examples below use exact mathematical integers and finite sequences. A numerical implementation must declare its comparison contract before accepting derivatives. Record identity and order count when observable. If a contract uses an equivalence, downstream consumers must respect it; independent local tolerances do not establish a pipeline error guarantee. Base computes values: constructing an export buffer belongs here, while writing it externally is a separate application action.

2 Delta meaning and the deferred carrier

The companion Delta Type Concept defines a delta function as a parameterized self-map $\mathrm{\Phi }:S\times P_{\mathrm{\Phi }}\to S$. A delta value $d=⟨\mathrm{\Phi },p⟩$ identifies the operation $s\mapsto \mathrm{\Phi }(s,p)$. A bound packet also retains a baseline $s$ and determines the endpoints $(s,\mathrm{\Phi }(s,p))$. An unbound reading uses the transform without consulting that baseline. These are readings of one delta concept; the same bound packet may serve an unbound consumer.

For squaring, old inputs $1$ and $-1$ both give old output $1$, yet an input Shift by $1$ produces $4$ and $0$. Old output plus that unbound Shift cannot determine the new square on all integers. A bound rule can retain $s$ and translate Shift by $h$ into Shift by $2sh+h^2$.

Family identity names an operation and its semantic spaces. Its schema describes the parameter representation. Both need checking: two operations with integer parameters are not necessarily the same operation. Registration rejects conflicting identities and incompatible schemas. A token match locates a possible rule; it does not verify the producer or prove applicability. Generic deltas need not be invertible, small, additive, or closed under composition. Useful families include $$\mathrm{Reuse}(s,())=s,\mathrm{Replace}(s,t)=t,\mathrm{Append}(s,p)=s\Vert p,\mathrm{Shift}(z,h)=z+h.$$ Append acts on finite sequences; Shift here acts on integers. Family parameters and baselines are different information.

2.1 One shared reference for each demanded value

This article proposes an immutable reference layer to make deferred work precise. It is an executable representation choice, not a change to the mathematical delta definition or a claim about an existing concrete class.

Ref<T>:
    Ready(value) or Delay(recipe, retained dependencies)
    Peek()  -> Ready(value) | Pending | Failed(error)
    Force() -> value or evaluation error

Packet<T>:
    family                  // identity, schema, action on T
    parameter: Ref<P>        // P belongs to that family
    baseline: Optional<Ref<T>>
    endpoint: Ref<T>        // derived by a trusted constructor

A delayed reference represents one fixed ordinary value on successful resolution. Family and schema are visible while the parameter remains pending. A schema may also expose certified ready fields beside deferred fields, but must specify what those fields mean. A changed-record label alone does not certify completeness of the changed keys.

Constructors derive the endpoint from the advertised action. Clients cannot attach an unrelated endpoint recipe to a plausible family. If a producer knows only a complete target reference, it can truthfully wrap it in Replace. A family unfamiliar to one Router is still usable for fallback if its retained generic evaluator defines the endpoint.

Bind(family, parameter, baseline):
    require baseline exists
    endpoint = Delay(capture family, parameter, baseline):
        return family.Apply(Force(baseline), Force(parameter))
    return Packet(family, parameter, baseline, endpoint)

BindReplace(payload):
    return Packet(Replace, payload, None, payload)

BindReuse(previous):
    require previous is a ready successful immutable Ref
    return Packet(Reuse, Ready(unit), previous, previous)

Eval(packet):
    return Force(packet.endpoint)

Generic Bind serves baseline-dependent families. Replace and Reuse avoid unnecessary operands. Each packet owns one endpoint reference, so repeated evaluation shares family application as well as parameter calculation. Memoizing only the parameter would still allow repeated concatenation of a large output sequence.

2.2 Replace keeps an ordinary payload

Replace’s semantic parameter remains $t\in T$. The carrier stores a reference $r_t$ representing $t$, rather than declaring an arbitrary closure to be an element of $T$. Thus $$\begin{array}{cc}\mathrm{Eval}(\mathrm{BindReplace}(r_t))=\mathrm{Force}(r_t)=t,\mathrm{Replace}(y,t)=t.& \hfill \text{(2)}\end{array}$$ For fallback, $r_t$ is a recipe for Base on the captured target inputs. Constructing that recipe does not execute Base. An eager-only replacement factory therefore needs a lazy adapter to implement this interface. An Append tail or Shift amount can use the same representation. If a recipe fails, evaluation reports failure; it has not produced a successful delta with a fabricated payload.

Replace requires no old output and therefore also handles first evaluation. For a later bound reading of that Replace, the receiving request may pair its parameter with the receiver’s established old input. That binding adds information without changing the constant action or its endpoint.

3 Requests, history, and context

Every coordinate has a complete target packet, even when useful change metadata is absent. Coordinate types may differ.

InputSlot:
    packet                         // target = packet.endpoint
    relation: Same | Edited | Unknown
    sourceAssociation              // relative to this frame

SuccessfulFrame:
    Base contract identity and old configuration
    immutable old input references
    output: Ref<T>                  // old, ready, successful
    auxiliary data and its determining input associations
    construction evidence for these relationships

Request:
    inputs[]: ordered InputSlot records, one per coordinate
    targetConfiguration, optional SuccessfulFrame
    explicitly named context and semantic-validity evidence

Same affirmatively establishes equality to the corresponding source input. Edited identifies a particular change at that source. Unknown supplies a valid target without an established useful relation; it never means unchanged. An unbound transform needing a baseline must be bound somewhere before its endpoint is provided. Absent storage is not an implicit baseline.

The chosen minimal policy requires a materialized successful old stage output for Reuse and specialization. Missing, failed, pending, evicted, or incoherent old output causes target-based fallback. The Router does not force old work merely to obtain history. Certified pending history is a possible extension, but requires its own success and failure protocol. Present updates still propagate lazily under this policy.

The state owner establishes a frame by completing Base or an exact output packet and retaining its associated inputs and configuration. It need not materialize every input endpoint that the successful path did not demand. The Router checks trusted construction associations rather than recomputing Base. Optional incoherent history can be discarded while independent valid targets remain available. A contradictory core packet or undefined target meaning is a request error, not merely a missed optimization.

A rule declares its information access: active input baselines, previous output, source siblings, target siblings, configuration, and auxiliary data. Source and target context are distinct. A checked bound view can expose the receiving frame’s old input for a baseline-free Replace after verifying the source association. An unbound view excludes the changing input’s baseline, including access through undeclared captures. Its own previous output is still available when declared.

Prepared context has the form $H(q,c)=A(q,P(c))$. A retained preparation must equal $P(c)$ for the actual context at consumption; retain $c$ too if application still reads it. After a dependency changes, rebuild the preparation, maintain it by an explicitly exact operation, or decline. An old index remaining allocated establishes lifetime, not validity for a new result. Preparation may serve many edits while its context is fixed, or one edit before a later change disturbs that context. Neither pattern permits a stale previous output.

New output and auxiliary indexes become a reusable frame only when their respective success and correspondence contracts hold. A returned plan alone does not replace the successful frame. If a stage’s new endpoint is never demanded, it may have no ready output for the next edit; this minimal policy then falls back or the application deliberately evaluates that endpoint first. Another option is a valid accumulated edit relative to an older retained successful frame: its whole change pattern, baselines, and context must be established relative to that frame. Merely relabeling a pending result does not establish this relationship. These are coverage and retention choices, not a hidden commitment of pending history.

4 Registration and nonforcing dispatch

A rule registration states its Base, stable identifier, complete change pattern, accepted families and schemas, bound or unbound readings, context reads, domain conditions, output family, builder, and deferred dependencies. It also declares bounded guard and construction work. For an admitted coherent request, the emitted family $\mathrm{\Psi }$ and ordinary parameter $q$ obey $$\begin{array}{cc}\mathrm{\Psi }(y^{-},q)=B(x^{+};k^{+}).& \hfill \text{(3)}\end{array}$$ The guard may admit a restricted part of an input family. The emitted family itself must be a genuine self-map family on its declared output space: a consumer defined only on a compatible source range is not automatically a global family. An exact specialized endpoint recipe can always be represented as Replace when a finer family is unavailable.

The illustrative policy here forbids guards and builders from forcing references or calling Base. They inspect identities, checked schemas, declared ready values, and sound immutable correspondence or domain evidence. Guards return Accept, Decline, or Unknown; only Accept selects a rule. Unavailable facts give Unknown. Builders allocate recipes and do declared bounded metadata work. Expensive preparation must be performed explicitly and charged to the same workload, not hidden inside dispatch.

Accept commits to the advertised family before downstream routing. A pending topology check cannot justify Append if failure might require changing its prefix. A coarser Replace can truthfully contain a delayed choice between an exact local algorithm and Base. That is an optional algorithm choice inside a fixed replacement promise, not permission to change a published family later.

4.1 Required checks follow what the consumer omits

Value identities do not authorize omission of specified semantic checks. For example, a Base that validates a shape and counts records must reject an invalid shape even when a rule predicts the same count. The issue also crosses stage boundaries: a downstream rule may read an upstream delta parameter without forcing the endpoint where validation normally occurs.

This minimal interface admits a shortcut only when the successful-domain conditions of every required semantic check it bypasses are established. The rule declares the omitted work, and trusted evidence is scoped to the actual target, configuration, and implementation. Evidence can come from completed validation or a total typed operation over certified operands. A mere boolean asserted by a caller is insufficient. Evidence is checked without Force. If any omitted check is unresolved, the shortcut declines to the complete endpoint path. This applies to invariant rules and generic Reuse as well as other derivatives, and includes omitted upstream checks.

Checks still executed on a demanded parameter path remain part of that path’s failure behavior. This article does not add a protocol for carrying new validation tickets through arbitrary projections. Such a protocol can extend coverage only after its propagation is specified. An unverified locality condition is also different from Base invalidity: valid geometry outside a local rule’s coverage must cause decline, not a manufactured late error to defend an optimistic family promise.

4.2 One deterministic route

The registry is frozen for a call, ordered by ascending rank then ascending stable identifier, with duplicates rejected. The first accepting rule wins. Rank can express a cost preference among applicable rules; it cannot ignore another change. Single-coordinate rules require all assumed-fixed siblings and configuration to be certified unchanged. Unknown siblings remain part of the complete change pattern.

Route_B(request):
    r = ValidateAndRetainTargets(request)        // no Force
    old = MatchingSuccessfulFrameOrNone(r, B)
    if old is None: return FullFallback_B(r)

    if AllInputsAndConfigurationSame(r, old)
       and BypassedChecksEstablished(r, Reuse):
        return BindReuse(old.output)

    for rule in FrozenRegistry_B ordered by (rank, stableId):
        if not rule.CoversWholePattern(r): continue
        view = CheckedDeclaredView(rule, r, old)
        if view is unavailable: continue
        if not BypassedChecksEstablished(r, rule): continue
        if rule.Guard(view) != Accept: continue
        return rule.Build(view)                 // no Force

    return FullFallback_B(r)

FullFallback_B(r):
    targets = retain [slot.packet.endpoint for slot in r.inputs]
    config = retain r.targetConfiguration
    implementation = retain this Base implementation
    payload = Delay(capture targets, config, implementation):
        values = [Force(target) for target in targets]
        return implementation(values, config)
    return BindReplace(payload)

Validation checks structural contracts and trusted associations, not arbitrary algorithm truth. A candidate-specific schema mismatch can decline while a sound generic endpoint remains usable. A broken core target cannot be repaired by fallback. All successful Router paths return packets; the only full Base call above is inside Delay. The target evaluation order and observable failure reporting follow the stage’s declared ordinary evaluation contract.

Reuse expresses an actual unchanged result. Unchanged complete inputs are one sufficient case; a registered invariant can cover a real edit. Missing history, an empty registry, and avoiding work establish no invariant. At first evaluation there is no prior output to reuse, even if an input edit is described as an identity.

5 Evaluation, errors, and ownership

Force(ref):
    if ref stores a value: return it
    if ref stores a failure: report it
    if ref is active: report dependency-cycle error
    mark ref active
    run its recipe, capturing its value or evaluation error
    store that outcome and mark ref resolved
    return the stored value or report the stored error

This is a single evaluation context over a finite acyclic graph. Concurrent forcing must preserve one shared outcome. Cancellation and transient resource retry policies belong to the runtime; a new attempt cannot silently use newer semantic inputs. Exactness does not require different algorithms to encounter identical incidental allocation failures.

Every pending recipe retains immutable references or copies of everything it can read: inputs, parameters, old output, sibling context, configuration, preparation, and selected implementation. A live scene pointer or lookup through a subsequently changed registry does not meet this contract. Later edits cannot alter an already issued target. Dependencies can be released when no pending or retained consumer needs them; long lazy chains can otherwise hold substantial geometry and index storage.

Evaluation builds private new values and never partly edits the old frame. Success permits installation with coherent auxiliary data. Failure preserves the previous successful frame. Guard decline is ordinary selection control flow; malformed requests, failed input recipes, Base domain failures, and violated accepted-rule contracts are different cases. Fallback supplies ordinary computation, not recovery from a failing Base. A false family promise cannot be repaired by silently relabeling a packet already consumed downstream. A later explicit attempt may choose Base on the retained targets.

6 A complete trace with a coverage gap

Consider finite sequences of integer points and four total stages: $$M(X)=[(x+1,2y):(x,y)\in X],E(V)=\sum _{(a,b)\in V}(a^2+b^2),Q(z)=z^2,L(w)=2w+3.$$ Start with $X^{-}=[(0,1),(2,0)]$ and materialized coherent stage outputs $$V^{-}=[(1,2),(3,0)],e^{-}=14,q^{-}=196,{\ell }^{-}=395.$$ Append $p=[(1,-1),(3,1)]$ with configuration unchanged. M registers an Append rule, E an Append-to-Shift rule, Q no derivatives, and L a bound Replace-to-Shift rule. The relevant identities are $$M(X\Vert p)=M(X)\Vert M(p),E(V\Vert a)=E(V)+E(a),L(t)=L(s)+2(t-s).$$ M and E read Append unbound: their translators need the tail and their own previous outputs, without reading the active input’s old prefix. L reads Replace bound: its old input $196$ and old output $395$ are separate fields. Its receiving frame supplies the baseline absent from Q’s replacement packet, after the source association is checked.

MapAppend.Build(view):
    p = retain view.input.parameter
    a = Delay(capture p):
        return [(x+1, 2*y) for (x,y) in Force(p)]
    return Bind(Append, a, view.previousOutput)

EnergyAppend.Build(view):
    a = retain view.input.parameter
    h = Delay(capture a):
        return Sum(x*x + y*y for (x,y) in Force(a))
    return Bind(Shift, h, view.previousOutput)

LinearReplace.Build(view):
    s = retain view.input.baseline
    t = retain view.input.parameter
    j = Delay(capture s, t): return 2*(Force(t) - Force(s))
    return Bind(Shift, j, view.previousOutput)

All guards check identity, schema, complete pattern, unchanged configuration, and coherent frames. The stated typed operations are total and their identities hold for every finite deferred tail, so there are no unresolved semantic checks on skipped endpoints. Machine integers or partial geometry would need their actual domain evidence. The builders do no new point or scalar work during dispatch.

Demanding L’s endpoint forces its displacement, then Q’s replacement. Q demands E’s scalar endpoint. E needs only old energy $14$ and the energy of the mapped tail, $8+20=28$. Q then runs its full Base on $42$ to obtain $1764$. L applies the displacement $2(1764-196)=3136$ to $395$. Ordinary full computation independently agrees: $$\begin{array}{cc}L(Q(E(M([(0,1),(2,0),(1,-1),(3,1)]))))=2(5+9+8+20{)}^2+3=3531.& \hfill \text{(4)}\end{array}$$

Neither the full new source sequence nor M’s full endpoint is demanded on this path. E’s endpoint and Q’s replacement are demanded. A later request for M’s endpoint concatenates the retained prefix with the same memoized tail: $$[(1,2),(3,0),(2,-2),(4,2)].$$ Repeated requests for a packet share its endpoint outcome.

The fallback is local: Q executes Base while L still specializes. If E also lacked its Append rule, its fallback would force M’s complete endpoint and sum all four squared distances. The answer stays the same but the demanded work changes. The tiny final affine rule demonstrates composition, not a speed advantage. Empty Append and Shift-zero remain exact identity effects; a Router need not force a tail just to discover Reuse. Without coherent history, the pipeline initializes through deferred Replace paths.

7 Combined inputs and geometric dependencies

The default policy is a joint rule for the complete pattern or one fallback on the complete target tuple. Independent old-context translations cannot generally be added. For $B(a,b)=ab$ with shifts $h,k$, the joint increment is $$\begin{array}{cc}u=hb+ak+hk,ab+u=(a+h)(b+k).& \hfill \text{(5)}\end{array}$$ At $(a,b)=(3,5)$ and $(h,k)=(2,-1)$, the old product is $15$ and the increment is $10-3-2=5$, giving $20$. Adding separate old-context increments gives $15+10-3=22$, omitting $hk=-2$.

JointProductShift.Build(view):
    a, b = retain view.oldBaselines
    h, k = retain view.shiftParameters
    u = Delay(capture a, b, h, k):
        av, bv = Force(a), Force(b)
        hv, kv = Force(h), Force(k)
        return hv*bv + av*kv + hv*kv
    return Bind(Shift, u, view.previousOutput)

An optional sequential policy first produces $(5,5)$ with output $25$, then applies the second change using updated sibling $a=5$ and intermediate previous output $25$, obtaining $20$. Both must be refreshed, as must their preparation. Under this article’s ready-history policy, the intermediate output must successfully evaluate before becoming the next frame. The default Router performs no automatic sequencing.

A sequential extension must also preserve edit order and validate intermediate domains. A valid final shape does not establish that every mixed intermediate tuple is valid. Same-coordinate composition needs an exact family law; otherwise retain its ordered endpoint recipe and publish Replace for the whole batch. The last individual delta does not by itself describe the net change. Commuting input edits also do not justify adding differences measured at the same old output.

For defeaturing, a patch Base often consumes both shapes and intersections. The new intersections were calculated for the new shapes, so neither is an unchanged sibling. A joint rule must account for their coordinated target, or Base must receive the complete new tuple. Sequentially pairing new shapes with old curves may violate the patch Base’s domain altogether.

These are contracts to establish, not a supplied topology or sampling algorithm. Enlarging a cylinder may create an intersection absent from the old dependency map. A sound target query or admitted-domain bound must establish completeness. Likewise fixed seeds alone do not preserve samples when a changed count shifts later draws from one sequential random stream. The rule must reproduce Base’s actual allocation and random assignment.

A changed-record family needs a defined action: keys to remove or replace, new records, insertion order, and behavior for absent keys. Its action must be defined on the declared record space even if correspondence to Base is guarded more narrowly. Changed keys and replacement records may remain deferred, but a downstream guard requiring ready keys declines while they are unavailable. Unknown affected sets cannot authorize an unsupported precise promise. Updated ownership and spatial indexes must match the new result or be unavailable to the next derivative; otherwise the first edit can be correct and the second wrong.

8 Cost and acceptance

Compare the same requested outputs on the same target inputs. Include capture, dispatch, guards, preparation and maintenance, forced parameter recipes, endpoint application, copying, and retained memory. Work deferred and eventually demanded still counts. An undemanded packet may save work while holding a large snapshot. A tail-only map can avoid prefix work for an aggregate, while materializing its whole output can still copy the prefix.

Record decisions separately from execution: selected rule and decline reason, family emitted, parameter and endpoint references forced, Base calls actually executed, preparation reuse, affected and copied records, retained bytes, and final-demand latency. Count sharing at actual reference boundaries. A selected fallback may never execute; a high rule-hit rate establishes neither exactness nor speed. No benchmark is asserted here.

An architect should require evidence that:

1. Base’s domain, failures, configuration, comparison, and designated Router are explicit; an empty registry supports initialization and fallback.
2. Constructors keep family, schema, parameter, baseline, and endpoint consistent. Unknown metadata is distinct from an undefined target and Same.
3. Old output and context have coherent immutable associations; missing or pending history cannot enter this policy’s Reuse.
4. Rules cover whole patterns, declare reads and omitted semantic checks, and establish their family promise before deterministic selection.
5. Dispatch counters show no Force or full Base work. Demand checks cover deferred replacement, shared endpoints, and specialization after fallback.
6. Comparisons against Base cover domain boundaries, rejected and unknown guards, first evaluation, joint edits, changed configuration, and empty edits.
7. Repeated edits verify auxiliary indexes and source associations; forcing after later live changes still yields the captured target. Failure preserves the last successful frame.
8. Cost checks use equal demand and include eventual work and retention, distinguishing useful coverage from correct but uneconomical rules.

Delta Type Concept and Prerequisite Mathematical Definitions develop the underlying delta and context terminology. Concrete Delta Type Classes choose storage mechanisms. The Group Orbit Hypothesis concerns the further empirical question of whether cheaper related generation improves a learning allocation. Producing the specified variants correctly, producing them more cheaply, and improving learning require separate evidence.