AXIS BLUE
CONTROL THE WORK. CONTROL THE RECORD.
Policy

Data policy.

This Data Policy describes how AXIS BLUE classifies, processes, stores, constrains, and exposes operational data and evidence within authorized deployments.

Core posture

AXIS BLUE is designed around controlled collection, purpose limitation, and scoped access. Where feasible, the platform prioritizes structured operational records over indefinite retention of raw evidence, except where evidence capture, retention, or export is expressly required by configuration, workflow, audit need, contractual requirement, or legal obligation.

This posture is intended to reduce unnecessary exposure, constrain storage growth, and preserve operational accountability without converting the platform into a general surveillance archive.

What we collect

AXIS BLUE may collect identity attributes, session context, visit metadata, user-entered values, structured event logs, scan outputs, timestamps, diagnostic records, generated documents, and other data reasonably necessary to operate configured workflows.

Evidence may include photographs, documents, notes, and related metadata. Evidence capture is governed by deployment rules and operational controls and is not intended to constitute continuous monitoring absent an explicit deployment decision to the contrary.

Local-first evidence and upload windows

Certain environments may operate on a local-first basis, such that photographs and other large evidence items remain on the device unless and until a user or administrator initiates export, synchronization, or submission. Upload rights may be restricted to defined workflow states, operational windows, or approved submission events.

Other environments may store structured records, evidence, and generated outputs within remote infrastructure when configured. Storage behavior is deployment-specific and not uniform across all AXIS BLUE implementations.

How data is processed

Submitted or captured inputs may be processed to generate classifications, counts, summaries, extracts, reports, audit artifacts, and other structured outputs. AXIS BLUE may preserve derived operational records in place of, or in addition to, raw source materials depending on configuration and business purpose.

Processing methods, model-assisted functions, and output formats may change over time. The controlling principle remains that collection and exposure should be limited to what is reasonably necessary for the configured use case.

Infrastructure, tool services, and "proxy" boundaries

Deployments may rely on organization-controlled infrastructure, third-party cloud infrastructure, object storage, and supporting service layers. Regions, storage classes, retention intervals, and backup behavior are deployment-specific and may be controlled by the deploying organization or its designated operators.

AXIS BLUE may use specialized processors for functions such as rendering, scanning, classification, or export generation. Where practicable, requests may be routed through controlled server-side gateways or proxy layers in order to limit direct client exposure, centralize authentication, preserve auditability, and restrict token distribution.

Tool access may be subject to server-side authentication, scoped tokens, approval flows, or other policy enforcement mechanisms. Such controls are intended to constrain the functional and temporal scope of access and should not be interpreted as a guarantee against misuse, misconfiguration, or unauthorized disclosure.

Retention and storage limits

Retention rules, evidence windows, and storage limits may be enforced by user, account, organization, workflow, visit, task, date range, or other configured boundary. Such limits may be used to control cost, reduce exposure, preserve system performance, and enforce policy.

Raw evidence may be reduced, transformed, archived, exported, overwritten, or deleted according to configuration and operational need. AXIS BLUE does not represent or warrant indefinite preservation of any record unless expressly required by a separate written commitment. Each deploying organization remains responsible for retention, export, preservation, and litigation-hold obligations applicable to its own use.

Access, roles, and sharing

Access may be constrained by role, environment, organization, boundary controls, time window, workflow status, approval state, or other configured condition. Sharing should be considered limited, logged where available, and restricted to the intended operational purpose.

Deploying organizations are responsible for account provisioning, role assignment, key or credential distribution, supervisory review, and validation that access settings satisfy internal policy and applicable law.

Organizational boundaries

Where supported, AXIS BLUE separates data by tenant, organization, program, workspace, or operational context. Such boundaries are configuration-dependent. Administrators remain responsible for validating isolation, access controls, retention settings, and export permissions within their environment. Misconfiguration may create exposure even where technical separation exists.

What AXIS BLUE is not

AXIS BLUE is not, by default, a public records repository, forensic evidence platform, litigation system, or generalized employee-surveillance system. It is an operational capture and workflow platform. Any use beyond that scope is the responsibility of the deploying organization and not an inherent representation of the product.

Policy updates

AXIS BLUE may revise this policy from time to time. Revisions become effective upon publication to this page unless a different effective date is stated.

For data-governance, retention, or access questions concerning AXIS BLUE, contact foundation@axisblue.io.

Last updated: 2026-04-10