Last updated: August 2026
The Palace Project is an open-source digital library platform operated by Lyrasis, a nonprofit organization. This document describes the logging, monitoring, and analytics that operate within the Palace Project, and what information they do and do not capture. It is intended to help partner libraries and institutions — and their privacy and compliance staff — understand how the platform behaves.
This page complements two related resources: our Privacy Policy, which governs how information is collected and used, and Patron Data and Third-Party Service Providers, which identifies the subprocessors that may access patron data.
Palace does not monitor, profile, or track the reading behavior of individual patrons. The logging that exists is operational: diagnostic logs for troubleshooting, crash reports for fixing app defects, aggregate usage statistics for library reporting, and automated monitoring of system health (servers, not people). Palace does not use third-party advertising or behavioral analytics services.
No feature anywhere in the platform presents an individual patron's reading or borrowing history as an activity trail, to library staff or to Lyrasis personnel. One component — the Virtual Library Card application — does keep an administrative audit log of staff actions on card and account records; that log is described under Audit logs below.
The Palace applications and backend services generate standard application logs used to operate the platform, troubleshoot problems, and provide technical support.
Diagnostic log records generated while handling a signed-in patron's request include that patron's library authentication identifier (such as a barcode or username), along with the request path, the originating IP address, the library the request was directed to, and the application version. These identifiers are attached automatically so that an individual request can be traced end to end when something goes wrong. They are used for troubleshooting and support only, and are not used to build reading histories or patron profiles.
The Palace mobile apps use Google Firebase Crashlytics to report crashes and errors so that defects can be identified and fixed. A patron identifier may appear in diagnostic logs and crash reports used to troubleshoot app issues. Crash reporting is described in more detail on the Patron Data and Third-Party Service Providers page.
The Palace Collection Manager records circulation events — such as checkouts, returns, holds placed and released, fulfillments, and first-time logins — in order to provide libraries with the usage data, inventory reports, and holds reports they need to manage their collections.
How events are recorded. Each circulation event is recorded individually rather than as a running total. An event record describes the item (title, author, genre, audience, language, format, distributor, and collection), the library, the time, and a randomly generated identifier representing the patron account involved. That identifier is internal to Palace: it is not the patron's barcode, name, or email address, and it cannot be used to look a patron up in any library system.
Why an identifier is involved at all. Libraries need to know how many distinct people their collection served, not only how many transactions took place — the difference between "10,000 checkouts" and "10,000 checkouts by 1,200 patrons." That second figure is what libraries rely on for budget planning, funding applications, and demonstrating the reach of the service, and it cannot be derived from running totals: a counter that only increments cannot distinguish one patron borrowing twenty titles from twenty patrons borrowing one each. Producing it requires something that stays consistent for a given account across the reporting period.
Palace uses the narrowest mechanism that satisfies that requirement, and retains it only for the period and the purposes that requirement implies: