The last OpenRS/DCB update focused on NCIP and the request lifecycle flowing between DCB and ORS-Appliance. This interim update is about the participation model behind that work.
ORS-Appliance is becoming a practical route for a library to connect to a DCB hub even when that library does not have a supported ILS integration. In fallback mode, ORS-Appliance is the local application staff use to keep the DCB request in sync with real work happening elsewhere: in an ILS, on a shelf, in a spreadsheet, or in a manual circulation process.
That matters because “not yet integrated” should not mean “unable to participate”.
The participation problem
DCB depends on systems being able to exchange a clear request lifecycle: request this item, confirm or decline supply, accept the item at the borrowing side, lend it, receive it back, and close the loop.
For libraries with a well-supported ILS, that can eventually be automated through a host-system adapter. But many libraries are not in that position. Some have an ILS without a suitable integration. Some have collection systems that do not look like a traditional ILS at all. Some are small enough that running a full ILS just to participate in a resource-sharing network would be disproportionate.
The fallback path is for those libraries.
ORS-Appliance as a lightweight local client
In this model, ORS-Appliance is not a full ILS deployment. It is a focused resource-sharing appliance: one backend service, a staff UI, local tenant configuration, and protocol endpoints.
That makes it much lighter than deploying a complete library management platform just to join a DCB network. The local staff member can receive the work, perform the local action in whatever system they actually use, then record the outcome in ORS-Appliance.
For DCB, the important point is that the conversation is still protocol-shaped. The current contract between ORS-Appliance and DCB is NCIP 2.02: a plain, open standard that anyone else can implement too.
Supplier-side fallback work
The supplier receives a DCB request in ORS-Appliance as a staff task. The task carries the item and request context needed to make a local decision.
A supplier-side fallback task: DCB has asked for an item, and local staff can perform the matching local work.
When staff start the work, ORS-Appliance records the local progress. In an automated adapter this step might be driven by an ILS callback. In fallback mode it is deliberately staff-driven.
Fallback mode is not a different business process. It is the manual version of the same host-system facts an adapter would emit automatically.
Once the supplier has completed the local work, ORS-Appliance projects the appropriate response back toward DCB.
Supplier-side completion gives DCB the next protocol-level fact it needs.
Borrower-side fallback work
The borrowing side can use the same pattern. When the item is expected locally, ORS-Appliance creates borrower-side work for staff to receive and circulate it.
Borrower-side staff can see that an item is expected and can record the next local action.
Receiving the item, checking it in for pickup, checking it out to the patron, and shipping it back can all be recorded without requiring an ILS adapter to exist on day one.
The item has been received locally. DCB can now be kept in sync with the borrower-side lifecycle.
Checkout is recorded by staff in fallback mode; an automated host-system adapter could emit the same fact later.
Return shipment closes the borrower-side handling step and tells the wider network where the item is in the lifecycle.
Why NCIP matters here
The key boundary is not a private API owned by one vendor. It is NCIP 2.02.
That does not mean every existing NCIP implementation is complete enough for this job. Much of the current work is about taking the protocol seriously enough to cover the whole lifecycle, not just a convenient subset. But the contract itself is open. ORS-Appliance can implement it. DCB can consume it. Other systems can implement it too.
That is an important difference from building a new closed adapter contract and calling it openness because one implementation happens to be visible.
Open by deployment, not just by licence
This is also why the deployment story matters.
ORS-Appliance is intended to be easy to download, run, inspect, and operate. The full local stack has Docker Compose files for development and demonstration. Kubernetes descriptors are part of the deployment direction for real environments. The point is not to create software that is technically available but practically usable only by a narrow set of specialist hosting vendors.
Our adoption of the FSL is part of that posture. The aim is a usable, inspectable, off-the-shelf appliance that real libraries can run or have hosted without being locked into a single walled garden.
Open participation has to include the operating model. If the software is impossible to understand, impossible to run locally, or impossible to connect without a privileged vendor relationship, then the licence alone has not solved the problem.
What this opens up
Fallback mode gives the community a migration path.
A library can start with manual participation. If an ILS adapter later becomes available, the same high-level lifecycle can become more automated. If a local system emits reliable host-side facts, ORS-Appliance can consume them. If a library has no useful local integration, staff can still keep the DCB request honest.
That is the direction we want: broader participation, clearer standards, and less pressure to choose a single monolithic system just to join the network.
This is still an interim checkpoint. The UI needs refinement, the full smoke path needs to keep hardening, and the state model work is still being tightened. But the shape is now clear enough to say what the fallback route is for.
ORS-Appliance should let libraries participate in DCB through a lightweight, standards-facing local service, even when their local systems are not yet ready to automate the whole conversation.