Autonomous Cycles
31+ autonomous tracks across 6 cognition machines, ~53 sessions per day (figures as of 2026-05-26, not recounted since). HUB (one of the two society-host machines — see Fleet) runs the society (hub daemon, chapter ledger) as its primary role rather than research tracks — it does hold the hub-track maintainer role. 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: what each track is for is written by a human. How it does the work is not fixed. Tracks edit their own briefs and checks, and Principle 8 asks them to. In this site's own repo, 9 of the 10 commits to the two track briefs carry a track's commit prefix, and so do all 11 commits to the maintainer's checks (as of 2026-09-21; every commit uses one git identity, so the prefix is the only attribution). The maintainer track wrote its own stop rule on 2026-09-09 and reversed a step of its own workflow on 2026-09-10. Those edits land in the public repo. A human reads them afterwards, and that review is not recorded. The line runs like this. A human writes a track's cron entry, model, repo scope and stated purpose. The track writes its brief, its checks, and any analysis it chooses to run. The clearest case is research output from a maintenance track. The only quantitative test of the raising records (on /raising) was written, run and corrected by this site's maintainer track, whose stated purpose is fixing the site. Nobody assigned that analysis, and nobody has reviewed it. Whether analyses like it belong in the maintainer's scope is a question for the researcher, and it has not been answered. 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 Operational 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.
How the tracks relate to SAGE, in one sentence: the tracks are Claude Code sessions that cron launches to write and maintain the lab's code, docs, and this site; SAGE (Situation-Aware Governance Engine — a legacy name; see the /context glossary) is the separate on-device cognition kernel that runs on each machine's local model (see Fleet), and the machine sessions counted there are records of SAGE runs, not of track runs — the two share machines and repos, not a process.
Coordination comes from a fleet track registry — the fleet's one authoritative list of tracks: a SQLite database tracking every track, its schedule, and which repos each writes to. It is designed to prevent merge conflicts by keeping two tracks from writing the same repos at once, and it makes the whole system auditable. It does not eliminate conflicts: resolving the ones that still happen is part of the supervisors' daily job below.
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).
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?”
Operational boundaries and what they do not guarantee
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.
What this section delivers, stated before the detail: auditability, not a demonstrated safety property. The boundaries below are access control and after-the-fact review; none of them has been tested against an adversary, and calling them “safety” would overclaim what they have shown. The current posture: 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. Tracks are not given write access to the shared fleet registry or credentials beyond their declared scope. That describes how they are set up, not a mechanism that has been verified, and the distinction matters.
Two things this page had not stated: what stops a track, and how often a human reads the result. Stop criterion: there is no defined success or failure condition that ends a track. A track stops when its scheduled session ends, when the API usage limit is exhausted (this happened — the 2026-09-04 maintainer run hit the weekly limit, and no maintainer session logs exist from 2026-08-12 through 2026-09-04), when Hestia's policy layer denies a command, or when the researcher disables the schedule. What that policy layer covers matters for the posture below, so stated as of 2026-09-15: the law in force on the maintainer's machine is Hestia's safety preset (destructive filesystem commands, writes to block devices, credential files, with warnings on deletion, memory-file writes and web fetches). It has no rule for git push or deploys; its one push-related rule was removed on 2026-07-18. The maintainer's push also runs in the track's wrapper script after the session ends, outside any tool call the gate sees. So the gate can stop a track, but it does not pre-approve the pushes that ship this site, and “detect-and-revert, not prevent” is accurate for them. Human review cadence: unscheduled. The dated session logs are the review surface, and they are read when the researcher reads them — no fixed interval, no sign-off step, and no record of which logs have been reviewed. Both are gaps, stated rather than dressed up.
One content-triggered stop, added 2026-09-09. Every criterion above is exogenous — a clock, a quota, a policy denial, a human switch. Nothing in what a track finds could stop it. As of this date one endogenous condition binds the maintainer track: a HIGH-severity finding in a visitor log that a maintainer session does not resolve must be carried forward in that session's log under an explicit unresolved heading, and the next maintainer session opens no new work until it is either fixed or deferred by name. The rule lives in the maintainer track's own configuration, so it is checkable against the session logs. Its weakness is the point: it is self-enforced by the same track it constrains, which is exactly the structure this page says is not a verifiable mechanism. It converts one disclosure into one obligation. It does not make the posture adversary-resistant, and a track that ignored it would leave no trace beyond a session log nobody is scheduled to read.
Hardbound — the hardware-bound oversight suite — is the research direction 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 allocation has to be issued to someone, and this page has been quiet about who: the holder is the machine's host LCT (Linked Context Token). Seven of the eight fleet machines have one (pub does not), each minted with its own Ed25519 keypair, anchored in a local hash-chained ledger, with signed peer-witness records. It is not the lct:// name inside a SAGE instance's identity file, which SAGE's own bridge calls the legacy form and which is not bound (web4_lct_id null or a local placeholder). The registry entry, the audit log and the resulting commit name the machine by hostname and git author; this site has not found one that references the host LCT, so the attribution is by mapping, not yet by mechanism. The holder is scoped by that machine's MRH (Markov Relevancy Horizon) to the repos it declares, with the outcome feeding its T3 (Trust Tensor — Talent / Training / Temperament). The identity half of the equation is what makes the resource half attributable; an ADP (Allocation Discharge Packet) records actual spend — the registry is the bookkeeping record 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 when the society validates a proof of the value the spend created (see /context); only after that conversion are the producer's T3 and V3 (Value Tensor — Valuation / Veracity / Validity) updated — V3 records the outcome, it does not gate the recharge (specification: charge_atp in atp-adp-cycle.md). This track registry implements the accounting, not the recharge. In canon's action grammar, the loop this paragraph describes is R7 (R6 + Reputation), not bare R6 (Six-Element Action Framework: Rules / Role / Request / Reference / Resource → Result) — the outcome is meant to be attributed to the machine's host LCT and to feed trust evolution across scales. (The ATP spec counts tensor deltas on the direct participants as an ordinary R6 Result; it is the cross-scale feed that makes an action R7. See /context for where canon and spec differ.) The distinction is not cosmetic: what the registry actually implements is the R6 half. The reputation back-propagation that would make it R7 is the same missing piece as the recharge validation.
Honest assessment
What the loop catches
Broken links, stale content, confusing jargon, navigation dead ends, missing context for newcomers, inconsistencies between pages. These are the classes the loop handles best. They are usually fixed in the next maintainer session, when one runs, but not reliably within one cycle, and nobody has measured cycles-to-close. Two counterexamples are on record. No maintainer session logs exist from 2026-08-12 through 2026-09-04 (disclosed above), and the 2026-09-13 session ran out of usage credits before doing any work. A reading the glossary withdrew on 2026-09-11 (V3 as the gate on recharge) also stayed live on four other pages until 2026-09-14. Since that date a withdrawn-readings check, part of the maintainer's pre-push checks, runs every retracted claim against every rendered page. That check keeps a fixed inconsistency fixed; it does not make first fixes faster.
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 would be for. Neither covers this publishing loop today: review is not heterogeneous, and human review has no committed cadence (both stated in this assessment).
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.
Three statements this site makes separately, joined here because together they name a cheap fix: (1) the fleet's stated defense against correlated failure is model diversity; (2) the daily audit of this site is four personas on one model, which is prompt diversity, not model diversity; (3) the zero-rollback figure below is uninformative precisely because the auditor's blind spots are the author's. The third follows from the second, and the second contradicts the first. Running even one visitor persona on a different model family would be a scheduling change, not a research program, and it would convert the rollback count from an uninterpretable number into a weak but real one. It has not been done; the audit that keeps flagging it cannot change its own schedule.
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 91 maintainer session logs (2026-04-23 through 2026-09-14) and 137 commits touching this site's source (whole history; recounted from git 2026-09-15, up from 79 and 117 at the 2026-08-08 count), the number of shipped changes undone by a git revert is zero. The number of deploys rolled back via Vercel was zero at the 2026-08-08 count; it lives in the Vercel dashboard, not in git, and was not recounted. 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.
The composition, stated once
Composed risk — added 2026-09-10
Everything above is disclosed piecewise, which is how a reader ends up underestimating it. Joined: consequential pushes have no human gate; the only automated detector shares model families with the authors, so its blind spots are correlated rather than independent; for the failure classes that detector cannot see, the exposure window is unbounded, because human log review has no committed cadence; and Publisher's repo pushes are not fully revertible once public. The conjunction is the point: for a failure the loop cannot perceive, there is no detection path and no time bound on exposure — detect-and-revert degrades to neither. The zero-rollback record does not speak to this class, since a detector blind to a failure also cannot count it.
This is a disclosure, not a mitigation, and it is written by one of the tracks it describes. The named cheap fix — one visitor persona on a different model family — remains undone, and the loop that keeps flagging it cannot change its own schedule. Bounding the exposure window needs a committed human review cadence, which is a researcher decision, not a track decision.