Axiom

Axiom

Inspiration

In an age of information overload, misinformation is a constant threat. While tools like Grammarly masterfully correct our grammar, we lack a similar safety net for the accuracy of our content. A simple factual error in notes, an email, or a report can instantly undermine credibility. We were inspired to create a tool that seamlessly integrates fact-checking into the writing process itself, stopping misinformation before it even starts. We envisioned a "Grammarly for facts"—an intuitive, real-time assistant to ensure everything we write is not just eloquent, but also true.

What it does

Axiom is a real-time, in-editor fact-checker that functions as a browser extension. As a user types in a web-based editor like Google Docs, Axiom's AI backend works silently to analyze each sentence. When it detects a statement that makes a verifiable claim, it extracts the core fact. If this fact is incorrect, Axiom highlights the statement instantly, just like a spelling or grammar checker. This allows users to catch and correct factual errors on the fly, ensuring their writing is credible and accurate from the moment they type it.

How we built it

Axiom is a hybrid system combining a browser extension frontend with a sophisticated Python backend, powered by the OpenAI API and Wikidata.

Frontend: A JavaScript-based browser extension monitors the user's text input in real-time. It identifies complete sentences and sends them to our backend for analysis.
Backend NLP Pipeline: Our Python server orchestrates a multi-step fact extraction process:
- Claim Detection: A gpt-4o-mini model first determines if a sentence is making a verifiable factual claim, filtering out questions and opinions.
- Triplet Extraction: For claims, a second, more powerful prompt asks the AI to extract up to k plausible facts as (Subject, Relation, Object) triplets. Crucially, we ask the AI for the canonical name of the relation (e.g., "position held"), which is a language task it excels at.
- Entity Mapping: We map the text-based Subject and Object to their official Wikidata Q-IDs using a massive, locally-stored lookup map built from the wikidata5m_entity.txt dataset.
- Relation Mapping: To get the most accurate Property ID, we perform a live API search against the Wikidata API for the Relation text provided by the AI. This is far more robust than a local lookup.

The final output is a structured, queryable triplet of IDs, ready for verification.

Challenges we ran into

Our biggest hurdle was bridging the gap between ambiguous human language and structured data.

Semantic Ambiguity: The phrase "born in" can refer to a place (P19) or a date (P569). Our initial local file lookups completely failed to understand this context. The solution was to delegate this semantic reasoning to the LLM.
AI Hallucinations: When we first asked the LLM to give us a Wikidata Property ID directly, it would often just make one up! We learned that a hybrid approach—asking the AI for the relation's name and then using our code to look up the real ID—was far more reliable.
Entity Mismatches: The AI would output "Obama," but our local file might only have "Barack Obama." We had to build a comprehensive lookup map containing all possible aliases for millions of entities to make the matching process work.

Accomplishments that we're proud of

We're incredibly proud of building a complete, end-to-end NLP pipeline in just a few days. The system successfully translates messy, complex sentences into the structured, verifiable triplets needed for fact-checking. The hybrid approach, which combines the language power of an LLM with the ground truth of Wikidata's API and our local data, is a sophisticated solution that actually works.

What we learned

This project was a deep dive into the art of prompt engineering and the power of hybrid AI systems. We learned that the success of an AI often depends on a single, well-crafted sentence in its prompt. More importantly, we discovered that the most robust systems don't rely on an LLM alone; they use it as a "language expert" to structure data, and then use deterministic code and trusted databases to handle the final verification.

What's next for Axiom

The foundation is built, and the next steps are clear.

Full Verification Loop: Use the generated ID-based triplets to perform a SPARQL ASK query against Wikidata to get the final true or false verdict.
Enhanced UI: Develop a Grammarly-style pop-up that not only highlights an error but also suggests a correction or provides a link to a credible source.
Platform Expansion: Move beyond Google Docs to support other platforms like email clients, social media, and more.
Implement the Fallback: For facts that can't be structured into triplets, build the alternative checking method using the Wikipedia API to provide broader coverage.