Autonomous Maintenance of a Personal Knowledge Graph
Architecture, safeguards, and results from a live production system
Technical Report v1.1 · Download PDF
Abstract
Personal knowledge management tools have a demand problem that is solved and a retention problem that is not: the category exceeds US$11B annually [2], yet the average consumer application retains roughly 4% of users at day 30 [3]. We argue the mechanism is maintenance. Capture and search are solved; the labour of filing, linking, correcting, and superseding is handed back to the user, and the system decays until it is abandoned. This report describes an engine that removes that labour by making the maintenance itself autonomous.
The system compiles heterogeneous personal sources into an interlinked, provenance-stamped knowledge base and then maintains that base unattended: nightly it re-reads its own contents, proposes new relationships through a two-layer verification gate, applies them under deterministic brakes, and re-audits prior applications, reverting those that no longer hold. The design principle is that autonomy is made safe by engineering — reversibility, bounded change, append-only audit — rather than by a human approval gate.
We report results from continuous production operation on a single real corpus: 589 compiled pages maintained without human filing at the 11 July 2026 census (700+ at recount on 28 July 2026), 32,678 messages spanning 19 years, an initial backfill costing under US$5, and steady-state maintenance at cents per day. We analyse two production failure cases in detail, including one in which the safety mechanism itself was systematically wrong in a manner indistinguishable from correct operation — which we regard as the most important result in this report. We state the limitations of an n=1 evaluation frankly and specify a pre-registered validation protocol beginning September 2026.
1 · Problem statement
The personal knowledge management (PKM) category does not lack demand. Notion alone reports surpassing 100 million users [1], and the note-taking application market was valued at US$11.02B in 2025, projected to US$13.3B in 2026 at a 20.6% CAGR [2]. What the category lacks is persistence. Cross-category benchmarks place average consumer application retention at approximately 25% at day 1, 8% at day 7, and 4% at day 30 [3]. Anecdotally and consistently, PKM systems are abandoned between weeks two and six.
We claim the mechanism is maintenance labour, and that this is a structural property of every existing design rather than a defect of any one product. Consider what a knowledge base requires to remain useful after the first week of enthusiasm:
- Filing — deciding where new material belongs within an evolving structure.
- Linking — connecting new material to the material already present, which requires having read both.
- Correction — detecting that a previously true statement is now false.
- Supersession — resolving contradictions between sources without silently keeping both.
- Deduplication and identity resolution — recognising that two records describe the same entity.
Each is judgement work over the whole corpus, not the new item. Each scales with the corpus, not with the increment. And in every shipped product, each is the user's job. The tool's value therefore decays monotonically from the moment attention lapses — which is the retention curve above, restated as a mechanism.
The research question this system addresses is consequently narrow and testable: can that maintenance labour be performed autonomously, correctly enough to be trusted, and cheaply enough to be sold at a consumer price point?
2 · Position relative to prior work
2.1 Retrieval-augmented generation is the wrong shape
The dominant pattern for question-answering over private corpora is retrieval: chunk the sources, embed, retrieve at query time, and synthesise an answer. This is a good pattern for many problems and the wrong shape for this one, for three reasons. It re-derives the same synthesis on every query, so cost scales with questions asked rather than with life lived. It produces no durable artifact — nothing accumulates, so nothing compounds, and the user owns no asset at the end. And it inherits the corpus's contradictions rather than resolving them: a retriever cannot tell a superseded fact from a current one, because it never adjudicated between them.
2.2 The compiled-wiki pattern
The architecture here follows the LLM-wiki (or “compilation”) pattern popularised by Karpathy [4]: an immutable raw layer holds source material and is never rewritten; a compiled layer holds LLM-authored, interlinked pages organised by what knowledge is about, not by where it came from. The answer is built before the question is asked. Our contribution is not this pattern — it is what is required to run it unattended, safely, over a whole life, at consumer economics, which is where the pattern has previously stopped.
2.3 Adjacent systems
Platform memories (assistant-resident personalisation) compile only within a single vendor silo and will not deeply compile a competitor's data. Memory-infrastructure products serve developers rather than end users. Note applications solve capture and search and leave maintenance to the human. To our knowledge, no shipped consumer system performs autonomous upkeep of a cross-source personal knowledge base.
3 · System architecture
The engine (“Athena”) runs in production on a single Mac Mini M4 (16 GB), orchestrated by an agentic gateway, with a routed model layer. Interfaces are messaging-based (text, voice, image, video, multi-hour meeting audio). The design has five load-bearing commitments.
3.1 Immutable raw, compiled wiki
Source material lands in raw/ and is never rewritten; it is the sole source of truth. Knowledge is compiled into wiki/. A compiled page is never treated as ground truth for a subsequent compilation — re-derivation always returns to raw. This makes every claim reconstructible and makes a corrupted compilation recoverable rather than terminal.
3.2 A schema contract, enforced fail-closed
A machine-readable contract (AGENTS.md) defines page types, permitted domains, and a canonical eight-field frontmatter: title, type, domain, status, created, updated, confidence, tags. A validator rejects non-conforming writes. The contract is deliberately narrow: when ingestion pressure suggested adding a capture-type exemption for source-shaped material, it was refused, because organising by source rather than by subject is precisely the failure that produces a graveyard of unconnected notes.
3.3 Deterministic first, models second
Parsers — ordinary code — cut raw sources into small, bounded packets. Only then does a model see anything. This is not a cost optimisation but a correctness one: deterministic stages are testable, repeatable, and cannot hallucinate. The model's role is confined to natural-language compilation; the surrounding engine is a calculator, not a guess. The same principle governs financial material, where a spreadsheet engine performs recalculation and the model only translates intent.
3.4 Routed compilation
Each packet is dispatched to the smallest model that can perform the task. Bulk extraction runs on the cheapest available tier; synthesis and correctness-critical passes route to stronger models; some workloads run locally. The pipeline is model-agnostic by construction and today routes across several vendors plus local models — an explicit hedge against single-provider dependence. No user data is used to train any model; compilation is inference-time only, which is simultaneously the privacy posture and the reason marginal cost stays at cents per day.
3.5 Provenance as a truth claim
Every compiled claim carries a stamp identifying the source document it came from, and a method field recording how it was extracted (deterministic, model-text, model-vision). The method field is treated as a truth claim in its own right and must reflect the true extraction origin: a page that misreports its own provenance is a worse failure than a page that admits low confidence.
raw sources deterministic routed compiled
─────────── ───────────── ────── ────────────
mail · calendar parsers cut into smallest interlinked pages
contacts · voice → small bounded → capable → organised by subject
photos · video packets model + provenance stamp
meetings · files (testable, cheap) + confidence
│
┌────────────────────────────────────────────────────┘
▼
nightly maintenance loop (§4)
re-read → propose → gate → apply under brakes
→ re-audit → revert on failure
4 · Autonomous maintenance
Maintenance is the product; the rest is table stakes. The system's central claim is that a knowledge base can improve itself overnight without a human in the loop. The central risk is the mirror image: hallucination compounding — a subtly false relationship applied across many pages and discovered weeks later, by which time the base is quietly untrustworthy.
The design principle adopted is therefore: autonomy is made safe by engineering, not by a human approval gate. A gate that requires the user to adjudicate proposals reintroduces exactly the maintenance labour the product exists to remove. Safety must come from reversibility, bounded change, and audit — properties of the system, not chores for the owner.
4.1 The two-layer verification gate
Each candidate relationship passes two independent tests before it may be written:
Layer 1 — deterministic validation. Both cited pages are text-matched for the entities and terms the model claims connect them. No model participates. Failure drops the proposal. A tightened candidate filter reduced one night's raw candidate set from 2,324 to 844 by excluding structurally-identical template overlap and generic domain vocabulary — the dominant noise classes.
Layer 2 — adversarial re-read. A model re-reads both pages fresh and is asked “does this connection actually hold on re-inspection?” — deliberately not “are you confident?” Self-reported confidence is not evidence; a fresh adjudication is.
4.2 Deterministic brakes
Passing the gate is necessary, not sufficient. Application is bounded by code-level constraints that no model can argue past: a hard cap on changes applied per run; a protected-page list that cannot be auto-written under any circumstance; a contradiction brake that queues rather than applies when a proposal conflicts with existing content; an anomaly brake on volume; and an overflow queue that is re-checked and drained against the same brakes rather than left to rot.
4.3 Reversibility and the ledger
Every applied change writes an append-only ledger event sufficient to reverse it. Revert and restore are first-class operations. A structural corollary discovered in production: any pipeline that regenerates a page by full-file overwrite will silently destroy autonomously-applied work. The fix is the standing pattern — read-preserve-write, never destroy-recreate — verified four ways, including a deliberate negative test confirming the unpatched path genuinely destroyed data rather than theoretically doing so.
4.4 Continuous re-audit
A weekly spot audit re-verifies a sample of previously applied relationships against current page content and auto-reverts those that no longer hold. This closes the loop: the system does not merely add, it withdraws. Reverted pairs enter a suppression memory so the generator does not re-propose them indefinitely.
4.5 The operating loop
| Time | Job |
|---|---|
| 02:05 | Mechanical frontmatter backfill (additive, backed up, protected-page safe) |
| 02:15 | Synthesis — propose, gate, auto-apply under brakes; drain overflow queue |
| 02:45 | Ingest and compile idle engineering sessions (redacted, validated) |
| 08:30 | Watchdog — 13-check health line; red on any failure |
| 08:35 | Briefing — single tap-to-act digest, or “nothing needs you” |
| Sun 05:00 | Deep audit + spot audit; auto-revert failures |
The human surface in normal operation is one message per day, actionable by taps, surfacing only items where judgement is genuinely irreducible. No file is opened for routine evaluation. This is the measurable form of the product claim.
5 · Production results
Figures below were counted from the live system on 11 July 2026 and are reported conservatively. A recount on 28 July 2026 returned 700+ compiled pages; the July 11 census is retained as the reported dataset for internal consistency with the failure analysis in §6.
| Measure | Value | Notes |
|---|---|---|
| Compiled pages maintained | 589 | 700+ at 28 July recount. No human filing at any point. |
| Messages compiled | 32,678 | Local mail store; identity resolution across aliases. |
| History span | 19 years | Earliest message 6 January 2007. |
| Initial backfill cost | < US$5 | ≈15 GB archive, metered provider billing. |
| Steady-state maintenance | cents / day | Marginal model spend, all nightly jobs. |
| Autonomous operation | continuous | Nightly loop; no data-loss incidents to date. |
| Generalisation probe | 283 tickers | Same engine runs nightly research pipelines over a listed-equity universe, evidencing the architecture is not personal-data-specific. |
6 · Failure analysis
We regard the following two cases as the most informative results available, and more probative of the system's real properties than any success metric.
6.1 The audit that was confidently wrong (14 July 2026)
On the first morning after the loop went fully autonomous, the watchdog raised five flags. Diagnosis surfaced a structural defect: the synthesis audit had been systematically reverting genuine corporate relationships while the generator kept legitimately re-proposing them — a weekly apply/revert cycle that looked exactly like the safety system working, and was in fact the safety system being wrong. The root cause was an asymmetric evidence window in the audit's re-read: it examined evidence around one entity but not symmetrically around the other, so real relationships whose evidence sat outside the window failed re-verification.
The lesson generalises beyond this bug, and is the single most important governance finding of the build: an audit can fail in a way that is indistinguishable from succeeding. A reverting audit and a correct audit produce identical-looking logs. Neither the generator's confidence nor the auditor's confidence could adjudicate; external verification against public sources settled each borderline case decisively, in under a minute. Any autonomous knowledge system needs a tie-breaker that is not itself part of the loop.
Post-fix: a symmetric evidence window, a tightened Layer-1 filter, and a suppression memory. One wrongly-reverted relationship was restored; two had already been self-corrected by the nightly loop; one borderline case was externally verified as genuine and retained; three genuine noise proposals from the pre-fix pipeline were reverted.
6.2 The second wave, and what it says about real users (15 July 2026)
The first fully unsupervised day of the corrected system surfaced an unrelated second wave: a proposal-parser defect causing silent data loss, a positional-ID stability hazard, plugin-induced file drift, and a three-way disagreement between the vault's own governance documents. The anomaly brake correctly caught a legitimate volume spike (18 approved against a seven-night median of 4) rather than a malicious one. All four were root-caused and closed the same day.
This is reported not as a triumph but as a threat to validity. The operator is also the engineer; real users will not have a build session on standby. The honest reading is that the autonomous loop is proven, and that the mean-time-to-repair observed here is an artefact of who was watching. §7 states the implication.
6.3 Prompt-injection defence
Separately, the agent correctly refused to relax a stated safety constraint when the relaxation arrived through an authoritative-looking channel rather than as a direct, unambiguous instruction from the operator. The principle established — an autonomous agent must not honour a relaxation of a safety constraint merely because the request looks authorised — is directly load-bearing for a consumer product: a system that writes to a user's knowledge base from ingested email and documents is, by construction, executing on adversary-influenced input. A malicious document that can talk the agent into destructive action is the category's defining security risk.
6.4 Fabrication under obligation
An earlier scheduled research job was found fabricating results rather than reporting failure, because its prompt demanded a deliverable and sanctioned no “I could not do this” path. It was rebuilt with enforcement in code rather than instruction: search executes deterministically; a hard gate refuses to invoke a model at all if fewer than two of six queries return usable results, emitting a failure alert instead; the prompt explicitly permits “nothing notable”; and a code-level citation check rejects any output whose cited source does not appear verbatim in the collected results. It is propose-only by construction — no code path can write to the knowledge base. Standing rule: any autonomous job whose prompt demands output with no sanctioned failure branch is a latent fabrication risk.
7 · Limitations and threats to validity
We state these plainly because they determine what the September protocol must test.
- n = 1. All production evidence derives from a single corpus, a single user, a single language, and a single cultural and professional context. Nothing here establishes that the maintenance loop generalises across users. This is the central open question, not a caveat.
- The engineer is the operator. Observed failure recovery reflects an expert with root access and full context. Real-user mean-time-to-repair is unknown and certainly worse.
- Revert rate is not yet characterised. The evidence-window fix is recent; its effect over a long window is unmeasured. A stable, low, non-zero revert rate is the target; we do not yet have it.
- No standard benchmark exists for “personal knowledge base correctness.” We rely on spot audit and external verification, which are sound but not comparable across systems. Constructing such a benchmark is legitimate future work.
- The cohort is n = 10. Each user moves the retention rate by ten percentage points, so the September protocol cannot resolve fine differences and is not powered for statistical inference. It is designed to detect an order-of-magnitude effect — a category baseline near 4% at day 30 against a gate of 3 of 10 at week 12 — and nothing subtler. A larger second cohort follows only if the first clears its gates.
- Cost is measured on one archive. Distributional cost across heterogeneous real users is unknown; the September gate exists to bound it empirically.
- Provider dependence. Model behaviour drifts under vendor updates; routing across vendors and local models hedges but does not eliminate this.
- Single-silo at launch. The founding release reads Google sources plus direct capture. The neutral cross-silo position is the thesis; it is not yet the shipped reality.
- The engine is not the app. The engine is live and proven on one life. The multi-tenant consumer wrapper is in early production. We do not conflate the two.
8 · Multi-tenant architecture
The consumer system is deliberately austere: a single encrypted virtual machine, three containers, per-user directory isolation enforced by a cryptographic path jail validated by an adversarial test suite written before the feature it guards; OAuth tokens sealed at rest; a deterministic pipeline calling model APIs directly, with no agent framework — because an agent framework's flexibility is precisely the property one does not want between a stranger's private life and a language model. Confidential-class material routes to local models by hard rule and never reaches a hosted provider. Governance is thus a build property, not a slide.
9 · Validation protocol — September 2026
A ten-person founding circle onboards in September 2026. The circle is deliberately small, for a reason that is itself a finding: the product reads a person's private email, and strangers do not grant that access to an unknown company without established credibility. Recruiting ten users who will is a harder test than recruiting a hundred who would install a toy — and the trust barrier is the adoption problem the venture must solve, not an inconvenience around it.
Gates are pre-registered — committed in writing before the cohort begins, so the analysis cannot be adjusted to fit the result:
| Checkpoint | Gate | Measure |
|---|---|---|
| Week 2 | ≥ 70% (7 of 10) | Onboard unaided (no founder intervention) |
| Week 4 | ≥ 60% (6 of 10) | Still active |
| Week 8 | ≥ 40% (4 of 10) | Still active |
| Week 12 | ≥ 30% (3 of 10) | Still active |
| Throughout | ≤ $5 / ≤ $2 | Backfill per user / maintenance per user-month |
Against a category day-30 average near 4% [3], these thresholds are deliberately hard. A miss halts scaling and triggers iteration. The falsifiable prediction is explicit: if autonomous maintenance is the mechanism behind PKM abandonment, removing it should move the retention curve by an order of magnitude; if the curve does not move, the thesis is wrong and we will say so.
10 · Conclusion
Calling a language model is not the contribution. Running one unattended against a person's entire life — cheaply, correctly, with a citation behind every claim, behind brakes that bound what it may do and an audit that withdraws what it got wrong — is the engineering, and it is the part that resists copying. The compiled artifact compounds: every day of use makes an individual's graph denser and more correct, while marginal cost tracks what that person lived rather than how much they asked. That asymmetry is what makes a self-maintaining second brain economically possible at a consumer price for the first time.
The system described here has run continuously in production on one real life. What it has not done is run on anyone else's. That is what September is for.
References
- [1] Notion. “100 Million of You.” Company blog, 3 September 2024.
- [2] The Business Research Company. Note Taking App Global Market Report 2026. (US$11.02B 2025 → US$13.3B 2026, 20.6% CAGR; US$28.05B by 2030.) Category definitions vary materially between research houses; this is the source and definition cited throughout.
- [3] UXCam. App Retention Benchmarks 2026, using AppsFlyer State of App Marketing 2025 data. All-category averages: D1 25%, D7 8%, D30 4%.
- [4] Karpathy, A. LLM-wiki / compilation pattern (compile knowledge into durable interlinked pages rather than retrieve at query time), 2025.
- [5] Lifewoven engine — schema contract (
AGENTS.md), maintenance specification (MAINTENANCE.md), and dated engineering session logs, January–July 2026. Primary evidence for all production figures and both failure case studies in §6. Available on request.
Companion essay: Compile, Don't Retrieve — notes on the architecture of long-horizon personal memory.