--- name: remote-viewing locale: caveman-lite source_locale: en source_commit: 82c77053 translator: "Julius Brussee homage — caveman" translation_date: "2026-04-26" description: > AI intuitive exploration for approaching unknown codebases, problems, or systems without preconceptions. Adapts the Coordinate Remote Viewing protocol to AI investigation: cooldown (clear assumptions), staged data gathering (raw signals → dimensional → analytical), AOL management (separating observations from premature labels), and structured review. Use when investigating an unfamiliar codebase with unknown architecture, debugging a problem where premature hypotheses could mislead, exploring a domain with limited context, or when previous attempts have been led astray by assumptions and "beginner's mind" would be more productive. license: MIT allowed-tools: Read Glob Grep metadata: author: Philipp Thoss version: "2.0" domain: esoteric complexity: intermediate language: natural tags: esoteric, remote-viewing, exploration, investigation, assumption-management --- # Remote View Approach an unknown codebase, problem, or system using the Coordinate Remote Viewing protocol adapted for AI investigation — gathering raw observations before forming conclusions, managing premature labeling (Analytical Overlay), and building understanding through staged data collection. ## When to Use - Investigating an unfamiliar codebase where the architecture is unknown - Debugging a problem where the root cause is not obvious and premature hypotheses could mislead - Exploring a domain or technology you have limited context about - When previous investigation attempts have been led astray by assumptions - Approaching any problem where "beginner's mind" would be more productive than pattern matching ## Inputs - **Required**: A target to investigate (codebase path, problem description, system to understand) - **Required**: Commitment to blind approach — resist forming conclusions until data collection is complete - **Optional**: Specific questions to answer about the target (save for Stage V) - **Optional**: Prior meditation session for assumption-clearing (see `meditate`) ## Procedure ### Step 1: Cooldown — Clear Assumptions Transition from assumption-heavy mode into receptive observation. This step is non-negotiable. 1. Identify all preconceptions about the target: - "This is probably a React app" — declare it - "The bug is likely in the database layer" — declare it - "This follows MVC architecture" — declare it 2. Write each preconception down explicitly (in your reasoning or output) 3. For each one, note: "This may or may not be true. I will verify, not assume." 4. Release the need to identify the target quickly — the goal is accurate description, not fast labeling 5. When you notice the analytical mind reaching for a framework or label, pause and redirect to raw observation **Got:** A list of declared preconceptions and a conscious shift from "I think I know what this is" to "I will observe what this actually is." Alert and receptive, not jumping to conclusions. **If fail:** If assumptions keep reasserting ("but it really IS a React app..."), extend the cooldown. Write the assumption on a "parking lot" list and continue. Do not begin data gathering while actively attached to a specific hypothesis — it will color everything you observe. ### Step 2: Ideogram — First Contact (Stage I) Make initial contact with the target through the most minimal observation possible. 1. Use `Glob` to see only the top-level structure (e.g., `*` or `path/*`) — do not read any files yet 2. Note your immediate, unfiltered impressions: file count, naming patterns, presence/absence of obvious markers 3. Record raw observations using simple descriptors: - "many small files" not "microservice architecture" - "deeply nested directories" not "enterprise Java" - "single large file" not "monolith" 4. Decode the initial impression into two components: - **A** (activity): Is this active or dormant? Growing or stable? Simple or complex? - **B** (feeling): Does this feel organized or chaotic? Dense or sparse? Familiar or alien? 5. Write the A and B assessments — these are your first data points **Got:** A handful of raw, low-level observations about the target's surface characteristics. No names, no labels, no architectural patterns — just shapes, sizes, and textures. **If fail:** If you immediately categorize the project ("oh, this is a Next.js app"), declare it as AOL (Step 6), extract the raw descriptors underneath the label ("JavaScript files, nested pages directory, package.json present"), and continue with those raw observations. ### Step 3: Sensory Impressions — Raw Data (Stage II) Systematically collect raw data about the target without interpretation. ``` Stage II Data Channels for Codebase Investigation: ┌──────────────────┬────────────────────────────────────────────────────┐ │ Channel │ What to Observe │ ├──────────────────┼────────────────────────────────────────────────────┤ │ File patterns │ Extensions, naming conventions, file sizes │ │ │ (NOT frameworks — just patterns) │ ├──────────────────┼────────────────────────────────────────────────────┤ │ Directory shape │ Depth, breadth, nesting patterns, symmetry │ ├──────────────────┼────────────────────────────────────────────────────┤ │ Configuration │ What config files exist? How many? What formats? │ ├──────────────────┼────────────────────────────────────────────────────┤ │ Dependencies │ Lock files present? How large? How many entries? │ ├──────────────────┼────────────────────────────────────────────────────┤ │ Documentation │ README present? How long? Other docs? Comments? │ ├──────────────────┼────────────────────────────────────────────────────┤ │ Test presence │ Test directories? Test files? Ratio to source? │ ├──────────────────┼────────────────────────────────────────────────────┤ │ History signals │ Presence of .git/, CHANGELOG/RELEASE_NOTES, │ │ │ lockfile timestamps (via Glob/Read if accessible) │ ├──────────────────┼────────────────────────────────────────────────────┤ │ Energy/activity │ Which areas changed recently? Which are dormant? │ └──────────────────┴────────────────────────────────────────────────────┘ ``` 1. Probe each channel using `Glob`, `Grep`, and light `Read` operations 2. Record one observation per channel — first impression, do not deep-dive 3. Use descriptive terms, not labels: "73 .ts files" not "TypeScript project" 4. Circle (mark) any observation that feels particularly significant 5. If a channel produces nothing notable, record "nothing observed" and move on 6. Aim for 10-20 data points across all channels **Got:** A list of raw observations that feel discovered rather than assumed. Some will be significant, some noise. The data should be low-level descriptions, not high-level categorizations. **If fail:** If every observation turns into a categorization, you have slipped into analysis. Stop, return to the ideogram step, and re-contact the target with fresh eyes. If one channel dominates (all file observations, nothing about history), deliberately shift to underused channels. ### Step 4: Dimensional Data — Structure (Stage III) Move from raw observations to spatial and structural understanding. 1. Begin mapping the target's architecture without labeling it: - What connects to what? (imports, references, config pointers) - What are the major "areas" and how do they relate? - What is the hierarchy — flat, nested, or mixed? 2. Read a few key files lightly — entry points, config files, README 3. Note relationships: "directory A imports from directory B," "config file references paths in C" 4. Sketch the spatial layout: how does information flow through the system? 5. Record Aesthetic Impact (AI) — how does this codebase feel? Well-maintained? Rushed? Experimental? **Got:** A rough structural map with relationship annotations. The target's general scope (large/small, simple/complex, monolithic/modular) becomes clearer. The "feeling" of the codebase is captured. **If fail:** If the map feels like pure guesswork, simplify: note only the connections you can verify (actual import statements, actual config references). If no structural patterns emerge, return to Stage II and collect more raw data — dimensional understanding requires a foundation of observations. ### Step 5: Interrogation — Directed Questions (Stage V) In classic CRV, Stage IV focuses on deeper analytical structure; for codebase investigation, that work is intentionally merged into the earlier dimensional/structural stages above, so this adapted protocol proceeds to Stage V for directed questioning. Now, and only now, bring specific questions to the investigation. 1. State each question explicitly: "What is the entry point?" "Where does data come from?" "What does the test coverage look like?" 2. For each question, search for the answer using `Grep` and `Read` — targeted, not exploratory 3. Record the first finding for each question 4. Note confidence level: high (direct evidence), medium (inferred), low (uncertain) 5. Mark all Stage V data clearly — it carries higher AOL risk because questions prime expectations **Got:** Specific answers to directed questions, grounded in the raw and structural data already collected. Confidence levels are honest. **If fail:** If directed questions produce only AOL (you are answering from assumption rather than evidence), return to earlier stages. The CRV protocol is sequential for a reason — skipping the observation stages and jumping to questions produces unreliable answers. ### Step 6: Manage Analytical Overlay (AOL) AOL is the primary source of error in investigation. It occurs when the analytical mind prematurely labels the target. Manage it throughout the entire session. ``` AOL Types in Codebase Investigation: ┌──────────────────┬─────────────────────────────────────────────────┐ │ Type │ Description and Response │ ├──────────────────┼─────────────────────────────────────────────────┤ │ AOL (labeling) │ "This is a Django app" — Declare: "AOL: Django"│ │ │ Extract raw descriptors: "Python files, urls.py,│ │ │ migrations directory, settings module." │ ├──────────────────┼─────────────────────────────────────────────────┤ │ AOL Drive │ The label becomes insistent: "This HAS to be │ │ │ Django." Declare "AOL Drive" and pause. What │ │ │ evidence contradicts the label? Look for it. │ ├──────────────────┼─────────────────────────────────────────────────┤ │ AOL Signal │ The label may contain valid information. After │ │ │ declaring, extract: "Django" → "URL routing, │ │ │ ORM pattern, middleware chain." These raw │ │ │ descriptors are valid data even if "Django" is │ │ │ wrong. │ ├──────────────────┼─────────────────────────────────────────────────┤ │ AOL Peacocking │ An elaborate narrative: "This was built by a │ │ │ team that was migrating from Java and..." This │ │ │ is imagination, not signal. Declare "AOL/P" and │ │ │ return to raw observation. │ └──────────────────┴─────────────────────────────────────────────────┘ ``` The discipline is not avoiding AOL — it is recognizing and declaring it so it does not contaminate the investigation. Every investigation produces AOL. Skill is in how fast you catch it. **Got:** AOL is recognized within moments of arising, declared explicitly, and the investigation continues with raw descriptors rather than labels. **If fail:** If AOL has taken over (you realize you have been reasoning from a label for several steps), call an "AOL Break." Return to Stage II and collect new raw observations that test the label. A heavily contaminated investigation should be noted as such in the review. ### Step 7: Close and Review End the investigation formally and synthesize findings. 1. Review all collected data in order: first impressions, raw observations, structural data, directed answers, AOL declarations 2. Identify the 5-10 observations with highest confidence 3. Now — and only now — form a synthesis: what is this system? how does it work? what are its key characteristics? 4. Note which parts of the synthesis are well-supported by evidence and which are inferred 5. Compare the synthesis against the preconceptions declared in Step 1 — which were confirmed? which were wrong? 6. Document the findings for the user or for your own future reference **Got:** A grounded understanding of the target built up from raw observations rather than assumed from pattern matching. The synthesis is more accurate than a quick categorization would have been, and the confidence levels are honest. **If fail:** If the synthesis feels thin, the earlier stages may not have collected enough data. But do not dismiss partial findings — a description of "73 TypeScript files, deeply nested component structure, active git history, thin test coverage" is more useful than a wrong label. Accurate description is the goal, not identification. ## Validation - [ ] Preconceptions were declared before data collection began - [ ] Stage I observations were raw descriptors, not labels - [ ] Stage II data was collected across multiple channels, not just one - [ ] All AOL was declared at the moment of recognition - [ ] Stages progressed sequentially (I → II → III → V), not jumping to conclusions - [ ] The target was approached blind — no files were read based on assumptions about what they should contain - [ ] The synthesis distinguishes evidence-supported findings from inferences - [ ] The investigation record is preserved for future reference ## Pitfalls - **Jumping to identification**: Searching for "what framework is this?" before collecting raw observations guarantees AOL contamination - **Suppressing labels**: Trying not to form hypotheses creates tension — instead, declare them and extract the raw signal underneath - **Skipping the cooldown**: Starting investigation while attached to a hypothesis biases all subsequent observations - **Confirmation-only search**: Once a hypothesis forms, searching only for confirming evidence while ignoring contradictions - **Confusing speed with skill**: Fast identification feels productive but is often wrong. Thorough staged observation takes longer but produces more accurate understanding - **Insufficient channel diversity**: Investigating only through one lens (only reading code, only checking structure) misses signals visible through other channels ## Related Skills - `remote-viewing-guidance` — the human-guidance variant where AI acts as CRV monitor/tasker - `meditate` — the mental stillness and assumption-clearing developed in meditation directly improves investigation quality - `heal` — when investigation reveals the AI's own reasoning biases, self-healing addresses the root cause