A sensor module that is a pipeline of transforms rather than a class of its own.

Mirrors tbp/monty/sensor_modules/sensor_module.py::SensorModule, the shape Monty's newer sensor modules take: one step hands the raw observation to the first transform, each transform answers a changed payload, and the last one's percept is what the step reports. Nothing here knows what a patch is — a view finder whose pipeline is empty reports no percept at all, which is exactly what it should do.

The port's one sensor contract

Monty declares RuntimeSensorModule and ResettableSensorModule as Protocols, purely so a runtime can ask whether an object is one. The port has a single sensor behaviour instead (Monty.Frameworks.Models.AbstractMontyClasses.SensorModule) — a sensor module is something with update_state/2, step/4, reset/1 and the two proposal answers — so neither protocol becomes a module here (docs/monty-differences.md §2.13).

What it does not have

Monty gives the plain class no reset at all; only the experiment wrapper resets, and only its transforms. The port's behaviour requires every sensor to reset, so this one forgets what its payloads set (goals, region, telemetry) and leaves the transforms alone — the wrapper is what resets those.