A custom rule must be a compatible linear derivative map

Start with the real-valued primal map, input and output shapes, dtype assumptions, and the domain where it is differentiable. A square root has a different derivative domain from a polynomial, while an approximate iterative solver can represent either its executed iterations or a separately defined implicit solution map. Those are different mathematical targets. A stable analytic rule can avoid an unstable implementation path without changing the derivative target, but a clipped or straight-through sensitivity generally defines a surrogate and should be labeled as such rather than presented as the ordinary derivative.

A custom JVP accepts an input tangent and returns an output tangent; a custom reverse rule accepts output cotangents and returns compatible input cotangents. Required residuals must correspond to the same forward evaluation. PyTorch 2.9's custom Function guidance describes saved context, mutation marking, and explicit double-backward support. JAX's pinned autodiff documentation likewise treats derivative transformations as composable operations. Framework conventions differ, so distinguish mathematical requirements from the selected version's registration and transform-support rules. Avoid assuming a custom backward automatically supports forward-mode transformations or every higher-order composition.

At a fixed differentiable input, derivative propagation must be linear in the incoming seed. A rule that squares a tangent or clips an output cotangent violates that requirement unless the operation being defined is explicitly another non-derivative procedure. Zero, sum, and scaled-seed checks can expose such errors cheaply. Passing them still does not prove the derivative is correct: multiplying every tangent by the wrong constant is linear too. Combine algebraic contracts with hand-derived examples and independent numerical directional checks on valid smooth inputs.

Boundary conventions require equal care. A framework may select a particular subgradient for a nonsmooth primitive, but that does not make the original function classically differentiable there. Invalid-domain forward operations can also produce undefined gradients even if a later mask hides their output. A custom rule should not silently invent physical meaning for NaN or out-of-domain values. State whether unsupported inputs raise an error, propagate an invalid result, or use a declared approximation, and verify that the convention composes as intended with batching and higher-order derivatives.

Test several inputs, seeds, scales, shapes, and degenerate cases allowed by the contract. Check accumulation through repeated uses and whether saved intermediates preserve the graph dependencies needed for a second derivative. If higher-order support is absent, reject it explicitly rather than returning a plausible constant by accident. A rule can be correct for one scalar seed of one and fail when the output is batched or weighted. Keep versioned tests around the actual public transformation combinations the application uses, including any limitations on sparse layouts or mutation.

The quadratic lab supplies a true analytic rule to compare against. Reset, set BOTH a=1 and x=1, predict slope two, then Play or Step. Reset and re-set BOTH a=2 and x=1; predict slope four. For either fixed input, compute two-seed linearity on paper using slope times v. Edits retain t; playback traces y=ax² and does not install a custom rule or run a checker. A correct demonstration for this scalar family does not validate a cubic, solver, boundary convention, or arbitrary custom kernel.