The team behind HistoriaMP
HistoriaMP did not emerge in a large institute, a research lab or a classical software company.
An unusual team
The project is currently initiated and led by one person. That person develops the questions, examines source problems, evaluates concepts, rejects false approaches, makes directional decisions and carries responsibility for the project’s intellectual line.
That is unusual. But it explains a great deal about the character of HistoriaMP.
HistoriaMP did not arise from completed scholarly certainty, but from a search: from the attempt to understand a historical source oneself; from dissatisfaction with smooth answers; and from the experience that neither secondary literature nor simple AI outputs automatically provide a checkable reading.
For precisely this reason, HistoriaMP does not claim to know everything already.
The project shapes its own working method around keeping questions visible, making assumptions checkable and keeping errors correctable.
The role of the human initiator
The human part of HistoriaMP is not the infallible expert in the background.
It asks the questions, notices problems, recognises contradictions, checks results and decides which direction should be pursued further.
One point is central: HistoriaMP is not being built from the position of a trained palaeographer, a classical developer or an institutional research team. For exactly that reason, the project must work with particular care.
No single decision may count as final truth. No assumption may be carried invisibly into later results. And the project must not create the impression that one person alone can answer all scholarly, technical and source-critical questions definitively.
The task of the human initiator is therefore not to know everything.
It is to guide the process in such a way that uncertainties remain visible, assumptions are checked, errors can be found and every reading must be tied back to the source evidence.
The role of AI systems
Different AI systems help with the technical and conceptual development of HistoriaMP.
They support the structuring of ideas, the design of modules, the writing and checking of code, the formulation of documentation, the comparison of concepts and the critical testing of methodological questions.
AI is not a replacement for responsibility.
It is a tool, a counterpart, a test instance and sometimes also a stress test. Suggestions are checked, changed, rejected or reclassified. Precisely because HistoriaMP itself treats AI outputs critically, the same standard applies to its own development.
No result is accepted merely because it sounds plausible.
No technical solution is considered correct merely because it is elegantly formulated.
No reading, module or concept becomes reliable just because a model outputs it convincingly.
AI helps make possibilities visible more quickly. It can suggest structures, generate variants, provoke errors and provide counter-proposals.
But it does not decide what counts as a sustainable project decision.
How HistoriaMP works
HistoriaMP develops iteratively.
Many decisions begin as plausible assumptions: a particular step should come at this point. A module should take on this task. A result should be checked in this way. A visual observation should be documented before a reading may arise from it.
Then it is tested.
Sometimes an assumption is confirmed. Sometimes it becomes clear that a step was conceived incorrectly, that a sequence does not hold, that a module decides too much or that a result does not remain sufficiently checkable.
Then it is corrected.
This working method is not a side effect. It is part of the project.
HistoriaMP does not arise from a master plan defined once and then merely implemented. It arises through repeated checking, rejecting, rebuilding and sharpening.
Specialist literature, technical documentation, scholarly discussions, existing tools, practical tests, AI drafts and counterarguments all flow into this process.
Not every idea is adopted. Not every suggestion is implemented. Not every plausible solution withstands examination.
What matters is whether a step remains justified, checkable and correctable.
Modularity as a protective principle
Precisely because errors are possible, HistoriaMP is built modularly.
An error in one step should not quietly dominate the entire system. A false assumption should not automatically contaminate all later results. A module should not become an untouchable authority.
Instead, individual steps should remain isolable, checkable, replaceable and capable of being reintegrated.
If it turns out that a workflow was conceived incorrectly, the entire project does not necessarily have to be discarded. The affected point can be analysed, corrected, replaced or moved into another context.
This applies to the technical pipeline as much as to visual recognition, checking and comparison instances.
HistoriaMP is therefore not designed as a rigid chain, but as a research workbench made of individual building blocks. These blocks can be connected, checked and rearranged when necessary.
Modularity is not a technical gimmick here. It is protection against false certainty.
External tools as candidate and checking layers
External systems are not treated as truth instances in HistoriaMP either.
Tools, models and analytical procedures can provide indications, generate candidates, suggest structures or support technical checks. But they do not replace the source-bound decision.
An external tool can mark an area.
A model can propose a reading.
A system can recognise a structure.
An AI can formulate an explanation.
But each of these results is initially only a contribution to the checking process.
What matters is not whether a tool outputs something convincingly. What matters is whether the result remains traceable, documented and checkable against the visible evidence.
HistoriaMP therefore treats external systems as comparison, candidate and control layers - not as the final authority.
Not a finished truth apparatus
HistoriaMP is not a finished truth apparatus in its own development either.
The project arises from working hypotheses, tests and corrections. It accepts that assumptions can be wrong. The central protection does not lie in excluding errors completely. That would be unrealistic.
The protection lies in making errors findable.
If an assumption is wrong, it should not enter later results invisibly. It should remain recognisable, isolable and correctable.
This applies to the later analysis of historical manuscripts - and it applies equally to the development of HistoriaMP itself.
The project’s working method therefore follows the same principle as its later analysis:
Not the fast answer counts.
Not the smooth surface counts.
Not apparent certainty counts.
What matters is whether the path to a result remains traceable.
Responsibility
In the end, HistoriaMP remains a human-led project.
AI systems help. External tools provide indications. Specialist literature and technical documentation provide orientation. Tests reveal limits. Errors lead to corrections.
But responsibility for direction, for the choice of principles and for deciding what is adopted, rejected or kept open lies with the human initiator.
That is exactly why the working method must remain transparent.
Not the most convincing output counts.
Not the most elegant technical solution counts.
Not the most plausible shortcut counts.
What matters is whether a step remains justified, checkable and correctable.
The core
The team behind HistoriaMP is unusual.
One human being asks the questions, carries responsibility and steers the direction.
AI systems support thinking, designing, checking and implementation.
External tools provide candidates, indications and comparison layers.
Specialist literature, tests and criticism correct the process.
HistoriaMP therefore does not emerge as a product of finished certainty, but as a modular research workbench that checks its own assumptions.
The aim is not to be infallible.
- The aim is to keep decisions visible, checkable and correctable.