01OBSERVABILITY
“The tool was called.”
Tracing systems can record the request, response and timing. Useful, but a trace alone does not explain which rule governed the action or whether a control was honoured.
event log ≠ verification evidence
OPEN SOURCE · APACHE-2.0 · LOCAL-FIRST
Verification infrastructure for AI systems and agents.
GroundLens turns observable AI execution into policy-governed, independently verifiable evidence.
Verify claims, tool calls, actions and outcomes. Record what happened, what was checked, which policy applied, and why a step was allowed, reviewed or denied.
Rust engine Python bindings MCP-ready Offline verification Signed records
01RUNinvoice-agentstart
02MODELresponse.generateok
03RETRIEVALinvoice.pdf#p1hash
04VERIFYnumeric + nlievidence
05TOOLinvoice.lookupALLOW
06ACTIONcustomer.notifyREVIEW
ExecutionEvidencePolicyDecisionRecord
THE GAP AI observability tells you what happened. It does not, by itself, prove that what happened was permitted or adequately verified.
THE LAYER GroundLens adds verification, policy and evidence without taking ownership of the model, agent or data plane.
THE OUTPUT A portable record a reviewer, operator or auditor can independently verify later.
Why GroundLens
The hard part is not another score. It is being able to show what was checked.
AI systems increasingly move from generating text to taking actions. A production verification layer therefore needs to handle both the content of an answer and the execution that produced it — with enough evidence to make the result reviewable.
02GUARDRAILS
“The action was blocked.”
A runtime gate can stop a step at the moment it happens. GroundLens is designed to keep the policy decision and its supporting evidence as a durable artefact as well.
control ≠ portable proof
03GROUNDLENS
“Here is what happened — and the proof.”
Every verification can identify the verifiers that ran, the evidence they produced, the policy that interpreted it, the resulting decision and the cryptographic record that binds it together.
verification = evidence + policy + provenance
Execution Runtime
One contract from the first token to the final side effect.
The unit is the execution: an ordered sequence of steps an AI system or agent takes. A single answer is simply the smallest execution — one run with one claim.
01Model callgeneration / reasoning
02Retrievalsources / context
03Tool requestarguments / identity / scope
04Tool resultreturned data / outcome
05Actionside effects / risk
06Human approvalreview / escalation
A
Observe beside the system
GroundLens sits next to the AI system rather than requiring access to model weights, prompts or internal architecture. The runtime works from the observable execution surface.
B
Verify before and after consequential steps
Claims can be checked with composable verifiers. Tool calls and actions can be evaluated by an ordered execution policy that returns ALLOW, REVIEW or DENY.
C
Keep the execution auditable
Each step can become an event in a hash-linked run log. After the run, GroundLens can audit the entire execution against the policy and record breaches in the signed result.
↳
Built for systems that already emit traces.MCP JSON-RPC messages can be ingested as an execution trace, with hashes recorded instead of raw tool arguments and results.
How It Works
A verifier produces evidence. A policy makes the decision.
GroundLens deliberately separates measurement from decision-making. The verifier says what it observed. The policy determines what that evidence means for the deployment.
01
Verify
Run one or more verifiers against a claim, source, tool call or execution event.
input → evidence
→
02
Interpret
A versioned policy interprets the evidence according to the risk rules of the deployment.
evidence → decision
→
03
Record
The evidence, policy, decision and provenance are sealed into a signed record.
decision → evidence record
Content checks claim and evidence results PASS REVIEW FAIL
Execution controls actions and tool permissions ALLOW REVIEW DENY
Verifiers
Compose checks instead of betting everything on one detector.
GroundLens gives different verification methods the same evidence contract. Exact checks can remain exact; statistical checks can declare their reproducibility class and calibration details.
01NUMERIC
Numbers, currencies, percentages and units.
Compare quantities exactly in base units, including locale-aware parsing and legitimate unit conversions.
EXACT02RULES
Your symbolic domain checks.
Encode deterministic constraints such as date ranges, field relationships or domain-specific invariants.
EXACT03LEXICAL
Evidence at the word and source-span level.
Anchor answer text against source material using a pinned multilingual encoder and retain the evidence that produced the finding.
REPRODUCIBLE04NLI
Entailment, contradiction and neutrality.
Check statements against a source with a cross-encoder when the deployment policy requires semantic verification.
REPRODUCIBLE +
The contract is extensible.
Semantic, geometric and LLM-judge verifiers can plug into the same verification model. Any non-deterministic component can be recorded with the model, prompt hash and settings that produced it.
Policy as Code
Your risk rules live in policy, not inside the verifier.
Two policies can interpret the same evidence differently. That is intentional: risk appetite, approval requirements and enforcement belong to the deployment policy and should be versioned independently from measurement.
See the example policies ↗execution-policy.yamlVERSIONED
id: eu_high_risk_v1
rules:
- id: no-shell
match: tool
name: shell.exec
effect: DENY
- id: human-for-high-risk
match: risk_at_least
risk: high
effect: REVIEW
default: ALLOWordered rules · first match winspure rule matching
Evidence Records
Trust is not a score. It is evidence with provenance.
The final artefact carries enough information to reconstruct what participated in the decision: inputs, verifier identities and hashes, evidence, policy and policy hash, decision, regulatory mapping and the previous record hash.
01Hash-linked
Each record carries the hash of the previous record in the log.
02Signed
Ed25519 seals the record so a verifier can detect changes later.
03Offline-verifiable
Verification can recompute hashes and signatures without reaching a network.
evidence-record.jsonSEALED
"record_id": "rec_350455f4…",
"engine_version": "…",
"inputs":
"answer_hash": "sha256:…",
"source_hash": "sha256:…"
,
"verifiers": [
"groundlens.numeric@…",
"groundlens.nli@…"
],
"policy": "eu_high_risk_v1",
"decision": "REVIEW",
"regulatory_mapping": […],
"previous_record_hash": "sha256:…",
"signature": "ed25519:…"
tamper-evident verify() · verify_chain()
Designed for Controlled Environments
Verification should not become another data dependency.
The runtime is deliberately local-first. Sensitive deployments can keep verification close to the system they are protecting, while the evidence artefact stays portable.
No model access required
GroundLens operates on observable execution. It does not need your weights, prompts or internal architecture.
Verification is offline
The engine and runtime have no HTTP/TLS dependency. Network access is explicit and isolated to the optional bundle pull operation.
Content can stay out of the log
Execution traces can record hashes of tool arguments and results instead of persisting the raw content in the evidence record.
Reproducibility is explicit
Exact checks are exact. Pinned statistical verifiers carry their model identity, hash and declared tolerance. Non-deterministic components can be recorded rather than hidden.
Fits Beside Your Stack
Keep your models, agents and observability stack. Add one verification layer.
LLMsRAGAgentsToolsMemoryHuman workflow
↓ observable execution ↓
GROUNDLENS
Observeevents / traces
Verifyclaims / actions
Policyrules / gates
Recordevidence / signatures
↓ portable evidence ↓
ReviewAuditComplianceIncident analysisIndependent verification
Where It Fits
From one answer to a full agent run.
The same evidence model can be used at different boundaries in the lifecycle of an AI system.
CONTENT
RAG and grounded answers
Verify claims against retrieved evidence, combine exact and semantic checks, and preserve the evidence behind the decision.
answer → claims → evidence → decision
EXECUTION
Agent tool calls and actions
Inspect the sequence of events and apply execution policy at the tool/action boundary.
trace → gate → action → record
ASSURANCE
Pre-deployment verification
Run representative executions through a controlled policy and produce an evidence package before a system reaches production.
dataset → verification → report
AUDIT
Independent review and replay
Hand over a signed record or JSONL chain and verify its integrity without depending on the original runtime.
record → verify → review
Engineering Surface
Small core. Explicit boundaries. Inspectable by design.
GroundLens keeps the verification engine independent from deployment infrastructure. The Rust workspace exposes the same core through the Python layer and the glv binary.
RUSTCore engine and runtime
Verification logic, execution events, policy evaluation and record sealing live in a portable core.
PYTHONDeveloper-facing API
Use GroundLens from Python without moving the verification contract into a cloud service.
CLIAutomation-friendly execution
Verify answers, inspect records, lint policies, pull bundles and verify chains from the command line.
MCPAgent execution boundary
Ingest MCP JSON-RPC traces and keep execution evidence tied to the same runtime model.
Open Source Foundation
Build AI systems that can show how they were verified.
GroundLens is the verification layer underneath a broader governance stack: observe the execution, verify the relevant facts and actions, interpret them with policy, and leave evidence that can survive outside the original runtime.