AXIS | C2
CONTROL THE WORK. CONTROL THE RECORD.
Policy
Política

Data policy.

Política de datos.

AXIS BLUE is an independent project and is not a production system. It is designed to minimize exposure, control storage cost, and keep operational records scoped to purpose. Intelligence is durable. Evidence is conditional.

AXIS BLUE es un proyecto independiente y no es un sistema en producción. Está diseñado para minimizar la exposición, controlar el costo de almacenamiento y mantener los registros operativos con alcance al propósito. La inteligencia es duradera. La evidencia es condicional.

Core posture

AXIS BLUE is built around controlled capture. We prefer collecting structured operational intelligence (what happened) over collecting raw evidence (what was photographed), unless evidence is required by workflow, risk, audit, or explicit escalation.

This approach is intended to reduce cost, reduce unnecessary surveillance, and preserve operator trust while still enabling accountability when proof is needed.

What we collect

AXIS BLUE may collect operational context such as identity and session context, visit metadata, user-entered fields, structured event logs, scan results, timestamps, and generated outputs (for example: summaries and reports).

Evidence may include photos, documents, and supporting notes. Evidence capture is intended to be operator-initiated within defined usage windows and governed by client policy, not continuous monitoring.

Local-first evidence and upload windows

In the current stage, non-foundation usage is local-only by default. Photos and large evidence items are stored locally on the operator device unless the user explicitly exports or shares them. Uploading to server storage can be restricted to controlled windows (for example: during an active visit, or during an evidence submission window) to reduce cost and prevent misuse.

Foundation-level usage may store structured intelligence and related outputs beyond local storage when configured. Non-foundation usage remains local unless explicitly exported by the user.

How data is processed

Operational inputs may be processed to generate structured outputs such as summaries, counts, classifications, and reports. AXIS BLUE is designed to retain derived operational records where possible, while limiting retention of raw evidence unless required.

Processing methods and outputs may evolve as the platform develops, but the core principle remains: collect what is necessary, keep it scoped, and minimize exposure.

Infrastructure, tool services, and “proxy” boundaries

Deployments may use cloud infrastructure for services and object storage. Retention, regions, and storage configuration are deployment-specific and controlled by the deploying organization.

AXIS BLUE may use specialized processors for specific tasks such as PDF rendering or barcode/QR scanning. When third-party processors are used, AXIS BLUE is designed to route requests through controlled server-side tool gateways (proxies) where possible. This keeps vendor keys and internal tokens off operator-facing clients and allows tighter access controls, logging, and rate limits.

Tool access can be protected using server-side authentication and token checks. These gates are intended to create a brief, controlled window into tool functionality rather than exposing tool services directly to the public web.

Retention and storage limits

Evidence windows, retention rules, and storage limits may be enforced per user, per visit, per organization, or per time period. Limits exist to control cost, reduce exposure, and prevent misuse.

Raw evidence may be reduced, transformed, exported, or discarded based on configuration and operational need. AXIS BLUE does not guarantee indefinite preservation of raw evidence. Organizations are responsible for exporting or retaining records as required by their internal policy or applicable law.

Access, roles, and sharing

Access may be limited by role, configuration, time windows, Boundary mechanisms, or explicit approval. Sharing is intended to be controlled, auditable, and purpose-limited.

Deploying organizations are responsible for account approval, role assignment, key distribution, and ensuring that access aligns with internal requirements.

Organizational boundaries

Where supported, AXIS BLUE separates data by organization, program, or operational context. Administrators are responsible for validating access controls and retention settings in their environment. Misconfiguration can create exposure even in well-designed systems.

What AXIS BLUE is not

AXIS BLUE is not intended to be a surveillance product, a forensic evidence platform, or a legal system of record. It provides operational capture and visibility, not determinations, enforcement, or behavioral monitoring.

Policy updates

This policy may be updated as AXIS BLUE evolves. Material changes will be reflected on this page.

For data questions or requests, contact gkearns@axisblue.io.

Postura central

AXIS BLUE se basa en la captura controlada. Preferimos recopilar inteligencia operativa estructurada (lo que ocurrió) en lugar de evidencia en bruto (lo que se fotografió), a menos que la evidencia sea requerida por el flujo de trabajo, el riesgo, la auditoría o una escalación explícita.

Este enfoque busca reducir costos, disminuir la vigilancia innecesaria y preservar la confianza del operador, sin dejar de habilitar la rendición de cuentas cuando se necesita prueba.

Qué recopilamos

AXIS BLUE puede recopilar contexto operativo como identidad y contexto de sesión, metadatos de visita, campos ingresados por el usuario, registros de eventos estructurados, resultados de escaneos, marcas de tiempo y salidas generadas (por ejemplo: resúmenes y reportes).

La evidencia puede incluir fotos, documentos y notas de soporte. La captura de evidencia está pensada para ser iniciada por el operador dentro de ventanas de uso definidas y gobernada por la política del cliente, no por monitoreo continuo.

Evidencia local primero y ventanas de carga

En la etapa actual, el uso no fundacional es local por defecto. Las fotos y elementos grandes de evidencia se almacenan localmente en el dispositivo del operador a menos que el usuario los exporte o comparta explícitamente. La carga al almacenamiento del servidor puede restringirse a ventanas controladas (por ejemplo: durante una visita activa o durante una ventana de entrega de evidencia) para reducir costos y evitar el mal uso.

El uso a nivel fundacional puede almacenar inteligencia estructurada y salidas relacionadas fuera del almacenamiento local cuando se configure. El uso no fundacional sigue siendo local a menos que el usuario lo exporte explícitamente.

Cómo se procesan los datos

Las entradas operativas pueden procesarse para generar salidas estructuradas como resúmenes, conteos, clasificaciones y reportes. AXIS BLUE está diseñado para conservar registros operativos derivados cuando sea posible, mientras limita la retención de evidencia en bruto salvo que sea necesaria.

Los métodos y salidas de procesamiento pueden evolucionar conforme la plataforma se desarrolla, pero el principio central se mantiene: recopilar lo necesario, mantenerlo acotado y minimizar la exposición.

Infraestructura, servicios de herramientas y límites “proxy”

Las implementaciones pueden usar infraestructura en la nube para servicios y almacenamiento de objetos. La retención, regiones y configuración de almacenamiento dependen de la implementación y están controladas por la organización que despliega.

AXIS BLUE puede usar procesadores especializados para tareas específicas como renderizado de PDF o escaneo de códigos de barras/QR. Cuando se usan procesadores de terceros, AXIS BLUE está diseñado para enrutar solicitudes a través de puertas de enlace de herramientas del lado del servidor (proxies) cuando sea posible. Esto mantiene las llaves de proveedor y los tokens internos fuera de los clientes de cara al operador y permite controles de acceso, registro y límites de tasa más estrictos.

El acceso a herramientas puede protegerse usando autenticación del lado del servidor y verificaciones de tokens. Estas puertas están pensadas para crear una ventana breve y controlada hacia la funcionalidad de la herramienta en lugar de exponer servicios de herramientas directamente a la web pública.

Retención y límites de almacenamiento

Las ventanas de evidencia, reglas de retención y límites de almacenamiento pueden aplicarse por usuario, por visita, por organización o por periodo de tiempo. Los límites existen para controlar costos, reducir exposición y prevenir el mal uso.

La evidencia en bruto puede reducirse, transformarse, exportarse o descartarse según la configuración y la necesidad operativa. AXIS BLUE no garantiza la preservación indefinida de evidencia en bruto. Las organizaciones son responsables de exportar o conservar registros según su política interna o la ley aplicable.

Acceso, roles y compartición

El acceso puede limitarse por rol, configuración, ventanas de tiempo, mecanismos de Boundary o aprobación explícita. La compartición está pensada para ser controlada, auditable y limitada al propósito.

Las organizaciones que despliegan son responsables de aprobar cuentas, asignar roles, distribuir llaves y garantizar que el acceso se alinee con requisitos internos.

Límites organizacionales

Cuando se admite, AXIS BLUE separa los datos por organización, programa o contexto operativo. Los administradores son responsables de validar los controles de acceso y la configuración de retención en su entorno. Una mala configuración puede generar exposición incluso en sistemas bien diseñados.

Lo que AXIS BLUE no es

AXIS BLUE no está destinado a ser un producto de vigilancia, una plataforma de evidencia forense ni un sistema legal de registro. Proporciona captura y visibilidad operativa, no determinaciones, imposiciones ni monitoreo de comportamiento.

Actualizaciones de la política

Esta política puede actualizarse conforme AXIS BLUE evoluciona. Los cambios materiales se reflejarán en esta página.

Para preguntas o solicitudes sobre datos, contacta a gkearns@axisblue.io.