From PDF Prison to Oracle Knowledge Base: Searching HCM Docs During Ticket Triage

Sun, 19 Apr 2026 00:00:00 +0000

The Problem With Oracle Documentation

Oracle HCM ships with thorough documentation. I mean that sincerely — the guides are detailed, well-structured, and genuinely useful. The problem is how they’re packaged.

They come as PDFs. Hundreds of pages, multiple volumes. Using Global Human Resources. Implementing Global Human Resources. Oracle HCM Cloud Security Reference Guide. Each one is enormous. Each one is a knowledge prison.

When a ticket lands in my queue — a department not appearing in a List of Values, an enhancement request for a new absence type, a defect on a Redwood page — the documentation that could help me is buried somewhere in a PDF I last opened six months ago. I can open it and Ctrl+F, but only if I remember which guide covers what I need. And during live triage, that friction costs real time.

I needed a way to search all of that documentation the way I search my own notes: fast, in plain language, without leaving my workspace.

I Already Had the Tool

A few months ago I built a PDF-to-Markdown converter with Claude Code — a Python CLI I called pdf2md. If you’ve read that post , you know the backstory: I needed to feed a research paper into my AI workflow and PDFs were the blocker. The converter was the fix.

Once it existed, I used it for research papers, cybersecurity books, product docs. But I hadn’t pointed it at the one category of PDFs I deal with most at work: Oracle HCM documentation.

That changed when I got a ticket I couldn’t reproduce in the development environment.

The Workflow: PDF to Searchable Knowledge in Three Steps

The setup is simpler than it sounds.

Step 1: Run the converter

cd ~/projects/pdf-to-markdown
source venv/bin/activate
python pdf2md --batch input/

I drop Oracle PDF guides into the input/ folder and run the converter. For text-based PDFs like Oracle’s official documentation, pdf2md extracts cleanly — headings become Markdown headings, tables become Markdown tables, inline formatting is preserved. One command, and the PDF becomes a .md file.

For scanned or image-based PDFs, I run an OCR step first with ocrmypdf before converting, but Oracle’s official guides are text-based, so that’s rarely needed here.

Step 2: Add to the Obsidian vault

I move the converted Markdown files into a dedicated folder in my Obsidian vault. Each Oracle guide gets its own file. The vault’s native search indexes everything automatically — no configuration required.

Step 3: Search in plain English

Now when a ticket lands, I open Obsidian, search for the relevant concept, and the passage I need surfaces in seconds. Not the PDF filename — the actual text, in context, with chapter headings intact so I know exactly where I am in the guide.

That’s it. No embeddings, no vector database, no infrastructure to maintain. Just Markdown files in a vault.

How It Helps With Enhancement Tickets

Enhancement work in Oracle HCM usually means understanding the configuration model before proposing a change. What are the valid options? What are the dependencies? What does Oracle recommend?

Before the KB, I’d skim PDFs looking for the relevant section. Now I search the vault directly. Configuring a new absence plan type means searching “absence plan configuration” and landing on the exact table of parameters and their valid values. Proposing a change to compensation cycle eligibility means searching “eligibility profile” and getting the implementation guide’s description of how profile types interact.

This matters not just for speed, but for quality. Enhancement proposals that reference the actual documentation — chapter and section — land differently than ones that don’t.

How It Helps With Issue and Defect Triage

This is where the KB earns its keep on a daily basis.

Last quarter I had a ticket where a department wasn’t appearing in the List of Values on a Redwood employment page. Standard move: try to reproduce in the development environment. Clean — no issue there. That mismatch meant something changed in Production that wasn’t reflected in the dev environment.

I described the situation to PAI — the AI infrastructure I run on top of Claude Code — and it pulled from the Oracle HCM documentation library to surface the relevant triage logic. The diagnostic path came from Using Global Human Resources, Chapter 7, which describes the three filters that govern department LoV visibility: effective date, active status, and Business Unit set assignment. And from Implementing Global Human Resources, Chapter 3, which covers how Reference Data Sets tie departments to business units.

The root cause turned out to be an effective date issue: a department record had been updated in Production on a specific date, and records with that update date weren’t resolving correctly in the LoV. Testing with an effective date one day earlier made the department visible immediately.

That’s a subtle triage path. Without the documentation — specifically, without knowing that effective date is one of the LoV filters described in Ch. 7 — it’s easy to go down the wrong trail first. The KB made the right trail obvious.

What’s in the KB

Right now the Oracle HCM knowledge base covers the guides I’ve needed most often:

Using Global Human Resources — workforce structures, departments, positions, jobs
Implementing Global Human Resources — configuration model, reference data sets, business unit assignments
Oracle HCM Cloud Security Reference Guide — roles, privileges, data security policies
Release update guides for recent quarterly patches

As I encounter new problem domains — absence management, compensation, talent management — I add the relevant guide. The pattern scales without any additional tooling.

This Is the KB PAI Now Pulls From

If you’ve read the post on triaging the Oracle HCM department issue with PAI , you saw me mention that PAI pulled from “the Oracle HCM documentation library I have indexed locally.” This is that library.

When PAI runs triage on an HCM ticket, it searches this Obsidian KB as part of the workflow. The same vault I use manually for quick lookups is also the source PAI reads from when I hand it a structured problem to investigate.

The PDF converter was the unlock. Once Oracle documentation was in Markdown and in the vault, it stopped being a set of documents I occasionally referenced and became infrastructure I reason with every day.

The Takeaway

Oracle HCM documentation is good. The format it ships in is not. Converting it to Markdown and loading it into Obsidian took less than an hour of setup. The return on that hour has been substantial — faster triage, better enhancement specs, and a foundation for the AI-assisted workflows that followed.

If you work in any enterprise system that ships PDF documentation — Oracle, SAP, Workday, it doesn’t matter — the pattern is the same. The tool exists. The only step left is pointing it at the right files.

Workflow on