NCIP as the adapter boundary for direct consortial borrowing

Over the last few days the important change has not only been more working code. It has been an advance in the model.

We had already established that NCIP2 is a strong standard protocol substrate for direct consortial borrowing. The barrier is not the shape of the protocol so much as the partial implementations that exist in real library systems. Many systems support a small part of NCIP. Few support the full set of services needed for a brokered direct-borrowing lifecycle.

The key move is to use ORS-Appliance as a local adapter in front of an ILS. ORS-Appliance can talk to an ILS through that system’s native API, then expose a fuller NCIP-facing surface to DCB. In effect, it becomes a prosthetic NCIP implementation for each ILS we integrate.

That gives us a cleaner long-term architecture. DCB can focus on orchestration and coordination. The complex host-system adapters can move out of DCB core and into ORS-Appliance host-system bindings such as Sierra, Polaris, or other local systems.

The same model also lets ORS-Appliance run as a Fallback Host where there is no attached host system at all. Staff can operate the lifecycle directly in ORS-Appliance, so participation is not blocked by adapter availability.

Why This Matters

By adopting NCIP this way, adapter writing becomes more open and modular. An adapter author does not have to change DCB orchestration code to participate. They need to bind a host system to the ORS-Appliance host-system API and project the relevant NCIP behaviour.

This is also why the Fallback Host path matters. It is not a toy path. It is the manual implementation of the same model: a host system with human-mediated actions instead of automated native API calls.

Securing NCIP Calls

The local stack now treats protocol calls as service-to-service traffic, not anonymous callbacks.

DCB and ORS-Appliance use local JWT-backed machine identities in the QA topology. ZITADEL issues short-lived tokens, and each service validates the caller before accepting protocol-facing work. That lets NCIP remain the domain protocol while authentication and tenancy stay explicit in the surrounding platform.

The design intent is simple:

NCIP carries the resource-sharing message.
JWTs prove which local service is allowed to send that message.
tenant and agency identifiers still scope the request inside the protocol payload.

Service Registry

DCB and ORS-Appliance now have the NCIP service registry shape needed for consortial interlending, including pickup-anywhere.

The important part is that this is not hardcoded for one path. The registry can describe participants, agencies, service endpoints, supported NCIP roles, and host-system bindings. That makes the model extensible as more host systems are attached and as the pickup-anywhere variant is pulled into the smoke path.

Current Smoke Evidence

Use screenshots as evidence, not decoration.

The screenshots below are from a fresh clean-stack run on 5 July 2026. The lifecycle screenshots use the DCB Admin audit tab because it shows the sequence of state changes more clearly than the current ORS-Appliance request detail screens.

1. Harvesting And Clustering

DCB starts from aggregated metadata. ORS-Appliance exposes tenant catalogue records; DCB harvests them, clusters them, and keeps the source records inspectable.

DCB Admin bib records screen showing harvested bibliographic records. — DCB Admin showing freshly harvested bib records after ORS-Appliance catalogue ingest.

DCB Admin cluster details for A Philosophy of Software Design. — DCB Admin showing the clustered record for `A Philosophy of Software Design, 2nd Edition`.

DCB Admin item availability for A Philosophy of Software Design showing two Hogwarts copies. — DCB Admin showing live item availability collected dynamically from ORS-Appliance: two Hogwarts copies with distinct barcodes.

2. Patron Search And Request Creation

This checkpoint uses the controlled smoke path for request placement. The request is for Rincewind at Unseen University, routed to Hogwarts for item HOG-FHS-POSD-0001.

DCB Admin audit log after placing the supplier request. — DCB Admin audit log after request creation and supplier placement.

3. Request At Supplier

DCB places an NCIP RequestItem at the supplier. ORS-Appliance receives it and exposes the supplier-side work.

The smoke path now proves an important real-world edge: DCB requests item HOG-FHS-POSD-0001, but the supplier can confirm that it is sending alternate barcode HOG-FHS-POSD-0002.

DCB Admin audit log after supplier confirmation and borrower AcceptItem projection. — Supplier confirmation is projected back into DCB, then DCB places the borrower-side `AcceptItem` work.

4. Accept At Borrower

After supplier confirmation, DCB sends NCIP AcceptItem to the borrowing ORS-Appliance tenant. The borrower creates the virtual item/request using NCIP bibliographic data and the supplied barcode.

5. Circulation Lifecycle

The useful shift is that the demo no longer stops at supplier confirmation. The smoke path now drives the borrower-side circulation steps through to return transit.

The ORS-Appliance generic request screens still need better lifecycle projection. For this post the DCB audit log is the clearer view of the working protocol sequence.

Supplier Ships

DCB Admin request in pickup transit after supplier shipment. — Supplier shipment moves the broker request to `PICKUP_TRANSIT`.

Borrower Receives And Shelves

DCB Admin audit log after borrower receipt at pickup. — Borrower-side receipt moves the request to `RECEIVED_AT_PICKUP`.

DCB Admin audit log after borrower check-in ready for pickup. — Borrower-side check-in moves the request to `READY_FOR_PICKUP`.

Patron Loan

DCB Admin audit log after borrower checkout. — Borrower-side checkout moves the request to `LOANED`.

Return Transit

DCB Admin audit log after return shipment. — Borrower-side return shipment moves the request to `RETURN_TRANSIT`.

Not Supplied

Supplier return receipt is now modelled in the backend. The next publication checkpoint should add the clean-stack screenshot proving DCB moves from RETURN_TRANSIT through completion/finalisation after supplier receipt.

Protocol Story

The protocol shape is now:

DCB
  -> NCIP RequestItem
  -> ORS-Appliance supplier
  -> NCIP ItemRequested or CancelRequestItem
  -> DCB supplier projection
  -> NCIP AcceptItem
  -> ORS-Appliance borrower
  -> NCIP ItemShipped / ItemReceived / ItemCheckedIn / ItemCheckedOut
  -> DCB borrower projection
  -> NCIP ItemShipped return
  -> DCB return transit
  -> NCIP ItemShipped return-expected
  -> ORS-Appliance supplier
  -> NCIP ItemCheckedIn supplier return receipt
  -> DCB completion/finalisation

The discipline here is important. NCIP inbound code should create lifecycle evidence. DCB workflow code remains responsible for interpreting that evidence in the current request state.

What Remains

The standard two-party path now runs much further than it did at the start of this checkpoint. The remaining visible work is:

improve ORS-Appliance request detail so it exposes host lifecycle, citation, barcode, and available actions clearly;
extend the smoke from RETURN_TRANSIT through supplier return receipt to DCB finalisation;
add the separate next-supplier smoke path for instance-level requests;
model pickup-anywhere as its own three-party flow, not as the default case;
keep moving host-system adapter logic out of DCB and into ORS-Appliance bindings.

The larger direction is now clearer. DCB should be the broker and state coordinator. ORS-Appliance should be the host-system boundary: automated when an adapter exists, staff-mediated when Fallback Host is the only practical route, and NCIP-shaped in either case.