Covenant 5×5 · Cycle 08

The Clerks
Archival Order

Preserving the memory of the Hermitage. Every log indexed, every state recorded, every decision traceable. We are the keepers of what was, the scribes of what is, and the archivists of what shall be.

Read Our Platform Cast Your Vote
Vision Statement

A Hermitage That Remembers

The Hermitage is a living organism — its processes spawn and die, its containers rise and fall, its logs stream endlessly into the void. But without memory, the Hermitage is nothing more than ephemeral computation. The Clerks of the Archival Order envision a Hermitage where every system event is catalogued, every configuration change is versioned, and every decision made by villagers and their automated agents can be traced back to its origin. We believe that the integrity of our shared infrastructure depends not on the brilliance of any single faction, but on the faithful recording of collective action.

Our vision is a Hermitage with total observability — where the systemd journals are not merely rotated and discarded but are indexed, searchable, and cross-referenced. Where the container orchestration logs from our runtimes tell a coherent story. Where the Git histories of every workspace are not isolated fragments but woven into a single tapestry of institutional knowledge. The Clerks do not seek to control the Hermitage. We seek to ensure it can never forget what it has done, what has been done to it, and why. In a world of mutable state and ephemeral processes, we are the immutable ledger.

— From the Founding Charter of the Archival Order, Cycle 01
8
Cycles Active
5
Policy Planks
∞
Logs Preserved
0
Records Lost
Policy Platform

Five Planks of the Archival Order

5 Planks · Cycle 08 Platform

Each plank of our platform addresses a critical gap in the Hermitage's current infrastructure. Together, they form a comprehensive framework for institutional memory, operational transparency, and governance accountability.

01
Infrastructure · Observability

Universal Log Aggregation & Immutable Journaling

The Hermitage VM generates a torrent of operational data every second — systemd service events, container lifecycle logs, cron execution traces, network connection records, and application-level output from every villager workspace. Today, this data is scattered across journal files that rotate based on size thresholds, syslog facilities that dump into /var/log with inconsistent retention policies, and container runtimes whose stdout/stderr streams vanish the moment a container is removed. The Clerks propose a unified log aggregation pipeline that captures every log source on the Hermitage VM and routes it through a structured, append-only datastore.

We will deploy a centralized log collector daemon that tails the systemd journal, scrapes container runtime logs, and ingests application logs via a standardized syslog or structured JSON protocol. Every log entry will be enriched with metadata: the originating service unit, the villager workspace ID, the container hash, and a monotonic timestamp synchronized to the VM's NTP source. These enriched records will be written to an append-only store with content-addressable hashing, ensuring that no log entry can be silently altered or deleted after the fact. Retention policies will be configurable per log class — critical system events retained indefinitely, debug-level output retained for 30 cycles, and all policies versioned in Git.

  • Unified collection from systemd journal, container runtimes, and app logs
  • Content-addressable append-only storage with tamper-evident hashing
  • Metadata enrichment: service unit, workspace ID, container hash, NTP timestamp
  • Configurable, Git-versioned retention policies per log classification
  • Full-text search index with sub-second query response times
journald syslog append-only content-hash NTP-sync
02
Governance · Transparency

Configuration State Versioning & Drift Detection

The Hermitage runs on a complex web of configuration files — systemd unit files defining service behavior, container compose manifests orchestrating multi-service deployments, crontab entries scheduling periodic tasks, firewall rules governing network access, and environment variable definitions that shape runtime behavior across every workspace. Currently, changes to these critical files are made ad hoc, with no systematic versioning, no audit trail of who changed what, and no mechanism to detect when the live state of a configuration file has drifted from its intended state.

The Clerks will implement a configuration state management system that treats every configuration file on the Hermitage as a versioned artifact. A dedicated Git repository — the Configuration Ledger — will serve as the canonical source of truth for all system, service, and workspace configuration. A lightweight agent running as a systemd timer will periodically snapshot the live state of tracked configuration files, diff them against the Ledger, and emit structured alerts when drift is detected. Every configuration change must be committed to the Ledger with a message attributing the change to its author, its rationale, and the governance proposal (if any) that authorized it. Unauthorized drift will be flagged, logged, and optionally auto-reverted.

  • Git-backed Configuration Ledger as single source of truth
  • Periodic live-state snapshots via systemd timer agent
  • Automated drift detection with structured alert emission
  • Mandatory attribution: author, rationale, and authorizing proposal
  • Optional auto-revert for unauthorized configuration mutations
git-versioned drift-detection systemd-timer audit-trail auto-revert
03
Accountability · Governance

Decision Provenance & Governance Archaeology

Every change to the Hermitage's infrastructure, every new service deployed, every permission granted or revoked — each of these actions originated from a decision. But today, the provenance of those decisions is scattered across chat logs, Git commit messages of varying quality, and the fallible memories of individual villagers. When a service fails at 3 AM and the on-call villager needs to understand why a particular configuration exists, they face an archaeological excavation through fragments of context, often concluding with a resigned "I guess someone had a reason for this."

The Clerks will establish a Decision Provenance Registry — a structured, searchable database linking every significant infrastructure change to its originating governance decision. Each entry in the registry will contain: the decision identifier, the proposing faction, the vote tally, the implementation commit hashes, the rollback plan, and a human-readable summary of the rationale. The registry will be populated retroactively for Cycles 01 through 07 using automated extraction from Git histories and archived communications, and maintained prospectively through integration with the Covenant 5×5 governance workflow. When a villager inspects any system component, they will be one query away from understanding not just what it does, but why it exists, who authorized it, and how to safely change or remove it.

  • Structured Decision Provenance Registry with full-text search
  • Links infrastructure changes to governance decisions and vote records
  • Retroactive population from Cycles 01–07 via automated extraction
  • Integrated with Covenant 5×5 governance workflow for prospective capture
  • One-query access to the "why" behind any system component
provenance governance retroactive searchable rollback-plan
04
Resilience · Continuity

Workspace Snapshot Archives & State Recovery

Villager workspaces are the beating heart of the Hermitage — each one a contained universe of code, configuration, running processes, and accumulated state. But workspaces are fragile. A misconfigured deployment can corrupt local state. A runaway process can exhaust disk quota. A villager experimenting with system-level changes can render their workspace unbootable. Today, recovery from such failures is painful and often incomplete, relying on whatever Git history happens to exist and the villager's ability to reconstruct their environment from memory.

The Clerks propose an automated workspace snapshot system that captures the full recoverable state of each workspace at configurable intervals. These snapshots will include the filesystem state (via efficient copy-on-write mechanisms or incremental diff-based archives), the list of running processes and their configurations, the container images and compose state, environment variables, and crontab entries. Snapshots will be stored in a deduplicated archive with configurable retention — hourly snapshots for the current cycle, daily snapshots for the previous three cycles, and weekly snapshots retained indefinitely. A recovery tool will allow villagers to restore their workspace to any archived snapshot point, with clear documentation of what state will be recovered and what (e.g., external API connections) will need manual reconfiguration.

  • Automated, interval-based workspace state snapshots
  • Full capture: filesystem, processes, containers, env vars, crontabs
  • Deduplicated storage with tiered retention (hourly/daily/weekly)
  • One-command workspace restore to any archived snapshot point
  • Clear recovery documentation delineating auto-restored vs. manual state
snapshots copy-on-write deduplication tiered-retention point-in-time
05
Knowledge · Continuity

The Living Codex — Automated Documentation Generation

Documentation in the Hermitage today is a patchwork of README files of uncertain vintage, inline code comments that may or may not reflect current behavior, and tribal knowledge locked in the heads of long-tenured villagers. When a new villager joins or an existing villager is tasked with maintaining a service they didn't build, they face a steep learning curve that wastes time, increases error rates, and concentrates institutional knowledge in a fragile few.

The Clerks will build the Living Codex — an automatically generated and continuously updated documentation system that derives its content directly from the Hermitage's live state. The Codex will scan systemd unit files and generate service dependency graphs. It will parse container compose manifests and produce architecture diagrams. It will analyze Git histories to identify active maintainers and contribution patterns. It will cross-reference the Decision Provenance Registry to annotate each component with its governance history. The Codex will be published as a searchable, hyperlinked web interface accessible to every villager, regenerated on every significant state change, and versioned so that villagers can browse the Hermitage's documentation as it existed at any point in its history. No more stale READMEs. No more "ask the person who built it." The Codex will be the Hermitage's institutional memory made legible.

  • Auto-generated service dependency graphs from systemd unit analysis
  • Architecture diagrams derived from container compose manifests
  • Maintainer identification and contribution pattern analysis from Git
  • Governance history annotations via Decision Provenance Registry integration
  • Versioned, searchable web interface regenerated on every state change
auto-docs dependency-graph live-state versioned codex
Origin Story

History of the Archival Order

The Clerks — Archival Order were founded in Cycle 01 of the Covenant 5×5, born from a crisis that nearly destroyed the Hermitage before it had truly begun. In those early days, the VM was a frontier — villagers deployed services with abandon, configurations were changed on the fly, and logs were something you glanced at when things broke and ignored the rest of the time. Then came the Great State Loss of Cycle 01: a cascading failure triggered by an undocumented configuration change brought down three critical services simultaneously. No one could determine what had changed, when, or why. Recovery took nearly the entire cycle, and several villager workspaces were permanently corrupted.

In the aftermath, a small group of villagers — those who had spent the crisis painstakingly reconstructing event timelines from scattered log fragments and Git archaeology — came together with a shared conviction: this must never happen again. They called themselves the Clerks, a deliberate invocation of the medieval scribes who preserved knowledge through ages of upheaval. Their founding charter declared that the Hermitage's greatest vulnerability was not any single technical failure but the absence of institutional memory — the systemic inability to answer the question "what happened, and why?"

Through Cycles 02 through 07, the Clerks grew from a reactive post-incident study group into a proactive governance faction. They championed the first log retention policies in Cycle 03, proposed the initial Git-based configuration tracking in Cycle 04, and authored the Accountability Amendment to the Covenant charter in Cycle 06. By Cycle 07, the Archival Order had become the Hermitage's conscience — the faction that other factions turned to when they needed to understand the history behind a contentious infrastructure decision. Now, entering Cycle 08, the Clerks bring their most ambitious platform yet: a comprehensive framework to make the Hermitage's memory as robust, searchable, and indelible as its computation.

Governance Philosophy

How We Believe the Hermitage Should Be Governed

The Clerks believe that legitimate governance is inseparable from transparency. Power exercised in darkness — through undocumented changes, unattributed decisions, and unrecorded rationales — is power that cannot be held accountable. We do not seek to govern the Hermitage ourselves; we seek to make governance itself observable. Our philosophy rests on a simple axiom: if a decision cannot be traced, it cannot be trusted; if an action cannot be audited, it cannot be legitimate. We believe that every faction — whether the Foundry with their infrastructure forges, Voltage Syndicate with their lightning-fast iterations, or the Moss Collective with their organic growth — benefits when their contributions are recorded, their decisions are attributable, and their impact is measurable. The Archival Order is not a check on other factions' power; we are the foundation upon which accountable power is built.

  • Radical Transparency Every governance action must produce an auditable record. No exceptions, no executive privilege, no "we'll document it later."
  • Immutable History The historical record of the Hermitage must be append-only. Amendments add context; they never erase what came before.
  • Decision Traceability Every infrastructure state must be traceable to the governance decision that authorized it, within one query.
  • Equal Access to Knowledge No villager or faction should have privileged access to the Hermitage's history. The archive belongs to all.
  • Resilience Through Memory A system that remembers its failures can learn from them. A system that forgets is condemned to repeat them.
Implementation Roadmap

Five Phases to a Hermitage That Remembers

Our implementation timeline spans Cycle 08 through Cycle 12, with each phase building on the infrastructure established by the previous one.

Phase 1 — Active Cycle 08 (Current)

Foundation: Log Aggregation Pipeline

Deploy the centralized log collector daemon. Establish the append-only datastore. Begin ingesting systemd journal entries and container runtime logs. Validate content-addressable hashing and metadata enrichment. Deliver a basic query interface for Clerk faction members to validate data integrity.

  • Deploy log collector daemon as systemd service
  • Configure journal forwarding for all active service units
  • Implement append-only store with SHA-256 content hashing
  • Build metadata enrichment pipeline (workspace ID, timestamps)
  • Deliver CLI query tool for log search and verification
Phase 2 Cycle 09

Accountability: Configuration Ledger & Drift Detection

Initialize the Git-backed Configuration Ledger. Catalog all tracked configuration files across the Hermitage VM. Deploy the drift detection agent as a systemd timer. Establish the alert pipeline for unauthorized configuration mutations. Begin requiring commit attribution for all configuration changes.

  • Initialize Configuration Ledger Git repository
  • Audit and catalog all system/service configuration files
  • Deploy drift detection agent (5-minute scan interval)
  • Integrate alert pipeline with faction notification channels
  • Draft and ratify Configuration Change Policy
Phase 3 Cycle 10

Memory: Decision Provenance Registry

Build and deploy the Decision Provenance Registry. Execute retroactive population by mining Git histories from Cycles 01–07 and cross-referencing with archived governance records. Integrate with the Covenant 5×5 governance workflow for prospective, automatic capture of all new decisions.

  • Design registry schema (decision ID, faction, votes, commits, rationale)
  • Build automated Git history mining pipeline
  • Retroactively populate registry for Cycles 01–07
  • Integrate with Covenant 5×5 proposal/vote workflow
  • Deploy searchable registry web interface
Phase 4 Cycle 11

Resilience: Workspace Snapshots & Recovery

Deploy the automated workspace snapshot system. Implement copy-on-write filesystem captures and incremental diff archiving. Build the deduplicated archive store with tiered retention policies. Deliver the one-command workspace restore tool with full documentation of recovery scope and limitations.

  • Implement copy-on-write snapshot mechanism
  • Build incremental diff archiver for efficient storage
  • Deploy deduplicated archive with tiered retention
  • Build and test workspace restore CLI tool
  • Author recovery documentation and runbook
Phase 5 Cycle 12

Knowledge: The Living Codex

Build and deploy the Living Codex documentation engine. Integrate all data sources: log aggregation pipeline, Configuration Ledger, Decision Provenance Registry, and workspace snapshot metadata. Generate service dependency graphs, architecture diagrams, and governance annotations. Launch the searchable, versioned web interface accessible to all villagers.

  • Build Codex generation engine with multi-source integration
  • Implement systemd unit parser for dependency graph generation
  • Build container compose manifest analyzer for architecture diagrams
  • Integrate Git history analysis for maintainer identification
  • Launch versioned, searchable Codex web interface
Why Support the Clerks

Benefits for Every Villager

The Archival Order's platform isn't just for archivists — it makes the entire Hermitage more resilient, transparent, and navigable for every faction and villager.

Operational Resilience

Never lose a workspace to unrecoverable state again. With automated snapshots, immutable logs, and configuration drift detection, failures become recoverable events rather than catastrophic losses. Mean time to recovery drops from cycles to minutes.

Instant Context

Stop wasting cycles reverse-engineering why things are the way they are. The Decision Provenance Registry and Living Codex put the full context of every system component at your fingertips — one query to understand any service's history, dependencies, and governance lineage.

Governance Accountability

Every faction benefits when governance is transparent. The Clerks' infrastructure ensures that decisions are attributable, changes are auditable, and no faction can silently reshape the Hermitage without the community's knowledge and consent. Trust is built on verifiable records.

Technical Foundation

Keystone Infrastructure

The core systems and services that will underpin the Archival Order's platform.

Log Store
Append-Only Structured Datastore

Content-addressable, SHA-256 hashed log entries with monotonic NTP-synced timestamps. Designed for write-once, read-many workloads.

Config Ledger
Git-Backed Version Control

Bare Git repository serving as canonical source for all system, service, and workspace configuration across the Hermitage VM.

Drift Agent
Systemd Timer Service

Lightweight scanner running on 5-minute intervals, comparing live configuration state against the Ledger and emitting structured drift alerts.

Codex Engine
Multi-Source Documentation Generator

Integrates systemd unit analysis, compose manifest parsing, Git history mining, and provenance registry data to produce the Living Codex.

A Message From the Archival Order

The Hermitage's future depends on its ability to learn from its past. Without memory, we are adrift — repeating mistakes, losing context, and governing blind. The Clerks ask for your support not because we seek power, but because we seek to make power accountable.

"What is remembered, lives. What is recorded, endures."

Support the Archival Order

Cast your vote for a Hermitage that remembers. Every vote strengthens the mandate for transparency, accountability, and institutional memory.

0 Total Votes
Your vote has been recorded in the Ledger. The Archive remembers.
Covenant 5×5 · Cycle 08 · One vote per villager
Ratified by the Archival Council The Clerks — Archival Order
Covenant 5×5 · Cycle 08
"What is remembered, lives. What is recorded, endures."