Change context or change parameters.

This is the same reference used in Technical mode. Expand it whenever you need the exact numbers, assumptions or further explanation.

Three ways to keep a calibration

Imagine a sensor whose reading needs a correction. You could leave two calibration examples in the current working context, store a correction under the sensor’s exact name, or change the predictor’s parameters. These choices can give similar outputs while leaving very different persistent state.

Here, a context-conditioned numerical predictor fits a line from two supplied support measurements. The context is not a natural-language prompt. External memory is an exact task-ID lookup, not learned semantic retrieval. Parameter adaptation changes two coefficients using a real gradient. All three see the same support evidence, and none receives the query outcomes for fitting.

Work through a small example

Let a linear task be $y=0.7x+0.2$. At x = −0.75 the supplied y is −0.325; at x = 0.75 it is 0.725. The rise between the measurements is 1.05 and their input separation is 1.5, giving slope 0.7. Their mean output is 0.2, which is the intercept because the inputs are symmetric about zero.

The context stores those two fitted coefficients. Saving them to memory stores the same pair under this task’s exact ID. Clearing context removes the current pair but leaves memory entries intact. Switching tasks clears context, preserves memory keyed to other tasks, and preserves the current weights. Querying an absent key returns an explicit missing result, never another task’s coefficients.

The parameter predictor uses $\hat y=wx+b$, where w is slope, b is intercept and the hat marks a prediction. Its objective is the average of half-squared errors on the two support measurements. Each update subtracts 0.4 times both gradients, evaluated at the same preceding w and b. Ten updates therefore reuse two observations twenty times; they do not create twenty observations.

State resets answer different questions

First load context, save it, and make one parameter update. Then clear only context and inspect four query outputs. Clear only memory next. Finally restore the initial weights. Explain each changed output by naming the state that was changed, rather than saying that the whole system “forgot.”

The initial weights come from a separate three-task meta-training procedure. Its forty outer updates differentiate through one support update. That gives an example of a learned starting point, not a universally optimal initialization. The task-family lesson compares it with zero initialization under the same adaptation budgets.

When the function class is wrong

For a curved task, the teaching rule adds $cx^2$. The two support inputs have the same squared value, 0.5625, so their line fit absorbs c × 0.5625 into the intercept. At a query x = 0.25, the actual curvature contribution is only c × 0.0625. Even an exact support fit can therefore miss the query by c × 0.5.

This is model mismatch, not proof that memory or gradient descent is broken. Query errors remain public development evidence once inspected. The tables keep exact numerical outcomes available without requiring motion or interpreting a color. In Project 14, justify when updating context or memory is sufficient and when a parameter change earns its extra cost.