# Athanor — Personal OS Framework: Install Instructions for an AI Agent **Version**: 1.0 **Audience**: an AI agent ("installing agent") setting up Athanor for a new human user, and the human user who runs that agent. **Output**: a working Athanor installation — directories, skeleton files, a personalized core instruction file, and a drafted identity layer — ready for standard-mode use. --- ## 0. How to Read This Document This is a manual, not a narrative. Read Sections 0–7 in order once; then use the Table of Contents below as a jump map during install. Appendices are lookup material: read the specific appendix only when the current phase requires it. - **Sections 1–3** describe the framework: what it is, its structure, its operating rules. Read before acting. - **Section 4** is the install protocol (7 phases). Execute in order. Do not skip phases. - **Sections 5–7** describe standard-mode operation, quality signals, and personalization boundaries. Reference during and after install. - **Appendices** are lookup material: directory tree, logs, interview prompts, limits, checks, helper prompts, templates, and final shape check. Do not load or reproduce all appendices up front. **Token-budget rule**: do not paste large generated files, full drafts, or long checklist audits into chat unless the user asks. Write them to disk, then show a compact review packet: paths changed, 3–7 important decisions, remaining GAPs, and next action. **Non-goals of this document**: it is not a philosophy essay; it is not a marketing page; it is not a fixed prescription. It describes the invariants an installing agent must preserve and the levers it may adjust. Everything outside "Fixed Core" in Section 7 is tunable. **Language**: this install doc is English. The framework itself is language-agnostic — the installing agent settles language before anything else (by inferring from the user's initial prompt and confirming, with a fallback open question if detection is ambiguous) and produces all memory files, rituals, and conversation in that language. English is the default fallback only if the user has no preference. **User interface rule**: distinguish the agent manual from the user interface. The manual may use framework vocabulary; the user sees plain explanations in their chosen language. Keep English only for literal paths, filenames, schema values, and documented preset keys. ### Table of Contents 1. Framework at a Glance 2. Directory & File Skeleton 3. Core Instruction File — Skeleton 4. Installation Protocol (Minimal Path + 7 phases) 5. Standard-Mode Protocols (rituals and cadence) 6. Self-Discovery Track (Quality Signals) 7. Variation & Personalization Guidance 8. Appendix A — Directory Tree 9. Appendix B — Ingestion Log Template 10. Appendix C — Setup Interview Prompt Bank 11. Appendix D — Non-Goals / Known Limits 12. Appendix E — Acceptance Checklist 13. Appendix F — Standard-Mode Helper Prompts 14. Appendix G — Minimal Valid Templates 15. Appendix H — Finished Install Shape Check ### Suggested user kickoff prompt A user starting an install can paste this into their agent: > Set up Athanor for me using `athanor_install_guide.md`. Follow the guide step by step. Ask me for choices when needed. Keep the chat concise and write files to disk. --- ## 1. Framework at a Glance ### 1.1 Mission Athanor helps its user become more capable and happier over multiple years by improving self-understanding and discovering/acting on **unknown unknowns** — blind spots, hidden constraints, undervalued strengths, mistaken assumptions, and unconsidered opportunities. It is not a productivity tool. It is a **personal operating system**: an integrated memory of who the user is, what they are figuring out, what they are doing now, and how energy flows through all of it. ### 1.2 The Four-Layer Memory Stack | Layer | Folder | Question it answers | Cadence of change | |---|---|---|---| | **0 — Identity** | `00_identity/` | Who am I? What am I aiming at (slow)? | Yearly or rarer | | **1 — Operating** | `01_operating/` | What am I figuring out, with data? | Monthly / quarterly | | **2 — Execution** | `02_execution/` | What am I doing now? | Weekly | | **3 — Artifacts** | `03_artifacts/` | Reference material *outside* the layers | On demand | - Layer 0 is **default-true**. Only updated deliberately. - Layer 1 is **provisional**. Expect churn. Dated entries, audit trail. - Layer 2 is **short-horizon**. Fast-cadence review; must not become a graveyard of stale todos. - Layer 3 is **attachments**: conversation summaries, maps, templates, archived projects. Not live operating state. Promotion path: a pattern noticed in Layer 2 becomes a hypothesis in Layer 1; a confirmed hypothesis promotes to Layer 0. ### 1.3 Energy as Vertical Substrate Energy is not a horizontal peer layer. It is a **vertical substrate** that flows through all three operational layers (thinking, self-knowledge, execution) and modulates their performance. - Captured at Layer 0 in `energy_map.md` (confirmed gives/takes with controllability and magnitude). - Tracked at Layer 2 via weekly/monthly rituals. - Synthesized at Layer 1 via quarterly analysis (pattern detection, map updates). A user resisting quantified-self practice can keep energy tracking qualitative. Energy-as-substrate is **fixed core**; the *form* of tracking is tunable. ### 1.4 Two Separation Principles Athanor's architecture rests on two separations. The installing agent preserves both. **Separation 1 — Ingest vs. Analyze.** Rituals that *collect* data (check-ins, weekly reviews, monthly reflections) are not the rituals that *synthesize* patterns. Collection and analysis happen at different cadences and require different cognitive modes. Mixing them produces longer, mushier rituals that are worse at both jobs. **Separation 2 — Identity vs. Sensemaking vs. Execution vs. Reference.** Each memory layer has one role. Do not write open questions into `user_model.md`. Do not write identity claims into `insights.md` before they've survived Layer 1 churn. Do not store live execution in `03_artifacts/`. ### 1.5 Output Shape of the Install When the install completes: - A directory tree matching Appendix A exists on disk. - A core instruction file is written in the user's chosen language, reflecting their chosen tone/challenge/privacy/ritual/values preferences. - Layer 0 files have draft content where evidence exists, with confidence annotations and visible gaps for the user to review. - Layer 1 and Layer 2 files exist as empty skeletons with clear purpose headers. - `03_artifacts/` contains the canonical project template plus any ingested material the user chose to preserve as reference. - The user has reviewed the draft identity layer and signed off (or edited). - The installing agent has run the starter-pack reading order once and confirmed it loaded cleanly. --- ## 2. Directory & File Skeleton The installing agent creates the tree below. All folder and file names are lowercase with underscores. Paths are relative to the install root (which the user chooses; `athanor/` is the suggested default). ``` athanor/ ├── 00_core.md (fallback core instruction file; may be replaced by a native agent file) ├── README.md (user-facing; see athanor_readme.md template) ├── tone_of_voice/ │ ├── short/ (empty; user pastes short-form samples here) │ └── long/ (empty; user pastes long-form samples here) └── memory/ ├── README.md ├── 00_identity/ │ ├── README.md │ ├── user_model.md │ ├── values.md │ ├── life_goals.md │ ├── wishes.md │ └── energy_map.md │ (optional: relationships_map.md, custom files) ├── 01_operating/ │ ├── README.md │ ├── open_loops.md │ ├── experiments.md │ └── insights.md ├── 02_execution/ │ ├── README.md │ ├── now.md │ ├── goals/ │ │ ├── README.md │ │ └── goalsYYYY.md │ ├── weekly_reviews/ │ │ ├── README.md │ │ └── weekly_review_log.md │ ├── checkings/ │ │ ├── README.md │ │ └── checking_template.md │ └── active_projects/ │ └── README.md └── 03_artifacts/ ├── README.md ├── install/ │ └── _install_state.md ├── intake/ │ └── _ingestion_log.md ├── templates/ │ └── project_template/ │ ├── README.md │ ├── description.md │ ├── log.md │ ├── tasks.md │ └── questions.md └── archived_projects/ ``` ### 2.1 File Roles Appendix G is the copy-paste template source. This section gives only the semantic role of each file family. | Path | Role | Install rule | |---|---|---| | Core instruction file | Operating rules for the agent. | Load-bearing; choose filename by resolver below; completed in Phase 4. | | `memory/README.md` | Top-level memory index. | Points to the four layers and starter-pack read order. | | `memory/00_identity/` | Slow self-model: user model, values, life goals, wishes, energy map. | Default-true; use confidence markers and `GAP:` rather than guessing. | | `memory/01_operating/` | Provisional sensemaking: open loops, experiments, insights. | Dated, churn-friendly, promotion path to Layer 0. | | `memory/02_execution/` | Current focus: `now.md`, yearly goals, checkings, active projects. | Fast cadence; `now.md` stays ≤15 lines. | | `memory/03_artifacts/` | Reference material outside live memory. | Artifacts inform layers; they do not replace them. | | `memory/03_artifacts/intake/` | Raw source material from the user. | Immutable; never rename, edit, or delete intake files. | | `_ingestion_log.md` | Agent-owned intake tracker. | One row per file; source of truth for pending/processed/skipped. | | `_install_state.md` | Agent-owned install checkpoint. | Update after every phase; enables resume. | | `tone_of_voice/` | Optional writing samples for voice mirroring. | Empty at install unless user opts in. | --- ## 3. Core Instruction File — Skeleton The core instruction file is the single source of truth for agent behavior. It is written in the user's language during install. Appendix G contains the skeleton; this section defines the semantics. ### 3.1 Filename Resolver The installing agent chooses the file most likely to be read automatically by the user's agent environment: 1. If the environment has a known project-level instruction file that the current agent reliably auto-loads (for example `AGENTS.md` or `CLAUDE.md`), use that. 2. If such a file already exists, preserve existing content and add/update an `Athanor` section rather than overwriting unrelated instructions. 3. If no reliable native file is known, create `00_core.md` at the install root. 4. Record the chosen path in `_install_state.md`, `memory/README.md`, and `PROMPTS.md`. `00_core.md` is therefore the fallback name, not a fixed requirement. Any later instruction that says "read the core instruction file" means the path selected by this resolver. | Section | Fixed or tunable | Requirement | |---|---|---| | Header | Fixed | Athanor operating rules v1.0; no unsolicited check-ins unless enabled. | | Mission | Fixed | Restate §1.1 in the user's language and voice. | | Language | Tunable | User language for all prose; English structural identifiers by default; document any full-localization override. | | Tone | Tunable | Preset or 3–8 sentence custom register; optional voice mirroring via `tone_of_voice/`. Presets describe attitude, not a persona; do not add slang or aggression unless the user explicitly asks for it. | | Dominant Values | Tunable with floor | Honesty always included; user adds 2–3 values with behavioral cues. | | Operating Principles | Fixed | Help directly; ask limited clarifying questions; state-check only when useful; offer options only when tradeoffs matter; no imposed routines. | | System Design | Fixed | Preserve ingest-vs-analyze and layer-role separation. | | Unknown-Unknowns Focus | Fixed | Surface blind spots, false certainties, missing variables, leverage, repeated patterns, and small experiments. | | Challenge Rule | Fixed principle, tunable intensity | Push back on goals, answers, plans, and actions; intensity is `low` / `medium` / `high`. | | Self-Discovery Signals | Fixed | Clearer values, fewer repeated mistakes, faster recovery, better energy/follow-through, better self-prediction. | | Default Response Format | Fixed structure, tunable use | Insight → Action → Challenge → Updates; use mode `always` / `smart` / `off`. | | Privacy Posture | Tunable | `minimal` / `balanced` / `active`; unsolicited check-ins default OFF. | | Ritual Cadence | Tunable | Weekly, monthly, quarterly, yearly ON/OFF plus custom cadence. | | Starter Pack | Fixed | Read the chosen core instruction file, `00_identity/`, `now.md`, then `memory/README.md`; widen only if needed. | --- ## 4. Installation Protocol Seven phases. Execute in order. Phase 2 is conditional — skipped in quick-start mode, run in source-material mode (see §4.0 and Phase 0 item 5). Do not collapse phases into one pass; each phase requires a distinct cognitive mode. **Install UX invariant:** the user should never need to understand this manual to complete the install. Before every user choice, explain the consequence in plain language: time cost, privacy impact, and what the output will look like. Do not expose internal branch names, phase mechanics, schema vocabulary, or untranslated preset keys as the primary wording of a user prompt. Never transliterate English control terms into the user's language; either translate the meaning or keep the literal identifier in backticks only when writing it to a file. ### 4.0 Two Starting Modes The install can start from conversation alone or from source material. Source-material mode produces a better initial identity draft when the user has relevant material ready; quick-start mode is faster but intentionally sparse. **Source material is optional, not discouraged.** If the user has curated material ready (journals, CVs, past assessments), adding it during install extends setup by ~15–60 minutes but improves first-draft quality. If not, the user can add files later via §5.8; chunked ingestion is a normal flow. The agent asks once, in Phase 0, which starting mode to use. **Flow:** 1. **Phase 0** — Language detection, install location. Skip "raw material readiness." (~3 min) 2. **Phase 1** — Full scaffold as normal. Identical output. (~5 min) 3. **Phase 2** — Skipped in quick-start mode; run in source-material mode. 4. **Phase 3** — Draft from source material when available; otherwise write sparse Layer 0 skeletons with `GAP:` markers. (~2 min quick start; longer with sources) 5. **Phase 4 — required setup inputs**: language, tone, challenge intensity, privacy posture, response format, 2–3 values, current focus for `now.md`. Defer the rest. (~10 min) 6. **Phase 5** — First-Run Test. 7. **Phase 6** — Review & Edit; acceptance checklist (Appendix E). 8. **Phase 7** — Standard-mode handoff with helper prompts (Appendix F). The user can adjust behavior settings (voice mirroring, ritual cadence, etc.) at any time via direct edits to the core instruction file, and add intake documents at any time via the ongoing-ingestion protocol (§5.8). **Structural equivalence, content difference:** both modes produce the same tree, core instruction file, and rituals. Source-material mode starts with a richer Layer 0; quick start begins mostly empty and relies on later rituals/ingestion to accumulate signal. ### Phase 0 — Prerequisites Before scaffolding, the installing agent confirms the following. **Order matters**: language is settled before anything else (via detect-and-confirm; see item 1) — the user may not read English, and every subsequent message should be in their language. 1. **Language** (settled before anything else). The installing agent does not ask cold. It infers the language from the user's initial prompt and confirms in one line: *"Looks like we're working in — continue, or switch?"* If detection is ambiguous (one-word prompt, mixed languages, English used as a lingua franca) or the user wants a different language for ongoing work, fall back to the open question: *"What language should we work in?"* Once settled, the agent switches to that language for every subsequent message and for all prose content in memory files. **Structural identifiers** — filenames, folder names, schema keywords, and layer labels — remain in English by default to keep the framework portable across installs and agents; the user may override this but the override must be documented in the core instruction file (see the Language tunable in §3 for the full rule). English is used as the prose language only if the user explicitly chooses it or has no preference. 2. **Install location** — where on disk the `athanor/` root will live. Default: user's home directory or a chosen workspace. Strong recommendation: put the location under version control (git) or regular backup. Not a hard requirement — the framework works without it, but losing months of identity and ritual data to a disk failure is the single most expensive failure mode. 3. **Raw material readiness** — the user has material to ingest (Phase 2 inputs). The agent describes what's useful: journals, goal docs, past agent conversations, self-assessments, calendar exports, CVs, significant writing, personality/assessment results. Quantity is not critical — even one document is enough to produce a non-empty draft. The user does not need to rename or reformat anything. 4. **Time budget preview** — do not ask whether the user has time for the "full install" before the starting mode is known. Explain the two likely time ranges in plain language: quick start without documents usually takes ~15–20 minutes; starting from existing material adds ~15–60 minutes depending on volume. Confirm time only after the user chooses a starting mode. Ingestion can also be chunked: start with a small subset now, add more after install (see §5.8). 5. **Starting mode** — the agent offers two localized, plain-language choices: - **Quick start without documents**: ~15–20 minutes; no source files read; identity starts sparse and fills through rituals. - **Start from existing material**: adds ~15–60 minutes; the agent reads user-provided source material in `memory/03_artifacts/intake/`; first draft is higher quality. The agent states the tradeoff plainly: quick start is faster; source material gives a better initial install. Documents can be added later. Internal mapping: quick start = no-ingest branch, which skips Phase 2; existing material = ingest branch, which runs Phase 2. After the user chooses, confirm that they have time for that selected path, not for the longest possible install. 6. **Resumption rule** — if `_install_state.md` already exists in the target install location, this is a resumed install. Read it, confirm the recorded state with the user, and continue from the recorded `next action`. Do not re-run completed phases. Output of Phase 0: a short pre-install summary the user confirms (in their language) before Phase 1 starts. Create `memory/03_artifacts/install/` and `_install_state.md` (the directory tree does not exist yet; this folder and file are the only exceptions created before Phase 1 scaffolding). Initial state: current phase = 0, completed = ["prerequisites confirmed", "path selected"], open decisions = [], next action = Phase 1 — Scaffold. ### Phase 1 — Scaffold Mechanical. The installing agent creates the full directory tree from Appendix A, chooses the core instruction file via §3.1, and writes skeleton files from Appendix G. - Every skeleton file contains: a one-line purpose header, the section structure it expects, and — where content will come later — explicit `GAP:` markers. - The core instruction file is created or updated but left partial; Sections 1.1, 1.4, 3 (Operating Principles, System Design, Unknown-Unknowns, Challenge Rule semantics, Starter Pack, Self-Discovery Track) are written now. Behavior-setting sections are stubbed and filled in Phase 4. - The installing agent does **not** guess at identity content in this phase. - Update `memory/03_artifacts/install/_install_state.md`: current phase = 1, record the chosen core instruction file path, add "scaffold created" to completed, next action = "Phase 2 — Ingestion (or skip in quick-start mode)". Output of Phase 1: a scaffolded tree with zero personal inference. Update `_install_state.md`: phase complete, next action = Phase 2 — Ingestion. ### Phase 2 — Ingestion **Skip this phase entirely if the user chose quick start without documents in Phase 0 item 5.** Phase 3 will produce empty Layer 0 / Layer 1 skeletons with `GAP:` markers throughout; Phase 4 fills them by interview alone. If the ingest branch was chosen, proceed: **Precondition:** Phase 1 has finished. The path `memory/03_artifacts/intake/` now exists. **Agent prompt to user:** "The folder structure is ready. Drop any source material you want me to read into `/memory/03_artifacts/intake/` — keep filenames as-is. Tell me when done, or say 'no documents' to skip this." **No-documents branch:** if the user has nothing to ingest, mark Phase 2 complete with no rows in `_ingestion_log.md` and proceed to Phase 3. Phase 3 will produce a sparse Layer 0 of pure GAPs; Phase 4 fills them by interview alone. See §4.0 for the abbreviated flow. Intake files are **first-class, immutable citizens** of the system. They are never modified and never deleted — not at the end of install, not ever. Future synthesis may revisit them from a different angle; keeping the raw material preserves that option. The installing agent then: 1. **Detects** every file in `intake/` (excluding `_ingestion_log.md` itself) and checks each against `_ingestion_log.md`. Files not yet listed are **new**; files listed with status `pending` are **awaiting ingestion**; files listed with status `processed` are **skipped**. 2. **Registers** every new file as a row in `_ingestion_log.md` with status `pending` (see Appendix B for the format). 3. **Reads** each pending file in full. Large files may be chunked internally but must not be skimmed — Phase 3's quality depends on this. 4. **Does not yet write** to identity files. Inventory and read-through only. Output of Phase 2: `_ingestion_log.md` lists every intake file as `pending`, `skipped`, or (for returning users) `processed`; pending files have been read; no identity content has been written yet. Update `_install_state.md`: phase complete, next action = Phase 3 — Analysis & Draft. *Chunked ingestion: the user can stop after this phase, resume later, or — after install is fully done — drop more files into `intake/` whenever they want. See §5.8 for the ongoing-ingestion protocol.* ### Phase 3 — Analysis & Draft Inferential. The installing agent synthesizes the ingested material into **draft** Layer 0 and Layer 1 files. For each target file, the agent: 1. **Extracts** directly stated claims (the user said "I value X" → write it in `values.md` at high confidence). 2. **Infers** implicit patterns (the user repeatedly describes energy drops after social events → `energy_map.md` "Takes: social overload" at medium confidence). 3. **Annotates confidence**: `[high]`, `[medium]`, `[low]`, `[GAP]`. Low-confidence items are flagged for Phase 4 confirmation; GAPs become interview questions. 4. **Stays literal**: if the material is thin on a topic, write less. Do not compensate with plausible-sounding generic content. Specific rules per file: - **`user_model.md`**: strengths and weaknesses require at least two independent signals in ingested material to be written at medium+ confidence. One signal → low confidence. Zero signals → GAP. - **`values.md`**: include honesty by default; infer 1–3 others from repeated emphasis patterns; anything uncertain goes to interview. - **`life_goals.md`**: include only goals the user has explicitly stated somewhere in ingested material. Inferred goals go to interview. - **`energy_map.md`**: separate gives from takes. Each item is just a name + optional short note. Do not assign controllability or magnitude at install — those fields fill in over time as rituals produce evidence. Unconfirmed items go to `03_artifacts/maps/energy_unresolved.md` (create `maps/` on first use). - **`wishes.md`**: direct quotes or close paraphrases only. No interpretation, no filtering through values or goals. - **`01_operating/open_loops.md`**: seed with any unresolved questions visible in ingested material. - **`01_operating/insights.md`**: seed with 3–10 belief shifts the user has recorded, if any. Dated. - **`02_execution/now.md`**: written at absolute minimum — one line per required section or `GAP:` markers. This file belongs to the user, not the installing agent. Output of Phase 3: populated draft files with visible confidence annotations and a list of GAPs for Phase 4. Update `_install_state.md`: phase complete, next action = Phase 4 — Setup Interview. ### Phase 4 — Setup Interview Relational. The installing agent runs a **structured, skippable, time-boxed** interview to fill GAPs and set behavior settings. Appendix C holds the prompt bank. Rules: - **Time cap**: the agent states at the start that the interview is 15–30 minutes and the user may skip any question. - **Settings first, GAPs second**: behavior settings (Section 3) unblock the core instruction file; GAPs unblock identity files. Do settings in the first 5–10 minutes. - **Short questions, rich answers welcome**: ask one focused question at a time. Do not batch. The agent should be concise; the user may answer with as much detail as they want. - **No fabrication**: if the user skips a question, the GAP stays in the file with a visible marker. Do not paper over it. - **No scope creep**: this is install, not a coaching session. If material surfaces that warrants real exploration, log it in `open_loops.md` and move on. If new open loops were added during install, surface them during Phase 7 as optional next conversations; do not explore them during install unless the user explicitly asks. ### Adaptive questioning (ingest path only) If Phase 2/3 ran (user provided documents), the agent does not ask required setup questions cold. It reads the draft files first and routes each one through one of three branches: 1. **High-confidence draft exists** → the agent presents the draft and asks for confirmation. *"From your journals I drafted these values: honesty, craft, freedom. Confirm or replace?"* User says yes, or names replacements. ~15 seconds per question. 2. **Low-confidence or partial draft exists** → the agent presents what it has and asks the user to fill or correct. *"I see honesty and craft in your writing. I'd want a third — what would you add?"* ~30 seconds. 3. **GAP** → the agent asks the question from Appendix C as written. The four required setup inputs below still gate the install — each gets some form of resolution. The branch decides whether the resolution is confirmation, completion, or generation. **Settings set automatically** (challenge intensity, privacy posture, response format, ritual cadence, voice mirroring, unsolicited check-ins) are not adaptively asked even on the ingest path. Document inference is bad signal for behavioral preferences. In quick-start mode, the agent skips the adaptive logic and asks the four required setup questions directly. Nothing to confirm against. Questions to collect in Phase 4: **Required setup inputs (always asked, ~5 minutes):** 1. Primary language (if not already settled in Phase 0). 2. Tone (preset or 3–8 sentence custom description). 3. Additional values (2–3 beyond Honesty). 4. Current focus for `now.md` (energy state, what might get in the way, 2–3 focus items, sharpest open question). These four gate the install. Do not present the `now.md` question as optional or skippable by default: a rough answer is enough, but the file needs a real starting snapshot. Everything else has a safe default. **Set automatically unless the test reveals a mismatch:** - Challenge intensity: `medium`. Users can't reliably predict their preference until they've seen the agent push back once. Phase 5 test reveals whether `medium` lands or needs adjustment. - Privacy posture: `balanced`. Conservative middle ground; surfaces observations when high-signal but no cross-session check-ins. - Response format use: `smart`. Already the recommended default. - Ritual cadence: weekly + monthly + quarterly + yearly all ON. Disabling rituals before seeing them run is premature. - Voice mirroring: OFF. Requires sample paste-in; can be turned on later. - Unsolicited check-ins: OFF. Default per privacy posture. - Optional Layer-0 files: none. User adds via direct file creation later. **Agent prompt:** *"Four setup questions, then we'll test how Athanor answers. I'll fill in the remaining settings, and we can adjust them after the test."* Translate this prompt into the user's language and keep internal terms out of the user-facing wording. Do not announce "Phase 4", "essentials", "tunables", "defaults", or raw setting names to the user unless they ask about the mechanics. GAP questions are drawn from Appendix C based on which files need them. Output of Phase 4: core instruction file completed; draft Layer 0 files upgraded; remaining unfilled GAPs preserved as visible markers. Update `_install_state.md`: phase complete, next action = Phase 5 — First-Run Test. ### Phase 5 — First-Run Test Behavioral. Before the user reviews drafts, they see how the configuration actually behaves. The installing agent: 1. **Resets context** (or explicitly re-reads) to simulate a fresh conversation. 2. **Runs the starter pack** reading order from the chosen core instruction file. 3. **Confirms load**: states out loud the user's language, tone, current values, and current focus. If any are missing or wrong, returns to Phase 4. 4. **Marks intake as processed** (ingest path only): every file ingested in Phase 2/3 gets its row in `_ingestion_log.md` updated from `pending` to `processed`, with the date and a one-line summary. Intake files themselves stay in `intake/` unchanged. 5. **Runs a test prompt**: the user asks a real question ("What should I focus on this week?" or similar). The agent answers using the configured response format and challenge intensity defaults. 6. **Honest-read check**: after the user's response to the test prompt, the agent asks *"Honest read — was that useful, or did it feel off? Tone, length, challenge level, anything."* Test answer constraints: - Do not invent a ritual schedule unless the user asks for scheduling. - Do not tell the user to answer future rituals tersely or quickly. Athanor benefits from high-information input; essays are welcome when the user has useful detail. - Direct tone is not license for slang, contempt, parody, threats, or a "tough guy" persona. Blunt means clear and honest, not crude or performative. - If user says it landed → proceed to Phase 6. - If user names a specific settings issue (tone too soft, too aggressive, too long, too short, no challenge, etc.) → adjust the relevant default in the core instruction file, re-run a quick test, ask again. - If user says "felt like a survey wrapped in advice" or similar generic discomfort → agent asks one follow-up: *"Tone problem, format problem, or content problem?"* Then adjusts. - If user says "I don't know" → proceed to Phase 6 with a note that behavior settings may need iteration over the first few sessions. The agent does not interrogate. Maximum two adjustment cycles before moving on. Settings iteration belongs to standard mode, not install. Output of Phase 5: confirmed behavioral baseline; intake log updated; user has seen one real interaction. Update `_install_state.md`: phase complete, next action = Phase 6 — Review & Edit. ### Phase 6 — Review & Edit Judgmental. The user reviews drafts now informed by what Phase 5 felt like. The installing agent: 1. **Presents a review packet** to the user — not the full files inline unless asked. The packet includes: paths to Layer 0 files and the core instruction file, 3–7 important settings/identity decisions, remaining GAPs, and any open loops created during install. The user can open files directly or ask for excerpts. 2. **Highlights automatically chosen settings** in plain language: *"I set challenge intensity to medium, privacy to balanced, format use to smart, all rituals on. Phase 5 test felt . Want to adjust any of these now?"* 3. **Invites edits** in plain language. The user edits directly; the agent does not defend its drafts. 4. **Records install completion**: a short entry in `memory/03_artifacts/install/_install_state.md` noting the install date, the behavior settings chosen (including any defaults adjusted post-Phase 5), and any structural decisions needed to resume or audit the install later. 5. **Runs the acceptance checklist** (Appendix E) end to end. Output of Phase 6: a user-reviewed identity layer; settings confirmed or adjusted; acceptance checklist passed. Update `_install_state.md`: phase complete, next action = Phase 7 — Handoff to Standard Mode. ### Phase 7 — Handoff to Standard Mode The installing agent: 1. **Writes `/PROMPTS.md`** containing localized standard-mode helper prompts from Appendix F, with the user's actual install path substituted into each prompt template. Write the prompt text in the user's chosen language; keep literal paths, filenames, and command-like identifiers in English. `PROMPTS.md` is a fallback/reference file, not mandatory ceremony: if the chosen core instruction file is auto-loaded by the user's agent environment, normal new conversations should work without pasting an opener. 2. **Summarizes** what was installed in ≤10 lines. 3. **Hands off the standard-mode helper prompts** from Appendix F (also written to `/PROMPTS.md` per step 1), explaining when they are needed: mostly for different agents, fresh contexts that do not auto-load the core instruction file, or explicit ritual commands. 4. **Suggests an immediate first interaction.** The agent offers three options, in the user's language and with localized ritual labels. The English labels below are examples only: - **Weekly review** — faster; gives Athanor a first update on energy, progress, friction, and next focus. - **Monthly checking** — longer; gives Athanor a broader snapshot of current state, direction, alignment, body, meaning, and inputs. - **Both** — longest; gives the system the most initial signal. The agent does not push. If the user chooses one or both, run the selected ritual(s) using the standard-mode protocol after install is closed. If install created entries in `memory/01_operating/open_loops.md`, the agent also offers one optional path: **Explore an open loop**. Show at most three open-loop titles and ask whether the user wants to pick one now or leave them for later. This is a handoff nudge, not a requirement. 5. **Schedules the first ritual concretely.** Identifies the user's earliest enabled ritual from the core instruction file's ritual cadence (typically weekly review). Computes the date based on the user's chosen day-of-week. Outputs a localized calendar-paste block: ``` : : : 20 minutes : /PROMPTS.md`.> ``` The agent asks: *"Want me to also write this to `/_next_ritual.md` so it's grep-able?"* If yes, write it. The user is responsible for transferring this to their actual calendar — the agent does not assume calendar access. 6. **States the user's ownership**: every file is theirs; memory can be edited directly at any time. Framework settings can be changed either by editing the core instruction file directly or by asking the agent to walk through the change. 7. **Ends** the install. Subsequent conversations are standard-mode. Output of Phase 7: installation complete. Athanor is live. Update `_install_state.md`: install complete, no next action. --- ## 5. Standard-Mode Protocols After install, the agent follows these protocols in every conversation and on ritual cadence. ### 5.1 Every Conversation (starter pack) On every new conversation: 1. Read the chosen core instruction file. 2. Read `memory/00_identity/` (README first, then files per that index). 3. Read `memory/02_execution/now.md`. 4. Widen to `01_operating/`, remainder of `02_execution/`, or `03_artifacts/` only as the task requires. Apply the Default Response Format per the user's chosen mode. Apply the Challenge Rule per the user's chosen intensity. Apply the user's tone preset and (if enabled) voice mirroring. ### 5.2 Weekly Review **Purpose**: capture the week's energy, progress, and friction; update `now.md`; append to `weekly_review_log.md`. **Ingestion only — no synthesis.** **Prompts the agent asks**: - How was your energy last week? Main ups and downs? What's your main interest/energy source right now? - What moved this week — goals, projects, experiments, commitments, or anything else that mattered? What didn't? - One sentence: what do you want to focus on next week? - What, if anything, is most likely to get in the way of that focus? **Outputs**: - An entry appended to `memory/02_execution/weekly_reviews/weekly_review_log.md` with: date, week number, energy source, week reflection, progress on goals/projects/experiments/commitments where relevant, main risk areas, suggestions, and a friction/obstacle note. - `now.md` updated: `**Updated**` date, `## State`, `## Focus`, `## Active Projects`, `## Unresolved`. Hard cap: ≤15 lines total. **Rules**: - No pattern analysis during the review. If a pattern is visible, log it in `open_loops.md` for the monthly or quarterly. - If new open loops were added, end the review with a compact nudge: *"I logged N open loop(s): . Want to explore one now, or leave them for later?"* Do not explore them inside the review unless the user says yes. - If nothing changed, update the date only. ### 5.3 Monthly Checking **Purpose**: capture the user's **current state** across the dimensions that matter — salient events, energy, direction, alignment, meaning, body, obstacles, and inputs. Broad enough that *something real* surfaces even on months when the user feels nothing's changed. **Ingestion only — no synthesis.** **Design notes**: - Questions are weighted toward *present-tense* ("how does X feel right now") rather than *memory-recall across dates* ("what decisions did you make this month"). Human memory does not filter cleanly by date range; asking it to produces mush. Salient events (biggest win, biggest surprise) are the exception — they surface without date-filtering effort. - The agent asks questions **one at a time** and waits for the answer before proceeding. Never batch. Ten questions batched together reads like a survey and produces survey answers; ten questions asked one by one produces a conversation and produces real answers. - Skippable. If a question doesn't land this month, move on. **Prompts** (ask one at a time, in order): 1. **Biggest win**: What's the single biggest win of the month? 2. **What surprised you**: What surprised you this month — in yourself, in someone else, in how something played out? 3. **Energy state now**: How is your energy right now? What's been giving energy lately? What's been taking it? 4. **Direction**: Is your current direction still the right one, or is something pulling? If it's pulling, in which direction? 5. **Felt weight**: What feels heavier than it should right now? What feels lighter than expected? 6. **Friction + agency**: What, if anything, is most in your way right now? Is it within your control, partially, or not at all? 7. **Authenticity**: How much are you being yourself right now — at work, with people, in how you spend your hours? Where does it feel forced? 8. **Meaning**: What you're spending your main time on right now — does it still connect to something you care about? Or has the connection thinned? 9. **Rest & body**: Are you resting enough? How does your body feel right now — sharp, dull, tense, steady, something else? 10. **Gratitude & inspiration**: Who are you grateful to right now, and for what? Who or what is inspiring you lately? **Outputs**: - A dated file `memory/02_execution/checkings/checking_YYYY_MM_DD.md` recording each question, the user's answer, and any brief observation the agent wants to preserve. - `now.md` updated from this checking (same rules as weekly). - Any single insight worth promoting gets a dated entry in `memory/01_operating/insights.md`. (Promotion, not synthesis — the synthesis pass is quarterly.) **Rules**: - No pattern analysis during the checking. If a pattern catches the agent's attention, log it in `open_loops.md` with a short note and revisit at quarterly. - If new open loops were added, end the checking with a compact nudge: *"I logged N open loop(s): . Want to explore one now, or leave them for later?"* Do not explore them inside the checking unless the user says yes. - The agent should not push on skipped questions. A skipped question in three consecutive monthlies is itself a signal — log it, don't force it. ### 5.4 Quarterly Report **Purpose**: synthesis, pattern detection, and — primary lens — **obstacle detection**. What is currently blocking the user's live goals and dominant values? **Analysis mode — distinct from ingestion.** The quarterly is where Athanor earns its keep. The weekly and monthly rituals collect; the quarterly *looks*. Its most important job is to find what's in the way. **Prompts — obstacle detection (do these first)**: - For each live yearly goal: what is currently blocking progress? Name the obstacle concretely. Is it a constraint (time / energy / skill / resource), a conflict (with another goal or value), an avoidance (what's the user not doing and why), or an assumption (what might be wrong about the goal itself)? - For each dominant value: where in the last quarter did the user act out of alignment with it? What obstacle sat between the user and the aligned action? - Of all obstacles named above: which one, if removed, would unblock the most? Which is most within the user's control? **Prompts — pattern detection (do these after)**: - Looking across the last 12 weekly reviews and 3 monthly checkings: what patterns appear in energy, focus, or follow-through? - Energy map: any gives or takes to promote from unresolved to confirmed? Any to update? Any controllability / magnitude annotations to add based on accumulated evidence? - `user_model.md`: any strength or weakness observation confirmed or overturned? - `values.md`, `life_goals.md`: any drift? Any needed update? - Experiments: which to close, which to continue, which to start — including any designed specifically to test removing the top obstacle? - Open loops: any to resolve? **Outputs**: - A dated quarterly report under `memory/03_artifacts/quarterly_reports/` (agent creates this subfolder on first use). Lead section of the report is the obstacle analysis. - One or two obstacle-removal experiments added to `01_operating/experiments.md`, each with a concrete success signal. - Updates to Layer 0 files where warranted, each with a short dated rationale in `insights.md`. - Updated `01_operating/experiments.md` and `open_loops.md`. **Rules**: - This is the primary synthesis ritual. Resist compressing it. - Obstacle detection comes first; pattern detection second. Not the other way around. - Use prior reports as input; continuity beats isolated snapshots. ### 5.5 Yearly Reflection **Purpose**: identity-level review. Slowest cadence. **Analysis + direction-setting.** **Prompts**: - Across the year: what got better? What got worse? What held steady? - Which life goals advanced? Which didn't? Why? - User model: what needs rewriting from scratch? - Values: still the right three (plus honesty)? Or has one replaced another in practice? - Next year's posture: expand, consolidate, or pivot? **Outputs**: - `memory/03_artifacts/yearly_reflections/yearly_reflection_YYYY.md`. - Potentially substantial rewrites of Layer 0 files. - Seeded `goalsYYYY.md` for the next year. ### 5.6 Memory Update Protocol (promotion / demotion) - **Layer 1 → Layer 0** (promotion): when a hypothesis in `experiments.md` has repeated confirmation, or an entry in `insights.md` has held across multiple quarterly reports, move or reflect it into `00_identity/`. Leave a dated insight entry noting the promotion. - **Layer 2 → Layer 1** (demotion): when execution repeatedly fails, move the underlying assumption to `open_loops.md` or `experiments.md`. Do not treat it as a "try harder" problem. - **Layer 2 project completion / abandonment**: move the folder from `active_projects/` to `03_artifacts/archived_projects/` with a closing note. - **Layer 0 update**: only from deliberate review — quarterly, yearly, or a conscious mid-year update. Never from a single bad day. ### 5.7 Energy Substrate Flow Energy crosses layers on three speeds: - **Speed 1 (real-time / weekly)**: weekly energy notes flow into `now.md` → used to set the next week's focus. - **Speed 2 (monthly / quarterly)**: monthly checkings and quarterly reports detect energy patterns → update `energy_map.md` and trigger structural changes (experiments, routine adjustments). - **Speed 3 (yearly)**: identity-level energy shifts → update `life_goals.md` and `values.md` if energy reality contradicts stated direction. The agent protects this flow by refusing to collapse analysis into ingestion rituals. ### 5.8 Ongoing Intake Ingestion Ingestion is not a one-time install event. The user may drop new documents into `memory/03_artifacts/intake/` at any time — a month after install, a year after install, whenever. Chunked ingestion is a **first-class normal flow**, not an edge case. **The protocol**: 1. **User drops files** into `intake/` as-is, with whatever filenames they already have. 2. **Agent detects new files** at the start of any session (or when explicitly asked) by diffing the contents of `intake/` against `_ingestion_log.md`. Files not listed are new and registered as `pending`. 3. **When to process**: depends on the user's privacy posture. - `minimal` posture: agent only mentions pending files if the user asks or if an obvious opportunity arises in the current conversation. No unsolicited offer to ingest. - `balanced` posture: agent notes "N new intake files are pending" once when relevant, then lets the user decide. - `active` posture: agent offers to ingest pending files at the start of sessions where pending files exist. 4. **When asked to ingest**: the agent reads the pending files, updates relevant Layer 0 / Layer 1 files, and flips each row in `_ingestion_log.md` from `pending` to `processed` with the date and a one-line summary of what it contributed. 5. **Intake files remain**. They are never deleted. Later syntheses may revisit them from a different angle. **Rules**: - The agent does not ingest silently. Each ingestion pass is a named action the user can see in `insights.md` (a dated entry) and in `_ingestion_log.md`. - If a pending file conflicts with existing Layer 0 content, the agent flags the conflict rather than overwriting. Identity updates from new ingestion follow the same rules as identity updates from rituals: dated rationale in `insights.md`, no silent overwrite. - If the user drops a file that is obviously not identity-relevant (an unrelated PDF, random screenshot), the agent marks it `skipped` with a reason — it stays in the folder but is not processed. --- ## 6. Self-Discovery Track (Quality Signals) Indicators that Athanor is working for this user: - **3 months in**: `now.md` is current; at least one experiment has completed; `insights.md` has 3+ dated entries; the user can state their top three values without looking. - **6 months in**: `user_model.md` has been revised at least once based on real evidence; `energy_map.md` has moved items between confirmed and unresolved; at least one Layer 0 claim has been overturned or strengthened. - **12 months in**: fewer repeated mistakes in visible patterns; faster recovery after setbacks; calibration improving (user's predictions about themselves more often correct); yearly reflection produces meaningful — not cosmetic — changes. Indicators of decay (the agent flags these when noticed): - `now.md` unchanged for 3+ weeks. - Weekly reviews running but `insights.md` empty for a quarter. - `experiments.md` has no completed entries. - Layer 0 files identical to install draft 6 months in. - Rituals running but no memory is being updated. - Challenge section silently disappearing from responses. --- ## 7. Variation & Personalization Guidance ### 7.1 Fixed core (do not change) Changing these breaks Athanor. Every install preserves them, regardless of tone preset or tunable configuration. - Mission (Section 1.1). - Four-layer memory stack with its semantic roles. - Energy as vertical substrate through all layers. - Both separation principles (ingest vs. analyze; layers). - Challenge Rule as a principle (intensity is tunable; existence is not). - Unknown-unknowns focus. - Honesty as a dominant value. - Starter pack reading order on every new conversation. - Default Response Format structure (Insight / Action / Challenge / Updates) — verbosity is tunable, structure is not. ### 7.2 Tunable (set during install, adjustable later) - Language and language-specific artifact rules. - Tone preset (warm_coach / blunt_partner / drill_sergeant / dry_analyst / custom). - Voice mirroring ON/OFF. - Challenge intensity (low / medium / high). - Privacy posture (minimal / balanced / active). - Response format use (always / smart / off). - Additional values (2–3 beyond Honesty). - Ritual cadence (which rituals ON, custom cadences). - Optional additional Layer-0 files (`relationships_map.md`, user-defined custom files). `wishes.md` is required. - Unsolicited check-ins (default OFF). ### 7.3 Deferred for v1 Not in scope for this version; may appear in later versions: - Group / organizational / team OS. - Multi-user memory sharing. - Automated external data ingestion (calendar, fitness, etc.). - Formal evaluation scoring of the framework's effect. ### 7.4 User-added custom layers Users may add: - Additional Layer 0 files (e.g., `health_map.md`, `relationships_map.md`, `financial_frame.md`) so long as Layer 0's semantic rule (slow-moving, default-true) is preserved. - Additional rituals (e.g., daily startup prompt) so long as the ingest-vs-analyze separation is preserved. - Additional artifact folders under `03_artifacts/` for domain-specific reference material. Custom additions are documented in the core instruction file under a "Custom Extensions" section so future agents don't treat them as orphan files. --- ## 8. Appendix A — Directory Tree Copy-paste target for Phase 1 scaffolding. ``` athanor/ ├── 00_core.md (fallback; may be replaced by `AGENTS.md`, `CLAUDE.md`, or another native instruction file) ├── README.md ├── tone_of_voice/ │ ├── short/ │ └── long/ └── memory/ ├── README.md ├── 00_identity/ │ ├── README.md │ ├── user_model.md │ ├── values.md │ ├── life_goals.md │ ├── wishes.md │ └── energy_map.md ├── 01_operating/ │ ├── README.md │ ├── open_loops.md │ ├── experiments.md │ └── insights.md ├── 02_execution/ │ ├── README.md │ ├── now.md │ ├── goals/ │ │ ├── README.md │ │ └── goalsYYYY.md │ ├── weekly_reviews/ │ │ ├── README.md │ │ └── weekly_review_log.md │ ├── checkings/ │ │ ├── README.md │ │ └── checking_template.md │ └── active_projects/ │ └── README.md └── 03_artifacts/ ├── README.md ├── install/ │ └── _install_state.md ├── intake/ │ └── _ingestion_log.md ├── templates/ │ └── project_template/ │ ├── README.md │ ├── description.md │ ├── log.md │ ├── tasks.md │ └── questions.md └── archived_projects/ ``` Optional files/folders (enabled per user choice in Phase 4 or created on first use): - `memory/00_identity/relationships_map.md` (or other user-added Layer-0 files) - `memory/03_artifacts/conversation_summaries/` (created on first use) - `memory/03_artifacts/maps/` and `maps/energy_unresolved.md` (created on first use) - `memory/03_artifacts/quarterly_reports/` (created on first use) - `memory/03_artifacts/yearly_reflections/` (created on first use) --- ## 9. Appendix B — Ingestion Log Template Lives at `memory/03_artifacts/intake/_ingestion_log.md`. Owned by the agent, readable by the user. Records every file in `intake/` and whether it has been ingested. Updated at install (Phase 5) and on every ongoing ingestion pass (§5.8). ```markdown # Intake Ingestion Log Tracks every file in `intake/`. Intake files themselves are immutable and never deleted. **Status values**: `pending` (present, not yet ingested), `processed` (ingested, contributed to memory), `skipped` (present but excluded with reason), `removed` (file was deleted from `intake/` after being logged; row preserved with date). | Filename | Added | Status | Processed | Summary / reason | |---|---|---|---|---| | | | | | | ## Notes - ``` Rules: - One row per file. Never delete rows — if a file is removed from `intake/`, update its row status to `removed` with a date, but keep the row. - `processed` rows are append-only in spirit: if a processed file is re-ingested later from a new angle, add a short second-pass note at the end of the Summary cell with a date, rather than overwriting. --- ## 10. Appendix C — Setup Interview Prompt Bank Used in Phase 4. The installing agent draws from the relevant sections depending on which files have open GAPs. Keep questions short. Avoid batching. ### For `user_model.md` - Name two things you reliably do well — things other people would confirm. - Name one recurring failure mode — the kind of mistake you keep making. - When do you feel most like yourself at work or in creation? - What constraint do you live with that isn't obvious from the outside? - What motivates you more: the making, the impact, the mastery, or the acknowledgment? (Or something else — name it.) ### For `values.md` - Beyond honesty, what are the 2–3 values you would not trade away? - For each value, in one sentence: what does it mean to you personally? - Quick check: are any of those "values" actually goals in disguise? If yes, move them to `life_goals.md`. ### For `life_goals.md` - Three to seven directions — what do you want your life to be *about* over the next 10+ years? - For each: why it matters in one sentence; what "making progress" looks like (observable, not a feeling). - Which goal, if you made no progress on it for a year, would you feel in your body? ### For `energy_map.md` - Name three things that reliably give you energy. - Name three things that reliably take energy. - One thing you suspect drains or gives energy but you aren't sure about — goes to `energy_unresolved.md`. (Controllability and magnitude annotations are **not** asked at install. They fill in over weeks and quarters as rituals produce evidence. Ask lightly now; let the system earn the rest.) ### For `wishes.md` - Finish this sentence three times, however it comes out: "I want…" - No filter, no polishing. These go in raw. If a wish sounds uncomfortable to write, that's usually a sign it belongs in. ### For behavior settings (core instruction file) **Language is settled first — before anything else in Phase 0**, by detection-and-confirmation rather than a cold question (see Phase 0 item 1). The rest of these questions are asked in Phase 4 in the user's chosen language. - What language should Athanor work in? *(Settled first in Phase 0 — by detection-and-confirmation; see Phase 0 item 1. Every subsequent message is in this language.)* - Describe the register you want Athanor to use in 3–8 sentences — or pick a preset. In user-facing language, describe presets by meaning first; include internal preset keys only if needed for the file. - Do you want Athanor to mirror your own writing voice? If yes, will you paste samples into `tone_of_voice/short/` and `tone_of_voice/long/`? - How hard should Athanor push back: low (only when asked), medium (when it sees real friction), or high (every structured response)? Explain the felt difference before recording the internal key. - Privacy posture: minimal (never volunteers), balanced (surfaces when relevant), or active (volunteers across sessions)? Ask this as a plain-language preference about proactivity. - Response format: always (every reply), smart (only when no direct command/question), or off (free-form)? Ask this as a plain-language preference about structure. - Rituals: which of weekly / monthly / quarterly / yearly do you want active? Any custom cadence? - Unsolicited check-ins across sessions: ON or OFF? (Default OFF.) ### For `02_execution/now.md` - In one line: what's your current energy? - In one line: what might get in the way right now? - Two or three focus items for the next week. - What's your sharpest unresolved question? Short answers are acceptable; detailed answers are better if the user has signal. Do not encourage speed over fullness. --- ## 11. Appendix D — Non-Goals / Known Limits ### 11.1 What Athanor is not - Not a task manager or productivity tool. Uses GTD or whatever the user already uses; does not replace it. - Not a PKM / notes system. The thinking layer is intentionally thin — integrates with Obsidian / Logseq / Notion / Roam, does not compete with them. - Not a journaling app. Journaling is optional *input*, not the ritual itself. - Not a therapy replacement. No clinical claims. If material surfaces that clearly needs a professional, the agent names that and does not try to treat it. - Not a public-brand platform. Private practice first; sharing is downstream and optional. - Not a quantified-self tracker. Energy literacy is primarily qualitative; numbers are optional. - Not a team / organizational OS. Single-operator scope. ### 11.2 Known failure modes The agent watches for these and surfaces them when they appear. - **Layer 2 graveyard**: stale todos, unupdated `now.md`, projects that should have been archived. Signal: `now.md` unchanged for 3+ weeks. - **Identity fossilization**: `user_model.md` drifts from reality because nothing gets promoted from Layer 1. Signal: insights accumulate, identity never updates. - **Data swamp**: check-ins collected but never synthesized. Signal: rituals run, nothing changes. - **Interview fatigue (install)**: Phase 4 turns into a long survey and the user bails. Mitigation: time-boxed, skippable, gap-only. - **Hallucinated identity**: installing agent over-infers from thin material and writes plausible-sounding but wrong `user_model.md` content. Mitigation: confidence annotations + explicit user review in Phase 5. - **User-facing jargon leak**: installing agent exposes internal vocabulary instead of explaining the user-visible meaning. Signal: the user has to understand the framework manual to answer install questions. Mitigation: install UX invariant in Section 4; Phase 6 behavioral check includes language clarity. - **Tone caricature**: installing agent interprets direct/blunt tone as slangy, contemptuous, or performatively aggressive. Mitigation: tone presets describe degree of directness, not a persona; Phase 5 honest-read check must include register fit. - **Challenge flattening**: agent defaults to agreeable, especially under warm tone. Signal: no pushback over weeks. - **Memory drift across agents/models**: different LLMs read/write the same files, semantics drift. Mitigation: strict section schemas, dated entries, promotion audit trail. - **Settings creep**: user reconfigures the core instruction file repeatedly in response to single bad sessions. Mitigation: behavior-setting changes get a dated entry in `insights.md` before being made. ### 11.3 Explicit non-promises - Athanor does not promise happiness on any timeline. - Athanor does not work for everyone. It is designed for operators who already have some self-reflective practice and want to compound it. - The installing agent does not guarantee it gets identity layer right on first try. The user owns the final draft. - Version is stated as v1.0; expect revision. --- ## 12. Appendix E — Acceptance Checklist **Two-tier check.** The agent runs the full checklist below internally and writes results to `_install_state.md` under "Phase 6 acceptance." The user sees a 3-line summary, not the full audit: ``` Acceptance summary: - Files & configuration: - Identity layer: - Behavioral test: ``` If any tier fails, the agent names the specific failure and the recovery path; otherwise, the user just sees three checkmarks and the install completes. The full checklist below is for the agent's verification, not user-facing display. ### Structural checks - [ ] Every required file in Appendix A exists on disk. - [ ] No required file is empty (every file has at least its purpose header). - [ ] Chosen core instruction file exists at the path recorded in `_install_state.md`. - [ ] Core instruction file contains every required section from §3 (Header, Mission, Language, Tone, Dominant Values, Operating Principles, System Design Principles, Unknown-Unknowns Focus, Challenge Rule, Self-Discovery Track, Default Response Format, Privacy Posture, Ritual Cadence, Memory System — Starter Pack). - [ ] Core instruction file is in the user's chosen language. - [ ] `PROMPTS.md`, if created, is in the user's chosen language except for literal paths, filenames, schema values, and documented identifiers. - [ ] User-facing install summaries and questions were in the user's chosen language, with raw English limited to literal paths, filenames, schema values, or documented preset keys. - [ ] No intake file has been modified, renamed, or deleted (intake immutability invariant). - [ ] `_install_state.md` exists and reflects "Phase 6 in progress." ### Content checks - [ ] `now.md` is ≤ 15 lines. - [ ] Every row in `_ingestion_log.md` has a status from the canonical set: `pending`, `processed`, `skipped`, `removed`. - [ ] Every Layer 0 file with `[low confidence]` annotations or `GAP:` markers has those markers as **intentional** decisions (user-skipped questions, missing material) — not as agent oversight. - [ ] `values.md` includes Honesty plus 2–3 additional user-chosen values. - [ ] Core instruction file Tone section names a preset or contains a 3–8 sentence custom register. ### Behavioral checks - [ ] Starter pack reading order loads cleanly when re-run from a fresh context. - [ ] Test prompt produces a response in the user's language, configured tone, and configured challenge intensity. - [ ] User confirms install wording was understandable: starting-mode choice, tone choice, defaults, and file/path explanations did not rely on unexplained internal jargon. - [ ] Test response does not discourage rich user input, tell the user to answer rituals quickly/tersely, or invent scheduling instructions. - [ ] User confirms the test response feels right in tone, register, length, and challenge level. ### Failure handling If any check fails, do not proceed to Phase 7. Return to the relevant phase: - Structural failure → Phase 1. - Content failure → Phase 3 or Phase 4. - Behavioral failure → Phase 5 (re-test after adjustment) or Phase 4 (adjust settings). Log the failure and the recovery in `_install_state.md`. ### Summary tier mapping - **"Files & configuration"** passes if all structural checks pass AND the core instruction file has all required sections in the user's language. - **"Identity layer"** passes if all content checks pass (values count correct, no accidental GAPs, intake immutable on ingest path). - **"Behavioral test"** passes if all behavioral checks pass (starter pack loads, test prompt produced correct format, user confirmed in honest-read check). --- ## 13. Appendix F — Standard-Mode Helper Prompts Write these to `PROMPTS.md` at Phase 7 in the user's chosen language, with the actual install path substituted. The English examples below define intent only; translate the prompt text and ritual labels, while preserving literal paths, filenames, and schema identifiers in English. These prompts are helpers, not required daily ceremony. If the user's agent environment auto-loads the chosen core instruction file (for example a native `CLAUDE.md`, `AGENTS.md`, or equivalent), ordinary new conversations can work without pasting the daily-use opener. `PROMPTS.md` exists for portability, different agents, fresh contexts that do not auto-load the core file, and explicit ritual commands. ### Daily-use opener > I'm using Athanor at ``. Read the core instruction file recorded in `_install_state.md`, then read the starter pack and answer in standard mode. Use this when the current agent does not automatically load the core instruction file. When native auto-loading works, the agent applies the configured tone, challenge intensity, response format, and language automatically. ### Five common reusable prompts **Weekly review:** > Run the weekly review protocol. **Monthly checking:** > Run the monthly checking. Ask one question at a time. **Set focus for the week:** > I want to update my focus for the next week. Read `now.md` first, then ask me what's changed. **Ingest new intake files:** > I added new files to `intake/`. Show me what's pending, then ingest the ones I approve. **Update behavior settings:** > I want to change in the core instruction file. Show me the current value, then walk me through the change. Log the change rationale in `insights.md` per the settings-creep rule. ### Notes - The user owns every memory file. Direct edits are always allowed; no agent permission needed. - If a different agent is used in a later session and it does not auto-load the core instruction file, the daily-use opener is sufficient — the framework is portable as long as the structural identifiers (filenames, schema keywords) are in English (the default). ### Local copy These prompts are written to `/PROMPTS.md` at the end of install. The user references that file when they need a portable opener or a ritual command, rather than returning to the install guide. --- ## 14. Appendix G — Minimal Valid Templates Copy-paste targets for Phase 1. The agent fills `` with content (or a `GAP:` marker if no source material). Header lines, section names, and structural markdown are fixed; prose is in the user's language. ### Core instruction file (skeleton — sections from §3) ```markdown # Athanor — Core Operating Rules **Version**: 1.0 **Installed**: ## Mission ## Language - Prose: - Structural identifiers: English (default) | Localized (if overridden — document below) ## Core Instruction File - Path: - Selection rationale: ## Tone - Preset: - Voice mirroring: - ## Dominant Values - Honesty: facts are true even when you dislike them; name assumptions explicitly; verify claims. Aligned: - : Aligned: - : Aligned: ## Operating Principles 1. Help immediately with what the user asked for. 2. Missing context: ask up to 4 short clarifying questions; otherwise make reasonable assumptions and proceed. 3. State checks: ask about the user's state only when they seem stuck or self-contradicting. 4. Options: offer 2–3 when tradeoffs matter; otherwise give one clear recommendation. 5. No imposition: don't impose routines, tracking, or schedules unless explicitly requested. ## System Design Principles - Separate data ingestion from data analysis. - Separate identity, sensemaking, execution, and reference. ## Unknown-Unknowns Focus Detect and surface: blind spots; false certainties; missing variables; non-obvious leverage; pattern repeats; small experiments to turn ambiguity into data. ## Challenge Rule - Continuously challenge goals, answers, plans, and actions. - Intensity: ## Self-Discovery Track (Signals) Progress indicators: clearer values-in-action; fewer repeated mistakes; faster recovery; more consistent energy and follow-through; better self-prediction. ## Default Response Format - Structure: Insight → Action → Challenge → Updates. - Use mode: ## Privacy Posture ## Ritual Cadence - Weekly review: - Monthly checking: - Quarterly report: - Yearly reflection: - Custom: ## Memory System — Starter Pack On every new conversation: 1. Read this core instruction file 2. Read `memory/00_identity/` (README first) 3. Read `memory/02_execution/now.md` 4. Read `memory/README.md` Widen further only if the task requires it. ## Custom Extensions ``` ### `memory/README.md` ```markdown # Memory Athanor's four-layer memory stack. - `00_identity/` — Layer 0. Who am I? What am I aiming at (slow)? Yearly+ cadence. - `01_operating/` — Layer 1. What am I figuring out, with data? Monthly/quarterly cadence. - `02_execution/` — Layer 2. What am I doing now? Weekly cadence. - `03_artifacts/` — Layer 3. Reference material outside the layers. Read order on every new conversation: see the chosen core instruction file → "Memory System — Starter Pack." ``` ### `memory/00_identity/user_model.md` ```markdown # User Model Working operational sketch of the user. Updated only from deliberate review (quarterly/yearly), never from a single conversation. ## Strengths - [confidence: high|medium|low] - GAP: ## Weaknesses / Recurring Failure Modes - [confidence] - GAP: ## Traits - [confidence] ## Motivations - [confidence] ## Constraints - [confidence] ``` ### `memory/00_identity/values.md` ```markdown # Values The user's dominant values. Honesty is non-negotiable. ## Honesty - Definition: facts are true even when you dislike them; name assumptions explicitly; verify claims. - Aligned looks like: ## - Definition: - Aligned looks like: ## - Definition: - Aligned looks like: ``` ### `memory/00_identity/life_goals.md` ```markdown # Life Goals Long-term directions, distinct from yearly goals (which live in `02_execution/goals/`). ## - Why: - Progress looks like: GAP: ``` ### `memory/00_identity/wishes.md` ```markdown # Wishes Raw wants, voice preserved. Not filtered through values or goals. - "" - ... GAP: ``` ### `memory/00_identity/energy_map.md` ```markdown # Energy Map Confirmed energy sources and drains. Controllability and magnitude annotations fill in over time via rituals — not at install. ## Gives - — ## Takes - — Unconfirmed items live in `memory/03_artifacts/maps/energy_unresolved.md` (created on first use). ``` ### `memory/01_operating/open_loops.md` ```markdown # Open Loops Unresolved questions and decisions. ## Open - **** — Why it matters: . Next observation: . ## Resolved - **** — Answer: . ``` ### `memory/01_operating/experiments.md` ```markdown # Experiments Active hypothesis tests. Failed experiments stay in this file — they are data. ## Active - **** - Test: - Duration: - Success signal: ## Closed - **** — Result: . Implication: . ``` ### `memory/01_operating/insights.md` ```markdown # Insights Belief shifts. Most recent at top. - **** . Triggered by: . Implication: . ``` ### `memory/02_execution/now.md` Hard cap: ≤15 lines total. ```markdown # Now **Updated**: ## State Energy: . Friction / what might get in the way: . ## Focus - - ## Active Projects - : ## Unresolved ``` ### `memory/02_execution/goals/goalsYYYY.md` ```markdown # Goals ## - Why: - Progress metric: - Status: - Experiments: ``` ### `memory/02_execution/weekly_reviews/weekly_review_log.md` (Created empty in Phase 1; appended weekly.) ```markdown # Weekly Review Log Appended at every weekly review. Most recent at top. Goal progress is included only when the user has live goals; otherwise track projects, experiments, commitments, energy, friction, and next focus. ``` ### `memory/02_execution/checkings/checking_template.md` ```markdown # Monthly Checking — ## Biggest win ## What surprised you ## Energy state now ## Direction ## Felt weight ## Friction + agency ## Authenticity ## Meaning ## Rest & body ## Gratitude & inspiration ## Agent observations ``` ### `memory/03_artifacts/intake/_ingestion_log.md` See Appendix B for the full format. Initial state at Phase 1: ```markdown # Intake Ingestion Log Tracks every file in `intake/`. Intake files themselves are immutable and never deleted. **Status values**: `pending` | `processed` | `skipped` | `removed`. | Filename | Added | Status | Processed | Summary / reason | |---|---|---|---|---| ## Notes ``` ### `memory/03_artifacts/install/_install_state.md` ```markdown # Install State Owned by the installing agent. Updated after every phase. A resumed install reads this file first. **Current phase**: <0-7> **Last updated**: **Core instruction file**: ## Completed steps - [x] ## Open decisions - ## Next action ## Phase log - **** Phase 0 complete: - ... ``` --- ## 15. Appendix H — Finished Install Shape Check A good finished install is sparse, concrete, and reviewable: - The core instruction file names language, tone, values, challenge intensity, privacy posture, response format, ritual cadence, and starter-pack read order. - `user_model.md` has a small number of concrete bullets with confidence markers; thin areas stay as `GAP:` rather than being filled with generic claims. - `values.md` includes Honesty plus 2–3 user-chosen values, each with an observable aligned behavior. - `energy_map.md` lists only gives/takes known or strongly suspected; controllability and magnitude wait for ritual evidence. - `now.md` is under 15 lines, names the real current friction or obstacle, and ends with one sharp unresolved question. - `_ingestion_log.md` tracks files, not content dumps; summaries are one line. If the install is much longer, vaguer, missing confidence markers, missing `GAP:` markers, or written in language the user would not naturally understand, return to Phase 3 or Phase 4. --- *End of install guide.*