# Loading it back

**🟠 Advanced · Lesson 18**

THE LOADING HALF - and the one place in melder where a successful return deliberately does NOT mean what you would assume.

TWO PLACES A CHECKPOINT CAN LIVE created an id exists in the running crystallizer cached it has been SEALED to the local cache create_checkpoint() gives you the first. flush_checkpoint() moves it to the second - and, if a persistence manager is attached, tries to ship it onward too.

flush_checkpoint(id=None) -> list[str] seal, then ship list_cached_checkpoint_ids() what is sealed locally reload_cached_checkpoint(id) -> dict read one back verify_checkpoint_chain(...) -> dict is the lineage intact delete_cached_checkpoint(id) -> str drop one

NOW THE TWO WARNINGS, BOTH FROM MELDER'S OWN CONTRACT.

1. A SUCCESSFUL FLUSH DOES NOT PROVE THE REMOTE RECEIVED ANYTHING.

"THE REMOTE LEG IS LENIENT BY DEFAULT. Under the default posture an [error is tolerated and] a successful return does NOT prove the remote received anything - the local seal is [what you actually get]."

Everywhere else in this tier melder refuses rather than substituting (lessons 06/13/14/17/18). HERE IT IS DELIBERATELY LENIENT, and the reason is sound: a network you do not control should not be able to fail your local checkpoint. But it means flush() returning cleanly guarantees the LOCAL SEAL and nothing about the remote.

If you need remote confirmation, the return value of flush() is not it. Knowing which half of a two-part verb a return value covers is the difference between a backup and the belief in one.

2. FLUSHING CAN EVICT SOMETHING ELSE.

"The FIFO cap means an old cached checkpoint can be EVICTED AS A SIDE EFFECT."

So flush is not purely additive. The cache is bounded, and sealing a new checkpoint may silently retire your oldest. If a specific checkpoint matters, do not assume it is still cached - list_cached_checkpoint_ids() is the check, and it is cheap.

THE TIER'S CLOSING IDEA Every lesson from 09 onward has been about the same discipline: know exactly what a call promises. Two bits instead of one. Names instead of contents. A refusal instead of a partial application. And here, at the end, a verb that is honest about covering two legs with different guarantees.

## Before you run

Use the [Advanced guide](../../advanced/index.md) for prerequisite concepts. Run from a checkout with Melder installed and Python 3.14 free-threading selected. The collection download includes the level's local helper modules.

## Run the saved script

```bash
python UX_and_AIX_experiences/03_advanced/18_loading_it_back.py
```

```powershell
py -3.14t UX_and_AIX_experiences/03_advanced/18_loading_it_back.py
```

{download}`Download this collection <../../downloads/advanced-examples.zip>` · [Source on GitHub](https://github.com/Synaptic724/melder/blob/a30a754d0bb61db0b142936010cdb82cffecec6f/UX_and_AIX_experiences/03_advanced/18_loading_it_back.py)

## Public surface

flush_checkpoint, list_cached_checkpoint_ids,
                   reload_cached_checkpoint, verify_checkpoint_chain,
                   delete_cached_checkpoint

## Code

```{literalinclude} ../../downloads/03_advanced/18_loading_it_back.py
:language: python
:linenos:
```

## Check the outcome

The script contains its own assertions or demonstrated refusal paths. Run it to evaluate those checks against your installed version. The code above is taken directly from the saved file; no run output is invented here.

[More advanced examples](index.md) · [Level guide](../../advanced/index.md)

## Related guides

- [Checkpoint and cache entry points](../../advanced/checkpoints.md)