AXIS BLUE
CONTROL THE WORK. CONTROL THE RECORD.
Policy

Data policy.

AXIS BLUE is designed to minimize data exposure, control storage cost, prevent misuse, and keep operational evidence scoped to its intended purpose.

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 foundation@axisblue.io.

Last updated: 2026-04-10