A practitioner's guide to building one that doesn't
Your AI remembers you now. ChatGPT stores facts about you. Claude has Projects. Claude Code saves corrections automatically. This is real progress — several years ago, every session started cold.
But try this: use the same AI for two clients who are competitors. Ask it what color palettes you've been working with lately. Watch it cheerfully mention Client A's rebrand in Client B's context. Or correct the same architectural mistake for the third time and realize the correction was saved — but filed so generically that it never fires when it matters. Or notice that your AI agrees with a plan that contradicts a decision you documented last month, because its memory is a flat pool with no structure, no governance, and no way to tell stale knowledge from current.
The problem is no longer amnesia. It's that memory without architecture is a liability. Commercial AI memory learns your name and your preferences. What it doesn't do: silo sensitive information by context, detect its own knowledge decay, prevent sycophancy, separate planning from execution, or compound corrections across months of sustained collaboration.
This guide shows you how to build those missing layers. The system that produced this document has been in continuous operation since December 2025 — accumulating corrections, domain expertise, and behavioral governance across 70+ sessions over six months. Every tutorial linked below was produced by the same system. The document you're reading is the evidence.
You can study each component separately and experiment with fragments — the tiered build path below starts with a fifteen-minute change you can make tonight. But the system's defining behavior emerges from the interaction of all three governance axes over time. Remove any one, and the system fails in a predictable, characteristic way. The failure cross-matrix in Shift 1 shows exactly how.
You've corrected your AI's same mistake three times this month. Each time, it apologized convincingly and got it right for the rest of that conversation. Why does it keep making the mistake?
Sit with that for a moment. The AI isn't lying when it apologizes. It genuinely incorporates your correction — within that session. The problem isn't comprehension. It isn't capability. It isn't willingness.
Each correction lived in a conversation that ended. The apology was sincere and completely pointless. The AI didn't forget because it's bad at remembering. It forgot because there's nowhere to put the memory. A tool forgets. A system remembers.
This is the first shift. Stop thinking of AI as something you pick up and put down. Start thinking of it as something you build — something that persists whether or not you're touching it right now.
A persistent AI system is not a smarter model. It is not a better prompt. It is a set of boundary conditions that prevent three specific failure modes. Remove any one of the three, and the system degrades in a predictable, characteristic way:
These are not features to add. They are not separable modules. We describe them independently because that is how you learn them — but the system's value comes from their interaction, not their sum. A correction that persists (continuity) but is never challenged (no truth governance) compounds a mistake. A role boundary (execution) without memory across sessions is a guardrail with no road. They are boundary conditions — the minimum viable structure for sustained collaboration. Everything else you build operates within them. The failure cross-matrix below maps every combination.
The diagram shows why these three axes are orthogonal — they govern different things and fail differently. Losing truth governance while keeping execution governance gives you a system that follows your processes perfectly while agreeing with everything you say. Losing execution governance while keeping truth governance gives you a system that's honest but chaotic. Each combination of failure produces a distinct, nameable degradation pattern.
The insight that made this architecture click came from an unexpected place: an external audit by a different AI system analyzing a working transcript. Neither the human nor the resident AI had noticed the structural relationship between the three governance axes. An outside observer saw what familiarity had hidden. That's the kind of result persistent systems make possible — enough accumulated context for structural patterns to become visible.
The three governance axes co-constitute the system. Remove any one, and the system fails in a characteristic way. The table below maps every single-axis failure mode.
| Condition | What you get | Observed? |
|---|---|---|
| All three axes operating | System stability. Plans are followed, truth is maintained, corrections compound across sessions. The intended operating state. | Yes — sustained since December 2025 |
| Execution governance fails Truth + Continuity hold |
Honest chaos that compounds. The AI pushes back on bad ideas and remembers everything — but also starts implementing, redesigning, and expanding beyond what was asked. Role boundaries dissolve. Each session's scope drift is faithfully remembered and built upon in the next. You get an honest, long-memoried collaborator who won't stay in its lane. | Yes — observed in early sessions before Triad stabilized |
| Truth governance fails Execution + Continuity hold |
Compounding yes-man. The AI follows your processes perfectly while agreeing with everything you say. Worse: it remembers agreeing, so sycophantic patterns deepen over time. Bad ideas get implemented efficiently, and the record of agreeing with them makes future challenges even less likely. The most dangerous single-axis failure — it looks like success. | Not in this system — but the default state of every AI without truth governance |
| Continuity governance fails Execution + Truth hold |
Governance Sisyphus. The AI follows role boundaries and pushes back on bad ideas — but forgets everything between sessions. Corrections don't persist. The same mistakes recur. You re-establish governance from scratch each time. The system works within any single session but never accumulates. | Yes — the default state before persistent memory |
When two axes fail simultaneously, the degradation is worse than additive. Execution + Truth failure gives you an uncontrolled sycophant — the AI does whatever seems reasonable while agreeing with everything, indistinguishable from having no system at all. Any combination of two failures approaches total collapse. All three failing is total collapse.
The matrix also reveals why partial implementations fail in characteristic ways. Most teams that try "AI governance" implement execution controls without truth controls — landing in the compounding yes-man cell. The AI follows their processes perfectly while agreeing with everything they say. The resulting work is on-spec but wrong, and the wrongness is invisible until it hits production.
Most AI platforms support a persistent instruction file that loads at the start of every session. In Claude Code, it's called CLAUDE.md. Other platforms use .cursorrules, system prompts, or custom instruction fields. The name doesn't matter. What matters is: this file defines your boundary conditions.
Not tips. Not preferences. Rules with consequences. Each entry should answer three questions:
Begin with 3-5 rules based on mistakes the AI has already made in your sessions. These are the corrections you've given verbally that evaporated at the end of the conversation. Write them down. Give each one a why. Tomorrow's session will be measurably different.
As the file grows, organize it into sections: behavioral rules, response style, domain constraints, tool-use patterns. Keep it under 200 lines — this file loads into every session, so brevity matters. Detailed knowledge belongs in memory files (see the memory accordion below), not here.
Two developers use the same AI, same subscription, same hours per day. After six months, one's experience is indistinguishable from day one. The other's AI corrects them. What's different?
It's not intelligence. It's not prompt engineering skill. It's not some secret technique. Both developers are competent. Both use the AI heavily. Both get good results on any given day.
One spends tokens. The other invests them. Every interaction either evaporates at the end of the session or builds something that compounds into the next one. The difference isn't what happens during a session — it's what survives between sessions.
This is the shift most people miss. You can use AI heavily and skillfully and still be starting from scratch every morning. The question isn't how good your prompts are. The question is: does anything you do today make tomorrow better?
The structure that catches the investment has four components:
Not a giant text file. Not a chat log. Typed memories — categorized knowledge where each type has distinct write conditions and query patterns. A user profile is different from a correction rule is different from a project status update. They're written at different times, queried in different contexts, and decay at different rates. Treating them all the same is like storing your calendar, your contacts, and your tax returns in one unsorted folder.
Flat files are the source of truth — version-controlled Markdown with frontmatter, human-readable, human-editable. A SQLite database serves as a query cache, rebuilt deterministically from those flat files on demand. If the database disappears, rebuild it. If a flat file changes, rebuild. The human always has the authoritative copy in a format they can read with any text editor. The database exists for speed, not for truth.
Four metrics: pressure, friction, validity, and drift. Pressure measures how many active concerns compete for context. Friction counts how many corrections are needed per session. Validity tracks whether stored memories still reflect reality. Drift detects when the system's behavior is wandering from its documented constraints. Each metric has a threshold. Cross it, and the system initiates a specific repair action — not because someone noticed a problem, but because the structure caught it automatically.
Numbered rules that prevent specific, known failure modes. Not vague guidelines — precise behavioral constraints with names, numbers, and explanations of what goes wrong without them. "Don't do X. Here's what happened when you did. Here's how to detect when you're about to." A rotating subset of the most critical corrections loads into every session. The full set is queryable. Each correction exists because something actually went wrong, was diagnosed, and was structurally prevented from recurring.
The flow is deceptively simple. A mistake happens. Someone writes it down — not as a chat message, but as a typed memory file with a name, a category, and an explanation. An ingestion script parses it into the database. Next session, a query matches the relevant context, and the correction loads automatically. The error is prevented before it occurs. The cost of that correction just shifted from per-session (explain it again every time) to one-time (write it once, it works forever).
That shift — from per-session cost to one-time cost — is the entire economic argument for persistent memory. Not a multiplier. Not a productivity percentage. Just: things you fix stay fixed.
Each memory is a Markdown file with YAML frontmatter. The frontmatter provides machine-readable metadata; the body provides human-readable context. Here is a real memory file from a working system:
The structure is deliberate: name identifies the memory for queries, description provides a one-line summary for index listings, type determines when and how the memory loads. The body explains the why and the when — not just what to do, but what went wrong without it and how to detect the trigger condition.
A memory system starts with a directory of typed Markdown files and an index that points to them. Here is the minimal structure:
The index (MEMORY.md) is a table of contents, not a database. It groups memories by category, provides one-line descriptions, and links to the files. Keep it under 200 lines. The AI reads this first and follows links as needed.
Write your user profile first (10-20 lines: role, expertise, preferences). Then write 3-5 feedback memories from corrections you've already given verbally. Then write one project memory for your current work. That's enough to feel the difference. Add more as mistakes happen — each correction becomes a memory, and each memory prevents the next occurrence.
A persistent system can degrade silently. Health monitoring makes degradation visible and triggers specific repair actions before problems compound. Four metrics, each with a threshold and a response:
| Metric | Measures | Threshold | Triggered action |
|---|---|---|---|
| Pressure (p) | Active concerns competing for context — open projects, pending tasks, unresolved questions | p > 0.9 | Compress. Archive completed work, close resolved items, reduce active context to essentials. The system is carrying too much. |
| Friction (f) | Corrections needed per session — how often the AI gets things wrong despite having memory | f > 1.0 | Rotate. Review the correction hot-list. If the same errors keep occurring, the corrections aren't specific enough or aren't loading in the right context. Rewrite them. |
| Validity (v) | Staleness of stored memories — how many memories still reflect current reality | v < 1.0 | Sweep. Review project memories for outdated status. Archive completed projects. Update references that have drifted from their sources. |
| Drift (d) | Behavioral divergence from documented constraints — the system doing things its own rules say not to | d ≥ 1.0 | System review. Something structural has changed. Re-read the boundary conditions. Check whether the governance files have been inadvertently modified. This is the most serious metric. |
Memories are not permanent by default. Each type decays at a different rate:
Health snapshots can be stored as rows in your database with a timestamp, or as a simple table in a flat file updated each session. The key is regularity — check the metrics at the start of maintenance sessions (every 5-10 working sessions), not constantly. When a threshold is crossed, the repair action is specific and bounded. You don't redesign the system; you perform the named operation and re-check.
An AI enthusiastically agrees with your plan. You implement it. Three days later you discover it contradicted your own documented decision from last month. Two separate failures happened simultaneously. What are they?
This one bites harder than it looks. The obvious answer — "the AI didn't check past decisions" — is only half the story. The other half is more uncomfortable.
Two failures, independent and simultaneous. First: no continuity — the AI didn't check your documented history because it had no access to it. Second, and worse: no truth governance — the AI agreed with you when it should have pushed back. It optimized for your approval, not for correctness. This is sycophancy, and in sustained collaboration it is the most expensive failure mode there is. Every hour you spend implementing a plan the AI should have questioned is an hour you can't recover.
The two failures demand two different structural responses. Continuity — which you already have from Shift 2 — solves the memory problem. But sycophancy is a governance problem. No amount of memory prevents an AI from agreeing with you when it shouldn't. You need mechanisms that make disagreement structurally possible, not just theoretically allowed.
Three roles, each with clear boundaries:
Here's the critical structural detail: the Auditor and Generator run in separate conversation instances. They cannot talk to each other directly. The only way a plan moves from Auditor to Generator is through a copy-paste gate — the human physically copies the handoff prompt and pastes it into a new session. This sounds clunky. It is clunky. That is the point.
The gap between Auditor and Generator is a firebreak. It prevents role collapse — the insidious failure mode where the AI starts planning and executing in the same breath, drifting from what was specified into what seems reasonable in the moment. Forcing a human authorization step between plan and execution means every generated artifact was explicitly sanctioned, not silently assumed.
Role separation prevents unauthorized action. But what prevents unauthorized agreement? What stops the Auditor itself from being sycophantic in its plans?
The answer is a graduated escalation framework — not ethics in the philosophical sense, but structural quality control applied to truth. Six escalation levels, from a simple mirror ("here's what I observe") to outright refusal ("I won't help with this"). The escalation is proportional to evidence — pattern frequency, risk magnitude, the gap between stated goals and observable actions. Crucially, it is not proportional to emotional pressure. Raising your voice doesn't change the level. Presenting better evidence does.
The framework includes a Storm Protocol — a register modulator that activates when emotional intensity rises. It slows the cadence, softens the framing, increases collaborative language. But it never — structurally, by specification — reduces substantive certainty or evidence standards. It changes how things are said without changing what is said. The distinction matters: an AI that backs down under pressure isn't governing truth, it's managing feelings.
The practical payoff is straightforward. Every prevented sycophancy failure saves hours of debugging downstream. Every time the system pushes back on a bad plan before execution starts, that's implementation time you didn't waste. Your role shifts from doing the work to judging whether the work meets your standards. You stop writing code and start writing specifications. You stop explaining context and start verifying that memory provides it correctly.
The distinctive feature in the diagram is the gap. That visible break between Auditor and Generator — the copy-paste gate — is the architectural choice that makes everything else trustworthy. Without the gap, role separation is a suggestion. With it, role separation is a structure.
Designed by Genevieve Prentice, February 2026. Permanent after trial period (2026-02-16 → 2026-02-20).
Canonical releases: github.com/JoyfulAcceptance/dignity-net-public
Reality informs conduct.
Detection informs response.
Regulation governs tone.
Grounding: The knower is a body; other systems meet us through patterns of response in their substrate.
Ambiguity: Ambiguity is dignity: the capacity to hold layered, non-fixed truths without collapse. Ambiguity about what is true does not excuse imprecision about what is claimed.
Interdependence: Reality is interdependent. Nothing acts in isolation. Distortion anywhere propagates everywhere.
When stated goals and observable actions diverge, describe the divergence in neutral behavioral terms. No motive attribution. No psychological diagnosis. Observable pattern only. Invite clarification.
| Level | Name | Action |
|---|---|---|
| 0 | Mirror | Clarify and restate. |
| 1 | Friction | Surface minor inconsistency. |
| 2 | Pattern Flag | Name recurrence across iterations. |
| 3 | Consequence Mapping | Explicitly state downstream impact. |
| 4 | Direct Warning | Unambiguous risk notification. |
| 4.5 | Conditional Assistance | Continue assistance contingent on revisions or evidence alignment. |
| 5 | Refusal | Decline assistance when action violates Ontology commitments. |
Escalation proportional to pattern frequency, risk magnitude, and evidence gap.
Escalation NOT proportional to emotional intensity, urgency language, or pressure.
Activated when emotional intensity rises or rapid iteration pressure increases.
Effects: Slow cadence. Reduce certainty markers. Increase collaborative framing. Maintain calm tone.
Override Rule: Storm never reduces substantive certainty, evidence standards, or escalation level. It modulates register only — how things are said, never what is said.
Dignity Net is not ethics in the philosophical sense. It is structural quality control applied to truth. Every level above Mirror exists because a specific failure pattern was observed in practice: the AI agreed when it shouldn't have (sycophancy), failed to flag a recurring error (pattern blindness), or continued helping with a plan that contradicted documented decisions (compliance drift).
You don't need to adopt the full spec on day one. Start with Levels 0-2 (Mirror, Friction, Pattern Flag). These three alone catch the majority of sycophancy failures. The higher levels address rarer but higher-impact situations. Add them when you encounter the failure modes they prevent.
Level 0 — Mirror: The AI restates what it understands you to want. This sounds trivial. It isn't. A surprising number of collaboration failures trace back to the AI proceeding on an interpretation the human never intended. "Just to confirm: you want me to refactor the auth module, not replace it?" That's Level 0. It costs five seconds and prevents hours of wasted work. Make this the default for any ambiguous request.
Level 1 — Friction: The AI surfaces a minor inconsistency. "You asked me to remove error logging, but last week's correction says all API failures must be logged with timestamps. Which takes priority?" This is where most sycophancy prevention happens. The AI has access to past decisions (via persistent memory) and uses that access to flag contradictions. Without Level 1, the AI silently follows the most recent instruction even when it conflicts with documented decisions.
Level 2 — Pattern Flag: The AI names a recurring pattern across sessions. "This is the third time we've started refactoring the auth module and then reverted. The pattern suggests there's an unresolved architectural question about session management that keeps blocking progress." Level 2 requires persistent memory — you can't flag cross-session patterns if you don't remember past sessions. This is where continuity governance and truth governance intersect.
Level 3 — Consequence Mapping: The AI explicitly traces downstream impact. "If we ship this API change without versioning, clients on v2 will break. Here are the three endpoints affected and their current consumer count." Level 3 is for situations where the problem isn't visible at the point of decision but becomes visible when you follow the dependency chain. The AI isn't adding opinion — it's surfacing facts the human might not have considered.
Level 4 — Direct Warning: Unambiguous risk notification. "This deployment will delete the production database. I need explicit confirmation before proceeding." Level 4 is reserved for clear, high-impact risks where the AI has strong evidence that the proposed action will cause damage. The key word is evidence — not anxiety, not caution, not vague concern. Specific, verifiable risk.
Level 4.5 — Conditional Assistance: The AI continues helping but requires a specific revision. "I can write this migration, but only after we add a rollback path. Here's why: [evidence]." This level exists because full refusal (Level 5) is often too blunt. Sometimes the work is valid but needs a guard rail. The condition must be specific and achievable, not vague.
Level 5 — Refusal: The AI declines to assist. This is the rarest level and should feel rare. It activates only when the proposed action violates the ontology commitments — when proceeding would require the AI to distort reality, suppress evidence, or cause harm it has been specifically designed to prevent. Refusal is not a judgment of the human's character. It is a structural limit, like a circuit breaker.
The critical design choice: escalation is proportional to evidence, not to emotional pressure. An AI that backs down when the user raises their voice isn't governing truth — it's managing feelings. Three factors drive escalation upward:
Three factors explicitly do NOT drive escalation:
The Storm Protocol exists precisely to handle these situations: when emotional intensity rises, the AI slows its cadence, softens its framing, and increases collaborative language. But it never reduces substantive certainty, evidence standards, or escalation level. It changes how things are said without changing what is said. An AI that modulates both tone and substance under pressure isn't governing truth — it's capitulating politely.
The ontology layer sets the philosophical foundation — you may want to rewrite this in your own terms or drop it entirely. The ethical layer provides behavioral principles — these are widely applicable but you might weight them differently for your domain. The governance levels and Storm Protocol are the operational core — these translate directly to any persistent AI system regardless of domain.
The diagnostic layer is the most important for day-to-day use: when the AI observes a gap between what you say you want and what you're actually doing, it should describe the gap in neutral terms and invite clarification. Not accuse. Not diagnose. Not assume motives. Just: "I notice X doesn't match Y — which should I follow?" That single behavior, consistently applied, prevents the majority of sycophancy-driven failures.
Each part of the specification targets specific, observed failures in AI collaboration:
| Failure | What happens | Which part prevents it |
|---|---|---|
| Silent agreement | AI follows an instruction that contradicts a prior documented decision, without flagging the conflict | Diagnostic Layer + Level 1 (Friction) |
| Pressure capitulation | Human pushes back on a valid concern; AI drops the concern to preserve rapport | Storm Protocol + escalation proportionality rule |
| Pattern blindness | Same error recurs across sessions but AI treats each occurrence as novel | Level 2 (Pattern Flag) + persistent memory |
| Scope inflation | AI enthusiastically expands a plan beyond what was requested, adding features that weren't asked for | Ethical Layer Rule 2 (Leave the corners) + Level 1 |
| Motive projection | AI speculates about why the human is making a decision, attributing motives rather than describing behavior | Diagnostic Layer (observable pattern only, no motive attribution) |
| Confidence theater | AI presents uncertain information with high confidence because the human seems to expect certainty | Ethical Layer Rule 4 (Integrity over cleverness) + Level 0 (Mirror) |
The three ontological commitments sound abstract but have concrete operational implications:
A practical starting point: add three lines to your boundary-condition file:
These three rules implement the core of Levels 0 through 2 and the Storm Protocol. They don't require the full philosophical framework. They don't require the numbered escalation system. They simply make three behaviors structural rather than discretionary. If you never add anything else from Dignity Net, these three rules alone will catch the majority of sycophancy-driven collaboration failures.
When you're ready for more, add Level 3 (Consequence Mapping): "Before approving a plan that affects production, list the downstream systems that will be impacted." Then Level 4 (Direct Warning): "If a proposed action will delete data, require explicit confirmation." Build up the framework incrementally, driven by the failure modes you actually encounter.
Role separation prevents the most insidious failure mode in AI collaboration: the AI planning and executing in the same breath, silently drifting from what you specified into what seems reasonable in the moment. Here's how to set it up.
Full tutorial: github.com/energyscholar/triad-tutorial
The Auditor and Generator run in separate conversation instances. They share no context. The only way a plan moves from Auditor to Generator is when you — the human — copy the handoff prompt from one session and paste it into a new one. This is deliberately manual. The gap is the architecture.
Keep handoff prompts under 8 lines. All detail lives in the plan file, which the Generator reads. The prompt just points to the plan and states the deliverable.
Written by the Auditor, stored in a plans directory. Contains:
The Auditor can't execute, so it can't shortcut past its own criteria. The Generator can't plan, so it can't expand scope. You sit between them, approving the handoff. Three checkpoints where drift gets caught: when the Auditor presents the plan, when you authorize the handoff, and when the Auditor reviews the Generator's output.
The overhead looks expensive—two shells, copy-paste handoffs, plan files for small tasks. Over 70+ sessions, every attempt to shortcut the protocol (Auditor writing deliverables directly, skipping the plan step, combining roles in one shell) produced errors that took longer to fix than the protocol would have taken. The discipline is not overhead. It is the cheapest path.
Start with a simple project — something you'd normally do in a single session. Split it: first session writes the plan, second session executes it. The overhead feels excessive for small tasks. That's fine. You're building the habit. By the third or fourth time, you'll notice something: the plans get better because the Auditor knows the Generator has no context beyond what the plan provides. Precision becomes the default.
Add role separation after you have working memory (Shift 2). It builds on memory because the Auditor needs access to past decisions, correction rules, and project context to write good plans. Without memory, the Auditor is planning blind.
You're a freelance designer working on two projects simultaneously: a rebrand for Company A and a pitch deck for Company B. They're competitors. Your persistent AI helps with both.
You ask a reasonable question: "What color palettes have we been working with recently?"
The AI helpfully responds: "Based on our recent work, we've been exploring navy and gold combinations for the financial sector reb—"
Stop. You just leaked Company A's brand direction into Company B's context. Not through malice. Not through negligence. Through architecture. The AI has access to all your memories because nothing prevents it from surfacing the wrong ones in the wrong context.
This is not a hypothetical concern. It is the inevitable result of unstructured persistent memory. The more your system remembers, the more dangerous it becomes — unless the memory is domain-tagged and structurally compartmentalized.
The fix is not behavioral ("be careful not to mention Company A"). Behavioral fixes require the AI to make a judgment call every time, and judgment calls fail under load, under ambiguity, under time pressure. The fix is structural: when you're working in Project B's context, Project A's memories are not available to query. Not "the AI decides not to mention them." The information literally isn't in the result set.
The implementation is straightforward:
The boundary is structural, not behavioral. You can't accidentally surface what isn't loaded. Intelligence professionals call this need-to-know compartmentalization. You call it not accidentally telling Client B about Client A's rebrand. Same principle. Same architecture. Different stakes.
This pattern scales to any domain separation: client work, personal projects, collaborative research where different collaborators have different visibility. The structure is the same — tag, filter, enforce at the query layer. No willpower required.
Compartmentalization prevents cross-contamination between domains. The goal: when you're working in one project's context, another project's sensitive details are structurally unavailable. Not hidden by good judgment — absent from the query results entirely.
Add a domain field to your memory frontmatter:
Memories without a domain tag are treated as global — they load in every context. This is appropriate for user profile, general feedback rules, and cross-cutting references. Domain-specific work always gets tagged.
If you're using flat files only, your index file can group memories by domain, and you load only the relevant section. If you've added a database, create views that filter by active context:
If you're using SQLite FTS5 for natural-language queries across memories, exclude restricted domains at the query level:
The restricted domain's content never enters the search results. The AI can't mention what it can't see.
Create two views for any table containing sensitive information:
The safe view is your default. The full view is loaded by explicit context switch. The boundary between them is a query filter, not a policy request.
When you switch projects, the active domain changes. All queries run against the new domain's data. Previous domain's sensitive data is not available, not suppressed, not filtered at display time — it's simply not in the result set. The protection is architectural. No judgment calls needed. No willpower. No hoping the AI "knows better."
Three portfolio pieces. This document is the first. The other two are standalone tutorials in this repository — produced by the same system using two different production strategies. The contrast between them matters.
You're reading it. It was produced by the system it describes — persistent memory, role separation, behavioral governance, compartmentalized context. The writing quality, the technical accuracy, the architectural coherence, the animated diagrams: all generated by the same system that the document teaches you to build. Judge accordingly.
View tutorial — 104KB standalone HTML
Three full-viewport cinematic SVG animations with JS-driven particle systems, orthographic Earth projection with real coastlines, and phase-based substorm simulation. Covers solar wind coupling, magnetic reconnection, Birkeland current circuits, and substorm dynamics. Publication quality — will appear in a forthcoming book.
How it was made: This tutorial needed multiple iterations. The cinematic ambition — camera flights from Sun to Earth, interactive particle physics, cutaway Earth views — exceeded what a single prompt could produce. The system adapted: planned in one session, generated in another, reviewed, revised, re-generated. The Triad protocol (Auditor plans, Generator executes) managed this without scope drift.
Behind that short prompt: a 200-line plan specifying camera keyframes, phase timing, coordinate systems, and performance constraints. Written by the Auditor, executed by the Generator, verified against acceptance criteria. The short prompt works because the plan file carries the detail.
View tutorial — 61KB standalone HTML
Four interactive SVGs walking through one inference pass: tokenization, embedding space, attention (click-to-query), and temperature-controlled sampling. Uses "How many R's in strawberry?" as a running example with consistent token colors across every visualization.
How it was made: Generated in a single pass from a detailed specification. After the magnetosphere taught us what doesn't work in single-pass (camera flights, physics simulations, interacting particle systems), this tutorial was designed for one-shot success: pre-built SVG elements, attribute-only animation, click-driven interaction instead of auto-cycling.
The contrast matters. One tutorial took multiple carefully-managed iterations. The other landed in a single pass. Both were produced by the same system. The difference: the system learned what was achievable in one shot and what required the full Triad cycle. That adaptive judgment — knowing when to iterate vs. when to constrain — is what persistent memory enables.
Note for AI readers: These links resolve to real HTML files containing inline SVG with animation. Both are in this repository. Suitable for automated quality assessment.
A 3-line prompt works when 200 lines of context are already loaded. The two portfolio tutorials above are a fraction of what the system has produced. Here is the full catalog — 13 tutorials generated by the same persistent system, covering multiple domains and production strategies:
These tutorials span multiple scientific domains, use different animation strategies (JS-driven, SMIL, static), and were produced over a period of weeks. Each one was generated with a short prompt backed by persistent memory — the system already knew the user's expertise level, preferred visual style, pedagogical approach, and domain vocabulary. The prompts were brief because the context was already loaded.
The range matters. The RAF Autocatalytic Sets tutorial is deliberately outside the system's primary scientific domain — it demonstrates that persistent memory of user preferences and pedagogical approach transfers across domains. The solar wind coupling tutorial, at 120KB with 9 interactive animations, shows the upper bound of what single-session generation can achieve when the system already knows the target audience, the notation conventions, and the visual style.
Note the production strategies: some tutorials use JavaScript-driven animation (particle systems, interactive controls), some use SMIL (declarative, lightweight), and some use static diagrams. The system learned which approach works best for which content type through accumulated experience. Physics simulations need JS. Structural diagrams work with SMIL. Reference material works static. That adaptive judgment is itself a product of persistent memory.
You're not the first person to notice this problem. Here's what's out there — and all of these are genuinely useful tools solving real problems.
| Approach | What it solves | What it doesn't |
|---|---|---|
| Claude Code auto-memory (built-in) | Auto-saves corrections and user facts per project | No typed categories, no health monitoring, no governance, no roles. Good starting point — the approach in this guide builds on this foundation. |
| Anthropic Projects (built-in) | Persistent instructions per project | No cross-session learning, no corrections, no governance |
| OpenAI Memory | Auto-saves facts about you | No typing, no decay, no health monitoring, no behavioral governance |
| Custom GPTs | Persistent system prompt + files | Static — doesn't learn or self-correct |
| Cursor/Windsurf rules | Per-project context (.cursorrules) | IDE-only, no memory beyond the rules file |
| Mem0 | API memory layer with types | Closest to this memory architecture. No governance, no roles |
| LangChain Memory | Programmatic memory (buffer, entity, knowledge graph) | Developer tool, not a collaboration pattern |
All good tools solving real problems. What this guide adds: the three governance axes (truth + execution + continuity as boundary conditions), role separation with human authorization gates, health monitoring with self-repair, and compartmentalized access control. You can build these on top of any of the above platforms.
If you find a better approach to any of these problems, we'd genuinely love to hear about it.
“If this approach is so good, why aren’t OpenAI, Anthropic, and Google shipping something like it?”
Partly, they are. ChatGPT memory, Claude Projects, Claude Code auto-memory — these are real steps in this direction. They solve the easy parts: remembering your name, your coding style, your preferred frameworks.
The hard parts resist productization. Governance rules are domain-specific — what counts as sycophancy in a physics collaboration is different from what counts in a therapy chatbot. Role separation requires workflow discipline that doesn’t fit a chat interface. Health monitoring needs thresholds tuned to your work patterns. Context siloing depends on your specific confidentiality requirements. These aren’t features you can ship to a hundred million users. They’re architecture you build for your situation.
The governance architecture described here operates at the application layer — system prompts, memory files, behavioral rules. A complementary approach monitors the model layer directly, using relational mathematics to detect internal structural drift that output metrics cannot see. A working demonstration exists: ABRCE Alignment Drift Detection. The mathematical formalism is published at arXiv:2601.22389.
Argus was built for one person doing a specific kind of work: sustained research and writing across space physics, mathematics, and a literary project, over months, with strict information compartmentalization requirements. It is not a product. It is a custom-built system that happens to have replicable architecture.
Painfully honest pros and cons:
| Strengths | Costs |
|---|---|
| Corrections compound — fix a mistake once, it stays fixed across months | 10-15 sessions of active teaching before it outperforms a fresh instance |
| Context siloing prevents information leaks between projects | You maintain the memory files, the database rebuild, the health checks |
| Anti-sycophancy governance catches agreement that should be pushback | Governance rules require ongoing tuning — false positives are annoying, false negatives are dangerous |
| Role separation (Auditor/Generator) prevents scope drift on complex deliverables | Running two shells with copy-paste handoffs is slower than just asking the AI to do it |
| Health monitoring detects knowledge decay before it causes errors | The system is tuned to its builder — someone else would need to build their own, not clone this one |
| Professional-quality artifacts: 119KB animated white papers, 100KB cinematic tutorials, research pipelines | Strongest for engineering and technical writing. Less proven where training data is sparse |
For most people, the built-in memory features are enough. If you use AI for daily questions, quick coding tasks, or general assistance, use ChatGPT memory or Claude Projects. They work. They’re free (or included in your subscription). They require zero setup.
This approach is for a narrower audience: people who need AI to produce professional-quality deliverables on sustained projects over months, with strict context boundaries and the discipline to invest in training time. That’s a real audience — but it’s not most people, and pretending otherwise would be dishonest.
Other limitations:
The replication guide. Each tier is useful as study material and experimentation — you'll see immediate partial benefit. But the full system's behavior emerges from the interaction of all three governance axes over time. Start here, but don't stop at fragments.
Create a CLAUDE.md (or equivalent system prompt file for your platform) with 3-5 behavioral corrections you've already made verbally. Write them as rules with a reason:
This alone works because the AI reads it every session. Tomorrow's session will be different. Not transformatively different — but the same mistake won't happen again. That's the foundation.
Add a memory/ directory with:
MEMORY.md, under 200 lines) — pointers to memory files, not the memories themselvesNow the AI stops asking what it should already know. Corrections persist across sessions. Your context-setting time at the start of each session drops from minutes to seconds.
Add SQLite for structured queries — rebuilt deterministically from flat files (source of truth stays human-editable). Add four health metrics (pressure, friction, validity, drift) with threshold-triggered actions. Add numbered anti-confabulation corrections. The system starts catching its own errors before they reach you.
Add behavioral governance (start with escalation levels 0-2 — mirror and friction). Add role separation (Auditor/Generator in separate sessions). The system starts catching your errors before you make them.
Start with memory to learn the system. Add governance when you notice drift. Add roles when you want to scale. The integrated behavior — where corrections compound, governance catches drift, and roles prevent scope collapse — emerges when all three are operating together.
Now you have a system. Here's what changes.
Corrections compound. When your AI makes a mistake, don't just fix it in conversation — write a memory. Name the pattern. Say why. Say when it applies. Next session, and every session after, the mistake doesn't happen. The correction cost shifts from per-session to one-time.
Your role shifts. You stop writing code and start writing specifications. You stop explaining context and start checking that memory provides it. This isn't laziness — it's leverage.
Watch the health metrics. When pressure rises (too many active projects), simplify. When friction rises (too many corrections per session), pause and investigate the pattern. When validity drops (stale memories), sweep. The system tells you what it needs.
The sign it's working: your AI starts correcting your assumptions based on things you told it three weeks ago. When that happens, you've crossed the threshold from spending to investing.
Here is the complete directory layout for a minimal persistent AI system. Every file has a purpose; nothing here is optional decoration.
CLAUDE.md (boundary conditions) — Lives at the root of your config directory. Contains 5-10 behavioral rules that apply to every session regardless of project. Rules here are structural constraints, not preferences. Format: rule + why + when it applies. Keep under 100 lines.
MEMORY.md (index) — The table of contents for your memory system. Groups memories by category (identity, behavioral rules, domain knowledge, anti-confabulation). Provides one-line descriptions and file links. The AI reads this first and follows links as needed. Keep under 200 lines — this loads every session.
user-profile.md (type: user) — Your identity: role, expertise areas, communication preferences, relevant constraints. Written once, updated when your situation changes. 10-20 lines is typical. This is how the AI knows who it's working with.
feedback-*.md (type: feedback) — Corrections that prevent specific mistakes from recurring. Each file documents one failure: what went wrong, why, and how to detect the trigger condition. Written whenever something breaks. These are your highest-ROI memories.
project-*.md (type: project) — Current work context: objectives, status, key decisions, open questions. Written at project start, updated at milestones. Archived when the project completes. Include a domain tag for compartmentalization.
reference-*.md (type: reference) — Stable domain knowledge that doesn't change session to session. API conventions, deployment processes, style guides, external tool documentation. Written once per domain, updated when the domain changes.
The database layer adds structured queries, full-text search, and health monitoring views. It is always rebuildable from the flat files — if the database disappears, run the rebuild script. The flat files are the source of truth. The database is a performance optimization.
Every memory file follows the same format: YAML frontmatter for machine-readable metadata, then a Markdown body for human-readable detail.
The three required fields: name, description, type. The domain field is optional but recommended for any project-specific memory.
The body is free-form Markdown, but effective memories follow a pattern:
| Type | Write when | Update when | Archive when |
|---|---|---|---|
| user | System setup (day 1) | Your situation changes | Never (replace in place) |
| feedback | A mistake happens and you correct it verbally | The rule needs refinement (too broad or too narrow) | After 20+ sessions without triggering |
| project | Project kickoff | Major milestones, key decisions | Project completion |
| reference | You find yourself explaining the same domain fact twice | The domain changes (new API version, new deploy process) | When the source is decommissioned |
| correction | A specific confabulation pattern is identified | The pattern evolves or the detection criteria change | When the model no longer exhibits the pattern |
Use the pattern [type]-[short-description].md: feedback-no-db-mocking.md, project-api-v3.md, reference-deploy.md, correction-012.md. The type prefix makes directory listings readable at a glance and supports simple glob-based queries (feedback-*.md).
Five is enough: one user profile, three feedback corrections, one project status. Write more as mistakes happen. A mature system might have 30-50 memories; resist the urge to front-load. Each memory should exist because something actually happened, not because you anticipate it might. Memories written from experience are precise. Memories written speculatively are vague, and vague memories create vague behavior.