TASCO submission

Inspiration

TASCO started from a very specific systems problem: most enterprise knowledge already exists, but it is trapped inside static PDFs, annual reports, operating manuals, and compliance documents that were never designed for retrieval, pedagogy, or mobile consumption. We were interested in whether a single ingestion pipeline could convert those dense artifacts into a typed, multimodal learning object without requiring a human curriculum team to manually rewrite every document into lessons, cards, slides, and quizzes.

The motivating insight was that internal training is usually bottlenecked less by content scarcity than by transformation cost. TASCO treats enterprise documents as a high-entropy source corpus and compiles them into structured learning surfaces for employees in either English or Vietnamese. Instead of building “yet another PDF viewer,” we built a document-to-learning compiler that optimizes for operational usability, schema integrity, and deployment realism.

What it does

TASCO is an end-to-end document ingestion and study-delivery system. An admin uploads a PDF into a password-gated studio, the backend extracts and cleans the source text, pushes the job through a background processing queue, generates a fully structured chapter package, and publishes it to a mobile app. Each published chapter contains a normalized summary, exactly 6 lesson sections, 20 flashcards, 8 slides, 20 quiz questions, an audio transcript, and a downloadable PPTX artifact generated from the same underlying slide JSON.

On the client side, the mobile app exposes the generated chapter as multiple learning interfaces rather than a single long transcript: a reading view, flashcard deck, slide view, quiz engine, and audio/transcript surface. The app also caches chapter data locally and persists user progress, so the system behaves like a real training product rather than a thin demo wrapper around an LLM response. In practice, that means TASCO converts unstructured enterprise documents into reusable, bilingual, mobile-first learning modules with deterministic shape guarantees.

How we built it / How we used Qwen

We built TASCO as a TypeScript monorepo with a Railway-hosted Express backend, SQLite persistence, filesystem-backed artifact storage, a lightweight admin interface, and an Expo Router mobile client. The critical design choice was to define a strict shared schema for generated content and make both the server and the mobile app consume that same contract. That gave us a typed generation target instead of treating model output as an opaque blob of prose. The backend handles PDF upload, text extraction, cleaning, queueing, generation, normalization, persistence, publication, and PPTX export; the mobile layer simply renders the canonical typed chapter object.

Qwen was used as the primary structured-generation engine, not as a general chatbot. We integrated it through DashScope’s OpenAI-compatible chat/completions interface, explicitly requested json_object output, and disabled free-form reasoning traces to reduce format drift. We prompt Qwen to synthesize a fixed pedagogical object model from the extracted source text: title, description, summary, lesson sections, flashcards, slides, quiz questions, and audio transcript. We then run the response through JSON recovery, normalization, and Zod validation so partially correct outputs can still be repaired into a valid chapter package. We also use the same provider path for cross-language generation/translation when the source document language differs from the learner-facing target language.

Challenges we ran into

The hardest problem was not UI or even model prompting; it was making noisy enterprise PDFs behave like machine-tractable source material. Real documents contain page furniture, repeated headers, table-of-contents fragments, broken line wraps, bilingual text, and formatting artifacts that can seriously degrade downstream generation. We had to build a text-cleaning layer that strips repeated document scaffolding, merges broken narrative lines, scores paragraphs for semantic density, and selects source excerpts that are likely to contain meaningful facts rather than decorative layout noise.

The second major challenge was generation reliability under hard structural constraints. Asking a model for “exactly 6 lesson sections, 20 flashcards, 8 slides, and 20 quiz items” sounds simple, but in practice you get malformed JSON, off-by-one counts, shallow restatements, or content that is semantically plausible but structurally invalid. We addressed that by combining provider timeouts, JSON candidate extraction, schema normalization, fallback synthesis, and a provider-agnostic execution layer. That let us preserve demo reliability even when the live provider path did not consistently return a fully compliant object on the first try.

Accomplishments that we're proud of

The accomplishment we are most proud of is that TASCO is not a prompt demo; it is a functioning ingestion-to-delivery system. A document can be uploaded, processed, persisted, published, consumed on mobile, and exported as a slide deck through a single operational pipeline. That required getting backend orchestration, content contracts, artifact generation, persistence, deployment, and client rendering to line up under hackathon time constraints.

We are also proud of the failure-tolerance architecture. Rather than assuming the model will always behave, we designed TASCO so that every chapter still resolves into a usable learning object even when provider behavior is imperfect. The system degrades gracefully from model-generated structured content to normalized or deterministic content while preserving the same external schema. For a judge looking at engineering quality, that matters more than a flashy one-shot LLM call.

What we learned

The biggest technical lesson was that the winning abstraction is not “prompt in, text out”; it is “source in, typed artifact out.” Once we started treating generated content as a first-class data structure with explicit invariants, the entire system became easier to reason about, test, render, and recover. Shared schemas, post-generation normalization, and deterministic repair logic were substantially more valuable than prompt iteration alone.

We also learned that document-grounded AI products live or die on preprocessing and validation. PDF extraction quality, line-join heuristics, source-language detection, and schema conformance have outsized impact on perceived intelligence. Qwen’s API compatibility made integration fast, but production-grade behavior still required aggressive guardrails around timeout handling, JSON parsing, count normalization, and content fallback. In other words, model capability matters, but systems engineering matters more.

What's next for TASCO submission

The next step is to move from “high-confidence prototype” to “source-grounded enterprise learning platform.” Technically, that means adding citation-level traceability from every lesson element back to exact source spans, improving extraction with OCR and table-aware parsing, and replacing heuristic excerpt selection with retrieval-driven chunking. We also want to add true audio synthesis, richer admin observability, and regression evaluation that scores faithfulness, schema compliance, and pedagogical coverage across a corpus of real TASCO documents.

From an architecture perspective, we would harden the storage and processing layer by moving from local SQLite/filesystem assumptions toward Postgres, object storage, and a more durable job system. That would make TASCO ready for multi-document indexing, higher ingestion throughput, and team-scale content operations. The core thesis remains the same: enterprise documents should be compilable into structured learning experiences, and TASCO is the first version of that compiler.

Built With

• codex
• qwen