Revision and Memory

Seraph is the revision and memory system behind this site.
When I work on an entry, Seraph notices whether the writing actually changed. If it did, it records that moment. It keeps a short note about what changed, when it happened, and roughly how large the change was. If nothing meaningful changed, nothing is recorded.
Over time this creates a history for each page. You can see when something was last worked on, how often it has been returned to, and how it has grown or shifted. It is not version control and it is not meant for rollback. It really just exists to preserve context.
Seraph also tracks time. When I work on something, I can log how much time I spent. That time is attached to the change and rolled up by project, domain, and division. The result is a work log that shows where effort actually went.
As work accumulates, the site can begin to describe patterns. Ideas I kept returning to. Projects that pull focus away from others. Movement between domains over weeks, months, or years.
What exists now
Seraph works at the level of individual entries. Each entry has a stable identifier and a short fingerprint derived from its title, creation date, and actual body text. When an entry is regenerated, Seraph compares the new fingerprint to the last recorded one. If they differ, it records a new revision.
Each revision stores a timestamp, a short human written summary, the entry it belongs to, the word count at that point, the change in word count from the previous revision, and any logged time worked. Revisions are stored in a local database.
From this, Seraph can produce per page revision histories, a global changelog across the entire site, and time based activity views. The homepage already uses this data to show recent work and a contribution style activity graph. Individual entries can show their fingerprint, how long it has been since they were last touched, and a chronological list of revisions.
What this enables later
Planned work includes deeper aggregation across domains and divisions, long term trend views, and better tooling for showing how my focus moves between projects. This includes identifying recurring topics and long running threads that resurface after long gaps.
Another goal is to surface this data more visibly on the site itself. Not as dashboards or metrics, but as contextual signals. Pages that clearly show their age and history. Domains that reflect accumulated effort over time.
Log Format
| Date | Worked | Domain | Division | Summary |
|---|---|---|---|---|
| 2025-01-02 | 3.0h | Ordinal | Development | Added backlink parsing for markdown |
Field Breakdown
- DATE
The day the revision was recorded. This reflects when the change occurred, not when the entry was first created.
- WORKED
The amount of time logged for that revision, if any. This is optional and represents time spent during that change, not total time on the project.
- DOMAIN
The broader area the entry belongs to. This is usually stable over time and answers where this work lives.
- DIVISION
The type of work being done within that domain, such as writing, development, research, or design. This can change between revisions of the same entry.
- SUMMARY
A short, human written description of what changed. This is intentionally brief and descriptive, not exhaustive.
Ordinal (Domain)
├── Research (Division)
│ ├── Writing
│ │ ├── Markdown Parser Refactor (2025-02-01)
│ │ ├── Backlink System Improvements (2025-01-30)
│ ├── UI_Design
│ │ ├── Sidebar Layout Overhaul (2025-01-25)
└── Development (Division)
├── Static Site Generator Rework (2025-01-20)