{
  "title": "From acquired evidence to a reviewed result — Tools & experiences",
  "text": "MODAVIS (2026). From acquired evidence to a reviewed result — Tools & experiences. Research notebooks, October 2026 · Wider reading and source audit edition. https://modavis.org/editions/2026-10-reading/software/processing/",
  "bibtex": "@misc{modavis_software_processing_2026_10_reading,\n  author = {{MODAVIS}},\n  title = {From acquired evidence to a reviewed result — Tools & experiences},\n  year = {2026},\n  month = {10},\n  version = {2026-10-reading},\n  url = {https://modavis.org/editions/2026-10-reading/software/processing/},\n  note = {Content SHA-256: 69a70f899074ee5265778682cd0bc2e8f583a6b3dfc92ef0e921e7a99ee8a6a9}\n}",
  "url": "https://modavis.org/editions/2026-10-reading/software/processing/",
  "sha256": "69a70f899074ee5265778682cd0bc2e8f583a6b3dfc92ef0e921e7a99ee8a6a9",
  "edition": "2026-10-reading",
  "date": "2026-10-09",
  "canonicalPayload": "{\"book\":{\"number\":\"06\",\"slug\":\"software\",\"title\":\"Tools & experiences\"},\"chapter\":{\"blocks\":[{\"text\":\"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.\",\"type\":\"p\"},{\"id\":\"processing-example\",\"text\":\"A source statement through the workflow\",\"type\":\"heading\"},{\"text\":\"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.\",\"type\":\"p\"},{\"headers\":[\"Module\",\"Input and useful output\"],\"rows\":[[\"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.\"]],\"type\":\"table\"},{\"boundary\":\"The example illustrates component responsibilities without attributing unverified processing history to the actual release.\",\"caseLabel\":\"Cuntz\",\"concept\":\"A processing candidate is a proposed interpretation of source material. Review and publication are additional decisions, with their own evidence and responsibilities.\",\"evidence\":\"Illustrative scenario\",\"expanded\":false,\"id\":\"cuntz-software-boundaries\",\"scenario\":\"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.\",\"sources\":[{\"detail\":\"Published manifest: identities, measurement observations, realization digests, profiles and rights. Exact examples checked against this release.\",\"href\":\"https://doi.org/10.5281/zenodo.22151203\",\"label\":\"Cuntz Positiv · VAO 0.5.0-rc.2\"},{\"detail\":\"Identity, state, configuration, evidence, assertions, context and provenance. Teaching examples explain its distinctions without inventing new normative properties.\",\"href\":\"https://doi.org/10.5281/zenodo.22126086\",\"label\":\"MODAVIS Ontology Network 0.1.0\"}],\"steps\":[{\"text\":\"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.\",\"title\":\"Preserve the source\"},{\"text\":\"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.\",\"title\":\"Inspect the candidate\"},{\"text\":\"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.\",\"title\":\"Publish the accountable result\"}],\"takeaway\":\"Automation can propose a useful structure; an accountable workflow keeps the interpretation and its grounds inspectable.\",\"title\":\"Where does an extracted number become an accepted claim?\",\"type\":\"example\",\"visual\":{\"caption\":\"This is an illustrative review workflow, not a report of an additional Cuntz experiment.\",\"layout\":\"flow\",\"nodes\":[{\"detail\":\"An algorithm produces an attributable output.\",\"icon\":\"database\",\"label\":\"Processing\",\"value\":\"Candidate result\"},{\"detail\":\"A reviewer can accept, reject or defer.\",\"icon\":\"compass\",\"label\":\"Review\",\"value\":\"Check the evidence\"},{\"detail\":\"Keep the decision and lineage.\",\"icon\":\"quote\",\"label\":\"Publication\",\"value\":\"A qualified claim\"}],\"relations\":[\"review the candidate\",\"publish the scoped result\"],\"title\":\"Separate extraction from acceptance\"}},{\"id\":\"analytical-paths\",\"text\":\"Three specialist analytical paths\",\"type\":\"heading\"},{\"headers\":[\"Module\",\"Result\",\"Interpretation boundary\"],\"rows\":[[\"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 reconstruction artifacts; the October hub requests DA3 GLB output.\",\"Inspect the representation, view coverage and scale. A GLB container does not guarantee a textured surface or an acoustic model.\"]],\"type\":\"table\"},{\"id\":\"review-handoff\",\"text\":\"What a reviewable handoff contains\",\"type\":\"heading\"},{\"items\":[\"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.\"],\"type\":\"list\"},{\"text\":\"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.\",\"type\":\"p\"},{\"id\":\"processor-status\",\"text\":\"Read the package status literally\",\"type\":\"heading\"},{\"text\":\"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.\",\"type\":\"p\"},{\"items\":[{\"href\":\"/notebooks/software/directory/#processor-modules\",\"label\":\"Processor modules in the directory\"},{\"href\":\"https://doi.org/10.5281/zenodo.22662664\",\"label\":\"Workflow demonstrations 0.1.1\"},{\"href\":\"/notebooks/ontologies/evidence/\",\"label\":\"Evidence and reviewed assertions\"}],\"type\":\"links\"},{\"id\":\"replay-and-revision\",\"text\":\"Distinguish replay from new evidence\",\"type\":\"heading\"},{\"text\":\"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.\",\"type\":\"p\"},{\"text\":\"The portable 0.2.0 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 snapshot-specific contracts protect the path back to the evidence while allowing a later version to improve the interpretation.\",\"type\":\"p\"},{\"items\":[{\"detail\":\"Inputs, outputs, examples and diagnostic limits.\",\"href\":\"/notebooks/software/modules/\",\"label\":\"Read all twelve module contracts\"}],\"type\":\"links\"}],\"intro\":\"A practical reading of the twelve modules documented in the September 2026 portable Processor 0.2.0 snapshot, with later reconstruction changes identified separately.\",\"slug\":\"processing\",\"sources\":[{\"detail\":\"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.\",\"label\":\"Dominik Ukolov · Musikinstrumente im virtuellen Raum (2026)\"},{\"href\":\"https://doi.org/10.5281/zenodo.22662664\",\"label\":\"Research workflow demonstrations 0.1.1\"},{\"detail\":\"Portable Processor 0.2.0 module guide and package README, inspected on 26 September and rechecked on 9 October 2026. This is a dated, unpublished development snapshot; its twelve-module map and CLI examples are not a claim about every later hub checkout or public release.\",\"label\":\"MODAVIS Processor · module guide and package README\"},{\"detail\":\"Code inspected on 9 October 2026: processor/modules.py; the DA3 reconstruction adapter, optional camera-data path and authored simple-GLB fallback. The inspection establishes implemented contracts, not a new GPU run, accuracy benchmark or public software release.\",\"label\":\"Processor hub and Modelgenerator · inspected development code\"}],\"title\":\"From acquired evidence to a reviewed result\"},\"date\":\"2026-10-09\",\"edition\":\"2026-10-reading\",\"figures\":{}}",
  "payload": {
    "edition": "2026-10-reading",
    "date": "2026-10-09",
    "book": {
      "slug": "software",
      "title": "Tools & experiences",
      "number": "06"
    },
    "chapter": {
      "slug": "processing",
      "title": "From acquired evidence to a reviewed result",
      "intro": "A practical reading of the twelve modules documented in the September 2026 portable Processor 0.2.0 snapshot, with later reconstruction changes identified separately.",
      "blocks": [
        {
          "type": "p",
          "text": "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."
        },
        {
          "type": "heading",
          "text": "A source statement through the workflow",
          "id": "processing-example"
        },
        {
          "type": "p",
          "text": "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."
        },
        {
          "type": "table",
          "headers": [
            "Module",
            "Input and useful output"
          ],
          "rows": [
            [
              "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."
            ]
          ]
        },
        {
          "type": "example",
          "id": "cuntz-software-boundaries",
          "title": "Where does an extracted number become an accepted claim?",
          "concept": "A processing candidate is a proposed interpretation of source material. Review and publication are additional decisions, with their own evidence and responsibilities.",
          "scenario": "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.",
          "steps": [
            {
              "title": "Preserve the source",
              "text": "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."
            },
            {
              "title": "Inspect the candidate",
              "text": "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."
            },
            {
              "title": "Publish the accountable result",
              "text": "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."
            }
          ],
          "takeaway": "Automation can propose a useful structure; an accountable workflow keeps the interpretation and its grounds inspectable.",
          "boundary": "The example illustrates component responsibilities without attributing unverified processing history to the actual release.",
          "sources": [
            {
              "label": "Cuntz Positiv · VAO 0.5.0-rc.2",
              "href": "https://doi.org/10.5281/zenodo.22151203",
              "detail": "Published manifest: identities, measurement observations, realization digests, profiles and rights. Exact examples checked against this release."
            },
            {
              "label": "MODAVIS Ontology Network 0.1.0",
              "href": "https://doi.org/10.5281/zenodo.22126086",
              "detail": "Identity, state, configuration, evidence, assertions, context and provenance. Teaching examples explain its distinctions without inventing new normative properties."
            }
          ],
          "expanded": false,
          "caseLabel": "Cuntz",
          "evidence": "Illustrative scenario",
          "visual": {
            "layout": "flow",
            "title": "Separate extraction from acceptance",
            "nodes": [
              {
                "label": "Processing",
                "value": "Candidate result",
                "detail": "An algorithm produces an attributable output.",
                "icon": "database"
              },
              {
                "label": "Review",
                "value": "Check the evidence",
                "detail": "A reviewer can accept, reject or defer.",
                "icon": "compass"
              },
              {
                "label": "Publication",
                "value": "A qualified claim",
                "detail": "Keep the decision and lineage.",
                "icon": "quote"
              }
            ],
            "caption": "This is an illustrative review workflow, not a report of an additional Cuntz experiment.",
            "relations": [
              "review the candidate",
              "publish the scoped result"
            ]
          }
        },
        {
          "type": "heading",
          "text": "Three specialist analytical paths",
          "id": "analytical-paths"
        },
        {
          "type": "table",
          "headers": [
            "Module",
            "Result",
            "Interpretation boundary"
          ],
          "rows": [
            [
              "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 reconstruction artifacts; the October hub requests DA3 GLB output.",
              "Inspect the representation, view coverage and scale. A GLB container does not guarantee a textured surface or an acoustic model."
            ]
          ]
        },
        {
          "type": "heading",
          "text": "What a reviewable handoff contains",
          "id": "review-handoff"
        },
        {
          "type": "list",
          "items": [
            "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."
          ]
        },
        {
          "type": "p",
          "text": "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."
        },
        {
          "type": "heading",
          "text": "Read the package status literally",
          "id": "processor-status"
        },
        {
          "type": "p",
          "text": "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."
        },
        {
          "type": "links",
          "items": [
            {
              "label": "Processor modules in the directory",
              "href": "/notebooks/software/directory/#processor-modules"
            },
            {
              "label": "Workflow demonstrations 0.1.1",
              "href": "https://doi.org/10.5281/zenodo.22662664"
            },
            {
              "label": "Evidence and reviewed assertions",
              "href": "/notebooks/ontologies/evidence/"
            }
          ]
        },
        {
          "type": "heading",
          "id": "replay-and-revision",
          "text": "Distinguish replay from new evidence"
        },
        {
          "type": "p",
          "text": "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."
        },
        {
          "type": "p",
          "text": "The portable 0.2.0 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 snapshot-specific contracts protect the path back to the evidence while allowing a later version to improve the interpretation."
        },
        {
          "type": "links",
          "items": [
            {
              "label": "Read all twelve module contracts",
              "href": "/notebooks/software/modules/",
              "detail": "Inputs, outputs, examples and diagnostic limits."
            }
          ]
        }
      ],
      "sources": [
        {
          "label": "Dominik Ukolov · Musikinstrumente im virtuellen Raum (2026)",
          "detail": "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."
        },
        {
          "label": "Research workflow demonstrations 0.1.1",
          "href": "https://doi.org/10.5281/zenodo.22662664"
        },
        {
          "label": "MODAVIS Processor · module guide and package README",
          "detail": "Portable Processor 0.2.0 module guide and package README, inspected on 26 September and rechecked on 9 October 2026. This is a dated, unpublished development snapshot; its twelve-module map and CLI examples are not a claim about every later hub checkout or public release."
        },
        {
          "label": "Processor hub and Modelgenerator · inspected development code",
          "detail": "Code inspected on 9 October 2026: processor/modules.py; the DA3 reconstruction adapter, optional camera-data path and authored simple-GLB fallback. The inspection establishes implemented contracts, not a new GPU run, accuracy benchmark or public software release."
        }
      ]
    },
    "figures": {}
  }
}