Board Game Rule Conflict Resolver

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Board Game Rule Conflict Resolver is a source-grounded tournament judge for resolving ambiguous board game interactions.

Players enter:

• The cards involved
• The current game phase
• Their rules question

The agent retrieves structured card text, official interaction rulings, errata, and core rule priorities from Sanity before producing a ruling.

The resolver is designed to avoid inventing rules. When Sanity does not contain enough authoritative information, it returns a low-confidence response explaining that there is insufficient official data rather than guessing.

The demo dataset contains fictional board game content, including:

• Card mechanics and effect text
• Trigger phases and keywords
• Core rule priorities
• Explicit multi-card interaction rulings

Demo

Try the deployed application:

Open Board Game Rule Conflict Resolver

Recommended demo flow:

1. Open the resolver.
2. Ask about Mirror Shield versus Piercing Bolt.
3. Try the three-card interaction involving Chain Lightning, Sanctuary Zone, and Blood Pact.
4. Try an unknown card such as Mystic Dragon to see the strict low-confidence fallback.
5. Open Sanity Studio at /studio and update the official ruling for an interaction.
6. Submit the same question again and observe how the retrieved Sanity content changes the answer.

Code

GitHub repository

The main implementation is organized around:

• Next.js App Router
• /api/resolve-conflict agent endpoint
• Sanity schemas and seeded content
• GROQ-backed local tools
• Sanity Context MCP integration
• A browser-based resolver UI
• An end-to-end agent test suite

How I Used Sanity

Sanity is the structured source of truth for the agent.

I modeled three document types:

gameCard

Stores:

• Card name
• Stable card slug
• Card type
• Trigger phase
• Keywords
• Effect text

gameRule

Stores:

• Rule title
• Rule code
• Rule category
• Priority order
• Rule text

interactionConflict

Stores:

• Conflict title
• Linked cards
• Conflict description
• Official ruling
• Governing rule

The agent exposes tools for:

• Looking up card documents by name or slug
• Finding interaction conflicts linked to the retrieved cards
• Retrieving ordered core rules by category

The intended agent workflow is:

1. Retrieve every named card from Sanity.
2. Use the returned card identifiers to search for linked conflict and errata documents.
3. Retrieve relevant rule-priority documents.
4. Use the official ruling as primary evidence when an explicit conflict document exists.
5. Return a JSON ruling with a verdict, reasoning, cited documents, and confidence level.

The server can use Sanity Context MCP tools when configured. It also includes local GROQ-backed tools for the same structured content workflow.

The agent is explicitly instructed to rely only on retrieved Sanity context. If no definitive card, conflict, errata, or rule data exists, it returns:

Insufficient official data in Sanity Content Lake to render an absolute judgment.

This makes content editors part of the rules-maintenance workflow: updating a ruling in Sanity changes the evidence used by the resolver without changing application code.

Sanity Project Details

Sanity project ID: kjwkn2a2
Dataset: production

The project contains the structured demo cards, core rules, and interaction conflict documents used by the resolver.

The seeded content is fictional demo content created for this challenge. It is intended to demonstrate the content architecture and agent workflow rather than represent official rules for an existing commercial game.

Technical Highlights

• Next.js 16 App Router
• React 19
• TypeScript
• Sanity Studio
• GROQ queries
• Sanity Context MCP
• Groq-compatible model tool calling
• Strict JSON ruling responses
• Low-confidence fallback for unknown content
• Vercel production deployment