Trust Center

Pre-Execution Artifact & Governance Guarantees

Lens is designed for deterministic extraction under a pinned version and controlled runtime, producing a stable pre-execution governance artifact before downstream execution occurs. The resulting Authorized Intent Record (AIR) captures the user’s explicitly stated scope and is returned with a signed integrity block for independent verification.

• Authorized Intent Record (AIR): Lens returns a structured pre-execution record containing canonical governance fields, including scope and boundary, together with record metadata such as record_id, timestamp, and version.
• Explicit Scope Extraction: Lens is designed to capture only the explicit terms and domains expressed in the request. It does not expand scope through downstream retrieval, hidden enrichment, or execution-time reasoning.
• Boundary as Governance Contract: Each AIR includes a fixed structural boundary statement that customers may use as a contract point for downstream controls, audit checks, policy evaluation, or review workflows within their own systems.
• Signed Integrity Layer: Every successful Lens response includes an integrity block containing a payload hash, signature, public key identifier, and algorithm. Customers may verify the AIR independently using the published Lens public key.
• Audit & Review Baseline: AIR provides a stable pre-execution comparison point between what the user stated and what downstream systems later attempted, generated, or executed. This supports governance reviews, operational oversight, and audit-sensitive workflows.
• Schema Stability & Version Pinning: Lens v1.0 is designed as a fixed response contract. Customers integrate against a stable AIR + integrity shape rather than an unstructured text response, and future versions are adopted explicitly rather than silently introduced.
• Attestation-Only Architecture: Lens does not perform downstream authorization, policy enforcement, tool execution, or access control. It defines and attests to pre-execution intent; customers retain authority over all execution and enforcement decisions.

Lens Guarantees

These guarantees define the operational and governance properties customers can rely on when integrating Lens into production and audit-sensitive workflows.

• Zero Content Retention: Null Lens is designed not to store, persist, or retain customer prompt or response content as application memory, long-term logs, or training data.
• Stateless by Design: Each request is processed in isolation with no cross-request memory, reuse, or carryover of customer content.
• Signed Response Integrity: Every successful Lens response includes an AIR together with a signed integrity block containing a payload hash, signature, public key identifier, and algorithm for independent verification.
• Stable Governance Contract: Lens v1.0 returns a fixed response shape built around the structured air object and accompanying integrity block. Future versions, if introduced, are explicitly versioned rather than silently substituted.
• Explicit Scope Handling: Lens is designed to reduce requests into a bounded pre-execution governance record based on the user’s explicitly stated scope, without relying on downstream tool execution, retrieval, or policy enforcement.
• Private Deployment Model: Lens is currently provisioned through private customer deployments with isolated runtime boundaries and organization-scoped endpoints.
• Minimal Output Surface: Lens returns only the structured governance artifact and integrity metadata required for integration and verification. Internal prompts, hidden reasoning, and system instructions are not exposed in the response contract.

Responsibility Matrix

This matrix defines the control boundary across Null Lens, our infrastructure vendors, and customer systems. It reflects Lens as a stateless, pre-execution governance layer rather than a downstream enforcement system.

Infrastructure & Isolation

Null Lens is currently provisioned as a private-instance deployment. Each customer environment runs on isolated infrastructure with dedicated runtime boundaries, rather than a shared public inference pool.

• Core inference is executed on Runpod-managed GPU infrastructure. Runpod is responsible for the underlying compute orchestration and physical hosting, while Null is responsible for the application layer, including AIR generation, signed response integrity, request isolation, and operational controls.
• Each customer deployment runs on a dedicated instance boundary. The current operating model is designed to avoid shared customer runtime state and cross-tenant memory carryover.
• API routes are provisioned per organization and are intended to be accessible only within the assigned customer environment and credentials.
• The front end and management surfaces are hosted on Vercel. Vercel handles static delivery, CDN, and edge routing; it does not perform model inference for Lens.
• Organization records, billing metadata, and API key tracking are stored in Supabase. We store account-level metadata only and do not store customer prompt or response content there.
• All network traffic between client and service is encrypted in transit (HTTPS/TLS). Data at rest in vendor-managed systems, where applicable, is protected using standard encryption controls provided by the underlying vendors.
• Minimal operational metadata such as latency, status codes, and billing-related records may be collected for service operation and uptime monitoring. Customer prompt and response content is not retained as application memory or long-term logs.

Security & Compliance

Null Lens applies security controls at the application layer while relying on established infrastructure providers for hosting, identity, and platform-level safeguards. This section describes those boundaries directly.

• Authentication & Access Control: Authentication and identity are handled through Clerk. Clerk manages user authentication, sessions, and identity-layer controls, while Null manages organization scoping and API key issuance at the application layer.
• Least-Privilege Access: Lens uses organization-scoped credentials and follows a least-privilege model for programmatic access, reducing unnecessary exposure across customer environments.
• Vendor Compliance Boundary: Null Lens itself has not undergone its own SOC 2 audit. Null Lens currently relies on vendor-backed infrastructure controls together with application-layer safeguards. First-party compliance maturation is part of the longer-term enterprise roadmap. Key providers in our stack maintain independent security attestations and compliance controls. Clerk states SOC 2 Type II, HIPAA, DPF, and GDPR/CCPA-related privacy coverage. Supabase states SOC 2 Type II, supports HIPAA projects and BAAs, and provides GDPR-related DPA/privacy coverage.Vercel states SOC 2 Type 2, ISO 27001, PCI DSS, DPF, GDPR, HIPAA support for enterprise customers, and TISAX Level 2. Runpod states SOC 2 Type II and has announced independent verification against HIPAA and GDPR standards. Null remains responsible for its own application-layer design, request isolation model, signed AIR responses, and data-handling practices.
• Application-Layer Controls: Null is responsible for the Lens application layer, including request isolation, signed AIR generation, integrity handling, and non-persistence of customer content within the Lens service design.
• Secure Development Practices: We perform automated vulnerability scanning and periodic manual review before production releases. Critical issues are prioritized through patching and incident response workflows.
• Risk Transparency: Null relies on third-party infrastructure providers for hosting availability, physical security, and certain platform controls. If a vendor experiences an outage or security incident, recovery timelines and remediation at the infrastructure layer follow that vendor’s published processes. Null coordinates customer communication where appropriate.

Data Governance

Lens is designed to process customer content ephemerally and to minimize retained data at the application layer. This section explains what is and is not retained as part of normal service operation.

• No Long-Term Content Retention: Null Lens is designed not to store customer prompt or response content as application memory, training data, or long-term retained logs in normal production operation.
• Ephemeral Processing: Request content is processed in-memory within the active runtime boundary and is not intended to persist across requests as reusable application state.
• Minimal Operational Metadata: Limited metadata such as organization ID, request latency, status codes, and billing-related records may be retained for reliability, service operation, and account management. This metadata does not include customer prompt or response content.
• Customer Ownership: Customers retain ownership and control over their own data and downstream records. Null does not claim customer content for reuse, resale, or model training.
• Audit & Retention Responsibilities: Null Lens does not provide long-term customer content retention or archival logging by default. Customers who require durable audit trails, evidence retention, or content archiving should implement those controls within their own systems or middleware.
• PII & Regulated Data: Customers should evaluate whether personal, health, financial, or other regulated data is appropriate for their use case before transmitting it to Lens. Where legally required and commercially appropriate, Data Processing Addendums (DPAs) or Business Associate Agreements (BAAs) may be discussed on request.

Reliability & SLA

Null Lens is deployed on vendor-backed infrastructure with platform-level uptime commitments and public status reporting. Null monitors the Lens application layer for availability, latency, and error conditions, while underlying infrastructure availability remains dependent on the relevant vendor platforms.

• Infrastructure Availability: Lens runs on Runpod for GPU compute and Vercel for web delivery and edge routing. Runpod states a typical 99.99% uptime commitment through its SLA, and Vercel’s enterprise SLA also states 99.99% service availability, subject to the terms and exclusions defined by each provider.
• Application-Layer Monitoring: Null monitors uptime, latency, and error rates at the Lens application layer and responds operationally on top of these vendor platforms. Vendor infrastructure restoration remains subject to the providers’ own incident and recovery processes.
• Current Deployment Model: Lens is currently provisioned through private isolated customer deployments rather than a public shared inference pool. Any customer-specific operational commitments beyond the baseline vendor platform terms are defined by contract where applicable.
• Latency Profile: Typical request latency varies by model runtime, queue depth, and regional load. In normal operation, customers should expect responses in the low-single-digit seconds range rather than sub-second inference.
• Incident Communication: In the event of a vendor or platform incident affecting Lens availability, Null coordinates customer communication where appropriate and can provide post-incident context or summaries on request.

Legal & Contact

Enterprise diligence, compliance documentation, and legal review are handled directly with customer teams based on deployment requirements and regulatory scope. Null supports diligence conversations around deployment isolation, signed AIR responses, and application-layer controls.

• Enterprise Documentation: Compliance and legal materials, including a Data Processing Addendum (DPA) and, where appropriate, a Business Associate Agreement (BAA), may be discussed with enterprise customers on request and evaluated based on the customer’s regulatory and contractual requirements.
• Security & Compliance Requests: For vulnerability disclosure, security review, enterprise diligence, or compliance inquiries, contact us at support@null-core.ai. For sensitive review materials, an NDA may be requested before disclosure.
• Vendor Documentation: Supporting vendor compliance materials for Clerk, Supabase, Vercel, and Runpod may be referenced during enterprise diligence where relevant to the deployment model and customer review process.
• © 2026 Null Technologies Pte. Ltd.