Diamond Evidence Gate

• 

Inspiration

AI is increasingly used to recommend what people should do next: adopt an API, change a production dependency, respond to a policy update, or approve an operational move.

The problem is that the recommendation can be confident while its knowledge is already stale.

Diamond Evidence Gate starts from a different rule: before AI recommends a consequential move, it must first obtain live evidence. The final decision must also remain visibly Human-controlled.

What it does

A Human enters:

1. a decision question; and
2. a proposed action.

Diamond Evidence Gate then:

• retrieves structured, real-time web results through SerpApi;
• normalizes the evidence and checks source diversity and freshness;
• asks a local AI model to produce a grounded decision brief using the numbered evidence;
• classifies the packet as READY_FOR_HUMAN or REVIEW_REQUIRED;
• presents an explicit Human Gate with Approve, Hold, or Reject;
• produces a hash-bound decision receipt tied to the evidence packet.

Approval records a Human decision only. The application does not automatically execute the proposed action.

How we built it

The application uses a small local-first architecture:

• SerpApi Google Search API for structured live web evidence;
• Python standard-library HTTP server;
• Ollama + qwen3:1.7b for local grounded synthesis;
• deterministic evidence normalization and quality flags;
• a visible Human Gate;
• hash-bound decision receipts;
• process-scoped API secrets and bounded local port handling on Windows.

The live-search and grounded-local-AI technical spine was validated end-to-end before the decision-control layer was added.

Challenges we ran into

The hardest part was not simply calling a search API.

We had to make three systems behave predictably together: live external search, a local AI runtime, and a Human-controlled authority boundary.

During development we handled:

• local Ollama model-store mismatches;
• stale local services and port collisions;
• Windows PowerShell execution-policy constraints;
• keeping API credentials out of proof artifacts;
• aligning machine acceptance tests with the exact browser-visible path;
• failing closed when evidence or AI synthesis is not good enough.

Those failures directly shaped the final architecture.

Accomplishments that we're proud of

Diamond Evidence Gate turns live search into a decision-control primitive rather than a search box.

The current design separates four things that are often collapsed together:

live evidence → grounded AI recommendation → explicit Human decision → auditable receipt

SerpApi is central to that flow. Without live SerpApi evidence, the packet cannot reach the final Human Gate path.

The system also preserves a strict authority boundary: AI may retrieve, analyze, and recommend, but it cannot silently make the final decision for the Human.

What we learned

The most useful boundary is not simply “AI versus Human.”

A stronger workflow is:

live evidence first, bounded AI reasoning second, explicit Human authority third, proof last.

We also learned that reliability includes operational details: local model identity, evidence diversity, secret handling, browser/runtime consistency, and visible fail-closed states.

What's next for Diamond Evidence Gate

Next we would add domain-specific evidence policies for areas such as software dependency changes, API migrations, compliance updates, and operational approvals.

We would also add optional connectors that can prepare reversible downstream actions after Human approval while preserving the same evidence, receipt, and authority boundary.

Built With

• css
• google-search-api
• grounded-ai
• html
• human-in-the-loop-ai
• javascript
• local-ai
• ollama
• python
• qwen3
• serpapi