Skip to main content
Paul Welty, PhD AI, WORK, AND STAYING HUMAN

The questions your faculty information system cannot answer

Ask a faculty information system where a single number in a promotion dossier came from, and watch what happens.

Not who entered it. Not when. The source. Which CV, which self-report, which extract job, which human being typed 47 into a box three years ago and never touched it again. Most systems can tell you the number exists. Almost none can tell you why you should believe it.

That’s the question I’d fix first if I could only fix one: what is the source line behind every dossier claim? Faculty are the front-line workers of the university, the ones who deliver its two actual products, teaching and research. Everything else — every dean’s office memo, every provost’s report, every accreditation binder — is downstream of what those two products produce and how well we can prove it. If the provenance underneath a dossier is mush, the mush travels. It shows up in tenure cases, program reviews, grant reports that cite output numbers nobody can trace back to a source. Faculty are, without much argument, the most important and least well tracked part of the university. Fix the source line and every other field that depends on it gets fixed with it.

The questions that follow it

Once you start asking that question, a few others follow it like they’ve been waiting.

“Show me the audit trail for every change made to this dossier in the past year, including who and why.” Most systems log the change. Fewer log the reason, and reason is the part a search committee actually needs.

“When a CV lists a publication that isn’t in the repository, or isn’t in Scopus, which source wins, and how do you know?” Ask this in a room full of associate deans and watch the silence.

“What’s the process when a faculty member disputes their own data, and how is that dispute tracked?” Not whether there’s a form. Whether the form connects to anything.

“Can you break down workload and service obligations by department against our own targets?” It sounds like a reporting question. It’s actually a data-model question wearing a reporting question’s clothes.

None of these are exotic. A provost could ask any of them on a Tuesday and expect an answer by Thursday. Most systems can’t produce one, and that’s not a missing feature. It’s a fair reflection of what the system was built to optimize.

Ask this one and people start looking at me like I’m being difficult on purpose: “What is this faculty member’s current research focus?” You’d think this sits in a dropdown somewhere. It doesn’t. It’s scattered across a CV that’s a year stale, a departmental bio page nobody updates, a grants database that only knows what got funded, and a memory in the department chair’s head. Ask the question plainly and people assume you already have the answer and are testing them. You’re not. Nobody has the answer, reliably, across the whole institution. That’s the part that’s hard to say out loud in a meeting.

I’ve raised these gaps with vendors and with campus IT more than once. The answers cluster around a couple of shapes: too complex, not a standard feature. Sometimes it’s “would need significant custom development,” which is the same answer dressed up for a budget conversation. Sometimes the reason offered is a privacy concern, that opening up the audit trail or the source data would create compliance risk. Whatever risk is real runs through institutional policy and state personnel law, not FERPA — FERPA covers students and has nothing to say about a faculty member’s publication record. Real exposure sits where student data touches a faculty record: advising notes, recommendation letters. When the wrong regulation gets cited as the reason something can’t be built, that’s usually a sign the real reason hasn’t been said out loud.

I don’t fully believe the other reasons either. What I think is actually going on is a design choice made a long time ago, without anyone voting on it: these systems were built for the administrator entering the data. The faculty member the data describes, or the dean who has to defend it in a hearing, was never really the audience. Your systems are built around what’s easy to measure, and that’s rarely the same as what matters. A system that can log a change but not a reason was built by someone who needed the log for a different purpose than the one you’re using it for now.

Change the question you lead with

You don’t need to burn down what you have. You need to change which question you lead with when you sit across from a vendor or your own IT shop. Stop asking whether the system can do the thing it was demoed doing. Ask it the question it was never asked to answer. Ask for the source line. See what comes back. Whatever comes back is the actual state of your faculty data. The dashboard was showing you something else: a system that reports on faculty without actually knowing them.

Additional reading

Nobody takes you aside anymore

Print taught a generation when to stop. What we lose when the machines absorb the constraints that used to form us.

Your AI agents need a water cooler

Coordination is a property of the room, not the org chart. What that means when your coworkers are agents.

On the death of the author and the birth of the detector

Why worrying about AI authorship is lazier, and more prejudiced, than it looks.

The work of being available now

A book on AI, judgment, and staying human at work.

The practice of work in progress

Practical essays on how work actually gets done.

Memory is (almost) solved. time is next.

AI can't tell if a memory is two minutes or two weeks old. The fix isn't making models feel time — it's cache invalidation: an as-of stamp on every fact, a clock in the context, and a freshness window for anything volatile.

Did the state change? A simple test for whether work actually happened

Either something exists now that did not exist before, or it does not. A simple test for whether work actually happened, and what changes when you build your systems so they can't record anything else.