Hallucination Detection
in/guard/out vs Lens
Lens is an answer engine for teams whose answers get reviewed. It searches your documents and an index of over a billion passages, collapses copies and syndication so one source counts once, counts each distinct source as support, dispute or silence, and checks the finished answer claim by claim – every citation opening to its passage. Counting the sources that disagree, not just the ones that agree, is a genuinely good idea, and enterprise search with permissions that carry through is Lens’s lane.
in/guard/out starts from the other end. It doesn’t build the answer – it checks the ones your apps already produce, with whatever retrieval they already have, on the wire between them and the model. And it covers what an answer engine doesn’t: the JSON that has to parse, the customer data that shouldn’t reach the provider, and the agents that act on an answer once they have it.
Side by side
| Capability | Lens | in/guard/out |
|---|---|---|
| What it is | An answer engine – search, retrieval and checked answers through its own surfaces | A guardrails proxy on the traffic your apps and agents already send |
| Where the evidence comes from | Its own retrieval: your documents, the Lens index, the web | The sources in the request – your RAG context, documents, tool results – plus optional RAG and web search |
| Wrong numbers in an answer | Claims checked against the sources | Deterministic grounding: arithmetic recomputed and altered figures corrected from the source, with no model call |
| When a claim fails | Marked in the answer | Repaired where safe, blocked or flagged – PREVENT or FIX per key, user or request |
| Structured output | — | JSON-schema validation with automatic repair |
| Private data | Documents and queries kept out of training; existing permissions respected | Screened to placeholders before the provider sees it, restored in the response, and tracked so it can’t leave through a tool argument |
| Unsafe content and injection | — | Profanity filter and dedicated safety classifiers; tool results injection-scanned before they reach the model |
| Agents | Agents built inside Strata, with a fixed set of tools and actions checked against sources | The agents you already run – n8n, LangChain, MCP, your own code: tool policy, permission tiers, grounded payments, taint |
| Agent spend | — | Hard per-run caps: each request reserves its worst-case cost before it is sent |
| What the checks cost you | — | Per-stage latency and every guard-model call priced into the request |
Based on Lens’s publicly available information. We’ve done our best to keep it accurate, but details may have changed since we last looked. If you’ve noticed an error, please email us.
Building the right answer vs checking the one you got
An answer engine is right by construction when the question fits its retrieval: it chose the sources, so it can count them. Most production LLM traffic doesn’t look like that. It is a support bot answering from a ticket, an extraction job filling a schema from a contract, a report rewritten for a new quarter, an agent deciding what to pay – each with its own context assembled by the app. That traffic needs checking where it already flows, against the sources it was actually given, and the commonest failure in it – a figure that drifted from the source, a total that doesn’t add up – is one a deterministic check catches exactly, for free, and can correct rather than mark.
The two compose. Lens offers an MCP server, so an agent can use it as a research tool; route that agent through in/guard/out and Lens’s passages arrive as tool results – injection-scanned on the way in, and counted as evidence when action grounding checks a payment’s payee or amount against what the run read.
Frequently asked questions
Is in/guard/out a Lens alternative?
Only where the jobs overlap. If you want a research and enterprise-search product that tells you how many distinct sources back or dispute each claim, that is Lens. If you want the answers and agent actions your own apps produce checked, repaired and audited – with any provider, behind a base-URL change – that is in/guard/out.
Both put a gateway in front of the model – what’s different?
What the gateway checks the answer against. Lens checks against its own retrieval. in/guard/out checks against the sources your app sent with the request – the ticket, the contract, the tool results – then validates the format, screens and restores PII, enforces safety, and governs tool calls. Its first grounding tier needs no model call at all.
Lens has grounded actions too – how is that different?
Lens checks the actions of agents built inside Strata, with the tools it gives them. in/guard/out governs agents wherever they already run – an n8n workflow, a LangChain app, an MCP client – across the whole run: schema-checked tool calls, permission tiers, payees grounded in sources, screened values blocked from leaving, loops stopped and budgets reserved before the next call spends.
Can I use Lens and in/guard/out together?
Yes. Give your agent Lens as an MCP research tool and point the agent through in/guard/out. Lens supplies sourced passages; in/guard/out scans them as untrusted tool results and uses them as evidence for the actions the agent takes next.
See it on your traffic first.
FIX mode observes without blocking, so you can measure what in/guard/out catches before enforcing anything. We are running a limited demo - sign up and we will get you in as soon as we can.