Project timeline
Ordered by the actual event period, regardless of when a retrospective post was written or published.
The TTS path has moved well beyond the first September state: the engine-neutral API now runs with Qwen3-TTS-1.7B, six neutral preset profiles and VoiceDesign on the target VM and is reachable through the public test demo. This is real integration, but not yet an audio-quality or production approval.
IncluLearn.AI does not need to reinvent every target format and transformation. MathML, EPUB Accessibility, DAISY Pipeline, Pandoc and PlantUML illustrate different building blocks for open, interoperable and reusable workflows — without implying a final tool choice.
The public prototype is not the finished AI pipeline. It is an early working model for materials, review, release and accessible use. The important foundations are user goals, accessibility-first design, DE/EN and a clear distinction between demo and real functionality.
Modern Document AI models can reconstruct layout, text and scientific markup from visual documents. For IncluLearn.AI, this is an important building block — but it is not yet the subject semantics of circuits, UML, plots or other STEM artefacts.
Recent VLM research shows progress on charts, UML and scientific diagrams. At the same time, many benchmarks measure question answering rather than complete reconstruction — a crucial distinction for accessible STEM representations.
IncluLearn.AI does not want to reduce model quality to a single benchmark. Reference data, preprocessing, structured output, rules and review paths should first be compared under the same conditions; fine-tuning remains a targeted option for clearly identified error classes.
Public descriptions of media-centre workflows already provide concrete evidence about effort, bottlenecks and quality requirements. IncluLearn.AI nevertheless treats the resulting needs as hypotheses until they have been validated with practice partners and users.
IncluLearn.AI deliberately separates AI involvement, subject review and approval. Human ownership, risk-based review, provenance and cautious data classification are intended to make AI useful without transferring responsibility to the system.
IncluLearn.AI's technical foundation is being built reproducibly and with clear responsibility boundaries. The public test demo can be deployed automatically, while remaining deliberately separate from later production operation with real data and stronger security requirements.
Technical diagrams, mathematics, circuits and quantitative graphics carry structure and relationships that often cannot be represented meaningfully in one short image description. IncluLearn.AI therefore considers structured, textual, tactile and auditory representations.
From the needs hypotheses, we derived a first solution hypothesis: five core components with high strategic value, five subsequent production and integration services, and three specialised later options.
From the researched workflows, we derived twelve concrete needs hypotheses: from semantic preparation and expert review to reuse, examinations, provenance, output profiles and inclusive collaboration.
Public workflow descriptions point to high manual effort, long lead times, subject-specific transformation, established reuse practices and special examination requirements. For IncluLearn.AI, these are concrete signals of where semantic AI support may be useful.
IncluLearn.AI deliberately separates open exchange, authoritative subject artefacts and public communication. The key is not the communication channel itself, but ensuring that relevant feedback can be traced into requirements, decisions, evaluation and later publications.
Before the project start, central rules for collaboration, project steering, accessibility and AI use were structured, together with a concrete start plan for the first work package.