Real-Time Transcripts, Correct Ordering: The District Side of a National Best-Practices Award

In May 2009, eight Wake County high schools went live delivering current transcripts to North Carolina colleges electronically, in real time, instead of by mail — twenty-six schools by that fall. I wrote the Wake County side of that system, on contract to Wake County Public School System, working with a developer at the College Foundation of North Carolina (CFNC) — years before BitSalt existed.

The system CFNC submitted around that work — the "Electronic High School Transcript System" — won the Postsecondary Electronic Standards Council's 2009 national Best Practices award, announced the following spring. The award went to CFNC's submission, not to me. But PESC's own award package includes something more useful than a trophy: a side-by-side comparison of the two paths North Carolina was running to move the same kind of data, and the Wake County path is the one I built.

Two paths, one state

North Carolina ran electronic transcripts through two separate systems at the time. NCDPI — the state Department of Public Instruction — hosted the path for 480 public and charter high schools, moving data as ANSI X12 EDI transaction sets through UT Austin's SPEEDE server. It had been running since 2003, and by fall 2009 it was handling roughly 5,200 transcripts a month with a 24–72 hour turnaround from request to delivery.

Wake County ran the other path: live in May 2009 with eight high schools, twenty-six by that fall, using the PESC XML high-school transcript schema over web services instead of EDI — about 2,200 transcripts a month by fall 2009, delivered directly to 110 NC colleges and universities through CFNC. Charlotte-Mecklenburg was the third county in the deck, and its own slide listed its future plan as the Wake County pattern, not the state's — PESC XML and web services, not EDI.

The bug the state's system had, and Wake County's didn't

NCDPI's EDI path generated a final-transcript request automatically once a school posted final grades and diploma dates. The listed disadvantage: that request got created before the system had confirmed the current transcript had actually processed successfully — extra, unnecessary work and bandwidth on a system the deck itself describes as already "complex and sometimes difficult to track errors."

Wake County's path did the same job in the other order: the final-transcript request fired only after a successful response to the current-transcript request. The other difference was speed — Wake County delivered current transcripts in real time; the state's path took one to three days for the same job, the same state, the same students.

What it cost to fit in

Wake County's system carried exactly one listed disadvantage in the deck: it needed a mapping from PESC XML to EDI so it could still talk to the systems already in production around it. That's not a shortcoming — it's the cost of not breaking what a bigger, older system depended on. The new piece had to conform to the interfaces the rest of the state was already using, not the other way around. It's the same discipline I still reach for on any legacy integration: the new thing has to survive contact with the old thing, not just replace it.

Nearly two decades

The transcript exchange was one project inside a much longer relationship. Wake County kept bringing me back on contract for nearly two decades, across budget and finance systems, COVID-tracking applications built fast when the district needed them fast, and a contractor time-entry application, among other work.