I Built WazehTerms: When Your Job Offer Promised One Thing, And Your Contract Says Another, It Shows the Evidence.

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

What I Built

WazehTerms is an evidence-first employment-document review assistant for people in Pakistan considering private-sector employment in the UAE.

It helps a worker understand what their job offer and employment contract actually say before signing.

The system:

• extracts important employment terms with page-level evidence;
• lets the user review and correct extracted values;
• compares offer and contract terms deterministically;
• retrieves potentially relevant official sources through Sanity Context;
• verifies retrieved evidence against structured Sanity rules before raising a source-backed concern;
• separates confirmed mismatches, missing information, questions, and uncertainty instead of producing a generic “safe/legal” verdict.

The key idea is simple:

AI should not make a legal-sounding claim just because it found a relevant sentence. It should first prove that the source, rule, scope, actor, date, and document evidence actually line up.

The public demo uses fictional English PDFs only. No real employment documents should be uploaded.

Demo

Live application: https://wazehterms-957765366699.asia-south1.run.app

No login is required. Start with the fictional sample cases.

The main journey is:

Choose a sample → Extract terms → Verify evidence → Compare documents → Review findings

Code

GitHub: https://github.com/abubakar-ahmed-dev/wazeh-terms

The application uses React/Vite + TypeScript on the frontend and an Express/TypeScript API deployed to Google Cloud Run.

How I Used Sanity

This is where Sanity becomes more than a content store.

I modeled the reference layer as structured records including:

• authority
• sourceDocument
• rule
• contractFieldDefinition

The current release contains 44 approved published records: 2 authorities, 6 source versions, 3 rules, and 33 contract-field definitions.

A rule can carry its responsible actor, jurisdiction, worker category, effective period, conditions, source version, and exact official pinpoint.

The runtime flow is:

Document
   ↓
Gemini extraction + evidence
   ↓
Deterministic comparison
   ↓
Sanity Context MCP retrieval
   ↓
Canonical Sanity rule verification
   ↓
Evidence-backed finding

Sanity Context is used for candidate discovery. A retrieved passage does not automatically become a finding.

The application reconciles it with the canonical Sanity record and checks whether the rule actually applies before showing a source-backed concern.

This matters in cases such as recruitment charges. A keyword search might find an official source mentioning recruitment fees, but WazehTerms also needs to establish the relevant jurisdiction, actor, worker category, dates, and exact source support.

If that chain cannot be established, the system withholds or qualifies the claim.

That is the part of WazehTerms that would be difficult to reproduce with a simple search box.

Sanity Project Details

Project ID: 8g0kllu0

Dataset: production

Knowledge Base: kbynAP4r8P6m

Sanity Studio contains the curated structured reference records used by the application, while the Knowledge Base provides the retrieval layer used through Sanity Context MCP.

Worker documents and extracted reports are not stored in Sanity.

What I Learned

The biggest lesson from building WazehTerms was:

“AI with citations” is not necessarily grounded decision-making.

A citation can make an unsupported conclusion look trustworthy.

So I designed the system around a stricter rule:

retrieve → verify → check applicability → inspect evidence → then speak.

And when the evidence chain breaks:

“I don't know yet” is a valid result.

That is what I wanted Sanity's structured content to make possible.