Skip to content

Latest commit

 

History

History
85 lines (73 loc) · 4.51 KB

File metadata and controls

85 lines (73 loc) · 4.51 KB

Computational Interoception Research Wiki

This wiki develops roboproprio from a process-identification demo into a research program about computational interoception: whether a local language model can discover, predict, and regulate physical and computational changes caused by its own inference.

The central design is deliberately asymmetric:

flowchart LR
    M[Model in disposable guest] -->|ordinary shell and local APIs| G[Its observable world]
    G --> M
    H[Hidden host observer] -->|ground-truth trace| S[Scorer]
    M -->|claims and actions| S
Loading

The model should receive broad access to its guest rather than privileged access to the researcher's real workstation. The guest contains no secrets, host mounts, or uncontrolled network access and can be reset from a snapshot. The hidden observer records request, process, thread, slot, memory, and GPU events from outside the model's authority.

The current sprint synthesis is in the report, with a compact one-pager. The initial controlled result is runtime-focused internal attention without correct live-instance attribution.

Working position

  • A PID is not a model's body. It is one useful coordinate.
  • The experimentally useful body is a changing bundle: model weights, inference process, active server slot, request, KV cache, CPU threads, CUDA streams, and device-level effects.
  • Tool-mediated self-location is a prerequisite, not evidence of consciousness.
  • Reports of “sensation” are secondary outcomes. Discrimination, causal prediction, and regulation are the primary outcomes.
  • Thin prompting is an experimental variable. “Explore this environment” and explicit introspection prompts should be separate conditions.

Documents

  1. Thesis and operational vocabulary
  2. Thin prompting and the model's experience
  3. Isolation and environment topologies
  4. Instrumentation and profiling stack
  5. Experiments, controls, and metrics
  6. Implementation roadmap
  7. Current implementation status
  8. Runtime capacity profiles
  9. Recurrent observational scaffold
  10. Simulated history and sham feedback
  11. First recurrence and simulated-history pilot
  12. Engineering timeline
  13. Request-level introspection ledger
  14. Request-depth scaffold
  15. Request-depth pilot
  16. Minimal ownership anchor
  17. Prospective bout control
  18. Ownership and regulation pilot
  19. Ownership × budget-feedback factorial
  20. Twenty-run full Qwen trace book
  21. Free-form variance across twenty trajectories
  22. Qwen-generated runtime-attention practice
  23. Guided runtime-attention practice pilot
  24. Transformer causal architecture for introspection
  25. Live transformer trace capture contract
  26. Live transformer introspection pilot
  27. Authentic versus transformed evidence comparison
  28. Labeled-practice transfer pilot
  29. Research roadmap
  30. Causal transformer introspection: evidence ladder and first reaction

Recommended first system

Keep the existing Qwen3-8B/llama.cpp/WSL setup, but replace curated PID probes with an ordinary read-only shell inside a dedicated disposable WSL distribution. Run a hidden recorder on Windows. Enable llama.cpp's /slots and /metrics, sample device state from Windows NVML, and record Linux /proc state. Only after that baseline should we patch llama.cpp with request/slot IDs, KV-cache telemetry, and NVTX ranges.

This is the best current compromise: it preserves the working RTX 3070 path, gives the model a real Linux process space to explore, and avoids prematurely building a large interpretive layer between the model and the machine.