Inspiration
Field-data quality problems become harder and more expensive to fix when they are discovered only after data has already moved into cleaning, analysis or reporting. Missing identifiers, inconsistent household totals, implausible interview durations and weak GPS captures can all reach downstream workflows before a supervisor has seen the evidence. We were inspired to build a system that brings that review loop closer to the point of collection while remaining useful in environments where connectivity may be limited. We also wanted to challenge a common assumption in AI products: that the model should be the source of truth. FieldReady Local was designed around a different principle: AI can assist with interpretation, but deterministic evidence and the human reviewer should retain authority.
What it does
FieldReady Local is a local-first survey-quality review assistant for field supervisors.
A survey batch is imported against a versioned ruleset, and deterministic Python validation identifies issues such as completeness problems, duplicate identifiers, invalid categories or ranges, household inconsistencies, conditional missing values, implausible interview durations and poor GPS accuracy.
The supervisor then reviews each finding with its rule, category, severity, observed value, expected value, explanation and verification guidance. Review decisions are stored separately in SQLite, require an explicit reason and confirmation, and never modify the source CSV.
The browser communicates with a real self-hosted MCP server over Streamable HTTP. The MCP surface is intentionally limited to three tools: validate_batch, list_findings and get_review_summary. Review writes, filesystem access, shell commands, SQL and export operations are deliberately kept outside the model-facing tool surface.
An optional local AI model helps interpret what the supervisor is asking about, but it does not decide scope, create factual findings or save decisions. Python remains responsible for factual explanations, and the human remains responsible for the final decision.
Finally, FieldReady can export an audit-ready local package containing a Markdown summary, findings CSV, review-history CSV and integrity manifest with SHA-256 hashes. The raw source CSV is deliberately excluded.
How we built it
We built FieldReady Local as a deliberately small, auditable local stack using Python, the official MCP Python SDK v2, Streamable HTTP, Uvicorn, SQLite, HTML/CSS/JavaScript and Ollama with the local qwen2.5:1.5b model.
The architecture separates responsibilities clearly:
- Deterministic Python rules own validation and factual evidence.
- MCP exposes a bounded validation/evidence interface.
- Local AI performs only advisory review-focused classification.
- The browser presents evidence and the supervisor workflow.
- The human reviewer explicitly owns every saved decision.
- SQLite preserves review state and history locally.
The richer field-survey-v1.0.0 demonstration contains 14 fictional records and produces a fixed answer key of 17 findings across 13 affected records, including 3 critical, 9 high and 5 medium findings, with 80 evaluable and 5 not-evaluable rule applications.
Challenges we ran into
One of the biggest challenges was deciding how much authority to give the local language model.
Our first free-form model implementation produced plausible but unsupported factual statements. We then tested a model-based scope classifier, which achieved only 50% accuracy in the first broader benchmark. A later hybrid approach improved routing but still incorrectly rejected legitimate review questions.
Instead of trying to solve this only with more prompting, we changed the architecture. Scope became deterministic, factual wording moved entirely into Python, and the language model was reduced to a non-critical advisory role.
A second challenge was preserving auditability. We needed to keep source evidence, validation findings, AI assistance and human decisions clearly separated so that a model could never silently alter the underlying data or supervisor outcome.
We also learned that simply running on localhost is not proof of offline operation. We built an explicit offline verification gate that first checks that external network targets are unreachable and then exercises MCP, the browser backend, SQLite, local AI and the confirmed-review workflow.
Accomplishments that we're proud of
We are especially proud that FieldReady is not just a UI mock-up. The verified Windows workflow includes 115 passing M1 tests, MCP protocol 2026-07-28, real MCP restart persistence, real web-to-MCP-to-SQLite integration, a full MCP/web/export/restart test, and the exact 14-record / 17-finding / 13-affected-record demonstration.
We also demonstrated clean installation in a fresh environment, explicit network-disabled operation and real local Ollama inference.
Most importantly, we turned measured AI failures into a stronger product architecture rather than hiding them behind prompt changes. The final workflow preserves one coherent chain from validation, to evidence, to bounded AI assistance, to explicit human review, to an auditable local export.
What we learned
The most important lesson was that useful AI does not need unrestricted authority.
We learned that deterministic systems are better suited to owning facts, constraints and irreversible decisions, while language models can still add value by helping users interpret evidence and navigate a workflow.
We also learned that MCP is most useful when it is treated as an architectural boundary rather than merely an integration checkbox. Limiting FieldReady to three explicit MCP tools made it much easier to reason about what an assistant could and could not do. Finally, we learned that strong verification matters as much as implementation. Protocol negotiation, structured tool responses, restart tests and explicit offline checks gave us much stronger evidence than simply proving that an SDK could be imported.
What's next for FieldReady Local
The next step is to move from a hackathon demonstration towards a pilot-ready field-supervision tool while preserving the same authority boundaries that made the prototype reliable.
We would expand the library of reviewed, versioned survey rules; support additional questionnaire structures; improve batch-level diagnostics and supervisor reporting; strengthen local security and encrypted storage; introduce role-based access for multi-user deployments; and package the application more conveniently for field laptops and low-connectivity environments.
We would also like to pilot FieldReady with real survey teams so that future rule packs, review workflows and reporting features are shaped by actual field-supervision needs rather than only synthetic examples.
The principle would remain unchanged:
Evidence stays authoritative, AI stays bounded, and the human stays in control.
Log in or sign up for Devpost to join the conversation.