Operations · rights, catalog & records · Remote from Jefferson City, MO
Eight years of catalog and rights administration taught me one habit: a record isn’t reliable until it’s been checked against another source. That habit is the whole job — whether the records are copyright registrations, royalty statements, vendor accounts or customer files.
Systems I administer in
Everything I use →
In rights administration
“A record isn't reliable until it's double checked against another source.”
In software
“A feature isn't complete until it's been tested and verified that it works.”
Those are the same sentence. I wrote one of them about metadata and the other about software, years apart, before I noticed they were actually the same rule. It’s why I build systems that don’t trust themselves — a cynical system avoids blind compliance. Something may look and even sound correct (a number, a date, even a dollar amount) but in order for it to be truly accurate, one must know not just the numbers but the "why" behind those numbers. By understanding the context of the underlying system itself, an inaccurate record can be verified and corrected, before it is brought in front of stakeholders who rely on the data to make decisions. This is my approach to all my systems I use to manage, curate, and utilize data. That rule is the only thing I’d ask you to judge me on.
Every figure below traces to a record I can produce on request.
Said up front, not in the interview
I don't write code by hand, and I don't make the specific engineering calls either — Claude Code does. My work is the architecture: I scope the system, set the goals and constraints that shape the technical trade-offs, sequence the build so nothing gets built on a missing foundation, and define what 'done' actually means before anything ships.
I don’t hide this, because a reader who finds it out later reads everything else as inflated. Directing a build well is a real skill and a different one than writing the code, and I’d rather be judged on the one I actually have.