The intentional AI wearable checklist

How to use the checklist

Ask each question before treating a wearable as intentional or privacy-preserving. A clear answer should describe observable product behavior, the data path and the user control—not rely on labels such as “private,” “secure” or “responsible AI.”

This framework is not a certification, legal assessment or product ranking. A documentation answer shows what a company says. A physical test shows what a registered sample actually does. Keep those forms of evidence separate.

1–3. Define the capture boundary

Intentional capture needs a beginning and an end that a person can understand. A button alone is insufficient if the microphone was already buffering, the stop state is ambiguous or a failure leaves the wearer unsure what happened.

• Does the microphone remain inactive until a deliberate action?
• What exact action begins and ends capture?
• Is recording feedback continuous, understandable and able to reveal a failure?

4–5. Make the social boundary legible

Wearable recording affects people beyond the owner. A product should explain any pre-activation buffer and make active capture reasonably noticeable. An indicator can support awareness, but it does not replace consent or create permission to record.

• Is any audio buffered before the deliberate action, and if so, for how long?
• Can people nearby reasonably understand when capture is active?

6–8. Follow every form of the data

Raw audio, a transcript and extracted context expose different information and should not inherit the same retention or access rule by default. A useful evaluation follows each form from creation through processing, storage, correction and deletion.

• Are raw audio, transcript and extracted context treated as separate data forms?
• Are the processor, storage location and retention period disclosed for each form?
• Can the owner correct, export and delete data, and revoke future access?

9–10. Limit what connected AI can retrieve and do

A wearable can collect data responsibly and still expose too much downstream. Connected assistants need narrow permissions, preserved provenance and a clear separation between understanding a captured intention and receiving authority to act on it.

• Can a connected AI retrieve raw audio, or only the bounded context its permission allows?
• Does a captured intention remain context rather than authorization for an external action?

What counts as evidence

Record the source for every answer. Product documentation can establish a stated design or policy. A privacy notice can establish disclosed processors and retention. Only a reproducible test on an identified physical sample can establish device behavior such as feedback, offline storage, transfer recovery or battery performance.

Use “unknown” when the evidence is missing. An unanswered question is more informative than a confident inference from marketing copy. Update the record when the product, policy, firmware or connected service changes.

• Documentation evidence: dated public product, security or privacy material.
• Observed evidence: reproducible result tied to a device, firmware and test method.
• Unknown: no source strong enough to support an answer.
• Not applicable: the function or data form does not exist in the evaluated system.

Research basis and scope

The checklist translates broader work on episodic wearable interaction, trustworthy AI, privacy, transparency and human oversight into product questions that can be answered without pretending to provide a universal standard.

BEFORE Band publishes this framework as a design and reporting aid. It has not been endorsed by the researchers or institutions below.

• The Pen: Episodic Cognitive Assistance via an Ear-Worn InterfaceCHI 2026 research on intentionally invoked, episodic wearable AI and its social boundaries.
• NIST Artificial Intelligence Risk Management Framework 1.0A voluntary framework for incorporating trustworthiness into AI design, use and evaluation.
• NIST AI RMF: Human–AI interactionContext for defining human roles, responsibilities and limitations in operational AI systems.