Inspiration
As a cataloger, I am excited by what AI can contribute to bibliographic description and subject analysis. But I have some basic questions: How can a cataloger tell which parts of an AI-created record accurately reflect the source evidence? Which parts are uncertain? What changed during review?
Those questions led to this project. Instead of asking one AI to produce a supposedly perfect answer, I separate the work into visible evidence, AI creation, independent AI review, and human decision. Cataloging is the first use case, but the same pattern could help other experts who create and review structured professional records.
What it does
The application accepts pasted text, a validated ISBN, or a PDF evidence packet. For the demo, I use an original fictional PDF containing a title page, publication information, a description, and a table of contents. The extractor identifies candidate information and cites the page where it found each element. The cataloger then reviews a visible Resource Source Package and confirms exactly what both AI roles will receive.
The AI Creator drafts the bibliographic description and subject analysis. Rule-based code then converts that structured information into MARC 21. The independent AI Reviewer compares the draft with the same confirmed evidence and the active cataloging policy. It reviews every MARC area, including areas where it recommends no change.
For subject and genre/form headings, the application also records checks against Library of Congress vocabularies. It keeps two questions separate: Is this the authorized form, and is it appropriate for this resource? The cataloger can open the supporting LC authority evidence directly in the interface.
The Reviewer cannot change the record. It can only recommend. The cataloger may accept, edit, or reject each recommendation, and only those explicit decisions affect the final MARC. A downloadable audit preserves the whole process, including the source, Creator draft, Reviewer findings, authority evidence, human decisions, final record, run mode, and any fallback.
How we used Codex and GPT-5.6
Codex was my main engineering collaborator throughout Build Week. Together, we turned an earlier cataloging interface into this focused workflow. Codex helped me design and implement the interface and Python services, separate the Creator and Reviewer prompts, define structured outputs, encode valid MARC, add PDF and ISBN intake, connect authority checks, write tests, diagnose failures, and document the project.
My role was not simply to approve what the AI produced. I defined the cataloging requirements and human-approval boundary, tested each version, corrected MARC structures, explained LCSH subdivisions and authority records, and stopped the workflow whenever a result was unsupported or misleading. Those conversations changed and improved the product with each iteration.
GPT-5.6 performs two separate jobs within the application. The Creator sees only the confirmed Source Package and drafts the record. In a second call with a separate prompt, the Reviewer receives the same evidence, the draft, rule-based findings, and recorded authority results. It reports its coverage and recommendations but has no power to apply them.
What existed before Build Week
Before the submission period, I had created an earlier CatalogingUI ESM prototype with help from an earlier version of GPT. During Build Week, Codex and I created a separate workspace for this new project and built the Creator/Reviewer workflow, visible Source Package, live GPT-5.6 services, human-decision process, audit trail, PDF and ISBN ingestion, cataloging-policy profile, authority reconciliation, demo assets, documentation, and tests.
This work meaningfully extended and transformed my earlier prototype during the Build Week submission period. The dated Git history and primary Codex session document that work.
Challenges
The hardest part was not generating MARC text. It was keeping evidence, AI inference, authority verification, cataloging policy, and human judgment from becoming blurred together. Subject headings made this especially clear: finding an authorized term does not automatically mean that the term fits the resource, and different types of subdivisions must be encoded and verified differently.
What we learned
I learned that explainability has to be something the user can act on. A confidence badge alone is not enough. The cataloger needs to see the evidence, the draft, the reason for a recommendation, the authority result, and exactly what will change.
I also learned that verification works in both directions. AI can catch problems in a draft, but a human can misunderstand or mistype a correction too. Visible evidence and a complete audit make both AI and human decisions reviewable. The goal is not a perfect autonomous AI cataloger; it is a more accountable Human-AI collaboration.
What’s next
There is more I would like to do after Build Week. Codex and I could add LCNAF identity reconciliation for personal and corporate names, support more complex multi-subdivision LCSH construction, add URL and spreadsheet evidence ingestion, provide additional export formats, and support configurable local policy profiles. I intentionally deferred these features to keep the Build Week demonstration focused and coherent.
Built With
- 21
- api
- codex
- congress
- css3
- data
- flask
- gpt-5.6
- html5
- javascript
- library
- linked
- marc
- of
- open
- openai
- python
- service
Log in or sign up for Devpost to join the conversation.