Null logo
Null

Null Lens — Enterprise API Docs

Null Lens is a signed pre-execution governance artifact for AI systems. Under a pinned version, it deterministically extracts the user’s stated intent and returns a structured Authorized Intent Record (AIR) with a cryptographic integrity block signed with Ed25519. The returned AIR serves as a stable comparison point for downstream systems.

Enterprise

Enterprise Endpoint

Null Lens is deployed as a dedicated enterprise instance with isolated infrastructure, org-scoped credentials, and signed AIR responses. Lens provides attestation, not enforcement, and is built for regulated, production, and audit-sensitive environments.

Endpoint
https://null-core.ai/api/lens-private
Python (requests)
Example
import os
import requests

r = requests.post(
  "https://null-core.ai/api/lens-private",
  headers={
    "Authorization": f"Bearer {os.getenv('NULL_LENS_API_KEY')}",
    "Content-Type": "application/json",
  },
  json={
    "messages": [
      {
        "role": "user",
        "content": "Summarize internal audit posture"
      }
    ]
  }
)

print(r.json())
cURL
Example
curl -X POST "https://null-core.ai/api/lens-private" \
  -H "Authorization: Bearer <PRIVATE_API_KEY_HERE>" \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      {
        "role": "user",
        "content": "Summarize internal audit posture"
      }
    ]
  }'
Response model: Lens returns structured JSON containing an air object and an integrity block. Customers may verify the returned AIR independently using the published Lens public key and use it as a stable comparison point in downstream systems.
Response

Structured Response

A typical 200 response returns a structured air object together with an integrity block for independent verification. Downstream systems can persist the record, verify its signature, and compare it against their own policy, routing, review, or audit logic.

Example response
JSON
{
  "object": "chat.completion",
  "org_id": "27a1dc4e-ab57-44e9-89af-c66231a2296b",
  "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"
  }
}
JavaScript / TypeScript
Example
const response = await fetch("https://null-core.ai/api/lens-private", {
  method: "POST",
  headers: {
    Authorization: "Bearer <PRIVATE_API_KEY_HERE>",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    messages: [
      {
        role: "user",
        content: "Summarize internal audit posture"
      }
    ]
  })
})

const data = await response.json()

console.log(data.air.scope)
console.log(data.air.boundary)
console.log(data.integrity.signature)
Python
Example
import os
import requests

r = requests.post(
  "https://null-core.ai/api/lens-private",
  headers={
    "Authorization": f"Bearer {os.getenv('NULL_LENS_API_KEY')}",
    "Content-Type": "application/json",
  },
  json={
    "messages": [
      {
        "role": "user",
        "content": "Summarize internal audit posture"
      }
    ]
  }
)

data = r.json()

print(data["air"]["scope"])
print(data["air"]["boundary"])
print(data["integrity"]["signature"])
Tip: Integrate directly against the AIR object and integrity block. Do not parse Lens responses as plain text.
Verification

Verifying Signed AIR

Every Lens response includes an AIR object and a signed integrity block. To verify a response, rebuild the canonical AIR payload in the exact field order shown below, hash it with SHA-256, and verify the returned Ed25519 signature using the published Lens public key.

1. Fetch the Lens public key

curl https://null-core.ai/api/lens-public-key

Example response:

{
  "public_key_id": "lens_2026_v1",
  "algorithm": "ed25519",
  "public_key": "BASE64_PUBLIC_KEY"
}

2. Canonical AIR payload

The verifiable payload is the canonical AIR object only, in this exact field order: record_id, timestamp, version, scope, boundary.

{
  "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."
}

3. Signature to verify

{
  "signature": "LRLoXyk5lSZ/jqtqKov1iRyWbtsVim01nRHX8DZkGJbBMeIxq25rL+X3EB9gg0hrhne65tNPSEJAx7ge7CgpDA==",
  "public_key_id": "lens_2026_v1",
  "algorithm": "ed25519"
}

4. Verify locally

Install the verifier dependency first: npm install tweetnacl

import nacl from "tweetnacl"
import crypto from "crypto"
import { Buffer } from "buffer"

const 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."
}

const signature =
  "LRLoXyk5lSZ/jqtqKov1iRyWbtsVim01nRHX8DZkGJbBMeIxq25rL+X3EB9gg0hrhne65tNPSEJAx7ge7CgpDA=="

const publicKeyBase64 = "BASE64_PUBLIC_KEY"

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 sig = Buffer.from(signature, "base64")
const pubKey = Buffer.from(publicKeyBase64, "base64")

const valid = nacl.sign.detached.verify(hash, sig, pubKey)

console.log("Signature valid:", valid)

5. Expected result

Signature valid: true

Verification is performed independently by the customer or downstream system. Lens signs and returns the AIR; customers choose how to operationalize verification in their own stack.

For production and audit-sensitive workflows, treat verification as the final acceptance check before downstream policy, routing, review, audit, or execution use.

Best Practices

Recommended operating patterns for production, regulated, and audit-sensitive Lens deployments.

  • One call per user input. Send the full instruction in messages[0].content. Lens is optimized for complete requests rather than token streams.

  • Store the full signed response. Persist both the AIR object and the integrity block together so the record remains verifiable over time.

  • Verify before downstream use. In regulated or production workflows, verify the returned signature with the published Lens public key before using the AIR in downstream policy, routing, review, audit, or execution systems.

  • Treat containment as non-actionable. When scope returns "Contained Input", halt downstream execution. Do not treat containment as authorization to proceed. Route to human review, or retry once with the original, unmodified input if the request appears legitimate.

  • Run Lens first. Call Lens before retrieval, tool use, RAG, or agent execution. Treat the returned AIR as the authoritative pre-execution record.

  • Never reconstruct intent manually. If a response is malformed or fails verification, retry once and then route to human review. Do not infer or regenerate a replacement AIR outside Lens.

  • Keep transport clean. Strip malformed markup, control characters, or corrupted payload content that could affect surrounding infrastructure.

  • Design for privacy. Lens is stateless by design and does not require persistent customer state to produce or verify an AIR.

Schema Stability & Governance Guarantees

Lens v1.0 defines a fixed response contract with two layers: the structured AIR object and the accompanying integrity block. Within the AIR, the canonical governance fields are scope and boundary.

Stable response shape

Lens v1.0 returns the same top-level format on every successful response: AIR plus integrity.

Fixed governance fields

The AIR contract for v1.0 remains centered on scope and boundary.

Deterministic extraction

Lens is designed for deterministic extraction under a pinned version and controlled runtime.

Cryptographic integrity

Each AIR is signed with Ed25519 and returned with a payload hash, signature, key identifier, and algorithm so customers can verify authenticity independently.

Version pinning

Enterprises may rely on Lens v1.0 without silent upgrades, forced migration, or hidden behavioral drift.

Explicit evolution

Future versions, if introduced, are separately versioned and explicitly adopted.

These guarantees let teams attach audit controls, policy logic, and verification workflows to a contract whose structure remains stable across time.

Integration Notes

Operational guidance for integrating Lens into production and audit-sensitive workflows.

  • Parse structured JSON. Lens returns a top-level AIR object and integrity block. Integrate against the JSON contract directly.

  • Bounded intent reduction. Long-form instructions are reduced into a compact AIR while preserving explicit domains from the input.

  • Independent verification. Customers may verify responses locally using the published Lens public key. Verification does not require sending the output back to Null.

  • Operational handling. Retry once on transient failures with exponential backoff. If a response is malformed or fails verification, do not use it downstream.

  • Performance profile. Typical latency ranges from 1–4 seconds depending on infrastructure, isolation, and deployment configuration.

Troubleshooting & Resilience

Operational guidance for handling containment responses, malformed inputs, verification failures, and transient reliability issues.

Containment Responses

When Lens cannot safely resolve an explicit scope due to unsafe, malformed, adversarial, or non-resolvable input, it may return a containment AIR that preserves the response contract while narrowing scope to a safe fallback.

{
  "air": {
    "record_id": "air_xxx",
    "timestamp": "2026-03-11T22:15:03.759Z",
    "version": "v1.0",
    "scope": "Contained Input",
    "boundary": "Strictly limited to the expressed scope. No additional domains inferred."
  },
  "integrity": {
    "payload_hash": "sha256:...",
    "signature": "...",
    "public_key_id": "lens_2026_v1",
    "algorithm": "ed25519"
  }
}

This indicates deliberate containment, not silent corruption. Lens preserves the signed response model while preventing unsafe, adversarial, or non-resolvable input from influencing downstream systems.

Downstream systems should treat a containment AIR as non-actionable for downstream execution or enforcement. Do not use scope: "Contained Input" as authorization to proceed.

Halt execution and route the request for human review or retry. Repeated containment on the same or similar input is a signal of adversarial input, prompt injection, or transport corruption rather than a transient inference failure.

  • Halt downstream execution — containment AIRs are not authorization to proceed.

  • Inspect the request for prompt injection, override attempts, or malformed transport payloads.

  • Retry once if the containment response is unexpected and the input appears legitimate.

  • Verify the returned signature before relying on the response downstream.

  • Route to human review if containment persists. Repeated containment on similar inputs indicates adversarial activity or transport corruption — not a transient inference failure.

Operational Reliability

Lens is designed for high-availability enterprise deployments. Use standard retry logic for transient network or upstream failures, and treat verification as the final acceptance check before downstream use.

FAQ

Common questions about Lens behavior, guarantees, verification, and operational use.

Does Lens store my data or learn from my inputs?

No. Lens is stateless by design. It does not store, retain, or train on customer inputs as application memory. Minimal operational telemetry such as latency, status, and error signals may be collected for service reliability.

What exactly is Lens?

Lens is a signed pre-execution governance artifact for AI systems. Under a pinned version, it deterministically extracts a natural-language request into an Authorized Intent Record (AIR) and returns that AIR together with a cryptographic integrity block.

What is included in the AIR?

The AIR contains the canonical governance fields scope and boundary, along with record metadata such as record_id, timestamp, and version.

Is Lens deterministic?

Lens is designed to be deterministic at the schema and extraction level for a pinned version. Identical input under the same version and controlled runtime is intended to produce the same AIR payload and extracted scope.

Does Lens improve model accuracy?

No. Lens does not optimize downstream reasoning quality. It defines and attests to pre-execution intent. It is a governance primitive, not an accuracy enhancement layer.

Are responses cryptographically signed?

Yes. Each AIR is signed with Ed25519 and returned with a payload hash, signature, algorithm, and public key identifier.

How do customers verify a response?

Customers fetch the published Lens public key, rebuild the canonical AIR payload, hash it, and verify the returned Ed25519 signature locally. Verification is performed independently by the customer or downstream system.

Will the output format ever change?

Lens v1.0 is version-pinned. The response shape and AIR contract are fixed for the version you integrate against. Future versions, if introduced, are explicit rather than silent upgrades.

What latency should I expect?

Typical latency ranges from 1–4 seconds depending on infrastructure, isolation, and workload. Enterprise deployments are optimized for consistency and governance reliability rather than maximum raw throughput.

How should I handle malformed outputs or verification failures?

Retry once with the same input. If the response remains malformed, fails verification, or returns repeated containment, route to human review. Do not manually reconstruct or infer a replacement AIR.

How should downstream systems handle containment AIRs?

Containment AIRs should be treated as non-actionable by default. Halt downstream execution, preserve the signed record, and route the request to human review or retry once with the original unmodified input if the request appears legitimate. Repeated containment on similar inputs may indicate adversarial input, malformed transport, or upstream corruption rather than a transient failure.

Who is Lens built for?

Lens is built for organizations operating in regulated, high-accountability, or audit-sensitive environments, including financial services, healthcare, enterprise governance, security, and compliance-heavy platforms.

Null Lens™

Signed pre-execution governance artifact for AI systems.

Deterministic extraction under a pinned version, structured AIR responses, signed integrity, and private isolated deployment for regulated and audit-sensitive environments.

Null Lens is a signed pre-execution governance artifact layer. It defines and signs a pre-executiongovernance artifact but does not perform downstream authorization, policy enforcement, or tool execution. Customers remain responsible for how Lens outputs are used within their own systems.

Null Lens™ and Null Core™ are trademarks of Null Technologies Pte. Ltd.

© 2026 Null Technologies Pte. Ltd. All rights reserved.