Key idea & worked example
A processing candidate is a proposed interpretation of source material. Review and publication are additional decisions, with their own evidence and responsibilities.
Automation can propose a useful structure; an accountable workflow keeps the interpretation and its grounds inspectable.See the worked example →On this page
Processor work begins with identified evidenceEvidenceMaterial offered as grounds for a claim. Its relevance depends on the claim, context, transmission and interpretation.Work through the Cuntz example → 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 observationObservationA record connecting a property and result to the thing observed, with a method and source context. A number alone leaves those relationships unspecified.Explain the 1281 mm Cuntz 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. |
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.
- ProcessingCandidate resultAn algorithm produces an attributable output.review the candidate
- ReviewCheck the evidenceA reviewer can accept, reject or defer.publish the scoped result
- PublicationA qualified claimKeep the decision and lineage.
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.
- 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 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. |
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 configurationConfigurationAn identified arrangement of components and their relationships. Rebuilding or reassigning parts can change a configuration while the instrument’s broader identity persists.Work through the Cuntz example → 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 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.