Software Modules

Software modules are production-ready, end-to-end pipelines that combine software components into a single, configurable workflow. They eliminate the need to wire components together manually — you provide the input and your field requirements, and the module handles transcription or parsing, schema generation, and structured extraction in one step.

See also: No-Code Assets for prompt templates and packaged skills.

Overview

---

Audio-to-Structured-Data

This module bridges the gap between spoken language and structured data. It combines the Transcriber and Extractor components into a single pipeline: audio is transcribed to text, and the text is processed against your field requirements to produce validated, structured output. Both the transcript and the extracted fields are returned together. The generated schema can be saved and reused on subsequent runs (save_schema() / load_schema()), making repeated processing fast and cost-efficient.

Example: A site worker records a 90-second voice note describing a water leak in the storage room. The module produces: a clean transcript ("At 14:30, a water leak was noticed in storage room B..."), and extracted incident fields: Event type: Water leak · Location: Storage room B · Time: 14:30 · Severity: Yes · Immediate action: Area cordoned off · Equipment affected: Electrical equipment near east wall.

What the module returns:

Key features:

• Single entry point for voice-to-data workflows
• Plain-language field requirements — no code or schema definition needed
• Returns both transcript and extracted data for full traceability
• Schema reuse eliminates redundant processing on repeated runs

Potential applications:

• Workplace incident and safety observation reporting

• Construction site and field work diary entries

• Field service and maintenance activity logging

• Quality inspection and audit recordings

• Medical and clinical dictation capture

• Sales call notes and customer interaction summaries

• Meeting minutes and action item extraction

• Implementation code: software_modules/audio_to_structured_data

• Usage examples: examples/audio_to_structured_data

---

Document-to-Structured-Data

This module turns static documents into structured, queryable data. It combines the Document Parser and Extractor components: a document is first converted to clean markdown, then processed against your field requirements to extract exactly the data you need. The module supports both vision-based and local parsing strategies, making it adaptable from clean digital PDFs to visually complex, multi-column layouts.

Example: A scanned 8-page supplier invoice PDF with embedded tables is parsed into clean markdown. The module extracts the required fields: Invoice number: INV-20241103 · Supplier: Acme Components Ltd · Total (excl. VAT): €4,820.00 · Due date: 30.11.2024 · Line items: 3.

What the module returns:

Key features:

• Configurable parser choice — vision-based for complex layouts, local for speed and cost efficiency
• Plain-language field requirements eliminate manual schema work
• Returns both parsed text and extracted data for full traceability
• Schema reuse supports efficient batch processing across large document sets

Potential applications:

• Invoice and purchase order data capture from PDFs

• Contract and agreement key term extraction

• Technical specification and datasheet processing

• Research report and regulatory filing analysis

• CV and job application data extraction

• Insurance and financial form digitization

• Product catalogue and pricing data ingestion

• Implementation code: software_modules/documents_to_structured_data

• Usage examples: examples/documents_to_structured_data

---

RAG-Workflow

This module enables question-answering over document collections. It combines the RAG parser, embedder, vector store, retriever and answer generator into a complete workflow with two phases: an indexing phase that parses, embeds, and stores documents, and a query phase that retrieves relevant context and generates answers with citations. The module maintains a persistent vector store and optional conversation history, making it suitable for interactive document exploration and knowledge retrieval applications.

Example: A team indexes 50 technical specification PDFs. Later, a user asks: "What is the maximum operating temperature for component X?" The module retrieves relevant chunks and responds: "The maximum operating temperature for component X is 85°C [Source: TechSpec_X_v2.pdf, page 4]. For extended duty cycles, derate to 70°C [Source: OperatingGuide.pdf, page 12]."

What the module returns:

Key features:

• Two-phase workflow: index once, query many times
• Persistent vector store — indexed data reused across sessions
• Configurable retrieval: top-k, score threshold, hybrid search, reranking
• Citation support — every answer references source documents and pages
• Optional conversation history for multi-turn dialogue
• Streaming response support for real-time UX
• PostgreSQL / pgvector support available at the component level for custom pipelines

Potential applications:

• Internal knowledge base search for technical documentation

• Compliance and policy Q&A over regulatory documents

• Research paper exploration and literature review assistance

• Customer support knowledge retrieval from product manuals

• Legal contract and case law research

• Medical guideline and protocol reference systems

• Educational content Q&A and study assistance

• Implementation code: software_modules/RAG_workflow

• Usage examples: examples/RAG_workflow

---

Report-Writer

This module writes a fixed-template report, such as a building condition assessment, from mixed source files. It follows CURACT (Curation-Anchored, Governed, Traceable Reporting) and runs three stage components in turn: the Source Normalizer, the Knowledge Curator and the Report Synthesizer. One JSON report spec defines the report: title, language, sections with their required items, report instructions, sources grouped as primary and secondary, an optional sample report and an optional model for each role. Each stage saves plain files to a workspace folder that the next stage reads. A person can inspect and edit the files of any stage and rerun only the later stages.

The curation stage extracts fact units with verbatim quotes for each technical section and checks every quote against its source. The writer drafts each section from its own knowledge file only, and a separate reviewer model checks the draft with exact search-and-replace edits. Sections with depends_on, such as recommendations and a summary, are written afterwards from the reviewed texts of the sections they depend on. A single-call mode writes the whole report in one call from every source, as a baseline that shows what curation and review add.

Example: The house construction report example describes a fictional 1½-storey timber-frame house built in 1978. Its spec lists three site recordings as primary sources, and two PDF reports, a DOCX moisture survey, an XLSX maintenance log and a floor plan image as secondary sources. A sample report on another house sets the format and tone. The recordings are synthesized from written scripts by the example's generate_dataset.py (a paid text-to-speech call), so run it before the first report. The module writes one knowledge file for each of the five technical sections. A building services unit, for example, quotes the 1998 renovation report word for word: "Mechanical ventilation system installed during 1998 renovation. Design life 25 years." The dataset's expected behaviours include: the 1998 replacement of the distribution board is attributed to the renovation report, the vibration of the supply-air unit is narrated as a field observation, and (missing: latest sewer camera inspection) appears because no source covers that required item. The recommendations and the summary are written last, from the reviewed sections.

What the module returns:

Key features:

• One report spec (ReportSpec.load("report_spec.json")) with an optional model per role: vision, transcription, curator, writer and reviewer, and optional settings: transcription language, parallel curation, review attempts, strict review, DOCX output, and reasoning effort and temperature per step. The spec holds no credentials; an unknown key such as api_key raises
• Inspectable stages: run() executes all three stages, and normalize(), curate() and synthesize() each run one, so a run can resume from edited knowledge files
• No-model rebuild: rebuild() reassembles report.md and report.docx from edited section files without an LLM call
• Verified quotes: every quote must appear in its cited source, ignoring only whitespace; a section that still fails after one retry stops the run
• Role separation: the curator, the writer and the reviewer are separate calls, each with its own model setting
• Explicit gaps: a required item that no source covers becomes (missing: <item>), and an unresolved conflict is stated with both views
• Fails loudly: an unsupported, unreadable or empty source stops the run; with settings.strict_review, so does a reviewer edit that cannot be applied
• Install: pip install "gaik[report-writer]". The stages save report.docx unless settings.docx is off, which needs the Pandoc binary. Recordings go to the Transcriber, which needs OpenAI or Azure OpenAI
• Token usage: each stage result has usage: transcription and vision for normalize(), the curator for curate(), the writer and reviewer for synthesize()

Potential applications:

• Building and property condition assessments from site recordings and customer documents

• Technical due diligence of properties

• Machinery audits and field service reports

• Environmental site assessments

• Clinical case summaries

• Meeting reports from a recording, notes and supporting documents

• Legal due diligence, with the executed documents declared the primary sources

• Interactive demo: Report Writer demo

• Use case: Report Writing

• Implementation code: software_modules/report_writer

• Usage examples: examples/report_writer

---

Multi-Source-Report-Generator (legacy)

This module is kept as the legacy report writer; its successor is Report-Writer.

This module generates a fully user-defined long-form report from any mix of source files. You define the use case: report title, a description of the report's purpose, and as many sections as needed — each with a plain-language instruction describing what to extract from the evidence and what the section should contain. The module normalises every input file (PDF, Word, Excel/CSV, audio/video, images, text) into a common Markdown evidence pack. By default it writes the whole report in a single LLM call; with agentic=True (and the multi-source-report-generator-agentic extra) it runs an agentic workflow that drafts each section independently, fact-checks and repairs it with a diff-editor reviewer, and assembles the final report in your original section order.

In agentic mode, sections can declare dependencies on other sections using depends_on (single-call mode ignores it). Sections with no dependencies run in parallel; dependent sections wait for their dependencies to be finalized and receive their content as context — enabling a Summary or Recommendations section to synthesize from what earlier sections already established. The complete use-case configuration can be saved to a JSON file and reloaded for repeat runs on new evidence.

Example: A consultant uploads a meeting recording (MP3), a project budget (Excel), and a policy PDF. They define three sections — AI Maturity Level, Current Development Stage, and Recommendations (which depends on the first two). The module transcribes the audio, parses the documents, drafts and fact-checks each section in parallel, then writes Recommendations last using the finalized earlier sections as context. The output is a formatted Markdown report with a matching Word document.

What the module returns:

Key features:

• Fully user-defined use case — report title, description, and any number of sections each with a plain-language instruction specifying what to extract and how to write it
• Agentic per-section workflow (opt-in, agentic=True) — independent drafting, mandatory diff-editor reviewer repair, optional style polish per section
• Dependency-ordered sections (agentic mode) — depends_on lets summary or recommendation sections synthesize from finalized earlier sections rather than re-deriving from raw evidence
• Mixed input normalization — PDF, Word, Excel/CSV, audio/video, images, and plain text all processed in a single pipeline
• Optional sample report — provide an existing report to enforce a specific format, tone, and length; the writer mirrors its structure without copying content
• Config persistence — save the full use-case definition (sections, options, paths) to JSON with save_report_config; reload with load_report_config for repeat runs on new evidence
• Dual output — Markdown always produced; Word document optional

Potential applications:

• Meeting reports and advisory summaries from transcripts and supporting documents

• Client-facing project and progress reports from mixed deliverables

• AI readiness and consultancy assessments from interview recordings and documents

• Due-diligence and audit reports from heterogeneous evidence sources

• Research and literature summaries across documents and recordings

• Sales proposals and marketing materials from briefs and assets

• Interactive demo: Report Writer (legacy) demo

• Implementation code: software_modules/multi_source_report_generator

• Usage examples: examples/multi_source_report_generator