Project Aingeal mark

Project Aingeal

A civilian, user-controlled forensic integrity instrument focused on clarity, evidence continuity, and accountability-ready, tamper-evident recordkeeping — without surveillance, monitoring, or background execution.

Mission: Project Aingeal exists to help individuals preserve clarity and decision-grade records about their own digital artifacts, even when those artifacts are handled or processed by external systems and services.
Project Aingeal operates through discrete, user-authorized snapshots of state. Comparisons are performed only between states explicitly approved by the user, producing decision-grade records of change without continuous observation, passive monitoring, automated enforcement, or system control.
Milestones: M001–M013 validation checkpoints are now published as non-operational proof of repeatable runs, tamper-evident packaging, and independent verification posture.
The Spine is separate: it is the architectural foundation and file-flow discipline that makes milestones reproducible and evidence-grade. The spine itself is not a “milestone.”
Not a firewall. Not antivirus. Not monitoring software. Public-facing materials are intentionally explanatory and non-operational.
Public explanatory material only. No source code, execution pathways, operational procedures, or system-control functionality is disclosed.

What Problem This Addresses

When disputed access, unexpected changes, or unclear system behavior occur, individuals are often left reconstructing events weeks or months later without reliable, contemporaneous records.

Project Aingeal preserves what changed, when it changed, and why it was authorized at the moment records are created — not through later reconstruction.

The Gap This Fills

  • Decision-grade records: change evidence captured at the time of authorization.
  • Integrity-first preservation: records treated as continuity artifacts.
  • User authority: no background observation or implicit execution.
  • Governed scope: explicit limits on what is included and excluded.
  • Repeatability: consistent structure across time and cases.

Scope & Guardrails

  • No passive monitoring
  • No covert observation
  • No automated response or enforcement
  • No third-party analytics or tracking

Project Aingeal records change; it does not act on systems.

Public Materials

  • Architecture: conceptual structure and restraint-first design
  • Governance: ethical boundaries and permitted use
  • Milestones: non-operational validation checkpoints
  • GitHub: architecture-only public reference repository

Public Narrative

Project Aingeal did not begin as a technical exercise, a startup concept, or an academic pursuit. It began after a real-world cyber incident, when victims tried to report what happened and found that the systems designed to help them could not act — not from lack of concern, but from a structural absence: decision-grade records at the moment events occurred.

Without clear evidence of what changed, when it changed, and why it was authorized, institutions defaulted to reconstruction, delay, and dismissal. Under pressure, the victims began learning how digital systems record change, how evidence degrades over time, and why retrospective explanations fail.

The core insight: the problem is not malware classification. It is observability and integrity — preserving authoritative records anchored to user authorization, so decisions don’t depend on after-the-fact reconstruction.

Project Aingeal is an architectural response to that gap: user-initiated, event-bound snapshots that produce tamper-evident records of change, with transparency of intent and strict boundaries — not operational disclosure.