Warp: An Evidence Graph for Procurement Incidents

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

I built Warp, an AI-assisted procurement incident-response workspace for teams that need to choose a replacement supplier under time pressure.

A supplier failure creates a difficult problem. Procurement needs an alternative quickly. Operations needs to protect production. Quality needs to check certificates and specifications. Legal needs a defensible record before a new agreement is prepared. In many companies, these facts live in separate PDFs, supplier websites, inboxes, spreadsheets, and browser tabs.

Warp brings that investigation into one workflow. It takes an incident, researches alternative suppliers, extracts facts from documents, compares claims against evidence, ranks the options, and prepares a recommendation. It then stops. A person must approve, reject, or request more evidence before the workflow can continue.

The product rule is simple:

AI prepares. Humans authorize.

The demo scenario

The demo starts with an incident involving Pacific Components Ltd. The company supplies the PX-17 Power Controller. Only eight days of inventory remain. The estimated business exposure is $2.4 million.

Warp evaluates three alternative suppliers:

• Apex Electronics has a credible certification record, but a longer lead time.
• Nexus Manufacturing has a clean business-registration record, direct PX-17 compatibility, and expedited shipping evidence.
• Shenzhen Rapid Parts offers the lowest price, but two critical claims fail verification.

Shenzhen claims it was established in 2018. Its business-registration evidence shows a formation date in 2021. It also provides an ISO 9001 certificate, but the certificate registry does not return a matching record.

Warp does not hide these failures inside a black-box risk score. It keeps the supplier claim, the contradicting registration field, the certificate result, the document source, and the final verdict connected and visible.

Why Sanity is central to Warp

Sanity is Warp’s durable supplier evidence graph.

A normal database model could store a supplier score and a short explanation. That would not be enough for this problem. Procurement teams need to inspect the path from a recommendation back to its evidence.

Warp uses Sanity to model the investigation as connected documents:

• evidenceIncident stores the disruption context.
• evidenceSupplier stores each candidate supplier.
• evidenceClaim stores material supplier statements, such as “ISO 9001 Certified” or “Established 2018.”
• evidenceDocument stores the document that supports or challenges a claim.
• evidenceSource stores external evidence, including registries and web research.
• evidenceDecision stores the recommendation, risk rationale, and human decision.

The relationship is deliberate:

incident → supplier → claim → document or source → extracted field → verification result → decision → human approval

This means a conflict is not an error that gets overwritten. It is a first-class part of the graph.

For example, the claim “Established 2018” and the business-registration field “FORMED 2021-06-08” can both exist in Sanity. Warp links them to the same supplier and shows the result as a conflict. The human reviewer can see what was claimed, what was found, and why the recommendation changed.

The Evidence screen reads this graph through GROQ. It presents verified claims, conflicts, unverified claims, documents, external sources, and the recommended supplier in a custom Next.js interface.

Demo

Live app: aegisflow-ai.vercel.app

The video walkthrough shows the complete decision path:

1. The procurement incident and business impact.
2. The supplier investigation and recommendation.
3. The Sanity evidence graph.
4. Claim-level provenance and conflicting evidence.
5. Document extraction and source records.
6. The human approval state.
7. The integration activity ledger.
8. The append-only audit trail.

Code

Public repository: github.com/kris70lesgo/Warp

The repository includes the Next.js application, the Sanity Studio, Sanity schemas, the evidence-graph queries, integration clients, and scripts for seeding the baseline graph.

My Build Process

I used Codex as my AI-native development environment. I built Warp with Next.js for the application and Sanity for the structured evidence layer.

The project started from a product question:

What should an AI procurement tool do when evidence is incomplete or contradictory?

My answer became the main product constraint: the AI can research, extract, compare, score, and draft. It cannot silently turn an uncertain conclusion into an approved business action.

The prompt that changed the architecture was:

“Make Sanity the supplier evidence graph. The app investigates suppliers from multiple sources. Sanity must hold the complete evidence state for every supplier, including claims, documents, sources, conflicts, and final decisions.”

At first, the model treated Sanity as a place to save a supplier summary. That produced the wrong application. A summary tells a user what the system concluded, but it loses the path that produced the conclusion.

I corrected the model in three ways.

First, I required separate records for each supplier claim and each piece of supporting or contradicting evidence. A supplier record could no longer hold only a final score.

Second, I required provenance. Every material fact needs to link back to a document field, external source, or explicit fallback. The UI must show whether an input is LIVE, LOCAL, or DEMO SEEDED.

Third, I separated an AI recommendation from a human decision. The recommendation can be stored and explained, but it cannot advance the workflow by itself.

These constraints led to the evidence graph. They also made the app more useful. Instead of asking users to trust a score, Warp lets them inspect the score’s inputs.

Prompts that worked

The strongest prompts described a rule, an actor, and a proof requirement. For example:

“Do not overwrite contradictory claims. Preserve the supplier statement and the evidence that challenges it. Make the conflict queryable and visible in the UI.”

“Show the provenance for every material claim. A human reviewer must be able to trace a recommendation back to a document field or source.”

“Treat a zero-result web search as evidence of missing corroboration, not as an empty result.”

“AI may prepare a decision. Only a human may approve, reject, or send an agreement to signature.”

These prompts produced better results than broad requests such as “build a procurement dashboard with Sanity.” Broad prompts produced generic cards and charts. The tighter prompts produced a workflow with rules, evidence links, and clear responsibility boundaries.

Where the model got stuck

The hardest part was keeping the system honest when an integration was not available.

A model will often fill a UI with plausible output, even when a live API did not respond. That would be dangerous in a supplier-verification workflow.

I added an Integration Activity Ledger to fix this. Every provider call is recorded with its mode:

• LIVE means the provider responded.
• LOCAL means Warp used a local implementation or extracted fixture.
• DEMO SEEDED means Warp used a known demo record and shows that fact.

This rule applies to the visible product. The app does not label a fallback as a live result.

I also kept Sanity distinct from the operational database. Sanity holds the durable, connected evidence graph. Xano holds operational incident records and the append-only event stream. This separation keeps the explanation layer and the workflow ledger clear.

The workflow

A Warp response follows these stages:

1. Analyse the incident and business exposure.
2. Search for supplier and market evidence.
3. Extract relevant fields from supplier documents.
4. Check claims against source evidence.
5. Score alternatives with transparent risk dimensions.
6. Persist the investigation as connected Sanity evidence records.
7. Prepare a recommendation.
8. Require human review.
9. Prepare documents only after approval.
10. Record every important action in the audit trail.

The important design choice is step six. The recommendation is not the only output of the investigation. The evidence graph is also an output. It lets the system answer future questions without rebuilding the investigation from scratch.

What I did not use

I did not use Sanity App SDK or Sanity Workflows in this version. I built a custom Next.js interface and a dedicated Sanity Studio for the evidence model. I wanted the challenge entry to focus on one idea executed deeply: structured supplier evidence that stays connected through an investigation.

Sanity Project Details

• Sanity project ID: af8ykvwc
• Dataset: production
• Frontend query language: GROQ
• Sanity Studio: included in the repository under /sanity

Sanity is the durable record of a Warp investigation.

One investigation can persist the incident context, candidate suppliers, supplier claims, documents, extracted fields, web and registry sources, verification results, conflicts, recommendation, and human decision.

The schema preserves disagreement. If a supplier statement conflicts with a registration record or certificate check, Warp keeps both records. It marks the claim as VERIFIED, CONFLICT, or UNVERIFIED, but it does not erase the source material.

That is the reason Sanity is central to the product. It changes the system from an AI tool that produces an answer into a decision workspace that preserves the evidence behind the answer.

Agent Session

I am not embedding the raw agent session because it contained development credentials during integration testing. Any public agent session should be reviewed and scrubbed before publishing.

Warp uses Sanity to make supplier decisions structured, queryable, and reviewable.

AI prepares. Humans authorize.