Null Lens™
Signed pre-execution governance artifact for AI systems.
Lens deterministically extracts stated user intent under a pinned version and returns a signed AIR before downstream execution.
Attestation, not enforcement.
See the artifact Lens returns before execution.
What Lens returns before execution.
Each request returns a structured Authorized Intent Record (AIR) and signed integrity block. Downstream systems can log it, verify it, compare it, or enforce against it. Lens itself remains attestation-only.
{
"air": {
"record_id": "air_36b4a07e-d239-46d3-8ce9-d285a83f71e4",
"timestamp": "2026-03-11T22:15:03.759Z",
"version": "v1.0",
"scope": "internal audit posture",
"boundary": "Strictly limited to the expressed scope. No additional domains inferred."
},
"integrity": {
"payload_hash": "sha256:020d8318a6840413403a54cfdfaf73a3f29eb00406d0ea9fbe5c0e79baa6cd4a",
"signature": "BASE64_SIGNATURE",
"public_key_id": "lens_2026_v1",
"algorithm": "ed25519"
}
}Structured AIR
A fixed pre-execution artifact containing canonical governance fields and record metadata.
Signed integrity
Every response includes a payload hash, signature, key identifier, and algorithm for independent verification.
Before execution
Lens defines and signs the record before retrieval, tool use, routing, or downstream agent execution.
Lens records the declared authorization claim. Customer systems decide policy, enforcement, and execution.
Next: why this control layer exists.
Most AI systems can log execution.
Few can prove declared authority before it happened.
Prompts, logs, traces, and model outputs can help explain what happened after execution. They do not create a signed pre-execution record of what the request was explicitly authorized to do. Lens fills that control gap.
- Authorization is reconstructed after execution.
- Prompts and logs are treated as evidence of intent.
- Scope is inferred from behavior, outputs, or outcomes.
- Security, legal, and engineering debate the record after the fact.
- No signed, versioned pre-execution artifact exists to verify against.
- Declared scope is recorded before downstream execution.
- AIR is returned in a fixed response contract.
- Integrity can be independently verified by customer systems.
- Security, legal, and engineering reference the same artifact.
- Downstream controls evaluate against a signed pre-execution record.
Lens does not explain intent after execution. It defines and attests to declared authority before execution begins.
Next: where Lens sits in the execution path.
Inserted before retrieval,
tool use, or agent execution.
Lens sits at the front of the execution path. It defines and signs the pre-execution governance artifact first. Your systems then decide how to verify it, compare it, route it, review it, and apply downstream policy or execution controls.
User Input
A natural-language request enters the system before any downstream retrieval, reasoning, or tool action occurs.
Null Lens
Lens deterministically extracts the user’s stated intent under a pinned version, returns a structured Authorized Intent Record, and signs the integrity block.
AIR + Integrity
Customer systems can verify the signature, persist the artifact, compare declared scope, and use it as a stable comparison point for downstream policy, routing, review, and audit logic.
Downstream System
Retrieval, tools, agents, workflow engines, or internal controls execute only after the pre-execution record exists.
What Lens does
- • Deterministically extracts stated intent under a pinned version
- • Produces the structured AIR object
- • Signs the returned integrity block
- • Provides a stable comparison point for downstream systems
What Lens does not do
- • It does not authorize downstream actions
- • It does not enforce policy or access control
- • It does not execute tools or business workflows
- • It does not replace customer governance systems
Lens is attestation, not enforcement.
It defines and signs the record. Your systems decide how to verify, route, review, or execute downstream.
Next: how customer systems verify the returned artifact.
Independently verifiable
by customer systems.
Every Lens response includes a signed integrity block. Customer systems can rebuild the canonical AIR payload, hash it, and verify the returned Ed25519 signature locally using the published Lens public key.
Payload hash
The canonical AIR 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: air.record_id,
timestamp: air.timestamp,
version: air.version,
scope: air.scope,
boundary: air.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 is what makes AIR an attestation artifact, 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 signed governance artifacts must be generated 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 AIR + integrity response shape designed for integration into production governance workflows.
What customers get
- • Signed AIR responses before execution
- • Deterministic extraction under a pinned version
- • Clear attestation vs. enforcement boundary
- • A stable comparison point for downstream systems
What Lens does not become
- • A shared consumer API
- • A downstream execution engine
- • A replacement for customer-side policy systems
- • A long-term customer content store
Lens is designed to establish the signed governance artifact first, then leave downstream authorization and execution decisions with customer systems.
Private deployment, signed integrity, and stateless handling are part of the operating model — not optional add-ons.
Next: request enterprise deployment.
Deploy Lens before downstream execution
carries risk.
Add a signed pre-execution governance artifact layer to your AI stack with deterministic extraction under a pinned version, structured AIR responses, Ed25519 integrity, and private isolated deployment.
Structured AIR
Fixed response contract with canonical governance fields and record metadata.
Signed integrity
Independently verifiable payload hash, signature, key identifier, and algorithm.
Private deployment
Dedicated runtime boundaries, org-scoped access, and stateless handling by design.
Lens is attestation, not enforcement. It defines and signs the pre-execution artifact; customer systems retain control over policy, execution, and audit workflows.
AIR + integrity · private isolated deployment · fixed v1.0 contract
Return to top