SOFT_ERROR // BOOT

> soft error

> booting…

> loading manifesto…

> 0 trackers attached

> ready. _

← All Lab Notes

CASE 0004 // CASE STUDY

Making a research dataset legible

A research group had brilliant data trapped in forty confusing tables. We turned the export into something a newcomer could understand by lunchtime.

Client
A university research group
Sector
Research · Data
Engagement
4 weeks · data + API
READING MODE: HUMAN DataResearchAPI

A university research group was sitting on genuinely valuable data and losing weeks to it anyway. Every new student or collaborator had to be personally walked through which of forty tables meant what, in a tour only two people in the building could give.

How it started

They did not describe it as a software problem. They described it as a people problem: knowledge lived in two researchers’ heads, and every arrival taxed those heads again. When one of them went on leave, an entire strand of work stalled, because nobody else could reliably answer “which column is the corrected value and which is the raw one”.

The dataset was designed to be understood — our favourite kind of brief — and had simply never been given the interface that would let it be.

What we found

The export was forty-odd tables with archaeological naming: three generations of convention layered on top of each other, columns whose meaning depended on the value of another column, and undocumented joins that only worked if you already knew the answer.

None of this was carelessness. It was the honest residue of research that evolved as it went. But the cost had migrated to every newcomer, paid in the same confused week, over and over. The knowledge existed; it was just not written down anywhere a machine or a stranger could read.

What we built

We did not touch the science. We built a legible surface over it.

  • A documented schema that names things once, correctly, with the meaning of every field written down beside it instead of in someone’s memory.
  • A small, queryable API over the cleaned tables, so a researcher asks for what they want in plain terms rather than reconstructing a five-table join from folklore.
  • A validation pass that runs on ingest and refuses data that violates the rules the group actually cares about — the raw/corrected mix-up that had quietly poisoned more than one analysis now fails loudly at the door.
  • Documentation aimed at the newest person in the room, not the two who already knew.

Results

Onboarding a new researcher went from the better part of a week to an afternoon, because the dataset now explains itself. The two people who used to be the documentation got their time back, and — more importantly — stopped being a single point of failure for the group’s output.

We measured almost nothing here in the conventional sense; the honest result is qualitative and it is the one that mattered. Data that can be understood by a stranger is data that survives the people who made it. That was the actual deliverable.