99Bridges  ·  paper

Shared Return Architecture

Reuse at city scale needs shared return points. A shared return point has to know what just went into it. This paper is about that problem — and about the record that solving it produces.

Every reuse programme eventually runs into the same wall, and it is not a technology wall. A return point you do not walk past is a return point you do not use. Reuse competes against the easiest action available, and any detour is friction measured against an alternative that costs nothing.

An operator with twenty locations — a coffee chain, a campus dining service, a grocer’s prepared-food counter — can place twenty return points, exactly where its own customers already are. That is twenty places in a whole city, and the container is already in a bag heading to an office, a train, or home. Every operator builds a network that is correct for its own footprint and too thin to change anybody's habits outside it.

Density is the product. Everything else is how you get there.

Density comes from sharing, and sharing creates a problem a private bin never has. A single operator’s own bin does not need to recognise anything — everything in it is theirs, and whatever comes back goes to the same shelf. A shared return point has to know whose container it just took. What goes into it is collected and washed as one mixed batch and only sorted back to its owners afterwards, so identification is what credits the right customer at the bin and what lets the sort on the far side put every container back where it belongs.

This paper is about that problem: how a return point answers what just went in, and whose is it, for any container in the shared catalogue rather than only the ones its own operator put there, with or without RFID.

What's inside

  1. Returning has to be as easy as throwing away. Why density, not material or washing capacity, decides whether a programme works.
  2. No single operator can reach density. And why a network that asks operators to retag before joining stays small.
  3. Sharing creates a recognition problem. The design constraint underneath shared reuse infrastructure.
  4. Three ways to return a container. What the customer does, and the gap between being acknowledged and being confirmed.
  5. What IRIS is. Verification rather than identification, three signals that may decline to answer, and a reference that improves with use instead of being trained.
  6. What IRIS adds. Confirmation at the bin without tags, and a chain of custody that starts at the return point instead of the wash.
  7. Keeping the evidence. Retention, sync, offline operation and integrity.
  8. Where the boundaries are. Nested stacks, mixed piles, and what condition assessment does not yet do.