Estimate and graph "insulin activity"

[mortenfyhn]

An idea that builds on #22

I've been thinking, to make treatment decisions, wouldn't it be neat to have a graph, I guess in this context on the watchface, that shows the insulin activity over time? Meaning how much the insulin is working to push BG down at a given point in time. So after a bolus, it'd start flat, rise to some peak insulin activity, and then taper off to zero again. Especially useful, I hope, to time temporary target or strategic pump suspend to match the reduced insulin activity with planned physical activity.

I've been working a little bit on this, so I'll drop some robot-written context/info below.

[mortenfyhn]

Here's one variant of this, after some discussion with one AI model:

🤖 AI written, obviously

---

Insulin Activity Curve — implementation brief

A handoff note for a coding agent. It describes what to compute and why; the agent knows the target environment, language, and data plumbing.

---

1. Goal

Plot a curve of insulin activity — the rate at which insulin is currently acting to lower blood glucose — on the same time axis as the CGM trace, with both a historical and a forward-projected portion.

The forward portion is the point of the whole exercise. Motivating use cases:

• Before exercise: verify that insulin activity will be low throughout the planned activity window. Because insulin action lags delivery by roughly an hour, this decision has to be made well in advance; by the time activity starts, the pressure is already committed.
• Around meals: verify that a bolus produces activity that overlaps the expected carb absorption window.

Current IOB alone does not answer either question — see §3.

---

2. Definitions

Term	Meaning	Units
IOB (insulin on board)	Insulin delivered but not yet acted. Equivalently, the remaining BG-lowering effect still queued up. Jumps discontinuously at each delivery.	U
Insulin activity	The rate at which that effect is being delivered right now. activity(t) = −dIOB/dt. Zero at the moment of injection, rises to a peak, decays to zero.	U/h
tp	Time-to-peak of the activity curve.	min
td	Duration of action — age at which a dose is fully spent.	min

activity is the standard term (it's the literal variable name in OpenAPS/AndroidAPS; papers sometimes write IA). The equivalent quantity measured experimentally in clamp studies is GIR (glucose infusion rate), so that's the curve to look at when sanity-checking tp/td against literature.

Note the terminology collision with physical activity. In UI copy and comments, consider "insulin activity" always spelled in full, or "insulin pressure" as an unambiguous informal label.

---

3. Why current IOB is insufficient

Two states with identical IOB = 2.0 U project completely differently:

• one fresh 2 U bolus → nearly all the effect is still to come
• four older doses totalling 2 U → mostly spent, activity already fading

Current IOB would determine the future only if the decay were a pure exponential (the memoryless property). The pump's curve is S-shaped, so it isn't. The delivery history is required, not just the current IOB value.

---

4. The computation

The model is linear and time-invariant: every unit behaves identically regardless of when it was delivered or what else is on board. So everything is a convolution of the delivery history with a fixed kernel.

Let:

• f(a) = fraction of one unit remaining at age a — the pump's IOB decay curve, f(0) = 1, f(td) = 0
• k(a) = −f′(a) = activity kernel, fraction of a unit acting per unit time at age a. k(0) = 0, peaks at tp, ∫₀^td k = 1.

Then for delivery events (tᵢ, dᵢ):

IOB(t)      = Σᵢ dᵢ · f(t − tᵢ)          for 0 ≤ t − tᵢ < td
activity(t) = Σᵢ dᵢ · k(t − tᵢ)          for 0 ≤ t − tᵢ < td

Evaluate on a 5-minute grid, from a few hours back to td ahead.

Forward projection is the identical sum evaluated at t > now with no new delivery events added. That is the honest "committed" curve: what will happen from insulin already in the body. In SmartGuard the pump will keep micro-bolusing, so real future activity will sit somewhat above this — but the committed curve is the one that answers "can I still act on this?"

Optionally add a scenario mode later: continue delivery forward at some assumed rate and compare curves.

Deriving the kernel

The user has the exact IOB curve used internally by the MiniMed 780G. Use that as f, and derive k from it:

• if f is given as a formula → differentiate analytically
• if f is a lookup table → differentiate numerically on a fine grid

This is a one-time offline step on a clean, smooth curve, so there is no noise problem. (Do not instead numerically differentiate the logged IOB time series — at 5-minute logging resolution that's noisy and would need smoothing.)

Fallback kernel

If the pump curve turns out to be unusable, the standard Loop/AndroidAPS exponential parameterised by tp/td is a reasonable substitute:

τ = tp·(1 − tp/td) / (1 − 2·tp/td)
a = 2τ/td
S = 1 / (1 − a + (1 + a)·exp(−td/τ))
k(t)   = (S/τ²)·t·(1 − t/td)·exp(−t/τ)                                  # per minute

f(t)   = 1 − S·(1 − a)·[ (t²/(τ·td·(1−a)) − t/τ − 1)·exp(−t/τ) + 1 ]

Make tp and td configurable. Typical starting values for fast analogues: tp ≈ 75 min, td ≈ 360 min. td is the knob most worth tuning — 6 h makes the tail look longer than most people's felt experience.

---

5. Data sources (MiniMed 780G)

• Delivery events — all of them, in one stream: boluses, SmartGuard micro-boluses (every 5 min in Auto Mode), and autocorrections. Do not treat these as separate categories; for activity purposes a unit is a unit.
• Reported IOB — available continuously; used for validation (§6), not as the primary input.
• CGM trace — for the overlay.

Resolution caveat — check this early

The near-term shape of the curve depends on having micro-bolus deliveries at 5-minute resolution. If the export (CareLink or otherwise) only provides hourly basal totals, the most recent hour — the part that matters most — gets smeared into a block. Establish what granularity is actually obtainable before building on top of it.

SmartGuard note

In Auto Mode the pump does not follow the user's configured basal profile; the algorithm replaces it with model-driven micro-boluses. The profile applies only in Manual Mode. This is why the design uses gross (total) activity rather than activity net of scheduled basal — netting against a baseline that isn't being delivered would be meaningless.

---

6. Validation

Before trusting the forward projection, reconstruct IOB from the delivery history and compare against the pump's own reported IOB series:

IOB_reconstructed(t) = Σᵢ dᵢ · f(t − tᵢ)

• Match → the event log and the curve are both correct, and the forward projection inherits that confidence.
• Drift → delivery events are missing or the curve is wrong. Worth catching before the graph is trusted for decisions.

This is cheap and should probably be a standing check, not a one-off.

---

7. Units and display

• Units: U/h. Do not multiply by ISF. Converting to mmol/L per hour was considered and rejected: ISF is the noisiest parameter in the chain, and it's precisely the one that shifts during exercise. Keeping the curve on the insulin side is honest about what's actually known.
• Plot beneath/behind the CGM trace, shared time axis, with the forward portion visually distinguished (dashed, lighter, or a "now" divider).
• The user is building a custom display and will handle presentation — the requirement here is the correct series, evaluated forward.

Deferred (discussed, intentionally not in v1)

Start with the raw curve and live with it for a couple of weeks; real numbers will make these easier to specify than estimating them up front.

• Neutral reference line. Zero is a true floor but the wrong anchor for judging "low" — at zero activity, BG rises from endogenous glucose production. The physiologically neutral level is roughly where insulin action cancels liver output, i.e. near basal-equivalent delivery. Candidate implementations: recent TDD/24, or a 7-day trailing mean of the activity curve at the same time of day (adapts to diurnal variation in insulin need).
• Committed vs controllable shading. Shade now → now + tp, the region already determined by insulin in the body. Makes the lead-time constraint legible at a glance.
• Carb overlay. Carb absorption in g/h scaled by 1/ICR lands in U/h too, so both curves share an axis and meal matching becomes area-vs-area.

---

8. Caveats to carry into the model's interpretation

• Linearity breaks down for large doses (subcutaneous depot saturation) and varies substantially with injection site and between individuals.
• Exercise raises insulin sensitivity and can accelerate subcutaneous absorption. The same activity curve therefore produces a larger BG drop than during rest. The curve tells you when the pressure lands, not how hard — it understates risk during activity rather than overstating it.
• Published tp/td values are population averages.

This is a personal visualisation tool, not a dosing calculator. It should not compute or suggest doses.

[mortenfyhn]

🤖 Written by Claude at Morten's request.

What the number should be

"Insulin activity" is worth splitting into three different curves, because the interesting one is not the one the pump gives us.

1. IOB, units still outstanding. This is what the pump reports. It is an accounting quantity for the bolus calculator, not a physiological one.
2. Activity, -d(IOB)/dt, in U/h. How fast insulin is leaving the "outstanding" account.
3. Effect, activity × ISF, in mmol/L per hour, and its integral, the glucose drop still to come.

For the use case in the issue body, timing a temp target or a suspend against a dip in insulin action, curve 2 is the shape to plot and curve 3 is the number to read. "1.8 U on board" needs mental arithmetic before it means anything; "still coming: -3.4 mmol/L" does not.

The pump's own curve is not a pharmacodynamic curve

We fitted the 780G's IOB decay from a clean lunch bolus (~4.25 U, 2026-08-21, spike v51 flash log, SAKE: IOB N mu per read):

• An oref-style exponential IOB curve fits with DIA ≈ 130 min and peak ≈ 42 min, RMSE 1.5% of the bolus. A linear decay is about 4x worse.
• The pump then clips straight to zero at its Active Insulin Time setting (observed at 116 min against AIT = 2 h) rather than running out the tail.
• IOB is quantized to 0.025 U, which is the configured bolus increment.
• Autocorrections appear in IOB as +0.15 U steps. Auto-basal micro-boluses never appear.

So the pump's model peaks at 42 min and is over in 2 h. Fiasp clamp studies put peak glucose-lowering action later than that and duration at 4 to 6 h. The two disagree because AIT is a stacking guard, not a claim about how long the insulin works. We should not build the activity graph on the pump's curve.

Use the Loop/oref exponential model instead

The same two-parameter exponential (peak time, action duration) is what Loop, oref0 and AndroidAPS all use, so there is a known-good implementation to copy from. LoopKit has presets in ExponentialInsulinModelPreset (ExponentialInsulinModel.swift, InsulinMath.swift); the Fiasp preset is roughly peak 55 min, duration 360 min, against 75/360 for generic rapid-acting adult. AndroidAPS's Ultra-Rapid Oref plugin uses peak 55 as well. Worth reading the current values out of the repo rather than trusting these numbers.

Suggested starting point for a Fiasp user: peak 55 min, duration 360 min, evaluated as a lookup table rather than a formula, since the watch has no reason to compute exponentials repeatedly.

The hard part is the dose ledger, not the curve

To project activity forward we need every unit delivered, with a timestamp. Four possible sources:

a. IOB steps. Rises in the IOB trace are boluses and autocorrections. Available today with no new protocol work, but bolus-only, so it misses every auto-basal micro-bolus. In SmartGuard that is a large fraction of total insulin, and it biases the estimate low in exactly the situation where you are deciding whether to add more insulin.

b. Reservoir differencing. Morten's suggestion, and it looks like the best one available now. Reservoir Remaining Amount (f32, IU) is already in IDD Status and already parsed on-watch as reservoir_mu in minimed_status.c (logging only, not displayed). Evidence from the v55 full-day log:

• Resolution is 0.025 IU, the same quantum as IOB, so individual micro-boluses are resolvable.
• SmartGuard micro-boluses show up directly. From 15:34 onward: 149700, 149625, 149550, 149475, 149425 mu at 5-minute intervals, which is 0.075, 0.075, 0.075, 0.05 U per 5 min, about 0.85 U/h of auto-basal.
• Insulin not delivered during a suspend is handled for free, since the reservoir simply stops falling. No reference basal rate needed, which is the thing that made the history-event approach awkward in SmartGuard.
• It captures everything without needing to attribute it. For an activity model that is fine, since all the insulin is the same insulin.

Three things to handle:

• Reservoir changes and priming. Same log, 06:51 res=0, 07:06:01 res=166000, then 07:06:12 res=159750 and 07:06:24 res=159150. That is 6.85 U consumed by fill and prime in 23 seconds, none of which reaches the body. A jump up must reset the ledger, and the burst right after it must be excluded. The cannula-fill event (history 0x08) is the cross-check.
• res=0 is "unknown", not "empty". It appears while the reservoir is detached during a set change.
• Time resolution depends on our read cadence, not the pump's. In the same log the value changes every 5 min during the afternoon but only twice between 23:34 and 06:30. Whether that is read cadence or push behaviour is untested. IDD Status Changed bit 2 is Reservoir Status Changed, so in principle we get a push per change. Worth confirming before relying on the timestamps.

c. IDD history events (0xf001 auto-basal micro-bolus, 0x0099 basal rate change, 0xf00a/0xf00b stop/restart). Exact and attributed, but gated on the RACP-over-IDD-History backfill, which is still deferred.

d. GET_DELIVERED_INSULIN (0x03c0/0x03cf) and GET_TOTAL_DAILY_INSULIN_STATUS (0x0395/0x039a). Present in the opcode list, no parser, no documentation, never probed. If either returns a cumulative delivered total, it beats reservoir differencing because it is immune to reservoir changes and priming. Probing them is a cheap read-only experiment.

Useful property of (a) and (b) together: reservoir differencing gives total delivered, IOB steps give the bolus-only part, and the difference is the basal side. That is a free cross-check on both, and it also answers #22 directly.

Sketch

1. Ledger: ring buffer of (timestamp, milli-IU) impulses covering the last 6 h, fed from reservoir deltas with priming and reservoir-change filtering.
2. Curve: Fiasp exponential as a lookup table, 5-min bins.
3. Activity: convolve the ledger with the curve, project forward 6 h. Cheap; the buffer is at most a few hundred entries.
4. Effect: multiply by ISF for a mmol/L timeline. Start from the pump's own ISF setting.
5. Display: activity curve for timing decisions, remaining-drop number for bolus decisions.

Validating it against our own CGM

The parameters should not be taken on faith from a Loop preset. We have CGM every 5 min and now a complete dose ledger, so the curve can be fitted:

• Take isolated corrections with no carbs for 3 h either side and no exercise, normalize dBG/dt by dose, stack and average.
• If the traces agree, fit peak and duration. If they scatter, per-dose variance dominates and a fancier model will not help.

Confounds worth stating up front:

• SmartGuard fights the measurement. The loop responds to the same excursion being measured, which is why the ledger has to include micro-boluses rather than just the bolus.
• CGM lag, roughly 5 to 15 min, will push the fitted peak later than a clamp study would. For this purpose that is correct: the goal is predicting the number on the watch, so the lag belongs inside the kernel. It does mean the fitted peak should not be compared directly against published Fiasp numbers.
• Dose size matters. Larger doses absorb more slowly and last longer, so a curve fitted on 4 U corrections will not transfer to 1 U ones.

Whatever comes out is our estimate with our own model, not Medtronic's, and the display should say so.

Open questions

1. Does IDD Status Changed bit 2 push on every reservoir change, or is the 5-minute cadence above just our read cadence?
2. What do 0x03c0 and 0x0395 return?
3. Reservoir resolution is 0.025 IU here, matching the configured bolus increment. Is it tied to that setting, or is 0.025 fixed?
4. Does a temp target or a suspend show up in the reservoir trace cleanly enough to drive the exercise use case, or is the 5-minute granularity too coarse?

[mortenfyhn]

🤖 Written by Claude at Morten's request.

Insulin activity curve: design

Settles the open choices from the two briefs above and turns them into a build order. Where the two disagreed, the reasoning for the choice is given.

1. Model

Unchanged from the implementation brief, which is right about the core. Linear and time-invariant: a ledger of delivery events (tᵢ, dᵢ) convolved with a fixed kernel k(a), normalized so ∫₀^td k = 1, evaluated on a 5-minute grid.

activity(t) = Σᵢ dᵢ · k(t − tᵢ)     for 0 ≤ t − tᵢ < td

Forward projection is the same sum evaluated at t > now with no new delivery events added. Gross activity, never netted against a basal profile, because in SmartGuard the configured profile is not being delivered.

Units are U/h. The brief's argument against multiplying by ISF wins: ISF is the noisiest parameter in the chain and it is exactly what shifts during exercise, which is the use case driving the whole feature. Keeping the curve on the insulin side is honest about what is actually known.

2. Two kernels, two jobs

The implementation brief says to use the pump's own IOB curve as f and differentiate it. That is the one place it should not be followed.

What we have is not the 780G's internal curve. It is a fit to the pump's displayed IOB, and the display is an accounting quantity for the bolus calculator: AIT-scaled, and hard-clipped to zero at the AIT setting. Measured on a clean 4.25 U bolus, it is well described by an oref-style exponential with DIA ≈ 130 min and peak ≈ 42 min (RMSE 1.5% of the bolus), then clipped at 116 min against AIT = 2 h.

Differentiating that gives a curve which asserts that insulin action peaks at 42 minutes and is completely over after two hours. For Fiasp neither is true, and for exercise planning the error is in the unsafe direction: it says the pressure is gone while it is still landing.

So the brief's own fallback becomes the primary, and the pump curve keeps a narrower job:

• k_fiasp drives the display. The Loop/oref exponential parameterised by tp and td, starting at tp = 55 min and td = 360 min (LoopKit's Fiasp preset, and AndroidAPS's Ultra-Rapid Oref uses peak 55 as well). Both configurable, both fitted against real data in phase 2.
• f_pump (tp 42, td 130, clipped) is used only to reconstruct IOB when validating the delivery ledger. It never reaches the display.

This also resolves the brief's validation step. Reconstructing IOB and comparing against the pump's reported IOB validates the ledger, and only when reconstructing with f_pump. It says nothing about whether the display kernel is right. Those are separate checks.

3. Where the deliveries come from

The brief worries that an export might only give hourly basal totals, which would smear the most recent hour. Reading live over BLE, that concern does not apply, and the resolution is better than it feared.

The source is reservoir differencing. Reservoir Remaining Amount (f32, IU) is in IDD Status and is already parsed on-watch as reservoir_mu in minimed_status.c. From the v55 full-day log:

• Resolution is 0.025 IU, the same quantum as IOB, so individual micro-boluses are resolvable.
• Micro-boluses are directly visible. From 15:34 on: 149700, 149625, 149550, 149475, 149425 mu at 5-minute intervals, which is about 0.85 U/h of auto-basal.
• Insulin not delivered during a suspend needs no special handling, since the reservoir simply stops falling. No reference basal rate is required, which is what made the history-event approach awkward in SmartGuard.
• It captures boluses, autocorrections and micro-boluses in one stream without needing to attribute them, which is what the brief asks for: for activity purposes a unit is a unit.

Why the current logs look sparse

Worth recording, since it was open question 1 on this issue. The comment at minimed_sake_read.c:563 already notes that bit 2 of IDD Status Changed, Reservoir Status Changed, "rides every microbolus". But the read path only re-reads status on bits 0, 1 and 16. The reservoir is therefore sampled only as a side effect of suspends and SmartGuard transitions, which is why the overnight gap in the v55 log is hours wide.

The ledger should be push-driven rather than polled: one status read per bit-2 push is one reservoir sample per micro-bolus, with the pump deciding when there is something to look at.

4. Build order

Phase 1: logging build

Add MINIMED_IDD_FLAG_RESERVOIR (1ULL << 2) to minimed_idd_flags.h and to the trigger set at minimed_sake_read.c:563. About five lines. The res=%ld mu log line already exists and the 0x101 flag word is already logged, so sample provenance is derivable from the dump.

Cost is roughly 12 extra SAKE status reads per hour in Auto Mode. Risk is low relative to the v57 hard-fault: this changes which pushes trigger an existing read path, it does not add logging inside a BLE callback.

Soak about a week. Hardware checklist:

1. Reservoir samples arrive at roughly 5-minute cadence in Auto Mode, confirming the bit-2 comment.
2. A manual bolus appears as a single large delta.
3. A set change is captured, so the prime burst is characterised on more than the single instance we have.
4. Overnight cadence matches daytime, ruling out the observed gap being push behaviour rather than trigger selection.

Phase 2: offline prototype

Python against the dump, before any of this reaches C.

Reservoir deltas become a ledger, with three filters: a level increase means a reservoir change, res=0 means unknown rather than empty, and deltas inside the priming window after an increase are discarded. The one set change captured so far shows why: 06:51 res=0, 07:06:01 res=166000, then 07:06:12 res=159750 and 07:06:24 res=159150. That is 6.85 U of fill and prime in 23 seconds, none of which reaches the body.

Free cross-checks:

• IOB step rises should coincide with bolus-sized reservoir deltas. Reservoir total minus the bolus-derived part is the basal side, which answers Compute total IoB (including basal) #22 as a by-product.
• Reconstruct IOB from the bolus-only ledger using f_pump and compare against reported IOB. A match means the ledger is complete; drift means deliveries are being missed.

Then fit tp and td of k_fiasp against CGM response on isolated corrections: no carbs for 3 h either side, no exercise, normalize dBG/dt by dose, stack and average. If the traces scatter, per-dose variance dominates, and the honest answer is to keep the Loop preset and say so.

Two things to keep in mind while fitting. CGM lag of roughly 5 to 15 minutes will push the fitted peak later than a clamp study would, and that is correct here, because the goal is predicting the number on the watch, so the lag belongs inside the kernel. It does mean the fitted peak should not be compared directly against published Fiasp figures. And SmartGuard responds to the same excursion being measured, which is why the ledger has to include micro-boluses rather than just the bolus.

Output is a lookup table, not a formula.

Phase 3: on-watch

New module minimed_activity.{c,h}, pure and host-testable under tools/minimed_sake_hosttest, following the minimed_iob and minimed_idd_flags pattern. Three entry points: feed a reservoir sample, sample the curve onto a grid, load and store the ledger. Roughly 300 to 400 lines of C plus tests.

• Ledger is a ring buffer of (uint32 ts, int16 milli_iu), 256 entries. Six hours of SmartGuard is about 72 micro-boluses, so there is headroom for boluses and autocorrections.
• Kernel is a static const fixed-point table at 5-minute steps out to td.
• Persistence. The ledger is accumulated state: reservoir differencing tells you what changed since the last sample and nothing about what came before it. A reboot or a long disconnect would otherwise leave an empty ledger drawing a flat zero-activity curve, which is wrong in the unsafe direction. So the ledger is written to flash and replayed on boot. Flash wear at one write per 5 minutes still needs checking against what the settings layer does about it. This is the one implementation question the design does not answer.
• Gaps. A sample arriving more than 10 minutes after the previous one marks the span unknown, distributes the delta across it as a flat rate, and sets a provisional flag that clears once the gap is older than td.
• Priming. A reservoir level increase starts a 5-minute window in which deltas are discarded. The ledger is not cleared, because insulin already delivered is still in the body. This is a heuristic, and it will also discard a bolus given inside that window, which is rare and happens at a moment you know about.

Phase 4: protocol and display

New capability in pebble-glucose-protocol, announced like the others. The firmware computes the convolution and sends the sampled series; the watchface only draws. The insulin model appears in exactly one place.

Payload is a uint8 array on a 5-minute grid, about 36 points back and 72 forward, at 0.05 U/h per LSB. That gives a 12.75 U/h ceiling, which a 10 U bolus does not approach, at a resolution finer than a 144-pixel-wide display can show. Plus grid_minutes, now_index, count, and a flags byte carrying the provisional state. About 115 bytes, sent on the same cadence as the recomputation.

Sending the ledger instead was considered and rejected: it would put the insulin model into every watchface that wants the feature, and a SmartGuard day carries about 200 micro-boluses in 6 hours.

5. Not in v1

Deferring the implementation brief's list, and agreeing with its reasoning that two weeks of looking at the raw curve will specify these better than guessing now: mmol/L conversion, neutral reference line, committed-versus-controllable shading, carb overlay, scenario mode.

6. Known error sources

• Cannula fill outside the priming window consumes insulin that never reaches the body.
• Linearity breaks down for large doses, and absorption varies with site and between individuals.
• Reservoir differencing establishes that insulin left the reservoir, not that it reached the body.
• Published tp and td values are population averages, which is what phase 2 is for.
• Exercise raises insulin sensitivity, so the same activity curve produces a larger BG drop than at rest. The curve says when the pressure lands, not how hard.

This is a personal visualisation tool, not a dosing calculator. It computes and suggests no doses.

[mortenfyhn]

🤖 Written by Claude at Morten's request.

Correction to the design above: the ledger is RAM-only. Scratch the flash persistence in phase 3.

The reasoning that changed:

• A pump disconnect never needed flash. The watch stays up, the RAM ledger survives, and the existing gap rule covers it: distribute the delta flatly across the gap, flag the curve provisional.
• Flash therefore only buys the reboot case, and since v55 fixed the hourly assert-reboot those are rare. A write every 5 minutes forever is a bad trade against a rare event.
• Retained RAM would have been the middle path, but PebbleOS has no noinit or retained section for it, and adding one means editing stock linker files. Not worth it for this.

So on boot the ledger starts empty and the curve is marked provisional until 6 h of samples have accumulated, reusing the flag the gap case already needs. A fresh boot draws a curve that is honestly incomplete rather than a confident flat zero, which was the property the persistence was there to protect.

This also removes the one implementation question the design left open, since the flash wear question no longer arises.

If phase 2 shows reboots are more common than expected, two fallbacks: write every 30 min instead of every 5, losing at most half an hour of detail, or seed the ledger from the pump's reported IOB on boot, which recovers the magnitude of the bolus side but not its timing.

Nothing else in the design changes.