Null Lens™
Know what was asked before your AI system acts.
Null Lens records and signs requested scope before an AI system runs, so teams can compare what was asked with what happened.
Call the Lens API before agents use tools, retrieve data, or enter business workflows.
See the signed record Lens returns before execution.
From request to signed scope.
Send the user request to the Lens API before tools, retrieval, or workflows. Lens extracts scope and returns it as a signed record.
Scope means the concrete resource, task, event, or requirement contained in the request — the part downstream systems can later compare against.
User request
Our team needs to access internal documents for project brief generation. Legal requires every access event to include a logged intent record before retrieval happens.
Lens output
[Scope]: internal documents; project brief generation; access event; logged intent record
Lens signs this scope with record metadata and an integrity block.
If the agent later retrieves unrelated documents, generates a different artifact, or skips the logging step, teams have a signed scope record to compare against.
Scope extraction
Extracts the concrete resources, tasks, events, and requirements from the request.
Signed integrity
Every response includes a payload hash, signature, key identifier, and algorithm for independent verification.
Before execution
Creates the scope record before retrieval, tool use, routing, or downstream agent execution.
Lens creates the record first. Customer systems decide what happens next.
Next: why this record matters.
Logs show what happened.
Lens shows what was in scope first.
Prompts, logs, traces, and model outputs can help explain what happened after execution. They do not prove which resource, task, event, or requirement was in scope before the agent ran.
- Teams reconstruct the agent's intent after execution.
- Prompts and logs become the only evidence of what was asked.
- Scope is inferred from behavior, outputs, or outcomes after the fact.
- Security, legal, and engineering debate what was actually in scope.
- No signed pre-execution record exists to compare against.
- Requested resources, tasks, events, and requirements are recorded before downstream execution.
- A signed record is returned in a fixed response contract.
- Integrity can be independently verified by customer systems.
- Security, legal, and engineering reference the same pre-execution record.
- Downstream systems can compare what happened against the signed record.
Lens gives teams a fixed reference point before execution, instead of forcing them to reconstruct the agent's intent later.
Next: where Lens sits in the execution path.
A reference point before
downstream work begins.
Lens is designed to sit before downstream work begins. It creates the signed scope record first, then your systems can verify it, store it, compare what happened against it, or use it in downstream workflows.
User Input
A natural-language request enters the system with resources, tasks, events, or requirements that need to be made explicit before downstream work begins.
Null Lens
Your system calls the Lens API. Lens captures the requested resources, tasks, events, and requirements under a pinned version, then returns a signed pre-execution record.
Record + Integrity
Customer systems can verify the signature, store the record, compare what happened against the stated scope, and use it as a stable reference point for policy, routing, review, and audit logic.
Downstream System
Retrieval, tools, agents, workflow engines, or internal controls can use the record as a reference point before downstream work continues.
What Lens does
- • Captures requested resources, tasks, events, and requirements
- • Produces a signed pre-execution record
- • Signs the returned integrity block
- • Provides a stable reference point for downstream systems
Product boundary
- • Does not grant downstream permission
- • Does not execute tools or business workflows
- • Does not replace customer-side policy systems
Lens creates the record. Your systems decide how to use it.
Next: common integration patterns.
Use the record where
scope needs to be provable.
Lens is intentionally small: it creates the signed scope record. Customer systems decide how that record is used for logging, comparison, review, routing, policy, controls, or audit workflows.
Log-only
Store the signed record alongside execution logs so audit teams can see what was in scope before the system ran.
Compare-only
Compare outputs, tool calls, or workflow steps against the signed scope record after the system runs.
Review-trigger
Route mismatches, expanded scope, or sensitive downstream actions to human review.
Customer-owned control
Use the signed record inside your own policy engine, workflow gate, or approval layer.
Start with visibility. Add comparison, review, or customer-owned controls where your system needs them.
Next: how customer systems verify the returned record.
Independently verifiable
by customer systems.
Every Lens response includes a signed integrity block. Customer systems can rebuild the canonical record payload, hash it, and verify the returned Ed25519 signature locally using the published Lens public key.
Payload hash
The canonical record payload is hashed before signature verification.
Ed25519 signature
Each response includes a signature, key identifier, and algorithm.
Local verification
Verification happens in your environment. No response needs to be sent back to Null for confirmation.
{
"payload_hash": "sha256:020d8318a6840413403a54cfdfaf73a3f29eb00406d0ea9fbe5c0e79baa6cd4a",
"signature": "BASE64_SIGNATURE",
"public_key_id": "lens_2026_v1",
"algorithm": "ed25519"
}const canonical = JSON.stringify({
record_id: record.record_id,
timestamp: record.timestamp,
version: record.version,
scope: record.scope,
boundary: record.boundary,
})
const hash = crypto.createHash("sha256")
.update(canonical)
.digest()
const valid = nacl.sign.detached.verify(
hash,
sig,
pubKey
)
console.log("Signature valid:", valid)Signed structure makes the record independently verifiable, not just formatted output.
Lens returns the signed record. Customers choose how to operationalize verification.
Next: deployment model and isolation boundary.
Private isolated deployment
for audit-sensitive environments.
Lens is provisioned through private customer deployments with dedicated runtime boundaries, organization-scoped credentials, and stateless request handling. It is built for environments where teams need a signed record of scope before downstream execution begins.
Dedicated runtime boundary
Lens is provisioned for private customer deployments rather than positioned as a shared public inference product.
Org-scoped access
Access is controlled through organization-scoped credentials and non-discoverable customer endpoints.
Stateless by design
Customer content is processed ephemerally and is not retained as application memory across requests.
Fixed v1.0 contract
Lens returns a stable record + integrity response shape designed for production workflows that need verifiable scope evidence.
What customers get
- • Signed pre-execution records before execution
- • Requested scope captured under a pinned version
- • Clear product boundary
- • A stable reference point for downstream systems
Product boundary
- • Not a shared consumer API
- • Not a downstream execution engine
- • Not a replacement for customer-side policy systems
- • Not a long-term customer content store
Lens establishes the signed scope record first. Customer systems handle downstream decisions and execution.
Private deployment, signed integrity, and stateless handling are part of the operating model — not optional add-ons.
Next: request enterprise deployment.
Put the scope record
before the agent.
Add a signed scope record layer to your AI stack with pinned-version scope capture, local signature verification, and private isolated deployment.
Signed record
Fixed response contract with stated scope, boundary, version, and record metadata.
Local verification
Verify the payload hash and Ed25519 signature inside your own environment.
Private deployment
Dedicated runtime boundaries, org-scoped access, and stateless handling by design.
Lens records and signs scope before execution; customer systems retain control over policy, controls, execution, and audit workflows.
Return to top