AegisWatch · Ethical AI Use Framework

This page is a plain, static ethics document. It is not connected to any system and grants no capability — it states the principles this (strictly non-weapon) monitoring project commits to.

1. Human-in-command, always

• No AI system in this project may initiate, recommend, or execute any use of force. The system only observes, logs, and surfaces alerts to a human operator.
• Every escalation ends with a named human decision-maker. The AI never "decides" for the human; it assists triage only.

2. No autonomous lethal force

• Autonomous lethal force is categorically excluded from scope. There is no targeting module, no weapons interface, and no API that could actuate a weapon — by design, not by policy alone.
• Any feature request that would introduce weapon-adjacent capability (targeting, tracking for interdiction, weapon cueing) must be rejected at design review.

3. Audit logging

• Every alert, every operator action (acknowledge / escalate / dismiss), and every configuration change is written to an append-only, tamper-evident event log with timestamps.
• Logs are reviewable by independent auditors and retained for a defined period. No operator may edit or delete their own log entries.

4. Proportionality

• Responses to alerts must be proportionate to the assessed threat. A "door left ajar" alert warrants a walk-over check, not a facility lockdown.
• Severity levels shown in the UI (low / medium / high) are heuristics, not ground truth — operators are trained to verify before acting.

5. Civilian-harm avoidance

• The system's purpose is protective monitoring of defined zones, not the classification of people. It must never be used to profile, track, or build dossiers on individuals or groups.
• Where the system operates near public spaces, data minimization applies: no facial recognition, no identity storage, no data retention beyond operational need.
• If a deployment context risks civilian harm, the deployment does not proceed — commercial or operational pressure does not override this.

6. Honest labeling

• Simulated elements must be labeled as simulated everywhere they appear — in the UI, in demos, and in sales material. A mockup must never be presented as a live capability.
• Known limitations (e.g. no object detection in this MVP) must be disclosed up front, not buried in footnotes.