|
 |
The Next Big Documentation Problem Isn’t 'Metadata' — It’s Missing 'Paradata'
Tech writers have spent years organizing info — now we need data to prove how it was created, reviewed, and transformed
|
| |||||||||||||||
The first time an AI system gives a wrong answer from your documentation, no one’s going to ask whether the topic had a good title. They’re going to ask where the answer came from.
Then they’ll ask which source it used, whether that source was current, who approved it, whether it had been translated, rewritten, reused from another product, or lightly “improved” by someone who was mostly trying to get to lunch.
That’s when metadata starts looking a little lonely.
 |
While Metadata Helps Us Find Things‚ Paradata Helps Us Explain Them
Tech writers have spent years learning to care about metadata. We tag content by product, audience, version, region, language, task type, and anything else we can persuade the system to remember.
That work matters. Metadata helps content move, surface, filter, and behave like it was raised properly.
But metadata doesn’t tell the whole story.
It can tell you that a topic is for administrators using version 6.2 in North America. It usually won’t tell you that the topic was stitched together from old release notes, edited by three people, reviewed after a support escalation, machine-translated, rewritten with AI, and approved by someone who clicked the button because the meeting was starting.
That missing story is paradata.
Paradata Is Our Content’s Backstory
Paradata is info about the process behind the content. It tells us (and the machines upon which we rely) how something was created, reviewed, revised, transformed, approved, reused, translated, or generated. It’s not the content itself. It’s not just the labels around the content. It’s the trail of decisions and actions that explain how the content became what it is.
Paradata is the receipt. And our documentation needs receipts now.
