From acquired evidence to a reviewed result
A practical reading of the Processor’s twelve modules, organised around the decisions they support.
Processor work begins with identified evidence and ends with outputs whose status is explicit. Some modules prepare candidates, others perform bounded analyses, and controlled projection connects reviewed decisions to the canonical research view. The modules should not be read as twelve mandatory stages for every record.
A source statement through the workflow
Imagine an acquired document naming a workshop and a place. Ingestor first stages its transfer record. Document evidence can identify the relevant passage; language detection can provide a qualified language observation; Normalizer and Localizer can propose structured interpretations. The workflow retains the original wording and lets a reviewer distinguish an extracted string from a supported identity or geographic link. This is an illustrative workflow rather than a report of a particular processed document.
| Module | Input and useful output |
|---|---|
| Ingestor | Acquired transfers → source-preserving staging with structural validation. |
| Document evidence | Identified documents → page assets, selectors and source-bound candidates. |
| Language detection | Text → detection and quality evidence, including abstention. |
| Normalizer | Staged observations → deterministic normalization and reconciliation proposals. |
| Localizer | Place mentions and provider evidence → ranked, qualified geographic proposals. |
| Litparser | Citation text → literature candidates with literal field evidence. |
| Enrichment | Authorized source requests → retained evidence and reviewable facts. |
| PLENUM | Claim-specific evidence → suitability, dependency and uncertainty assessments. |
| Bootstrap | Versioned policy and reviewed decisions → authorized projection receipts. |
Cuntz · Worked example#
Where does an extracted number become an accepted claim?
A processing candidate is a proposed interpretation of source material. Review and publication are additional decisions, with their own evidence and responsibilities.
Work through the example 3 STEPS
Use the Cuntz workbook observation to imagine a new import workflow. This is an explanatory mapping to the Processor architecture, not a claim that the published Cuntz release was built by all current Processor modules.
Preserve the source
Intake identifies the workbook bytes and source context. Extraction retains the literal cell, property code and unit rather than keeping only a convenient normalized number.
Inspect the candidate
A normalizer can propose a structured observation and a pipe identity. A reviewer checks the cell interpretation, the identity match and qualifications such as the timestamp note.
Publish the accountable result
An accepted projection keeps the evidence link and decision. A public view can be concise while a fixed release preserves the record needed to re-examine the claim.
BASIS FOR THIS EXAMPLE
- Cuntz Positiv · VAO 0.5.0-rc.2 ↗
Published manifest: identities, measurement observations, realization digests, profiles and rights. Exact examples checked against this release.
- MODAVIS Ontology Network 0.1.0 ↗
Identity, state, configuration, evidence, assertions, context and provenance. Teaching examples explain its distinctions without inventing new normative properties.
The example illustrates component responsibilities without attributing unverified processing history to the actual release.
The useful distinction. Automation can propose a useful structure; an accountable workflow keeps the interpretation and its grounds inspectable.
Three specialist analytical paths
| Module | Result | Interpretation boundary |
|---|---|---|
| Ambitus | Nominal pitch-range evidence from MusicXML, MXL or MIDI. | Score or event content does not establish acoustic performance or instrument identity. |
| Imageseg | Aligned image masks and annotations. | Class-agnostic segmentation needs interpretation before assigning organological meaning. |
| Modelgenerator | Photographic point clouds and camera paths. | A supported reconstruction output does not guarantee a textured mesh or an acoustic model. |
What a reviewable handoff contains
- The fixed inputs and their source context.
- The operation, software state, parameters and any relevant model dependencies.
- The resulting observation or candidate, with uncertainty and limitations.
- A distinction between a successful computation and an accepted historical interpretation.
- The review decision and projection record when canonical data is affected.
A module can execute successfully while producing an unresolved candidate. Conversely, a technical failure says nothing by itself about the historical truth of the source. Keeping execution status and interpretation status separate helps operators diagnose problems without silently changing the scholarly meaning of the record.
Read the package status literally
The cohesive Processor 0.2.0 package is described here as a development candidate. The public workflow demonstrations are separately versioned review material and do not establish that every current module or operational configuration has been released as a public service. Use the directory for dated availability and the demonstration deposit for the scope of that artifact.
Distinguish replay from new evidence
Replaying a retained input tests a particular processing configuration against the same evidence. Fetching a page again creates a potentially different source snapshot. Changing a model, parameter set or interpretation creates another derived result. Preserve those differences so a reviewer can tell whether a changed output came from a source update, a software change or an editorial decision.
The current module documentation makes this distinction concrete: exact Normalizer replay preserves decisions; Enrichment separates retained evidence from a new fetch; Document evidence keeps selectors tied to identified bytes. These contracts protect the path back to the evidence while allowing a later version to improve the interpretation.
Sources & further reading
- Dominik Ukolov · Musikinstrumente im virtuellen Raum (2026)
Dissertation submitted to Universität Leipzig, 11 September 2026. Chapters 1–6 and 8; Appendix I.4 for the software and resource inventory. See the dedicated research guides for claim-specific section references. Page numbers refer to the printed manuscript pagination. The manuscript is not distributed by this website.
- Research workflow demonstrations 0.1.1
- MODAVIS Processor · module guide and package README
Project documentation inspected on 26 September 2026; package 0.2.0, an unpublished development candidate. Used for current module responsibilities and limitations, not as a claim of public package availability.
Page editions 2026-09-r5 ↓
Read a fixed snapshot of this chapter, or return to the current notebook.
Edition 2026-09-r5 · SHA-256
2691c78567a9Page metadata ↗