Every device is a discovery item
Every phone, laptop, watch, and camera an operator carries into the field is a potential record. GPS breadcrumbs, camera frames, sensor logs, AI recommendations, chat messages, biometric data. Enterprise platforms treat this as a feature: total capture for accountability, review, and legal compliance. Operators treat it as a liability.
The concern is not hypothetical. Operators have watched helmet camera footage reviewed frame-by-frame by people who were not present, did not understand the context, and used the data to question split-second decisions made under fire. Radio transcripts have been pulled into investigations months after the fact. GPS tracks have been subpoenaed. The more data a device captures, the more material exists for someone with the benefit of hindsight and the luxury of time to second-guess.
None of this is an argument against accountability. The point is that the current data architecture, where everything is captured and nothing is disposable, creates a chilling effect on adoption. Operators respond predictably: a tool that records everything gets turned off, worked around, or left in the truck.
The enterprise model: capture everything, store forever
Platforms like Lattice and Maven are designed for persistent data capture. Every sensor feed, every detection, every operator action flows to cloud storage. This architecture serves command and legal review. It does not serve the operator.
The implicit contract is: we give you AI and situational awareness, and in exchange we record everything you do. For the analyst at a desk, this trade is invisible. For the operator in the field, it is the reason they distrust the software.
The Netherlands Armed Forces study on wearable health monitoring confirmed this dynamic. Operators accepted biometric monitoring when it was controlled by their medic and stayed within the team. Acceptance collapsed when the same data was accessible to command or external review. The technology was identical. The data governance model was different. The outcome was different.
The problem is not that operators are hiding something. The problem is that total persistent capture turns every mission into a permanent record that can be reviewed by anyone with access, for any purpose, at any point in the future. Operators respond rationally: they use less technology, not more.
What ephemeral means
An ephemeral mission is a mission where the data lifecycle is defined before step-off, controlled by the team during the operation, and enforced by the software after the mission ends. Load the mission. Run the operation. Export what you choose to keep. Destroy the rest. Nothing persists by default.
Ephemeral does not mean 'delete the files.' It means the architecture assumes mission data will not survive the mission unless someone makes an explicit, auditable decision to preserve it. The default is gone. The exception is kept.
Technically, this requires three things: isolated mission containers, selective export, and verified destruction.
Isolated mission containers
Each EdgeLance mission runs in its own data container. Models, RAG libraries, reference material, sensor logs, detections, AI assessments, operator decisions, and evidence clips all live within the mission boundary. Nothing from mission A leaks into mission B. Nothing from either mission persists in the device's general storage.
The mission container is created at mission start with the loadout the team selects: which AI models to run, which reference material to load, which sensor profiles to use, which ATAK overlays to publish. During the mission, all data generated by EdgeLance writes to the container. The container is encrypted at rest using hardware-backed keys where the device supports it.
Apple's Data Protection architecture provides hardware-backed file encryption on iOS and macOS. Each file is encrypted with a unique per-file key, wrapped by a class key tied to the device's Secure Enclave. EdgeLance mission containers use the most restrictive protection class: data is only accessible when the device is unlocked and the mission is active. When the mission ends and the container is destroyed, the per-file keys are discarded. Without the keys, the encrypted data on disk is unrecoverable.
Selective export
Before the mission container is destroyed, the team decides what to keep. EdgeLance presents the mission record: a timeline of detections, AI assessments, operator decisions, evidence clips, and the AAR narrative. The team lead and medic review the record and select what to export.
Export options are structured, not raw. The team does not export 'all the video.' They export a packaged AAR that contains: the mission summary, selected evidence clips tied to specific events, detection logs, and the decision timeline. The package is signed and timestamped. It can be delivered to command, uploaded to a system of record, or handed to a debriefer.
What is exported is a curated mission product. What is destroyed is the raw operational data that produced it. Command gets the intelligence picture. The operator's GPS breadcrumbs, raw biometric data, unselected camera frames, and intermediate AI assessments do not survive.
This satisfies both the operator's need for data control and command's need for mission intelligence. The AAR is the record. The raw data is disposable.
Verified destruction
Deletion is not destruction. A file deleted from an SSD may persist in wear-leveling blocks, journal entries, or filesystem metadata. For ephemeral missions to be credible, the destruction must be verifiable.
NIST SP 800-88 Rev. 1 defines three sanitization levels: Clear (logical overwrite), Purge (device-specific commands that make data unrecoverable through state-of-the-art lab techniques), and Destroy (physical destruction). For field operations on consumer hardware, Purge-level sanitization is the target.
On Apple devices, EdgeLance leverages the hardware encryption architecture. Destroying the mission container means discarding the encryption keys held in the Secure Enclave. The encrypted data remains on disk but is cryptographically unrecoverable. This is the same mechanism Apple uses for remote wipe: the device does not overwrite every sector, it destroys the keys that protect them. The result is the same: the data is gone.
On Android devices with hardware-backed keystore (Samsung Knox, Pixel Titan), the same approach applies. The mission container's encryption keys are bound to the hardware security module. Destroying the keys renders the container unrecoverable.
The system logs the destruction event itself: mission ID, timestamp, container hash before destruction, destruction method, and the operator who authorized it. This log entry is the only artifact that survives. It proves the mission existed and was properly disposed of, without preserving any mission content.
The legal question
The immediate objection: what happens when JAG or an investigation needs the mission record and the team wiped it? This is a real concern and it has a real answer.
First, the AAR export is the system of record. The team exports a structured, signed, timestamped mission package before destruction. That package contains the intelligence product, not the raw surveillance feed. If an investigation requires the mission record, the AAR exists in the system of record where it was delivered.
Second, the mission data policy is defined before step-off, not after. The data retention rules, what gets exported, what gets destroyed, and what the destruction timeline is, are part of the mission planning process. The retention rules are policy-driven data lifecycle management consistent with DoD Instruction 5200.01 and the classification authority's data handling requirements.
Third, the alternative is worse. If operators distrust the software because it records everything, they stop using it. A system that is unused captures nothing. A system that is trusted, used, and properly disposed of captures mission intelligence during the operation and delivers a structured record afterward. The net intelligence value of the trusted system is higher even though the raw data does not persist.
What changes for the operator
The operator knows before step-off that the mission data belongs to the team. The AI runs locally. The detections stay local. The biometric data stays with the medic. The GPS tracks stay in the container. When the mission ends, the team reviews the record, exports the AAR, and wipes the rest.
This changes the calculus on technology adoption. The reason operators turn off cameras, avoid using health trackers on missions, and work around enterprise platforms is the persistent surveillance architecture. Remove the persistence and the adoption problem changes. An operator who knows the data wipes clean after the mission will use the wearable readiness scoring, the AI detection overlay, and the mesh chat because none of it becomes a permanent record.
The DoD AI Strategy memo calls for AI that operates 'on-board, in real time, and often without connectivity.' Ephemeral missions extend that mandate: AI that operates on-board, in real time, without connectivity, and without creating a permanent surveillance record. That is AI the operator will actually use.
Implementation in EdgeLance
Ephemeral missions require four mechanisms. Mission containers: isolated encrypted storage per mission using hardware-backed keys. Selective export: structured AAR packaging with operator-controlled scope before destruction. Cryptographic destruction: key disposal through the device's secure enclave, rendering container data unrecoverable. Destruction receipts: a signed log entry proving the mission was properly disposed of.
The team lead configures the data retention policy during mission planning. Options include: destroy immediately after AAR export, destroy after 24/48/72 hours, or retain until manual destruction. The default is destroy after AAR export. The destruction is automatic unless the team explicitly extends the retention window.
A hold mechanism handles legal or investigation requirements. If a hold is placed on a mission before destruction, the container is preserved and the hold is logged. The hold requires explicit authorization from a designated authority, not a blanket policy. This prevents silent data retention while preserving the ability to hold specific missions when legally required.
The ephemeral mission architecture is what makes the difference between a surveillance tool and a mission tool. The team controls what leaves the field.