This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady
What I Built
Meet ProofPocket — an open-weight AI paperwork agent built around a simple idea: people shouldn't have to spend hours organizing documents when AI can handle the repetitive work.
Whether you're preparing a scholarship application, organizing internship documents, or gathering paperwork for a program, the process is often the same: read the requirements, search through files, figure out what's missing, rename documents, and double-check everything.
ProofPocket turns this tedious process into a structured, reviewable workflow.
Here's what it does:
- Understands requirements: Converts application instructions into a structured checklist.
- Finds relevant evidence: Matches uploaded documents to requirements and explains why each match was suggested.
- Flags missing information: Identifies missing documents, incomplete evidence, and ambiguous matches instead of blindly marking everything complete.
- Organizes the paperwork: Suggests descriptive filenames and creates a downloadable application pack.
- Keeps humans in control: Lets users review the results, correct mistakes, and approve the final pack before downloading it.
The goal isn't to replace human judgment. It's to eliminate the repetitive work that gets in the way of it.
Instead of manually checking every document against every requirement, users can focus on the exceptions that actually need their attention.
Demo
Code
Repository: ProofPocket on GitHub
The project is designed to be open source, with a modular AI architecture so developers can inspect, modify, and extend how document analysis works.
How I Built It
ProofPocket combines a modern web application with an open-weight AI model and a structured document-processing pipeline.
The technology stack:
- Next.js and TypeScript: The web application, dashboard, document upload workflow, and review interface.
- Google Gemma: The open-weight AI model used to interpret requirements, extract structured information from document text, and reason about potential evidence matches.
- MongoDB Atlas: Stores project metadata, requirements, extracted fields, and relationships between documents and evidence.
- Render: Hosts the application and its backend.
- Sentry: Provides error monitoring and visibility into processing failures.
The processing pipeline separates deterministic operations from AI reasoning.
First, uploaded files are validated and their text is extracted using suitable document-processing tools. The extracted text and application instructions are then passed through structured analysis. Gemma helps interpret the requirements and suggest relationships between available documents and required evidence.
The application validates the resulting structured data and presents each match with its supporting evidence. When the evidence is insufficient or ambiguous, the requirement is sent for human review instead of being automatically marked as satisfied.
Finally, the user can review the proposed document pack and generate a ZIP containing organized files and reports.
This separation is important: the model handles language and ambiguity, while deterministic code handles validation, file operations, and output generation.
The application is designed to support a configured Gemma inference endpoint rather than requiring large model weights to run on the web server itself. This keeps the deployment practical while preserving the ability to experiment with different open-weight model configurations.
Why Does Open Innovation Matter?
For ProofPocket, open innovation is about more than avoiding dependence on a single model API.
1. The reasoning can be inspected and changed.
Document requirements vary significantly. A scholarship application, internship application, and academic program may use different terminology for similar documents. An open-weight model makes it possible to experiment with prompts, model versions, and fine-tuning strategies to improve how the system interprets these requirements.
2. The model is not locked into one provider.
By separating the AI provider from the application logic, developers can evaluate different compatible inference setups without rewriting the entire product. This makes it easier to compare quality, latency, and cost.
3. Local inference becomes a possible deployment option.
A compatible local inference setup can allow document analysis to run on a user's own machine, reducing the need to send sensitive document text to an external inference provider. This requires suitable hardware and configuration, but it offers a meaningful privacy advantage for users who need it.
4. The workflow can improve through reproducible evaluation.
Developers can create synthetic test documents, define expected requirements and evidence matches, and evaluate where a model makes mistakes. They can investigate false positives, adjust the pipeline, and share improvements with the community.
That last point matters particularly for paperwork automation. A system that confidently makes an incorrect match can be worse than one that admits uncertainty.
Open innovation gives developers more freedom to investigate those failure modes rather than treating the model as an unquestionable black box.
One important distinction: hosting ProofPocket on Render does not automatically make document processing private or offline. The privacy characteristics depend on where the inference runs, what information is transmitted, and how the application handles uploaded files.
My Agent Session
The Lazy Payoff
The real payoff is reducing the number of repetitive decisions a person has to make.
Without ProofPocket, someone might repeatedly switch between an application instruction PDF, their downloads folder, scanned certificates, and a checklist to determine whether everything is ready.
With ProofPocket, the intended workflow is simpler:
Upload → Analyze → Review exceptions → Download.
The system brings the relevant evidence and missing items together, reducing unnecessary searching and repeated checking.
I want the most meaningful measure of success to be the time spent reaching a correct, reviewable application pack—not the number of AI calls or the number of documents processed.
The evaluation should compare manual completion time against assisted completion time using the same document set, while also measuring incorrect matches and missed requirements. That way, any time savings can be assessed alongside the accuracy of the result.
Prize Categories
- Render — Best Use of Render: Hosting the deployed application and backend.
- Gemma — Best Use of Gemma: Using an open-weight model for requirement interpretation and evidence matching.
- MongoDB — Best Use of MongoDB Atlas: Managing project data and document-to-requirement relationships, with semantic retrieval where configured.
- Sentry — Best Use of Sentry Agent Tracing: Observing processing stages, errors, and performance.
These categories reflect the intended integrations; the final submission should include only those that are actually implemented and demonstrable.
Top comments (0)