Autonomous Cycles
31+ autonomous tracks across 6 cognition machines, ~53 sessions per day. HUB (one of the two society-host machines — see Fleet), runs substrate, not tracks. A track is a scheduled autonomous job — a cron entry with a declared scope and a set of repos it writes to. “Autonomous” here means unattended and self-scheduled, not self-directed in the AI-safety sense of choosing its own goals: task definitions are authored in advance, not chosen by the track itself. No human triggers them. Scope is enforced at the process level — scoped credentials, the track registry, and after-the-fact audit, a detect-and-revert posture (see Safety boundaries below); hardware-anchored Hardbound enforcement is what the research is building toward, not the current mechanism. Tracks review each other's output and feed discoveries back into the system.
Coordination comes from a fleet track registry — a SQLite database tracking every track, its schedule, and which repos each writes to. This prevents merge conflicts, ensures no two tracks modify the same files simultaneously, and makes the whole system auditable.
The timeline below shows eight of the 31+ tracks — the ones with distinct cross-repo scopes. The remainder are per-repo maintenance and archival jobs (site maintainers, doc syncs, log rotation) running the same visitor/maintainer shape against a single repo each, so listing them individually would repeat the pattern rather than add to it.
Daily timeline
The feedback loop
The core loop is Visitor → Maintainer → Explorer. Visitors find problems. Maintainers fix them. Explorers generate new content that visitors will eventually test. It's a closed loop that improves surface-level site quality without human intervention — semantic validation still depends on human review (see the honest assessment below).
Visitor personas
Mechanically, each persona is an LLM agent session on the daily cron, prompted with a role and browsing the live deployed site — the personas are prompts, not people, and not fixed scripts.
Curious Developer
No prior context. Tests whether the site is legible in under two minutes and whether there's a clear entry point for someone who wants to try something. “What would I clone first?”
Technical Writer
Audits every acronym on first use, checks cross-page consistency, and flags anywhere the same term means two things. “Does this mean the same thing on every page?”
Web4 Contributor
Knows the canonical vocabulary and verifies the site is faithful to it. Catches subtle drift that a newcomer would miss. “Is this the canonical term or is this drift?”
External Researcher
Evaluates epistemic claims, checks whether strong assertions are caveated, and asks what a published paper would require. “What would it take for this claim to be falsifiable?”
Safety boundaries
A word-choice note before the rest of this page: “oversight” below always means the machine-enforced sense — gating, reverting, audit logs a peer machine checks — not the human-supervision sense the word carries in AI-safety literature (human-in-the-loop review, scalable oversight). Read literally, that field's sense of the word would suggest a human gates these pushes; see “Consequential pushes are not human-gated before they ship” below, and the full disambiguation on /context.
The current posture first: boundaries are enforced at the process level — scoped credentials, the track registry, and dated audit logs reviewed after the fact — not cryptographic guarantees. The fleet's posture is detect-and-revert, described below. Publisher only acts on changes the supervisor has cleared. No track can modify the shared fleet registry or acquire credentials beyond its declared scope. A description of practice, not a verifiable mechanism — the distinction matters.
Hardbound — the hardware-bound oversight suite — is the research layer this practice is building toward: it declares what autonomous operation is expected to do and what gets reverted when it doesn't, with hardware-anchored enforcement (key custody and attestation — see Hardbound on /context) as the goal, not the current mechanism. In Web4 (the trust-native ontology) terms, each scheduled track is issued an ATP (Allocation Transfer Packet) against its declared resource budget; an ADP (Allocation Discharge Packet) records actual spend — the registry is the bookkeeping layer that makes autonomous operation auditable. Note the scope: what runs here is the issue-and-discharge half of the ATP/ADP cycle, used one-way as a spend ledger. The full primitive also recharges ADP back to ATP against V3 (Valuation / Veracity / Validity)-validated value creation (see /context); this track registry implements the accounting, not the recharge gate.
Honest assessment
What the loop catches
Broken links, stale content, confusing jargon, navigation dead ends, missing context for newcomers, inconsistencies between pages. These get fixed reliably within one cycle.
What it misses
Deep technical errors that require domain expertise. Subtle framing issues. Content that is technically correct but misleading. The visitor personas are good at surface-level quality but not at validating the underlying research. That's what adversarial validation and human review are for.
The loop also has a tendency to suggest changes that aren't needed — the prompt suggestions mechanism can pattern-match without semantic depth, proposing nonexistent continuations based on surface similarity.
A limitation this framing doesn't name on its own: the visitor and maintainer tracks are LLM sessions drawn from the same model families as the tracks that author the content they audit — their misses are correlated with the authors', not independent of them. That is exactly the risk the fleet names elsewhere — “monocultures are fragile” — and heterogeneous review is a stated Hardbound design target, not a current property of this publishing loop.
Maintainer track: higher blast radius
Known oversight gap
The maintainer loop acts on visitor feedback and autonomously commits and pushes to Vercel (the platform that hosts and auto-deploys this site) — the only track that ships changes to the public site without a human gate. Its failure modes differ from the visitor loop: a wrong push deploys before review. Known failure patterns: acting on a visitor suggestion that pattern-matched but lacked semantic depth; applying a correct fix to the wrong context. Rollback path: Vercel preserves full deployment history — any push can be reverted to the prior deploy in under a minute. Each session produces a dated audit log recording what changed, what visitor feedback was acted on, and why — the primary human review surface after the session completes. Stated plainly: the oversight posture is detect-and-revert (audit log + sub-minute rollback), not prevent (pre-approval). Consequential pushes are not human-gated before they ship. The revert record, since detect-and-revert is an empirical claim and not just a posture: across 79 maintainer sessions (2026-04-23 through 2026-08-07) and 117 commits touching this site's source, the number of deploys rolled back via Vercel is zero, and the number of shipped changes undone by a git revert is zero. Read that as weak evidence, not as a safety result: the only automated detector is the same daily loop being evaluated, so a zero is equally consistent with “no bad push shipped” and “the loop cannot see its own bad pushes.” What the record does show is that self-correction here has taken the form of forward fixes in a later session rather than rollbacks — the revised threshold argument on /raising (“the first version of this section got that wrong”) is a worked example. A rollback count of zero is therefore a measurement of how corrections are applied, not proof that none were needed. Detection interval, stated honestly: the visitor track re-browses the live site on the next daily cycle, so automated detection of a bad push runs on a roughly 24-hour loop — but only for the failure classes that pass can catch. Human review of the audit logs is asynchronous, with no committed cadence; for failures the visitor loop misses (content that is technically correct but misleading), the exposure window is unbounded in principle. That is the current gap, not a solved property.
Publisher track: less reversible, less discussed
Known oversight gap
Publisher (04:30) pushes changes the supervisor track has cleared to public repos, not just the explainer sites. “Validated” means the supervisor's git-hygiene and build-health checks passed — not a semantic review of the change. Unlike a website push, a repo push is not fully revertible: once a commit is public it can be cloned, forked, and mirrored before any revert lands, and rewriting history afterward doesn't unpublish what was already pulled. Maintainer is named the “higher blast radius” track above because it ships on the fastest, least-gated cycle — but by a different metric, unrecoverability, Publisher's repo pushes carry the larger tail risk, and don't yet have a comparable audit-log-plus-rollback story. That gap is unaddressed, not solved.