DCB can now ask a Fallback Host to supply

This is the current state of the Fallback Host path. DCB can place an NCIP RequestItem against ORS-Appliance. ORS-Appliance creates a staff task for the supplying agency. Staff can then answer with either a positive ItemRequested message or a not-supplied CancelRequestItem message.

The screens below are from the local QA stack on June 30, 2026. They show the visible story, including the gaps.

The supplier has the item

Hogwarts is acting as the future supplier. Its ORS-Appliance metadata registry has a loanable resource description for A Philosophy of Software Design, 2nd Edition.

Hogwarts ORS-Appliance metadata registry showing A Philosophy of Software Design as a loanable resource description. — The supplying tenant has the resource before the request is placed. This is the item DCB later targets.

Discovery can find it

The shared discovery layer sees the clustered title. This is the patron-facing catalogue evidence before request placement.

OpenRS Discovery search results for Philosophy showing A Philosophy of Software Design. — Discovery search returns one clustered result for the title.

The detail page now shows live availability from the supplying side: available, Hogwarts location, call number, and item id.

OpenRS Discovery detail page showing live availability for HOG-FHS-POSD-0001 at Hogwarts. — Live availability is visible before request placement: one available item at Hogwarts.

DCB places the supplier request

For this checkpoint the request is placed through the DCB API, not the patron request screen. DCB records the request, the selected supplier item, and the supplier hold status.

DCB admin projection showing the patron request, supplier request, placed status, and HOG-FHS-POSD-0001 item. — DCB has placed the request at the supplying agency and records the supplier hold as `PLACED`.

The protocol shape is now:

DCB
  -> NCIP RequestItem
  -> ORS-Appliance Hogwarts tenant
  -> Fallback Host task
  -> staff decision
  -> NCIP ItemRequested or CancelRequestItem
  -> DCB supplier projection

Requester-side UI is still a gap

The requesting agency side is not yet populated for this DCB-originated path. The screen exists, but this request does not appear there yet.

Unseen University ORS-Appliance requester queue filtered to requester requests with no matching rows. — The requester-mode queue is present, but the DCB-originated request is not projected into it yet.

That is a useful gap to keep visible. It prevents the demo story from silently skipping requester-side state.

Supplier staff can decide

The supplier-side task is the important new operating point. Hogwarts sees the incoming Fallback Host task with the selected item and two staff actions.

Hogwarts ORS-Appliance Fallback Host task queue showing an open supplier request with Will supply and Not supplied buttons. — The supplying agency can now say `Will supply` or `Not supplied` from ORS-Appliance.

Those two buttons now drive real NCIP responses back to DCB:

Will supply sends ItemRequested, including the selected item barcode.
Not supplied sends CancelRequestItem, including a not-supplied reason.

The local smoke path verifies that DCB records those supplier outcomes as CONFIRMED and MISSING.

The next visible step is the patron-facing request screen. Discovery already shows the title and live availability; the missing piece is letting the patron place the request from that page.

The harder design work is identity routing in consortial hub setups. We need to pin down how FromSystemId, ToSystemId, FromAgencyId, and ToAgencyId interact when a hub brokers messages between requesting agency, supplying agency, and the systems that represent them.