The Local Eye (Sovereign Vision)

We’ve built a system that is Reliable, Affordable, and Governed. But until now, our Forensic Team has been “blind.” It could only reconcile text-based metadata.

In the world of rare book forensics, the text is only half the story. The typography, paper grain, and binding texture are the true “fingerprints.” However, sending high-resolution, proprietary scans of a $50,000 asset to a cloud-based LLM is a Data Sovereignty nightmare.

Today, we introduce The Local Eye: Edge-based Multimodal Vision that processes pixels without letting them leak into the cloud.

The Sovereignty Gap in Multimodal AI

Most multimodal implementations send raw images directly to frontier models (like GPT-4o). For an enterprise, this is a liability.

  1. Intellectual Property: Who owns the training data rights to the scan?
  2. Privacy: Does the image contain metadata or background information that violates NDAs?
  3. Cost: Sending 10MB 4K images for every query is an “Accountant’s” nightmare.

Implementing “Feature Extraction” at the Edge

Instead of sending the image to the cloud, we use Llama 3.2 Vision running locally via Ollama. Our MCP server acts as an “Airlock.”

The Handshake:
Normalization: The sharp library resizes and standardizes the forensic scan locally.
Local Inference: The Vision SLM analyzes the image and generates a text-based “Feature Map.”
Metadata Egress: Only the textual description is passed to the reasoning agents. Even if The Accountant routes the task to a Cloud model for deep analysis, the cloud only sees our description, never the pixels.

Architectural diagram of the 'Local Eye' workflow. An artifact image is processed locally using the Sharp library and Llama 3.2 Vision. Only the resulting text metadata is allowed to pass through the security airlock to cloud-based reasoning models, ensuring the original pixels never leave the local environment.
The Sovereign Vision Workflow—Extracting intelligence at the edge to prevent data leakage.

The Sovereign Vision Workflow—Extracting intelligence at the edge to prevent data leakage.
Architectural diagram of the 'Local Eye' workflow. An artifact image is processed locally using the Sharp library and Llama 3.2 Vision. Only the resulting text metadata is allowed to pass through the security airlock to cloud-based reasoning models, ensuring the original pixels never leave the local environment.

In code we might have something like this then:

// From src/index.ts: The Vision Airlock
async function analyzeArtifactVision(imagePath: string, focus: string) {
  const processedImage = await sharp(imagePath).resize(512, 512).toBuffer();

  // Local-only call to Ollama
  const description = await ollama.generate({
    model: 'llama3.2-vision',
    prompt: `Analyze the ${focus} of this artifact.`,
    images: [processedImage.toString('base64')]
  });

  return description; // Pixels stay here. Only text leaves.
}

The “Zero-Pixel” Policy

The goal is to maximize Intelligence while minimizing Exposure. By implementing Local Vision, we treat the cloud as a “Reasoning Utility,” not a “Data Store.” We send it the logic puzzle, but we never give it the raw forensic evidence. We gain the power of frontier-model reasoning without the risk of data harvesting.

Developer Lessons: The “Latency of Locality”

In building the Sovereign Vault, we learned that ‘Data Sovereignty’ has a physical cost: Time.

While a cloud-based API might analyze a 4K image in seconds, running a deep-dive OCR and visual analysis on local consumer hardware using Llama 3.2-Vision takes significantly longer. We had to tune our “Airlock” timeouts—raising the ceiling from 120 seconds to 300 seconds—to give the local “Eye” enough time to process complex handwriting on a standard CPU.

Additionally, we realized that our error logs were a potential privacy leak. We implemented Log Truncation to ensure that even our failures respect the Sovereign Vault’s privacy mandate.

The “Zero-Glue” Discovery

In a traditional setup, adding vision would require rewriting the orchestrator’s core logic. Because we use the Model Context Protocol, the orchestrator simply asked the server: “What can you do?”. The server replied with the analyze_artifact_vision manifest. The agent then dynamically decided to use this new “Eye” to investigate the Gatsby image. No new glue code was written to connect the vision model to the reasoning brain.

Case Study: The Gatsby Inscription

To test our Sovereign Vault, we ran a forensic audit on a high-value first edition of The Great Gatsby. Our local Vision Agent detected something anomalous on the title page: a cursive, multi-line inscription.

An image of The Great Gatsby copyright page
Image credit: [University of Southern Mississippi Special Collections](https://lib.usm.edu/spcol/exhibitions/item_of_the_month/iotm_june_2021.html) (June 2021 Item of the Month)

The Sovereign Trace

When we ran the analyze_artifact_vision tool, the local Llama 3.2 Vision model performed a deep scan and returned a fascinating finding:

**Visual Findings: Handwritten Inscription**
* Location: Right-hand margin of title page
* Medium: Faint pencil, cursive script
* Transcribed Content: "Then we are not alone at all when we remember that we have in our hearts that something so precious..."

Why this matters: Notice that the model didn’t just see “scribbles.” It attempted to transcribe a 40-word passage. Crucially, the Forensic Analyst (Claude) recognized that this text does not exist in any canonical version of The Great Gatsby.

This is a massive forensic win. The “Eye” identified a potential fabricated provenance or a non-standard owner intervention. Because this happened inside our “Airlock,” the specific handwriting and the non-canonical text were captured without ever touching a cloud API.

The Architect’s Trade-off: The Reasoning Gap
While our local Llama 3.2-Vision is an incredible “Eye,” it occasionally faces a Reasoning Gap. In certain runs, it may identify a note as “illegible” or produce repetitive output due to CPU thermal throttling or model constraints.

Instead of hallucinating a “clean” signature, our system is designed to Safe-Fail. It flags the finding as “Indeterminate” and triggers a High-Severity Human Authorization request.

The Governance Challenge: We now have a transcribed inscription that might contain a previous owner’s private thoughts or names. If we simply passed this output to an LLM for summarization, we would have leaked a private message to a third-party server. This discovery sets the stage for our next architectural layer: The Redactor.

Facebooktwitterredditlinkedinmail

The Guardian: Human-in-the-Loop AI Governance

The Guardian: Human-in-the-Loop AI Governance

We’ve built a system that is Reliable and Affordable. Our Forensic Team is accurate, and The Accountant ensures we aren’t wasting our cognitive budget.

But in the enterprise, “capable” is not enough. For high-stakes decisions—like a $50k rare book audit or a compliance check—fully autonomous AI is a Liability.

Today, we introduce The Guardian: The final phase of our Production-Grade AI trilogy. We are implementing a standardized Human-in-the-Loop (HITL) checkpoint, moving from “Autonomous Agents” to “Augmented Intelligence.”

1. The Autonomous Trap: Confident Hallucination

In the first post of this series, The Judge proved that even the best models can confidently hallucinate. In a forensic audit, an agent might identify a water damage pattern and declare: “CRITICAL: High probability of modern forgery.” If that finding is wrong, the reputational and financial damage is severe. The problem isn’t the AI’s capability; it’s the lack of authorization. The agent is a worker, not a partner.

2. Implementing the “Governance Gate”

We need a way to “brake” the agent’s flow when it finds a high-severity issue. We’ve added the request_human_signature tool to our Forensic Analyzer MCP server project.

In orchestrator.py, we updated the logic. When the Analyst flags a “HIGH” severity discrepancy, the system performs a specialized handshake:

  1. Stateful Pause: The Python orchestrator interrupts the agent workflow.
  2. Authorization Prompt: It presents the evidence to the user via a CLI prompt.
  3. Cryptographic Signature: The user must authorize the finding before it’s committed to the final report.
# The Guardian's "Nuclear Key" moment in orchestrator.py
def _apply_guardian_handshake(analyst_result: dict) -> tuple[dict, list[dict]]:
    """
    Human-in-the-Loop: if Analyst has HIGH discrepancies, prompt for authorization.
    """
    disputed: list[dict] = []
    data = analyst_result.get("data") or {}
    disc = data.get("discrepancies", [])

    # Filter for the "High Stakes" findings
    high_disc = [d for d in disc if (d.get("severity") or "").upper() == "HIGH"]

    for d in high_disc:
        summary = f"[{d.get('severity')}] {d.get('field')}: {d.get('expected')} vs {d.get('observed')}"
        print(f"\n  Guardian: HIGH severity finding — {summary}")

        # THE STATEFUL PAUSE: The orchestrator stops and waits for a human
        answer = input("  Do you authorize this forensic finding? (yes/no): ").strip().lower()

        if answer != "yes":
            # Escalation: If not authorized, it's flagged as 'DISPUTED_BY_HUMAN'
            disputed.append({**d, "status": "DISPUTED_BY_HUMAN"})

    return analyst_result, disputed

By requiring a human to type ‘yes’, we are moving from Autonomous Assumption to Authorized Augmentation in the following ways:

  1. Severity-Based Intervention: “We don’t interrupt the user for every ‘Low’ or ‘Medium’ variance. We only trigger the Guardian for High-Severity findings—those that carry legal or financial liability. This preserves the ‘UX flow’ while maintaining safety.”
  2. The ‘Disputed’ State: “Notice that a ‘No’ from the human doesn’t just delete the finding. It moves it to a specialized ‘Requires Further Investigation’ section of the report. This ensures that the AI’s observation is preserved but clearly labeled as unauthorized.”
  3. Non-Interactive Fallback: “The code includes a check for EOFError (line 507). If the system is running in a non-interactive environment like a CI/CD pipeline, it defaults to ‘No’ (Dispute) for safety. Never default to ‘Yes’ for a high-risk authorization.”
Architectural diagram of a human-in-the-loop AI governance system called The Guardian. An agent workflow processes a task. When it detects a high-severity finding, it pauses and performs a stateful 'Authorization Handshake' with a Human Guardian. The human must sign or reject the finding before it proceeds to finalize the output report.
The Guardian Architecture—Moving from Autonomous Agents to Stateful, Authorized Human-AI Augmentation.

3. Beyond the CLI: The Enterprise Handshake

This reference implementation uses a CLI input() prompt for simplicity. However, the MCP tool is standardized. In a production environment, this tool wouldn’t pause a Python script; it would:

  • Trigger a Slack/Teams Alert to a senior auditor.
  • Open a Jira Ticket for manual review.
  • Request a Webauthn (Biometric) Signature in a web dashboard.

Summary: Building the Sovereign AI Stack

Across this series, we’ve moved from basic orchestration to a Production-Grade AI Mesh. We’ve proven that we can build systems that are:
1. Reliable: Audited by The Judge.
2. Sustainable: Optimized by The Accountant.
3. Safe: Governed by The Guardian.

The road to autonomous agents isn’t paved with more tokens; it’s paved with better guardrails.

What’s Next?

The code for the entire trilogy is available in the MCP Forensic Analyzer repository.

I’m currently working on Phase 3: The Sovereign Vault, where we will explore Local Multimodal Vision (processing artifact images without cloud egress) and PII Redaction to protect proprietary “Golden Data.”

Have questions about implementing these patterns in your own enterprise? Connect with me on LinkedIn or follow the blog for the next series.

The Production-Grade AI Series (Complete)

Looking for the foundation? Check out my previous series: The Zero-Glue AI Mesh with MCP.

Facebooktwitterredditlinkedinmail