Inspiration

Finding a local festival should take one question, not an afternoon of detective work. In practice, event details are scattered across websites, social posts, conversations with friends, and posters around town. Even an AI assistant can confidently return an outdated date or confuse an event with one in a similarly named place when its underlying sources disagree.

OpenEvents grew from that frustration. People need event answers backed by current evidence, able to distinguish independent confirmation from copied listings, and open to corrections from the community.

I also wanted to build for a world in which people increasingly interact with services through AI assistants—not force them to navigate yet another standalone event website. That is why MCP is the primary interaction layer. It lets agents search verified events, inspect evidence and conflicts, and submit new sources or corrections directly from a conversation. The web application is deliberately secondary: it makes the provenance and reasoning behind each answer transparent.

What it does

OpenEvents gives AI assistants a shared trust layer for public events anywhere—local or online. It compares conflicting claims field by field, traces every value back to evidence, detects when several listings copied the same source, and returns the most defensible current details with an explanation.

The primary experience is conversational:

  1. Ask an AI assistant what is happening nearby, on a particular date, or online.
  2. The assistant queries OpenEvents through MCP and answers with verified details and any important caveats.
  3. If something is missing or wrong, share a source, poster, or correction in the same conversation.
  4. The assistant submits that evidence to OpenEvents, which appends the new claims without erasing the old ones and recalculates the result.

MCP is the main delivery surface. The React web experience is a transparency companion: it shows people and judges exactly which values were selected, which sources agree, and why an AI assistant may or may not recommend an event.

This repository is an end-to-end hackathon MVP: an append-only SQLite assertion ledger, a fixed-rule assertion parser, a deterministic TypeScript trust engine, a stdio MCP server for conversational agent access, and a React verification experience.

How we built it

I started with research rather than code. Using GPT-5.6 Pro in ChatGPT, I investigated publicly documented trust and reputation patterns used by platforms that depend on user-contributed information, including Google Maps, Airbnb, and eBay. The goal was not to reproduce their proprietary algorithms, but to understand the underlying principles: authority depends on context, recent evidence should matter more than stale evidence, copied sources are not independent confirmation, unresolved conflicts must remain visible, and higher-risk actions require stronger evidence.

From that research, I defined the core trust model for OpenEvents. Instead of storing one mutable event record, the platform keeps every submitted value as an append-only assertion with its publisher, source, evidence, timestamps, and provenance. Confidence is calculated separately for the title, time, location, status, and ticket URL. Sources that copied the same announcement are grouped into one provenance cluster, and different actions—such as displaying, recommending, or booking an event—use different confidence thresholds.

I then turned the product requirements and trust-model research into a detailed build prompt for Codex, running GPT-5.6 Sol with Ultra reasoning. Codex divided the work across parallel agents covering the domain model, SQLite persistence, HTTP server, MCP interface, React frontend, fixtures, tests, and documentation. It also discovered and reused locally installed skills and existing project conventions rather than treating the repository as a blank slate.

The resulting MVP uses TypeScript throughout. It includes an append-only SQLite assertion ledger, a pure deterministic verification engine, conservative provenance detection, three structured MCP tools, and a web experience for inspecting the evidence behind an agent's answer. A controlled seed scenario demonstrates the central problem: three aggregators repeat the same outdated start time, while an official organizer and an independent venue publish a newer time. OpenEvents correctly counts the three copied pages as one source lineage and selects the independently confirmed update.

I stayed actively involved in the product and architectural decisions throughout the build. Codex initially treated the MCP interface as a reason to submit OpenEvents under Developer Tools, but I redirected the positioning toward Apps for Your Life: MCP is only the infrastructure, while the actual product helps ordinary people discover and correct trustworthy event information through chat. I also decided to remove the initial runtime GPT integration. GPT-5.6 helped research and build the system, but OpenEvents itself should not depend on probabilistic model output when determining event facts.

Finally, Codex validated the implementation with deterministic fixtures, domain and integration tests, type checking, linting, production builds, and HTTP and MCP smoke tests. The complete demo runs locally without an API key, model connection, or unpredictable live website. Given the same assertions, configuration, and evaluation time, OpenEvents always returns the same selected values, confidence breakdowns, explanations, and action decisions.

Challenges we ran into

The hardest challenge was balancing openness with trust. OpenEvents should let anyone contribute a new event or correction through chat, but a low-friction contribution model can also admit stale, copied, mistaken, or malicious information. A single opaque trust score would hide that tension rather than solve it.

The solution was to preserve every claim as an append-only assertion and assess each event field independently. Source authority, publisher reliability, freshness, provenance, corroboration, conflicts, and parsing uncertainty remain explicit. This keeps contribution easy without treating every contribution as equally trustworthy.

Accomplishments that we're proud of

In a few focused hours, I turned the idea into a runnable end-to-end MVP: an append-only SQLite ledger, deterministic field-level verification, copied-source detection, action-specific trust policies, three MCP tools, a polished evidence interface, deterministic fixtures, and meaningful automated tests.

I am especially proud of the demo scenario: three websites report the same outdated start time, but OpenEvents recognizes that they copied one source. A newer organizer update and an independent venue confirmation win—while the rejected claims remain visible and inspectable.

What I learned

  • GPT-5.6 Sol with Ultra reasoning coordinated parallel Codex agents efficiently without excessive token usage. This made it practical to work on the domain model, UI, documentation, and quality checks concurrently.
  • Codex automatically discovered and reused my locally installed skills and project conventions, helping the implementation take shape without requiring every workflow detail to be specified manually.
  • Research with GPT-5.6 Pro in ChatGPT helped me explore the factors behind deterministic trust scoring. Implementing that research reinforced an important boundary: AI can help investigate the model, but production scores should remain explicit, reproducible, and testable.
  • Fast agentic execution still requires strong human product direction. Codex initially recommended the Developer Tools category because OpenEvents exposes MCP. I redirected it to Apps for Your Life because MCP is infrastructure—the actual product is for people discovering and correcting trustworthy events through the AI assistant they already use.

What's next for OpenEvents

  • add event data via MCP
  • Deploy a public beta with a stable, hosted MCP endpoint.
  • Build a conversational interface on top of the MCP service and publish it as a ChatGPT app or plugin, so people can discover and correct events without using a form.
  • Let organizers, venues, and other event providers create verified profiles and build a field-specific reliability history.
  • Add policy-gated ticket and booking integrations that act only when the event status, time, location, and ticket URL meet the required confidence thresholds.

Built With

Share this project:

Updates