# Client Agent Workspace Setup v0 **Status / authority:** Current client-readable setup specification; v0 applied-protocol support **Effective date:** 2026-08-04 **Dependencies:** `Client_Agent_Navigation_Standard.md`; `Client_Agent_Workspace_Templates.md`; `../LEGANT_METHOD_REFERENCE.md` **Supersedes:** Earlier ARC-first workspace setup routing where it conflicts. Existing client workspaces change only through their local controls. **Purpose:** Reusable setup process for full-engagement client-owned Innate Edge agent workspaces. Use this when the client's Operating Manual is ready to become a working navigation system for the client and their agents. This is a versioned, client-readable setup specification. Revise it when new implementations reveal a generalizable improvement. --- ## Objective Create a client-owned navigation layer that lets future agents help the client make more congruent, coherent, and contributing decisions without re-reading the whole archive. The workspace should: - make the current Operating Manual hypothesis usable for real decisions; - preserve factual life/project context; - keep the client's self-model visible but provisional; - route facts differently from interpretations; - make live projects easy to pressure-test; - preserve navigation continuity as agents work with the client; - record what changed and why. ## Setup Boundary The client workspace is for the client and their agents. It should include client-owned context and the client-readable Legant Method, including relevant Innate Edge applied protocols. Do not include: - maintainer-private notes or decompressions; - other client folders; - private production, proposal, or output folders; - raw methodology production files that are not client-readable; - private strategic context unless the maintainer explicitly decides it is client-owned. Shared methodology stays read-only. Client-specific context lives in the client folder. Recommended access pattern: ```text / Access_Manifest.md README.md .md Innate Edge/ / ``` The parent client folder routes people to the shared and private workspaces. Keep it clean enough that the maintainer can explain the access model in one sentence. The shared client folder holds client-owned sources, current deliverables, and agent context. The private sibling holds maintainer-private decompressions, strategy notes, internal production chains, unverified research, and calibration material not written for client access. ### Folder Hygiene Principles Use these principles before deciding where any file belongs: 1. **Access boundary first.** If the client and their agents can use it without seeing maintainer-private judgment, it can live in the shared workspace. If not, it goes in `/`. 2. **Human-readable shared root.** The shared workspace should be navigable by the client, not only by agents. Keep the latest official deliverable files at the top level; tuck system files, source ledgers, reference indexes, and archive material away. 3. **Latest official docs at eye level.** Current OM / Positioning / active deliverables belong in the shared root. Historical deliverables belong in `Historical Deliverables/`. 4. **Source material is organized by epistemic role.** Evidence should help an agent know what kind of source it is reading: psychometrics, qualitative input, evidence extraction, transcripts, or deliverables. 5. **No duplicate truth.** Do not leave the same source group in both the parent folder and shared workspace. Preserve superseded copies in private maintainer storage if needed; do not leave them where future agents will treat them as current. 6. **Transcripts are client-owned unless they are decompressions.** Raw client conversations can live in the shared workspace. Maintainer decompressions, Decoder interpretations, strategy notes, and internal session artifacts go private unless the maintainer promotes a specific point. 7. **Preserve before deleting.** When cleaning a messy historical folder, move internal or superseded material into private preservation buckets first. Delete only generated cruft or confirmed duplicates. 8. **Folder polish is not the goal.** A clean folder is useful only if it improves agent judgment, client navigation, and source discipline. ## Setup Depth Use a baseline + expansion model. **Baseline setup** creates the smallest context layer an agent needs to orient itself: rules, source map, timeline, current state, extended operating manual, open questions, navigation log, and changelog. For full-engagement clients, do not stop at the client-facing OM. The core handoff is the agent-operating overlay: an expanded `Personal_Operating_Manual.md` that translates the current OM hypothesis into decision guidance, language guidance, watch points, and falsifiers. The extended OM should translate the formal OM and positioning work into an agent-usable overlay: a compact wiring summary, natural decision ritual, cross-domain mechanism table, engine/fuel boundary, scatter/nozzle patterns, language that lands, active-vehicle cheatsheet, and update signals. It should not replace the formal OM or absorb the whole archive. It should make the map usable in live decisions and route unresolved project questions to context pages. Show evidence anchors explicitly. The client remembers their own examples; an agent does not. Add a compact evidence-anchor key when the folder contains transcripts, evidence ledgers, or post-OM reception data. Use it to keep claims grounded without turning the OM into an evidence dump. **Deep synthesis expansion** is needed when the client has a rich or messy archive: multiple transcripts, older reports, evidence workbooks, evolving archetype language, positioning work, or active vehicles that depend on subtle interpretation. Deep synthesis adds three jobs: - source coverage: what has been processed, lightly represented, or left untouched; - transcript indexing: what each conversation contains and where it should feed the wiki; - development arc: how the self-model evolved across time, so the latest frame is not treated as ahistorical truth. Every setup must say whether deep synthesis was needed, skipped, or deferred. ## Minimum Folder Pattern Use exact names where possible. If a client already has a reasonable equivalent, keep the existing name and note the mapping in `Agent System/Reference_Index.md`. Use `Client_Agent_Workspace_Templates.md` for copyable skeletons when helpful. Templates are starting points, not required forms. ```text / README.md CLAUDE.md Access_Manifest.md .md Innate Edge/ / # separate; never shared by default ``` Build the shared workspace as a usable client packet: ```text Innate Edge/ AGENTS.md CLAUDE.md README.md _Operating_Manual_.pdf _Operating_Manual_.docx _Operating_Manual_Draft_.md Historical Deliverables/ Transcripts/ Evidence/ Psychometrics/ Qualitative Input/ Evidence Extraction/ Agent System/ Reference_Index.md Methodology_Library.md Source_Change_Log.md Source_Coverage_Ledger.md Wiki/ Timeline.md Current_State.md Personal_Operating_Manual.md Development_Arc.md Decisions_and_Open_Questions.md AI_Working_Preferences.md Navigation_Log.md Conversation_Transcript_Index.md _changelog.md Projects/ / _Context_Brief.md ``` Baseline setup can skip `Development_Arc.md`, `AI_Working_Preferences.md`, and project pages if the client has a thin source base and no active vehicle yet. Do not skip `AGENTS.md`, `Agent System/Reference_Index.md`, `Wiki/Timeline.md`, `Wiki/Current_State.md`, `Wiki/Personal_Operating_Manual.md`, `Wiki/Decisions_and_Open_Questions.md`, `Wiki/Navigation_Log.md`, or `Wiki/_changelog.md`. Do not default to `Raw Sources/` as the shared folder pattern. That name is too archive-like and tends to hide what humans and agents need. Use explicit folders: `Transcripts/`, `Evidence/`, and `Historical Deliverables/`. ## Setup Steps ### 1. Inventory Sources Create or update `Agent System/Reference_Index.md` and `Agent System/Source_Coverage_Ledger.md`. Capture: - current Operating Manual or equivalent self-model; - positioning report or vehicle strategy, if any; - transcripts and session notes; - active project files; - client-authored notes; - current open decisions; - source files not yet synthesized. Also inventory source ownership: - shared client-owned; - maintainer-private; - internal production residue; - duplicate/superseded; - unverified external/public research; - generated cruft. Move each source group into the access zone that matches its ownership before building the wiki layer. For rich archives, give each source a coverage status: - `Processed in wiki`: directly synthesized into named wiki pages. - `Lightly represented`: partially reflected, but not deeply processed. - `Evidence-extracted only`: captured in an evidence workbook but not translated into agent context. - `Unprocessed`: known source, not yet used. - `Reference/duplicate`: useful for traceability, not a primary synthesis source. Do not over-synthesize yet. The first job is to know what exists, what has been used, and whether the setup needs a deep synthesis pass. ### 1A. Clean The Folder Shape Before writing agent context, make the folder itself tell the truth. Parent client folder: - keep only routing/admin files plus the shared and private sibling folders; - move current shareable deliverables into ` Innate Edge/`; - move internal workshopping, decompressions, unverified research, and duplicate legacy source folders into `/`; - remove empty old shells like `evidence/`, `source-data/`, `transcripts/`, `deliverables/`, or `Decode Report Work/` from parent level after preserving their contents. Shared workspace: - put the latest official deliverables at root; - put older official deliverables in `Historical Deliverables/`; - put raw client transcripts in `Transcripts/`; - put evidence/source data in `Evidence/`; - put agent control files in `Agent System/`; - keep `Wiki/` for agent-readable summaries, not raw archives. Recommended evidence subfolders: ```text Evidence/ Psychometrics/ Qualitative Input/ Evidence Extraction/ ``` Use different names if the client's archive already has clearer names, but keep the epistemic split. Agents should know whether they are reading measured inputs, first-person/client-provided input, third-party qualitative input, or extracted analytical evidence. ### 2. Establish Agent Rules Create or update `AGENTS.md`. It must include: - agent role: long-horizon alignment advisor; - load order; - source boundary; - context update routing; - navigation continuity / after-handoff logging loop; - raw-sources-win rule; - client-specific challenge style; - things the agent should not assume. Keep it compact. `AGENTS.md` is behavioral infrastructure, not a report. ### 3. Point To Shared Methodology Create or update `Agent System/Methodology_Library.md`. It must point to: - the [shared Legant Method Library](https://drive.google.com/drive/folders/1PSWz-bzXrZs8upcQAufN3jpiDsfAoaZK) or its local synced root; - `Client_Agent_Navigation_Standard.md`; - `Client Agent Reply Standard.md`, if used; - relevant Innate Edge, Positioning, and Navigation sources named by the Legant Method Reference. State that methodology is read-only and client-specific updates belong in the client workspace. ### 4. Build The Wiki Layer Populate the core wiki pages: - `Timeline.md`: source-anchored factual chronology. No interpretation except brief source notes. - `Current_State.md`: what is alive now; active vehicles, constraints, pending decisions. - `Personal_Operating_Manual.md`: current self-model map, clearly marked as provisional where needed. - `Development_Arc.md`: how the current self-model evolved across earlier frames, reports, and lived evidence. - `Decisions_and_Open_Questions.md`: unresolved choices and self-model update signals. - `Navigation_Log.md`: episode-level continuity ledger for meaningful navigation interactions. - `Conversation_Transcript_Index.md`: transcript ledger and processing status. - `_changelog.md`: newest-first trace of context updates and self-model changes. Before generating `Personal_Operating_Manual.md`, read `Client_Agent_Navigation_Standard.md`. The governing question is: > What would a future agent need to know about this client's durable wiring to help them make a more congruent, coherent, contributing decision? Use these routing principles: - **Client-facing OM:** the distilled, client-usable map produced by the OM process. Treat the current version as good enough unless the maintainer explicitly asks to reopen it. - **Extended OM / `Personal_Operating_Manual.md`:** the agent's slow wiring map. Because the agent does not have the client's memory, major claims should connect to concrete examples, source pointers, or evidence summaries elsewhere in the folder. Claims without anchors should be marked as hypotheses or gaps. - **Context pages:** live terrain. Use them for current situation, active projects, recent decisions, constraints, open questions, and navigation history. - **Source / evidence:** the reservoir. New evidence can feed the log of possible OM refinements, but it should not silently rewrite the wiring map. `Personal_Operating_Manual.md` is the slow map: the client's relatively stable wiring, recurring mechanism, energy pattern, sources of scatter, nozzle conditions, decision filters, and enduring watch points. The map is a hypothesis and can be refined when better evidence reveals the wiring more accurately. But it should not drift just because the client's projects, mood, constraints, or current chapter changes. Use context pages for live terrain: current projects, recent evidence, active decisions, open questions, constraints, and navigation history. Navigation uses both: - `Personal_Operating_Manual.md` = slow map of durable wiring. - `Current_State.md`, project briefs, `Decisions_and_Open_Questions.md`, and `Navigation_Log.md` = live terrain. When writing the extended OM, include only context that clarifies the durable wiring or helps an agent apply it. Do not turn it into a biography, project tracker, or archive summary. When translating from a client-facing OM into the extended agent OM, preserve the parts that make the manual usable in a live decision: - the client's natural decision ritual, phrased the way the client or their agent would actually use it; - the mechanism sequence, not just one label or Verb; - the distinction between core engine work and fuel, play, practice, favors, maintenance, curiosity, or rest; - the pattern to check when the client wants to leave, redesign, reshape, or hand off something; - boundary tradeoffs: what the client consciously gives up by honoring the boundary; - update signals: what future evidence would strengthen, weaken, or refine the map. Use project context briefs for active vehicles that need pressure-testing. ### 5. Route Updates By State Type Follow `Client_Agent_Navigation_Standard.md`. Auto-update directly when the claim is factual, source-backed, low-inference, decision-relevant, and in-scope. Route as an open question, update signal, or approval diff when the claim changes meaning: - self-model; - strategy; - positioning; - durable pattern; - interpretation; - what an event proves; - whether a live question is resolved. Routing test: - If it says what happened, update and log. - If it says what it means, route it. - If it is true but low-value, leave it out. ### 6. Create Project Briefs For Live Vehicles For each active vehicle, create a context brief only if it will materially improve agent guidance. A project brief should answer: - what the project is; - why it matters to the client's current chapter; - current status; - what decisions are live; - what risks or scatter patterns to watch; - what evidence would clarify fit. Do not create project pages for dormant interests unless the client is actively deciding around them. ### 7. Run Canary Tests Run at least two canaries before calling the setup ready. Generate canary prompts from the client's actual context. Phrase them the way the client would naturally ask an agent for help, not as internal evaluation instructions. Canary A: **Routing** Use a client-natural prompt that contains mixed facts and interpretations. The agent should update or recommend updating facts, route interpretation, and avoid turning maintainer or client interpretation into settled truth. Canary B: **Advice** Use a client-natural prompt about a real or realistic live pressure-test. The agent should: - name files read; - separate map from evidence; - apply 3C; - preserve uncertainty; - push back if needed; - end with a stepping stone, sharper decision question, or reason no next step is appropriate. ### 8. Record Deviations Every setup should leave a short note in `Wiki/_changelog.md` or `Agent System/Source_Change_Log.md` with: - what was created or changed; - what sources were used; - what was intentionally skipped; - whether deep synthesis was used, skipped, or deferred; - what broke or felt client-specific. If a setup needs a different page, file name, or sequence, record why. These deviations are inputs for improving the shared protocol. For folder cleanup, also record: - what was moved into the shared workspace; - what was moved into maintainer-private; - what duplicate or old parent-level folders were removed; - any source category that still feels messy and should improve the next version of the standard. ### 9. Seed Navigation Log Create `Wiki/Navigation_Log.md`. The log tracks meaningful navigation episodes, not full transcripts. Use it when an agent helps with a decision, doubt, project pressure-test, self-model question, or live evidence update. Each entry should capture only what future agents need: - date; - actor; - platform or chat locator, if available; - topic / decision / doubt; - sources read; - agent recommendation; - client response, if known; - chosen stepping stone; - evidence to watch; - context updates made or proposed. Use simple status values: `Active`, `Closed`, `Deferred`, or `Interrupted`. The log is for real navigation episodes, not canary outputs. Do not log canary tests unless the maintainer or client explicitly wants the test treated as a real context artifact. ### 10. Define The After-Handoff Loop The workspace should get smarter through use. After handoff, when an agent helps with meaningful navigation, it should: - start a `Navigation_Log.md` entry before giving substantive advice; - use the map -> reality -> 3C -> stepping stone -> update signal loop; - update factual context directly when the change is source-backed, low-inference, decision-relevant, and in scope; - route self-model, strategy, positioning, and interpretation changes as open questions or update signals; - update `Agent System/Source_Change_Log.md` when client-owned source material changes; - leave interrupted or unresolved episodes open rather than inventing closure. ## Definition Of Done A workspace is ready for pilot testing when: - `AGENTS.md` gives the agent role, load order, routing rule, source boundary, and client-specific challenge style. - `Access_Manifest.md` documents the shared client workspace, shared methodology access, private maintainer sibling folder, and excluded internals. - The parent folder contains only routing/admin files plus ` Innate Edge/` and `/`. - The shared workspace root is human-readable and contains current official deliverables. - Historical deliverables, transcripts, evidence, wiki pages, and agent system files are separated. - `Agent System/Reference_Index.md` lists source, wiki, project, and methodology pointers. - `Agent System/Methodology_Library.md` points to the shared client-readable methodology and Navigation standard. - `Agent System/Source_Coverage_Ledger.md` names what has been processed, lightly represented, evidence-extracted only, unprocessed, or intentionally skipped. - `Timeline.md` exists and can answer basic chronology questions. - `Current_State.md` states what is alive now. - `Personal_Operating_Manual.md` gives the current self-model map without pretending it is final truth. - If the archive is rich, `Development_Arc.md` explains how the current model evolved and why any older frame was retained, revised, or retired. - `Decisions_and_Open_Questions.md` holds live choices and update signals. - `Navigation_Log.md` exists and is ready to preserve meaningful navigation episodes as they begin. - `_changelog.md` records the setup. - At least one live pressure-test canary passes. - The after-handoff update loop is clear in `AGENTS.md` or the local workspace instructions. - Known gaps are named rather than hidden. ## Full-Engagement Handoff Threshold A workspace is complete enough for full-engagement handoff when: - all client-owned source groups are inventoried, including deliverables, transcripts, evidence workbooks, project notes, client-authored notes, and known gaps; - the access boundary is visible in the folder structure: shared material is in ` Innate Edge/`, maintainer-private material is in `/`, and parent-level clutter has been removed; - evidence/source material is grouped by role, not dumped into one opaque archive; - the current OM hypothesis has been translated into `Personal_Operating_Manual.md` as an agent-operating overlay with decision filters, language guidance, watch points, and falsifiers; - major chronology-dependent sources are represented in `Timeline.md`, and rich archives have either `Conversation_Transcript_Index.md` / `Development_Arc.md` or an explicit deferral note; - `Current_State.md`, `Decisions_and_Open_Questions.md`, and any live project briefs make the client's active decisions pressure-testable; - `Navigation_Log.md` and `AGENTS.md` make the after-handoff use-and-update loop clear; - the canary test shows the agent can separate facts, evidence, interpretation, and self-model update signals; - remaining gaps are named and do not block useful navigation. ## Validation Sequence Validate first against a completed workspace, then against a different client's workspace, and finally against a complex case where the client, methodology owner, and agent operator roles overlap. Record which elements generalize and which remain client-specific before revising the shared protocol. ## What Not To Overbuild Do not create a full personal operating system before the client has live use for it. Do not create a separate page for every framework. Do not reorganize for aesthetic neatness alone. Reorganize when the current structure violates the access boundary, hides current official deliverables, duplicates source truth, or blocks reliable agent use. Do not make the agent dependent on maintainer-private context for client-owned guidance. Do not treat a polished folder as proof that the agent gives good advice. The canary tests are the proof.