Laterlight: Upload the Paperwork, Get a Verified To-Do List 🦥

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

🚀 Try Laterlight

Open the Live Demo · Alternative Render Demo · View Source on GitHub

What I Built

Everyone has the pile: an invoice you'll pay "later", a renewal notice buried in a PDF, or a contract with exactly one date that matters.

Laterlight turns that pile into a to-do list. Upload a TXT, PDF, or DOCX document, and an open-weight model extracts what needs doing, who it involves, how much, when it's due, and how urgent it is. A follow-up draft is ready for review, while a dashboard helps organize tasks into overdue and due-soon items.

The chore	Without Laterlight	With Laterlight
Find the important date	Re-read the whole document	Extracted with supporting evidence
Work out who and how much	Hunt through paragraphs	Structured fields
Write the reply	Stare at a blank email	A draft ready to review
Remember it	Hope	An action dashboard

The problem it solves

A chat summary is still prose you have to turn into tasks—and you have to trust what it says. Laterlight focuses on the gap between "I received a document" and "I did the thing."

The goal isn't just to summarize paperwork. It's to turn it into an actionable queue where extracted details are backed by evidence from the original document.

What makes it different?

• ✅ Evidence-checked, not trust-me. Extracted items carry evidence quotes that are checked against the document text.
• ✅ Actions, not just summaries. Due dates, amounts, counterparties, priorities, and follow-up drafts are structured for review.
• ✅ You stay in charge. Suggestions are advisory; users remain responsible for reviewing and acting on them.
• ✅ Guardrails around a small model. Schema validation, evidence checks, and one repair attempt help catch malformed or unsupported output.
• ✅ Open and swappable. The model is configured separately from the application logic, keeping the AI provider replaceable.
• ✅ Careful document handling. Upload validation, input limits, and per-user data isolation help reduce security and privacy risks.

How I Built It

Open-weight AI: Qwen3.5-4B, using the tinker Python SDK. The backend is built with FastAPI, Pydantic, and SQLAlchemy; the frontend uses React, Vite, TypeScript, and Tailwind CSS.

The processing pipeline:

1. Validate the upload: Allowlisted extensions, MIME checks, file-signature checks, and a 10 MB size limit.
2. Parse and sanitize: Extract text from PDFs and DOCX files, including tables, strip control characters, and cap the input at 12,000 characters.
3. Generate structured output: Use a schema derived from the same Pydantic model that validates the model's response.
4. Verify the evidence: Validate the response and check that extracted evidence quotes actually appear in the document.
5. Repair once: Give malformed output one repair attempt. API errors are surfaced as sanitized errors rather than repeatedly retried.
6. Process updates safely: Match existing actions and mark outdated ones as superseded instead of creating duplicates.

Testing: The backend has 32 tests using a mocked SDK, so the test suite does not need live or paid model calls. Without an API key, the app can use a basic regex-based extractor; when a key is configured, it does not silently switch AI providers.

Built with GitHub Copilot. I used Copilot as a pair programmer while building and debugging the application, from project structure and backend integration to extraction validation and testing.

Why Does Open Innovation Matter?

An important distinction: Laterlight uses Tinker's hosted API to run Qwen3.5-4B. That means document text is sent to the hosted service when AI processing is requested. Laterlight is not an offline application, and I haven't benchmarked it against a closed model, so I won't claim it extracts better.

What open weights changed in the design:

• Less lock-in: The model is configured separately, and the provider sits behind an interface. A self-hosted provider could be added without rewriting the application, although that provider is not implemented yet.
• A model people can explore: A 4B-parameter model offers a smaller starting point for experimenting with self-hosting than a much larger model.
• More reproducible experiments: The model, prompt template, and sampling settings can be pinned, making it easier to investigate and reproduce extraction behavior.

For me, open innovation isn't just about choosing an open model. It's about building an application where the model's output can be inspected, validated, and challenged rather than blindly trusted.

What's Next?

I'd like to keep improving extraction reliability, expand automated end-to-end coverage, and explore a self-hosted provider for people who want to process sensitive paperwork without sending document text to a hosted model.

The goal is simple: less time buried in paperwork, more confidence about what needs to happen next.

Try it out: querysmith.tech

Explore the code: github.com/kushal-pandey/Laterlight

Thanks for checking out Laterlight! 🦥