@@ -14,7 +14,7 @@ the same pull request that causes it.
 
 | Path | Holds |
 |---|---|
-| `src/` | The pybind11 binding, 47 `.cpp` and 47 `.hpp`, compiled into the `rexlib._binding` extension |
+| `src/` | The pybind11 binding, 51 `.cpp` and 51 `.hpp`, compiled into the `rexlib._binding` extension |
 | `python/rexlib/` | The Python package, 11 `.py`: everything the binding cannot express |
 | `tests/` | pytest suites, mirroring the binding's module structure |
 | `tests/assets/` | Two dummy plugins, built by CMake, that the plugin tests discover |
@@ -71,7 +71,7 @@ name that names them. See #143.
 | `_binding.dispatch` | `src/core/dispatch/` | `ExecutionContext`, `Dispatcher`, `ProgramManager` |
 | `_binding.concurrency` | `src/core/concurrency/` | `Executor` and its two kinds, `Completion` |
 | `_binding.functional` | `src/functional/` | The operations, each taking an explicit context |
-| `_binding.em.image` | `src/em/image/` | `ImageLocation`, the format managers and reader providers, the sources, `read`, `write` and the shape queries |
+| `_binding.em.image` | `src/em/image/` | `ImageLocation`, `ImageDescriptor`, `IndexTable`, the format managers, the reader and writer providers, the source and the sink, and the functions of `image_read.hpp` and `image_write.hpp` |
 
 A submodule is created by the `main.cpp` above it, which then hands it to the
 `bind_` function of the directory it stands for: `src/main.cpp` creates `em`
@@ -89,7 +89,7 @@ the order the declarations need.
 | `_device.py` | `rexlib.device(...)`, the `with` block that activates one |
 | `_functional.py` | The operations again, with `context` defaulting to the active one |
 | `_ndarray.py` | Installs the Python operators onto `Array` |
-| `em/` | The electron microscopy areas, one module each; `em/image/` defaults the format manager and the context |
+| `em/` | The electron microscopy areas, one module each; `em/image/` defaults the formats, the reader provider and the context, and assembles sources and sinks |
 
 `_paths` is imported first in `__init__.py`, and the order matters: on Windows
 nothing else imports until the bundled library is findable. `_ndarray` is
@@ -99,13 +99,30 @@ imported for its side effect, before anything can hand out an `Array`.
 than carrying one of its own, so `read` asks for an active device exactly as
 `zeros` does and there is one place to change if that ever stops being the
 rule. Two things about those functions are rexlib's and not this package's:
-`em::read` allocates on the host whatever device is active, and `em::write`
-refuses storage the host cannot reach instead of transferring it. Both are
+`em::read` allocates on the host whatever device is active, and the writes
+refuse storage the host cannot reach instead of transferring it. Both are
 stated in their docstrings, since a caller has no other way to find out.
 
+Only what the functions of `image_read.hpp` and `image_write.hpp` need is
+bound. A reader, a writer, a format, a transfer plan and a sanitizer have no
+Python counterpart, so `ImageSource` and `ImageSink` are bound without the
+`read` and `write` that take them, and `ManagedImageWriterProvider` without
+`acquire`.
+
+A collaborator the package defaults moves behind the arguments it does not:
+`em::write(arr, path, manager, descriptor)` is
+`write(array, path, descriptor, manager=None)`. A function with nothing to
+default is re-exported as the binding has it, which is how
+`read_batch_async` and `write_batch_async` arrive.
+
+The helpers that assemble collaborators are nouns: `reader_provider`,
+`writer_provider`, `source` and `sink`. `sink` takes its writer provider
+rather than assembling one, since whoever writes keeps it to declare the
+files and to close them.
+
 `image_metadata` is not bound. rexlib declares it empty, so the parameter is
-left off `write` until the type has fields; adding it later is compatible,
-and publishing an empty class now would not be.
+left off the writes and off `declare` until the type has fields; adding it
+later is compatible, and publishing an empty class now would not be.
 
 ## Building
 
@@ -249,16 +266,16 @@ written, which is rexlib's to do rather than this binding's;
 
 A binding that blocks releases the GIL with
 `py::call_guard<py::gil_scoped_release>()`. `Completion.wait`, `Completion.get`
-and `ImageBatchSource.read` all do: held through a read, the GIL would freeze
-every other Python thread for its duration and there would be nothing
-asynchronous left about the interface. pybind11 converts the arguments before
+and everything in `em.image` that reaches a file all do: held through a
+read, the GIL would freeze every other Python thread for its duration and
+there would be nothing asynchronous left about the interface. pybind11 converts the arguments before
 the guard is constructed and the return value after it is destroyed, so
 nothing touches Python without it.
 
 `rexlib::array` is move-only, and anything taking one by value has to be given
-`destination.share()` rather than the caller's own. Bound plainly, pybind11
-would move the array out of the Python object and hand the caller back an
-empty one.
+`destination.share()` rather than the caller's own, or `source.share_const()`
+where it takes a `const_array`. Bound plainly, pybind11 would move the array
+out of the Python object and hand the caller back an empty one.
 
 A type rexlib parses from a string carries a `from_string` static method and
 no constructor that parses. `DeviceIndex` and `ImageLocation` both do, and
@@ -350,7 +367,7 @@ Tests for what `_binding` exposes at its top level stay at the root.
 | `tests/hardware/` | Devices, sessions, events, memory resources, the session pool |
 | `tests/dispatch/` | `ExecutionContext`, the active context, `rexlib.device(...)` |
 | `tests/functional/` | The operations |
-| `tests/em/image/` | `ImageLocation`, parsing, the format managers, `read` and `write` |
+| `tests/em/image/` | `ImageLocation`, `ImageDescriptor`, `IndexTable`, the format managers, the providers, the synchronous reads and writes and the asynchronous ones |
 
 There are no `__init__.py` files and no `conftest.py`. Test module names are
 therefore unique across the whole tree, and a fixture belongs to the file that
 
@@ -4,7 +4,7 @@ Work whose shape is settled and only waits to be scheduled. Everything here
 has a known method; nothing here is waiting on a judgement call. Open
 questions live in [DECISIONS.md](DECISIONS.md).
 
-Reviewed 20 Sep 2026, against rexlib-python `abb3000` and rexlib `ce67271d`.
+Reviewed 1 Oct 2026, against rexlib-python `cec13df` and rexlib `3d7fb23f`.
 
 ## 1. Bind the rest of `functional`
 
@@ -56,43 +56,42 @@ One trap before `compare` lands: a type that defines `__eq__` and no
 rexlib, so the comparison operators need an answer about identity before they
 go in.
 
-## 3. Bind the patch source
-
-`image_patch_source` arrived with the batch source upstream and crops batches
-of patches out of an image, clipped at the borders. The batch source is bound;
-this one is not, and it stands on the same chain, so it is a smaller piece of
-work than the first was.
-
-## 4. Translate the library's exceptions
+## 3. Translate the library's exceptions
 
 There is no `py::register_exception` anywhere in `src/`, so everything rexlib
-throws arrives through pybind11's catch-all. `invalid_operation_error` derives
-from `std::logic_error` and `image_format_error` from `std::runtime_error`,
-neither of which pybind11 special-cases, so both land as a bare
-`RuntimeError`.
-
-This cost nothing while the surface a caller could fail against was small. It
-no longer is: a missing file, a format nothing recognises, a truncated file
-and an array the host cannot reach are four different mistakes that a caller
-meets routinely through `em.image` and cannot tell apart.
+throws arrives through pybind11's catch-all. `image_file_error`,
+`image_format_error`, `unsupported_operation_error` and
+`unsupported_capability_error` all derive from `std::runtime_error`, which
+pybind11 does not special-case, so all four land as a bare `RuntimeError`.
+
+rexlib now tells them apart, and the binding throws that away: a file that
+cannot be reached, a file whose contents contradict its format, a format
+nothing recognises and an array the host cannot reach are four different
+mistakes that a caller meets routinely through `em.image` and cannot tell
+apart. What already arrives well is what rexlib throws as a standard
+exception: an index past the end of a stack is an `IndexError`, and a
+destination of the wrong shape a `ValueError`.
 
 The cheapest visible win is a missing file arriving as `FileNotFoundError`. It
-reaches `image_read_format_manager::open` as "no registered format recognizes
-the file", which is true but is not what went wrong and is not what anyone
-will search for.
+is an `image_file_error` in rexlib, raised with the path at the front of its
+message, and a `RuntimeError` here.
 
 Register the types once where the module is built so every submodule inherits
 them; translate only what genuinely corresponds to a Python builtin and give
 the rest types of their own; the tests under `tests/em/image/` currently
 assert `RuntimeError` and follow.
 
-## 5. Zero-copy exchange with the array ecosystem
+## 4. Zero-copy exchange with the array ecosystem
 
 `Array` can now be measured and printed, but nothing can be handed to anything
 else: there is no buffer protocol, no `__array__`, no DLPack. Loading batches
 at speed and receiving objects that cannot leave the package is a pipeline
 without an exit.
 
+It is also why the tests under `tests/em/image/` assert shapes, types and
+failures and never a value: a patch clipped at a border, or a batch read back
+from a stack, cannot be looked into from Python.
+
 Worth separating: the buffer protocol or `__array__` for host-resident arrays,
 where device-resident ones refuse rather than transfer, matching the explicit
 transfer rule the library holds everywhere else; and DLPack afterwards, if
 
@@ -5,9 +5,9 @@ them by accident. Each names the condition that would reopen it, so a future
 reader can tell a considered choice from an oversight. Implementation work
 lives in [BACKLOG.md](BACKLOG.md).
 
-Reviewed 20 Sep 2026. Nothing is currently waiting on an answer.
+Reviewed 1 Oct 2026. Nothing is currently waiting on an answer.
 
-## The batch source
+## Sources and sinks
 
 ### A destination's data type is chosen, not discovered
 
@@ -17,8 +17,9 @@ the pipeline computes in and the read converts on the way. The type is fixed
 by what the work needs rather than by what the file happens to hold, and
 reading straight into it saves a separate conversion pass later.
 
-So no query for a file's native type is needed, and none exists. The
-conversion is the design rather than an oversight.
+The conversion is the design rather than an oversight. A file's own type is
+still there for whoever wants it: `query_descriptor` reports it, and the
+synchronous `read` keeps it unless it is asked for another.
 
 **Revisit when** a pipeline is measured to be spending materially in that cast
 and reading into the file's own type would avoid it.
@@ -28,7 +29,7 @@ and reading into the file's own type would avoid it.
 Sharing an executor between sources is the caller's responsibility rather than
 the binding's; most clients hold a single source and a single sink. A default
 is still provided, and per instance is the one chosen, with an explicit
-executor accepted as an override.
+executor accepted as an override. `source()` and `sink()` both follow it.
 
 Per instance rather than process-wide because the choice is meant to be
 revisited once there is evidence of how clients use it, and this is the
@@ -57,10 +58,13 @@ with code already built on `asyncio` or `concurrent.futures`.
 
 ### Blocking calls release the GIL
 
-`wait` and `get` block, and `read` opens files through the provider before
-returning. Bound plainly they would hold the GIL and freeze every Python
-thread for the duration, which makes the asynchronous interface pointless.
-All three take `py::call_guard<py::gil_scoped_release>()`.
+`wait` and `get` block, and the asynchronous reads and writes open files
+through their provider before returning. Bound plainly they would hold the
+GIL and freeze every Python thread for the duration, which makes the
+asynchronous interface pointless. All of them take
+`py::call_guard<py::gil_scoped_release>()`, and so does everything else in
+`em.image` that reaches a file: the synchronous reads and writes,
+`query_descriptor`, `flush` and `close`.
 
 Safe because pybind11 constructs the guard after the arguments are converted
 and destroys it before the return value is cast, so nothing touches Python
@@ -79,21 +83,43 @@ loads a `std::vector` from anything passing `isinstance<sequence>`, so a list,
 a tuple and a `range` all reach `make_contiguous_array_descriptor`. Tests pin
 both halves, including the round trip: a shape this reports is one it accepts.
 
+### Centres are an `IndexTable` in the binding and any sequence in the package
+
+`read_patches_async` takes an `index_table` in rexlib, so the binding takes an
+`IndexTable` and nothing else. The package accepts any sequence of sequences
+beside it and builds the table, with the rank the destination implies, which
+is what keeps an empty list of centres meaningful.
+
+The table is bound as a class rather than hidden behind a caster because a
+caller cropping many batches can fill one and reuse it, which a conversion on
+every call would not allow.
+
+### Only what the high-level functions need is bound
+
+`rexlib.em.image` exposes the functions of `image_read.hpp` and
+`image_write.hpp` and the classes a caller has to construct to call them.
+Readers, writers, formats, transfer plans and sanitizers stay in C++: nothing
+Python does with them could not be done through those functions, and each
+would be another surface to keep matching rexlib.
+
+**Revisit when** a format or a border rule has to be written in Python.
+
 ### `__eq__` without `__hash__` leaves a type unhashable
 
-Where rexlib gives a type a `hash()` of its own, forward it; `array_descriptor`
-and `image_location` both do. Where it does not — `device_index` is the one
-left — the hash would have to be written rather than forwarded, and that
-belongs in rexlib beside the ones that already exist. `_session_pool.py` keys
-on a `(backend, id)` tuple in the meantime.
+Where rexlib gives a type a `hash()` of its own, forward it; `array_descriptor`,
+`image_descriptor` and `image_location` all do. Where it does not —
+`device_index` is the one left — the hash would have to be written rather
+than forwarded, and that belongs in rexlib beside the ones that already exist.
+`_session_pool.py` keys on a `(backend, id)` tuple in the meantime.
 
 **Revisit when** rexlib gives `device_index` a `hash()`.
 
 ### `image_metadata` is not bound
 
-rexlib declares the class empty and says so. Leaving the parameter off `write`
-until the type has fields is backward compatible; publishing an empty class
-whose shape is going to change is not.
+rexlib declares the class empty and says so. Leaving the parameter off the
+writes and off `ManagedImageWriterProvider.declare` until the type has fields
+is backward compatible; publishing an empty class whose shape is going to
+change is not.
 
 **Revisit when** rexlib gives `image_metadata` contents.