The Box of Transparency

When artificial intelligence is used in the humanities, the demand for transparency has by now become common ground. Automatically generated transcriptions should not be accepted without review. A high confidence score is not proof, and a plausible reading must be measured against the visual finding.

There is little doubt about that. Especially with historical manuscripts, it would be problematic to output only a smoothed text at the end and keep the path that led there hidden.

But what happens if this demand is implemented consistently?

What happens if not only the result is preserved, but also the image version, the segmentation, the individual candidates, discarded readings, corrections, model states, uncertainties and technical dependencies?

Then opening the black box quickly turns into a box of Pandora.

The convenient black box

A classic black box is simple to operate. You feed in a manuscript page and receive a transcription.

Image in
↓
Processing
↓
Text out

That is easy to grasp. It is barely verifiable, though.

The user does not know which image areas were taken into account. They do not see where signs were uncertain or which alternatives the system discarded. Nor can they easily judge whether a linguistically likely form was actually recognizable in the image, or whether the model silently completed a damaged spot.

The black box makes the process simple by hiding its complexity.

For everyday use, that is convenient. For a scholarly edition, it is not enough.

What becomes visible on closer inspection

HistoriaMP therefore takes a different approach. The system is meant not only to deliver a reading, but to document how that reading came about.

In this context, a manuscript page is not simply an image. It consists of different analysis areas, lines, segments, traces of writing, possible signs and reading candidates.

Even before the actual transcription, numerous decisions arise. Which part belongs to the writing? Where does a line begin? Is a dark trace ink, damage or dirt? Does a superscript mark belong to the letter beneath it? Was a word actually recognized, or only added because of linguistic context?

Each of these questions can produce several processing states. A segment is cropped differently. A candidate is discarded. A human correction changes the basis for the next processing step. An earlier result is kept because it should remain traceable later why it was not adopted.

The path from source to reading then looks roughly like this:

Source
↓
Image state
↓
Layout area
↓
Segment
↓
Visible trace
↓
Sign candidate
↓
Reading candidate
↓
Review
↓
Decision

What at first glance looks like a simple transcription becomes an extensive chain of evidence.

One page, thousands of states

Take a simplified example: a page with 140 segments. If each segment goes through 26 processing steps and produces an average of three justified attempts, that yields 10,920 possible processing operations.

This number does not yet describe the individual objects actually stored. Each operation can carry further data: inputs, outputs, status information, timestamps, tool and model versions, parameters, hash values, uncertainties, dependencies and review decisions.

A single manuscript page can therefore produce several tens of thousands of technical state and provenance records.

Whether the final count is 30,000, 50,000 or 78,000 objects depends on the concrete granularity. The exact number is secondary to the underlying problem.

What matters is this: the more carefully we document, the larger the volume of information becomes.

When transparency becomes unmanageable

At this point the original idea tips over.

The black box is opaque because information is missing. But the fully documented system can become opaque as well, because too much information is present at once.

The scholar then sees not only the accepted reading. They see different image states, alternative segmentations, diverging candidates, probability scores, discarded proposals, corrections, error states, model versions, hash values and technical logs.

Formally, everything is disclosed.

In practice, it becomes increasingly difficult to recognize which piece of information actually mattered for the concrete scholarly decision.

This is precisely the transparency paradox:

Opening the black box does not necessarily remove opacity. It can produce a new form of it.

One form arises from hiding information. The other from its sheer mass.

Why the box of Pandora fits

Transparency does not create the uncertainties, errors and contradictions. It makes visible what was already there.

A model already had several possible readings before. A segment was already ambiguous before. A correction already had consequences for later steps before. In a closed processing chain, however, all of that stayed hidden.

As soon as we disclose these processes, we also have to manage them. Earlier states must not simply disappear. Discards need a reason. Dependencies must remain recognizable. Uncertainties must not be concealed behind a display that looks final.

The box is thus open. Its contents cannot simply be put back without returning to the original opacity.

The problem therefore shifts. It is no longer only:

How do we open the black box?

It is now:

How do we prevent its contents from burying the scholarly work?

The historian as reviewer of technical processes

A historian first wants to know what is recognizable on a page, how certain a reading is, and what it rests on.

They usually do not want to compare JSON files, read dependency graphs, check model versions or evaluate technical status messages.

A consistently transparent architecture can nonetheless make exactly that necessary. Classic source criticism is extended by another layer: the critique of digital processing.

That is fundamentally reasonable. If a digital procedure is involved in producing a reading, that procedure must be verifiable too.

Still, it cannot be expected that every user personally checks every technical detail. Even with solid IT skills, it would hardly be realistic to individually trace thousands of states for every single page.

That is not a personal competence problem. It is a structural mismatch.

A computer system can easily store far more states than a human can meaningfully oversee.

When disclosure leads back to blind trust

At this point an uncomfortable consequence arises.

Full documentation is meant to prevent blind trust. But if it is too extensive or too poorly organized, it can force exactly that trust again.

The user then perhaps checks only a few selected spots. They accept the rest. They trust that processing ran correctly, because full control is barely feasible in everyday work.

This brings the black box back on a different level.

The information is technically present, but practically no longer reviewed. The system is technically open, yet feels closed in use.

Transparency on paper is therefore not yet usable transparency.

Not less documentation, but better ordering

The obvious reaction would be to store less. That, however, would be the wrong path.

Discarded candidates, earlier states and technical dependencies can become important later. Perhaps it turns out that a model version was faulty. Perhaps a segmentation is reassessed. Perhaps another researcher wants to trace why a reading was accepted.

The data should therefore be preserved.

But it does not all have to be visible at the same level at the same time.

Scholarly work first needs a condensed view. There, the reading, the visual finding, the justification and the remaining uncertainty should be recognizable.

Only below that follow the alternative candidates, the discarded attempts and the technical detail.

Such a view could initially show just this:

Reading: regula
Status: accepted
Uncertainty: low

If needed, the justification can be opened:

The visible letter bodies support the reading.
The superscript mark is only partially preserved.

Then follow the alternatives:

• regula – accepted
• regular – discarded
• regule – discarded

Anyone who wants to check further can finally open the technical path of origin: segment ID, attempt, model version, parameters, artifact hash and raw log.

Nothing is deleted. But not everything sits in the foreground at the same time.

The user interface is part of the method

This gives the user interface a task that goes far beyond design.

It has to mediate between the system's data volume and the limited attention of a human reader. It co-decides whether transparency actually becomes usable.

In doing so, it must not smooth over uncertainty. It must not bury discarded candidates so deeply that they become practically unfindable. And it must not present a decision as more definite than the visual finding allows.

A good interface first answers the scholarly questions:

• What is visible?
• Which reading was derived from it?
• What alternatives existed?
• Why was one possibility preferred?
• Where does uncertainty remain?

The technical evidence stays reachable, but only comes to the foreground when it is actually needed.

This is not hiding data. It is ordering by relevance.

An edition of its own genesis

Through this form of documentation, the edition itself changes as well.

It no longer consists only of image, transcription, translation and apparatus. It additionally contains the documented path from the visible trace to the accepted reading.

HistoriaMP thus does not merely process a historical text. The system also records how that text was established: which observations were made, which candidates arose, which proposals were discarded, and which uncertainties were left open.

One could therefore speak of an edition of the editing process.

That sounds abstract at first, but it describes a practical difference. The final reading does not stand alone. Its path of origin remains part of the scholarly object.

This is exactly what creates traceability. It is also exactly what produces the enormous volume of data.

Transparency for different tasks

Not every user needs the same depth.

A reader may only be interested in the transcription and a clear marking of uncertain spots. An editor wants to see the justification and the discarded alternatives. A technical reviewer needs model versions, parameters and dependencies.

A single view can hardly satisfy all of these requirements at once.

Transparency therefore has to be organized depending on task and role. The underlying data stays the same, but access changes.

This does not mean that individual users are excluded from certain information. It only means that a transcription does not automatically have to be overloaded with the full technical log.

The decisive condition is that every relevant statement can be traced back to its basis.

What remains after opening

In the story of Pandora, hope remains in the box at the end.

With digital editions too, the released volume of information is not only a problem. It shows how many decisions and uncertainties stand behind a seemingly simple reading.

The black box did not remove this complexity. It only hid it.

Returning to the closed box would therefore be no solution. The task is to handle its contents so that they remain verifiable without smothering the actual research.

This does not require maximum visibility on every screen. It requires a reliable connection between source, observation, candidate, decision and technical evidence.

The central question is therefore not:

How can we show as much data as possible?

But rather:

How do we preserve full traceability without burying the scholar under its data volume?

The box of transparency remains open.

Now we have to order its contents so that they can still be read, checked and understood.