I built Aver (pronounced "AH-ver") because I believe important knowledge should be an indestructible artifact. It shouldn't live in a SaaS silo or a complex SQL schema; it should live in your Git repo, alongside your code, as plain text.
## The "Markdown-as-Truth" Architecture:
*The Authority is the File*: Records are stored as {id}.md files with YAML frontmatter. Aver treats your filesystem as the database.
*Disposable Indexing*: We use SQLite strictly as a performance layer (a "Lens"). If the DB is lost, aver admin reindex rebuilds it from the source files in seconds.
*Solving Merge Conflicts*: To make a Git-based tracker work for teams, Aver uses a Record/Note model. Instead of appending to one file, every update is a unique, separate file. This allows multiple devs to update the same record in different branches and merge cleanly.
## Why this matters:
*Digital Stewardship*: As a pastor and a dev, I value the "decades-long view." Aver is designed so your data is readable in 20 years with nothing more than a text editor.
*Zero-Dependency*: No servers, no daemons, no background processes. It’s a single-script engine that operates only when you tell it to.
*JSON I/O*: It includes a persistent JSON bridge so you can use it as a "storage engine" for automated workflows or custom front-ends without reimplementing the validation logic.
## Adaptability:
Aver isn't just a bug tracker. Because the structure is defined in your ``config.toml``, it’s a "chameleon." It’s currently being used for everything from technical logs to editorial workflows and research logs.
I'm interested in the community's thoughts on "Subsidiarity of Data"—the idea that the source of truth should reside at the lowest competent level: with the user, in their own repository.