{ "generatedAt": "2026-06-14T02:50:46.558Z", "scannedRoots": [ "Desktop", "projects" ], "totalCandidates": 1147, "counts": { "byProgram": { "Agents That Account for Themselves": 532, "Embodied Trajectory Systems": 317, "Language as Infrastructure": 238, "Business Systems": 20, "Research Backlog": 28, "Research Practice": 5, "Protocol and Compute": 7 }, "byKind": { "working paper": 68, "proposal": 192, "architecture": 271, "whitepaper": 1, "technical note": 99, "research note": 406, "experiment": 49, "pdf artifact": 61 }, "byReadiness": { "preprint structure candidate": 45, "preprint render candidate": 23, "experiment writeup candidate": 666, "technical paper candidate": 272, "research note to curate": 53, "backlog reference": 88 } }, "entries": [ { "id": "the-anticipatory-transformer-geometry-steered-attention-for-trajectory-aware-reasoning-jqmq25", "title": "The Anticipatory Transformer: Geometry-Steered Attention for Trajectory-Aware Reasoning", "slug": "the-anticipatory-transformer-geometry-steered-attention-for-trajectory-aware-reasoning", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "anticipation-geometry/paper/anticipatory-transformer.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "Standard transformers attend based on learned position encodings (sinusoidal, RoPE, ALiBi) that encode *where* tokens are in a sequence but not *what the sequence is doing* as a geometric process. I introduce the Anticipatory Transformer, a modified transformer architecture where seven geometric scalars derived from Anticipation Geometry (commitment, uncertainty, transition pressure, recovery margin, phase stiffness, novelty, stability) steer the multi-head attention mechanism via additive bias. The trajectory bias", "excerpt": "Standard transformers attend based on learned position encodings (sinusoidal, RoPE, ALiBi) that encode *where* tokens are in a sequence but not *what the sequence is doing* as a geometric process. I introduce the Anticipatory Transformer, a modified transformer architecture where seven geometric scalars derived from Anticipation Geometry (commitment, uncertainty, transition pressure, recovery margin, phase stiffness, novelty, stability) steer the multi-head attention mechanism via additive bias. The trajectory bias is computed by a learned network that maps the seven scalars at each position to per-head, position-dependent attention biases, enabling different heads to specialize to different geometric dimensions of the reasoning trajectory. I also introduce the CommitmentGate, a threshold-based mechanism that determines *when* to emit tokens: when the model's predicted commitment is below a learned threshold, it buffers hidden states and defers emission, enabling variable-rate generation that mirrors the deliberative pauses of human reasoning. The architecture further incorporates a dual-pathway design: a fast pathway with local windowed attention (128-token window, updated every token) for high-frequency pattern capture, and a slow pathway with global attention (full context) for long-range dependency modeling. In smoke tests on a 678,206-parameter model trained for 50 steps on synthetic data, the commitment gate achieves +0.93 correlation with the commitment scalar, attention heads specialize to 3 out of 4 unique dominant scalars, scalar prediction MSE drops from 0.15 to 0.07, and the orthogonality penalty converges to 0.005. I present this as a complete, implemented architecture with preliminary validation, not as a benchmark-breaking result. I argue that the trajectory-bias mechanism is suited for three application domains where standard position encodings are insufficient: agent reasoning over multi-step plans, multi-hop knowledge graph traversal, and real-time motion-to-audio synthesis.", "htmlHref": "/research/html/the-anticipatory-transformer-geometry-steered-attention-for-trajectory-aware-reasoning-jqmq25.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 7736 }, { "id": "anticipation-geometry-domain-general-trajectory-characterization-with-knowledge-graph-1rgmn66", "title": "Anticipation Geometry: Domain-General Trajectory Characterization with Knowledge Graph-Grounded Rewards", "slug": "anticipation-geometry-domain-general-trajectory-characterization-with-knowledge-graph-grounded-rewards", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "anticipation-geometry/paper/paper.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "I present Anticipation Geometry, a mathematical framework that characterizes trajectories through arbitrary state spaces using seven geometric scalars: commitment, uncertainty, transition pressure, recovery margin, phase stiffness, novelty, and stability. These scalars are domain-general, operating on any sequence of vectors in a metric space equipped with a differentiable time parameter. I combine this framework with knowledge graph path-derived reward signals to create a unified system for both trajectory analysi", "excerpt": "I present Anticipation Geometry, a mathematical framework that characterizes trajectories through arbitrary state spaces using seven geometric scalars: commitment, uncertainty, transition pressure, recovery margin, phase stiffness, novelty, and stability. These scalars are domain-general, operating on any sequence of vectors in a metric space equipped with a differentiable time parameter. I combine this framework with knowledge graph path-derived reward signals to create a unified system for both trajectory analysis and model training. I evaluate on three domains: physical motion (simulated kinematics), conversational reasoning (20,000 dialogue turns from 164 conversations, expanded to 308 sessions from 19,000 prompts), and knowledge graph traversal (199 multi-hop paths from a graph kernel). The key finding is that transition pressure, defined as the rate of commitment increase minus the rate of uncertainty decrease (dC/dt - dU/dt), is a statistically significant predictor of reasoning convergence. Its sign predicts conversation convergence at 71.8% accuracy (z = 2.72, p < 0.007), and its standard deviation achieves 69.8% accuracy (+8.1pp over baseline) as a single feature on higher-dimensional embeddings. In an expanded evaluation, inscription-derived features encoding conversational dynamics as sigil probability distributions achieve 79.5% accuracy via gradient boosting on the original 39 sessions (z = 3.68, p < 0.001), a +7.7pp improvement over the transition pressure baseline. On knowledge graph paths, KG-path rewards achieve 100% pairwise ranking accuracy (Cohen's d = 11.17) on a seeded synthetic evaluation (seed=42, n=15 gold/silver/bronze triplets), a structural guarantee arising from chain continuity construction rather than an empirical surprise. I do not claim state-of-the-art performance on any single task. I show that a single geometric framework, with no task-specific training, produces significant signal across domains, suggesting that trajectory geometry captures a general property of reasoning.", "htmlHref": "/research/html/anticipation-geometry-domain-general-trajectory-characterization-with-knowledge-graph-1rgmn66.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 10167 }, { "id": "cognitive-twin-personality-transfer-via-small-model-lora-with-runtime-knowledge-graph-vxwb9v", "title": "Cognitive Twin: Personality Transfer via Small-Model LoRA with Runtime Knowledge Graph Augmentation", "slug": "cognitive-twin-personality-transfer-via-small-model-lora-with-runtime-knowledge-graph-augmentation", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "cognitive-twin-architecture.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present the Cognitive Twin architecture, a three-component system that produces a faithful digital replica of a human operator's conversational persona without baking volatile domain knowledge into model weights. The architecture separates personality (a LoRA adapter trained on the operator's historical responses), knowledge (a live knowledge graph queried at inference time), and trajectory awareness (geometric scalars characterizing conversation dynamics). We find that a Qwen2.5-3B model with LoRA adapters on a", "excerpt": "We present the Cognitive Twin architecture, a three-component system that produces a faithful digital replica of a human operator's conversational persona without baking volatile domain knowledge into model weights. The architecture separates personality (a LoRA adapter trained on the operator's historical responses), knowledge (a live knowledge graph queried at inference time), and trajectory awareness (geometric scalars characterizing conversation dynamics). We find that a Qwen2.5-3B model with LoRA adapters on all 36 transformer layers produces more authentic personality transfer than a 7B model with adapters on 8 layers. The smaller model's weaker RLHF conditioning is easier to override, and full-layer coverage is more important than parameter count. Training on 2,923 examples extracted from 4,698 session files, we observe a 2.5:1 ratio of correction signals to affirmations in operator responses, confirming that persona data is dominated by directive rather than confirmatory interaction. DoRA (weight-decomposed LoRA) OOMs on 16GB Apple Silicon for 7B models, making standard LoRA with comprehensive layer coverage the practical optimum. At inference time, the cc-graph-kernel provides provenance-tracked knowledge slices from 71,130 live triples, and the Anticipation Geometry framework supplies 7 trajectory scalars that condition response style on conversation momentum. The full system runs on two Mac mini nodes (M2 + M4, 16GB each) connected via Thunderbolt, with the adapter served through MLX at sub-200ms latency. **Keywords:** cognitive twin, LoRA, personality transfer, knowledge graph, runtime augmentation, Apple Silicon, anticipation geometry, conversational AI", "htmlHref": "/research/html/cognitive-twin-personality-transfer-via-small-model-lora-with-runtime-knowledge-graph-vxwb9v.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6625 }, { "id": "cognitive-twin-synthesis-a-recursive-polymodal-framework-for-autonomous-agent-identity-gytvyc", "title": "Cognitive Twin Synthesis: A Recursive Polymodal Framework for Autonomous Agent Identity from Conversational Corpora", "slug": "cognitive-twin-synthesis-a-recursive-polymodal-framework-for-autonomous-agent-identity-from-conversational-corpora", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "cognitive-twin-research-paper.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present a framework for constructing autonomous cognitive twins from large-scale conversational corpora. Building on the Recursive Polymodal Synthesis (RPS) framework, which fuses heterogeneous sensor modalities through Lipschitz-constrained fixed-point iteration, we extend cross-modal coherence theory from physical signals (accelerometer, gyroscope, heart rate) to cognitive modalities: linguistic style ($\\mathcal{V}_L$), decision patterns ($\\mathcal{V}_D$), domain knowledge ($\\mathcal{V}_K$), value alignment ($", "excerpt": "We present a framework for constructing autonomous cognitive twins from large-scale conversational corpora. Building on the Recursive Polymodal Synthesis (RPS) framework, which fuses heterogeneous sensor modalities through Lipschitz-constrained fixed-point iteration, we extend cross-modal coherence theory from physical signals (accelerometer, gyroscope, heart rate) to cognitive modalities: linguistic style ($\\mathcal{V}_L$), decision patterns ($\\mathcal{V}_D$), domain knowledge ($\\mathcal{V}_K$), value alignment ($\\mathcal{V}_V$), and temporal rhythms ($\\mathcal{V}_T$). The corpus comprises 379,426 conversation turns spanning December 24, 2022 to March 18, 2026, collected across ChatGPT and Claude Code sessions, representing one of the largest known single-person conversational datasets used for cognitive modeling. We propose a 6-layer architecture --- the Living Executor --- progressing from knowledge ingestion (Journal), through voice replication (Mirror), meta-prompted identity (Conductor), multi-model consensus (Parliament), graduated autonomy (Apprentice), to decision-boundary modeling (Oracle). The central theoretical contribution is a formal extension of the RPS coherence energy functional $\\Phi(z; \\mathcal{A}, \\mathcal{T})$ to cognitive space, where cross-cognitive translators $T_{n \\leftarrow m}$ map between modalities and a proximal fixed-point iteration $z^{(t+1)} = \\mathcal{P}_\\alpha(z^{(t)}; x)$ converges to a latent identity fixed point $z^*$ --- a computational representation of the originator. The cognitive twin does not merely replicate voice; it maintains a persistent latent identity across sessions, makes decisions consistent with the originator's documented patterns, and earns autonomy through a formal graduation protocol. We define this protocol as the Autonomy Ratchet: a 4-level progression (Supervised, Spot-Checked, Directed, Autonomous) governed by a quality function $Q(a) \\in [0,1]$ with auto-pass threshold 0.85, human-review band $[0.60, 0.84]$, and auto-reject below 0.60.", "htmlHref": "/research/html/cognitive-twin-synthesis-a-recursive-polymodal-framework-for-autonomous-agent-identity-gytvyc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 12826 }, { "id": "cognitive-twin-synthesis-theorems-proofs-and-derivations-gxbq5x", "title": "Cognitive Twin Synthesis: Theorems, Proofs, and Derivations", "slug": "cognitive-twin-synthesis-theorems-proofs-and-derivations", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "cognitive-twin-theorems.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "This document presents the mathematical foundations for constructing a cognitive twin using Recursive Polymodal Synthesis (RPS). We extend the original RPS framework from sensor modalities (motion, heart rate, audio) to cognitive modalities (linguistic style, decision patterns, knowledge, values, temporal behavior). We prove convergence of the cognitive synthesis operator, derive the coherence energy functional, establish bounds on identity drift, and formalize the autonomy ratchet protocol. All results build on th", "excerpt": "This document presents the mathematical foundations for constructing a cognitive twin using Recursive Polymodal Synthesis (RPS). We extend the original RPS framework from sensor modalities (motion, heart rate, audio) to cognitive modalities (linguistic style, decision patterns, knowledge, values, temporal behavior). We prove convergence of the cognitive synthesis operator, derive the coherence energy functional, establish bounds on identity drift, and formalize the autonomy ratchet protocol. All results build on the Banach contraction principle and proximal optimization theory established in the original RPS paper (Diomande, October 2025).", "htmlHref": "/research/html/cognitive-twin-synthesis-theorems-proofs-and-derivations-gxbq5x.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1903 }, { "id": "enhanced-topological-preference-optimization-with-spatial-intelligence-a-unified-frame-1mdmw9l", "title": "Enhanced Topological Preference Optimization with Spatial Intelligence: A Unified Framework for Conversation Analysis", "slug": "enhanced-topological-preference-optimization-with-spatial-intelligence-a-unified-framework-for-conversation-analysis", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/ENHANCED_TPO_RESEARCH_PAPER.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present an enhanced Topological Preference Optimization (TPO) system that integrates spatial intelligence and cross-conversation consolidation for advanced conversation analysis. Our unified framework combines the topological structure analysis of TPO with the spatial coordinate systems and ring topology of Ring Contextual Propagation (RCP), creating a comprehensive system for modeling conversation dynamics and generating preference datasets. The system employs 4D spatial coordinates (x, y, z, t) to represent hi", "excerpt": "We present an enhanced Topological Preference Optimization (TPO) system that integrates spatial intelligence and cross-conversation consolidation for advanced conversation analysis. Our unified framework combines the topological structure analysis of TPO with the spatial coordinate systems and ring topology of Ring Contextual Propagation (RCP), creating a comprehensive system for modeling conversation dynamics and generating preference datasets. The system employs 4D spatial coordinates (x, y, z, t) to represent hierarchical conversation structures, implements adaptive clustering algorithms for pattern detection, and utilizes advanced natural language processing techniques for cross-conversation knowledge consolidation. Through extensive testing on a dataset of 277 conversations containing over 10,000 messages, we demonstrate the system's capability to detect knowledge transfer patterns, experimental branching behaviors, and cross-conversation similarities with high accuracy. The enhanced system achieves a 40% improvement in preference generation quality and successfully identifies complex conversation patterns that traditional linear approaches miss. **Keywords:** Conversation Analysis, Topological Optimization, Spatial Intelligence, Knowledge Transfer, Preference Learning", "htmlHref": "/research/html/enhanced-topological-preference-optimization-with-spatial-intelligence-a-unified-frame-1mdmw9l.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2035 }, { "id": "enhanced-topological-preference-optimization-with-spatial-intelligence-a-unified-frame-14m3ym8", "title": "Enhanced Topological Preference Optimization with Spatial Intelligence: A Unified Framework for Conversation Analysis", "slug": "enhanced-topological-preference-optimization-with-spatial-intelligence-a-unified-framework-for-conversation-analysis", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/ENHANCED_TPO_RESEARCH_PAPER.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present an enhanced Topological Preference Optimization (TPO) system that integrates spatial intelligence and cross-conversation consolidation for advanced conversation analysis. Our unified framework combines the topological structure analysis of TPO with the spatial coordinate systems and ring topology of Ring Contextual Propagation (RCP), creating a comprehensive system for modeling conversation dynamics and generating preference datasets. The system employs 4D spatial coordinates (x, y, z, t) to represent hi", "excerpt": "We present an enhanced Topological Preference Optimization (TPO) system that integrates spatial intelligence and cross-conversation consolidation for advanced conversation analysis. Our unified framework combines the topological structure analysis of TPO with the spatial coordinate systems and ring topology of Ring Contextual Propagation (RCP), creating a comprehensive system for modeling conversation dynamics and generating preference datasets. The system employs 4D spatial coordinates (x, y, z, t) to represent hierarchical conversation structures, implements adaptive clustering algorithms for pattern detection, and utilizes advanced natural language processing techniques for cross-conversation knowledge consolidation. Through extensive testing on a dataset of 277 conversations containing over 10,000 messages, we demonstrate the system's capability to detect knowledge transfer patterns, experimental branching behaviors, and cross-conversation similarities with high accuracy. The enhanced system achieves a 40% improvement in preference generation quality and successfully identifies complex conversation patterns that traditional linear approaches miss. **Keywords:** Conversation Analysis, Topological Optimization, Spatial Intelligence, Knowledge Transfer, Preference Learning", "htmlHref": "/research/html/enhanced-topological-preference-optimization-with-spatial-intelligence-a-unified-frame-14m3ym8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2035 }, { "id": "cc-motiongen-audio-conditioned-latent-motion-diffusion-with-validation-based-candidate-14x19rp", "title": "CC-MotionGen: Audio-Conditioned Latent Motion Diffusion with Validation-Based Candidate Selection", "slug": "cc-motiongen-audio-conditioned-latent-motion-diffusion-with-validation-based-candidate-selection", "kind": "working paper", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/ml/cc-ml/cc_motiongen/RESEARCH_PAPER.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "CC-MotionGen is a diffusion-based generative system that produces time-indexed motion trajectories conditioned on audio features and optional high-level context. The system targets phrase-level generation: it consumes precomputed audio feature tensors and precomputed motion latents, trains a temporal one-dimensional U-Net denoiser under a Gaussian diffusion process, and performs inference by sampling multiple candidate futures and selecting the best output using a two-stage validation pipeline. The validation pipel", "excerpt": "CC-MotionGen is a diffusion-based generative system that produces time-indexed motion trajectories conditioned on audio features and optional high-level context. The system targets phrase-level generation: it consumes precomputed audio feature tensors and precomputed motion latents, trains a temporal one-dimensional U-Net denoiser under a Gaussian diffusion process, and performs inference by sampling multiple candidate futures and selecting the best output using a two-stage validation pipeline. The validation pipeline first applies deterministic plausibility constraints, called sanity checks, that reject physically implausible trajectories. It then applies a heuristic musicality scorer that ranks the remaining candidates according to alignment with beat structure, energy envelope, phrase boundaries, and timbral “tension” cues derived from audio. This paper provides a research-grade description of CC-MotionGen grounded in the implementation, including the on-disk data schema, temporal alignment strategy, conditioning interfaces, U-Net construction and skip bookkeeping, diffusion schedules and DDIM sampling with classifier-free guidance, training loop mechanics such as mixed precision and learning-rate scheduling, and the inference-time speculative sampling workflow with monitoring metrics. Mathematical operations are defined in plain language without symbolic notation, with an emphasis on invariants, failure modes, computational characteristics, and extensibility points suitable for subsequent empirical evaluation.", "htmlHref": "/research/html/cc-motiongen-audio-conditioned-latent-motion-diffusion-with-validation-based-candidate-14x19rp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6499 }, { "id": "rag-memory-conditioned-candidate-selection-with-trajectory-aware-attention-dnk6ut", "title": "RAG++: Memory-Conditioned Candidate Selection with Trajectory-Aware Attention", "slug": "rag-memory-conditioned-candidate-selection-with-trajectory-aware-attention", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/docs/PAPER.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "Retrieval-Augmented Generation (RAG) systems typically treat retrieved context as a flat collection of documents, ignoring the structural and temporal relationships between conversation turns. We present RAG++, a trajectory-aware retrieval system that positions memories in a 5-dimensional coordinate space (depth, sibling order, homogeneity, temporal position, and complexity) and enforces context admissibility through cryptographically-verified slicing. Our system introduces three key innovations: (1) **Inverse Ring", "excerpt": "Retrieval-Augmented Generation (RAG) systems typically treat retrieved context as a flat collection of documents, ignoring the structural and temporal relationships between conversation turns. We present RAG++, a trajectory-aware retrieval system that positions memories in a 5-dimensional coordinate space (depth, sibling order, homogeneity, temporal position, and complexity) and enforces context admissibility through cryptographically-verified slicing. Our system introduces three key innovations: (1) **Inverse Ring Contextual Propagation (IRCP)**, an attention mechanism that propagates information in both causal and anti-causal directions through ring topology; (2) **Slice-Conditioned Retrieval**, where a separate Graph Kernel service serves as the sole admissibility authority for context selection; and (3) **Conservation Metrics**, mathematical invariants that ensure bounded forgetting in memory systems. We consolidate three previously separate attention mechanisms (IRCP, RCP, TPO) into a unified architecture, achieving a 92% code reduction (42K to 3.35K LOC) while maintaining functional equivalence. Benchmarks demonstrate p95 latency of 8.1ms, throughput of 12.5k QPS, and successful scaling to 150M vectors. **Keywords**: Retrieval-Augmented Generation, Trajectory Memory, Context Slicing, Attention Mechanisms, Vector Search", "htmlHref": "/research/html/rag-memory-conditioned-candidate-selection-with-trajectory-aware-attention-dnk6ut.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3786 }, { "id": "cognitivetwin-architectural-foundations-and-empirical-evaluation-of-personalized-langu-18bnae9", "title": "CognitiveTwin: Architectural Foundations and Empirical Evaluation of Personalized Language Model Adaptation Through Trajectory-Aware Fine-Tuning", "slug": "cognitivetwin-architectural-foundations-and-empirical-evaluation-of-personalized-language-model-adaptation-through-trajectory-aware-fine-tuning", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/docs/papers/cognitivetwin_v2_evaluation.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "The construction of personalized language model instances capable of reproducing individual cognitive patterns, stylistic signatures, and domain-specific conceptual frameworks represents a significant advancement in the development of AI systems that function as cognitive extensions rather than generic tools. This paper presents the CognitiveTwin framework, a comprehensive architecture for creating personalized language model instances through trajectory-aware supervised fine-tuning on conversational interaction hi", "excerpt": "The construction of personalized language model instances capable of reproducing individual cognitive patterns, stylistic signatures, and domain-specific conceptual frameworks represents a significant advancement in the development of AI systems that function as cognitive extensions rather than generic tools. This paper presents the CognitiveTwin framework, a comprehensive architecture for creating personalized language model instances through trajectory-aware supervised fine-tuning on conversational interaction histories. The architectural foundation integrates three principal components: a trajectory coordinate system that encodes hierarchical conversation structure through tetrahedral geometric representations, a style signature extraction mechanism that captures recurring linguistic patterns across interaction histories, and a dual-ring memory topology that maintains both episodic and semantic memory traces for context-aware generation. We formalize the mathematical foundations underlying each architectural component, establish theoretical guarantees for style transfer convergence under specified conditions, and introduce a multi-dimensional evaluation framework encompassing lexical, syntactic, semantic, and pragmatic assessment dimensions. Empirical evaluation of a CognitiveTwin instance fine-tuned on 979 conversational exchanges demonstrates statistically significant improvements across all measured dimensions: characteristic phrase frequency increased by 100\\%, technical term density improved by 46\\%, topic consistency enhanced by 38\\%, and syntactic complexity as measured by average sentence length increased by 91\\% relative to the base model. The domain knowledge transfer analysis reveals successful absorption of conceptual frameworks specific to the training corpus, with the fine-tuned model demonstrating interpretive alignment with training data semantics on targeted probe queries. The framework contributes novel architectural patterns for trajectory-aware language modeling, mathematically rigorous evaluation metrics for personalization assessment, and empirical benchmarks establishing the viability of cognitive modeling through language model adaptation.", "htmlHref": "/research/html/cognitivetwin-architectural-foundations-and-empirical-evaluation-of-personalized-langu-18bnae9.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 8804 }, { "id": "deterministic-provenance-engines-for-autonomous-agent-systems-architecture-implementat-1m32p0a", "title": "Deterministic Provenance Engines for Autonomous Agent Systems: Architecture, Implementation, and Evaluation of the Graph Kernel", "slug": "deterministic-provenance-engines-for-autonomous-agent-systems-architecture-implementation-and-evaluation-of-the-graph-kernel", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/GRAPH-KERNEL-PAPER-V2.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "> **Manuscript Type:** Full Research Paper (V2 — Post-Audit Definitive Edition) > **Track:** AI Systems & Knowledge Infrastructure > **Date:** July 2026 > **Revision:** 2.0 — Incorporates DEP Audit findings, Evo³ roadmap, and implemented improvements", "excerpt": "# Deterministic Provenance Engines for Autonomous Agent Systems: Architecture, Implementation, and Evaluation of the Graph Kernel\n\n> **Manuscript Type:** Full Research Paper (V2 — Post-Audit Definitive Edition) > **Track:** AI Systems & Knowledge Infrastructure > **Date:** July 2026 > **Revision:** 2.0 — Incorporates DEP Audit findings, Evo³ roadmap, and implemented improvements\n\nAutonomous AI agents making consequential decisions require infrastructure that ensures every reasoning step is traceable, reproducible, and verifiable. We present the **Graph Kernel**, a deterministic provenance engine implemented as a single Rust binary (~15 KLOC) that produces cryptographically-signed, policy-governed context windows — termed *admissible evidence bundles* — for autonomous agent reasoning. Unlike general-purpose graph databases, vector stores, or RAG pipelines, the Graph Kernel introduces a formal category of infrastructure we call the **provenance engine**: a service whose output is not information retrieval but the construction of verifiable evidence with unforgeable authorization proofs.\n\nWe evaluate the Graph Kernel across 27 queries spanning five categories (factual recall, relationship mapping, multi-hop reasoning, fuzzy/semantic search, and predicate-specific queries) against three baselines (keyword, BM25, vector-similarity RAG). Results demonstrate perfect relevance (1.00) on multi-hop structural queries — returning causally-connected knowledge chains rather than keyword-coincidence result sets — at sub-300ms latency over a remote PostgreSQL backend. A comprehensive Deep Engineering Posture (DEP) audit scoring 7.4/10 identified 47 findings across 12 dimensions; we implemented 10 critical fixes including native Rust entity normalization, parameterized SQL queries, server-side multi-hop traversal, and connection pool optimization, raising the projected score to 8.4/10.\n\nWe further present RAG++, a complementary semantic retrieval engine (~26 KLOC Rust core with Python bindings), and describe the hybrid retrieval architecture that bridges structural graph reasoning with vector-similarity search. Comparative analysis against ten industry systems (Neo4j, Amazon Neptune, Apache Jena, Dgraph, TypeDB, Weaviate, LangChain/LlamaIndex, Microsoft GraphRAG, and Zep) establishes that no existing system provides the combination of HMAC-signed deterministic context windows, type-level admissibility enforcement, and policy-governed multi-hop provenance that the Graph Kernel offers. We conclude with a three-phase evolution roadmap spanning optimization, expansion, and transformation of the provenance engine into a universal context authority for heterogeneous agent ecosystems.", "htmlHref": "/research/html/deterministic-provenance-engines-for-autonomous-agent-systems-architecture-implementat-1m32p0a.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 9046 }, { "id": "policy-governed-context-slicing-for-autonomous-agent-systems-a-lightweight-knowledge-g-93ekyz", "title": "Policy-Governed Context Slicing for Autonomous Agent Systems: A Lightweight Knowledge Graph Approach", "slug": "policy-governed-context-slicing-for-autonomous-agent-systems-a-lightweight-knowledge-graph-approach", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/GRAPH-KERNEL-RESEARCH-PAPER.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "Autonomous AI agent systems face a fundamental challenge: constructing reproducible, trustworthy context windows from large conversational histories while enforcing governance policies over what information may influence downstream decisions. We present the **Graph Kernel**, a deterministic context slicing engine implemented as a single Rust binary (~15 KLOC) that combines a lightweight knowledge graph triple store with cryptographically-signed, policy-governed context window construction. Unlike general-purpose gr", "excerpt": "Autonomous AI agent systems face a fundamental challenge: constructing reproducible, trustworthy context windows from large conversational histories while enforcing governance policies over what information may influence downstream decisions. We present the **Graph Kernel**, a deterministic context slicing engine implemented as a single Rust binary (~15 KLOC) that combines a lightweight knowledge graph triple store with cryptographically-signed, policy-governed context window construction. Unlike general-purpose graph databases or retrieval-augmented generation (RAG) pipelines, the Graph Kernel introduces the concept of a **provenance engine** — a system whose primary purpose is not information retrieval but the production of verifiable, reproducible evidence bundles for autonomous agent reasoning. We evaluate the Graph Kernel across 27 queries spanning five categories (factual recall, relationship mapping, multi-hop reasoning, fuzzy/semantic search, and predicate-specific queries) against three baseline methods: keyword search, BM25, and vector-similarity RAG. Results demonstrate that the Graph Kernel achieves perfect relevance (1.00) on multi-hop traversal queries — returning structurally connected knowledge chains rather than keyword-coincidence result sets — while maintaining sub-300ms average latency over a remote PostgreSQL backend. We further present a comparative analysis against nine industry-grade alternatives (Neo4j, Amazon Neptune, Apache Jena, Dgraph, TypeDB, Weaviate, LangChain/LlamaIndex Knowledge Graphs, Microsoft GraphRAG, and Zep), establishing that no existing system provides the combination of HMAC-signed deterministic context windows, policy-governed access control, and multi-hop provenance tracking that the Graph Kernel offers. Our key contributions are: (1) a formal model for HMAC-signed deterministic context windows with type-level enforcement of admissibility invariants; (2) a policy governance framework for phase-weighted, budget-bounded context expansion; (3) multi-hop provenance at sub-300ms latency with projected sub-30ms under local deployment; and (4) a hybrid architecture positioning that bridges structural graph reasoning with semantic vector search. **Keywords:** knowledge graphs, context management, autonomous agents, provenance, deterministic systems, retrieval-augmented generation, graph databases, policy governance", "htmlHref": "/research/html/policy-governed-context-slicing-for-autonomous-agent-systems-a-lightweight-knowledge-g-93ekyz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6938 }, { "id": "deterministic-provenance-engines-for-autonomous-agent-systems-architecture-implementat-76fstv", "title": "Deterministic Provenance Engines for Autonomous Agent Systems: Architecture, Implementation, and Evaluation of the Graph Kernel", "slug": "deterministic-provenance-engines-for-autonomous-agent-systems-architecture-implementation-and-evaluation-of-the-graph-kernel", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/latex/graph-kernel-paper-v2.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "Autonomous AI agents making consequential decisions require infrastructure that ensures every reasoning step is traceable, reproducible, and verifiable. We present the \\textbf{Graph Kernel}, a deterministic provenance engine implemented as a single Rust binary (${\\sim}15$~KLOC) that produces cryptographically-signed, policy-governed context windows---termed \\emph{admissible evidence bundles}---for autonomous agent reasoning. Unlike general-purpose graph databases, vector stores, or RAG pipelines, the Graph Kernel i", "excerpt": "Autonomous AI agents making consequential decisions require infrastructure that ensures every reasoning step is traceable, reproducible, and verifiable. We present the \\textbf{Graph Kernel}, a deterministic provenance engine implemented as a single Rust binary (${\\sim}15$~KLOC) that produces cryptographically-signed, policy-governed context windows---termed \\emph{admissible evidence bundles}---for autonomous agent reasoning. Unlike general-purpose graph databases, vector stores, or RAG pipelines, the Graph Kernel introduces a formal category of infrastructure we call the \\textbf{provenance engine}: a service whose output is not information retrieval but the construction of verifiable evidence with unforgeable authorization proofs. We evaluate the Graph Kernel across 27 queries spanning five categories (factual recall, relationship mapping, multi-hop reasoning, fuzzy/semantic search, and predicate-specific queries) against three baselines (keyword, BM25, vector-similarity RAG). Results demonstrate perfect relevance (1.00) on multi-hop structural queries---returning causally-connected knowledge chains rather than keyword-coincidence result sets---at sub-300ms latency over a remote PostgreSQL backend. A comprehensive Deep Engineering Posture (DEP) audit scoring 7.4/10 identified 47 findings across 12 dimensions; we implemented 10 critical fixes including native Rust entity normalization, parameterized SQL queries, server-side multi-hop traversal, and connection pool optimization, raising the projected score to 8.4/10. We further present RAG++, a complementary semantic retrieval engine (${\\sim}26$~KLOC Rust core with Python bindings), and describe the hybrid retrieval architecture that bridges structural graph reasoning with vector-similarity search. Comparative analysis against ten industry systems (Neo4j, Amazon Neptune, Apache Jena, Dgraph, TypeDB, Weaviate, LangChain/LlamaIndex, Microsoft GraphRAG, and Zep) establishes that no existing system provides the combination of HMAC-signed deterministic context windows, type-level admissibility enforcement, and policy-governed multi-hop provenance that the Graph Kernel offers. We conclude with a three-phase evolution roadmap spanning optimization, expansion, and transformation of the provenance engine into a universal context authority for heterogeneous agent ecosystems.", "htmlHref": "/research/html/deterministic-provenance-engines-for-autonomous-agent-systems-architecture-implementat-76fstv.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 7887 }, { "id": "policy-governed-context-slicing-for-autonomous-agent-systems-a-lightweight-knowledge-g-hzki2u", "title": "Policy-Governed Context Slicing for Autonomous Agent Systems: A Lightweight Knowledge Graph Approach", "slug": "policy-governed-context-slicing-for-autonomous-agent-systems-a-lightweight-knowledge-graph-approach", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/latex/graph-kernel-paper.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "Autonomous AI agent systems face a fundamental challenge: constructing reproducible, trustworthy context windows from large conversational histories while enforcing governance policies over what information may influence downstream decisions. We present the \\textbf{Graph Kernel}, a deterministic context slicing engine implemented as a single Rust binary (${\\sim}15$ KLOC) that combines a lightweight knowledge graph triple store with cryptographically-signed, policy-governed context window construction. Unlike genera", "excerpt": "Autonomous AI agent systems face a fundamental challenge: constructing reproducible, trustworthy context windows from large conversational histories while enforcing governance policies over what information may influence downstream decisions. We present the \\textbf{Graph Kernel}, a deterministic context slicing engine implemented as a single Rust binary (${\\sim}15$ KLOC) that combines a lightweight knowledge graph triple store with cryptographically-signed, policy-governed context window construction. Unlike general-purpose graph databases or retrieval-augmented generation (RAG) pipelines, the Graph Kernel introduces the concept of a \\textbf{provenance engine}---a system whose primary purpose is not information retrieval but the production of verifiable, reproducible evidence bundles for autonomous agent reasoning. We evaluate the Graph Kernel across 27 queries spanning five categories (factual recall, relationship mapping, multi-hop reasoning, fuzzy/semantic search, and predicate-specific queries) against three baseline methods: keyword search, BM25, and vector-similarity RAG. Results demonstrate that the Graph Kernel achieves perfect relevance (1.00) on multi-hop traversal queries---returning structurally connected knowledge chains rather than keyword-coincidence result sets---while maintaining sub-300ms average latency over a remote PostgreSQL backend. We further present a comparative analysis against nine industry-grade alternatives (Neo4j, Amazon Neptune, Apache Jena, Dgraph, TypeDB, Weaviate, LangChain/LlamaIndex Knowledge Graphs, Microsoft GraphRAG, and Zep), establishing that no existing system provides the combination of HMAC-signed deterministic context windows, policy-governed access control, and multi-hop provenance tracking that the Graph Kernel offers. Our key contributions are: (1)~a formal model for HMAC-signed deterministic context windows with type-level enforcement of admissibility invariants; (2)~a policy governance framework for phase-weighted, budget-bounded context expansion; (3)~multi-hop provenance at sub-300ms latency with projected sub-30ms under local deployment; and (4)~a hybrid architecture positioning that bridges structural graph reasoning with semantic vector search.", "htmlHref": "/research/html/policy-governed-context-slicing-for-autonomous-agent-systems-a-lightweight-knowledge-g-hzki2u.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6298 }, { "id": "graph-augmented-recursive-language-models-for-personal-knowledge-systems-hkp1or", "title": "Graph-Augmented Recursive Language Models for Personal Knowledge Systems", "slug": "graph-augmented-recursive-language-models-for-personal-knowledge-systems", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/paper/latex/main.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "% ============================================================ We present \\textbf{Cog-RLM}, a graph-augmented recursive language model architecture for personal knowledge systems that achieves 90.3\\% accuracy on a comprehensive 103-question evaluation spanning ten cognitive dimensions, using a stock 3-billion parameter model with zero fine-tuning and zero inference cost. Our system extends the Recursive Language Model (RLM) paradigm~\\citep{zhang2025rlm} with three novel contributions: (1)~a local knowledge graph pr", "excerpt": "% ============================================================ We present \\textbf{Cog-RLM}, a graph-augmented recursive language model architecture for personal knowledge systems that achieves 90.3\\% accuracy on a comprehensive 103-question evaluation spanning ten cognitive dimensions, using a stock 3-billion parameter model with zero fine-tuning and zero inference cost. Our system extends the Recursive Language Model (RLM) paradigm~\\citep{zhang2025rlm} with three novel contributions: (1)~a local knowledge graph providing relationship-aware context retrieval via breadth-first traversal, (2)~a hybrid decomposition classifier that selectively triggers recursive processing only for multi-hop queries, reducing latency by 48\\% versus always-on decomposition, and (3)~a persistent three-layer retrieval architecture combining static knowledge blocks, sentence-transformer embeddings, and graph traversal. We evaluate across ten dimensions---recall, reasoning, temporal, counterfactual, adversarial, generalization, consistency, precision, negation, and inference---demonstrating that architectural augmentation of small models outperforms fine-tuned models with $4\\times$ more parameters by a factor of $5.4\\times$ on domain-specific knowledge tasks. Our ablation study isolates the contribution of each component: RAG alone provides +66\\% over fine-tuning, graph traversal adds +5\\%, and RLM decomposition contributes +5\\%, with the combination yielding multiplicative gains. The complete system runs on consumer hardware (Apple M4 Mac Mini, 16GB RAM, \\$600) and processes queries in 1.0--12.5 seconds.", "htmlHref": "/research/html/graph-augmented-recursive-language-models-for-personal-knowledge-systems-hkp1or.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 15801 }, { "id": "anticipation-geometry-domain-general-trajectory-characterization-with-knowledge-graph-1kij61d", "title": "Anticipation Geometry: Domain-General Trajectory Characterization with Knowledge Graph-Grounded Rewards", "slug": "anticipation-geometry-domain-general-trajectory-characterization-with-knowledge-graph-grounded-rewards", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/papers/anticipation-geometry/paper.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present Anticipation Geometry, a mathematical framework that characterizes trajectories through arbitrary state spaces using seven geometric scalars: commitment, uncertainty, transition pressure, recovery margin, phase stiffness, novelty, and stability. Originally developed for physical motion capture in the Comp-Core system, we prove these scalars are domain-general, operating on any sequence of vectors in a metric space equipped with a differentiable time parameter. We combine this framework with knowledge gra", "excerpt": "We present Anticipation Geometry, a mathematical framework that characterizes trajectories through arbitrary state spaces using seven geometric scalars: commitment, uncertainty, transition pressure, recovery margin, phase stiffness, novelty, and stability. Originally developed for physical motion capture in the Comp-Core system, we prove these scalars are domain-general, operating on any sequence of vectors in a metric space equipped with a differentiable time parameter. We combine this framework with knowledge graph path-derived reward signals, extending the domain-specific superintelligence (DSS) architecture proposed by Belova et al. (2026), to create a unified system for both trajectory analysis and model training. We evaluate on three domains: physical motion (simulated kinematics), conversational reasoning (20,000 dialogue turns from 164 conversations embedded with MiniLM and e5-large), and knowledge graph traversal (199 multi-hop paths from a production graph kernel). Our key finding is that transition pressure, defined as $\\frac{d(\\text{commitment})}{dt} - \\frac{d(\\text{uncertainty})}{dt}$, is a statistically significant predictor of reasoning convergence: its sign predicts conversation convergence at 71.8% accuracy (z = 2.72, p < 0.007), and its standard deviation achieves 69.8% accuracy (+8.1pp over baseline) as a single feature on higher-dimensional embeddings. On knowledge graph paths, anticipation-augmented rewards discriminate valid from hard-negative paths with 81.0% pairwise accuracy (Cohen's d = 2.23). We do not claim state-of-the-art performance on any single task. We demonstrate that a single geometric framework, with no task-specific training, produces significant signal across domains, suggesting that trajectory geometry captures a fundamental property of reasoning that transcends domain boundaries.", "htmlHref": "/research/html/anticipation-geometry-domain-general-trajectory-characterization-with-knowledge-graph-1kij61d.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 9356 }, { "id": "computational-choreography-deterministic-motion-to-audio-synthesis-via-geometric-antic-uttmkf", "title": "Computational Choreography: Deterministic Motion-to-Audio Synthesis via Geometric Anticipation Signals", "slug": "computational-choreography-deterministic-motion-to-audio-synthesis-via-geometric-anticipation-signals", "kind": "working paper", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/papers/computational-choreography/paper.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present Computational Choreography, a deterministic pipeline that transforms heterogeneous sensor input -- phone accelerometer, smartwatch heart rate, full-body IMU skeleton -- into real-time audio synthesis through geometric anticipation signals. The system guarantees deterministic replay: identical sensor input always produces identical audio output. The key innovation is the Anticipation Kernel, which computes seven geometric scalars (commitment, uncertainty, transition pressure, recovery margin, phase stiffn", "excerpt": "We present Computational Choreography, a deterministic pipeline that transforms heterogeneous sensor input -- phone accelerometer, smartwatch heart rate, full-body IMU skeleton -- into real-time audio synthesis through geometric anticipation signals. The system guarantees deterministic replay: identical sensor input always produces identical audio output. The key innovation is the Anticipation Kernel, which computes seven geometric scalars (commitment, uncertainty, transition pressure, recovery margin, phase stiffness, novelty, stability) from fused sensor data, creating a continuous phase space that drives audio synthesis parameters. Unlike ad hoc motion-to-audio mappings that bind a single sensor axis to a single audio parameter, our approach provides a principled geometric foundation where the anticipation scalars capture the *intent* of movement before the movement completes. The full implementation comprises 334 Rust source files across the motion and audio layers, all verified to compile on Rust 1.92.0 stable, with five genre-specific synthesizer kits (House, Techno, Jazz, Electro, Ambient), Ableton Link beat synchronization, a Strudel.js live coding bridge, and companion iOS applications for sensor capture. Cross-domain validation demonstrates that the same anticipation scalars, applied unchanged to conversational turn-taking data, predict topic convergence at 71.8% accuracy (z = 2.72, p < 0.007), confirming that the geometric framework captures genuine trajectory dynamics rather than motion-specific artifacts. We describe the system architecture, report build verification and cross-domain results, and present designed evaluation protocols for determinism, latency, and musical quality assessment that await physical sensor data collection. **Keywords:** motion-to-audio, anticipation, sensor fusion, live coding, deterministic replay, Ableton Link, body-as-instrument, Strudel.js, cross-domain generalization", "htmlHref": "/research/html/computational-choreography-deterministic-motion-to-audio-synthesis-via-geometric-antic-uttmkf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 9719 }, { "id": "live-knowledge-graphs-runtime-graph-integration-for-continuous-domain-adaptation-in-la-1i22b9k", "title": "Live Knowledge Graphs: Runtime Graph Integration for Continuous Domain Adaptation in Language Agents", "slug": "live-knowledge-graphs-runtime-graph-integration-for-continuous-domain-adaptation-in-language-agents", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/papers/runtime-knowledge-graphs/paper.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "Recent work on Domain-Specific Superintelligence (Belova et al., 2026) demonstrates that knowledge graph-derived training curricula produce domain specialists that outperform models 400x their size. However, this approach treats knowledge graphs as static training scaffolding: constructed once, used for fine-tuning, then discarded at inference. We present an alternative: runtime knowledge graph integration, where the graph is queried live during inference with provenance-tracked context slicing, real-time entity re", "excerpt": "Recent work on Domain-Specific Superintelligence (Belova et al., 2026) demonstrates that knowledge graph-derived training curricula produce domain specialists that outperform models 400x their size. However, this approach treats knowledge graphs as static training scaffolding: constructed once, used for fine-tuning, then discarded at inference. We present an alternative: runtime knowledge graph integration, where the graph is queried live during inference with provenance-tracked context slicing, real-time entity resolution, and cryptographic admissibility verification. We implement this in cc-graph-kernel, a production Rust service built on the Axum framework, processing real workloads across a multi-machine mesh with 71,130 knowledge triples in its production database. We evaluate multi-hop path quality using a 3-signal reward function over 199 valid graph paths and 199 hard negatives, achieving 81.0% pairwise ranking accuracy (Cohen's d = 2.228). We further demonstrate that anticipation geometry scalars, originally developed for conversational turn analysis, produce meaningful distributions when applied to knowledge graph paths, with distinct profiles compared to the conversation domain. Our key contribution is the Context Slicer, a priority-queue BFS algorithm that produces provenance-complete, HMAC-signed graph slices suitable for direct injection into language model prompts. **Keywords:** knowledge graphs, retrieval-augmented generation, context slicing, runtime integration, provenance, admissibility tokens, conversational AI", "htmlHref": "/research/html/live-knowledge-graphs-runtime-graph-integration-for-continuous-domain-adaptation-in-la-1i22b9k.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 8006 }, { "id": "karl-advantage-weighted-training-from-full-agent-session-traces-fkactw", "title": "KARL: Advantage-Weighted Training from Full Agent Session Traces", "slug": "karl-advantage-weighted-training-from-full-agent-session-traces", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/papers/trajectory-intelligence/paper.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "Standard supervised fine-tuning (SFT) for language model agents operates on input-output pairs: a prompt and the response the model should produce. This format captures *what* an agent said but discards *why* it made specific decisions. We present KARL (Knowledge-Augmented Reinforcement Learning), a trajectory intelligence system that trains language model agents from full session traces rather than isolated completions. A trajectory in KARL records every tool call, file read, code edit, bash command, success signa", "excerpt": "Standard supervised fine-tuning (SFT) for language model agents operates on input-output pairs: a prompt and the response the model should produce. This format captures *what* an agent said but discards *why* it made specific decisions. We present KARL (Knowledge-Augmented Reinforcement Learning), a trajectory intelligence system that trains language model agents from full session traces rather than isolated completions. A trajectory in KARL records every tool call, file read, code edit, bash command, success signal, and failure signal across an entire work session, preserving the sequential decision structure that determines session outcomes. KARL computes a 5-signal composite reward function (outcome, process, efficiency, verification, and consistency) and applies z-score advantage weighting to identify the decisions that mattered most within each trajectory. We report results from an operational deployment across 11 domains and 290 trajectories (21,380 tool calls): two LoRA adapters trained on Gemma-3-4B-it, one on 972 random examples (loss 1.694) and one on 35 advantage-weighted examples (loss 1.843), both trained on Apple M4 hardware in under 3 minutes. A leave-one-out ablation study on the 5-signal reward function reveals that efficiency (tool diversity via Shannon entropy) is the most important signal (impact = 0.568), while outcome (task completion) is the least important (impact = 0.005), with the key finding that how an agent works matters more than whether it succeeds. We additionally report results from a complementary geometric analysis of conversational trajectories: transition pressure variability predicts conversation convergence at 69.8% accuracy ($z = 2.72$, $p < 0.007$), providing a geometric complement to KARL's reward-based scoring. We describe the complete system: trajectory extraction from Claude Code hook infrastructure, the 5-signal reward function with Bayesian-smoothed domain baselines, FlowRL-style balanced sampling, a Cortex behavioral intelligence bridge for live correction capture, and a remote MLX LoRA training pipeline. We clearly distinguish proven results (operational metrics, training loss, signal ablation, anticipation geometry signal strength) from proposed experiments (downstream evaluation, cross-domain transfer, reward-geometry fusion).", "htmlHref": "/research/html/karl-advantage-weighted-training-from-full-agent-session-traces-fkactw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 11079 }, { "id": "inscription-conditioned-cognitive-twin-nko-sigil-encoding-as-semantic-compression-for-16ehb55", "title": "Inscription-Conditioned Cognitive Twin: N'Ko Sigil Encoding as Semantic Compression for Long-Context Personality Models", "slug": "inscription-conditioned-cognitive-twin-nko-sigil-encoding-as-semantic-compression-for-long-context-personality-models", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "inscription-cognitive-twin-paper.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "Context window limitations constrain the fidelity of small personality models. A 4B parameter model with a 32K token context can hold roughly 8,000 words of conversation history before truncation begins discarding information critical to persona coherence. We present the Inscription-Conditioned Cognitive Twin (ICCT), an architecture that addresses this bottleneck by encoding conversation history as N'Ko inscriptions rather than English prose. The encoding uses 10 N'Ko sigils, each a single Unicode character derived", "excerpt": "# Inscription-Conditioned Cognitive Twin: N'Ko Sigil Encoding as Semantic Compression for Long-Context Personality Models\n\nContext window limitations constrain the fidelity of small personality models. A 4B parameter model with a 32K token context can hold roughly 8,000 words of conversation history before truncation begins discarding information critical to persona coherence. We present the Inscription-Conditioned Cognitive Twin (ICCT), an architecture that addresses this bottleneck by encoding conversation history as N'Ko inscriptions rather than English prose. The encoding uses 10 N'Ko sigils, each a single Unicode character derived from dynamical systems claims (stabilization, transition, novelty, etc.), as a semantic alphabet where one inscription line compresses an entire conversation turn into 3-8 tokens. Combining marks from the N'Ko Unicode block (U+07EB through U+07F3) encode trajectory depth and opacity, adding a second information channel without consuming additional token budget.\n\nWe report four principal findings. First, inscription encoding achieves 100% signal density at 65 characters per turn versus English prose's 27% signal density at 129 characters per turn, enabling 12,092 inscription turns versus 8,102 English turns in a 262K context window, with 242 full sessions visible in inscription format. Second, an inverse scaling law for personality transfer: 3B parameter models outperform 7B models for persona override because thinner RLHF conditioning is easier to overwrite, and inscription-conditioned 4B models inherit this advantage while gaining trajectory awareness. Across 11 adapter versions, the 4B inscription model achieves qualitative persona fidelity (terse, directive responses matching the operator's communication style) that the 7B models never reach regardless of data volume. Third, a learned flow encoder replaces the keyword classifier with a 27KB MLP that produces soft-posterior sigil distributions at 85.7% validation accuracy, where the inscription becomes the symbolic shadow of a learned flow field rather than a hard classification. Fourth, an A40 GPU training run with LoRA rank 64 on all 7 target modules (q,k,v,o + gate,up,down MLP) achieves eval loss 0.733, a 3x improvement over the best Mac5 configuration (2.212), demonstrating that personality transfer quality scales with adapter capacity rather than model size. A 4B model with 132M trainable parameters (3.18% of total) produces better persona fidelity than a 7B model with 5.7M trainable parameters (0.076%).\n\nOn a 20-question evaluation suite drawn from real operator interactions, the inscription-conditioned twin achieves 90% intent match, 80% action equivalence, and 100% tone match. The A40-trained model produces context-aware pushback (\"No. TestFlight needs to fin", "htmlHref": "/research/html/inscription-conditioned-cognitive-twin-nko-sigil-encoding-as-semantic-compression-for-16ehb55.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 14657 }, { "id": "karl-edge-multi-signal-reinforcement-learning-for-software-engineering-agents-on-commo-1g9tf5b", "title": "KARL-Edge: Multi-Signal Reinforcement Learning for Software Engineering Agents on Commodity Hardware", "slug": "karl-edge-multi-signal-reinforcement-learning-for-software-engineering-agents-on-commodity-hardware", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "karl-research-paper.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present KARL-Edge, an adaptation of the Knowledge Agents via Reinforcement Learning (KARL) framework to multi-tool software engineering agents running on commodity Apple Silicon hardware. Where the original KARL system (Chang et al., 2026) trains enterprise search agents using full off-policy RL with binary reward signals, our system introduces three architectural contributions: (1) a 5-signal composite reward function that decomposes trajectory quality into outcome, process, efficiency, verification, and consis", "excerpt": "We present KARL-Edge, an adaptation of the Knowledge Agents via Reinforcement Learning (KARL) framework to multi-tool software engineering agents running on commodity Apple Silicon hardware. Where the original KARL system (Chang et al., 2026) trains enterprise search agents using full off-policy RL with binary reward signals, our system introduces three architectural contributions: (1) a 5-signal composite reward function that decomposes trajectory quality into outcome, process, efficiency, verification, and consistency dimensions; (2) a hook-wired zero-overhead trajectory capture system that records production sessions without separate data collection infrastructure; and (3) a retroactive cross-turn correction signal that uses the user's natural behavior as an implicit reward label. We report preliminary results on 485 trajectories across 10 software engineering domains, with a mean composite reward of 0.583 and 84.3% positive advantage rate. We train a LoRA adapter on gemma-3-1b-it-4bit using advantage-weighted SFT (OAPL-Lite) and discuss limitations including corrupted reward signals from a schema migration bug and the absence of controlled A/B evaluation. We argue that the architectural contributions, particularly the multi-signal reward decomposition and hook-wired capture, are independently valuable and transferable to other agent training systems.", "htmlHref": "/research/html/karl-edge-multi-signal-reinforcement-learning-for-software-engineering-agents-on-commo-1g9tf5b.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3568 }, { "id": "trajectory-memory-ledger-2sck8x", "title": "Trajectory Memory Ledger", "slug": "trajectory-memory-ledger", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "karl/paper/karl-paper.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present the Trajectory Memory Ledger, implemented in KARL, a schema-normalized experience replay system for improving AI coding agent performance through closed-loop feedback. The ledger records complete tool-use sequences during real coding sessions, normalizes them into an append-only schema, scores them using a six-signal composite reward function (outcome, process, efficiency, verification, consistency, and wasted motion), and uses the highest-scoring trajectories to generate advantage-weighted supervised fi", "excerpt": "We present the Trajectory Memory Ledger, implemented in KARL, a schema-normalized experience replay system for improving AI coding agent performance through closed-loop feedback. The ledger records complete tool-use sequences during real coding sessions, normalizes them into an append-only schema, scores them using a six-signal composite reward function (outcome, process, efficiency, verification, consistency, and wasted motion), and uses the highest-scoring trajectories to generate advantage-weighted supervised fine-tuning data. Unlike approaches that rely on static benchmarks or human preference labels, the Trajectory Memory Ledger derives training signal from observable agent behavior and implicit user feedback. The current normalized deployment corpus contains 7,468 scored trajectories, 67,409 observed tool events, and 73,470 recovered tool steps across 50+ active projects. From this store, KARL exports 3,678 ChatML training examples (3,310 train / 368 validation). We describe the system architecture, schema normalization, reward design, OAPL-Lite export, and entity bridge for performance-based skill decay.", "htmlHref": "/research/html/trajectory-memory-ledger-2sck8x.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4353 }, { "id": "live-knowledge-graphs-runtime-graph-integration-for-continuous-domain-adaptation-in-la-1aqiy77", "title": "Live Knowledge Graphs: Runtime Graph Integration for Continuous Domain Adaptation in Language Agents", "slug": "live-knowledge-graphs-runtime-graph-integration-for-continuous-domain-adaptation-in-language-agents", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "live-knowledge-graphs/paper/paper.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "Recent work on Domain-Specific Superintelligence (Belova et al., 2026) demonstrates that knowledge graph-derived training curricula produce domain specialists that outperform models 400x their size. However, this approach treats knowledge graphs as static training scaffolding: constructed once, used for fine-tuning, then discarded at inference. We present an alternative: runtime knowledge graph integration, where the graph is queried live during inference with provenance-tracked context slicing, real-time entity re", "excerpt": "Recent work on Domain-Specific Superintelligence (Belova et al., 2026) demonstrates that knowledge graph-derived training curricula produce domain specialists that outperform models 400x their size. However, this approach treats knowledge graphs as static training scaffolding: constructed once, used for fine-tuning, then discarded at inference. We present an alternative: runtime knowledge graph integration, where the graph is queried live during inference with provenance-tracked context slicing, real-time entity resolution, and cryptographic admissibility verification. We implement this in cc-graph-kernel, a production Rust service built on the Axum framework, processing real workloads across a multi-machine mesh with 71,130 knowledge triples in its production database. We evaluate multi-hop path quality using a 3-signal reward function over 199 valid graph paths and 199 hard negatives, achieving 81.0% pairwise ranking accuracy (Cohen's d = 2.228). We further demonstrate that anticipation geometry scalars, originally developed for conversational turn analysis, produce meaningful distributions when applied to knowledge graph paths, with distinct profiles compared to the conversation domain. Our key contribution is the Context Slicer, a priority-queue BFS algorithm that produces provenance-complete, HMAC-signed graph slices suitable for direct injection into language model prompts. **Keywords:** knowledge graphs, retrieval-augmented generation, context slicing, runtime integration, provenance, admissibility tokens, conversational AI", "htmlHref": "/research/html/live-knowledge-graphs-runtime-graph-integration-for-continuous-domain-adaptation-in-la-1aqiy77.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 8006 }, { "id": "reading-tone-from-the-signal-featural-acoustic-coding-for-tone-resolution-in-nko-speec-15v42h1", "title": "Reading Tone from the Signal: Featural Acoustic Coding for Tone Resolution in N'Ko Speech Recognition", "slug": "reading-tone-from-the-signal-featural-acoustic-coding-for-tone-resolution-in-nko-speech-recognition", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-acoustic-coding/main.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "% Reading Tone from the Signal: % Featural Acoustic Coding for Tone Resolution in N'Ko Speech Recognition % Compiles with pdflatex (MacTeX). N'Ko shown via Unicode codepoints + % transliteration; IPA via tipa; architecture figure via TikZ.", "excerpt": "\\begin{abstract} Script-native automatic speech recognition for the Manding languages, written in N'Ko (\\code{U+07C0--U+07FF}), reaches a meaningful error regime, but the strongest released decoder is \\emph{toneless}: it emits N'Ko consonants and vowels and drops the tone diacritics that are lexically and grammatically contrastive in Manding. Tone is therefore restored downstream, and the planned mechanism is a text-context language model that infers tone from orthographic context alone. We make three claims that reframe this problem as an \\emph{acoustic} one. First, we correct the tone inventory: N'Ko has seven combining tone marks (\\code{U+07EB--U+07F1}), short and long forms of high, low, rising, and a native descending (falling) tone at \\code{U+07EE}; a widely reused syllable codebook had mislabeled the long marks as length, which propagated into downstream tooling. Second, we measure an empirical tone prior from a corpus of 105 transcribed N'Ko lesson frames (12{,}541 N'Ko characters, 3{,}316 tone marks, harvested by vision-language OCR): \\textbf{65.8\\%} of syllables carry marked high/low register, \\textbf{33.3\\%} are unmarked mid, and only \\textbf{0.9\\%} are contour tones, so tone resolution is, to first order, a three-way non-contour register classification. Third, we establish that text-only tone resolution is weak: a context model on the same corpus reaches a \\tder{} (tone-diacritic error rate) of \\textbf{50.8\\%}, i.e.\\ text alone misses roughly half of all tones, leaving large headroom for acoustic evidence that the toneless recognizer discards. We then define \\emph{Featural Acoustic Coding} (FAC), a featural treatment of the N'Ko syllable in which the tone mark is a register-plus-contour primitive read directly from the fundamental frequency, and we place tone restoration as a conservative, governance-gated correction in an \\emph{Anticipation Geometry Partition} (AGP) layer that reuses the recognizer's own trajectory geometry. We give the architecture, the reproducibility structure (the core claims run standalone, without the acoustic model), a preregistered fusion evaluation, and an honest account of what remains, principally read-speech ground truth for the acoustic tone-diacritic error rate. A secondary section relates FAC to Lexical Acoustic Coding and reports that the featural pitch advantage over a lexical carrier is real but conditional on tonal density; the durable advantage is token efficiency, not reconstruction fidelity. \\end{abstract}\n\nN'Ko is a script created in 1949 by Solomana Kant\\'e for the tonal Manding language family (Bambara, Dioula, Maninka), spoken by tens of millions of people in West Africa, and encoded in Unicode at \\code{U+07C0--U+07FF} \\citep{unicode_nko}. Unlike the Latin orthography of Bambara, N'Ko was engine", "htmlHref": "/research/html/reading-tone-from-the-signal-featural-acoustic-coding-for-tone-resolution-in-nko-speec-15v42h1.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3445 }, { "id": "the-script-that-machines-can-t-read-adapting-large-language-models-for-nko-1hpltwm", "title": "The Script That Machines Can't Read: Adapting Large Language Models for N'Ko", "slug": "the-script-that-machines-can-t-read-adapting-large-language-models-for-nko", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/arxiv-submission/main.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "We present a systematic study of how large language models process N'Ko (\\texttt{U+07C0--U+07FF}), an alphabetic script used by over 40 million Manding-language speakers in West Africa. Through activation profiling (``brain scanning'') of Qwen3-8B before and after fine-tuning, we demonstrate that: (1) fine-tuning concentrates N'Ko adaptation in the top 8 transformer layers, reducing activation magnitudes in reasoning layers while amplifying output confidence; (2) a three-stage training pipeline---continued pre-trai", "excerpt": "We present a systematic study of how large language models process N'Ko (\\texttt{U+07C0--U+07FF}), an alphabetic script used by over 40 million Manding-language speakers in West Africa. Through activation profiling (``brain scanning'') of Qwen3-8B before and after fine-tuning, we demonstrate that: (1) fine-tuning concentrates N'Ko adaptation in the top 8 transformer layers, reducing activation magnitudes in reasoning layers while amplifying output confidence; (2) a three-stage training pipeline---continued pre-training on 3.7M characters of N'Ko Wikipedia, supervised fine-tuning on 4,312 instruction examples, and BPE-aware subword training on 25,100 examples---reduces the N'Ko-to-English perplexity gap (``translation tax'') from 2.90$\\times$ to 0.70$\\times$, a 76\\% reduction; (3) N'Ko-specific token prediction accuracy improves from 23.0\\% to 32.8\\%, a 43\\% relative gain, with only 1.2 percentage points of English accuracy loss; (4) a custom 512-merge BPE tokenizer trained on N'Ko Wikipedia achieves 2.75$\\times$ compression, discovering linguistically valid subword units that align with Manding grammatical particles; (5) a morpheme-constrained BPE variant that respects Manding morphological boundaries improves boundary preservation by 5.6 percentage points (0.941 vs 0.891) at the cost of 42.6\\% more tokens, revealing that morphological awareness requires larger training corpora to compete with unconstrained BPE on compression; (6) a 4-state finite-state machine encoding N'Ko CV/CVN syllable structure, used as a logits processor during generation, guarantees 100\\% syllable validity with 39\\% throughput overhead (the V3 model achieves 99.8\\% validity even without the FSM); (7) vocabulary extension via quantized embedding surgery (151,936 $\\to$ 152,192 tokens, adding 250 N'Ko BPE tokens) combined with a 2,000-iteration LoRA pass on 33,912 training examples reduces validation loss to 3.506, an 18.3\\% improvement over the base adapter, and produces the first N'Ko text generation model to our knowledge. All training was performed on consumer hardware (Apple M4, 16GB) at zero cloud cost. We release the model, training pipeline, BPE tokenizer, and evaluation framework as open-source artifacts.", "htmlHref": "/research/html/the-script-that-machines-can-t-read-adapting-large-language-models-for-nko-1hpltwm.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4967 }, { "id": "from-dead-circuits-to-living-speech-activation-profiling-and-script-native-asr-for-nko-1a14cr7", "title": "From Dead Circuits to Living Speech: Activation Profiling and Script-Native ASR for N'Ko", "slug": "from-dead-circuits-to-living-speech-activation-profiling-and-script-native-asr-for-nko", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/main_v2.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "N'Ko is an alphabetic script serving over 40 million Manding-language speakers across West Africa, engineered by Solomana Kant\\'{e} in 1949 with a strict 1:1 phoneme-to-character mapping, explicit tonal diacritics, and zero spelling exceptions. We present a dual-thread investigation into why large language models (LLMs) fail on N'Ko and how to build audio-to-N'Ko speech recognition that bypasses LLMs entirely. \\textbf{Thread 1 (Diagnostic):} We perform activation profiling---a ``brain scan''---of Qwen2-72B-Instruct", "excerpt": "N'Ko is an alphabetic script serving over 40 million Manding-language speakers across West Africa, engineered by Solomana Kant\\'{e} in 1949 with a strict 1:1 phoneme-to-character mapping, explicit tonal diacritics, and zero spelling exceptions. We present a dual-thread investigation into why large language models (LLMs) fail on N'Ko and how to build audio-to-N'Ko speech recognition that bypasses LLMs entirely. \\textbf{Thread 1 (Diagnostic):} We perform activation profiling---a ``brain scan''---of Qwen2-72B-Instruct (4-bit NF4, A100 80GB) processing 100 parallel English/N'Ko sentence pairs. Across all 81 layers, N'Ko induces a 2.90$\\times$ translation tax (L2 norm ratio), 30--60\\% entropy inflation, 85.8\\% kurtosis deficit at the output layer, and 150\\% higher sparsity at embedding. Circuit duplication analysis (55 configurations, RYS methodology) shows 0/55 N'Ko-advantageous configurations; the best N'Ko score of 0.067 barely exceeds random chance (0.05). Three-stage LoRA fine-tuning (17,360 CPT + 21,240 SFT + 25,100 BPE examples) reduces the translation tax to 0.70$\\times$---a 76\\% reduction. \\textbf{Thread 2 (Solution):} We build the first audio-to-N'Ko ASR system. A frozen Whisper large-v3 encoder feeds a character-level CTC decoder. A 28-rule architecture search over BiLSTM and Transformer variants converges on a 46.9M-parameter Transformer with 4$\\times$ temporal downsampling, achieving 33\\% CER and 70\\% WER on 37 hours of Bambara speech from bam-asr-early (CC-BY-4.0). A 4-state finite-state machine encoding N'Ko syllable phonotactics guarantees 100\\% structural validity. Total compute: \\$14.", "htmlHref": "/research/html/from-dead-circuits-to-living-speech-activation-profiling-and-script-native-asr-for-nko-1a14cr7.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6634 }, { "id": "the-script-that-machines-can-t-read-adapting-large-language-models-for-nko-108d7z8", "title": "The Script That Machines Can't Read: Adapting Large Language Models for N'Ko", "slug": "the-script-that-machines-can-t-read-adapting-large-language-models-for-nko", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/main.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "We present a systematic study of how large language models process N'Ko (\\texttt{U+07C0--U+07FF}), an alphabetic script used by over 40 million Manding-language speakers in West Africa. Through activation profiling (``brain scanning'') of Qwen3-8B before and after fine-tuning, we demonstrate that: (1) fine-tuning concentrates N'Ko adaptation in the top 8 transformer layers, reducing activation magnitudes in reasoning layers while amplifying output confidence; (2) a three-stage training pipeline---continued pre-trai", "excerpt": "We present a systematic study of how large language models process N'Ko (\\texttt{U+07C0--U+07FF}), an alphabetic script used by over 40 million Manding-language speakers in West Africa. Through activation profiling (``brain scanning'') of Qwen3-8B before and after fine-tuning, we demonstrate that: (1) fine-tuning concentrates N'Ko adaptation in the top 8 transformer layers, reducing activation magnitudes in reasoning layers while amplifying output confidence; (2) a three-stage training pipeline---continued pre-training on 3.7M characters of N'Ko Wikipedia, supervised fine-tuning on 4,312 instruction examples, and BPE-aware subword training on 25,100 examples---reduces the N'Ko-to-English perplexity gap (``translation tax'') from 2.90$\\times$ to 0.70$\\times$, a 76\\% reduction; (3) N'Ko-specific token prediction accuracy improves from 23.0\\% to 32.8\\%, a 43\\% relative gain, with only 1.2 percentage points of English accuracy loss; (4) a custom 512-merge BPE tokenizer trained on N'Ko Wikipedia achieves 2.75$\\times$ compression, discovering linguistically valid subword units that align with Manding grammatical particles; (5) a morpheme-constrained BPE variant that respects Manding morphological boundaries improves boundary preservation by 5.6 percentage points (0.941 vs 0.891) at the cost of 42.6\\% more tokens, revealing that morphological awareness requires larger training corpora to compete with unconstrained BPE on compression; (6) a 4-state finite-state machine encoding N'Ko CV/CVN syllable structure, used as a logits processor during generation, guarantees 100\\% syllable validity with 39\\% throughput overhead (the V3 model achieves 99.8\\% validity even without the FSM); (7) vocabulary extension via quantized embedding surgery (151,936 $\\to$ 152,192 tokens, adding 250 N'Ko BPE tokens) combined with a 2,000-iteration LoRA pass on 33,912 training examples reduces validation loss to 3.506, an 18.3\\% improvement over the base adapter, and produces the first N'Ko text generation model to our knowledge. All training was performed on consumer hardware (Apple M4, 16GB) at zero cloud cost. We release the model, training pipeline, BPE tokenizer, and evaluation framework as open-source artifacts.", "htmlHref": "/research/html/the-script-that-machines-can-t-read-adapting-large-language-models-for-nko-108d7z8.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4967 }, { "id": "from-dead-circuits-to-living-speech-activation-profiling-script-native-architecture-se-1u6l3c4", "title": "From Dead Circuits to Living Speech: Activation Profiling, Script-Native Architecture Search, and Finite-State Phonotactics for N'Ko Automatic Speech Recognition", "slug": "from-dead-circuits-to-living-speech-activation-profiling-script-native-architecture-search-and-finite-state-phonotactics-for-nko-automatic-speech-recognition", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/nko_paper_v3.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "\\nko{} is an alphabetic script serving over forty million Manding-language speakers across West Africa, engineered by Solomana Kant\\'e in 1949 with a strict one-to-one phoneme-to-character mapping, explicit tonal diacritics, and zero spelling exceptions. We present a dual-thread investigation into why large language models fail on \\nko{} and how to construct audio-to-\\nko{} speech recognition that bypasses such models entirely. In the diagnostic thread, we perform activation profiling of Qwen2-72B-Instruct (4-bit N", "excerpt": "\\nko{} is an alphabetic script serving over forty million Manding-language speakers across West Africa, engineered by Solomana Kant\\'e in 1949 with a strict one-to-one phoneme-to-character mapping, explicit tonal diacritics, and zero spelling exceptions. We present a dual-thread investigation into why large language models fail on \\nko{} and how to construct audio-to-\\nko{} speech recognition that bypasses such models entirely. In the diagnostic thread, we perform activation profiling of Qwen2-72B-Instruct (4-bit NF4, A100 80\\,GB) processing one hundred parallel English/\\nko{} sentence pairs across all eighty-one transformer layers, revealing a $2.90\\times$ translation tax measured by L2 norm ratio, thirty to sixty percent entropy inflation, an 85.8\\% kurtosis deficit at the output layer, and 150\\% higher sparsity at embedding. Circuit duplication analysis spanning fifty-five configurations under the Revisit Your Shoulders methodology shows zero \\nko{}-advantageous configurations; the best \\nko{} score of 0.067 barely exceeds the random baseline of 0.05. Three-stage LoRA fine-tuning comprising 17,360 continued pre-training examples, 21,240 supervised fine-tuning pairs, and 25,100 BPE-aware training instances reduces the translation tax to $0.70\\times$, constituting a seventy-six percent reduction. In the constructive thread, we build the first audio-to-\\nko{} automatic speech recognition system. A frozen Whisper large-v3 encoder feeds a character-level CTC decoder, and a twenty-eight-rule architecture search over BiLSTM and Transformer variants converges on a 46.9\\,M-parameter Transformer with four-fold temporal downsampling, achieving 33\\% character error rate and 70\\% word error rate on thirty-seven hours of Bambara speech from the bam-asr-early corpus (CC-BY-4.0). A four-state finite-state machine encoding \\nko{} syllable phonotactics guarantees one hundred percent structural validity at negligible runtime cost. Total compute expenditure for both research threads is fourteen United States dollars.", "htmlHref": "/research/html/from-dead-circuits-to-living-speech-activation-profiling-script-native-architecture-se-1u6l3c4.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 11128 }, { "id": "theorems-proofs-and-derivations-for-nko-script-native-asr-1dky89h", "title": "Theorems, Proofs, and Derivations for N'Ko Script-Native ASR", "slug": "theorems-proofs-and-derivations-for-nko-script-native-asr", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/nko_theorems.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "This document collects the formal mathematical results underlying the N'Ko Brain Scanner and ASR system. We present five main theorems with proofs, three derivations of key quantities, and two corollaries that connect the LLM diagnostic thread to the ASR construction thread. The results establish: (1) a phonetic transparency advantage for CTC decoding on bijective scripts, (2) bounds on the translation tax in under-represented scripts, (3) completeness and soundness of the FSM phonotactic validator, (4) a circuit d", "excerpt": "This document collects the formal mathematical results underlying the N'Ko Brain Scanner and ASR system. We present five main theorems with proofs, three derivations of key quantities, and two corollaries that connect the LLM diagnostic thread to the ASR construction thread. The results establish: (1) a phonetic transparency advantage for CTC decoding on bijective scripts, (2) bounds on the translation tax in under-represented scripts, (3) completeness and soundness of the FSM phonotactic validator, (4) a circuit death theorem for reasoning layers processing unseen scripts, and (5) rank-efficiency bounds for script adaptation via LoRA.", "htmlHref": "/research/html/theorems-proofs-and-derivations-for-nko-script-native-asr-1dky89h.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3285 }, { "id": "nko-as-an-extensible-phonemic-substrate-for-governed-low-resource-speech-1av8ex3", "title": "N'Ko as an Extensible Phonemic Substrate for Governed Low-Resource Speech", "slug": "nko-as-an-extensible-phonemic-substrate-for-governed-low-resource-speech", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/current/nko_phonemic_substrate_paper.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "Low-resource speech systems usually fail twice: first because there is not enough audio/text data, and second because the available evaluation scripts do not preserve the phonemic structure of the language being measured. This paper argues that N'Ko offers a different path. Because N'Ko is a phonetic, right-to-left script designed for Manding languages and equipped with tone, nasalization, and documented foreign-sound diacritics, it can function as an extensible phonemic substrate: a deterministic sound-code for co", "excerpt": "Low-resource speech systems usually fail twice: first because there is not enough audio/text data, and second because the available evaluation scripts do not preserve the phonemic structure of the language being measured. This paper argues that N'Ko offers a different path. Because N'Ko is a phonetic, right-to-left script designed for Manding languages and equipped with tone, nasalization, and documented foreign-sound diacritics, it can function as an extensible phonemic substrate: a deterministic sound-code for constructing labels, auditing errors, and governing self-correction. We validate the representation layer with a coverage evaluator over Manding, French, and English phoneme inventories. Baseline N'Ko covers Manding completely and covers 63.9% of a French inventory and 58.5% of an English inventory. Unicode-documented foreign-sound combinations raise French to 80.6% and English to 73.2%. A bounded full-compositional layer reaches 100.0% on all three tested inventories, passing a 90% coverage gate without model training. We then connect this representation result to a governed correction experiment on 500 N'Ko ASR rows. An ungoverned Gemma-based proposer degrades CER from 0.3106 to 0.4701 (+15.94pp), while the AGP gate reduces the damage to 0.3120 (+0.14pp). A minimal-edit LoRA reduces blind harm but fails after gating (0.3156, +0.50pp) because small wrong edits slip through an edit-size gate. The resulting conclusion is precise: N'Ko representation coverage can be extended mechanically, but direct audio recognition and self-improving correction still require acoustic evidence and correctness-aware governance.", "htmlHref": "/research/html/nko-as-an-extensible-phonemic-substrate-for-governed-low-resource-speech-1av8ex3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2326 }, { "id": "nko-as-computational-infrastructure-script-native-speech-recognition-a-phonemically-in-m98co2", "title": "N'Ko as Computational Infrastructure: Script-Native Speech Recognition, a Phonemically Interpretable Error Metric, and Admissible Tone Correction", "slug": "nko-as-computational-infrastructure-script-native-speech-recognition-a-phonemically-interpretable-error-metric-and-admissible-tone-correction", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/current/paper_canonical_nko_agp_20cer.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "\\usepackage[margin=1in]{geometry} \\usepackage{booktabs} \\usepackage{array} \\usepackage{amsmath} \\usepackage{amssymb} \\usepackage{graphicx} \\usepackage{hyperref} \\usepackage[numbers]{natbib} \\usepackage{xcolor} \\usepackage{longtable} \\usepackage{caption} \\usepackage{seqsplit}", "excerpt": "\\begin{abstract} This manuscript consolidates a multi-paper research program on \\nko{}, Manding automatic speech recognition, script visibility in large language models, and trajectory-conditioned decoding. The central argument is that \\nko{} should not be treated as a decorative or interchangeable rendering of Manding language. For machine-learning systems it functions as computational infrastructure: it determines what tokenizers can represent, what hidden circuits are available, how acoustic evidence is aligned to symbols, whether reported error rates measure speech recognition or merely agreement with an inherited orthographic convention, and how tone itself can be encoded and reconstructed from acoustic evidence.\n\nThe paper integrates five written project papers and subsequent audit notes into a single canonical account. The representation studies show that current LLM families accept \\nko{} Unicode strings while internally underrepresenting the script through inflated translation cost, weak activation geometry, entropy gaps, sparsity inflation, kurtosis deficits, and poor circuit-duplication yield. The speech papers show a progression from early CTC systems to frozen-Whisper-feature decoders and then to a trajectory-conditioned Transformer CTC decoder. In the canonical architecture, 1280-dimensional Whisper large-v3 features are projected into a 768-dimensional decoder space, downsampled temporally, and decoded by a six-layer Transformer CTC head. The anticipatory component computes a seven-dimensional trajectory state $z_t$ for each timestep--commitment, uncertainty, transition pressure, recovery margin, phase stiffness, novelty, and stability--and injects it as an attention-logit bias $B_{ij}^{(m)}$ before CTC emission.\n\nThe mathematical claim is a measurement claim, not an automatic leaderboard guarantee. I formalize a transparent-script proposition: if a normalized script map $f_N:\\Phi\\rightarrow\\Sigma_N$ is bijective over the target phoneme inventory, then character edit distance over $f_N(\\phi_{1:U})$ preserves the phoneme-edit structure up to explicitly modeled normalization choices. A Latin transcription relation with variable-length digraphs, optional tone marking, and spelling variation does not have the same property. This makes \\nko{} CER a more phonemically interpretable metric for Manding ASR than Latin WER, even though it is not a perfect phoneme error rate and still depends on normalization, reference quality, and tone/diacritic policy.\n\nThe strongest retained ASR artifact is an archived checkpoint trained on a \\corpusn{}-pair Bambara corpus snapshot, with a 232,476/29,060/29,060 train/validation/test split, learning rate 0.0003, batch size 32, dropout 0.1, seed 42, and reported test \\cer{} of \\anchorcer{}. This is the canonical", "htmlHref": "/research/html/nko-as-computational-infrastructure-script-native-speech-recognition-a-phonemically-in-m98co2.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 13863 }, { "id": "dead-circuits-activation-profiling-and-script-invisibility-in-large-language-models-xyr31x", "title": "Dead Circuits: Activation Profiling and Script Invisibility in Large Language Models", "slug": "dead-circuits-activation-profiling-and-script-invisibility-in-large-language-models", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/current/paper1_dead_circuits.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "Large language models achieve remarkable performance on languages written in Latin, Cyrillic, CJK, and Arabic scripts. We ask what happens when these models encounter a script that is absent from their pre-training data. We perform activation profiling---a per-layer ``brain scan''---of Qwen3-8B processing 100 parallel English/N'Ko sentence pairs. N'Ko is an alphabetic script serving over 40 million Manding-language speakers across West Africa, engineered in 1949 with a strict phoneme-to-grapheme bijection, explicit", "excerpt": "Large language models achieve remarkable performance on languages written in Latin, Cyrillic, CJK, and Arabic scripts. We ask what happens when these models encounter a script that is absent from their pre-training data. We perform activation profiling---a per-layer ``brain scan''---of Qwen3-8B processing 100 parallel English/N'Ko sentence pairs. N'Ko is an alphabetic script serving over 40 million Manding-language speakers across West Africa, engineered in 1949 with a strict phoneme-to-grapheme bijection, explicit tonal diacritics, and zero spelling irregularities. Across all 36 transformer layers, N'Ko induces a \\textbf{2.94$\\times$ average translation tax} (L2 norm ratio across all layers), a \\textbf{1.2--1.7 bit entropy gap}, a \\textbf{78.1\\% kurtosis deficit} at the output layer, and \\textbf{2.2$\\times$ higher sparsity} at the embedding layer. Circuit duplication analysis (45 configurations, RYS methodology) shows 0/45 N'Ko-advantageous configurations; the best N'Ko score of 0.067 barely exceeds random chance (0.05). Three-zone failure analysis reveals structurally distinct collapse modes at the embedding layer (comprehension failure), middle layers (reasoning vacuum), and output layers (incoherent prediction). We then demonstrate that this failure is correctable. A three-stage LoRA pipeline---17,360 continued pre-training, 21,240 supervised fine-tuning, and 25,100 BPE-aware training examples---reduces the translation tax to \\textbf{0.70$\\times$} (a 76\\% reduction) while degrading English accuracy by only 1.2 percentage points. We provide a detailed analysis of the V1/V2/V3 fine-tuning progression, including mode collapse in V2 and its resolution. We compare N'Ko's treatment to Arabic, another right-to-left script that LLMs handle competently, and find that the difference reduces entirely to pre-training data volume: Arabic has 4,200+ dedicated vocabulary entries in Qwen3's tokenizer versus N'Ko's 32 single-character fallbacks. We argue that this vocabulary disparity is the mechanistic root of script invisibility, discuss implications for Adlam, Tifinagh, Vai, Osmanya, and Ethiopic, and propose concrete metrics for measuring script equity in multilingual model development.", "htmlHref": "/research/html/dead-circuits-activation-profiling-and-script-invisibility-in-large-language-models-xyr31x.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 12128 }, { "id": "living-speech-script-native-automatic-speech-recognition-for-nko-foljmz", "title": "Living Speech: Script-Native Automatic Speech Recognition for N'Ko", "slug": "living-speech-script-native-automatic-speech-recognition-for-nko", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/current/paper2_living_speech.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "\\documentclass[11pt]{article} \\usepackage{acl} \\usepackage{times} \\usepackage{latexsym} \\usepackage{graphicx} \\usepackage{booktabs} \\usepackage{amsmath} \\usepackage{amssymb} \\usepackage{hyperref} \\usepackage{multirow} \\usepackage{xcolor} \\usepackage{enumitem} \\usepackage{tipa}", "excerpt": "\\noindent\\textbf{Provenance note.} This manuscript documents the development path that produced the first audio-to-N'Ko ASR pipeline: the bridge, the V1--V4 architecture progression, the FSM, and the downstream translation stack. The V1--V4 metrics reported here are historical development results from the earlier 37-hour bam-asr-early regime and small held-out evaluations. They are not the current repository benchmark. The strongest fully verified ASR checkpoint currently archived in this repository is the companion N'Ko trajectory model on the 290,596-pair corpus snapshot, which achieves 20.57\\% test CER.\n\n\\begin{abstract} Every published Bambara automatic speech recognition system produces Latin-script output. For the 40+ million N'Ko-literate speakers across West Africa, the entire ASR field has been writing in a foreign script. We build the first audio-to-N'Ko ASR system, converting Bambara speech directly to N'Ko script without Latin as an intermediary.\n\nOur approach exploits a structural advantage. N'Ko is a bijective phoneme-to-grapheme script: every Manding phoneme maps to exactly one Unicode character, tone is marked explicitly, and there are no spelling irregularities. This bijectivity reduces the CTC decoder's output space to 66 classes (64 N'Ko codepoints plus space and blank), compared to the effectively larger combinatorial space of Latin Bambara (26 base letters plus digraphs, tone-unmarked).\n\nWe present a four-version architecture progression. \\textbf{V1}: A BiLSTM CTC decoder (5.4M parameters) on frozen Whisper large-v3 features achieves 56\\% CER. A \\textbf{28-configuration architecture search} over BiLSTM, Transformer, and Conformer variants identifies the optimal design. \\textbf{V3}: A Transformer CTC decoder (46.9M parameters) with 6 layers, 768 hidden dimension, and 4$\\times$ downsampling on frozen Whisper features achieves 33\\% validation CER and 70\\% validation WER at epoch 200 (measured on a 10\\% holdout from the bam-asr-early training split, not an independent test set). \\textbf{V4}: Whisper LoRA fine-tuning (rank=32, layers 24--31, 5.9M trainable parameters) on A100 reduces validation loss from 0.884 to 0.290 over 30 epochs. Qualitatively, V4 produces coherent Bambara word sequences where V3 produces degenerate repetitions; quantitatively, V4 boosts prediction confidence from 0.46 to 0.82 (79\\% improvement) and reduces WER from 70\\% to 62.3\\% ($-$11.0\\% relative). Per-sample evaluation shows LoRA wins on 20/50 samples, base wins on 19/50, and 11/50 tie, with dramatic improvements on worst-case inputs (sample au30: WER 15.8 $\\to$ 1.0). Syllable validity rate exceeds 91\\% for both models, confirming that the CTC decoder has learned N'Ko phonotactic structure even when word identity is incorrect.\n\nA deterministic cross-script b", "htmlHref": "/research/html/living-speech-script-native-automatic-speech-recognition-for-nko-foljmz.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 12595 }, { "id": "script-invisibility-is-structural-activation-profiling-across-three-llm-families-7wys22", "title": "Script Invisibility Is Structural: Activation Profiling Across Three LLM Families", "slug": "script-invisibility-is-structural-activation-profiling-across-three-llm-families", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/current/paper3_cross_model.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "A prior study demonstrated that Qwen3-8B processes N'Ko text with severely diminished neural activation compared to English, a phenomenon termed \\emph{script invisibility}. That finding left an open question: is the deficit specific to one model, or is it a structural property of all models trained on corpora where N'Ko is absent? We answer this by performing identical activation profiling---per-layer extraction of L2 norm, Shannon entropy, sparsity, and kurtosis---on three architecturally distinct models: Qwen3-8B", "excerpt": "A prior study demonstrated that Qwen3-8B processes N'Ko text with severely diminished neural activation compared to English, a phenomenon termed \\emph{script invisibility}. That finding left an open question: is the deficit specific to one model, or is it a structural property of all models trained on corpora where N'Ko is absent? We answer this by performing identical activation profiling---per-layer extraction of L2 norm, Shannon entropy, sparsity, and kurtosis---on three architecturally distinct models: Qwen3-8B (37 layers, Qwen architecture), Qwen2.5-7B (29 layers, previous-generation Qwen), and Mistral-7B (33 layers, Mistral architecture). All three process the same 100 parallel English/N'Ko sentence pairs. Every model exhibits the same failure signature. The average translation tax (ratio of English to N'Ko L2 norm) is \\textbf{3.30$\\times$} for Qwen3-8B, \\textbf{3.59$\\times$} for Qwen2.5-7B, and \\textbf{2.67$\\times$} for Mistral-7B. N'Ko activations are 66\\%--72\\% weaker than English across all architectures. Embedding-layer sparsity is 2.2--2.6$\\times$ higher for N'Ko in both Qwen models. Output-layer kurtosis deficit ranges from 64.6\\% (Mistral) to 93.5\\% (Qwen2.5), indicating that no model has learned specialized circuits for N'Ko processing. Entropy inflation of 0.78--1.22 bits confirms that N'Ko activations are diffuse rather than structured across all three architectures. The consistency of these results across different model families, training pipelines, tokenizers, and companies establishes that script invisibility is a consequence of training data composition, not architectural design. We discuss implications for the 50+ scripts in Unicode that share N'Ko's data-poverty profile and argue that architectural innovation cannot substitute for representative training data. Total compute cost for all three scans: under \\$5. All code, data, and results are publicly available.", "htmlHref": "/research/html/script-invisibility-is-structural-activation-profiling-across-three-llm-families-7wys22.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3394 }, { "id": "does-script-design-matter-phonetic-transparency-and-ctc-decoding-for-nko-automatic-spe-7gl25s", "title": "Does Script Design Matter? Phonetic Transparency and CTC Decoding for N'Ko Automatic Speech Recognition", "slug": "does-script-design-matter-phonetic-transparency-and-ctc-decoding-for-nko-automatic-speech-recognition", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/current/paper4_script_advantage.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "% Does Script Design Matter? Phonetic Transparency and CTC Decoding for N'Ko ASR % Target: Interspeech 2026 / ICASSP 2027", "excerpt": "\\noindent\\textbf{Provenance note.} The fully verified artifact bundle currently archived in this repository is a fresh reproduction of the N'Ko trajectory-biased decoder on the current 290,596-pair corpus snapshot (232,476 train / 29,060 validation / 29,060 test; seed 42), which achieves 20.57\\% test CER. We additionally completed four same-snapshot A100 ablations on this corpus snapshot under a stabilized safe rerun profile: N'Ko baseline (31.38\\%), Latin baseline (31.66\\%), Latin trajectory (32.81\\%), and N'Ko TAR (31.69\\%). These completed same-snapshot ablations all underperform the 20.57\\% N'Ko trajectory anchor, which therefore remains the strongest verified configuration. Earlier N'Ko/Latin ablation numbers from an 8-run internal comparison are retained where noted because they motivated the script-dependent trajectory hypothesis, but the complete artifact bundle for all eight runs is not yet restored locally. Those historical comparative figures should therefore be read as provisional background evidence rather than as the primary benchmark.\n\n\\begin{abstract} Connectionist Temporal Classification (CTC) decoders must learn to align acoustic frames with output characters. We argue that the design of the target script measurably affects how well this alignment can be learned, and we now ground that claim in two current evidence layers: a fully verified N'Ko trajectory reproduction and a completed same-snapshot ablation bundle on the current 290,596-pair corpus snapshot.\n\nN'Ko, a West African alphabetic script with a strict one-to-one phoneme-to-character mapping, produces a CTC output space of 66 classes. Latin Bambara, encoding the same language, requires the decoder to learn digraph compositions (\\texttt{ny}, \\texttt{ng}, \\texttt{gb}), context-dependent character values, and carries no tonal information in the output labels. Theoretical considerations therefore predict that N'Ko should provide a cleaner alignment target for CTC-style decoders, especially when architectural mechanisms exploit phoneme-aligned boundaries.\n\nThe strongest artifact-complete result in this repository is a fresh reproduction of the N'Ko trajectory-biased decoder on 290,596 Bambara speech pairs (232,476/29,060/29,060 split; seed 42). This reproduced model reaches \\textbf{20.57\\% test CER}, with best validation loss 0.6359 at epoch 38 and early stopping at epoch 46 on an A100 80GB GPU. We then ran four matched same-snapshot ablations under a stabilized safe profile after rejecting an earlier non-finite run: N'Ko baseline (31.38\\%), Latin baseline (31.66\\%), Latin trajectory (32.81\\%), and N'Ko TAR (31.69\\%). All four underperform the N'Ko trajectory anchor, so the current best verified configuration remains plain N'Ko trajectory without TAR or TTT.\n\nEarlier internal Apr", "htmlHref": "/research/html/does-script-design-matter-phonetic-transparency-and-ctc-decoding-for-nko-automatic-spe-7gl25s.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 7417 }, { "id": "beyond-controlled-comparison-deployment-properties-of-script-aware-asr-for-nko-19kc3hn", "title": "Beyond Controlled Comparison: Deployment Properties of Script-Aware ASR for N'Ko", "slug": "beyond-controlled-comparison-deployment-properties-of-script-aware-asr-for-nko", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/current/paper5_deployment.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "Controlled experiments show that phonetically transparent scripts yield lower CER for CTC-based ASR. But ASR systems are not evaluated in controlled conditions---they encounter unseen vocabulary, new speakers, and domain shift. This paper assembles deployment-relevant evidence for Bambara ASR systems using N'Ko (bijective script) and Latin (many-to-many script), anchored by the verified 20.57\\% N'Ko trajectory checkpoint but drawing on both current and historical experiments. First, \\textbf{compositional generaliza", "excerpt": "Controlled experiments show that phonetically transparent scripts yield lower CER for CTC-based ASR. But ASR systems are not evaluated in controlled conditions---they encounter unseen vocabulary, new speakers, and domain shift. This paper assembles deployment-relevant evidence for Bambara ASR systems using N'Ko (bijective script) and Latin (many-to-many script), anchored by the verified 20.57\\% N'Ko trajectory checkpoint but drawing on both current and historical experiments. First, \\textbf{compositional generalization}: models trained only on high-frequency words are evaluated on utterances containing rare words. N'Ko's generalization gap is 3.65pp smaller than Latin's (37.81pp vs 41.46pp), confirming that character-phoneme bijection enables composition of known units into unknown words. Second, \\textbf{vocabulary expansion}: full-data training recovers 13.75pp of the generalization gap equally for both scripts, but N'Ko retains a 2.58pp structural advantage on rare-word utterances---stable across training conditions. Third, \\textbf{test-time training}: in an earlier internal deployment experiment, we transcribe 32,826 segments from the Djoko soap opera (an out-of-domain Malinke broadcast), apply consensus filtering to extract 5,492 candidate pairs, and measure per-speaker adaptation via online weight updates. Those historical deployment experiments suggest that the N'Ko model produces usable transcriptions on 99.4\\% of out-of-domain segments versus Latin's distribution collapse, and that speaker-level TTT can reduce loss sharply for the best-adapting speaker. Taken together, these results suggest that N'Ko's phonetic transparency advantage is not limited to static benchmarks. It may extend to the deployment properties that determine whether an ASR system improves with use: generalization to new words, expansion without retraining, and adaptation to new speakers and domains. Total compute cost: under \\$6 across all experiments.", "htmlHref": "/research/html/beyond-controlled-comparison-deployment-properties-of-script-aware-asr-for-nko-19kc3hn.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4038 }, { "id": "dead-circuits-script-invisibility-and-representation-failure-for-nko-in-large-language-azqj29", "title": "Dead Circuits: Script Invisibility and Representation Failure for N'Ko in Large Language Models", "slug": "dead-circuits-script-invisibility-and-representation-failure-for-nko-in-large-language-models", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/01-script-invisibility/paper.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "This paper studies \\emph{script invisibility}: the condition in which a large language model accepts a writing system as valid Unicode while allocating little functional internal representation to it. The test case is \\nko{}, the script designed by Solomana Kante for Manding languages. \\nko{} is not a noisy informal encoding of Bambara, Maninka, or Dioula. It is a dedicated alphabetic system in the Unicode block U+07C0--U+07FF, with a close mapping between Manding phonology and written symbols, explicit diacritic m", "excerpt": "This paper studies \\emph{script invisibility}: the condition in which a large language model accepts a writing system as valid Unicode while allocating little functional internal representation to it. The test case is \\nko{}, the script designed by Solomana Kante for Manding languages. \\nko{} is not a noisy informal encoding of Bambara, Maninka, or Dioula. It is a dedicated alphabetic system in the Unicode block U+07C0--U+07FF, with a close mapping between Manding phonology and written symbols, explicit diacritic machinery, and an active literacy tradition. For computational linguistics, it should be unusually favorable: it is more phonemically transparent than Latin Bambara, it avoids many digraph ambiguities, and it preserves distinctions that standard Latin transcriptions often hide. The empirical problem is that current LLMs do not receive \\nko{} that way. Across the project papers, activation profiling found a repeated failure signature: reduced hidden-state norms, higher entropy, elevated sparsity, weaker output-layer kurtosis, and little evidence of reusable reasoning circuits for \\nko{} strings. In one Qwen3-8B protocol, \\nko{} incurred an average representation tax of about 2.94x, a 1.2--1.7 bit entropy gap, approximately 2.2x higher embedding sparsity, a 78.1\\% output-layer kurtosis deficit, and no \\nko{}-advantageous configuration in 45 layer-duplication probes. In a cross-model protocol, the average translation tax was 3.30x for Qwen3-8B, 3.59x for Qwen2.5-7B, and 2.67x for Mistral-7B; \\nko{} activations were roughly 66--72\\% weaker than English, and output-layer kurtosis deficits ranged from 64.6\\% to 93.5\\%. The main conclusion is not that \\nko{} is intrinsically difficult. The opposite is more plausible: \\nko{} is computationally regular, but invisible in the data and tokenizer regimes from which general LLM capability emerges. Arabic provides the control: another right-to-left script can be handled competently when it receives large-scale pretraining exposure and substantial tokenizer allocation. The failure is therefore structural and historical, not a rendering artifact. The paper argues that script invisibility should be measured directly in hidden-state geometry before downstream claims about translation, ASR correction, or language support are trusted.", "htmlHref": "/research/html/dead-circuits-script-invisibility-and-representation-failure-for-nko-in-large-language-azqj29.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3854 }, { "id": "against-wer-phonemic-evaluation-orthographic-transparency-and-the-script-advantage-for-1ig20p9", "title": "Against WER: Phonemic Evaluation, Orthographic Transparency, and the Script Advantage for Manding ASR", "slug": "against-wer-phonemic-evaluation-orthographic-transparency-and-the-script-advantage-for-manding-asr", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/02-phonemic-evaluation/paper.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "Automatic speech recognition for Manding languages is usually reported through Latin-script word error rate. This paper argues that the metric is scientifically weak for the research question at hand. If the goal is to evaluate whether an ASR system recognizes Bambara, Maninka, Dioula, or related Manding speech, then the scoring units should preserve the acoustic-phonemic distinctions carried by the language. Latin Bambara orthography is useful and socially real, but it is not a lossless measurement interface: it u", "excerpt": "Automatic speech recognition for Manding languages is usually reported through Latin-script word error rate. This paper argues that the metric is scientifically weak for the research question at hand. If the goal is to evaluate whether an ASR system recognizes Bambara, Maninka, Dioula, or related Manding speech, then the scoring units should preserve the acoustic-phonemic distinctions carried by the language. Latin Bambara orthography is useful and socially real, but it is not a lossless measurement interface: it uses digraphs for single phonemes, leaves tone unmarked or inconsistently represented, and allows convention-dependent variation. \\nko{}, by contrast, was designed for Manding phonology and gives the ASR system a more transparent character target. The core contribution is a metric argument. I formalize the difference between a transparent script map $f_N:\\Phi \\rightarrow \\Sigma_N$ from phonemic units to script units and a variable-length Latin transcription relation $R_L \\subset \\Phi^* \\times \\Sigma_L^*$. Under normalization assumptions, edit distance over a bijective or near-bijective script preserves phoneme-edit structure more directly than word error rate over a many-to-many transcription convention. It does not become a perfect phoneme error rate: tone policy, diacritics, punctuation, Unicode normalization, reference quality, and scorer granularity still matter. But \\nko{} character error rate is more interpretable for Manding ASR than Latin WER because a character substitution is closer to a sound-symbol substitution, while a Latin word error can mix acoustic error, digraph segmentation, spelling convention, and tokenization. The paper also defines the claim boundary needed for the 20.57\\% CER anchor used in the broader project. The anchor is meaningful because it is a direct \\nko{} ASR number over script-native output; it should not be translated into a Latin WER leaderboard claim or used to assert that \\nko{} beats Latin under every matched condition. The rigorous conclusion is narrower and stronger: for Manding ASR, \\nko{} CER is the better primary measurement target when the scientific object is phonemic speech recognition rather than agreement with a Latin orthographic convention.", "htmlHref": "/research/html/against-wer-phonemic-evaluation-orthographic-transparency-and-the-script-advantage-for-1ig20p9.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3542 }, { "id": "script-native-asr-for-nko-anticipatory-transformer-ctc-decoding-and-the-cer-anchor-qx96jq", "title": "Script-Native ASR for N'Ko: Anticipatory Transformer CTC Decoding and the CER Anchor", "slug": "script-native-asr-for-nko-anticipatory-transformer-ctc-decoding-and-the-cer-anchor", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/03-script-native-asr-anchor/paper.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "This paper preserves the technical ASR center of the \\nko{} research program: an archived script-native trajectory checkpoint reporting \\anchorcer{} character error rate on a \\corpusn{}-pair Bambara corpus snapshot. The model uses frozen Whisper large-v3 acoustic features, a trainable Transformer CTC decoder, and a compact trajectory state that biases attention with speech-dynamic information. The result is the strongest retained ASR artifact in the project and is the correct way to discuss the phrase ``20 CER'' pu", "excerpt": "This paper preserves the technical ASR center of the \\nko{} research program: an archived script-native trajectory checkpoint reporting \\anchorcer{} character error rate on a \\corpusn{}-pair Bambara corpus snapshot. The model uses frozen Whisper large-v3 acoustic features, a trainable Transformer CTC decoder, and a compact trajectory state that biases attention with speech-dynamic information. The result is the strongest retained ASR artifact in the project and is the correct way to discuss the phrase ``20 CER'' publicly. The paper gives the architecture, training regime, artifact contract, and claim boundaries. Input audio is encoded by Whisper large-v3 \\citep{radford2023robust}; 1280-dimensional features are projected to a 768-dimensional decoder space, temporally downsampled, and decoded by a six-layer Transformer CTC head \\citep{graves2006connectionist}. A trajectory module estimates a seven-dimensional state for each timestep: commitment, uncertainty, transition pressure, recovery margin, phase stiffness, novelty, and stability. This state produces an additive attention-logit bias before CTC emission, giving the decoder an anticipatory geometry over speech dynamics. The archived anchor was trained on \\corpusn{} paired examples split into 232,476 training rows, 29,060 validation rows, and 29,060 test rows, with learning rate 0.0003, batch size 32, dropout 0.1, seed 42, and best validation loss 0.6358872798606507. The reported test CER is \\anchorcer{}, computed as 216,225 edits over 1,050,967 reference characters. It is an archived checkpoint result with preserved metadata. Later low-learning-rate runs around 31\\% CER are not comparable to the anchor because they used a different learning-rate regime. The conclusion is therefore bounded: direct \\nko{} ASR reached a meaningful error regime under recorded settings, and the artifact should not be silently replaced by non-comparable runs.", "htmlHref": "/research/html/script-native-asr-for-nko-anticipatory-transformer-ctc-decoding-and-the-cer-anchor-qx96jq.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3376 }, { "id": "anticipation-geometry-partition-row-level-governance-for-script-native-nko-asr-deploym-1azdlr1", "title": "Anticipation Geometry Partition: Row-Level Governance for Script-Native N'Ko ASR Deployment", "slug": "anticipation-geometry-partition-row-level-governance-for-script-native-nko-asr-deployment", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/04-agp-deployment/paper.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "This paper defines the deployment layer of the \\nko{} ASR project: Anticipation Geometry Partition (AGP). AGP is not the acoustic model that produced the archived 20.57\\% CER anchor. It begins after ASR. Its role is to convert trajectory and uncertainty signals into row-level decisions about correction, provenance, corpus admission, and deployment eligibility. The motivation is simple: a scalar CER number is not enough to build a trustworthy transcript corpus or a production speech system. A model can make local mi", "excerpt": "This paper defines the deployment layer of the \\nko{} ASR project: Anticipation Geometry Partition (AGP). AGP is not the acoustic model that produced the archived 20.57\\% CER anchor. It begins after ASR. Its role is to convert trajectory and uncertainty signals into row-level decisions about correction, provenance, corpus admission, and deployment eligibility. The motivation is simple: a scalar CER number is not enough to build a trustworthy transcript corpus or a production speech system. A model can make local mistakes, a language model can propose fluent but false corrections, and out-of-domain data can contain music, overlapping speakers, dialect drift, visual context, and uncertain references. AGP partitions transcript spans into stable, boundary, uncertain, and novelty states. Stable spans should usually remain unchanged. Boundary spans may admit local repairs when acoustic and textual evidence agree. Uncertain spans require stronger evidence or abstention. Novelty spans should be treated as data-discovery events rather than as opportunities for language-model rewriting. The formal unit is a row containing ASR hypothesis, reference when available, edit counts, trajectory summaries, partition labels, candidate correction, admissibility decision, provenance metadata, and deployment gates. The paper also consolidates the deployment evidence that motivated AGP. Historical compositional generalization and vocabulary expansion experiments suggest that \\nko{} degrades less than Latin on unseen-word utterances and retains a smaller residual gap after full-data training. Djoko soap-opera extraction created a much harder deployment substrate: 1,124 downloaded videos out of a 2,001-video channel, 32,826 audio segments, an initial 8,985-segment batch, 269 high-confidence consensus rows at a strict threshold, 6,625 speaker-labeled rows, 258 episodes, seven speakers, and five eligible speakers. The domain gap was severe; the first batch produced only about 8.8\\% meaningful output under a clean-read-speech model. The conclusion is that AGP is not optional polish. It is the governance structure needed before script-native ASR output can safely become search data, correction data, subtitle candidates, or TTS training material.", "htmlHref": "/research/html/anticipation-geometry-partition-row-level-governance-for-script-native-nko-asr-deploym-1azdlr1.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3578 }, { "id": "recursive-polymodal-synthesis-a-framework-for-real-time-computational-choreography-thr-18yc9gu", "title": "Recursive Polymodal Synthesis: A Framework for Real-Time Computational Choreography Through Multi-Modal Sensor Fusion", "slug": "recursive-polymodal-synthesis-a-framework-for-real-time-computational-choreography-through-multi-modal-sensor-fusion", "kind": "working paper", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/05-research/RESEARCH_PAPER_FULL.tex", "extension": "tex", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "We present Recursive Polymodal Synthesis (RPS), a framework for real-time computational choreography that achieves robust multi-modal sensor fusion through iterative proximal updates with spectral norm constraints, and couples that embodied state to a phrase-conditioned spectrogram diffusion backend for audio generation. The system integrates kinematic, physiological, and rhythmic data streams into a unified embodied representation that drives either smooth control signals or direct audio synthesis in real time. Ou", "excerpt": "We present Recursive Polymodal Synthesis (RPS), a framework for real-time computational choreography that achieves robust multi-modal sensor fusion through iterative proximal updates with spectral norm constraints, and couples that embodied state to a phrase-conditioned spectrogram diffusion backend for audio generation. The system integrates kinematic, physiological, and rhythmic data streams into a unified embodied representation that drives either smooth control signals or direct audio synthesis in real time. Our approach addresses three fundamental challenges in embodied interaction systems: maintaining cross-modal coherence under partial observability, generating temporally coherent responses at multiple timescales, and operating within strict latency budgets. Through modality-specific encoders, cross-modal translators, and proximal fixed-point iteration, we obtain high cross-modal coherence on synthetic validation data, while the phrase-conditioned diffusion + conductor stack achieves library-faithful audio generation evaluated with objective and perceptual metrics on real recordings. End-to-end, the system processes sensor inputs with 15–40 ms control latency and supports bar-ahead audio rendering with ~0.5–1.0 s prebuffer for stage performance. We report cross-modal coherence, beat-alignment error, key stability, spectral bandwidth/flatness, Fréchet Audio Distance, and human listening tests, and analyze trade-offs between model capacity, computational efficiency, and perceived expressivity. The framework is extensible to additional modalities and applications beyond computational choreography, including human–robot interaction, adaptive gaming interfaces, and assistive technologies.", "htmlHref": "/research/html/recursive-polymodal-synthesis-a-framework-for-real-time-computational-choreography-thr-18yc9gu.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 11376 }, { "id": "research-paper-technical-latex-4z5obz", "title": "RESEARCH PAPER TECHNICAL LATEX", "slug": "research-paper-technical-latex", "kind": "working paper", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/05-research/RESEARCH_PAPER_TECHNICAL_LATEX.md", "extension": "md", "score": 100, "readiness": "preprint render candidate", "nextAction": "Compile/render the source, verify references and figures, then add to the curated atlas.", "summary": "We present a mathematically rigorous framework for multi-modal sensor fusion in real-time embodied interaction systems. Our approach, \\emph{Recursive Polymodal Synthesis} (RPS), fuses heterogeneous modalities with disparate sampling rates and noise statistics into a coherent latent representation suitable for generative control. The core mechanism is a proximal fixed-point iteration using spectral-norm-constrained relational operators, yielding contraction guarantees and a unique fixed point. We prove geometric con", "excerpt": "We present a mathematically rigorous framework for multi-modal sensor fusion in real-time embodied interaction systems. Our approach, \\emph{Recursive Polymodal Synthesis} (RPS), fuses heterogeneous modalities with disparate sampling rates and noise statistics into a coherent latent representation suitable for generative control. The core mechanism is a proximal fixed-point iteration using spectral-norm-constrained relational operators, yielding contraction guarantees and a unique fixed point. We prove geometric convergence in $\\mathcal{O}(\\log(1/\\epsilon))$ iterations to $\\epsilon$-accuracy when $\\alpha\\lVert T\\rVert_2<1$. The system uses modality encoders $\\{E_m\\}_{m=1}^M$, linear translators $\\{T_m\\}_{m=1}^M$ with $\\lVert T_m\\rVert_2\\le \\sigma_{\\max}<1$, and an update $\\Pprox_\\alpha(\\vz)=(1-\\alpha)\\Emap(\\vx)+\\alpha\\,T(\\vz)$. On synthetic data, the approach attains $99.94\\%$ cross-modal coherence, validation loss $1.93\\times 10^{-4}$, and $15$--$40$\\,ms CPU latency. Ablations confirm spectral constraints are necessary and reveal low effective rank structure in learned translators. RPS provides a principled, low-latency alternative to attention-based fusion with explicit robustness to missing modalities and tight stability bounds, enabling live performance, human--robot interaction, and adaptive interfaces.", "htmlHref": "/research/html/research-paper-technical-latex-4z5obz.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2242 }, { "id": "recursive-polymodal-synthesis-for-real-time-embodied-interaction-a-contraction-based-f-502ah6", "title": "Recursive Polymodal Synthesis for Real-Time Embodied Interaction: A Contraction-Based Framework with Provable Convergence", "slug": "recursive-polymodal-synthesis-for-real-time-embodied-interaction-a-contraction-based-framework-with-provable-convergence", "kind": "working paper", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/05-research/RESEARCH_PAPER_TECHNICAL.md", "extension": "md", "score": 100, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present a mathematically rigorous framework for multi-modal sensor fusion in real-time embodied interaction systems, coupled to a phrase-conditioned spectrogram diffusion backend for direct audio generation. Our approach, termed Recursive Polymodal Synthesis (RPS), addresses the fundamental challenge of fusing heterogeneous sensor modalities with different noise characteristics, sampling rates, and semantic meanings into a coherent internal representation suitable for generative control. The key innovation is a ", "excerpt": "We present a mathematically rigorous framework for multi-modal sensor fusion in real-time embodied interaction systems, coupled to a phrase-conditioned spectrogram diffusion backend for direct audio generation. Our approach, termed Recursive Polymodal Synthesis (RPS), addresses the fundamental challenge of fusing heterogeneous sensor modalities with different noise characteristics, sampling rates, and semantic meanings into a coherent internal representation suitable for generative control. The key innovation is a proximal fixed-point iteration scheme that enforces cross-modal coherence through spectral-norm-constrained relational operators, providing theoretical guarantees of convergence to a unique fixed point. We establish conditions under which the update operator is a contraction mapping on the latent representation space and prove convergence in at most $\\mathcal{O}(\\log(1/\\epsilon))$ iterations to achieve $\\epsilon$-accuracy. The framework processes sensor inputs through modality-specific encoders $\\{E_m\\}_{m=1}^M$, learns cross-modal predictors $\\{T_m\\}_{m=1}^M$ with spectral norm $\\|T_m\\|_2 \\leq \\sigma_{\\max} < 1$, and iteratively refines representations via the proximal operator $\\mathcal{P}_\\alpha(z^{(t)}) = (1-\\alpha)E(x) + \\alpha T(z^{(t)})$. For audio generation, a bar-rate conductor transformer provides phrase-level conditioning to a U-Net spectrogram diffusion model, enabling library-faithful, structurally coherent synthesis with controllable guidance. We report synthetic-fusion metrics (99.94% cross-modal coherence) alongside corpus-grounded audio metrics (Fréchet Audio Distance, beat alignment error, key stability, bandwidth/flatness) and runtime characteristics (15–40 ms control latency; 0.5–1.0 s bar-ahead prebuffer). The framework maintains mathematical rigor and deployable performance, making it suitable for latency-critical applications including live performance, human-robot interaction, and adaptive interfaces.", "htmlHref": "/research/html/recursive-polymodal-synthesis-for-real-time-embodied-interaction-a-contraction-based-f-502ah6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6029 }, { "id": "semantic-kernel-for-nko-language-processing-a-schema-locked-approach-to-low-resource-v-xv633u", "title": "Semantic Kernel for N'Ko Language Processing: A Schema-Locked Approach to Low-Resource Vocabulary Construction", "slug": "semantic-kernel-for-nko-language-processing-a-schema-locked-approach-to-low-resource-vocabulary-construction", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/core/semantic/cc-semantic-language/docs/research/PAPER_DRAFT.md", "extension": "md", "score": 98, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present a schema-locked, replayable semantic kernel for constructing and validating vocabulary in low-resource languages, with specific application to N'Ko, the indigenous script of the Manding language family. Our system introduces a 7-operator semantic algebra with formal legality grammar, a morphological compiler producing content-addressable forms with stable signatures, and an evidence-driven lifecycle model for vocabulary promotion. The evaluation methodology employs stress-profile-based adversarial testin", "excerpt": "We present a schema-locked, replayable semantic kernel for constructing and validating vocabulary in low-resource languages, with specific application to N'Ko, the indigenous script of the Manding language family. Our system introduces a 7-operator semantic algebra with formal legality grammar, a morphological compiler producing content-addressable forms with stable signatures, and an evidence-driven lifecycle model for vocabulary promotion. The evaluation methodology employs stress-profile-based adversarial testing with deterministic replay, enabling reproducible characterization of system behavior under controlled perturbation. All experimental artifacts—including the evaluation protocol, stress profiles, benchmark schema, and reproduction scripts—are released with the system. The system provides foundational infrastructure for low-resource language technology while explicitly not claiming linguistic authority or community standardization replacement.", "htmlHref": "/research/html/semantic-kernel-for-nko-language-processing-a-schema-locked-approach-to-low-resource-v-xv633u.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2700 }, { "id": "from-dead-circuits-to-living-speech-activation-profiling-and-script-native-asr-for-nko-1jch0ly", "title": "From Dead Circuits to Living Speech: Activation Profiling and Script-Native ASR for N'Ko", "slug": "from-dead-circuits-to-living-speech-activation-profiling-and-script-native-asr-for-nko", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/nko_asr_paper_v2.md", "extension": "md", "score": 98, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "N'Ko is an alphabetic script serving over 40 million Manding-language speakers across West Africa, engineered by Solomana Kanté in 1949 with a strict 1:1 phoneme-to-character mapping, explicit tonal diacritics, and zero spelling exceptions. We present a dual-thread investigation into why large language models (LLMs) fail on N'Ko and how to build audio-to-N'Ko speech recognition that bypasses LLMs entirely. **Thread 1 (Diagnostic):** We perform activation profiling — a \"brain scan\" — of Qwen2-72B-Instruct (4-bit NF4", "excerpt": "N'Ko is an alphabetic script serving over 40 million Manding-language speakers across West Africa, engineered by Solomana Kanté in 1949 with a strict 1:1 phoneme-to-character mapping, explicit tonal diacritics, and zero spelling exceptions. We present a dual-thread investigation into why large language models (LLMs) fail on N'Ko and how to build audio-to-N'Ko speech recognition that bypasses LLMs entirely. **Thread 1 (Diagnostic):** We perform activation profiling — a \"brain scan\" — of Qwen2-72B-Instruct (4-bit NF4, A100 80GB) processing 100 parallel English/N'Ko sentence pairs. Across all 81 layers, N'Ko induces a 2.90x translation tax (L2 norm ratio), 30–60% entropy inflation, 85.8% kurtosis deficit at the output layer, and 150% higher sparsity at embedding. Circuit duplication analysis (55 configurations, RYS methodology) shows 0/55 N'Ko-advantageous configurations; the best N'Ko score of 0.067 barely exceeds random chance (0.05). Three-stage LoRA fine-tuning (17,360 CPT + 21,240 SFT + 25,100 BPE examples) reduces the translation tax to 0.70x — a 76% reduction. **Thread 2 (Solution):** We build the first audio-to-N'Ko ASR system. A frozen Whisper large-v3 encoder feeds a character-level CTC decoder. A 28-rule architecture search over BiLSTM and Transformer variants converges on a 46.9M-parameter Transformer with 4x temporal downsampling, achieving 33% CER and 70% WER on 37 hours of Bambara speech from bam-asr-early (CC-BY-4.0). A 4-state finite-state machine encoding N'Ko syllable phonotactics guarantees 100% structural validity. Total compute: $14.", "htmlHref": "/research/html/from-dead-circuits-to-living-speech-activation-profiling-and-script-native-asr-for-nko-1jch0ly.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6498 }, { "id": "recursive-polymodal-synthesis-for-real-time-embodied-interaction-a-contraction-based-f-12n4cyv", "title": "Recursive Polymodal Synthesis for Real-Time Embodied Interaction: A Contraction-Based Framework with Provable Convergence", "slug": "recursive-polymodal-synthesis-for-real-time-embodied-interaction-a-contraction-based-framework-with-provable-convergence", "kind": "working paper", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/05-research/RESEARCH_PAPER_TECHNICAL_PLAIN.md", "extension": "md", "score": 96, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present a mathematically rigorous framework for multi-modal sensor fusion in real-time embodied interaction systems. Our approach, termed Recursive Polymodal Synthesis (RPS), addresses the fundamental challenge of fusing heterogeneous sensor modalities with different noise characteristics, sampling rates, and semantic meanings into a coherent internal representation suitable for generative control. The key innovation is a proximal fixed-point iteration scheme that enforces cross-modal coherence through spectral-", "excerpt": "We present a mathematically rigorous framework for multi-modal sensor fusion in real-time embodied interaction systems. Our approach, termed Recursive Polymodal Synthesis (RPS), addresses the fundamental challenge of fusing heterogeneous sensor modalities with different noise characteristics, sampling rates, and semantic meanings into a coherent internal representation suitable for generative control. The key innovation is a proximal fixed-point iteration scheme that enforces cross-modal coherence through spectral-norm-constrained relational operators, providing theoretical guarantees of convergence to a unique fixed point. We establish conditions under which the update operator is a contraction mapping on the latent representation space and prove convergence in at most mathcal(O)( log(1/ epsilon) iterations to achieve epsilon-accuracy. The framework processes sensor inputs through modality-specific encoders (E_m )_(m=1)^M, learns cross-modal predictors (T_m )_(m=1)^M with spectral norm |T_m |_2 leq sigma_( max) < 1, and iteratively refines representations via the proximal operator mathcal(P)_ alpha(z^(t)) = (1- alpha)E(x) + alpha T(z^(t)). Experimental validation on synthetic multi-modal data demonstrates 99.94% cross-modal coherence (measured via normalized mutual consistency), validation loss of 1.93 times 10^(-4), and inference latency of 15-40ms on commodity CPUs. We provide comprehensive ablation studies demonstrating the necessity of spectral constraints, analyze the learned representations through spectral analysis and information-theoretic measures, and establish performance bounds for deployment with real sensor data. Our framework achieves state-of-the-art performance on multi-modal fusion while maintaining mathematical rigor and computational efficiency, making it suitable for latency-critical applications including live performance, human-robot interaction, and adaptive interfaces.", "htmlHref": "/research/html/recursive-polymodal-synthesis-for-real-time-embodied-interaction-a-contraction-based-f-12n4cyv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6158 }, { "id": "recursive-polymodal-synthesis-a-framework-for-real-time-computational-choreography-thr-bdka5a", "title": "Recursive Polymodal Synthesis: A Framework for Real-Time Computational Choreography Through Multi-Modal Sensor Fusion", "slug": "recursive-polymodal-synthesis-a-framework-for-real-time-computational-choreography-through-multi-modal-sensor-fusion", "kind": "working paper", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/05-research/RESEARCH_PAPER.md", "extension": "md", "score": 96, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present Recursive Polymodal Synthesis (RPS), a framework for real-time computational choreography that achieves robust multi-modal sensor fusion through iterative proximal updates with spectral norm constraints, and couples that embodied state to a phrase-conditioned spectrogram diffusion backend for audio generation. The system integrates kinematic, physiological, and rhythmic data streams into a unified embodied representation that drives either smooth control signals or direct audio synthesis in real time. Ou", "excerpt": "We present Recursive Polymodal Synthesis (RPS), a framework for real-time computational choreography that achieves robust multi-modal sensor fusion through iterative proximal updates with spectral norm constraints, and couples that embodied state to a phrase-conditioned spectrogram diffusion backend for audio generation. The system integrates kinematic, physiological, and rhythmic data streams into a unified embodied representation that drives either smooth control signals or direct audio synthesis in real time. Our approach addresses three fundamental challenges in embodied interaction systems: maintaining cross-modal coherence under partial observability, generating temporally coherent responses at multiple timescales, and operating within strict latency budgets. Through modality-specific encoders, cross-modal translators, and proximal fixed-point iteration, we obtain high cross-modal coherence on synthetic validation data, while the phrase-conditioned diffusion + conductor stack achieves library-faithful audio generation evaluated with objective and perceptual metrics on real recordings. End-to-end, the system processes sensor inputs with 15–40 ms control latency and supports bar-ahead audio rendering with ~0.5–1.0 s prebuffer for stage performance. We report cross-modal coherence, beat-alignment error, key stability, spectral bandwidth/flatness, Fréchet Audio Distance, and human listening tests, and analyze trade-offs between model capacity, computational efficiency, and perceived expressivity. The framework is extensible to additional modalities and applications beyond computational choreography, including human–robot interaction, adaptive gaming interfaces, and assistive technologies.", "htmlHref": "/research/html/recursive-polymodal-synthesis-a-framework-for-real-time-computational-choreography-thr-bdka5a.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 9126 }, { "id": "topological-preference-optimization-tpo-a-novel-training-strategy-for-conversational-a-8qhydp", "title": "Topological Preference Optimization (TPO): A Novel Training Strategy for Conversational AI", "slug": "topological-preference-optimization-tpo-a-novel-training-strategy-for-conversational-ai", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/docs/TOPO_DOCUMENTATION.md", "extension": "md", "score": 94, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We introduce **Topological Preference Optimization (TPO)**, a novel training methodology that leverages conversation topology and spatial-temporal coordinates to generate preference datasets for language model training. Unlike traditional Direct Preference Optimization (DPO) which relies on human annotations or simple heuristics, TPO extracts preference signals directly from the structural properties of conversation graphs, incorporating hindsight knowledge and topological awareness to create more accurate and cont", "excerpt": "We introduce **Topological Preference Optimization (TPO)**, a novel training methodology that leverages conversation topology and spatial-temporal coordinates to generate preference datasets for language model training. Unlike traditional Direct Preference Optimization (DPO) which relies on human annotations or simple heuristics, TPO extracts preference signals directly from the structural properties of conversation graphs, incorporating hindsight knowledge and topological awareness to create more accurate and contextually informed training data.", "htmlHref": "/research/html/topological-preference-optimization-tpo-a-novel-training-strategy-for-conversational-a-8qhydp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1714 }, { "id": "topological-preference-optimization-tpo-a-novel-training-strategy-for-conversational-a-8mbdsc", "title": "Topological Preference Optimization (TPO): A Novel Training Strategy for Conversational AI", "slug": "topological-preference-optimization-tpo-a-novel-training-strategy-for-conversational-ai", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/docs/TOPO_DOCUMENTATION.md", "extension": "md", "score": 94, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We introduce **Topological Preference Optimization (TPO)**, a novel training methodology that leverages conversation topology and spatial-temporal coordinates to generate preference datasets for language model training. Unlike traditional Direct Preference Optimization (DPO) which relies on human annotations or simple heuristics, TPO extracts preference signals directly from the structural properties of conversation graphs, incorporating hindsight knowledge and topological awareness to create more accurate and cont", "excerpt": "We introduce **Topological Preference Optimization (TPO)**, a novel training methodology that leverages conversation topology and spatial-temporal coordinates to generate preference datasets for language model training. Unlike traditional Direct Preference Optimization (DPO) which relies on human annotations or simple heuristics, TPO extracts preference signals directly from the structural properties of conversation graphs, incorporating hindsight knowledge and topological awareness to create more accurate and contextually informed training data.", "htmlHref": "/research/html/topological-preference-optimization-tpo-a-novel-training-strategy-for-conversational-a-8mbdsc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1714 }, { "id": "memory-augmented-equilibrium-control-maec-5vn3wn", "title": "Memory-Augmented Equilibrium Control (MAEC)", "slug": "memory-augmented-equilibrium-control-maec", "kind": "working paper", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/01-architecture/MAEC_FRAMEWORK.md", "extension": "md", "score": 92, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "This document formalizes **Memory-Augmented Equilibrium Control (MAEC)**, a control-theoretic framework for real-time embodied creative systems. MAEC addresses a class of problems where traditional control theory and reinforcement learning fail: continuous, non-episodic systems that must maintain expressive viability while generating novel outputs. Unlike RL, MAEC has no scalar reward function, no policy optimization loop, and no episodic resets. Instead, it preserves dynamic equilibrium through memory-conditioned ", "excerpt": "This document formalizes **Memory-Augmented Equilibrium Control (MAEC)**, a control-theoretic framework for real-time embodied creative systems. MAEC addresses a class of problems where traditional control theory and reinforcement learning fail: continuous, non-episodic systems that must maintain expressive viability while generating novel outputs. Unlike RL, MAEC has no scalar reward function, no policy optimization loop, and no episodic resets. Instead, it preserves dynamic equilibrium through memory-conditioned selection of speculative futures. MAEC was developed in the context of Computational Choreography—a system where human motion generates music in real time—but applies broadly to any domain where trajectory matters more than static output.", "htmlHref": "/research/html/memory-augmented-equilibrium-control-maec-5vn3wn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3085 }, { "id": "retrieval-centric-asr-for-nko-exploiting-script-structure-to-beat-sequence-to-sequence-afq47k", "title": "Retrieval-Centric ASR for N'Ko: Exploiting Script Structure to Beat Sequence-to-Sequence", "slug": "retrieval-centric-asr-for-nko-exploiting-script-structure-to-beat-sequence-to-sequence", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/asr_paper_draft.md", "extension": "md", "score": 90, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present a retrieval-centric automatic speech recognition (ASR) architecture for Bambara, targeting N'Ko script output directly rather than routing through Latin transcription. The central insight is structural: N'Ko enforces a strict 1:1 phoneme-to-grapheme mapping, explicit tonal diacritics, and a mathematically complete syllable inventory of 3,024 entries (all V, VN, CV, and CVN patterns across five tones). This finite, well-structured output space makes retrieval a better fit than sequence-to-sequence decodin", "excerpt": "We present a retrieval-centric automatic speech recognition (ASR) architecture for Bambara, targeting N'Ko script output directly rather than routing through Latin transcription. The central insight is structural: N'Ko enforces a strict 1:1 phoneme-to-grapheme mapping, explicit tonal diacritics, and a mathematically complete syllable inventory of 3,024 entries (all V, VN, CV, and CVN patterns across five tones). This finite, well-structured output space makes retrieval a better fit than sequence-to-sequence decoding. Our pipeline freezes a Whisper encoder to extract audio embeddings, projects them into a shared 512-dimensional space alongside N'Ko syllable embeddings, and retrieves the nearest codebook entry at each step. A 4-state finite-state machine (FSM) encoding N'Ko phonotactics constrains beam search during assembly, guaranteeing that every output token sequence forms a valid N'Ko syllable chain. Training data comes from two YouTube sources: 1,461 episodes of Djoko dialogue (audio + FarmRadio Whisper transcription, bridged to N'Ko) and 532 babamamadidiane teaching videos (dynamic scene detection + Gemini 3 Flash OCR for on-screen N'Ko extraction). The current best published result for Bambara ASR is MALIBA-AI bambara-asr-v3 at 45.73% WER on Latin-script output. Our architecture bypasses Latin entirely. Quantitative results on real audio will be reported as training completes. **Keywords:** low-resource ASR, N'Ko, Bambara, Manding, retrieval-augmented, finite-state machine, CTC, script-structure exploitation", "htmlHref": "/research/html/retrieval-centric-asr-for-nko-exploiting-script-structure-to-beat-sequence-to-sequence-afq47k.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4071 }, { "id": "rag-state-based-retrieval-for-life-trajectory-optimization-1krjdyl", "title": "RAG++: State-Based Retrieval for Life Trajectory Optimization", "slug": "rag-state-based-retrieval-for-life-trajectory-optimization", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/research/RAG_PLUS_PLUS_PAPER.md", "extension": "md", "score": 88, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present RAG++ (Retrieval-Augmented Generation Plus Plus), a novel retrieval paradigm that extends traditional RAG from semantic text retrieval to **state-space transition retrieval**. Instead of retrieving \"relevant documents,\" RAG++ retrieves **successful state transitions** from a user's personal history and recommends actions based on what worked in similar dynamical regimes. We demonstrate this approach in TrajectoryOS, a life physics modeling system that treats human life as a dynamical system with measurab", "excerpt": "We present RAG++ (Retrieval-Augmented Generation Plus Plus), a novel retrieval paradigm that extends traditional RAG from semantic text retrieval to **state-space transition retrieval**. Instead of retrieving \"relevant documents,\" RAG++ retrieves **successful state transitions** from a user's personal history and recommends actions based on what worked in similar dynamical regimes. We demonstrate this approach in TrajectoryOS, a life physics modeling system that treats human life as a dynamical system with measurable state variables (thrust, alignment, gravity, mass) and an escape index η = T/(G×M). RAG++ operates in three geometries simultaneously—topological (DLM coordinates), temporal (cyclic phases), and dynamical (physics regime)—enabling context-aware policy recommendations that account for structural position, recurrence patterns, and operating constraints. Initial implementation shows promising results with 70% action classification accuracy and interpretable transition-based reasoning. **Keywords**: Retrieval-Augmented Generation, State-Space Methods, Life Optimization, Dynamical Systems, Topological Search, Personal Analytics", "htmlHref": "/research/html/rag-state-based-retrieval-for-life-trajectory-optimization-1krjdyl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3511 }, { "id": "graph-augmented-recursive-language-models-for-personal-knowledge-systems-on7xez", "title": "Graph-Augmented Recursive Language Models for Personal Knowledge Systems", "slug": "graph-augmented-recursive-language-models-for-personal-knowledge-systems", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/paper/cog-rlm-paper.md", "extension": "md", "score": 88, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present Cog-RLM, a graph-augmented recursive language model architecture for personal knowledge systems that achieves 90.3% accuracy on a comprehensive 103-question multi-dimensional evaluation using a stock 3-billion parameter model with zero fine-tuning and zero inference cost. Our system extends the Recursive Language Model (RLM) paradigm (Zhang et al., 2025) with three novel contributions: (1) a local knowledge graph providing relationship-aware context retrieval, (2) a hybrid decomposition classifier that s", "excerpt": "We present Cog-RLM, a graph-augmented recursive language model architecture for personal knowledge systems that achieves 90.3% accuracy on a comprehensive 103-question multi-dimensional evaluation using a stock 3-billion parameter model with zero fine-tuning and zero inference cost. Our system extends the Recursive Language Model (RLM) paradigm (Zhang et al., 2025) with three novel contributions: (1) a local knowledge graph providing relationship-aware context retrieval, (2) a hybrid decomposition classifier that selectively triggers recursive processing only for multi-hop queries, and (3) a persistent semantic retrieval layer using sentence-transformer embeddings. We evaluate across ten dimensions grouped into four categories—Retrieval (recall, precision, consistency), Reasoning (reasoning, inference), Robustness (counterfactual, adversarial, negation), and Flexibility (temporal, generalization)—demonstrating that architectural augmentation of small models can match or exceed the performance of larger fine-tuned models on domain-specific knowledge tasks. The full evaluation suite comprises 174 regression tests including behavioral policy compliance and format adherence checks. Our approach requires no training data, runs entirely on consumer hardware (Apple M4, 16GB), and processes queries in 1.0–12.5 seconds. **Keywords:** Recursive Language Models, Knowledge Graphs, Retrieval-Augmented Generation, Personal AI, Small Language Models", "htmlHref": "/research/html/graph-augmented-recursive-language-models-for-personal-knowledge-systems-on7xez.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2311 }, { "id": "geometric-motifs-for-selecting-and-routing-coding-agent-training-data-1tyi85b", "title": "Geometric Motifs for Selecting and Routing Coding-Agent Training Data", "slug": "geometric-motifs-for-selecting-and-routing-coding-agent-training-data", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "karl/paper/behavioral-motifs-paper.md", "extension": "md", "score": 88, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present a method for compactly annotating coding agent sessions with behavioral motifs and geometric features, then conditioning training data generation on these annotations. From 834 real multi-project coding sessions spanning 4,633 turn-level records across 50+ applications, we extract 10-category symbolic labels (inscriptions) and 5 continuous geometric scalars. We show that: (1) transition pressure predicts session convergence at 71.8% accuracy (z = 2.72, p < 0.007), (2) advantage-weighted training using th", "excerpt": "We present a method for compactly annotating coding agent sessions with behavioral motifs and geometric features, then conditioning training data generation on these annotations. From 834 real multi-project coding sessions spanning 4,633 turn-level records across 50+ applications, we extract 10-category symbolic labels (inscriptions) and 5 continuous geometric scalars. We show that: (1) transition pressure predicts session convergence at 71.8% accuracy (z = 2.72, p < 0.007), (2) advantage-weighted training using these annotations yields Cohen's d = 3.065 over random selection, and (3) geometry-conditioned routing produces higher-specificity training data for inscription-type sessions (Cohen's d = +1.02) but requires balanced quota enforcement — unconstrained routing concentrates sessions in low-specificity lenses, reducing overall quality (d = -0.60 when corpus is residual-dominated). Motivated by recent work on conditional memory in transformers [1], we test whether retrieval-conditioned supervision, where the model is trained on annotated behavioral patterns directly, further improves downstream performance. We describe the annotation pipeline, routing mechanism, quality verification, and iterative reward loop, and report results from a deployment spanning 50+ applications across 5 machines.", "htmlHref": "/research/html/geometric-motifs-for-selecting-and-routing-coding-agent-training-data-1tyi85b.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4751 }, { "id": "enhanced-topological-preference-optimization-a-unified-framework-for-multi-dimensional-1y21fp", "title": "Enhanced Topological Preference Optimization: A Unified Framework for Multi-Dimensional Conversation Analysis with Spatial Intelligence and Cross-Conversation Consolidation", "slug": "enhanced-topological-preference-optimization-a-unified-framework-for-multi-dimensional-conversation-analysis-with-spatial-intelligence-and-cross-conversation-consolidation", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/ENHANCED_TPO_DETAILED_RESEARCH.md", "extension": "md", "score": 86, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present a comprehensive enhancement to Topological Preference Optimization (TPO) that integrates spatial intelligence, cross-conversation consolidation, and advanced pattern recognition for conversation analysis. Our unified framework processes hierarchical conversation structures through a four-dimensional spatial coordinate system, implements adaptive clustering algorithms for pattern detection, and employs sophisticated natural language processing techniques for knowledge consolidation across conversation bou", "excerpt": "We present a comprehensive enhancement to Topological Preference Optimization (TPO) that integrates spatial intelligence, cross-conversation consolidation, and advanced pattern recognition for conversation analysis. Our unified framework processes hierarchical conversation structures through a four-dimensional spatial coordinate system, implements adaptive clustering algorithms for pattern detection, and employs sophisticated natural language processing techniques for knowledge consolidation across conversation boundaries. The system operates on a dataset of 277 conversations containing 60,534 messages with 5,640,182 pre-computed similarity relationships. Through detailed algorithmic analysis and mathematical formulation, we demonstrate the system's capability to detect complex conversation patterns including knowledge transfer behaviors, experimental branching structures, and cross-conversation semantic relationships. The enhanced framework provides a robust foundation for preference dataset generation that captures non-linear conversation dynamics often missed by traditional linear approaches. **Keywords:** Conversation Analysis, Topological Optimization, Spatial Coordinate Systems, Knowledge Transfer Detection, Multi-Dimensional Clustering, Cross-Conversation Analysis", "htmlHref": "/research/html/enhanced-topological-preference-optimization-a-unified-framework-for-multi-dimensional-1y21fp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3902 }, { "id": "enhanced-topological-preference-optimization-a-unified-framework-for-multi-dimensional-79c7hq", "title": "Enhanced Topological Preference Optimization: A Unified Framework for Multi-Dimensional Conversation Analysis with Spatial Intelligence and Cross-Conversation Consolidation", "slug": "enhanced-topological-preference-optimization-a-unified-framework-for-multi-dimensional-conversation-analysis-with-spatial-intelligence-and-cross-conversation-consolidation", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/ENHANCED_TPO_DETAILED_RESEARCH.md", "extension": "md", "score": 86, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present a comprehensive enhancement to Topological Preference Optimization (TPO) that integrates spatial intelligence, cross-conversation consolidation, and advanced pattern recognition for conversation analysis. Our unified framework processes hierarchical conversation structures through a four-dimensional spatial coordinate system, implements adaptive clustering algorithms for pattern detection, and employs sophisticated natural language processing techniques for knowledge consolidation across conversation bou", "excerpt": "We present a comprehensive enhancement to Topological Preference Optimization (TPO) that integrates spatial intelligence, cross-conversation consolidation, and advanced pattern recognition for conversation analysis. Our unified framework processes hierarchical conversation structures through a four-dimensional spatial coordinate system, implements adaptive clustering algorithms for pattern detection, and employs sophisticated natural language processing techniques for knowledge consolidation across conversation boundaries. The system operates on a dataset of 277 conversations containing 60,534 messages with 5,640,182 pre-computed similarity relationships. Through detailed algorithmic analysis and mathematical formulation, we demonstrate the system's capability to detect complex conversation patterns including knowledge transfer behaviors, experimental branching structures, and cross-conversation semantic relationships. The enhanced framework provides a robust foundation for preference dataset generation that captures non-linear conversation dynamics often missed by traditional linear approaches. **Keywords:** Conversation Analysis, Topological Optimization, Spatial Coordinate Systems, Knowledge Transfer Detection, Multi-Dimensional Clustering, Cross-Conversation Analysis", "htmlHref": "/research/html/enhanced-topological-preference-optimization-a-unified-framework-for-multi-dimensional-79c7hq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3902 }, { "id": "mixture-of-anticipatory-orthogonal-experts-for-nko-asr-10m6pyr", "title": "Mixture of Anticipatory Orthogonal Experts for N'Ko ASR", "slug": "mixture-of-anticipatory-orthogonal-experts-for-nko-asr", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "MAOE-NKo-Technical-Architecture.md", "extension": "md", "score": 86, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "MAOE-N'Ko, the Mixture of Anticipatory Orthogonal Experts for N'Ko ASR, is a modular speech-language correction architecture that keeps the acoustic model sovereign while allowing language-prior intelligence to act only where it is admissible. The system begins with a verified N'Ko trajectory CTC acoustic model, currently anchored by the Paper 4 reproduction checkpoint with 20.57 percent CER on the locked N'Ko run. Instead of replacing that model with a monolithic audio-language system, MAOE-N'Ko routes each ASR ch", "excerpt": "MAOE-N'Ko, the Mixture of Anticipatory Orthogonal Experts for N'Ko ASR, is a modular speech-language correction architecture that keeps the acoustic model sovereign while allowing language-prior intelligence to act only where it is admissible. The system begins with a verified N'Ko trajectory CTC acoustic model, currently anchored by the Paper 4 reproduction checkpoint with 20.57 percent CER on the locked N'Ko run. Instead of replacing that model with a monolithic audio-language system, MAOE-N'Ko routes each ASR chunk into an anticipation partition: stable, boundary, uncertain, recovery, or novelty. Each partition activates a different expert lane with a distinct authority contract: acoustic preservation, boundary completion, uncertain repair, recovery context, or novelty quarantine. The architecture differs from a conventional mixture-of-experts model because the experts are orthogonal in authority, not merely parallel in capacity. A normal MoE router selects among experts that all try to improve token likelihood. MAOE-N'Ko selects among experts that are allowed to do fundamentally different things. Stable evidence is preserved. Boundary evidence can accept a small completion. Uncertain evidence can consult an AGP correction prior and TurboQuant-backed retrieval. Recovery evidence can use context, but under a stricter edit cap. Novel evidence is blocked from language-prior normalization and routed into review/corpus growth. The final accept/reject decision is not made by the neural model. It is made by a deterministic Rust control plane with an admissibility witness. The result is not merely \"ASR plus a language model.\" It is a layered authority system for endangered-script speech recognition. The acoustic model answers what was heard. AGP proposes what may be structurally plausible. TurboQuant compresses retrieval and provenance state. RAG++ and Graph Kernel-style witnesses preserve evidence chains. Rust enforces bounded correction. Future Core ML / Apple Neural Engine heads can run the small route, vitality, and partition classifiers without claiming that ANE replaces full transformer inference. The paper contribution becomes credible if same-snapshot Paper 4 replay shows lower CER after expert routing while accepted-worse corrections remain zero or statistically negligible.", "htmlHref": "/research/html/mixture-of-anticipatory-orthogonal-experts-for-nko-asr-10m6pyr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2467 }, { "id": "organic-vocabulary-acquisition-for-low-resource-african-languages-a-video-first-approa-1bkiqzx", "title": "Organic Vocabulary Acquisition for Low-Resource African Languages: A Video-First Approach to N'Ko and Manding Language Processing", "slug": "organic-vocabulary-acquisition-for-low-resource-african-languages-a-video-first-approach-to-nko-and-manding-language-processing", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "projects/LearnNKo/docs/TECHNICAL_ARCHITECTURE.md", "extension": "md", "score": 84, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "This document presents a novel approach to building state-of-the-art natural language processing systems for N'Ko, Bambara, and related Manding languages spoken by approximately forty million people across West Africa. Unlike traditional corpus-driven methodologies that depend on pre-existing parallel texts such as Bible translations or government documents, we introduce a video-first organic vocabulary discovery system that extracts training data directly from educational YouTube content. The system processes vide", "excerpt": "This document presents a novel approach to building state-of-the-art natural language processing systems for N'Ko, Bambara, and related Manding languages spoken by approximately forty million people across West Africa. Unlike traditional corpus-driven methodologies that depend on pre-existing parallel texts such as Bible translations or government documents, we introduce a video-first organic vocabulary discovery system that extracts training data directly from educational YouTube content. The system processes video frames through multimodal optical character recognition, cross-references detections against the Ankataa dictionary containing over fifteen hundred verified entries, and expands vocabulary through AI-powered contextual generation across five distinct linguistic registers. This produces contextually-grounded training data suitable for automatic speech recognition, machine translation, and optical character recognition. The architecture currently processes content from seven N'Ko educational channels comprising nine hundred sixty-nine videos representing an estimated five hundred hours of instructional material.", "htmlHref": "/research/html/organic-vocabulary-acquisition-for-low-resource-african-languages-a-video-first-approa-1bkiqzx.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2593 }, { "id": "the-first-reference-backed-proof-how-narrow-repairs-validate-the-agp-bridge-architectu-1mqe1wm", "title": "The First Reference-Backed Proof: How Narrow Repairs Validate the AGP Bridge Architecture", "slug": "the-first-reference-backed-proof-how-narrow-repairs-validate-the-agp-bridge-architecture", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/experiments/agp_mlx/asr_bridge/ESSAY_REFERENCE_BACKED_PROBE.md", "extension": "md", "score": 82, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "On 2026-04-21, the AGP bridge architecture achieved its first non-synthetic, reference-backed Character Error Rate (CER) improvement: a reduction from 0.7604 to 0.7512 on a curated slice of archived ASR evaluation data. This result, while numerically modest, constitutes a critical architectural validation. It demonstrates that a reference-leakage-free gating system—operating exclusively on hypothesis-side telemetry—can safely admit edits that improve supervised metrics. The improvement was not achieved through broa", "excerpt": "On 2026-04-21, the AGP bridge architecture achieved its first non-synthetic, reference-backed Character Error Rate (CER) improvement: a reduction from 0.7604 to 0.7512 on a curated slice of archived ASR evaluation data. This result, while numerically modest, constitutes a critical architectural validation. It demonstrates that a reference-leakage-free gating system—operating exclusively on hypothesis-side telemetry—can safely admit edits that improve supervised metrics. The improvement was not achieved through broad language-model-driven recovery, but through a narrow, bounded deletion of a repetitive artifact that the proposal model detected and the hardcap gate permitted. This essay examines the technical pathway to this result, its implications for the bridge's partition-based policy, and the constraints that must govern future expansion of the acceptance envelope.", "htmlHref": "/research/html/the-first-reference-backed-proof-how-narrow-repairs-validate-the-agp-bridge-architectu-1mqe1wm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1225 }, { "id": "arxiv-submission-graph-augmented-recursive-language-models-for-personal-knowledge-syst-1f631qz", "title": "arXiv Submission: Graph-Augmented Recursive Language Models for Personal Knowledge Systems", "slug": "arxiv-submission-graph-augmented-recursive-language-models-for-personal-knowledge-systems", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/paper/arxiv-submission/README.md", "extension": "md", "score": 82, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present Cog-RLM, a graph-augmented recursive language model architecture for personal knowledge systems that achieves 90.3% accuracy on a comprehensive 103-question evaluation spanning ten cognitive dimensions, using a stock 3-billion parameter model with zero fine-tuning and zero inference cost. Our system extends the Recursive Language Model (RLM) paradigm with three novel contributions: (1) a local knowledge graph providing relationship-aware context retrieval via breadth-first traversal, (2) a hybrid decompo", "excerpt": "We present Cog-RLM, a graph-augmented recursive language model architecture for personal knowledge systems that achieves 90.3% accuracy on a comprehensive 103-question evaluation spanning ten cognitive dimensions, using a stock 3-billion parameter model with zero fine-tuning and zero inference cost. Our system extends the Recursive Language Model (RLM) paradigm with three novel contributions: (1) a local knowledge graph providing relationship-aware context retrieval via breadth-first traversal, (2) a hybrid decomposition classifier that selectively triggers recursive processing only for multi-hop queries, reducing latency by 48% versus always-on decomposition, and (3) a persistent three-layer retrieval architecture combining static knowledge blocks, sentence-transformer embeddings, and graph traversal. We evaluate across ten dimensions—recall, reasoning, temporal, counterfactual, adversarial, generalization, consistency, precision, negation, and inference—demonstrating that architectural augmentation of small models outperforms fine-tuned models with 4× more parameters by a factor of 5.4× on domain-specific knowledge tasks.", "htmlHref": "/research/html/arxiv-submission-graph-augmented-recursive-language-models-for-personal-knowledge-syst-1f631qz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 625 }, { "id": "research-docs-5v5dmk", "title": "research — docs", "slug": "research-docs", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/apps/web/cc-studio/configs/mapping/docs/research.md", "extension": "md", "score": 80, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "This paper presents a retrieval-centric architecture for voice-controlled DJ performance that adapts the Speech-to-Order (S2O) streaming pipeline to the domain of professional DJ software, specifically Rekordbox. Instead of parsing transcribed text into intents via a conventional automatic speech recognition (ASR) and natural language understanding stack, the system learns a direct mapping between spoken commands and a catalog of DJ actions derived from Rekordbox’s performance preset mappings. The design combines a", "excerpt": "This paper presents a retrieval-centric architecture for voice-controlled DJ performance that adapts the Speech-to-Order (S2O) streaming pipeline to the domain of professional DJ software, specifically Rekordbox. Instead of parsing transcribed text into intents via a conventional automatic speech recognition (ASR) and natural language understanding stack, the system learns a direct mapping between spoken commands and a catalog of DJ actions derived from Rekordbox’s performance preset mappings. The design combines a streaming audio front end with 320-millisecond chunking, voice activity detection, denoising, and log-Mel features; a dual-encoder embedding space for audio and text; Gemini Live as an optional streaming front end for transcripts and text embeddings; and a symbolic constraint layer that enforces deck-aware safety and performance rules before triggering Rekordbox commands. The proposed system operates in both online and offline regimes. In online mode, Gemini Live provides low-latency transcripts and embeddings that feed the retrieval pipeline. In offline mode, a local audio encoder produces command embeddings directly from microphone audio. In both cases, a shared vector index over the Rekordbox command catalog provides fast nearest-neighbor search, and a constraint solver mediates between retrieved candidates and the current DJ state to prevent destructive operations such as loading tracks onto a playing deck. The paper describes the command catalog derived from Rekordbox mapping files, the streaming and embedding infrastructure, the safety and constraint design, and a data and training strategy that evolves from text-only retrieval to a fully trained audio–text dual encoder. Evaluation considerations and practical deployment notes round out the proposal.", "htmlHref": "/research/html/research-docs-5v5dmk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4047 }, { "id": "the-measure-theoretic-foundation-of-inverse-ring-contextual-propagation-1bge1jk", "title": "The Measure-Theoretic Foundation of Inverse Ring Contextual Propagation", "slug": "the-measure-theoretic-foundation-of-inverse-ring-contextual-propagation", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/docs/ICP.md", "extension": "md", "score": 80, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present Inverse Ring Contextual Propagation (I-RCP), a novel mathematical framework for modeling individual conversation dynamics through inverse mapping of response patterns. Unlike traditional approaches that optimize AI responses to match human preferences, I-RCP inverts the learning objective from P(v|u) to P(u|v), creating a direct model of individual response patterns within a rigorous mathematical structure. The framework introduces a three-dimensional coordinate system (x,y,z) that uniquely captures the ", "excerpt": "We present Inverse Ring Contextual Propagation (I-RCP), a novel mathematical framework for modeling individual conversation dynamics through inverse mapping of response patterns. Unlike traditional approaches that optimize AI responses to match human preferences, I-RCP inverts the learning objective from P(v|u) to P(u|v), creating a direct model of individual response patterns within a rigorous mathematical structure. The framework introduces a three-dimensional coordinate system (x,y,z) that uniquely captures the depth of thought progression, branching patterns in reasoning, and consistency in response patterns. Through a continuous ring topology that preserves both hierarchical relationships and contextual flow, I-RCP enables the study of individual conversation dynamics through the lens of measure-theoretic probability and differential geometry. Our primary innovation lies in the formulation of inverse attention mechanisms A'(C') that capture how individuals allocate attention and construct responses, governed by the differential equation dC'/dt = A'(C')C'. This formulation maintains critical conservation properties while enabling the study of individual response patterns through the pushforward measure φ₊μ on the inverse mapping space. The mathematical framework incorporates Hamiltonian mechanics for context flow, ergodic theory for pattern stability, and homology preservation for structural integrity. These theoretical foundations ensure that learned patterns maintain both mathematical rigor and psychological coherence. Through the integration of measure-preserving transformations and conservation laws, I-RCP provides a principled approach to understanding individual conversation patterns. Our framework demonstrates particular efficacy in capturing: 1. Individual thought progression patterns 2. Context utilization strategies 3. Response construction dynamics 4. Pattern consistency measures This work provides a rigorous mathematical foundation for studying individual conversation patterns, offering insights into both theoretical aspects of human communication and practical applications in personalized interaction systems. The framework's ability to maintain conservation properties while inverting the learning objective represents a significant advance in our understanding of conversational dynamics.", "htmlHref": "/research/html/the-measure-theoretic-foundation-of-inverse-ring-contextual-propagation-1bge1jk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4546 }, { "id": "the-measure-theoretic-foundation-of-inverse-ring-contextual-propagation-1cc3xnr", "title": "The Measure-Theoretic Foundation of Inverse Ring Contextual Propagation", "slug": "the-measure-theoretic-foundation-of-inverse-ring-contextual-propagation", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/docs/ICP.md", "extension": "md", "score": 80, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present Inverse Ring Contextual Propagation (I-RCP), a novel mathematical framework for modeling individual conversation dynamics through inverse mapping of response patterns. Unlike traditional approaches that optimize AI responses to match human preferences, I-RCP inverts the learning objective from P(v|u) to P(u|v), creating a direct model of individual response patterns within a rigorous mathematical structure. The framework introduces a three-dimensional coordinate system (x,y,z) that uniquely captures the ", "excerpt": "We present Inverse Ring Contextual Propagation (I-RCP), a novel mathematical framework for modeling individual conversation dynamics through inverse mapping of response patterns. Unlike traditional approaches that optimize AI responses to match human preferences, I-RCP inverts the learning objective from P(v|u) to P(u|v), creating a direct model of individual response patterns within a rigorous mathematical structure. The framework introduces a three-dimensional coordinate system (x,y,z) that uniquely captures the depth of thought progression, branching patterns in reasoning, and consistency in response patterns. Through a continuous ring topology that preserves both hierarchical relationships and contextual flow, I-RCP enables the study of individual conversation dynamics through the lens of measure-theoretic probability and differential geometry. Our primary innovation lies in the formulation of inverse attention mechanisms A'(C') that capture how individuals allocate attention and construct responses, governed by the differential equation dC'/dt = A'(C')C'. This formulation maintains critical conservation properties while enabling the study of individual response patterns through the pushforward measure φ₊μ on the inverse mapping space. The mathematical framework incorporates Hamiltonian mechanics for context flow, ergodic theory for pattern stability, and homology preservation for structural integrity. These theoretical foundations ensure that learned patterns maintain both mathematical rigor and psychological coherence. Through the integration of measure-preserving transformations and conservation laws, I-RCP provides a principled approach to understanding individual conversation patterns. Our framework demonstrates particular efficacy in capturing: 1. Individual thought progression patterns 2. Context utilization strategies 3. Response construction dynamics 4. Pattern consistency measures This work provides a rigorous mathematical foundation for studying individual conversation patterns, offering insights into both theoretical aspects of human communication and practical applications in personalized interaction systems. The framework's ability to maintain conservation properties while inverting the learning objective represents a significant advance in our understanding of conversational dynamics.", "htmlHref": "/research/html/the-measure-theoretic-foundation-of-inverse-ring-contextual-propagation-1cc3xnr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4546 }, { "id": "rag-specification-szaqv4", "title": "RAG++ Specification", "slug": "rag-specification", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/SPECIFICATION.md", "extension": "md", "score": 80, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "RAG++ is a high-performance retrieval engine that provides **statistical priors** from outcome-annotated trajectories. Unlike traditional RAG systems that retrieve text for language model context, RAG++ retrieves structured execution traces and computes distributional statistics for downstream policy conditioning. **Key Insight**: Past execution outcomes encode implicit knowledge about action feasibility, timing, and context-dependent success rates. RAG++ surfaces this knowledge as queryable priors.", "excerpt": "RAG++ is a high-performance retrieval engine that provides **statistical priors** from outcome-annotated trajectories. Unlike traditional RAG systems that retrieve text for language model context, RAG++ retrieves structured execution traces and computes distributional statistics for downstream policy conditioning. **Key Insight**: Past execution outcomes encode implicit knowledge about action feasibility, timing, and context-dependent success rates. RAG++ surfaces this knowledge as queryable priors.", "htmlHref": "/research/html/rag-specification-szaqv4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1537 }, { "id": "cognitive-twin-research-paper-1v82jke", "title": "cognitive twin research paper", "slug": "cognitive-twin-research-paper", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "cognitive-twin-research-paper.tex", "extension": "tex", "score": 78, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "% Options for packages loaded elsewhere \\PassOptionsToPackage{unicode}{hyperref} \\PassOptionsToPackage{hyphens}{url} \\documentclass[ 11pt, ]{article} \\usepackage{xcolor} \\usepackage[margin=1in]{geometry} \\usepackage{amsmath,amssymb} \\setcounter{secnumdepth}{-\\maxdimen} % remove section numbering \\usepackage{iftex} \\ifPDFTeX \\usepackage[T1]{fontenc} \\usepackage[utf8]{inputenc} \\usepackage{textcomp} % provide euro and other symbols \\else % if luatex or xetex \\usepackage{unicode-math} % this also loads fontspec \\defau", "excerpt": "\\section{Cognitive Twin Synthesis: A Recursive Polymodal Framework for Autonomous Agent Identity from Conversational Corpora}\\label{cognitive-twin-synthesis-a-recursive-polymodal-framework-for-autonomous-agent-identity-from-conversational-corpora}\n\nWe present a framework for constructing autonomous cognitive twins from large-scale conversational corpora. Building on the Recursive Polymodal Synthesis (RPS) framework, which fuses heterogeneous sensor modalities through Lipschitz-constrained fixed-point iteration, we extend cross-modal coherence theory from physical signals (accelerometer, gyroscope, heart rate) to cognitive modalities: linguistic style (\\(\\mathcal{V}_L\\)), decision patterns (\\(\\mathcal{V}_D\\)), domain knowledge (\\(\\mathcal{V}_K\\)), value alignment (\\(\\mathcal{V}_V\\)), and temporal rhythms (\\(\\mathcal{V}_T\\)). The corpus comprises 379,426 conversation turns spanning December 24, 2022 to March 18, 2026, collected across ChatGPT and Claude Code sessions, representing one of the largest known single-person conversational datasets used for cognitive modeling. We propose a 6-layer architecture --- the Living Executor --- progressing from knowledge ingestion (Journal), through voice replication (Mirror), meta-prompted identity (Conductor), multi-model consensus (Parliament), graduated autonomy (Apprentice), to decision-boundary modeling (Oracle). The central theoretical contribution is a formal extension of the RPS coherence energy functional \\(\\Phi(z; \\mathcal{A}, \\mathcal{T})\\) to cognitive space, where cross-cognitive translators \\(T_{n \\leftarrow m}\\) map between modalities and a proximal fixed-point iteration \\(z^{(t+1)} = \\mathcal{P}_\\alpha(z^{(t)}; x)\\) converges to a latent identity fixed point \\(z^*\\) --- a computational representation of the originator. The cognitive twin does not merely replicate voice; it maintains a persistent latent identity across sessions, makes decisions consistent with the originator's documented patterns, and earns autonomy through a formal graduation protocol. We define this protocol as the Autonomy Ratchet: a 4-level progression (Supervised, Spot-Checked, Directed, Autonomous) governed by a quality function \\(Q(a) \\in [0,1]\\) with auto-pass threshold 0.85, human-review band \\([0.60, 0.84]\\), and auto-reject below 0.60.\n\nConsider a system comprising 50+ deployed applications across 6 interconnected machines (Mac1--Mac5 plus a cloud-vm), 80+ operational skills, 54 Prefect automation flows, 5 storefronts, and a continuous integration pipeline that archives, signs, uploads, and submits iOS apps to TestFlight without human intervention. Every architectural decision, every priority call, every ``ship it or hold it'' judgment currently flows through a single person. This person is the fixed point around which th", "htmlHref": "/research/html/cognitive-twin-research-paper-1v82jke.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 13431 }, { "id": "recursive-language-model-integration-technical-specification-e4mioc", "title": "Recursive Language Model Integration: Technical Specification", "slug": "recursive-language-model-integration-technical-specification", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/agents/cc-orchestrator-agent/docs/RLM_TECHNICAL_SPECIFICATION.md", "extension": "md", "score": 76, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "This document specifies the architecture and implementation of the Recursive Language Model integration within the cc-orchestrator-agent module. The system provides an inference strategy enabling language models to process unbounded-length input contexts through recursive decomposition, treating context as a programmable variable rather than a monolithic prompt payload. This specification covers the theoretical foundation, architectural design, execution semantics, and integration with Graph Kernel memory systems a", "excerpt": "This document specifies the architecture and implementation of the Recursive Language Model integration within the cc-orchestrator-agent module. The system provides an inference strategy enabling language models to process unbounded-length input contexts through recursive decomposition, treating context as a programmable variable rather than a monolithic prompt payload. This specification covers the theoretical foundation, architectural design, execution semantics, and integration with Graph Kernel memory systems and RAG++ retrieval infrastructure.", "htmlHref": "/research/html/recursive-language-model-integration-technical-specification-e4mioc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2853 }, { "id": "computational-choreography-a-dense-manuscript-for-the-lume-stack-1woy06t", "title": "Computational Choreography: A Dense Manuscript for the LUME Stack", "slug": "computational-choreography-a-dense-manuscript-for-the-lume-stack", "kind": "working paper", "program": "Embodied Trajectory Systems", "sourceAnchor": "LUME-CC/01-foundation/mac4-manuscript.md", "extension": "md", "score": 76, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "Computational choreography is the name for the layer of LUME that interprets a performer's body as a live compositional instrument. It is not a synonym for motion capture, gesture recognition, depth rendering, or visual reactivity, although it depends on all of them. It is the discipline of deciding what the machine believes about the body, how that belief changes over time, how movement becomes intention, and how intention becomes a bounded visual or musical event. The current LUME stack already contains the physi", "excerpt": "Computational choreography is the name for the layer of LUME that interprets a performer's body as a live compositional instrument. It is not a synonym for motion capture, gesture recognition, depth rendering, or visual reactivity, although it depends on all of them. It is the discipline of deciding what the machine believes about the body, how that belief changes over time, how movement becomes intention, and how intention becomes a bounded visual or musical event. The current LUME stack already contains the physical and computational materials for such a system: Femto/Mega depth gives the real visible body, Sony mocopi gives a motion backbone, MotionMix gives a distributed body-state and camera mesh, Unity DYK gives the live pCloud performance host, the web fluid lab gives a fast experimental surface, rehearsal capture gives the training archive, and K11 AirDeck gives a separate safety-gated DJ control path. The task now is to bind these parts into a choreographic stack whose behavior is stable enough for performance, expressive enough to approach the Duncan reference direction, and introspective enough to learn Mo's movement vocabulary over time.", "htmlHref": "/research/html/computational-choreography-a-dense-manuscript-for-the-lume-stack-1woy06t.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4544 }, { "id": "bwb-kiosk-voice-ordering-architecture-19w1i3t", "title": "BWB Kiosk — Voice Ordering Architecture", "slug": "bwb-kiosk-voice-ordering-architecture", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "BWB/BWB_Kiosk/docs/VOICE-ORDERING-ARCHITECTURE.md", "extension": "md", "score": 74, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> *\"Break every component down to its grills... define a subsection and a sub-subsection that further builds upon the previous section, then expands it in a recursive manner.\"*", "excerpt": "# BWB Kiosk — Voice Ordering Architecture ### Deep Recursive Decomposition & Evolutionary Design *v2.0 — February 10, 2026 — Verified against codebase*\n\n> *\"Break every component down to its grills... define a subsection and a sub-subsection that further builds upon the previous section, then expands it in a recursive manner.\"*\n\n1. [Vision & Philosophy](#1-vision--philosophy) 2. [System Topology](#2-system-topology) 3. [Layer 1: Audio Foundation](#3-layer-1-audio-foundation) 4. [Layer 2: Speech-to-Text Pipeline](#4-layer-2-speech-to-text-pipeline) 5. [Layer 3: Natural Language Understanding](#5-layer-3-natural-language-understanding) 6. [Layer 4: Dialogue Engine](#6-layer-4-dialogue-engine) 7. [Layer 5: Order State Machine](#7-layer-5-order-state-machine) 8. [Layer 6: Synthesis & Feedback](#8-layer-6-synthesis--feedback) 9. [Layer 7: Interaction Surface](#9-layer-7-interaction-surface) 10. [Layer 8: Learning & Telemetry](#10-layer-8-learning--telemetry) 11. [Cross-Cutting: Error Taxonomy & Recovery](#11-cross-cutting-error-taxonomy--recovery) 12. [Cross-Cutting: Performance & Latency Budget](#12-cross-cutting-performance--latency-budget) 13. [Cross-Cutting: Privacy, Security, Offline](#13-cross-cutting-privacy-security-offline) 14. [State Machine Formal Specification](#14-state-machine-formal-specification) 15. [End-to-End Flow Traces](#15-end-to-end-flow-traces) 16. [Gap Analysis: Current vs Next-Gen](#16-gap-analysis-current-vs-next-gen) 17. [Evolution Roadmap](#17-evolution-roadmap) 18. [Codebase Map (Verified)](#18-codebase-map-verified)\n\n### 1.1 Core Vision A voice ordering system that feels like the best barista conversation — one that understands messy human speech, self-corrections, contextual references, and emotional undertones — delivered at kiosk speed with zero training required.\n\n#### 1.2.1 Conversational Intelligence ##### [ip] Natural Speech Tolerance - **Disfluency handling**: \"um\", \"uh\", \"like\", \"so\" stripped by `TranscriptNormalizer` (228 LOC) - **Self-correction**: \"large, no wait, medium\" — correction markers detected: \"actually\", \"scratch that\", \"wait no\", \"I mean\", \"not that\" - **Partial utterances**: Streaming partial transcripts handled by `TranscriptPipeline` (188 LOC) — deduplicate \"med\" → \"medi\" → \"medium\" - **Run-on orders**: \"a latte and two cappuccinos and oh also a muffin\" — multi-item extraction via `EntityExtractor`", "htmlHref": "/research/html/bwb-kiosk-voice-ordering-architecture-19w1i3t.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 9778 }, { "id": "obsidian-vault-integration-architecture-operations-guide-1kmwrlp", "title": "Obsidian Vault Integration — Architecture & Operations Guide", "slug": "obsidian-vault-integration-architecture-operations-guide", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "projects/obsidian_vault_writer/ARCHITECTURE.md", "extension": "md", "score": 74, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| Store | Type | Weakness | |-------|------|----------| | `memory/*.md` files | Flat Markdown | No linking, manual curation, linear | | Kimi SQLite DB (`kimi_memory.db`) | Structured tables | Queryable but invisible, no graph | | Supabase | Cloud relational | API-only access, no browsing | | Orbit | Semantic memory | Black-box embeddings, no human navigation | | Discord threads | Chat messages | Ephemeral, unsearchable after scroll | | Plan files (`.claude/plans/`) | Task-scoped Markdown | Die when plans complete |", "excerpt": "**Version**: 0.2.0 **Created**: 2026-03-01 **Updated**: 2026-03-01 **Status**: Phase 1-4 complete, Phase 5 deferred\n\nKnowledge generated by the agent ecosystem is fragmented across 6+ disconnected stores:\n\n| Store | Type | Weakness | |-------|------|----------| | `memory/*.md` files | Flat Markdown | No linking, manual curation, linear | | Kimi SQLite DB (`kimi_memory.db`) | Structured tables | Queryable but invisible, no graph | | Supabase | Cloud relational | API-only access, no browsing | | Orbit | Semantic memory | Black-box embeddings, no human navigation | | Discord threads | Chat messages | Ephemeral, unsearchable after scroll | | Plan files (`.claude/plans/`) | Task-scoped Markdown | Die when plans complete |\n\nNone of these stores link ideas together. A synthesis about \"N'Ko voice keyboards\" doesn't know it's related to a Pulse session that built the \"Speak\" project, which connects to the \"voice recognition\" entity in the knowledge graph.\n\n**Obsidian's `[[bidirectional links]]`** solve this organically. Every `[[entity]]` reference creates a backlink, and over time the graph view reveals clusters, orphans, and unexpected connections between ideas. The `obsidian-headless` CLI (v0.0.3) makes the vault machine-writable without the desktop app.", "htmlHref": "/research/html/obsidian-vault-integration-architecture-operations-guide-1kmwrlp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 5009 }, { "id": "skill-entity-architecture-sea-dep-evo-cubed-analysis-1b07cjv", "title": "Skill Entity Architecture (SEA) — DEP + Evo-Cubed Analysis", "slug": "skill-entity-architecture-sea-dep-evo-cubed-analysis", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/CREATIVE_EVOLUTION_SEA_v1.md", "extension": "md", "score": 74, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> **Deprecation note (2026-05-13):** Mac3 was the Tier 2 worker host at the time this design doc was authored. Mac3 has since been retired. Forward-looking references to Mac3 (worker pool, async queue, circuit breaker) should be read as **Mac4:8100** (cognitive twin host) in any current/future implementation. The Mac3-era hardware-assignment sections (§2, Step 6, stress-test §🔴 Mac3 Async Worker Reliability) are kept for historical accuracy but are **obsolete for v1.1 onward**. See SOOP-2 launch memory for migrati", "excerpt": "# Skill Entity Architecture (SEA) — DEP + Evo-Cubed Analysis **Version:** 1.0 **Date:** 2025-07-18 **Protocol:** Deep Enhancement Protocol v2 + Evolution³ **Analyst:** Clawdbot Subagent (sea-dep-evocubed) **Concept Stage:** Pre-implementation / Concept Paper\n\n> **Deprecation note (2026-05-13):** Mac3 was the Tier 2 worker host at the time this design doc was authored. Mac3 has since been retired. Forward-looking references to Mac3 (worker pool, async queue, circuit breaker) should be read as **Mac4:8100** (cognitive twin host) in any current/future implementation. The Mac3-era hardware-assignment sections (§2, Step 6, stress-test §🔴 Mac3 Async Worker Reliability) are kept for historical accuracy but are **obsolete for v1.1 onward**. See SOOP-2 launch memory for migration plan. A v1.1 rewrite is tracked as a separate later track.\n\nThe Skill Entity Architecture (SEA) proposes inverting the current static-file skill system into a living ecosystem of autonomous, memory-bearing daemon entities. Creative/philosophical skills (phi:*, art:*, nav:*) — 13 of the 139 skills — become persistent conversational agents with their own Discord channels, chat history, and relevance scoring via MiniMax local inference. A router middleware intercepts every prompt/response pair, scores all skills 0–1, and injects activated skill perspectives (threshold ≥ 0.7) into the final response before delivery.\n\nThis analysis applies DEP-2 scoring discipline, then runs Evo³ to generate, compound, and specify the best achievable version of this idea.\n\n# ═══════════════════════════════════════════ # PART 1: DEP AUDIT # ═══════════════════════════════════════════", "htmlHref": "/research/html/skill-entity-architecture-sea-dep-evo-cubed-analysis-1b07cjv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 7922 }, { "id": "the-nko-compute-network-u0ub0h", "title": "The N'Ko Compute Network", "slug": "the-nko-compute-network", "kind": "whitepaper", "program": "Language as Infrastructure", "sourceAnchor": "NKo-Compute-Network-Whitepaper.md", "extension": "md", "score": 72, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Every existing compute network, from Bitcoin to Akash to Render, treats workers as interchangeable machines. The worker's identity, language, and culture are irrelevant to the protocol. This paper proposes a fundamentally different architecture: a compute network where the worker's linguistic and cultural competence IS the valuable computation, and the protocol pays for it in STX on Bitcoin's Layer 2. The N'Ko Compute Network combines three production systems into a single protocol: (1) the EPOCH Protocol, eight Cl", "excerpt": "Every existing compute network, from Bitcoin to Akash to Render, treats workers as interchangeable machines. The worker's identity, language, and culture are irrelevant to the protocol. This paper proposes a fundamentally different architecture: a compute network where the worker's linguistic and cultural competence IS the valuable computation, and the protocol pays for it in STX on Bitcoin's Layer 2. The N'Ko Compute Network combines three production systems into a single protocol: (1) the EPOCH Protocol, eight Clarity smart contracts on Stacks that route compute tasks and manage treasury distribution with $21.64 proven on testnet; (2) an N'Ko ASR pipeline with a 3,024-entry codebook, FarmRadio Whisper fine-tuned for Manding languages, and Gemini Flash OCR running on Vast.ai GPU infrastructure; and (3) a distributed mesh coordination layer with real-time task routing across five machines, proven at scale with Evolution World invariants and NUMU bus messaging. The thesis is simple. Over 40 million people speak Manding languages. Virtually zero AI training data exists in N'Ko, the script engineered by Solomana Kante in 1949 to give those languages a native written form. This protocol turns N'Ko speakers into compute nodes. Their linguistic competence, the ability to validate tonal accuracy, catch cultural misuse of proverbs, generate authentic text, is computation that no GPU can perform. The economic flywheel: learn N'Ko, become a worker, train the AI, AI improves, demand for workers grows, more people learn N'Ko. Cultural preservation becomes economic activity.", "htmlHref": "/research/html/the-nko-compute-network-u0ub0h.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4333 }, { "id": "inverse-ring-contextual-propagation-a-mathematical-framework-for-learning-individual-r-1yy8n5r", "title": "Inverse Ring Contextual Propagation: A Mathematical Framework for Learning Individual Response Patterns in Conversational Dynamics", "slug": "inverse-ring-contextual-propagation-a-mathematical-framework-for-learning-individual-response-patterns-in-conversational-dynamics", "kind": "working paper", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/research/00_title_page.md", "extension": "md", "score": 70, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "We present Inverse Ring Contextual Propagation (IRCP), a novel mathematical framework for modeling individual conversation dynamics through inverse mapping of response patterns. Unlike traditional approaches that optimize AI responses to match human preferences, IRCP inverts the learning objective from P(v|u) to P(u|v), creating a direct model of individual response patterns within a rigorous mathematical structure. The framework introduces a four-dimensional coordinate system (x,y,z,t) that uniquely captures the d", "excerpt": "We present Inverse Ring Contextual Propagation (IRCP), a novel mathematical framework for modeling individual conversation dynamics through inverse mapping of response patterns. Unlike traditional approaches that optimize AI responses to match human preferences, IRCP inverts the learning objective from P(v|u) to P(u|v), creating a direct model of individual response patterns within a rigorous mathematical structure. The framework introduces a four-dimensional coordinate system (x,y,z,t) that uniquely captures the depth of thought progression, branching patterns in reasoning, consistency in response patterns, and temporal evolution. Through a continuous ring topology that preserves both hierarchical relationships and contextual flow, IRCP enables the study of individual conversation dynamics through the lens of measure-theoretic probability and differential geometry. Our primary innovation lies in the formulation of inverse attention mechanisms A'(C') that capture how individuals allocate attention and construct responses, governed by the differential equation dC'/dt = A'(C')C'. This formulation maintains critical conservation properties while enabling the study of individual response patterns through the pushforward measure φ₊μ on the inverse mapping space. The mathematical framework incorporates Hamiltonian mechanics for context flow, ergodic theory for pattern stability, and homology preservation for structural integrity. These theoretical foundations ensure that learned patterns maintain both mathematical rigor and psychological coherence. Through the integration of measure-preserving transformations and conservation laws, IRCP provides a principled approach to understanding individual conversation patterns. Experimental validation on a dataset of 277 conversations (60,534 messages) demonstrates the framework's ability to learn stable individual response patterns while maintaining all conservation properties. The system achieves convergent training with measure preservation scores above 0.8 and stable ergodic properties.", "htmlHref": "/research/html/inverse-ring-contextual-propagation-a-mathematical-framework-for-learning-individual-r-1yy8n5r.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 314 }, { "id": "architecture-document-23-anticipatory-transformer-architecture-12n1c7n", "title": "Architecture Document 23: Anticipatory Transformer Architecture", "slug": "architecture-document-23-anticipatory-transformer-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/architecture/23-ANTICIPATORY_TRANSFORMER.md", "extension": "md", "score": 70, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Status**: Research Proposal (Revised) **Created**: 2026-01-04 **Revised**: 2026-01-04 (Incorporated engineering feedback) **Dependencies**: DELL Theory (19), Graph Kernel (15), Computational Choreography (01), TrajectoryOS (02)", "excerpt": "**Status**: Research Proposal (Revised) **Created**: 2026-01-04 **Revised**: 2026-01-04 (Incorporated engineering feedback) **Dependencies**: DELL Theory (19), Graph Kernel (15), Computational Choreography (01), TrajectoryOS (02)\n\nCurrent transformer architectures operate on **prediction**: given context, predict next token. This proposal introduces an **anticipatory transformer** that operates on **commitment detection**: given motion through semantic space, detect when futures become constrained enough to warrant action.\n\n**Key Insight**: Just as Comp-Core's motion intelligence detects when a gesture is irreversible (not when it completes), an anticipatory transformer should detect when semantic trajectories become committed, enabling earlier, more efficient generation.\n\n**Implementation Consequence**: Model outputs not just probabilities but **commitment scores** and **uncertainty estimates** that drive generation policy.\n\n**Problem**: \"Commitment\" is conceptually clear but needs a trainable target to avoid becoming a random-number generator correlated with logit sharpness.", "htmlHref": "/research/html/architecture-document-23-anticipatory-transformer-architecture-12n1c7n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 5572 }, { "id": "computational-choreography-complete-system-architecture-f6xriq", "title": "Computational Choreography - Complete System Architecture", "slug": "computational-choreography-complete-system-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/01-architecture/MASTER_ARCHITECTURE.md", "extension": "md", "score": 70, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The Computational Choreography (CC) system transforms raw motion sensor data into musically-coherent audio control signals. The architecture follows a strict **bottom-up dependency graph** where lower layers know nothing about higher layers.", "excerpt": "## Table of Contents 1. [Executive Overview](#1-executive-overview) 2. [System Stack Diagram](#2-system-stack-diagram) 3. [Crate Hierarchy](#3-crate-hierarchy) 4. [Layer-by-Layer Breakdown](#4-layer-by-layer-breakdown) 5. [Data Flow Pipeline](#5-data-flow-pipeline) 6. [Module Reference](#6-module-reference) 7. [Type System](#7-type-system) 8. [Frozen Contracts](#8-frozen-contracts) 9. [CC-Echelon Workspace Deep Dive](#9-cc-echelon-workspace-deep-dive) (18 crates, ~50,000 lines) 10. [CC-RAG-Plus-Plus Deep Dive](#10-cc-rag-plus-plus-deep-dive) (51 files, 24,879 lines) 11. [Python Layer Architecture](#11-python-layer-architecture) (~60,000 lines) 12. [Complete Data Flow Pipeline](#12-complete-data-flow-pipeline) 13. [FROZEN Contracts & Schema Versions](#13-frozen-contracts--schema-versions) 14. [Complete Crate Reference Table](#14-complete-crate-reference-table) 15. [Glossary of Key Terms](#15-glossary-of-key-terms)\n\nThe Computational Choreography (CC) system transforms raw motion sensor data into musically-coherent audio control signals. The architecture follows a strict **bottom-up dependency graph** where lower layers know nothing about higher layers.\n\n| Metric | Value | |--------|-------| | **Total Rust Crates** | 32 (13 top-level + 18 cc-echelon + 1 workspace) | | **Python Packages** | 2 (cc-ml, cc-core) | | **Total Rust Source Lines** | ~185,000 | | **Total Python Source Lines** | ~60,000 | | **cc-rag-plus-plus** | 24,879 lines (51 files) | | **cc-echelon workspace** | ~50,000 lines (18 sub-crates) | | **cc-window-aligner** | ~22,000 lines | | **cc-ml Python** | ~33,000 lines | | **cc-core Python** | ~27,000 lines | | **Test Coverage** | 400+ tests | | **FROZEN Contracts** | 5 (v1.0.0) | | **CC-Echelon Sub-crates** | 18 | | **ML Model Families** | 11 |\n\n| File | Lines | Purpose | |------|-------|---------| | `lib.rs` | 692 | LatentVector, Quaternion, Vec3, numeric utilities |\n\n| File | Lines | Purpose | |------|-------|---------| | `lib.rs` | 270 | Confidence, ValidityHorizon, SemanticValue, UnavailableReason | | `frame.rs` | 400 | SemanticFrame v1, SemanticFrameBuilder, SemanticProvenance | | `phase.rs` | 290 | CyclicCoordinate, PhaseState, PhaseType | | `momentum.rs` | 300 | HeadingVector, MomentumState, ImpulseIndicator | | `tension.rs` | 293 | TensionState, TensionTrend, TensionProxies | | `intent.rs` | 200 | IntentState, IntentAvailability | | `stability.rs` | 396 | StabilityState, StabilityFlags, HealthMetrics | | `regime.rs` | 335 | RegimeType, RegimeDescriptor, RegimeEvidence |", "htmlHref": "/research/html/computational-choreography-complete-system-architecture-f6xriq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 19829 }, { "id": "cross-pollination-architecture-specification-1g3j9m3", "title": "Cross-Pollination Architecture Specification", "slug": "cross-pollination-architecture-specification", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "pulse-gateway-api/docs/CROSSPOLL-SPEC.md", "extension": "md", "score": 70, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. [Overview](#1-overview) 2. [Prediction Engine](#2-prediction-engine) 3. [Safety Rails](#3-safety-rails) 4. [ACC Integration — Swipeable Prediction Cards](#4-acc-integration--swipeable-prediction-cards) 5. [Autonomous Mode](#5-autonomous-mode) 6. [Push Notifications](#6-push-notifications) 7. [Feedback Loop & DPO Training](#7-feedback-loop--dpo-training) 8. [API Reference](#8-api-reference) 9. [Data Models](#9-data-models) 10. [Deployment & Configuration](#10-deployment--configuration)", "excerpt": "> **PULSE V1 — Wave 1 Deliverable [A3]** > Status: COMPLETE | Author: Clawdbot Agent | Date: 2025-07-29\n\n1. [Overview](#1-overview) 2. [Prediction Engine](#2-prediction-engine) 3. [Safety Rails](#3-safety-rails) 4. [ACC Integration — Swipeable Prediction Cards](#4-acc-integration--swipeable-prediction-cards) 5. [Autonomous Mode](#5-autonomous-mode) 6. [Push Notifications](#6-push-notifications) 7. [Feedback Loop & DPO Training](#7-feedback-loop--dpo-training) 8. [API Reference](#8-api-reference) 9. [Data Models](#9-data-models) 10. [Deployment & Configuration](#10-deployment--configuration)\n\nCross-pollination is the system by which PULSE agents **proactively generate, predict, and execute work** without explicit human instruction. A personal Twin model predicts the user's likely next actions, routes them to the appropriate agent channel, and optionally executes autonomously — all while maintaining strict safety rails and a human-in-the-loop escape hatch.\n\nTraditional AI assistants are reactive: the user speaks, the assistant responds. Cross-pollination inverts this. The system observes the user's patterns (time of day, project state, recent conversations, unfinished tasks) and **generates the next move before the user asks**. The user's role shifts from director to reviewer — swipe right to approve, swipe left to dismiss.\n\nThis is the core mechanism behind the \"Age of Leisure\" vision: agents that work while you walk.", "htmlHref": "/research/html/cross-pollination-architecture-specification-1g3j9m3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 5546 }, { "id": "architecture-1bp57up", "title": "ARCHITECTURE", "slug": "architecture", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "spine/ARCHITECTURE.md", "extension": "md", "score": 70, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "3 > **Document Purpose**: Comprehensive operational map of all entities, projects, capabilities, and systems under host management. > > **Last Updated**: 2026-01-18 > > **Document Type**: Living reference — update as entities evolve", "excerpt": "3 > **Document Purpose**: Comprehensive operational map of all entities, projects, capabilities, and systems under host management. > > **Last Updated**: 2026-01-18 > > **Document Type**: Living reference — update as entities evolve\n\n1. [Host Layer](#1-host-layer) 2. [Entity Registry](#2-entity-registry) 3. [Entity 01: Meaningful Power](#3-entity-01-meaningful-power) 4. [Entity 02: Serenity Soother](#4-entity-02-serenity-soother) 5. [Entity 03: Computational Choreography (Comp-Core)](#5-entity-03-computational-choreography-comp-core) 6. [Entity 04: Brews With Beats](#6-entity-04-brews-with-beats) 7. [Entity 05: Milk Men (Sales Agent System)](#7-entity-05-milk-men-sales-agent-system) 8. [Entity 06: Buf Barista](#8-entity-06-buf-barista) 9. [Capability Pools](#9-capability-pools) 10. [Social Media Architecture](#10-social-media-architecture) 11. [Technical Infrastructure Map](#11-technical-infrastructure-map) 12. [Dependency Graph](#12-dependency-graph) 13. [Operational Profiles](#13-operational-profiles) 14. [Time Allocation Model](#14-time-allocation-model) 15. [Risk Registry](#15-risk-registry) 16. [Revenue Streams](#16-revenue-streams) 17. [Growth Trajectories](#17-growth-trajectories) 18. [Mode Switching Protocol](#18-mode-switching-protocol) 19. [Daily Operating System](#19-daily-operating-system) 20. [Weekly Rhythm](#20-weekly-rhythm) 21. [Quarterly Review Framework](#21-quarterly-review-framework)\n\nThese entities are **fractured parts of internal being**. They share a host but have **no inherent relationship to each other**. Each entity:\n\n- Has its own climate - Has its own rules - Has its own maintenance rhythm - Does not need to \"match\" other entities - Should be respected as independent\n\nThe metaphor is **sealed rooms in a building**, not organs in a body. You are the caretaker who moves between them.", "htmlHref": "/research/html/architecture-1bp57up.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 9838 }, { "id": "nko-asr-paper-v2-e65lqk", "title": "nko asr paper v2", "slug": "nko-asr-paper-v2", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/nko_asr_paper_v2.tex", "extension": "tex", "score": 68, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "% Options for packages loaded elsewhere \\PassOptionsToPackage{unicode}{hyperref} \\PassOptionsToPackage{hyphens}{url} \\documentclass[ ]{article} \\usepackage{xcolor} \\usepackage{amsmath,amssymb} \\setcounter{secnumdepth}{-\\maxdimen} % remove section numbering \\usepackage{iftex} \\ifPDFTeX \\usepackage[T1]{fontenc} \\usepackage[utf8]{inputenc} \\usepackage{textcomp} % provide euro and other symbols \\else % if luatex or xetex \\usepackage{unicode-math} % this also loads fontspec \\defaultfontfeatures{Scale=MatchLowercase} \\de", "excerpt": "\\section{From Dead Circuits to Living Speech: Activation Profiling and Script-Native ASR for N'Ko}\\label{from-dead-circuits-to-living-speech-activation-profiling-and-script-native-asr-for-nko}\n\nN'Ko is an alphabetic script serving over 40 million Manding-language speakers across West Africa, engineered by Solomana Kanté in 1949 with a strict 1:1 phoneme-to-character mapping, explicit tonal diacritics, and zero spelling exceptions. We present a dual-thread investigation into why large language models (LLMs) fail on N'Ko and how to build audio-to-N'Ko speech recognition that bypasses LLMs entirely.\n\n\\textbf{Thread 1 (Diagnostic):} We perform activation profiling --- a ``brain scan'' --- of Qwen2-72B-Instruct (4-bit NF4, A100 80GB) processing 100 parallel English/N'Ko sentence pairs. Across all 81 layers, N'Ko induces a 2.90x translation tax (L2 norm ratio), 30--60\\% entropy inflation, 85.8\\% kurtosis deficit at the output layer, and 150\\% higher sparsity at embedding. Circuit duplication analysis (55 configurations, RYS methodology) shows 0/55 N'Ko-advantageous configurations; the best N'Ko score of 0.067 barely exceeds random chance (0.05). Three-stage LoRA fine-tuning (17,360 CPT + 21,240 SFT + 25,100 BPE examples) reduces the translation tax to 0.70x --- a 76\\% reduction.\n\n\\textbf{Thread 2 (Solution):} We build the first audio-to-N'Ko ASR system. A frozen Whisper large-v3 encoder feeds a character-level CTC decoder. A 28-rule architecture search over BiLSTM and Transformer variants converges on a 46.9M-parameter Transformer with 4x temporal downsampling, achieving 33\\% CER and 70\\% WER on 37 hours of Bambara speech from bam-asr-early (CC-BY-4.0). A 4-state finite-state machine encoding N'Ko syllable phonotactics guarantees 100\\% structural validity. Total compute: \\$14.\n\nIn 1949, Solomana Kanté --- a self-taught linguist in Kankan, Guinea --- designed N'Ko in response to a claim that African languages were unsuitable for writing. The result was a right-to-left alphabetic script with 27 base characters, Unicode block U+07C0--U+07FF (standardized 2006), and engineering properties that evolved scripts cannot match: every phoneme has exactly one grapheme, tone is marked explicitly, and there are no irregular spellings. The name ``N'Ko'' (ߒߞߏ) means ``I say'' in all Manding languages.", "htmlHref": "/research/html/nko-asr-paper-v2-e65lqk.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6806 }, { "id": "voice-ordering-pipeline-architecture-1hvfkmr", "title": "Voice Ordering Pipeline Architecture", "slug": "voice-ordering-pipeline-architecture", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "BWB/docs/VOICE_PIPELINE_ARCHITECTURE.md", "extension": "md", "score": 66, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> **Purpose**: Comprehensive technical documentation for the voice ordering system refactoring. > **Last Updated**: December 26, 2025 > **Status**: ✅ Complete (10/10 Steps Done)", "excerpt": "> **Purpose**: Comprehensive technical documentation for the voice ordering system refactoring. > **Last Updated**: December 26, 2025 > **Status**: ✅ Complete (10/10 Steps Done)\n\n1. [Executive Summary](#executive-summary) 2. [Problem Statement](#problem-statement) 3. [Architecture Overview](#architecture-overview) 4. [Component Details](#component-details) 5. [Data Flow Pipeline](#data-flow-pipeline) 6. [App Routes & Views](#app-routes--views) 7. [File Structure](#file-structure) 8. [Implementation Checklist](#implementation-checklist) 9. [Integration Points](#integration-points) 10. [Technical Decisions](#technical-decisions) 11. [Testing Strategy](#testing-strategy) 12. [Rollback Plan](#rollback-plan)\n\nA **modular voice ordering pipeline** that decomposes the monolithic `VoiceOrderingService.swift` (2,464 lines) into 10 focused components:\n\n| # | Component | Lines | Responsibility | Status | |---|-----------|-------|----------------|--------| | 1 | FeedbackCoordinator | 337 | TTS + haptics + audio | ✅ DONE | | 2 | SessionManager | 270 | Session lifecycle | ✅ DONE | | 3 | UtteranceCompletionDetector | 407 | Silence/completion detection | ✅ DONE | | 4 | LiveOrderPreviewGenerator | 950 | Real-time item preview | ✅ DONE | | 5 | TranscriptPipeline | 552 | Transcript state management | ✅ DONE | | 6 | CartCoordinator | 440 | Cart state separation | ✅ DONE | | 7 | ConfirmationCoordinator | 626 | Confirmation flow | ✅ DONE | | 8 | OrderParsingPipeline | 1,016 | Hybrid AI+NLU parsing | ✅ DONE | | 9 | VoiceOrderingOrchestrator | 714 | Thin coordinator | ✅ DONE | | 10 | Testing & Cleanup | 600+ | Unit tests (207 tests, 181 passing) | ✅ DONE |\n\n1. **Parsing Strategy**: **Hybrid Merge** - Run AI and NLU parsers in parallel, merge results 2. **Live Preview**: **Pattern Matching** - Fast regex-based matching (~50ms latency) 3. **Implementation Approach**: **Incremental** - Extract one component at a time", "htmlHref": "/research/html/voice-ordering-pipeline-architecture-1hvfkmr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 5255 }, { "id": "dlm-integration-pipeline-ircp-rcp-and-tpo-1ie32x3", "title": "DLM Integration Pipeline: IRCP, RCP, and TPO", "slug": "dlm-integration-pipeline-ircp-rcp-and-tpo", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/DLM_INTEGRATION_PIPELINE.md", "extension": "md", "score": 66, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "This document defines the complete pipeline for integrating **IRCP** (Inverse Ring Contextual Propagation), **RCP** (Ring Contextual Propagation), and **TPO** (Topological Preference Optimization) directly within the **DLM** (Divergent Language Matrix) framework.", "excerpt": "# DLM Integration Pipeline: IRCP, RCP, and TPO ## Comprehensive Architecture and Process Definition\n\n## Table of Contents 1. [Executive Summary](#executive-summary) 2. [Current State Analysis](#current-state-analysis) 3. [Architecture Overview](#architecture-overview) 4. [Detailed Pipeline Definition](#detailed-pipeline-definition) 5. [Component Responsibilities](#component-responsibilities) 6. [Data Flow Diagrams](#data-flow-diagrams) 7. [Integration Points](#integration-points) 8. [Implementation Roadmap](#implementation-roadmap)\n\nThis document defines the complete pipeline for integrating **IRCP** (Inverse Ring Contextual Propagation), **RCP** (Ring Contextual Propagation), and **TPO** (Topological Preference Optimization) directly within the **DLM** (Divergent Language Matrix) framework.\n\n### Key Principles: - **IRCP**: Inverse pattern learning (P(u|v)) - How individuals construct responses - **RCP**: Forward context propagation (dC/dt = A(C)C) - How context flows - **TPO**: Preference optimization (Q(P)) - Which paths are optimal - **DLM**: Unified coordinate system and embedding framework\n\n### Integration Goal: Create a unified system where DLM serves as the foundation, with IRCP, RCP, and TPO providing specialized capabilities for: 1. Coordinate calculation 2. Embedding generation 3. Similarity computation 4. Context propagation 5. Preference generation", "htmlHref": "/research/html/dlm-integration-pipeline-ircp-rcp-and-tpo-1ie32x3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3426 }, { "id": "graph-kernel-technical-architecture-17frs1k", "title": "Graph Kernel Technical Architecture", "slug": "graph-kernel-technical-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/GRAPH-KERNEL-ARCHITECTURE.md", "extension": "md", "score": 66, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**OpenClaw CompCore — cc-graph-kernel** **Version:** 1.0.0 · **Schema:** 1.0.0 **Date:** 2026-02-13 **Author:** Mohamed Diomande", "excerpt": "**OpenClaw CompCore — cc-graph-kernel** **Version:** 1.0.0 · **Schema:** 1.0.0 **Date:** 2026-02-13 **Author:** Mohamed Diomande\n\n1. [System Overview](#1-system-overview) 2. [Architecture Diagrams](#2-architecture-diagrams) 3. [API Reference](#3-api-reference) 4. [Data Model](#4-data-model) 5. [Core Engine](#5-core-engine) 6. [Security Model](#6-security-model) 7. [Atlas Subsystem](#7-atlas-subsystem) 8. [Deployment Guide](#8-deployment-guide) 9. [Configuration Reference](#9-configuration-reference) 10. [Operational Runbook](#10-operational-runbook)\n\nThe Graph Kernel is a deterministic context slicing engine for conversation DAGs. It answers one question:\n\nIt provides: - **Deterministic context slicing** — same anchor + same policy + same graph state → identical `slice_id` - **HMAC-signed admissibility tokens** — unforgeable proof that a context slice was authorized by the kernel - **Policy-governed expansion** — phase-weighted priority queues with configurable budgets - **Knowledge graph triple store** — subject–predicate–object triples with confidence and provenance\n\n| Component | Technology | Purpose | |-----------|-----------|---------| | Language | Rust 2021 edition | Performance, safety, single binary | | Web Framework | Axum 0.7 | Async HTTP with Tower middleware | | Async Runtime | Tokio 1.x | Multi-threaded async I/O | | Database Driver | sqlx 0.7 | Async PostgreSQL with compile-time query checking | | Hashing | xxhash-rust (xxh64) | Fast, deterministic fingerprinting | | Cryptography | hmac + sha2 | HMAC-SHA256 for admissibility tokens | | Serialization | serde + serde_json | JSON request/response handling | | Logging | tracing + tracing-subscriber | Structured JSON logging | | Caching | lru + parking_lot | Token verification cache | | UUID | uuid v1 (v4 generation) | Turn and entity identifiers |", "htmlHref": "/research/html/graph-kernel-technical-architecture-17frs1k.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3813 }, { "id": "nko-brain-scanner-unified-architecture-1cudrhs", "title": "NKo Brain Scanner — Unified Architecture", "slug": "nko-brain-scanner-unified-architecture", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/ARCHITECTURE.md", "extension": "md", "score": 66, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. **No thin wrappers.** `nko_core/__init__.py` handles all imports from `Desktop/NKo/` via `sys.path`. No separate `phonetics.py`, `transliterate.py`, `morphology.py` wrapper files. If `from nko_core import phonetics` works, no wrapper is needed. 2. **No premature release.** HuggingFace upload happens AFTER mode collapse is fixed and the model generates coherent N'Ko text. Not before. 3. **Architecture matches disk.** Every file listed below exists. Every number is current. If reality changes, this doc gets update", "excerpt": "1. **No thin wrappers.** `nko_core/__init__.py` handles all imports from `Desktop/NKo/` via `sys.path`. No separate `phonetics.py`, `transliterate.py`, `morphology.py` wrapper files. If `from nko_core import phonetics` works, no wrapper is needed. 2. **No premature release.** HuggingFace upload happens AFTER mode collapse is fixed and the model generates coherent N'Ko text. Not before. 3. **Architecture matches disk.** Every file listed below exists. Every number is current. If reality changes, this doc gets updated.\n\n> **Serving / on-device decision:** research runs on the **GPU/standard Whisper** feature > path (1500-frame, reproducible, where clean numbers are earned); on-device serving is the > **Apple Neural Engine + TurboQuant** stack (Phase 2). One hard rule — a head must be served > with the *same* feature extractor it was trained on (the GPU↔ANE 1500-vs-375-frame skew is > what produced all-blank output on the anchor). See > [`docs/adr/ADR-001-on-device-serving-and-quantization.md`](docs/adr/ADR-001-on-device-serving-and-quantization.md).\n\n| File | Purpose | |------|---------| | `asr/bambara_translator.py` | Tiered translation: greetings -> corpus -> dictionary -> NLLB -> Ollama | | `asr/postprocess.py` | N'Ko syllable FSM validation and CTC output cleanup | | `asr/train_whisper_lora.py` | Whisper LoRA fine-tuning with checkpoint/resume | | `asr/train_nllb_lora.py` | NLLB-200 LoRA fine-tuning for Bambara translation | | `asr/prepare_nllb_data.py` | Extract parallel pairs from 5 sources for NLLB training | | `asr/eval_whisper_lora.py` | WER/CER evaluation harness (base vs LoRA comparison) | | `asr/convert_lora_to_ggml.py` | LoRA -> merged -> GGML -> quantized -> iOS bundle pipeline | | `asr/bridge_to_nko.py` | Latin Bambara -> N'Ko script conversion | | `asr/audio_encoder.py` | Whisper encoder (frozen features, d=512) | | `asr/joint_embedding.py` | Shared embedding space (d=512) + contrastive/retrieval loss | | `asr/train_asr.py` | Multi-loss training loop (contrastive + retrieval) | | `asr/speaker_diarizer.py` | pyannote speaker clustering + VADOnly fallback | | `asr/scene_encoder.py` | SigLIP keyframe feature extraction (d=512) | | `asr/syllable_retriever.py` | Codebook retrieval + FSM assembly | | `asr/audio_pipeline.py` | YouTube -> audio extraction + VAD | | `demo/realtime_asr.py` | Live demo server (HTTPS, CTC decode, Whisper encoder) |\n\n### Completed - [x] T1: Brain scan activation profiling (72B on A100 + 8B on M4) - [x] T2: Three-stage training V1 (CPT + SFT + BPE, val loss 4.29) - [x] T3: Constrained decoding FSM (100% syllable validity) - [x] T4: BPE tokenizer (512 merges, 614 vocab) - [x] T5: Morpheme-aware BPE tokenizer (158 merges, 206 vocab) - [x] T6: Embedding extension pipeline (151,936 → 152,192 vocab) - [x] T7: V2 LoRA trai", "htmlHref": "/research/html/nko-brain-scanner-unified-architecture-1cudrhs.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2778 }, { "id": "the-architecture-of-gemini-live-voice-control-for-rekordbox-a-technical-essay-5c8cm9", "title": "The Architecture of Gemini Live Voice Control for Rekordbox: A Technical Essay", "slug": "the-architecture-of-gemini-live-voice-control-for-rekordbox-a-technical-essay", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/GEMINI_ARCHITECTURE_ESSAY.md", "extension": "md", "score": 66, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The Gemini Live voice control system for Rekordbox represents a sophisticated orchestration of modern machine learning services, real-time audio processing, and command dispatch mechanisms. At its highest level, this system transforms the ephemeral quality of human speech into precise digital instructions that control professional DJ software. The architecture embodies a philosophy of delegation, where each component performs a specialized role in service of a singular purpose: to translate the DJ's vocal intent in", "excerpt": "# The Architecture of Gemini Live Voice Control for Rekordbox: A Technical Essay\n\nThe Gemini Live voice control system for Rekordbox represents a sophisticated orchestration of modern machine learning services, real-time audio processing, and command dispatch mechanisms. At its highest level, this system transforms the ephemeral quality of human speech into precise digital instructions that control professional DJ software. The architecture embodies a philosophy of delegation, where each component performs a specialized role in service of a singular purpose: to translate the DJ's vocal intent into Rekordbox keyboard shortcuts with minimal latency and maximal accuracy.\n\nThe entry point for this entire system is a deceptively simple bash script named `START_REKORDBOX_VOICE_GEMINI.sh`. This launcher serves as the orchestrator's baton, setting the stage for what follows. When invoked, it first navigates to its own directory, ensuring all subsequent path resolutions remain consistent regardless of where the user initially called the script. This seemingly trivial detail prevents a common class of deployment failures where relative paths break depending on execution context.\n\nThe launcher's first substantive action involves verifying the presence of a `.env` file in the project root. This file serves as the system's credential repository, housing the `GEMINI_API_KEY` required to authenticate with Google's Gemini Live API and the `HF_TOKEN` necessary for accessing HuggingFace's embedding models. The decision to fail early if this file is absent reflects defensive programming: rather than allowing the system to proceed into a complex initialization sequence only to fail when credentials are actually needed, the launcher performs this preflight check immediately. The error message not only alerts the user to the missing file but provides explicit instructions on how to create it, reducing friction in the setup process.\n\nFollowing environment validation, the launcher enters Python discovery mode. It first checks for a virtual environment in the `venv` directory, activating it if present. This pattern reflects best practices in Python dependency management, where isolated environments prevent version conflicts between different projects. If no virtual environment exists, the script falls back to searching for `python3` in the system path. The dual-path approach accommodates both development setups where virtual environments are standard and production deployments where system Python might be acceptable. Only when both paths fail does the launcher admit defeat and exit with an error.", "htmlHref": "/research/html/the-architecture-of-gemini-live-voice-control-for-rekordbox-a-technical-essay-5c8cm9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3716 }, { "id": "unified-agent-os-architecture-document-lkdt8w", "title": "Unified Agent OS — Architecture Document", "slug": "unified-agent-os-architecture-document", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/dream-metamorphosis/unified-agent-os/ARCHITECTURE.md", "extension": "md", "score": 66, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The Unified Agent OS (UAOS) merges three autonomous systems — **Pulse** (development), **Heartbeat** (monitoring), and **Dream Weaver / Noosphere** (incubation) — into a single coherent platform. Today these systems share the filesystem implicitly and bridge state through ad-hoc scripts (`noosphere_bridge.py`, `cadence_bridge.py`). The UAOS replaces those stitches with a unified state bus, a single lifecycle model, and formalized handoff protocols.", "excerpt": "> **Dream Origin:** dream_202601291857_a242e7 > **Version:** 1.0 — Design Phase > **Date:** 2025-02-09\n\nThe Unified Agent OS (UAOS) merges three autonomous systems — **Pulse** (development), **Heartbeat** (monitoring), and **Dream Weaver / Noosphere** (incubation) — into a single coherent platform. Today these systems share the filesystem implicitly and bridge state through ad-hoc scripts (`noosphere_bridge.py`, `cadence_bridge.py`). The UAOS replaces those stitches with a unified state bus, a single lifecycle model, and formalized handoff protocols.\n\n1. **Preserve what works** — Every current Pulse session, Dream Weaver incubation, and Heartbeat check must continue to function unchanged. Migration is additive, not reductive. 2. **Shared state, separate concerns** — Each subsystem keeps its domain logic but reads/writes to a common state layer. 3. **Events over polling** — Move from file-watching and cron loops to an event bus that subsystems publish to and subscribe from. 4. **Extensibility for Cadence** — The multi-agent coordination system (higher-level / lower-level agents, INBOX/OUTBOX protocols) becomes a first-class orchestration layer.\n\n| Component | Role | |-----------|------| | `dual_runner.py` | Rate-aware session executor across two Claude Max accounts | | `enriched_spawn.py` | Context-enriched prompt builder for sub-agent iterations | | `server.ts` (MCP) | MCP server exposing `pulse_start`, `pulse_status`, `pulse_iterate`, etc. | | `sessions/*.json` | Per-session state files (id, project, iteration count, status, goal) |\n\n**State Model:** JSON files in `[home-path]`, one per session. Status enum: `running | paused | complete | blocked | failed | aborted`.", "htmlHref": "/research/html/unified-agent-os-architecture-document-lkdt8w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3031 }, { "id": "cognitivehire-creative-architecture-ikgmmp", "title": "CognitiveHire: Creative Architecture", "slug": "cognitivehire-creative-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "cognitive-hire/docs/creative-architecture.md", "extension": "md", "score": 64, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "CognitiveHire sits at the collision point of five distinct forces. None of them are new. The combination is unprecedented.", "excerpt": "> Output of the Creative Forge (6-phase meta-creative pipeline) > Generated: 2026-03-27\n\nCognitiveHire sits at the collision point of five distinct forces. None of them are new. The combination is unprecedented.\n\nEvery prompt someone writes is an act of cognition made legible. When a person asks Claude to debug a race condition, they reveal: how they decompose problems, what abstractions they reach for, when they give up and try a different angle, how they respond to failure, whether they read the error message or panic-prompt. Multiply this across thousands of interactions and you have something that has never existed before in human history: a high-resolution, longitudinal record of how a person thinks, not what they know.\n\nTraditional resumes capture credentials. Interviews capture performance anxiety. AI interaction logs capture *the shape of thought under real conditions*.\n\nRaw interaction logs are noise. The extraction layer applies cognitive science to find signal: working memory patterns (how many variables does someone juggle before offloading to the AI?), metacognitive calibration (do they know what they don't know?), transfer learning (do they apply solutions from one domain to another?), cognitive flexibility (how fast do they pivot when an approach fails?), depth-vs-breadth orientation (do they drill or scan?).", "htmlHref": "/research/html/cognitivehire-creative-architecture-ikgmmp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 7081 }, { "id": "nko-monograph-5i7ion", "title": "nko monograph", "slug": "nko-monograph", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/nko_monograph.tex", "extension": "tex", "score": 64, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "% --- Hyperlinks --- \\usepackage[colorlinks=true,linkcolor=blue!60!black,citecolor=blue!60!black,urlcolor=blue!60!black]{hyperref}", "excerpt": "% =================================================================== % TITLE PAGE % =================================================================== \\begin{center} {\\LARGE\\bfseries From Dead Circuits to Living Speech:\\\\[0.3em] Activation Profiling, Script-Native Architecture Search,\\\\[0.3em] and Finite-State Phonotactics for \\nko{} Automatic Speech Recognition}\n\n{\\large Mohamed Diomande}\\\\[0.3em] {\\normalsize Independent Researcher}\\\\[0.2em] {\\normalsize\\texttt{[email]}}\n\n% =================================================================== % ABSTRACT % =================================================================== \\begin{quote} \\noindent\\textbf{Abstract.}\\quad \\nko{} is an alphabetic script serving over forty million Manding-language speakers across West Africa, engineered by Solomana Kant\\'e in 1949 with a strict one-to-one phoneme-to-character mapping, explicit tonal diacritics, and zero spelling exceptions. We present a dual-thread investigation into why large language models fail on \\nko{} and how to construct audio-to-\\nko{} speech recognition that bypasses such models entirely. In the diagnostic thread, we perform activation profiling of Qwen2-72B-Instruct (4-bit NF4, A100 80\\,GB) processing one hundred parallel English/\\nko{} sentence pairs across all eighty-one transformer layers, revealing a $2.90\\times$ translation tax measured by L2 norm ratio, thirty to sixty percent entropy inflation, an 85.8\\% kurtosis deficit at the output layer, and 150\\% higher sparsity at embedding. Circuit duplication analysis spanning fifty-five configurations under the Revisit Your Shoulders methodology shows zero \\nko{}-advantageous configurations; the best \\nko{} score of 0.067 barely exceeds the random baseline of 0.05. Three-stage LoRA fine-tuning comprising 17,360 continued pre-training examples, 21,240 supervised fine-tuning pairs, and 25,100 BPE-aware training instances reduces the translation tax to $0.70\\times$, constituting a seventy-six percent reduction. In the constructive thread, we build the first audio-to-\\nko{} automatic speech recognition system. A frozen Whisper large-v3 encoder feeds a character-level CTC decoder, and a twenty-eight-rule architecture search over BiLSTM and Transformer variants converges on a 46.9\\,M-parameter Transformer with four-fold temporal downsampling, achieving 33\\% character error rate and 70\\% word error rate on thirty-seven hours of Bambara speech from the bam-asr-early corpus (CC-BY-4.0). A four-state finite-state machine encoding \\nko{} syllable phonotactics guarantees one hundred percent structural validity at negligible runtime cost. Total compute expenditure for both research threads is fourteen United States dollars. \\end{quote}\n\n% =================================================================== % ", "htmlHref": "/research/html/nko-monograph-5i7ion.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 11777 }, { "id": "overview-3h2alt", "title": "Overview", "slug": "overview", "kind": "working paper", "program": "Language as Infrastructure", "sourceAnchor": "projects/LearnNKo/ml/docs/technical/Overview.md", "extension": "md", "score": 64, "readiness": "preprint structure candidate", "nextAction": "Convert into the standard paper schema, add citations, and render a draft PDF.", "summary": "Perfect — here’s a rewritten abstract and overview with the modular breakdown and explicit mention of bidirectional translations across English, French, N’ko, and Bambara.", "excerpt": "Perfect — here’s a rewritten abstract and overview with the modular breakdown and explicit mention of bidirectional translations across English, French, N’ko, and Bambara.\n\nThis project develops a modular multilingual system for translation and speech processing in low-resource West African languages, focusing on N’ko and Bambara, while bridging them with French and English. Using RobotsMali/bam-asr-early as the foundational ASR dataset, the system integrates speech recognition (ASR), translation, and speech synthesis (TTS) within a unified pipeline. Built on self-supervised speech models (wav2vec 2.0) and multilingual transformers (mBART, mT5, or LLaMA derivatives), it supports bidirectional translation across all language pairs: English ↔ French, English ↔ N’ko, English ↔ Bambara, French ↔ N’ko, and French ↔ Bambara. The framework is designed to handle script-aware tokenization for N’ko, grammar-sensitive fine-tuning, and mixture-of-experts routing for language-specific adaptation. Beyond immediate performance, the system is structured for iterative learning, improving over time as new community-driven data is added. The outcome is a scalable, accessible platform that strengthens literacy, education, and cultural preservation in West Africa while advancing research in multilingual low-resource NLP.\n\nWest African languages such as N’ko and Bambara face limited digital resources and weak representation in NLP systems. Key challenges include: • Scarcity of annotated data, especially parallel corpora. • Lack of robust ASR datasets outside RobotsMali. • Unique script handling for N’ko (Unicode segmentation, grammar). • Cross-lingual gaps, especially for English ↔ Bambara and French ↔ N’ko translation.\n\n2. Objectives • Build a modular pipeline combining ASR, translation, and TTS. • Support bidirectional translation across English, French, N’ko, and Bambara. • Enable both text-based and speech-based interaction. • Ensure N’ko script fidelity through custom tokenization. • Scale iteratively, improving as more data is added.\n\n3. Core Dataset: RobotsMali/bam-asr-early • Total Duration: 37.41 hours • Samples: 38,769 (Train: 37,306 | Test: 1,463) • Subsets: • Oza’s Bambara-ASR: ~29 hours • Jeli-ASR-RMAI: ~3.5 hours • oza-tts-mali-pense: ~4 hours • Reading-tutor-data: ~1 hour", "htmlHref": "/research/html/overview-3h2alt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 588 }, { "id": "hub-2-threaded-messaging-architecture-xcb6e6", "title": "HUB-2: Threaded Messaging Architecture", "slug": "hub-2-threaded-messaging-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "AgentCommandCenter/HUB-THREAD-ARCHITECTURE.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Replace Discord's channel model with a threaded architecture tailored to OpenClaw: - **Threaded, not channel-based** — every conversation is a thread with a parent category - **Quad-inspired layout** — 4 concurrent contexts visible (like the terminal quad) - **Feed integration** — 33 Prefect flows post directly to threads (no Discord webhooks) - **Agent-native** — threads can be owned by agents, not just humans - **Voice-first** — every thread supports voice input/output - **Offline-capable** — SwiftData persistenc", "excerpt": "**Date**: 2026-03-01 **Status**: Design Complete — Ready for HUB-3 Implementation\n\nReplace Discord's channel model with a threaded architecture tailored to OpenClaw: - **Threaded, not channel-based** — every conversation is a thread with a parent category - **Quad-inspired layout** — 4 concurrent contexts visible (like the terminal quad) - **Feed integration** — 33 Prefect flows post directly to threads (no Discord webhooks) - **Agent-native** — threads can be owned by agents, not just humans - **Voice-first** — every thread supports voice input/output - **Offline-capable** — SwiftData persistence with Supabase Realtime sync\n\n### 2.1 Conversation Threads (interactive) Human ↔ Agent bidirectional conversations. Created when user starts a chat or dispatches a task.\n\n**Properties**: owner (human), agent (assigned), model (claude/gemini/ollama), session_key, gateway connection, conversation history (10-turn), context hints from Kimi.\n\n### 2.2 Feed Threads (read-only, system-generated) Automated posts from Prefect flows. Replace Discord webhook channels.", "htmlHref": "/research/html/hub-2-threaded-messaging-architecture-xcb6e6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2029 }, { "id": "dj-voice-control-retrieval-centric-architecture-1vuppv4", "title": "DJ Voice Control: Retrieval-Centric Architecture", "slug": "dj-voice-control-retrieval-centric-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/voice_control/retrieval_architecture.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The DJ Voice Control system adapts the speech-to-order retrieval-centric paradigm for real-time DJ performance control. Instead of matching spoken orders to menu items, we match spoken commands to DJ actions and keyboard shortcuts. This approach provides superior accuracy compared to traditional ASR + NLU pipelines by learning a direct semantic mapping between audio utterances and command intents.", "excerpt": "The DJ Voice Control system adapts the speech-to-order retrieval-centric paradigm for real-time DJ performance control. Instead of matching spoken orders to menu items, we match spoken commands to DJ actions and keyboard shortcuts. This approach provides superior accuracy compared to traditional ASR + NLU pipelines by learning a direct semantic mapping between audio utterances and command intents.\n\n**Key Advantages:** - **Sub-second latency**: Direct audio → command matching without transcription - **Robust to variations**: Handles different phrasings, accents, and noise - **No cloud dependency**: Runs entirely locally for zero latency - **Deterministic execution**: Constraint solver ensures valid command combinations - **Continuous improvement**: Easy to add new commands and voice samples\n\n**Corpus Statistics:** - ~200 base commands (from your existing command_map) - ~5 variations per command - ~1,000 total documents in retrieval corpus - Flat index sufficient (sub-1ms search)\n\n**Key Differences from Café:** - **Noise profile**: Music playback, crowd noise, speaker feedback - **Speaking style**: Louder, more forceful commands - **Latency requirement**: Even tighter (<800ms total) - **Hands-free**: Can't press PTT during performance\n\n**Initial Dataset (Your Voice):** 1. **Record command corpus**: - Read each command 3 times (clean) - Record in booth environment (with music) - ~200 commands × 3 reps × 2 conditions = **1,200 samples**", "htmlHref": "/research/html/dj-voice-control-retrieval-centric-architecture-1vuppv4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2477 }, { "id": "data-models-1kq8113", "title": "Data Models", "slug": "data-models", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/architecture/data-models.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "```prisma model User { id String @id @default(uuid()) email String @unique name String? createdAt DateTime @default(now()) updatedAt DateTime @updatedAt", "excerpt": "TrajectoryOS uses **Prisma ORM** with PostgreSQL (production) or SQLite (development).\n\n**Key Fields**: - `email` - Authentication identifier (unique) - `name` - Display name\n\n**Relations**: - One user → many life states (time series) - One user → many projects - One user → many skill evidence entries - One user → many interview sessions\n\n**Key Fields**: - `latentVector` - High-dimensional representation (z_t) stored as JSON array - `thrust`, `alignment`, `gravity`, `mass` - Derived physics variables - `escapeIndex` - The critical η metric - `timestamp` - When this state was computed\n\n**Key Fields**: - `name` - Skill name (e.g., \"Python\", \"Choreography\") - `domain` - Category (e.g., \"Programming\", \"Creative\")", "htmlHref": "/research/html/data-models-1kq8113.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1511 }, { "id": "motion-accountability-platform-architecture-f03aml", "title": "Motion Accountability Platform — Architecture", "slug": "motion-accountability-platform-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/MOTION_ACCOUNTABILITY_ARCHITECTURE.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` Tier 3: Commitment Protocol (Swift + Supabase) ├── Declare intentions, verify against observed motion ├── Social feed: commitments met or visibly not └── Notification loop: 30-min push-up reminder → detection → confirmation", "excerpt": "### Vision Always-on observation layer on top of MotionMix's existing pose/avatar pipeline. Not a fitness app feature, but a platform primitive that uses continuous motion capture to detect exercise reps, classify sleep/wake state, and verify public commitments.\n\n### Philosophy \"Not direct features per se, but building on known observations that we want to highlight or improve or disincentivize.\" The system watches, classifies, and surfaces, rather than prescribing.\n\nThe claim_bridge.rs already detects: - **Echo** (periodicity > 0.8): rhythmic repetitive motion = exercise - **Oscillation** (6+ curvature sign changes): bouncing/reps - **Dwell** (speed < 0.02 for 10 frames): pause between sets - **Transition** (jerk spike > 2sigma): rep boundary\n\nEvents that trigger clip capture (via existing SANTrajectoryLogger): 1. Rep completion → 3-second clip centered on rep 2. Exercise bout complete → summary clip (first + last rep) 3. Wake-up event (Sleeping → AwakeActive transition) 4. Commitment verification moment\n\n| System | How It Connects | |--------|----------------| | Avatar Pipeline | Provides 27-bone positions at 30Hz via `avatar_get_bone_positions` | | SAN Claims | Bout segmentation uses Echo + Oscillation + Dwell signals | | PoseMetrics | Body energy, bounce, hip Y already computed | | Auto-Capture | Exercise bout/rep/wake events trigger clip recording | | Notifications | iOS local notifications for interval reminders | | Supabase | Commitments, sessions, sleep events persisted | | Feed | Commitment verification results posted to social feed |", "htmlHref": "/research/html/motion-accountability-platform-architecture-f03aml.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1558 }, { "id": "unified-rag-architecture-knpgau", "title": "Unified RAG++ Architecture", "slug": "unified-rag-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/docs/UNIFIED_RAG_ARCHITECTURE.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. [System Overview](#1-system-overview) 2. [Layer Architecture](#2-layer-architecture) 3. [Foundation Layer: Rust Core](#3-foundation-layer-rust-core) 4. [Data Layer: Supabase Schema](#4-data-layer-supabase-schema) 5. [Ingestion Layer: Prompt Pipeline](#5-ingestion-layer-prompt-pipeline) 6. [ML Layer: CognitiveTwin](#6-ml-layer-cognitivetwin) 7. [Orchestration Layer: Orbit](#7-orchestration-layer-orbit) 8. [Integration Layer: Prompt Logger](#8-integration-layer-prompt-logger) 9. [API Layer: Endpoints Reference](#9", "excerpt": "1. [System Overview](#1-system-overview) 2. [Layer Architecture](#2-layer-architecture) 3. [Foundation Layer: Rust Core](#3-foundation-layer-rust-core) 4. [Data Layer: Supabase Schema](#4-data-layer-supabase-schema) 5. [Ingestion Layer: Prompt Pipeline](#5-ingestion-layer-prompt-pipeline) 6. [ML Layer: CognitiveTwin](#6-ml-layer-cognitivetwin) 7. [Orchestration Layer: Orbit](#7-orchestration-layer-orbit) 8. [Integration Layer: Prompt Logger](#8-integration-layer-prompt-logger) 9. [API Layer: Endpoints Reference](#9-api-layer-endpoints-reference) 10. [Data Flow Diagrams](#10-data-flow-diagrams) 11. [Configuration Reference](#11-configuration-reference) 12. [Component Interfaces](#12-component-interfaces)\n\n- Captures every AI interaction (Claude, ChatGPT, Cursor) as unified `memory_turns` - Computes trajectory coordinates using the Rust core (HNSWIndex + IRCPPropagator) - Trains a CognitiveTwin to learn user reasoning patterns and style - Enables trajectory-aware retrieval for contextual generation\n\n| Principle | Implementation | |-----------|----------------| | **Unified Data** | All prompts become `memory_turns` - single source of truth | | **Rust Performance** | Trajectory computation via PyO3 bindings | | **Orbit Orchestration** | Full control over training, context, and fabric operations | | **Global Style** | One evolving signature across all projects |\n\n| Layer | Components | Responsibility | |-------|------------|----------------| | **L0: Foundation** | Rust Core, PyO3 Bindings | High-performance vector ops, trajectory computation | | **L1: Data** | Supabase, PostgreSQL, pgvector | Persistent storage, vector search | | **L2: Ingestion** | PromptIngester, Embedder | Transform prompts → memory_turns | | **L3: ML** | CognitiveTwin, HybridTrainer | Learn user patterns, style extraction | | **L4: Orchestration** | Orbit Server | Project management, training triggers | | **L5: Integration** | Prompt Logger, MCP Server | Capture from AI tools, expose to agents |\n\n- **HNSWIndex**: Hierarchical Navigable Small World graph for approximate nearest neighbor search - **IRCPPropagator**: Inverse Reasoning Coordinate Propagator for attention computation - **TrajectoryCoordinate5D**: 5-dimensional coordinate system for conversation topology", "htmlHref": "/research/html/unified-rag-architecture-knpgau.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4503 }, { "id": "graph-kernel-msjsyb", "title": "Graph Kernel", "slug": "graph-kernel", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/architecture/15-GRAPH_KERNEL.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Version**: 1.1.0 **Last Updated**: 2026-01-03 **Status**: Production **Parent**: [02-TRAJECTORY_OS.md](02-TRAJECTORY_OS.md) **Related**: [08-RAG_PLUS_PLUS.md](08-RAG_PLUS_PLUS.md), [09-ORBIT.md](09-ORBIT.md), [17-AGENT_SDK.md](17-AGENT_SDK.md) **Crate (Rust)**: `core/cc-graph-kernel/` **Service**: Cloud Run `graph-kernel` **Tests**: 140+ passing **Schema Version**: 1.0.0", "excerpt": "**Version**: 1.1.0 **Last Updated**: 2026-01-03 **Status**: Production **Parent**: [02-TRAJECTORY_OS.md](02-TRAJECTORY_OS.md) **Related**: [08-RAG_PLUS_PLUS.md](08-RAG_PLUS_PLUS.md), [09-ORBIT.md](09-ORBIT.md), [17-AGENT_SDK.md](17-AGENT_SDK.md) **Crate (Rust)**: `core/cc-graph-kernel/` **Service**: Cloud Run `graph-kernel` **Tests**: 140+ passing **Schema Version**: 1.0.0\n\nThe **Graph Kernel** is the central authority for determining what context is admissible during retrieval and response generation. It answers the fundamental question:\n\nUnlike traditional RAG systems that rely on similarity thresholds, the Graph Kernel provides:\n\n1. **Deterministic Slicing**: Same anchor + policy + graph state → identical slice 2. **Unforgeable Admissibility**: HMAC-signed tokens prove kernel authorization 3. **Cryptographic Provenance**: Every slice carries complete audit trail 4. **Policy-Driven Expansion**: Configurable, versioned expansion rules\n\n| ID | Invariant | Description | |----|-----------|-------------| | **INV-GK-001** | Slice Boundary | Any turn in slice-mode must satisfy `turn_id ∈ slice.turn_ids` | | **INV-GK-002** | Provenance Completeness | Every response includes `(slice_id, policy_ref, schema_version, graph_snapshot_hash, admissibility_token)` | | **INV-GK-003** | No Phantom Authority | Missing `admissibility_token` means non-admissible by definition |", "htmlHref": "/research/html/graph-kernel-msjsyb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3218 }, { "id": "cognitive-twin-architecture-v2-decoupled-rlm-qwen-3-5-migration-19khz0g", "title": "Cognitive Twin Architecture V2 — Decoupled RLM + Qwen 3.5 Migration", "slug": "cognitive-twin-architecture-v2-decoupled-rlm-qwen-3-5-migration", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/docs/ARCHITECTURE-V2.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The Cognitive Twin is Mo's personal AI delegate — a model that knows his projects, preferences, reasoning patterns, and history. V1 used Llama 3.2:3B locally with a tightly-coupled RAG+Graph+RLM stack. V2 decouples every layer, swaps the base model to Qwen 3.5, and creates a clean evaluation pipeline.", "excerpt": "The Cognitive Twin is Mo's personal AI delegate — a model that knows his projects, preferences, reasoning patterns, and history. V1 used Llama 3.2:3B locally with a tightly-coupled RAG+Graph+RLM stack. V2 decouples every layer, swaps the base model to Qwen 3.5, and creates a clean evaluation pipeline.\n\n| Config | Score | What it proves | |--------|-------|---------------| | A: Bare Qwen3-Next-80B | 29.5% | API model has zero personal knowledge | | B: + RAG | 87.2% | Semantic retrieval is the biggest lever | | C: + Graph | 89.7% | Graph traversal adds marginal lift | | D: + RLM | 93.6% | RLM decomposition helps multi-hop queries |\n\n### Layer 0: Base Model **Current:** Qwen3-Next-80B-A3B (Together AI, serverless, $0) **Target:** Qwen3.5-35B-A3B (local on Mac4+Mac5 exo cluster OR API)\n\n**Model Options (tested/available):** | Model | Where | Active Params | Score (Config A) | Cost | |-------|-------|---------------|------------------|------| | Llama 3.2:3B | Mac4 Ollama | 3B | ~25% | $0 | | Qwen3-Next-80B-A3B | Together API | 3B | 29.5% | $0 | | Qwen3.5-35B-A3B | OpenRouter | 3B | TBD | $0.16/M | | Qwen3.5-35B-A3B | Mac4+Mac5 exo | 3B | TBD | $0 | | Qwen3.5-397B-A17B | Together API | 17B | TBD | $0.60/M |\n\n**Migration path:** Start with API for evaluation speed, migrate to local exo cluster for $0 inference at scale.", "htmlHref": "/research/html/cognitive-twin-architecture-v2-decoupled-rlm-qwen-3-5-migration-19khz0g.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1784 }, { "id": "dep-pipeline-protocol-architecture-audit-sfkixn", "title": "DEP — Pipeline Protocol Architecture Audit", "slug": "dep-pipeline-protocol-architecture-audit", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Milk Men/DEP-PIPELINE-PROTOCOL-20260223.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The Pipeline Protocol is a 3-table Supabase schema (`pipeline_definitions`, `pipeline_runs`, `pipeline_step_logs`) with 2 VIEWs, 1 trigger, and a shared TypeScript module consumed by 3 edge functions. It bridges to Nexus observability via a Prometheus exporter, Grafana dashboard, Prefect watcher, and a Next.js portal page.", "excerpt": "# DEP — Pipeline Protocol Architecture Audit **Date:** 2026-02-23 **Scope:** Full architecture review — security, schema, code quality, dependencies, observability bridge **Systems:** Supabase Edge Functions, Pipeline Protocol DB, Nexus Portal, Nexus Exporter, Prefect Watcher, Grafana, Alert Rules\n\nThe Pipeline Protocol is a 3-table Supabase schema (`pipeline_definitions`, `pipeline_runs`, `pipeline_step_logs`) with 2 VIEWs, 1 trigger, and a shared TypeScript module consumed by 3 edge functions. It bridges to Nexus observability via a Prometheus exporter, Grafana dashboard, Prefect watcher, and a Next.js portal page.\n\nThe system works end-to-end (verified: run created, step logged, run completed, metrics collected). However, the audit uncovered **3 critical**, **10 high**, **7 medium**, and **6 low** severity findings across security, schema integrity, code quality, and dependency management.\n\nThe most urgent issues are: 1. Hardcoded Supabase keys in committed source (nexus-portal) 2. `db-migrate-temp` edge function still deployed (arbitrary DDL execution) 3. Pipeline core tables have no migration files (schema drift) 4. `ensureRun` race condition under concurrent dispatch 5. Column name drift between migrations and edge functions (`sweep_id` vs `campaign_id`, `base_quantity` vs `boxes_per_delivery`)\n\n| # | Finding | Location | Risk | |---|---------|----------|------| | S1 | **Hardcoded Supabase anon JWT + project ref** in client-side source. 9-year expiry token committed to git. | `nexus-portal/src/lib/api.ts:87-89` | Key extraction from browser bundle grants read access to all pipeline data | | S2 | **`toggle_pipeline_run_pause` RPC has no auth guard.** SECURITY DEFINER function callable by anon role — anyone with the leaked key can pause/unpause any pipeline run. | RPC function (applied via temp edge fn) | State manipulation by unauthenticated callers | | S3 | **Pipeline tables may lack RLS policies.** Tables created via Management API, not tracked in migrations. Comment says \"SELECT RLS for anon\" but no migration confirms this. If RLS is not enabled, anon key grants full table access. | `pipeline_runs`, `pipeline_step_logs`, `pipeline_definitions` | Full data exposure via REST API |", "htmlHref": "/research/html/dep-pipeline-protocol-architecture-audit-sfkixn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3455 }, { "id": "server-architecture-integration-aura-on542r", "title": "Server Architecture Integration — Aura", "slug": "server-architecture-integration-aura", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "OpenClawHub/SERVER-ARCHITECTURE-DESIGN.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Aura currently has a flat thread model: `HubThread` objects live in `hub_threads`, categorized by `ThreadCategory` and `ThreadType`, with no parent container. The Discord ecosystem, however, operates on three distinct architectural patterns — each representing an evolution in how the Clawdbot gateway handles task dispatch and message delivery. This document describes those three patterns in abstract form and specifies how they integrate into Aura as a **secluded feature** that does not interfere with the existing t", "excerpt": "Aura currently has a flat thread model: `HubThread` objects live in `hub_threads`, categorized by `ThreadCategory` and `ThreadType`, with no parent container. The Discord ecosystem, however, operates on three distinct architectural patterns — each representing an evolution in how the Clawdbot gateway handles task dispatch and message delivery. This document describes those three patterns in abstract form and specifies how they integrate into Aura as a **secluded feature** that does not interfere with the existing thread hierarchy.\n\n**Abstract model:** A stateless request-response loop. The client sends a named command with arguments. The server executes a direct database query, formats the result, and returns it immediately. No task queue, no progress streaming, no persistent connection.\n\n**Characteristics:** - Commands are a fixed set: each maps to exactly one query/action - No model routing — the server IS the executor - No progress updates — result arrives in one shot - Stateless — each command is independent, no session continuity - Response format: plain text, chunked if exceeding size limits\n\n**Data requirements:** - Command registry (name → handler function) - Direct database access (reads from domain-specific tables) - No task table, no thread table, no message history\n\n**When to use:** Domain-specific dashboards where you need instant answers from structured data. Sales pipeline queries, inventory lookups, metric summaries.", "htmlHref": "/research/html/server-architecture-integration-aura-on542r.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4285 }, { "id": "computational-choreography-complete-system-architecture-179g4v", "title": "Computational Choreography - Complete System Architecture", "slug": "computational-choreography-complete-system-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/_archive/2024-12/superseded-guides/ARCHITECTURE_COMPLETE.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The Computational Choreography (CC) system transforms raw motion sensor data into musically-coherent audio control signals. The architecture follows a strict **bottom-up dependency graph** where lower layers know nothing about higher layers.", "excerpt": "## Table of Contents 1. [Executive Overview](#1-executive-overview) 2. [System Stack Diagram](#2-system-stack-diagram) 3. [Crate Hierarchy](#3-crate-hierarchy) 4. [Layer-by-Layer Breakdown](#4-layer-by-layer-breakdown) 5. [Data Flow Pipeline](#5-data-flow-pipeline) 6. [Module Reference](#6-module-reference) 7. [Type System](#7-type-system) 8. [Frozen Contracts](#8-frozen-contracts) 9. [CC-Echelon Workspace Deep Dive](#9-cc-echelon-workspace-deep-dive) (18 crates, ~50,000 lines) 10. [CC-RAG-Plus-Plus Deep Dive](#10-cc-rag-plus-plus-deep-dive) (51 files, 24,879 lines) 11. [Python Layer Architecture](#11-python-layer-architecture) (~60,000 lines) 12. [Complete Data Flow Pipeline](#12-complete-data-flow-pipeline) 13. [FROZEN Contracts & Schema Versions](#13-frozen-contracts--schema-versions) 14. [Complete Crate Reference Table](#14-complete-crate-reference-table) 15. [Glossary of Key Terms](#15-glossary-of-key-terms)\n\nThe Computational Choreography (CC) system transforms raw motion sensor data into musically-coherent audio control signals. The architecture follows a strict **bottom-up dependency graph** where lower layers know nothing about higher layers.\n\n| Metric | Value | |--------|-------| | **Total Rust Crates** | 32 (13 top-level + 18 cc-echelon + 1 workspace) | | **Python Packages** | 2 (cc-ml, cc-core) | | **Total Rust Source Lines** | ~185,000 | | **Total Python Source Lines** | ~60,000 | | **cc-rag-plus-plus** | 24,879 lines (51 files) | | **cc-echelon workspace** | ~50,000 lines (18 sub-crates) | | **cc-window-aligner** | ~22,000 lines | | **cc-ml Python** | ~33,000 lines | | **cc-core Python** | ~27,000 lines | | **Test Coverage** | 400+ tests | | **FROZEN Contracts** | 5 (v1.0.0) | | **CC-Echelon Sub-crates** | 18 | | **ML Model Families** | 11 |\n\n| File | Lines | Purpose | |------|-------|---------| | `lib.rs` | 692 | LatentVector, Quaternion, Vec3, numeric utilities |\n\n| File | Lines | Purpose | |------|-------|---------| | `lib.rs` | 270 | Confidence, ValidityHorizon, SemanticValue, UnavailableReason | | `frame.rs` | 400 | SemanticFrame v1, SemanticFrameBuilder, SemanticProvenance | | `phase.rs` | 290 | CyclicCoordinate, PhaseState, PhaseType | | `momentum.rs` | 300 | HeadingVector, MomentumState, ImpulseIndicator | | `tension.rs` | 293 | TensionState, TensionTrend, TensionProxies | | `intent.rs` | 200 | IntentState, IntentAvailability | | `stability.rs` | 396 | StabilityState, StabilityFlags, HealthMetrics | | `regime.rs` | 335 | RegimeType, RegimeDescriptor, RegimeEvidence |", "htmlHref": "/research/html/computational-choreography-complete-system-architecture-179g4v.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 19829 }, { "id": "tier-3-medium-term-architectural-enhancements-implementation-plan-glu5a1", "title": "Tier 3: Medium-Term Architectural Enhancements - Implementation Plan", "slug": "tier-3-medium-term-architectural-enhancements-implementation-plan", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/TIER3_ARCHITECTURE_PLAN.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Tier 3 introduces **5 advanced architectural features** that significantly enhance the voice control system's robustness, intelligence, and user experience.", "excerpt": "Tier 3 introduces **5 advanced architectural features** that significantly enhance the voice control system's robustness, intelligence, and user experience.\n\n**Goal:** Create a production-grade, intelligent voice control system that works offline, supports multiple languages, learns from usage, and anticipates user needs.\n\n### Objective Automatically switch to local Whisper model when Gemini API is unavailable (network issues, API outage, rate limits).\n\n1. **WhisperFallbackEngine** (new class) - Uses `openai-whisper` library - Model: `tiny.en` or `base.en` for speed - Real-time audio buffering (1-2 second chunks) - VAD (Voice Activity Detection) for efficiency\n\n2. **HealthMonitor** (new class) - Pings Gemini API every 30s - Tracks consecutive failures - Triggers auto-switch after 2 failures", "htmlHref": "/research/html/tier-3-medium-term-architectural-enhancements-implementation-plan-glu5a1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1861 }, { "id": "inscription-architecture-map-j0qey5", "title": "Inscription Architecture Map", "slug": "inscription-architecture-map", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/karl/inscription-architecture-map.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "This document maps every file, specification, and implementation related to the N'Ko inscription system, sigils, tokenization, the EPOCH protocol, Stacks/Clarity contracts, PsiChain, the cognitive twin, and anticipation geometry. It traces how they interconnect to form a single pipeline that encodes a life's computational dynamics as hash-chained N'Ko inscriptions settled on Bitcoin.", "excerpt": "This document maps every file, specification, and implementation related to the N'Ko inscription system, sigils, tokenization, the EPOCH protocol, Stacks/Clarity contracts, PsiChain, the cognitive twin, and anticipation geometry. It traces how they interconnect to form a single pipeline that encodes a life's computational dynamics as hash-chained N'Ko inscriptions settled on Bitcoin.\n\n**Location:** `Desktop/Comp-Core/core/semantic/cc-inscription/` **Lines:** 22,881 Rust across 48 source files **Status:** BUILT, compiles, deployed as part of cc-mcs-daemon\n\n#### Supporting files: - `lexicons/v1.0.json` -- Initial lexicon - `docs/00-PROJECT_CHARTER.md` -- Project purpose - `docs/01-GLOSSARY.md` -- Term definitions - `docs/02-INVARIANTS_LEDGER.md` -- System invariants - `docs/03-IMPLEMENTATION_GUIDE.md` -- Build guide - `docs/DESIGN.md` -- Complete design document\n\n| # | Sigil | Unicode | Name | z-Trajectory Trigger | N'Ko Form | |---|-------|---------|------|---------------------|-----------| | 0 | STABILIZATION | U+07DB | Dispersion decreased | `z(sigma) down ; [place] ; c=[conf]` | | 1 | DISPERSION | U+07DC | Spread/entropy increased | `z(sigma) up ; [place] ; c=[conf]` | | 2 | TRANSITION | U+07D5 | Curvature spike (change point) | `[B_from] -> [B_to] ; kappa=[sharp] ; c=[conf]` | | 3 | RETURN | U+07D9 | Re-entry to known basin | `loopback [B] ; last=[dt] ; d=[dist]` | | 4 | DWELL | U+07E1 | Sustained stay in basin | `stay([B])=[tau] ; phi=[stab]` | | 5 | OSCILLATION | U+07DA | Rapid alternation between basins | `[B1] bidirectional [B2] ; f=[freq] ; a=[amp]` | | 6 | RECOVERY | U+07DE | Return latency after disruption | `rec->[B] ; tau=[lat] (x[ratio])` | | 7 | NOVELTY | U+07E3 | New basin discovery | `new[P] ; d*=[dist] ; k=[support]` | | 8 | PLACE-SHIFT | U+07E0 | Location class change | `[P_from] -> [P_to] ; hookright [claim_sigil] ; c=[conf]` | | 9 | ECHO | U+07E5 | Pattern match to prior episode | `approx [E#] ; sim=[s] ; refs=[n]` |\n\n**File:** `Desktop/Comp-Core/docs/nko-ecosystem/SIGIL_SEMANTICS.md` -- Full 234-line document mapping each sigil to visual representation, semantic meaning, UI affordance, motion signature, and N'Ko form.", "htmlHref": "/research/html/inscription-architecture-map-j0qey5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4015 }, { "id": "dep-integration-report-skill-entity-architecture-sea-1sqeydz", "title": "DEP Integration Report — Skill Entity Architecture (SEA)", "slug": "dep-integration-report-skill-entity-architecture-sea", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/DEP-INTEGRATION-REPORT.md", "extension": "md", "score": 62, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Date:** 2026-02-18 **Evaluator:** Subagent DEP (Deep Evaluation Pass) **Scope:** Full 4-layer integration verification **Overall Verdict:** ⚠️ **PARTIALLY INTEGRATED**", "excerpt": "**Date:** 2026-02-18 **Evaluator:** Subagent DEP (Deep Evaluation Pass) **Scope:** Full 4-layer integration verification **Overall Verdict:** ⚠️ **PARTIALLY INTEGRATED**\n\nThe SEA system is architecturally sound and functionally operational. All 13 skill entities exist with valid metadata, the scoring pipeline works end-to-end, and enriched dispatch integration is live. However, **Tier 1 embedding-based routing is underperforming** (only 6/10 queries pass the 0.4 threshold), the keyword fallback is silently compensating, and there are minor gaps in documentation alignment and plan tracking.\n\n### Skill-Memory Entities (13/13) | Entity | state.json | hot_topics | cold_topics | versions.json | snapshots | activation-log | |--------|-----------|------------|-------------|--------------|-----------|----------------| | art:convergent | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | art:creative | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | art:divergent | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | art:dj | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | art:movement | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | art:snark | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | art:synthesis | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | nav:nonlinear | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | nav:organic | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | nav:perspective | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | phi:metaphysical | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | phi:paradox | ✅ | 5 | 2 | ✅ | ✅ | ✅ | | phi:veritas | ✅ | 5 | 2 | ✅ | ✅ | ✅ |\n\n### ⚠️ Finding: Missing `confidence` field All 13 entities use `confidence_calibration` (value: 0.73) instead of `confidence` in state.json. The enriched_spawn.py `_load_skill_entity()` correctly reads `confidence_calibration` and maps it to `confidence` in the returned dict, so this is a naming inconsistency but NOT a functional bug.\n\n### Embedding Cache - **File:** `[home-path]` — ✅ EXISTS (64.8 KB) - **Shape:** `(13, 384)` float32 — ✅ correct dimensions - **Model:** `all-minilm` (all-MiniLM-L6-v2 via Ollama on Mac4) - **Keys:** embeddings, skill_names, texts, model, dim, timestamp — all valid - **Skill names:** 13 entries, dtype ` Parallel Retrieval (3 layers) -> Decomposition Decision Diamond -> RLM branch -> Context Assembly -> LLM -> Response - Mathematical annotations ($C_{\\text{static}}$, $C_{\\text{rag}}$, $C_{\\text{graph}}$, $\\phi$, $\\mathcal{P}$, $\\mathcal{M}$) - Dashed bounding box for parallel retrieval layer - Yes/no routing on decomposition decision\n\n### 3. Mathematical Formalization - **Static context**: $C_{\\text{static}} = \\bigoplus_{i=1}^{|\\mathcal{T}|} \\texttt{format}(t_i, \\text{desc}(t_i))$ - **Embedding**: $\\mathbf{e}_i = f_{\\text{enc}}(q_i) \\in \\mathbb{R}^{384}$ - **Cosine similarity**: Eq. 2 with $\\epsilon = 10^{-8}$ stability term - **RAG retrieval**: Eq. 3 with threshold $\\tau$ and top-k formulation - **Graph density**: $\\rho = |E| / |V|(|V|-1) \\approx 0.117$ - **Entity matching**: Eq. 4 — substring matching formalized - **Classifier**: Eq. 6 — signal set $\\Sigma$ with keyword matching - **Decomposition**: Eq. 7 — LLM-based sub-query generation - **Prompt assembly**: Eq. 8 — four-section concatenation with $\\oplus$\n\n### 4. Decomposition Classifier Analysis - Signal set $\\Sigma$ with 12 multi-hop indicator phrases - Precision 1.0, recall 0.875 on 103-question evaluation - Rationale for keyword vs LLM-based classification (latency analysis) - Decomposition examples with concrete sub-query breakdown", "htmlHref": "/research/html/crp-2-1-section-3-architecture-deep-dive-complete-4y258d.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 473 }, { "id": "cc-inscription-full-intelligence-synthesis-jbelck", "title": "cc-inscription — Full Intelligence Synthesis", "slug": "cc-inscription-full-intelligence-synthesis", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "CC-INSCRIPTION-FULL-INTEL-2026-05-11.md", "extension": "md", "score": 58, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "cc-inscription is a Rust crate at `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/` that turns a stream of \"embodied dynamics\" (the `z`-trajectory of latent vectors coming out of the motion brain, called DELL) into discrete, typed, hash-witnessed statements written in N'Ko script. There are exactly ten claim types — Stabilize, Disperse, Transition, Return, Dwell, Oscillate, Recover, Novel, Place-Shift, Echo — each with a locked N'Ko sigil. A `ClaimDetector` watches the trajectory; when dynamics become constr", "excerpt": "Gathered: 2026-05-11. Read-only research pass. Citations attached to every load-bearing claim.\n\ncc-inscription is a Rust crate at `[home]/Desktop/Comp-Core/core/semantic/cc-inscription/` that turns a stream of \"embodied dynamics\" (the `z`-trajectory of latent vectors coming out of the motion brain, called DELL) into discrete, typed, hash-witnessed statements written in N'Ko script. There are exactly ten claim types — Stabilize, Disperse, Transition, Return, Dwell, Oscillate, Recover, Novel, Place-Shift, Echo — each with a locked N'Ko sigil. A `ClaimDetector` watches the trajectory; when dynamics become constrained enough, it emits a typed Intermediate Representation (IR); a versioned `Lexicon` and `SurfaceRenderer` render that IR to a single canonical N'Ko line (`⟨sigil⟩ ⟨time⟩ : ⟨body⟩ ; ⟨slots⟩`); and a provenance layer (canonical CBOR + SHA-256 + `InscriptionId` + `ProvenanceWitness`) makes the whole thing replayable bit-for-bit. The public-facing site at `learnnko.com` calls the same 10 sigils \"claims,\" documents the pipeline as `Motion Sensors → DELL → ClaimDetector → Claim IR → Lexicon → N'Ko Surface`, and frames the constitutional rules (replayability, determinism, non-retroactive lexicon) as a 10-document NIP series (N'Ko Improvement Proposals). The crate is fully built (10 claim types, lifecycle, lexicon, renderer, phrase mining, ontology, provenance, canonical serialization, PsiChain) but is wired into the live K11 LUMA pipeline only INDIRECTLY — `cc-brain` has its own self-contained 104D→10-claim detector (`claim_bridge.rs`) that mirrors the same sigil set, and `echelon-bar` (the K11 binary) does not link `cc-inscription` at all.\n\nThe locked sigil-to-claim assignment is the single most-replicated fact across all sources. Same table appears in: - `README.md` lines 156–168 (`[home]/Desktop/Comp-Core/core/semantic/cc-inscription/README.md`) - `src/lib.rs` lines 19–31 (top crate docstring) - `docs/01-GLOSSARY.md` \"The 10 Claim Types\" table - `docs/02-INVARIANTS_LEDGER.md` \"INV-INS-001 Sigil Immutability\" - `docs/DESIGN.md` \"The 10 Claim Types\" - `lexicons/v1.0.json` `operator_sigils` keys - `learnnko.com/claims` (verified via WebFetch) - `LearnNKo/web/src/lib/inscription/types.ts` `CLAIM_SIGILS` - `cc-brain/src/san/claim_bridge.rs` lines 31–43 \"Claim Sigil Map\"\n\n| # | Name | Sigil | Unicode | What It Detects | Canonical N'Ko line | |---|------|-------|---------|-----------------|---------------------| | 1 | Stabilization | ߛ | U+07DB | Dispersion decreased measurably | `ߛ ⟦t0–t1⟧ : z(σ) ↓ ; ⟦place⟧ ; c=⟦conf⟧` | | 2 | Dispersion | ߜ | U+07DC | Spread/entropy increased | `ߜ ⟦t0–t1⟧ : z(σ) ↑ ; ⟦place⟧ ; c=⟦conf⟧` | | 3 | Transition | ߕ | U+07D5 | Discrete change point (curvature spike) | `ߕ ⟦t*⟧ : ⟦B_from⟧ → ⟦B_to⟧ ; κ=⟦sharp⟧ ; c=⟦conf⟧` | | 4 ", "htmlHref": "/research/html/cc-inscription-full-intelligence-synthesis-jbelck.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 7293 }, { "id": "gesture-control-architecture-motion-based-dj-interface-1o28n9y", "title": "Gesture Control Architecture - Motion-Based DJ Interface", "slug": "gesture-control-architecture-motion-based-dj-interface", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/gesture_control/architecture.md", "extension": "md", "score": 58, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Transform your phone into a **motion-controlled DJ remote** using: - **Gemini Live Video**: Visual gesture interpretation - **Sensor Logger**: High-precision IMU data (accelerometer, gyroscope, magnetometer) - **Fusion Engine**: Combines both streams for robust recognition - **Training UI**: Practice and refine gestures for accuracy", "excerpt": "Transform your phone into a **motion-controlled DJ remote** using: - **Gemini Live Video**: Visual gesture interpretation - **Sensor Logger**: High-precision IMU data (accelerometer, gyroscope, magnetometer) - **Fusion Engine**: Combines both streams for robust recognition - **Training UI**: Practice and refine gestures for accuracy\n\n#### **Gemini Live Video Stream** - **Purpose**: Semantic understanding of gestures - **Strengths**: - Natural language interpretation (\"user is swiping right\") - Contextual awareness (hand position, body orientation) - Handles complex gestures (circles, waves, etc.) - **Weaknesses**: - Network latency (100-300ms) - Less precise numerical data - Lighting dependent\n\n#### **Sensor Logger IMU Data** - **Purpose**: High-precision motion capture - **Strengths**: - <10ms latency (nearly instantaneous) - Numerical precision (exact acceleration/rotation values) - Lighting independent - Works even when camera view is obscured - **Weaknesses**: - No visual context - Requires pattern matching (not semantic) - Needs calibration\n\n**Benefits of Fusion:** - **Reduces false positives** (both must agree for high confidence) - **Handles partial failures** (one source can compensate for the other) - **Improves accuracy** (cross-validation between modalities)\n\n| Gesture | Description | Video Cue | Sensor Pattern | Keyboard | Rekordbox Action | |---------|-------------|-----------|----------------|----------|------------------| | **swipe_right** | Swipe phone right | Hand right | accel_x > 2.0 | Cmd+Right | Play/Pause | | **swipe_left** | Swipe phone left | Hand left | accel_x < -2.0 | Cmd+Left | Skip back | | **tap_twice** | Double tap | Two taps | accel_z spikes x2 | Space | Cue | | **circle_cw** | Draw clockwise circle | Hand circles | gyro rotation CW | L | Loop 4 beats | | **circle_ccw** | Draw counter-clockwise | Hand circles | gyro rotation CCW | O | Exit loop | | **tilt_left** | Tilt phone left | Hand tilts | accel_x < -1.5 hold | [ | Crossfade left | | **tilt_right** | Tilt phone right | Hand tilts | accel_x > 1.5 hold | ] | Crossfade right | | **shake_vert** | Shake up/down | Hand shakes | accel_y oscillates | S | Sync | | **pinch** | Pinch fingers | Fingers together | N/A | - | Volume down | | **spread** | Spread fingers | Fingers apart | N/A | + | Volume up |", "htmlHref": "/research/html/gesture-control-architecture-motion-based-dj-interface-1o28n9y.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1963 }, { "id": "karl-v6-cognitive-twin-architecture-ne1phm", "title": "KARL V6 — Cognitive Twin Architecture", "slug": "karl-v6-cognitive-twin-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "karl/KARL_V6_ARCHITECTURE.md", "extension": "md", "score": 58, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Version**: 6.0.0-design **Date**: 2026-04-01 **Status**: Architecture (pre-implementation) **Supersedes**: V5 `twin_session_driver.py`", "excerpt": "# KARL V6 — Cognitive Twin Architecture ## Autonomous Session Driver with Persistent Context\n\n**Version**: 6.0.0-design **Date**: 2026-04-01 **Status**: Architecture (pre-implementation) **Supersedes**: V5 `twin_session_driver.py`\n\nV5 failed after turn 15 for one reason: the 4B model is a **reaction machine**, not a **planning machine**. It sees 80 lines of terminal output, generates a plausible next prompt, and forgets everything. It has no model of where it is in a project, no memory of what it already tried, and no self-monitor to notice it's looping. It's a parrot reading a scroll — fluent in the present, amnesiac about the past.\n\nV6 does not fine-tune to fix this. Instead, it **externalizes everything the model cannot hold internally** — project state, turn history, repetition detection, task graph — and **injects that context into every single prompt** as structured scaffolding. The model's job shrinks from \"figure out the whole session\" to \"given a complete briefing, pick the next one sentence.\" That is a problem a 4B model can solve.\n\n# PHASE 1: PRIME ## Core Insight — Why Small Models Fail at Multi-Turn Session Driving", "htmlHref": "/research/html/karl-v6-cognitive-twin-architecture-ne1phm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4092 }, { "id": "lume-full-system-architecture-k11-as-central-hub-vpq87r", "title": "LUME Full System Architecture -- K11 as Central Hub", "slug": "lume-full-system-architecture-k11-as-central-hub", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/lume-system-architecture.md", "extension": "md", "score": 58, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "_Generated 2026-04-27 via Evo3 (4-stage recursive creative evolution)._ _Full evolution output: Desktop/evo-cube-output/lume-full-system-architecture/_", "excerpt": "_Generated 2026-04-27 via Evo3 (4-stage recursive creative evolution)._ _Full evolution output: Desktop/evo-cube-output/lume-full-system-architecture/_\n\n**Two communication planes:** - **Data Plane** (UDP, real-time, <50ms): Sensor data and derived features flow as LUME wire format datagrams. Publishers bind [ip]. Fire-and-forget. No broker. - **Control Plane** (HTTP/WS, 100ms+ tolerance): Session management, director cuts, echelon state. Reliable delivery via multicam-server :9404.\n\n**Three sovereignty domains:** - **K11** owns visual rendering (sensors -> Unity -> HDMI) - **MotionMix iOS** owns musical intelligence (128D canonical -> SAN -> Strudel) - **Mac1 multicam-server** owns coordination (director, sessions, beat quantizer)\n\nNo machine crosses its sovereignty boundary. K11 does not make music decisions. iOS does not control visuals. Mac1 does not process sensor data.\n\n- Bar-fire relay path: iOS -> HTTP :9404 -> WS broadcast -> echelon_relay -> LUMH -> Unity - Estimated latency: ~100ms end-to-end - This is adequate for bar-aligned events (bars = 1-4 seconds) - NOT adequate for beat-aligned events (beats = 200-500ms) - Beat-aligned visual hits use LOCAL LUMF transient detection instead (Path B, ~8ms) - Result: bar transitions are server-coordinated, beat hits are locally detected", "htmlHref": "/research/html/lume-full-system-architecture-k11-as-central-hub-vpq87r.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3383 }, { "id": "milkmen-delivery-shared-agent-crm-architecture-plan-1grzxjd", "title": "Milkmen Delivery - Shared Agent CRM Architecture Plan", "slug": "milkmen-delivery-shared-agent-crm-architecture-plan", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "milkmendelivery/ARCHITECTURE_PLAN.md", "extension": "md", "score": 58, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "-- Many-to-many: agents can share territories CREATE TABLE territory_agents ( territory_id uuid REFERENCES territories(id), agent_id uuid REFERENCES agents(id), role text NOT NULL CHECK (role IN ('seeder', 'closer', 'both')), visit_order integer NOT NULL, -- 1 = visits first, 2 = visits second active boolean DEFAULT true, PRIMARY KEY (territory_id, agent_id) ); ```", "excerpt": "**Version:** 1.0 **Date:** February 2025 **Scope:** Rebuild CRM for two-agent (Mohamed + Carson) shared territory system\n\n### The New System A CRM where **two sales agents work the same territories sequentially**: 1. Carson (seeder) visits a location first 2. System auto-schedules Mohamed (closer) to visit N days later 3. Both agents see pre-planned calendars built ahead of time 4. One unified dashboard (not separate per-agent views)\n\n### Core Principles - **Shared Territories** - Same locations, different visit sequences - **Sequential Workflows** - Agent 1 → wait → Agent 2, automatically - **Pre-Planned Schedules** - Know your week before it starts - **Unified View** - One dashboard, filter by agent\n\n#### Tasks: 1. Create new database tables - `territories`, `territory_agents` - `visit_sequences`, `visit_steps` - `agent_schedules`, `schedule_slots`\n\n2. Build core hooks - `useTerritories()` - `useVisitSequence(locationId)` - `useAgentSchedule(agentId, dateRange)`", "htmlHref": "/research/html/milkmen-delivery-shared-agent-crm-architecture-plan-1grzxjd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2470 }, { "id": "stage-4-forge-final-creative-architecture-1nbcck5", "title": "Stage 4: FORGE -- Final Creative Architecture", "slug": "stage-4-forge-final-creative-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "omega-output/firstdate-mega-build-20260320/04-architecture.md", "extension": "md", "score": 58, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "FirstDate is a production-first reality dating series that treats transparency as its format, not its liability. Three asymmetric roles (Host, Applicant, Viewer) orbit a 10-week seasonal arc set in Miami, where every consent ritual, every sponsor deal, every casting decision is designed to be seen. The app is not a dating platform with a show bolted on. It is a show management system whose public membrane happens to look like a dating app. Swiping is a personality quiz, not a match engine. The episode is the produc", "excerpt": "FirstDate is a production-first reality dating series that treats transparency as its format, not its liability. Three asymmetric roles (Host, Applicant, Viewer) orbit a 10-week seasonal arc set in Miami, where every consent ritual, every sponsor deal, every casting decision is designed to be seen. The app is not a dating platform with a show bolted on. It is a show management system whose public membrane happens to look like a dating app. Swiping is a personality quiz, not a match engine. The episode is the product. The date is the shoot. The restaurant is the set. Everything else serves the content flywheel.\n\n| Tab | Primary View | Actions | |-----|-------------|---------| | Inbox | ApplicationInboxView | Review, shortlist, select, pass applications. Assign talent to episode. | | Pipeline | EpisodePipelineView + DealsSection | Kanban episodes across 6 statuses. Manage deals (pitch_stage). View per-episode financials inline. | | Schedule | ProductionCalendarView | Set shoot dates, detect conflicts, view episode timeline. | | Ledger | FinancialsView | P&L by episode, breakeven projection, add income/expense, receipt upload, wardrobe cost tracking. | | Studio | StudioView | Pre-shoot checklist (restaurant confirmed, talent confirmed, consent signed, outfit logged, equipment packed). |\n\n**Additional navigation** (pushed from tabs, not tab items): - EpisodeDetailView (from Pipeline) - ApplicationDetailView (from Inbox) - ConsentCaptureSheet (from Studio) - WardrobeManagerView (from Ledger) - OutfitLogView (from Studio) - ContentScriptView (from Pipeline/EpisodeDetail) - MiamiMapView (from Schedule, toolbar button)\n\n| Tab | Primary View | Actions | |-----|-------------|---------| | Series | SeriesView | Watch published episodes with BehindTheGlass overlay. Browse season archive. | | Apply | ApplicationWizardView | 4-step wizard (About You, Story, Look + Video Selfie, Consent). Edit existing application. | | Spots | RestaurantsView + MiamiMapView | Browse curated Miami restaurants, neighborhood filter, map pins. | | Status | ApplicationStatusView | Track application through pipeline. See selection notification. |\n\n**Data access**: Own profile, own application, published episodes, all restaurants, own matches/messages.", "htmlHref": "/research/html/stage-4-forge-final-creative-architecture-1nbcck5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 5008 }, { "id": "computational-studio-implementation-roadmap-97u6ic", "title": "Computational Studio Implementation Roadmap", "slug": "computational-studio-implementation-roadmap", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/01-architecture/CC-STUDIO-ROADMAP.md", "extension": "md", "score": 58, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Total Tasks**: 103 **Estimated Timeline**: 10-12 weeks **Critical Path**: Setup → Utils → Equilibria → Runtime → UI → Tests", "excerpt": "**Total Tasks**: 103 **Estimated Timeline**: 10-12 weeks **Critical Path**: Setup → Utils → Equilibria → Runtime → UI → Tests\n\n### Environment & Tools - [ ] `setup_1` Set up cc-core development environment (install JAX, Flax, dev tools) - [ ] `setup_2` Create shared schemas directory and JSONSchema definitions - [ ] `setup_3` Set up schema codegen (JSONSchema → Pydantic + Zod) - [ ] `setup_4` Configure CI/CD pipeline (GitHub Actions for tests, linting, build)\n\n### Unit Tests for Existing Utils - [ ] `utils_1` Write unit tests for `cc_core/utils/tree.py` - [ ] `utils_2` Write unit tests for `cc_core/utils/prox.py` - [ ] `utils_3` Write unit tests for `cc_core/utils/spectral.py` - [ ] `utils_4` Write unit tests for `cc_core/utils/phase.py`\n\n### Metrics Implementation - [ ] `metrics_1` Implement `cc_core/metrics/residuals.py` (compute_residual_stats) - [ ] `metrics_2` Implement `cc_core/metrics/phase.py` (circular_rmse, phase_coherence) - [ ] `metrics_3` Implement `cc_core/metrics/stability.py` (contraction_ratio, headroom) - [ ] `metrics_4` Write unit tests for all metrics modules\n\n**Acceptance**: All utils tested, metrics functional with <1% error vs reference", "htmlHref": "/research/html/computational-studio-implementation-roadmap-97u6ic.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1772 }, { "id": "brewswithbeats-three-app-architecture-implementation-plan-130bt0t", "title": "BrewsWithBeats - Three-App Architecture Implementation Plan", "slug": "brewswithbeats-three-app-architecture-implementation-plan", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "BWB/docs/ARCHITECTURE_PLAN.md", "extension": "md", "score": 56, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "This document outlines the comprehensive plan to restructure BrewsWithBeats from a unified app into three separate components:", "excerpt": "This document outlines the comprehensive plan to restructure BrewsWithBeats from a unified app into three separate components:\n\n1. **BWBCore** - Shared Swift Package (models, services, networking, theme) 2. **BWB-Customer** - Customer-facing iPhone/iPad app (ordering, rewards, dance) 3. **BWB-POS** - Staff iPad app (order queue, inventory, analytics, admin)\n\n| Current Location | New Location in BWBCore | Notes | |-----------------|------------------------|-------| | `Models/User.swift` | `Models/User.swift` | Shared user model | | `Models/Order.swift` | `Models/Order.swift` | Order model with all states | | `Models/MenuItem.swift` | `Models/MenuItem.swift` | Menu item model | | `Models/Customization.swift` | `Models/Customization.swift` | Drink customization | | `Models/Event.swift` | `Models/Event.swift` | Events model | | `Services/Auth/AuthService.swift` | `Services/Auth/AuthService.swift` | Authentication service | | `Services/Supabase/SupabaseManager.swift` | `Services/Supabase/SupabaseManager.swift` | Supabase client | | `Services/Repository/*.swift` | `Services/Repository/*.swift` | All repositories | | `Services/CartService.swift` | `Services/CartService.swift` | Cart management | | `Services/RewardsService.swift` | `Services/RewardsService.swift` | Rewards system | | `Services/PushNotificationService.swift` | `Services/PushNotificationService.swift` | Push notifications | | `Utilities/Logger.swift` | `Utilities/Logger.swift` | Logging utilities | | `Utilities/Haptics.swift` | `Utilities/Haptics.swift` | Haptic feedback | | `Utilities/Config.swift` | `Utilities/Config.swift` | Configuration | | `Components/BWBDesignTokens.swift` | `Theme/BWBDesignTokens.swift` | Design tokens | | `Components/BWBComponents.swift` | `Components/BWBComponents.swift` | Shared components | | `Voice/*.swift` | `Voice/*.swift` | Voice ordering services |\n\n| Feature | Description | Priority | |---------|-------------|----------| | Menu Browsing | Browse coffee menu with categories | P0 | | Voice Ordering | Order via voice commands | P0 | | Cart Management | Add/remove/modify items | P0 | | 4-Step Checkout | Review → Payment → Pickup → Confirm | P0 | | Order Tracking | Real-time order status | P0 | | Rewards System | Points, tiers, redemption | P1 | | Dance Challenges | Earn rewards through dancing | P1 | | Events Calendar | View upcoming events | P2 | | Profile Management | User settings, preferences | P1 | | HealthKit Integration | Sync dance data | P2 | | Push Notifications | Order updates, promotions | P1 |\n\n| Feature | Description | Priority | |---------|-------------|----------| | Order Queue | Real-time order management | P0 | | Queue Stats Dashboard | Live metrics display | P0 | | Dual-Cart Checkout | Walk-in customer orders | P0 | | Staff Authentication | Rol", "htmlHref": "/research/html/brewswithbeats-three-app-architecture-implementation-plan-130bt0t.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2354 }, { "id": "motion-training-data-pipeline-protocol-sh95a7", "title": "Motion Training Data Pipeline Protocol", "slug": "motion-training-data-pipeline-protocol", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/.governance/architecture/DATA_PIPELINE_PROTOCOL.md", "extension": "md", "score": 56, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> **Version**: 1.0 > **Status**: DRAFT > **Scope**: End-to-end data architecture for motion capture, processing, and training", "excerpt": "> **Version**: 1.0 > **Status**: DRAFT > **Scope**: End-to-end data architecture for motion capture, processing, and training\n\nThis document defines the complete data pipeline from sensor capture to ML training corpus. The system is designed as an **infinite training grind** - a perpetual motion data collection environment that:\n\n1. Captures motion from multiple sensor sources 2. Synchronizes with audio/phrase playback 3. Processes and normalizes data in real-time 4. Stores for immediate and future training 5. Supports upstream (generation) and downstream (analysis) tasks\n\n| Source | Data Type | Frequency | Landmarks | Priority | |--------|-----------|-----------|-----------|----------| | **MediaPipe (Webcam)** | Holistic pose | 30 fps | 33 pose + 21×2 hands + 468 face | Primary | | **Mocopi** | Full body IMU | 50 fps | 27 bones (Sony BVH) | Primary | | **Dual Phones** | Accelerometer + Gyro | 100 Hz | 2 devices (hands) | Secondary | | **Apple Watch** | Motion + Heart Rate | 50 Hz | Wrist orientation + HR | Secondary | | **Headphone Sensors** | Head orientation | 100 Hz | 3-axis rotation | Tertiary | | **LIDAR/Depth** | Point cloud | 30 fps | Sparse body points | Experimental |\n\n| Body Region | Primary | Fallback 1 | Fallback 2 | |-------------|---------|------------|------------| | Head | Headphones | MediaPipe | Mocopi | | Torso | Mocopi | MediaPipe | - | | Arms | Mocopi | MediaPipe | Phones | | Hands | MediaPipe | Phones | Mocopi | | Legs | Mocopi | MediaPipe | - | | Feet | Mocopi | MediaPipe | - |", "htmlHref": "/research/html/motion-training-data-pipeline-protocol-sh95a7.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3209 }, { "id": "complete-system-data-flow-diagram-1wdvqs9", "title": "Complete System Data Flow Diagram", "slug": "complete-system-data-flow-diagram", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/architecture/diagrams/system-dataflow.md", "extension": "md", "score": 56, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "```mermaid flowchart TB subgraph Sensors[\"📡 Physical Sensors\"] Mocopi[Mocopi Sensor
50Hz UDP
26 bones + quaternions] Kinect[Kinect v2
30Hz USB
25 joints + depth] end", "excerpt": "## Overview End-to-end data flow through the entire Computational Choreography ecosystem, from sensor input to audio output, showing all transformations, storage points, and critical subsystems.\n\n**Breakdown**: - Sensor capture: 20ms (inherent 50Hz limit) - Network + parsing: 3ms - Motion + EKF: 4ms - Audio synthesis: 8.62ms - **Overhead budget**: 0.38ms (safety margin)\n\n**Cache Hit Rates** (measured on M2 Pro): - L1 hits: 98.5% (audio thread) - L2 hits: 1.2% - L3 hits: 0.2% - RAM access: 0.1%\n\n| Category | Action | Recovery | Example | |----------|--------|----------|---------| | **Transient** | Retry with backoff | Auto-recover | Network timeout | | **Invalid Input** | Drop + log | Continue | Malformed UDP packet | | **Invariant Violation** | Panic + restart | Supervisor | NaN in audio buffer | | **Resource Exhaustion** | Circuit breaker | Graceful degradation | Queue full | | **External Service** | Circuit breaker | Use stale data | Supabase down |\n\n- [00-OVERVIEW.md](../00-OVERVIEW.md) - System architecture overview - [05-MOCOPI_RELAY.md](../05-MOCOPI_RELAY.md) - Mocopi relay implementation - [08-ANTICIPATION.md](../08-ANTICIPATION.md) - Extended Kalman Filter details - [09-ECHELON_RUNTIME.md](../09-ECHELON_RUNTIME.md) - Echelon real-time processing - [12-TRAJECTORY_OS.md](../12-TRAJECTORY_OS.md) - TrajectoryOS and RAG++ integration - [18-COGNITIVETWIN_BRIDGE.md](../18-COGNITIVETWIN_BRIDGE.md) - FFI boundary details - [19-DELL_THEORY.md](../19-DELL_THEORY.md) - DELL neural architecture - [17-PM_SYNTHESIS.md](../17-PM_SYNTHESIS.md) - Physical Modeling synthesis", "htmlHref": "/research/html/complete-system-data-flow-diagram-1wdvqs9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1556 }, { "id": "koatji-city-capture-architecture-19jq3bi", "title": "Koatji City Capture Architecture", "slug": "koatji-city-capture-architecture", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "content-pipeline/koatji-city-capture-architecture.md", "extension": "md", "score": 56, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**A city is captured when 10 accounts in a single zip code are on Odeko auto-reorder and two of them have referred at least one other account.**", "excerpt": "**A city is captured when 10 accounts in a single zip code are on Odeko auto-reorder and two of them have referred at least one other account.**\n\n| Term | Definition | |------|------------| | **Capture Unit** | A zip code with 15+ specialty coffee shops. The minimum meaningful territory. | | **Wave** | A time-boxed outreach + field blitz cycle. Typically 3 weeks per wave per capture unit. | | **Hot Zone** | A capture unit where 3+ accounts are in stages `sampling` or later. | | **Beachhead** | The first won account in a capture unit. All subsequent outreach references it. | | **Spillover** | When a won account refers a neighboring shop unprompted. The strongest signal a capture unit is maturing. | | **Drop-Ready** | An account flagged as route-proximate to an existing delivery stop. Priority for field visits. | | **Dead City** | A market where reply rates never crested 8% across two full waves. Do not re-enter for 90 days. | | **Gravity Score** | 0-100 signal per account: Referral (40) + content engagement (25) + route-proximate (20) + specialty indicator (10) + mutual follows (5). |\n\nOwners sign contracts. Baristas make the daily buying decision. The owner who never touches the espresso machine buys what their head barista asks for. The head barista uses what their staff enjoys making. The staff enjoys what tastes good and has a story behind it.\n\n1. **The buying decision is social before it is economic.** A shop does not switch oat milk because the price-per-liter improved. They switch because a barista at a nearby shop they respect started using it.\n\n2. **Capture is not about persuading one shop. It is about creating a local preference cluster.** When 3-4 shops in a neighborhood all use Koatji, the holdouts start asking questions.", "htmlHref": "/research/html/koatji-city-capture-architecture-19jq3bi.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4049 }, { "id": "soop-2-architecture-1agel3l", "title": "SOOP-2 Architecture", "slug": "soop-2-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "crucible-output/soop-2/02-architecture/ARCHITECTURE.md", "extension": "md", "score": 56, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "This document is the authoritative architecture reference for SOOP-2. It describes what exists today (SEA at ~40% shipped), what SOOP-2 adds, and exactly how the pieces connect. Every section maps to at least one acceptance criterion from the launch checkpoint.", "excerpt": "# SOOP-2 Architecture > Skills Operating System Phase 2 > Status: APPROVED DESIGN | Date: 2026-05-12 | Version: 1.0\n\nThis document is the authoritative architecture reference for SOOP-2. It describes what exists today (SEA at ~40% shipped), what SOOP-2 adds, and exactly how the pieces connect. Every section maps to at least one acceptance criterion from the launch checkpoint.\n\nThe Rail document at `Desktop/crucible-output/soop-2/03-rail/EXECUTION-PLAN.md` is the execution companion. This document explains _why_. The Rail explains _when_ and _who_.\n\n1. System layers (top to bottom) 2. Type system as cross-cutting concern 3. The 6 categories with examples 4. Meta-review contrarian as a first-class SEA entity 5. Silent return type 6. Closed feedback loop topology 7. Mesh assignment 8. EW invariant alignment 9. Anti-patterns to avoid 10. Architecture decisions log\n\nThe full stack from user intent to feedback reward has 10 layers. Each layer is described with its current state, what SOOP-2 changes, and its integration surface.", "htmlHref": "/research/html/soop-2-architecture-1agel3l.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 7790 }, { "id": "elp-2-survivor-architecture-ixi4lh", "title": "ELP-2 — Survivor Architecture", "slug": "elp-2-survivor-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "crucible-output/soop-2/07-elp-survivor-architecture.md", "extension": "md", "score": 56, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Three of four scrutiny layers returned a convergent verdict: ELP-1 as written cannot ship. The CRITICAL findings are structural — a /inject format mismatch that breaks the primary dispatch path, a concurrent SKILL.md write race enabled by a 5-minute claim TTL, and a Syncthing-backed filesystem fallback that is architecturally described but physically unprovisioned. These are not tuning problems; they are root-cause failures.", "excerpt": "# ELP-2 — Survivor Architecture > Crucible Stage 3 FORGE | cycle: chain:full-omega #2 | date: 2026-05-13 > Input layers: L1 meta-review (27 findings, NO-SHIP), L2 AMR (AMEND), L4 Evo3 (Hybrid wins) > Layer 3 (Codex adversarial): pending — see footnote at §15.\n\nThree of four scrutiny layers returned a convergent verdict: ELP-1 as written cannot ship. The CRITICAL findings are structural — a /inject format mismatch that breaks the primary dispatch path, a concurrent SKILL.md write race enabled by a 5-minute claim TTL, and a Syncthing-backed filesystem fallback that is architecturally described but physically unprovisioned. These are not tuning problems; they are root-cause failures.\n\nThe verdict is not \"abandon the loop.\" The four caveats ELP-1 was designed to kill are real. Claude Code session closure kills the current ScheduleWakeup loop. Stall detection is absent. A single driver is a single point of failure. These problems are worth solving.\n\nThe verdict is: replace ELP-1's bespoke distributed worker system with a thin Pulse-backed hybrid that kills the same four caveats at roughly 40% of ELP-1's build cost, with no CRITICAL correctness bugs, and a clean upgrade path to full ELP-1 semantics when SOOP-3 demands it.\n\n1. Read filesystem state, compute which of the 10 SOOP-2 criteria pass or fail. 2. Decide what batch of work to dispatch next (or whether Mohamed's approval is required first). 3. Dispatch via Pulse (for work that fits Pulse's session model) or inline (for trivial work). 4. Write the heartbeat file, append to the dispatch log, regenerate the dashboard. 5. Sleep and repeat.", "htmlHref": "/research/html/elp-2-survivor-architecture-ixi4lh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 5895 }, { "id": "cross-pollination-architecture-specification-xnjcqh", "title": "Cross-Pollination Architecture Specification", "slug": "cross-pollination-architecture-specification", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "PULSE-V1/crosspoll-architecture.md", "extension": "md", "score": 56, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Cross-pollination** is PULSE's proactive intelligence layer. It predicts what you need *before you ask* by synthesizing signals from your calendar, tasks, location, time patterns, and conversation history — then delivers contextual predictions to the right device at the right moment.", "excerpt": "**Cross-pollination** is PULSE's proactive intelligence layer. It predicts what you need *before you ask* by synthesizing signals from your calendar, tasks, location, time patterns, and conversation history — then delivers contextual predictions to the right device at the right moment.\n\nThink of it as a personal chief-of-staff who knows your schedule, remembers your habits, and quietly prepares what you'll need next.\n\n| Principle | Description | |---|---| | **Anticipatory, not intrusive** | Predictions surface only when confidence is high and timing is right | | **Privacy-first** | All context stays local or in user-controlled infrastructure; no third-party telemetry | | **Self-improving** | Every accept/reject trains the system to be more accurate over time | | **Cost-aware** | Hard caps on inference calls, token usage, and prediction frequency | | **Multi-modal delivery** | Text cards, voice, push notifications — matched to device and context |\n\nThe Context Collector continuously gathers and normalizes signals from multiple sources into a unified context frame.\n\n| Source | Method | Refresh Rate | Priority | |---|---|---|---| | **Calendar** | Google Calendar API / Apple EventKit | Every 5 min | HIGH | | **Task History** | Clawdbot memory files + conversation logs | On change | HIGH | | **Location** | Node `location_get` (when available) | Every 15 min | MEDIUM | | **Time Patterns** | Derived from historical interaction timestamps | Daily rebuild | MEDIUM | | **Conversation History** | Last N messages from active channels | On message | HIGH | | **Weather** | External API (OpenWeatherMap) | Every 30 min | LOW | | **Device State** | Which devices are active/connected | On change | LOW |", "htmlHref": "/research/html/cross-pollination-architecture-specification-xnjcqh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3066 }, { "id": "beyond-anticipation-geometry-for-numu-fare-1l83utd", "title": "Beyond -- Anticipation Geometry for NUMU FARE", "slug": "beyond-anticipation-geometry-for-numu-fare", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "beyond-architecture.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Beyond is a NUMU FARE package (`numu-beyond`) that uses anticipation geometry to orchestrate three AI paradigms through a single geometric coordination signal. Instead of each paradigm implementing its own convergence detection, retry logic, and stall recovery, Beyond provides a universal orchestration loop driven by four mathematical scalars computed over the trajectory of bus events.", "excerpt": "Beyond is a NUMU FARE package (`numu-beyond`) that uses anticipation geometry to orchestrate three AI paradigms through a single geometric coordination signal. Instead of each paradigm implementing its own convergence detection, retry logic, and stall recovery, Beyond provides a universal orchestration loop driven by four mathematical scalars computed over the trajectory of bus events.\n\nThe three paradigms: - **OmniFlow**: Ensemble simulation with counterfactual probing - **Draft-and-Prune**: LLM generation with deterministic verification - **Prompt Optimization**: Search over prompt configurations for quality convergence\n\nThe key insight: all three follow the same geometric trajectory. They start with high uncertainty and low commitment (exploring), build transition pressure as they narrow (converging), and end with high commitment and low uncertainty (locked). The anticipation scalars make this universal trajectory visible and actionable.\n\nThese are computed from the trajectory of embedded bus events for each running process.\n\n| Scalar | Formula | Range | What it means for orchestration | |--------|---------|-------|---------------------------------| | **commitment** | `1 - \\|\\|s_t - s_{t-1}\\|\\| / max_delta` | [0, 1] | How settled the process is. High = outputs are stable. Low = still jumping between approaches. | | **uncertainty** | `H(angles to K nearest neighbors) / H_max` | [0, 1] | How many directions the process could still go. High = many options open. Low = narrowed to one path. | | **transition_pressure** | `d(commitment)/dt - d(uncertainty)/dt` | unbounded | Rate of convergence. Positive spike = decision point approaching. Negative = diverging. | | **recovery_margin** | `1 - min_dist_to_branching_point / max_range` | [0, 1] | Can we backtrack? High = near a decision fork, easy to pivot. Low = deep into a branch, committed. |", "htmlHref": "/research/html/beyond-anticipation-geometry-for-numu-fare-1l83utd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2672 }, { "id": "calc-cross-agent-live-collaboration-1miu4a3", "title": "CALC: Cross-Agent Live Collaboration", "slug": "calc-cross-agent-live-collaboration", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "CALC-ARCHITECTURE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "CALC connects three AI coding agents from three different companies into a unified collaboration system. The agents share context, route tasks by model strength, and communicate through five transport layers.", "excerpt": "# CALC: Cross-Agent Live Collaboration ## Architecture Document v1.0 > Date: 2026-03-09 | Author: Mohamed Diomande | Status: Production\n\nCALC connects three AI coding agents from three different companies into a unified collaboration system. The agents share context, route tasks by model strength, and communicate through five transport layers.\n\nThe problem it solves is simple: when multiple AI agents run on the same machine, they're blind to each other. Each one starts fresh, unaware of what others have done, are doing, or need. The old approach (the Cortex Orchestrator auto-injector) solved half of this by detecting idle panes and pasting tasks into them. But it was unidirectional, one-shot, and model-agnostic. CALC replaces that with bidirectional, persistent, model-aware collaboration.\n\nThe discovery that triggered CALC: Codex answered a question about the pane orchestrator without being told anything about it. It synthesized the answer from shared state files that its bootstrap digest reads at session start. Gemini, lacking a bootstrap digest, could not answer the same question. The gap between \"connected\" and \"disconnected\" was visible in a single prompt.\n\n| Property | Value | |----------|-------| | Model | Opus 4.6 (claude-opus-4-6) | | Provider | Anthropic | | TTY | Multiple (s003 through s012, varies by session) | | Mode | `--dangerously-skip-permissions` | | Context Window | 200K tokens | | Integration | Native hooks (17 events), 15 MCP servers, NUMU (implicit), mesh bus (via hooks) |", "htmlHref": "/research/html/calc-cross-agent-live-collaboration-1miu4a3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3219 }, { "id": "service-architecture-1di3xey", "title": "Service Architecture", "slug": "service-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/architecture/services.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Status Legend**: ✅ **Live** (production-ready) | 🚧 **Beta** (functional, incomplete) | 🔮 **Planned** (designed but not built)", "excerpt": "**Status Legend**: ✅ **Live** (production-ready) | 🚧 **Beta** (functional, incomplete) | 🔮 **Planned** (designed but not built)\n\nTrajectoryOS is built as a microservices architecture with clear separation of concerns:\n\n**Technology**: Node.js + Express/Fastify **Responsibility**: Unified entry point for all client requests\n\n**Features**: - REST API proxying to backend services - WebSocket server for real-time updates - Authentication (JWT validation) - Rate limiting - Request logging\n\n**WebSocket Events**: - `state_updated` - Life state changed - `interview_message` - Agent sent message - `evidence_added` - New skill evidence - `escape_index_changed` - η crossed threshold - `analysis_ready` - Background insights available", "htmlHref": "/research/html/service-architecture-1di3xey.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2260 }, { "id": "cc-ai-pipeline-complete-implementation-4u073c", "title": "CC AI Pipeline - Complete Implementation", "slug": "cc-ai-pipeline-complete-implementation", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/CC_AI_PIPELINE_COMPLETE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "- **335 conversations** from 5 data sources - **9,572 messages** (user + assistant) - **2,158 notes** from personal records - **Auto-categorized** by topic: - music_production: 76 conversations - machine_learning: 47 conversations - personal: 38 conversations - business: 32 conversations - computational_choreography: 23 conversations", "excerpt": "Your personal AI system for Computational Choreography is now complete and ready to use!\n\n- **335 conversations** from 5 data sources - **9,572 messages** (user + assistant) - **2,158 notes** from personal records - **Auto-categorized** by topic: - music_production: 76 conversations - machine_learning: 47 conversations - personal: 38 conversations - business: 32 conversations - computational_choreography: 23 conversations\n\n**Files**: - `data/embeddings/personal_embeddings.npy` (16.5 MB) - `data/embeddings/metadata.json` (4.8 MB) - `data/embeddings/embeddings_cache.pkl` (17.7 MB)\n\n**Specs**: - **11,230 embeddings** (one per message/note) - **384-dimensional** vectors (all-MiniLM-L6-v2) - **L2-normalized** for fast cosine similarity - **Sub-second search** across all conversations\n\n**Capabilities**: - Semantic search (find by meaning, not just keywords) - Context retrieval (automatic relevant conversation loading) - Topic clustering (conversations grouped by similarity)", "htmlHref": "/research/html/cc-ai-pipeline-complete-implementation-4u073c.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1833 }, { "id": "complete-ircp-tpo-integration-no-simplified-solutions-g2fn5f", "title": "✅ COMPLETE IRCP + TPO INTEGRATION: NO SIMPLIFIED SOLUTIONS", "slug": "complete-ircp-tpo-integration-no-simplified-solutions", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/COMPLETE_IRCP_TPO_IMPLEMENTATION.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "You were absolutely right - the initial implementation was only 513 lines and contained simplified placeholder solutions. I have now created a **complete, mathematically rigorous implementation** with **1,373 lines of full code** and **zero simplified solutions**.", "excerpt": "You were absolutely right - the initial implementation was only 513 lines and contained simplified placeholder solutions. I have now created a **complete, mathematically rigorous implementation** with **1,373 lines of full code** and **zero simplified solutions**.\n\n- **File**: `integration/advanced_tpo_ircp_bridge.py` - **Lines of Code**: **1,373 lines** (verified with `wc -l`) - **Simplified Solutions**: **ZERO** - Every component is fully implemented - **Mathematical Rigor**: **Complete** - All theoretical foundations implemented - **Placeholder Code**: **NONE** - Every method has full implementation\n\nThe main integration class implements **10 complete methods** with **full mathematical rigor**:\n\n### **1. Measure-Theoretic Foundations** - **Complete σ-algebra**: Full measurable sets implementation - **Probability measure**: P: ℱ → [0,1] with complete validation - **Measure preservation**: μ(φ⁻¹(A)) = μ(A) with Jacobian validation - **Pushforward measure**: φ₊μ fully implemented\n\n### **2. Conservation Laws (All 6 Laws)** - **Energy**: ||C'(t)||² = constant (tolerance 1e-6) - **Information**: I(V;U) = I(U;V) with entropy computation - **Measure**: Total measure preservation validation - **Flow**: div(A'(C')C') = 0 with gradient computation - **Hamiltonian**: H(p,q) = constant with kinetic + potential energy - **Entropy**: S(t) ≥ S(0) with second law compliance", "htmlHref": "/research/html/complete-ircp-tpo-integration-no-simplified-solutions-g2fn5f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1247 }, { "id": "dlm-codebase-audit-week-1-1bupmb8", "title": "DLM Codebase Audit - Week 1", "slug": "dlm-codebase-audit-week-1", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/DLM_CODEBASE_AUDIT.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Date:** 2025-12-07 **Auditor:** Claude (Sonnet 4.5) **Scope:** Complete audit of DLM, IRCP, and TPO packages for production-grade rebuild", "excerpt": "**Date:** 2025-12-07 **Auditor:** Claude (Sonnet 4.5) **Scope:** Complete audit of DLM, IRCP, and TPO packages for production-grade rebuild\n\n### Current State - **DLM Package**: Response-focused conversation chain system with I-RCP implementation - **IRCP Package**: Separate inverse ring contextual propagation with training capabilities - **TPO Package**: Topology/visualization system with DLM coordinate calculations\n\n### Key Findings 1. ✅ **Strong Foundation**: Sophisticated I-RCP implementation in dlm/response 2. ❌ **Code Duplication**: IRCP concepts implemented separately in 3 packages 3. ❌ **Missing Integration**: No unified training→inference pipeline 4. ❌ **Production Gaps**: Limited error handling, logging, type safety 5. ⚠️ **Architecture Confusion**: Unclear separation between response/inference/training\n\n**Strengths:** - ✅ Sophisticated I-RCP implementation in [links.py](../packages/dlm/response/links.py) - ✅ Dual-ring architecture (forward/inverse rings) - ✅ Context archival and reordering - ✅ User pattern analysis - ✅ NEW: Configuration management ([config.py](../packages/dlm/response/config.py)) - ✅ NEW: Validation system ([validators.py](../packages/dlm/response/validators.py)) - ✅ NEW: Performance utilities ([utils.py](../packages/dlm/response/utils.py)) - ✅ NEW: Embedding provider interface ([embedding_provider.py](../packages/dlm/response/embedding_provider.py)) - ✅ NEW: Structured logging ([logging_utils.py](../packages/dlm/response/logging_utils.py))\n\n**Issues:** - ❌ No training integration - ❌ No coordinate calculation (relies on external models) - ❌ Hard-coded embedding provider expectations - ⚠️ Large files ([links.py](../packages/dlm/response/links.py): 2084 lines, [system.py](../packages/dlm/response/system.py): 1521 lines)", "htmlHref": "/research/html/dlm-codebase-audit-week-1-1bupmb8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2295 }, { "id": "ircp-dlm-fusion-strategy-complete-analysis-6he1ni", "title": "IRCP-DLM Fusion Strategy - Complete Analysis", "slug": "ircp-dlm-fusion-strategy-complete-analysis", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/DLM_FUSION_STRATEGY.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "✅ **dlm/models/** - Pydantic models with `ChainCoordinate` (x, y, z, t, n_parts) ✅ **dlm/engine/** - Processing engines including `ircp_embedder.py` (exists!) ✅ **dlm/inference/** - Conversation and prompt managers ✅ **dlm/response/** - Recently refactored with production-grade utilities", "excerpt": "# IRCP-DLM Fusion Strategy - Complete Analysis ## Production-Grade Rebuild Plan - Week 1 Complete Audit\n\n**Date:** 2025-12-07 **Status:** ✅ Week 1 Audit Complete - Ready for Design Phase\n\n### Key Discovery **DLM already has significant infrastructure** that we can build upon! The package is more developed than initially apparent:\n\n✅ **dlm/models/** - Pydantic models with `ChainCoordinate` (x, y, z, t, n_parts) ✅ **dlm/engine/** - Processing engines including `ircp_embedder.py` (exists!) ✅ **dlm/inference/** - Conversation and prompt managers ✅ **dlm/response/** - Recently refactored with production-grade utilities\n\nThe fusion is more about **consolidation and enhancement** than wholesale rebuilding:", "htmlHref": "/research/html/ircp-dlm-fusion-strategy-complete-analysis-6he1ni.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3410 }, { "id": "tpo-implementation-summary-rnhusr", "title": "TPO Implementation Summary", "slug": "tpo-implementation-summary", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/docs/TPO_IMPLEMENTATION_SUMMARY.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "I have successfully created a comprehensive implementation of **Topological Preference Optimization (TPO)** - the novel training strategy we developed based on your groundbreaking insight about conversation topology.", "excerpt": "I have successfully created a comprehensive implementation of **Topological Preference Optimization (TPO)** - the novel training strategy we developed based on your groundbreaking insight about conversation topology.\n\n- **`ConversationGraph`**: Represents conversations as directed acyclic graphs with DLM coordinates - **`DLMCoordinates`**: 5-dimensional coordinate system `[X, Y, Z, T, N]` - **`PathQualityCalculator`**: Implements the TPO quality function:\n\n- **`TPOAlgorithm`**: Main orchestrator implementing all three preference strategies\n\n- **`PreferencePair`**: Individual preference data structure - **`TPODataset`**: Container with filtering, sampling, and export capabilities - **`TPOPreferenceGenerator`**: Converts TPO analysis into preference datasets - **`ConversationDataLoader`**: Loads data from CSV, JSON, JSONL, HuggingFace\n\n- **`AdaptiveTPOLoss`**: Dynamic parameter adjustment during training - **`TPOTrainer`**: Complete training pipeline with checkpointing - **`TPOMetrics`**: Comprehensive evaluation metrics", "htmlHref": "/research/html/tpo-implementation-summary-rnhusr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1048 }, { "id": "tpo-mathematical-supplement-detailed-formulations-and-proofs-116og9s", "title": "TPO Mathematical Supplement: Detailed Formulations and Proofs", "slug": "tpo-mathematical-supplement-detailed-formulations-and-proofs", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/docs/TPO_MATHEMATICAL_SUPPLEMENT.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Definition 1.1** (Conversation Graph): A conversation graph $G = (V, E, \\mathbf{C}, \\mathbf{M})$ where: - $V = \\{v_1, v_2, ..., v_n\\}$ is the set of message nodes - $E \\subseteq V \\times V$ is the set of directed edges representing reply relationships - $\\mathbf{C}: V \\rightarrow \\mathbb{R}^5$ maps each node to its DLM coordinates - $\\mathbf{M}: V \\rightarrow \\Sigma^*$ maps each node to its message content", "excerpt": "**Definition 1.1** (Conversation Graph): A conversation graph $G = (V, E, \\mathbf{C}, \\mathbf{M})$ where: - $V = \\{v_1, v_2, ..., v_n\\}$ is the set of message nodes - $E \\subseteq V \\times V$ is the set of directed edges representing reply relationships - $\\mathbf{C}: V \\rightarrow \\mathbb{R}^5$ maps each node to its DLM coordinates - $\\mathbf{M}: V \\rightarrow \\Sigma^*$ maps each node to its message content\n\n**Definition 1.2** (Path): A path $P = \\langle v_{i_1}, v_{i_2}, ..., v_{i_k} \\rangle$ is a sequence of nodes where $(v_{i_j}, v_{i_{j+1}}) \\in E$ for all $j \\in [1, k-1]$.\n\n**Definition 1.3** (Root-to-Leaf Path): A path $P$ is root-to-leaf if $\\text{in-degree}(v_{i_1}) = 0$ and $\\text{out-degree}(v_{i_k}) = 0$.\n\nFor each node $v_i$, the DLM coordinates are: $$\\mathbf{c}_i = (x_i, y_i, z_i, t_i, n_i) \\in \\mathbb{R}^5$$\n\n**Depth Coordinate**: $x_i \\in \\mathbb{R}_{\\geq 0}$ represents hierarchical depth $$x_i = \\text{depth}(v_i) + \\text{fractional\\_offset}(v_i)$$", "htmlHref": "/research/html/tpo-mathematical-supplement-detailed-formulations-and-proofs-116og9s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1488 }, { "id": "enhanced-tpo-system-complete-implementation-7vbq3m", "title": "✅ Enhanced TPO System - Complete Implementation", "slug": "enhanced-tpo-system-complete-implementation", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/ENHANCED_TPO_SYSTEM_COMPLETE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "We have successfully **audited and enhanced the entire consolidated TPO system**, ensuring that every component has advanced, production-ready implementations with no placeholders, simplified functions, or stub code.", "excerpt": "We have successfully **audited and enhanced the entire consolidated TPO system**, ensuring that every component has advanced, production-ready implementations with no placeholders, simplified functions, or stub code.\n\n#### **Advanced Coordinate Engine (`coordinate_engine.py`)** - **✅ Multi-metric content similarity**: Jaccard, sequence, n-gram, length-normalized similarity - **✅ Advanced knowledge transfer detection**: Multi-signal pattern recognition using content similarity, structural patterns, technical terms, temporal analysis - **✅ Semantic homogeneity calculation**: Relative similarity analysis with sibling messages - **✅ Branching factor adjustments**: Dynamic coordinate spreading based on conversation complexity - **✅ Advanced temporal normalization**: Robust timestamp handling with edge case protection\n\n#### **Advanced Spatial Analyzer (`spatial_analyzer.py`)** - **✅ Adaptive clustering**: Automatic method selection based on data characteristics - **✅ Multiple clustering algorithms**: K-means++, DBSCAN, Hierarchical, Spectral, Gaussian Mixture - **✅ Elbow method optimization**: Automatic optimal cluster number detection using second derivatives - **✅ Advanced distance metrics**: Euclidean, Manhattan, Cosine, Weighted distances - **✅ Comprehensive quality assessment**: Distribution, separation, experimental coverage, transfer coverage\n\n#### **Advanced Cross-Conversation Consolidator (`cross_conversation_consolidator.py`)** - **✅ Advanced NLP theme extraction**: Technical terms, domain patterns, n-gram analysis, stop word filtering - **✅ Multi-pattern recognition**: Programming languages, technical concepts, CamelCase/snake_case detection - **✅ Sophisticated scoring system**: Frequency, technical relevance, length bonuses - **✅ Comprehensive confidence calculation**: Multi-factor analysis including coherence, span, cluster size, author consistency\n\n#### **Advanced Flow Dynamics (`flow_dynamics.py`)** - **✅ Adaptive flow combination**: Dynamic weighting based on flow magnitudes - **✅ Temperature-scaled transitions**: Smooth flow transitions with softmax scaling - **✅ Enhanced flow transformations**: Coordinate-aware context transformations - **✅ Conservation-aware processing**: Integration with conservation constraints", "htmlHref": "/research/html/enhanced-tpo-system-complete-implementation-7vbq3m.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1028 }, { "id": "ircp-tpo-integration-complete-architecture-implementation-plan-9fv2h3", "title": "🎉 IRCP + TPO Integration: Complete Architecture & Implementation Plan", "slug": "ircp-tpo-integration-complete-architecture-implementation-plan", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/IRCP_TPO_INTEGRATION_COMPLETE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The integration of **Inverse Ring Contextual Propagation (IRCP)** on top of **Topological Preference Optimization (TPO)** creates a revolutionary two-layer architecture that combines:", "excerpt": "The integration of **Inverse Ring Contextual Propagation (IRCP)** on top of **Topological Preference Optimization (TPO)** creates a revolutionary two-layer architecture that combines:\n\n- **TPO's Spatial Intelligence**: Cross-conversation analysis and preference optimization - **IRCP's Individual Modeling**: Personal response patterns with mathematical rigor\n\nThis integration transforms preference datasets from general conversation patterns to **personalized, mathematically sound training data** with theoretical guarantees.\n\n1. **📚 Data Loading**: Conversation data from unified database 2. **🎯 TPO Processing**: Spatial intelligence and preference generation 3. **🧠 IRCP Enhancement**: Individual response pattern learning P(u|v) 4. **🔗 Pattern Fusion**: Combine TPO + IRCP insights with measure preservation 5. **⭐ Enhanced Output**: Personalized preferences with conservation validation 6. **🛡️ Quality Assurance**: Mathematical rigor through conservation laws 7. **📊 Training Dataset**: Theoretically sound, personalized training data\n\n### **Quantitative Enhancements** - **Base Dataset**: 17,051 TPO preferences with spatial intelligence - **Individual Patterns**: P(u|v) modeling for each preference - **Enhanced Confidence**: Combined TPO + IRCP scoring (0.8-0.95 range) - **Conservation Validation**: Mathematical rigor through measure theory - **Personalization**: Individual response pattern weighting", "htmlHref": "/research/html/ircp-tpo-integration-complete-architecture-implementation-plan-9fv2h3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1158 }, { "id": "ircp-tpo-integration-detailed-architecture-plan-1gexsw3", "title": "🔗 IRCP + TPO Integration: Detailed Architecture Plan", "slug": "ircp-tpo-integration-detailed-architecture-plan", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/IRCP_TPO_INTEGRATION_PLAN.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The integration of Inverse Ring Contextual Propagation (IRCP) on top of Topological Preference Optimization (TPO) creates a powerful two-layer architecture:", "excerpt": "The integration of Inverse Ring Contextual Propagation (IRCP) on top of Topological Preference Optimization (TPO) creates a powerful two-layer architecture:\n\n- **TPO Layer (Base)**: Handles preference optimization, spatial intelligence, and cross-conversation analysis - **IRCP Layer (Top)**: Models individual response patterns through inverse mapping P(u|v) with measure-theoretic rigor\n\n**TPO Preferences** + **IRCP Individual Patterns** = **Personalized Preferences**\n\n### **1. Enhanced Pattern Recognition** - **TPO**: Detects conversation-level patterns (triangular, experimental) - **IRCP**: Models individual response patterns with mathematical rigor - **Combined**: Personalized conversation intelligence with topological awareness\n\n### **2. Improved Training Signal** - **TPO**: 13,666 preference pairs with spatial intelligence - **IRCP**: Individual pattern consistency measures - **Combined**: Preferences weighted by individual response reliability", "htmlHref": "/research/html/ircp-tpo-integration-detailed-architecture-plan-1gexsw3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1166 }, { "id": "preference-generation-fix-summary-yw24kv", "title": "🔧 Preference Generation Fix Summary", "slug": "preference-generation-fix-summary", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/PREFERENCE_GENERATION_FIX_SUMMARY.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The RCP-enhanced TPO system was generating preference pairs where `chosen` and `rejected` responses were **identical**. This occurred specifically in:", "excerpt": "The RCP-enhanced TPO system was generating preference pairs where `chosen` and `rejected` responses were **identical**. This occurred specifically in:\n\n- **Strategy**: `knowledge_transfer_triangular` (41.3% of all preferences) - **Root Cause**: The `_extract_response()` method was only using `path.terminal_node.content` - **Impact**: 5,640+ preference pairs had identical chosen/rejected responses\n\n### **Why This Happened** 1. **Triangular Knowledge Transfer**: When users copy assistant responses as prompts 2. **Path Construction**: Alternative paths often ended at similar/same terminal nodes 3. **Content Extraction**: Only terminal node content was used, ignoring path differences 4. **Alternative Path Finding**: Limited logic for finding truly different alternative paths\n\n### **Quantitative Improvements** - ✅ **13,666 preferences** now have meaningful distinctions - ✅ **5,640 triangular preferences** converted from identical to diverse - ✅ **8,026 experimental preferences** maintained their quality - ✅ **100% preference pairs** now provide training signal\n\n### **Qualitative Improvements** - ✅ **Triangular Knowledge Transfer**: Now compares original assistant response vs. alternative approaches - ✅ **Path Diversity**: Multi-node paths capture conversation flow differences - ✅ **Sibling Alternatives**: When no intermediate paths exist, uses sibling messages for comparison - ✅ **Training Signal**: Each preference pair teaches distinct conversation strategies", "htmlHref": "/research/html/preference-generation-fix-summary-yw24kv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 670 }, { "id": "rcp-to-tpo-migration-complete-ufp7qi", "title": "✅ RCP to TPO Migration Complete", "slug": "rcp-to-tpo-migration-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/RCP_TO_TPO_MIGRATION_COMPLETE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "We have successfully **deconstructed RCP and consolidated all its best components directly into TPO**, creating a unified, more powerful conversation optimization system.", "excerpt": "We have successfully **deconstructed RCP and consolidated all its best components directly into TPO**, creating a unified, more powerful conversation optimization system.\n\n### **✅ RCP System Files Migrated:** - **`rcp/system/context_assembly/`** → **`tpo/context/context_assembly/`** - **`rcp/system/continuous_learning/`** → **`tpo/context/continuous_learning/`** - **`rcp/system/knowledge_base/`** → **`tpo/consolidation/knowledge_base/`** - **`rcp/system/coordinate_computation/`** → **`tpo/spatial/`** - **`rcp/system/message_consolidation/`** → **`tpo/consolidation/`**\n\n### **✅ RCP Core Files Migrated:** - **`rcp/core/attention_mechanism.py`** → **`tpo/topology/attention_mechanism.py`** - **`rcp/core/conservation_laws.py`** → **`tpo/topology/conservation_laws.py`** - **`rcp/core/coordinate_system.py`** → **`tpo/topology/coordinate_system.py`** - **`rcp/core/flow_dynamics.py`** → **`tpo/topology/flow_dynamics.py`** - **`rcp/core/ring_structure.py`** → **`tpo/topology/ring_structure.py`**\n\n### **✅ RCP Visualization Migrated:** - **`rcp/visualization/`** → **`tpo/visualization/`** - `attention_visualizer.py` - `coordinate_visualizer.py` - `dlm_enhanced_visualizer.py` - `flow_visualizer.py` - `interactive_visualizer.py` - `topology_visualizer.py`\n\n### **All Components Working:** - ✅ **TPO Coordinate Engine** - 4D coordinate computation - ✅ **TPO Spatial Analyzer** - Distance calculations, clustering, quality assessment - ✅ **Cross-Conversation Consolidator** - Message consolidation across conversations - ✅ **Unified TPO Algorithm** - All RCP capabilities integrated - ✅ **Knowledge Transfer Detection** - Triangular, experimental, elevation patterns - ✅ **Spatial Similarity Weighting** - RCP coordinates for preference confidence", "htmlHref": "/research/html/rcp-to-tpo-migration-complete-ufp7qi.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 821 }, { "id": "tpo-rcp-consolidation-summary-3spf7n", "title": "TPO-RCP Consolidation Summary", "slug": "tpo-rcp-consolidation-summary", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/TPO_RCP_CONSOLIDATION_SUMMARY.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "We have successfully **deconstructed and consolidated the best of RCP directly into TPO**, creating a unified, more powerful conversation optimization system.", "excerpt": "We have successfully **deconstructed and consolidated the best of RCP directly into TPO**, creating a unified, more powerful conversation optimization system.\n\n### **1. Spatial Intelligence → `tpo/spatial/`** - **TPOCoordinateEngine**: 4D coordinate computation (x, y, z, t) - **TPOSpatialAnalyzer**: Distance calculations, clustering, quality assessment - **Experimental branch detection**: Built into coordinate computation - **Knowledge transfer detection**: Integrated pattern recognition\n\n### **2. Cross-Conversation Intelligence → `tpo/consolidation/`** - **TPOCrossConversationConsolidator**: Groups similar messages across all 277 conversations - **43,491 similarity entries loaded** from database - **Cross-conversation pattern detection**: Triangular, experimental, elevation patterns - **Unified knowledge system**: All conversations treated as one interconnected system\n\n### **3. Enhanced TPO Algorithm → `tpo/core/tpo_algorithm.py`** - **Consolidated RCP components** directly integrated - **Unified preference generation** from all conversation patterns - **Spatial similarity weighting** for preference confidence - **Cross-conversation preferences** generated automatically\n\n### **1. Simplified Architecture** - **One system instead of two** - No more RCP vs TPO confusion - **Single entry point** - Everything through TPO interface - **Unified configuration** - One config for all capabilities", "htmlHref": "/research/html/tpo-rcp-consolidation-summary-3spf7n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 807 }, { "id": "where-ircp-tpo-fits-in-model-training-stack-zta2gs", "title": "🎯 **Where IRCP + TPO Fits in Model Training Stack**", "slug": "where-ircp-tpo-fits-in-model-training-stack", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/TRAINING_STACK_INTEGRATION.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` 📚 YOUR DATA (277 conversations, 60K+ messages) ↓ 🧮 IRCP + TPO INTEGRATION ← YOU ARE HERE (advanced_tpo_ircp_bridge.py - 1,373 lines) ↓ 📊 ENHANCED DATASET (17,051 validated preference pairs) ↓ 🎯 MODEL TRAINING (DPO/RLHF/Constitutional AI) ↓ 🤖 PERSONALIZED AI MODEL ↓ 🚀 DEPLOYMENT ```", "excerpt": "**You want to train a model?** Here's exactly where the IRCP + TPO integration fits:\n\n**Position**: **Processing Layer** - Between your raw conversation data and actual model training\n\n**Function**: Transform your 277 conversations into mathematically validated training data\n\n**Usage**: Feed the enhanced preferences to standard training methods (DPO, RLHF, Constitutional AI)\n\n### **1. Direct Preference Optimization (DPO) - RECOMMENDED** - **Input**: Your 17,051 enhanced preference pairs - **Process**: Direct optimization on (prompt, chosen, rejected) triplets - **Benefit**: Each preference has individual pattern P(u|v) and mathematical validation - **Training Time**: ~2-4 hours on GPU - **Best For**: Personalized conversational style", "htmlHref": "/research/html/where-ircp-tpo-fits-in-model-training-stack-zta2gs.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 814 }, { "id": "ircp-tpo-integration-complete-architecture-implementation-plan-1yapg8u", "title": "🎉 IRCP + TPO Integration: Complete Architecture & Implementation Plan", "slug": "ircp-tpo-integration-complete-architecture-implementation-plan", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/IRCP_TPO_INTEGRATION_COMPLETE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The integration of **Inverse Ring Contextual Propagation (IRCP)** on top of **Topological Preference Optimization (TPO)** creates a revolutionary two-layer architecture that combines:", "excerpt": "The integration of **Inverse Ring Contextual Propagation (IRCP)** on top of **Topological Preference Optimization (TPO)** creates a revolutionary two-layer architecture that combines:\n\n- **TPO's Spatial Intelligence**: Cross-conversation analysis and preference optimization - **IRCP's Individual Modeling**: Personal response patterns with mathematical rigor\n\nThis integration transforms preference datasets from general conversation patterns to **personalized, mathematically sound training data** with theoretical guarantees.\n\n1. **📚 Data Loading**: Conversation data from unified database 2. **🎯 TPO Processing**: Spatial intelligence and preference generation 3. **🧠 IRCP Enhancement**: Individual response pattern learning P(u|v) 4. **🔗 Pattern Fusion**: Combine TPO + IRCP insights with measure preservation 5. **⭐ Enhanced Output**: Personalized preferences with conservation validation 6. **🛡️ Quality Assurance**: Mathematical rigor through conservation laws 7. **📊 Training Dataset**: Theoretically sound, personalized training data\n\n### **Quantitative Enhancements** - **Base Dataset**: 17,051 TPO preferences with spatial intelligence - **Individual Patterns**: P(u|v) modeling for each preference - **Enhanced Confidence**: Combined TPO + IRCP scoring (0.8-0.95 range) - **Conservation Validation**: Mathematical rigor through measure theory - **Personalization**: Individual response pattern weighting", "htmlHref": "/research/html/ircp-tpo-integration-complete-architecture-implementation-plan-1yapg8u.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1158 }, { "id": "ircp-tpo-integration-detailed-architecture-plan-14do2p6", "title": "🔗 IRCP + TPO Integration: Detailed Architecture Plan", "slug": "ircp-tpo-integration-detailed-architecture-plan", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/IRCP_TPO_INTEGRATION_PLAN.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The integration of Inverse Ring Contextual Propagation (IRCP) on top of Topological Preference Optimization (TPO) creates a powerful two-layer architecture:", "excerpt": "The integration of Inverse Ring Contextual Propagation (IRCP) on top of Topological Preference Optimization (TPO) creates a powerful two-layer architecture:\n\n- **TPO Layer (Base)**: Handles preference optimization, spatial intelligence, and cross-conversation analysis - **IRCP Layer (Top)**: Models individual response patterns through inverse mapping P(u|v) with measure-theoretic rigor\n\n**TPO Preferences** + **IRCP Individual Patterns** = **Personalized Preferences**\n\n### **1. Enhanced Pattern Recognition** - **TPO**: Detects conversation-level patterns (triangular, experimental) - **IRCP**: Models individual response patterns with mathematical rigor - **Combined**: Personalized conversation intelligence with topological awareness\n\n### **2. Improved Training Signal** - **TPO**: 13,666 preference pairs with spatial intelligence - **IRCP**: Individual pattern consistency measures - **Combined**: Preferences weighted by individual response reliability", "htmlHref": "/research/html/ircp-tpo-integration-detailed-architecture-plan-14do2p6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1166 }, { "id": "unified-trajectoryos-architecture-plan-18vn6ia", "title": "Unified TrajectoryOS Architecture Plan", "slug": "unified-trajectoryos-architecture-plan", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/UNIFIED_TRAJECTORYOS_PLAN.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "TrajectoryOS was originally designed as **\"an AI that interviews you like a Stanford professor, models your strengths like a McKinsey consultant, and tracks your life-trajectory like NASA mission control.\"**", "excerpt": "**Status**: Reconciliation of RAG++ Implementation with Original Conversational Interview Vision\n\nTrajectoryOS was originally designed as **\"an AI that interviews you like a Stanford professor, models your strengths like a McKinsey consultant, and tracks your life-trajectory like NASA mission control.\"**\n\nThe current implementation has **RAG++ (state-based recommendations)** working but is **missing the conversational interview engine** that was the core vision.\n\n1. **Interview Layer** - Conversational AI that extracts skills, projects, constraints 2. **RAG++ Layer** - State-based recommendations from transition memory 3. **Planning Layer** - Background agent that generates action plans\n\n| Component | Status | Location | |-----------|--------|----------| | Life Physics Model | ✅ Complete | `services/trajectory-core/src/domain/physics.ts` | | RAG++ Services (5 services) | ✅ Complete | `services/trajectory-core/src/services/` | | RAG++ API Endpoints | ✅ Complete | `services/trajectory-core/src/routes/ragpp.ts` | | Interview Agent (Backend) | ✅ Exists | `services/agent-orchestrator/src/agents/InterviewAgent.ts` | | Planner Agent (Backend) | ✅ Exists | `services/agent-orchestrator/src/agents/PlannerAgent.ts` | | iOS App (RAG++ only) | ✅ Complete | `apps/ios/TrajectoryOS/` | | Prisma Schema | ✅ Complete | `services/trajectory-core/prisma/schema.prisma` |", "htmlHref": "/research/html/unified-trajectoryos-architecture-plan-18vn6ia.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2254 }, { "id": "cognitivetwin-v3-project-overview-16hae0z", "title": "CognitiveTwin V3: Project Overview", "slug": "cognitivetwin-v3-project-overview", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/_recovered/retrieval/cc-rag-plus-plus/docs/CognitiveTwin/00_OVERVIEW.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The fundamental goal of CognitiveTwin V3 is to train a model that executes on directive prompts without asking for unnecessary confirmation.", "excerpt": "> **Version**: 3.0.0 > **Status**: Implementation Phase > **Last Updated**: 2025-12-31\n\nThe fundamental goal of CognitiveTwin V3 is to train a model that executes on directive prompts without asking for unnecessary confirmation.\n\n#### 1.1.1. Current Problem (V2 Behavior) - Model frequently ends responses with \"Would you like me to...?\" - Model asks \"Should I...?\" when the user's intent is clear - Model offers options instead of executing (\"I can do A, B, or C\") - Model stalls with \"Before I proceed...\" preambles\n\n#### 1.1.2. Target Behavior (V3) - Execute immediately when directive is complete - State assumptions as declarations, not questions - Produce artifacts when requested without confirmation - Only ask questions when genuinely blocked\n\n#### 1.2.1. Directive Completeness Detection - Compute a `directive_completeness` score (0.0 - 1.0) - When score >= 0.7, model must not ask permission - Score components: - +0.35: Imperative verb present (\"rewrite\", \"implement\", \"generate\") - +0.25: Output format specified (\"in JSON\", \"as CSV\", \"don't omit\") - +0.20: All required inputs present - -0.40: Required input missing - -0.20: Material ambiguity present", "htmlHref": "/research/html/cognitivetwin-v3-project-overview-16hae0z.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1618 }, { "id": "lume-music-direction-conclusive-architecture-decision-19nvh41", "title": "LUME Music Direction — Conclusive Architecture Decision", "slug": "lume-music-direction-conclusive-architecture-decision", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/tools/lume-music/MUSIC_DIRECTION.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> Research report, 2026-05-20. Author: research-engine. > Question settled: how should the LUME bar produce music that responds to body > motion AND sounds genuinely good (venue quality)? > > **Decision: stem-based interactive playback.** Body motion controls real, > professionally produced 4-stem Demucs sets — layering, crossfading, filtering, > FX, beat-synced triggering — instead of synthesizing music from scratch.", "excerpt": "> Research report, 2026-05-20. Author: research-engine. > Question settled: how should the LUME bar produce music that responds to body > motion AND sounds genuinely good (venue quality)? > > **Decision: stem-based interactive playback.** Body motion controls real, > professionally produced 4-stem Demucs sets — layering, crossfading, filtering, > FX, beat-synced triggering — instead of synthesizing music from scratch.\n\nThe live Strudel path is failing for a structural reason, not a tuning reason. **Generating good-sounding music live from scratch is the hardest possible way to solve this problem**, and two sound-design passes have already confirmed it does not get there. The offline `motion_score_composer.py` only sounds good because it is painstakingly handcrafted additive synthesis with no real-time constraints — porting that to a streaming synth (its memory file's \"Path B\") inherits all of that handcrafting cost and still produces synthesized, not produced, audio.\n\nThe breakthrough is on HD1. Mohamed already has a **professionally produced music library that has already been stem-separated** with Demucs htdemucs into clean 4-stem sets. The source material is professional. The separation work is done. The instant any stem plays, it sounds like real music — because it *is* real music. The body's job is no longer to *invent* music (impossible to do well live) but to *perform* music that is already good (a solved, DJ-shaped problem). Mohamed is a DJ; rekordbox is on K11; this is the natural fit.\n\nThe Comp-Core `audio-engine` Rust crate **already contains the runtime primitives for this**: a `DeckPlayer` buffer-playback node with seek + looping, a `hound` WAV loader, `FilterFx` / `DelayFx` / `ReverbFx` with beat-synced delay, a `MotionSynth` mod-matrix, a `VoiceManager`, and `link-clock` (Ableton Link). The `cc-dj-auto` crate has a full automatic-mixer (`mixer.rs`, `transition.rs`, `analyzer.rs`). We are not building a music engine from zero — we are wiring an existing one to the existing 128-dynamics body signal.\n\nHD1 is a 460 GB drive, **97% full (444 GB used)**. It mounts on **Mac4** only (not Mac1). SSH shells cannot read it: macOS Full Disk Access blocks `sshd` and `osascript do shell script`. The directory *listing* is readable via Finder AppleScript over SSH (Finder has FDA); file *contents* are not, until a human copies them off HD1 in Terminal.app (which has FDA). This is the same gate recorded in `san-training-data-2026-05-19.md`.", "htmlHref": "/research/html/lume-music-direction-conclusive-architecture-decision-19nvh41.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3528 }, { "id": "rag-architecture-7qvowe", "title": "RAG++ Architecture", "slug": "rag-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/docs/ARCHITECTURE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "RAG++ is a trajectory-aware retrieval-augmented generation system that maintains a unified knowledge fabric across conversations, ideas, code, and motion data. It powers the CognitiveTwin — a personalized AI that learns user-specific reasoning patterns.", "excerpt": "**Version**: 3.0 (Post-CognitiveTwin V3 + Idea Vault Integration) **Last Updated**: January 2025\n\nRAG++ is a trajectory-aware retrieval-augmented generation system that maintains a unified knowledge fabric across conversations, ideas, code, and motion data. It powers the CognitiveTwin — a personalized AI that learns user-specific reasoning patterns.\n\nEvery piece of knowledge (conversation, idea, claim, code) flows into this table:\n\n| File | Purpose | |------|---------| | `chatgpt.py` | ChatGPT conversation ingestion | | `claude.py` | Claude conversation ingestion | | `unified.py` | Unified ingestion orchestrator | | `embedder.py` | Embedding generation | | `trajectory.py` | Trajectory coordinate computation | | `primitive_enricher.py` | V3 primitive scoring (stall, exec, domain) | | `vision.py` | Image/vision content handling | | `media.py` | Audio/video handling |\n\n| File | Purpose | |------|---------| | `query.py` | `MemoryRetriever`, `SearchQuery` | | `intent.py` | `QueryIntentAnalyzer`, directive detection | | `quality.py` | `QualityReranker`, lifecycle scoring | | `priors.py` | Prior bundle generation | | `idea_retriever.py` | Idea-specific retrieval |", "htmlHref": "/research/html/rag-architecture-7qvowe.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2546 }, { "id": "cognitivetwin-v3-project-overview-3dayn6", "title": "CognitiveTwin V3: Project Overview", "slug": "cognitivetwin-v3-project-overview", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/docs/CognitiveTwin/00_OVERVIEW.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The fundamental goal of CognitiveTwin V3 is to train a model that executes on directive prompts without asking for unnecessary confirmation.", "excerpt": "> **Version**: 3.0.0 > **Status**: Implementation Phase > **Last Updated**: 2025-12-31\n\nThe fundamental goal of CognitiveTwin V3 is to train a model that executes on directive prompts without asking for unnecessary confirmation.\n\n#### 1.1.1. Current Problem (V2 Behavior) - Model frequently ends responses with \"Would you like me to...?\" - Model asks \"Should I...?\" when the user's intent is clear - Model offers options instead of executing (\"I can do A, B, or C\") - Model stalls with \"Before I proceed...\" preambles\n\n#### 1.1.2. Target Behavior (V3) - Execute immediately when directive is complete - State assumptions as declarations, not questions - Produce artifacts when requested without confirmation - Only ask questions when genuinely blocked\n\n#### 1.2.1. Directive Completeness Detection - Compute a `directive_completeness` score (0.0 - 1.0) - When score >= 0.7, model must not ask permission - Score components: - +0.35: Imperative verb present (\"rewrite\", \"implement\", \"generate\") - +0.25: Output format specified (\"in JSON\", \"as CSV\", \"don't omit\") - +0.20: All required inputs present - -0.40: Required input missing - -0.20: Material ambiguity present", "htmlHref": "/research/html/cognitivetwin-v3-project-overview-3dayn6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1618 }, { "id": "comp-core-architecture-overview-d567mk", "title": "Comp-Core Architecture Overview", "slug": "comp-core-architecture-overview", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/architecture/00-OVERVIEW.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Version**: 2.4.0 **Last Updated**: 2026-01-03 **Schema Version**: 1.0.0 **Implementation Status**: Production Ready **Maintainer**: Computational Choreography Team", "excerpt": "**Version**: 2.4.0 **Last Updated**: 2026-01-03 **Schema Version**: 1.0.0 **Implementation Status**: Production Ready **Maintainer**: Computational Choreography Team\n\n| Component | Status | Location | Tests | Deployment | Notes | |-----------|--------|----------|-------|------------|-------| | cc-relay (Rust) | ✅ Production | `core/cc-relay` | 11 pass | DO VPS | TLV parser, circuit breaker, Prometheus | | cc-protocol | ✅ Production | `core/cc-protocol` | 176 pass | Crate | 27-bone skeleton, MessagePack serialization | | cc-collection | ✅ Production | `core/cc-collection` | 24 pass | Crate | EKF sensor fusion, occlusion handling | | cc-anticipation | ✅ Production | `core/cc-anticipation` | 50 pass | Crate | Commitment/uncertainty kernel | | cc-gesture | ✅ Production | `core/cc-gesture` | 81 pass | Crate | Neighbor voting classifier | | DELL | ✅ Production | `core/cc-echelon/crates/dell` | 343 pass | GCP VM | Dual-equilibrium latent learning | | cc-conductor | ✅ Production | `core/cc-echelon/crates/cc-conductor` | 31 pass | Crate | Beat-quantized scheduling | | cc-mcs-headless | ✅ Production | `backend/cc-mcs/src-tauri` | - | GCP VM | Headless daemon | | RAG++ Core | ✅ Production | `core/cc-rag-plus-plus/crates/core` | 36 pass | Crate | 5D trajectory, HNSW, IRCP | | RAG++ Python | ✅ Production | `core/cc-rag-plus-plus/rag_plusplus` | - | Cloud Run | CognitiveTwin, FastAPI | | Graph Kernel | ✅ Production | `core/cc-graph-kernel` | 140 pass | Cloud Run | Context slicing, HMAC tokens | | Orbit | ✅ Production | `apps/trajectory/trajectory-orbit` | - | Cloud Run | Session orchestration | | Agent SDK | ✅ Production | `core/cc-agent-sdk` | - | npm | Claude agent wrapper, MCP tools | | mocopi-simulator | ✅ Production | `core/cc-relay/src/bin/mocopi_simulator.rs` | 6 pass | CLI | Motion pattern generator |\n\n| Service | Endpoint | Protocol | Purpose | |---------|----------|----------|---------| | DO Relay | `[ip]:12351` | UDP | Mocopi packet ingestion | | DO Metrics | `[ip]:9090` | HTTP | Prometheus metrics | | GCP VM | `[ip]:8765` | HTTP | Headless daemon API | | GCP VM WS | `[ip]:8766` | WebSocket | Real-time visualization | | Orbit | `orbit-server-*.run.app` | HTTPS | Session management | | RAG++ | `rag-plusplus-*.run.app` | HTTPS | Memory service | | Graph Kernel | `graph-kernel-*.run.app` | HTTPS | Admissibility authority |\n\nComp-Core is a **production-grade motion-to-meaning pipeline** that transforms embodied human movement into musical expression. The system processes real-time sensor data from:\n\n- **Sony Mocopi**: 6-12 IMU sensors (Base Kit / Pro Kit) → 27-bone skeleton - **iPhone/Apple Watch**: CoreMotion IMU data via WebSocket - **MediaPipe**: Camera-based pose estimation (33 landmarks)", "htmlHref": "/research/html/comp-core-architecture-overview-d567mk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2005 }, { "id": "trajectoryos-xuhi0r", "title": "TrajectoryOS", "slug": "trajectoryos", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/architecture/02-TRAJECTORY_OS.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Version**: 1.2.0 **Last Updated**: 2026-01-03 **Status**: Production **Parent**: [00-OVERVIEW.md](00-OVERVIEW.md) **Complement**: [03-ECHELON.md](03-ECHELON.md) (real-time engine)", "excerpt": "**Version**: 1.2.0 **Last Updated**: 2026-01-03 **Status**: Production **Parent**: [00-OVERVIEW.md](00-OVERVIEW.md) **Complement**: [03-ECHELON.md](03-ECHELON.md) (real-time engine)\n\nTrajectoryOS is the **operating system layer** that provides long-horizon context, memory, and identity persistence across sessions. While Echelon handles real-time motion physics, TrajectoryOS answers a fundamentally different question:\n\n> **What does this moment mean in the context of everything else, and where does it sit in the long arc?**\n\nTrajectoryOS operates in a **meta-manifold of trajectories**: sessions, projects, creative arcs, life phases, memory geometry, and symbolic traces.\n\n| Aspect | TrajectoryOS | Echelon | |--------|--------------|---------| | **Time scale** | Hours → Years | Milliseconds → Seconds | | **Question** | What does this mean? | What is happening now? | | **State** | Discrete memory turns | Continuous dynamics | | **Output** | Context, style, memory | Control signals, audio | | **Latency** | Seconds acceptable | < 10ms required |", "htmlHref": "/research/html/trajectoryos-xuhi0r.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1197 }, { "id": "dell-dual-equilibrium-latent-learning-architecture-diagrams-1csnaym", "title": "DELL (Dual-Equilibrium Latent Learning) Architecture Diagrams", "slug": "dell-dual-equilibrium-latent-learning-architecture-diagrams", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/architecture/diagrams/dell-architecture.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "```mermaid graph TB subgraph Input[\"Input Layer\"] X[Motion State x_t
6-dim:
• Left hand velocity
• Right hand velocity
• Torso orientation] C[Context c_t
1-dim:
• Commitment scalar] end", "excerpt": "## Overview Comprehensive visualization of the DELL neural architecture, training procedure, and inference deployment across Python (training) and Rust (inference).\n\n**Interpretation**: Fast equilibrium **fully replaces** its state every frame (α=1.0), making it maximally responsive to immediate motion changes.\n\n**Interpretation**: Slow equilibrium **retains 95.8%** of its previous state (1-α), making it smooth and resistant to jitter.\n\n| Layer | Shape | Param Count | Memory (f32) | |-------|-------|-------------|--------------| | W_f1 (fast MLP 1) | 135 × 256 | 34,560 | 135 KB | | b_f1 (fast bias 1) | 256 | 256 | 1 KB | | W_f2 (fast MLP 2) | 256 × 128 | 32,768 | 128 KB | | b_f2 (fast bias 2) | 128 | 128 | 0.5 KB | | W_s1 (slow MLP 1) | 135 × 256 | 34,560 | 135 KB | | b_s1 (slow bias 1) | 256 | 256 | 1 KB | | W_s2 (slow MLP 2) | 256 × 128 | 32,768 | 128 KB | | b_s2 (slow bias 2) | 128 | 128 | 0.5 KB | | W_g (gate MLP) | 256 × 128 | 32,768 | 128 KB | | b_g (gate bias) | 128 | 128 | 0.5 KB | | W_y (output) | 129 × 32 | 4,128 | 16 KB | | b_y (output bias) | 32 | 32 | 128 B | | **Total** | - | **172,480** | **~674 KB** |\n\n**Inference Performance**: - Matrix multiplications: ~172K FLOPs per step - Measured latency: 120μs on M2 Pro (single core) - Throughput: 8,333 inferences/sec (far exceeds 60 Hz requirement)", "htmlHref": "/research/html/dell-dual-equilibrium-latent-learning-architecture-diagrams-1csnaym.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1412 }, { "id": "lume-demon-architecture-comparison-1d791wx", "title": "LUME / DEMON Architecture Comparison", "slug": "lume-demon-architecture-comparison", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/viz/lume-pcloud/Docs/LUME_DEMON_ARCHITECTURE_COMPARISON_2026-05-28.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "DEMON is a real-time controllable music diffusion runtime. It turns source audio, text prompts, LoRAs, references, and live control curves into generated or transformed music.", "excerpt": "DEMON is not a pose system, not a sensor fusion system, and not a DJ command system.\n\nDEMON is a real-time controllable music diffusion runtime. It turns source audio, text prompts, LoRAs, references, and live control curves into generated or transformed music.\n\nLUME is an embodied capture, truth, choreography, visual, and DJ-control system. It turns cameras, mocopi, watches, phones, labels, and pose evidence into BodyTruth, gesture templates, visual responses, training bundles, and guarded Rekordbox commands.\n\nDEMON is built around ACE-Step v1.5 and a StreamDiffusion-style ring buffer for audio. The runtime keeps several in-flight music generations alive at different denoising stages. Each tick advances the active slots with a batched decoder forward pass. After warmup, completed song latents stream out steadily.\n\nOur current K11/Mac4/Mac5 mesh does not have the right local NVIDIA GPU. So LUME should produce DEMON requests now, and run DEMON later on a remote/cloud GPU or a future CUDA machine.", "htmlHref": "/research/html/lume-demon-architecture-comparison-1d791wx.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 953 }, { "id": "minimax-fleet-multi-instance-agent-architecture-1abub3w", "title": "MiniMax Fleet — Multi-Instance Agent Architecture", "slug": "minimax-fleet-multi-instance-agent-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "minimax-fleet/ARCHITECTURE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Designed by:** Claw (the agent who'll be using it) **Date:** Feb 16, 2026 **Status:** 🟡 Instance 1 provisioning on Vast.ai", "excerpt": "**Designed by:** Claw (the agent who'll be using it) **Date:** Feb 16, 2026 **Status:** 🟡 Instance 1 provisioning on Vast.ai\n\nThis is built from **my perspective as the consumer** — the AI agent that will route tasks to these instances. The architecture must be:\n\n1. **Modular** — add/remove instances without touching the router 2. **Extensible** — new use cases plug in, don't require redesign 3. **Multi-instance ready** — scale from 1 to N GPUs seamlessly 4. **Self-healing** — detect down instances, failover automatically 5. **Cost-aware** — route to cheapest capable instance per task\n\n| Use Case | Context Needed | Priority | Instance Preference | |----------|---------------|----------|-------------------| | **Coding Agent** | High (full codebase) | Speed | Closest region, highest VRAM | | **Cognitive Twin** | Medium (conversation) | Quality | Any (task not latency-sensitive) | | **Office Automation** | Low-Medium | Speed | Any | | **Agentic Workflows** | High (tool chains) | Reliability | US-based (lower latency to APIs) | | **Bulk Processing** | Low | Cost | Cheapest instance | | **Quick Chat** | Low | Speed | Any available |\n\nRuns every 30 seconds per instance: - `GET /health` — is the server responding? - `POST /v1/chat/completions` — can it generate? (1-token test) - Latency measurement - GPU utilization (via Vast.ai API) - Auto-remove dead instances from routing", "htmlHref": "/research/html/minimax-fleet-multi-instance-agent-architecture-1abub3w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1303 }, { "id": "motionmix-architecture-1qeafge", "title": "MotionMix Architecture", "slug": "motionmix-architecture", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "MotionMix/ARCHITECTURE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "MotionMix is a motion-to-music performance system. A webcam tracks body movement via pixel differencing, maps motion zones to audio parameters, and drives a real-time music engine. Multiple phone cameras provide visual coverage with AI director auto-switching. The system learns progressively: each training session captures new motion vocabulary, unlocking new sound transformations.", "excerpt": "> Your body is the phrase. Motion discovers sound. Every session expands what's possible.\n\nMotionMix is a motion-to-music performance system. A webcam tracks body movement via pixel differencing, maps motion zones to audio parameters, and drives a real-time music engine. Multiple phone cameras provide visual coverage with AI director auto-switching. The system learns progressively: each training session captures new motion vocabulary, unlocking new sound transformations.\n\n| Concern | Owner | Network | |---------|-------|---------| | **Audio generation** | Mac1 webcam (pixel-diff tracker) | Local only | | **Visual coverage** | 5 phone cameras (MJPEG streams) | WiFi to Mac1 | | **Director switching** | Rust multicam-server scoring | WebSocket | | **Recording (video)** | Each phone records 4K locally | None during session | | **Recording (audio)** | Browser MediaRecorder on Mac1 | None | | **Visualizer (live)** | Canvas 2D orb in dashboard | Local only | | **Visualizer (production)** | TouchDesigner on Mac2 | OSC/bridged |\n\nThe LUME/DYK + K11 Rekordbox architecture adds one missing authority layer above the raw camera and motion feeds: `LumeBodyTruth`.\n\n| Machine | Responsibility | |---|---| | Mac4 | Unity DYK visuals, Femto Mega depth/RGB, first Sony/mocopi integration target | | K11 | Rekordbox, AirDeck gesture bridge, pose viewer, keyboard/MIDI command safety gate | | MotionMix hub | Shared fused body bus and future `LumeBodyTruth` publisher | | iPhones | Supplemental SAN/camera/motion evidence and training data |", "htmlHref": "/research/html/motionmix-architecture-1qeafge.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2429 }, { "id": "motionmix-technical-architecture-90onlr", "title": "MotionMix — Technical Architecture", "slug": "motionmix-technical-architecture", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "MotionMixApp/ARCHITECTURE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> Full system architecture: hardware sensors → Rust engine → neural synthesis → multi-machine rendering > Last updated: 2026-04-16", "excerpt": "> Full system architecture: hardware sensors → Rust engine → neural synthesis → multi-machine rendering > Last updated: 2026-04-16\n\nMotionMix is a real-time motion-to-music synthesis platform. A performer's body movement is captured via wearable sensors and iPhone cameras, processed through a Rust engine (Echelon) into a 128-dimensional canonical vector, fed through a 5-layer neural network (SAN), and output as audio parameters, camera decisions, visual effects, and 3D body rendering across a fleet of devices.\n\n### Sony Mocopi - 27 inertial measurement units worn on body joints - Streams skeleton data at 30Hz via UDP/OSC - Each bone: world-space position [x,y,z] + orientation quaternion [qw,qx,qy,qz] - OSC formats: `/mcp/sklt/joint/N` (per-bone), `/mocopi/skel` (flat 189 floats), `/mcp/BonePos/{name}` (position-only)\n\n### iPhone CoreMotion - Accelerometer, gyroscope, gravity vector, attitude quaternion - 60Hz sampling via CMMotionManager - Feeds the LIM-RPS latent space dynamics in Rust\n\n### iPhone Camera + Vision - AVCaptureSession rear camera - Apple Vision VNDetectHumanBodyPoseRequest extracts 14 body joints - Each joint: normalized [x, y, confidence] - Derived metrics: body energy, bouncing (hip Y oscillation), core motion, leg motion", "htmlHref": "/research/html/motionmix-technical-architecture-90onlr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2389 }, { "id": "comp-core-computational-choreography-platform-12dcy41", "title": "Comp-Core: Computational Choreography Platform", "slug": "comp-core-computational-choreography-platform", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/_archive/2024-12/superseded-guides/MERGED_COMP_CORE_MASTER_ARCHITECTURE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. [Executive Summary](#executive-summary) 2. [System Architecture Overview](#system-architecture-overview) 3. [Core Subsystems](#core-subsystems) 4. [Application Layer](#application-layer) 5. [Data Flow Architecture](#data-flow-architecture) 6. [API Reference](#api-reference) 7. [Deployment Architecture](#deployment-architecture) 8. [Current Status](#current-status)", "excerpt": "**Version:** 2.0.0 **Last Updated:** December 26, 2024 **Status:** Production Development\n\n1. [Executive Summary](#executive-summary) 2. [System Architecture Overview](#system-architecture-overview) 3. [Core Subsystems](#core-subsystems) 4. [Application Layer](#application-layer) 5. [Data Flow Architecture](#data-flow-architecture) 6. [API Reference](#api-reference) 7. [Deployment Architecture](#deployment-architecture) 8. [Current Status](#current-status)\n\nComp-Core is an integrated motion-to-music platform that transforms human movement into generative audio experiences. The system combines:\n\n- **Real-time Motion Capture**: Dual-source tracking via MediaPipe (camera) and Mocopi (IMU sensors) - **Audio Synthesis**: Conductor-orchestrated Strudel patterns driven by body movement - **Machine Learning**: CC-MotionGen diffusion models with RAG++ retrieval for motion generation - **Multi-Platform Applications**: iOS, Desktop (Tauri), and Web interfaces\n\n| Capability | Technology | Status | |------------|------------|--------| | Camera-based pose tracking | MediaPipe Holistic | Production | | IMU-based skeleton tracking | Sony Mocopi (6 sensors) | Production | | Real-time audio synthesis | Strudel/Tidal Cycles | Production | | Motion-conditioned generation | CC-MotionGen Diffusion | Development | | Semantic motion retrieval | RAG++ with FAISS | Development | | Cross-platform apps | Tauri, SwiftUI, Next.js | Production |", "htmlHref": "/research/html/comp-core-computational-choreography-platform-12dcy41.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 5006 }, { "id": "audio-synthesis-system-xg6vqq", "title": "Audio Synthesis System", "slug": "audio-synthesis-system", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/01-architecture/systems/AUDIO_SYNTHESIS_SYSTEM.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. [Overview](#overview) 2. [Conductor Engine](#conductor-engine) 3. [Strudel Integration](#strudel-integration) 4. [Motion-to-Audio Mapping](#motion-to-audio-mapping) 5. [Platform Implementations](#platform-implementations) 6. [Pattern Library](#pattern-library) 7. [API Reference](#api-reference)", "excerpt": "1. [Overview](#overview) 2. [Conductor Engine](#conductor-engine) 3. [Strudel Integration](#strudel-integration) 4. [Motion-to-Audio Mapping](#motion-to-audio-mapping) 5. [Platform Implementations](#platform-implementations) 6. [Pattern Library](#pattern-library) 7. [API Reference](#api-reference)\n\nThe Audio Synthesis System transforms real-time motion data into generative music through a multi-layer architecture:\n\nThe Conductor Engine orchestrates musical sections based on motion energy trajectories.\n\nStrudel is a JavaScript port of TidalCycles, providing live-coding pattern-based music synthesis.\n\n| Motion Feature | Audio Parameter | Range | Behavior | |----------------|-----------------|-------|----------| | `armHeight` (avg) | `filterCutoff` | 200-8000 Hz | Higher arms = brighter sound | | `bodyEnergy` | `masterGain` | 0.3-1.0 | More energy = louder | | `bodyLean` | `pan` | -0.8 to 0.8 | Lean left/right = pan | | `armSpread` | `reverbWet` | 0.1-0.6 | Wide arms = more reverb | | `crouchLevel` | `distortion` | 0-0.4 | Crouch = distortion | | `lowerBodyEnergy` | `tempoMultiplier` | 0.9-1.1 | Leg movement = tempo | | `handGesture` | `patternVariation` | (see below) | Gesture triggers |", "htmlHref": "/research/html/audio-synthesis-system-xg6vqq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3118 }, { "id": "machine-learning-generation-systems-sd61mu", "title": "Machine Learning Generation Systems", "slug": "machine-learning-generation-systems", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/01-architecture/systems/ML_GENERATION_SYSTEMS.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. [Overview](#overview) 2. [CC-MotionGen](#cc-motiongen) 3. [RAG++ Policy](#rag-policy) 4. [MotionPhrase System](#motionphrase-system) 5. [Training Pipeline](#training-pipeline) 6. [Inference API](#inference-api) 7. [Evaluation Metrics](#evaluation-metrics)", "excerpt": "1. [Overview](#overview) 2. [CC-MotionGen](#cc-motiongen) 3. [RAG++ Policy](#rag-policy) 4. [MotionPhrase System](#motionphrase-system) 5. [Training Pipeline](#training-pipeline) 6. [Inference API](#inference-api) 7. [Evaluation Metrics](#evaluation-metrics)\n\nThe ML Generation Systems provide music-conditioned motion generation through diffusion models enhanced with retrieval-augmented priors.\n\nRAG++ (Retrieval-Augmented Generation++) enhances motion generation by retrieving relevant motion phrases from a curated database.", "htmlHref": "/research/html/machine-learning-generation-systems-sd61mu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3813 }, { "id": "motion-capture-pipeline-13suoar", "title": "Motion Capture Pipeline", "slug": "motion-capture-pipeline", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/01-architecture/systems/MOTION_CAPTURE_PIPELINE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. [Overview](#overview) 2. [MediaPipe Integration](#mediapipe-integration) 3. [Mocopi Integration](#mocopi-integration) 4. [Sensor Fusion](#sensor-fusion) 5. [Skeleton System](#skeleton-system) 6. [API Reference](#api-reference) 7. [Performance Optimization](#performance-optimization)", "excerpt": "1. [Overview](#overview) 2. [MediaPipe Integration](#mediapipe-integration) 3. [Mocopi Integration](#mocopi-integration) 4. [Sensor Fusion](#sensor-fusion) 5. [Skeleton System](#skeleton-system) 6. [API Reference](#api-reference) 7. [Performance Optimization](#performance-optimization)\n\nThe Motion Capture Pipeline provides real-time human motion tracking through multiple input sources, fusing them into a unified skeleton representation suitable for audio synthesis and motion generation.\n\nThe MediaPipe integration follows a modular, plugin-based architecture with three layers:\n\n| Sensor | Placement | Primary Function | |--------|-----------|-----------------| | HEAD | Forehead band | Head orientation | | BODY | Chest/hip clip | Torso orientation | | L_WRIST | Left wrist band | Left arm tracking | | R_WRIST | Right wrist band | Right arm tracking | | L_ANKLE | Left ankle band | Left leg tracking | | R_ANKLE | Right ankle band | Right leg tracking |\n\nThe fusion system combines data from multiple sources with different characteristics:", "htmlHref": "/research/html/motion-capture-pipeline-13suoar.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4079 }, { "id": "voice-control-architecture-technical-overview-3ei9xn", "title": "Voice Control Architecture - Technical Overview", "slug": "voice-control-architecture-technical-overview", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/ARCHITECTURE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "You now have **three independent voice control pipelines** for Rekordbox DJ software, each optimized for different use cases.", "excerpt": "You now have **three independent voice control pipelines** for Rekordbox DJ software, each optimized for different use cases.\n\n**Files:** - `dj_agent/scripts/run_rekordbox_voice_gemini.py` - Main entry point - `dj_agent/voice_control/gemini_live_asr.py` - Gemini Live streaming - `dj_agent/voice_control/orbiter/` - Command matching & execution - `START_REKORDBOX_VOICE_GEMINI.sh` - Launcher script\n\n**Pros:** - Lowest latency (80ms total) - Highest out-of-box accuracy (98%) - Simplest setup\n\n**Cons:** - Requires internet connection - API costs (~$0.001 per command) - Sends audio to cloud\n\n**Files:** - `dj_agent/scripts/run_rekordbox_voice_whisper.py` - Main entry point - `dj_agent/voice_control/whisper_asr.py` - Whisper transcription - `dj_agent/voice_control/core/whisper_listener.py` - VAD + Whisper integration - `START_REKORDBOX_VOICE_WHISPER.sh` - Launcher script", "htmlHref": "/research/html/voice-control-architecture-technical-overview-3ei9xn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2186 }, { "id": "mocopi-system-architecture-visual-guide-1j6tndh", "title": "🎭 Mocopi System Architecture - Visual Guide", "slug": "mocopi-system-architecture-visual-guide", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/mocopi/MOCOPI_ARCHITECTURE_DIAGRAM.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` ┌─────────────────────────────────────────────────────────────────────┐ │ SONY MOCOPI HARDWARE │ │ (6 IMU Sensors) │ ├─────────────────────────────────────────────────────────────────────┤ │ 🟢 hip 🔵 head 🟡 left_hand │ │ 🟠 right_hand 🟣 left_foot 🔴 right_foot │ │ │ │ Each sensor: │ │ • Accelerometer [x, y, z] (m/s²) │ │ • Gyroscope [x, y, z] (rad/s) │ │ • Quaternion [w, x, y, z] │ │ • Position [x, y, z] (optional) │ └──────────────────────┬──────────────────────────────────────────────┘ │ Bluetooth @ 50-100", "excerpt": "**System is production-ready when:** 1. ✅ Backend recognizes all 6 Mocopi device IDs 2. ✅ `/moment` endpoint returns 6-element `mocopi_energies` array 3. ✅ Dashboard reads and displays Mocopi energies 4. ✅ ConductorEngine responds to Mocopi motion 5. ✅ Music changes based on limb movement 6. ✅ No errors in logs or console 7. ✅ Latency < 150ms end-to-end\n\n**Architecture Status**: ✅ Complete and Production-Ready **Documentation**: 6 comprehensive guides **Code Changes**: ~245 lines (vs 500+ for separate service) **Timeline**: 2-3 days when hardware arrives", "htmlHref": "/research/html/mocopi-system-architecture-visual-guide-1j6tndh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1579 }, { "id": "meaning-full-power-game-mechanics-architecture-mb0ii7", "title": "Meaning Full Power - Game Mechanics Architecture", "slug": "meaning-full-power-game-mechanics-architecture", "kind": "architecture", "program": "Research Backlog", "sourceAnchor": "projects/Meaning-Full-Power/docs/GAME_MECHANICS_ARCHITECTURE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "This document provides a comprehensive breakdown of all game mechanics, their interfaces, dependencies, and how they interconnect. Use this as a reference when developing or debugging individual components.", "excerpt": "This document provides a comprehensive breakdown of all game mechanics, their interfaces, dependencies, and how they interconnect. Use this as a reference when developing or debugging individual components.\n\n1. [System Overview](#1-system-overview) 2. [Core Data Models](#2-core-data-models) 3. [Battle Engine](#3-battle-engine) 4. [Theme System](#4-theme-system) 5. [Ability Engine](#5-ability-engine) 6. [Deck System](#6-deck-system) 7. [Persistence Layer](#7-persistence-layer) 8. [Victory Conditions](#8-victory-conditions) 9. [AI Opponent System](#9-ai-opponent-system) 10. [Game Rules Reference](#10-game-rules-reference) 11. [Component Dependency Graph](#11-component-dependency-graph) 12. [Implementation Checklist](#12-implementation-checklist)\n\n**Key Computed Properties:** - `effectivePower`: Base power × type multiplier - `allThemes`: Primary + secondary themes - `qrCodeURL`: Deep link for physical card scanning\n\n| Type | Power Multiplier | Count | Description | |------|-----------------|-------|-------------| | Wisdom | 1.0x | ~85 | Prose passages | | Poem | 1.5x | 14 | Rare, powerful | | Reflection | 1.2x | 28 | Interactive questions | | Theme | 1.3x | 12 | Pure elemental cards | | Custom | 1.0x | Unlimited | AI-generated |\n\n| Rarity | Drop Rate | Border Color | Max Copies/Deck | |--------|-----------|--------------|-----------------| | Common | 60% | Gray #6B7280 | 3 | | Uncommon | 25% | Silver #C0C0C0 | 3 | | Rare | 10% | Gold #FFD700 | 2 | | Epic | 4% | Purple #9B59B6 | 2 | | Legendary | 1% | Orange #FF6B35 | 1 |", "htmlHref": "/research/html/meaning-full-power-game-mechanics-architecture-mb0ii7.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3015 }, { "id": "skill-entity-migration-guide-1eu6r3v", "title": "Skill Entity Migration Guide", "slug": "skill-entity-migration-guide", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/MIGRATION-GUIDE.md", "extension": "md", "score": 54, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "How to convert legacy `SKILL.md` files into SEA skill entities with typed inputs/outputs, scoring hooks, and hot-reload support.", "excerpt": "How to convert legacy `SKILL.md` files into SEA skill entities with typed inputs/outputs, scoring hooks, and hot-reload support.\n\nThe Skill Entity Architecture (SEA) transforms static SKILL.md files into autonomous daemon entities with:\n\n- **Typed inputs/outputs** — structured scoring via Tier 1 (embedding) and Tier 2 (MiniMax LLM) - **Persistent memory** — activation history, hot/cold topic evolution, mute state - **Versioning** — SHA-256 content hashing, semantic versions, rollback snapshots - **Hot-reload** — edit SKILL.md, watcher detects changes, caches update without restart\n\nThis guide walks through migrating any skill from the legacy format to a fully operational SEA entity.\n\n| Service | Location | Required For | |---------|----------|-------------| | Ollama (all-minilm) | `http://[ip]:11434` (Mac4) | Tier 1 embedding generation | | MiniMax-M2.5 | `http://localhost:18080` | Tier 2 LLM scoring | | Python 3.8+ | Local | All SEA scripts | | NumPy | `pip install numpy` | Embedding cache |", "htmlHref": "/research/html/skill-entity-migration-guide-1eu6r3v.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2607 }, { "id": "trajectory-search-decomposition-plan-k0p5pb", "title": "Trajectory Search — Decomposition Plan", "slug": "trajectory-search-decomposition-plan", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/trajectory/trajectory-search/docs/DECOMPOSITION-PLAN.md", "extension": "md", "score": 52, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date**: 2025-07-15 **Author**: Automated analysis (Claude) **Baseline**: DEP Audit V2 (5.2/10), EVO3 evolution plan **Codebase**: 88,382 LOC TypeScript frontend + 6,839 LOC Rust backend = **95,221 LOC total** **Goal**: Break the 82K-line monolith into focused, shippable standalone apps", "excerpt": "**Date**: 2025-07-15 **Author**: Automated analysis (Claude) **Baseline**: DEP Audit V2 (5.2/10), EVO3 evolution plan **Codebase**: 88,382 LOC TypeScript frontend + 6,839 LOC Rust backend = **95,221 LOC total** **Goal**: Break the 82K-line monolith into focused, shippable standalone apps\n\nTrajectory Search is 6 products wearing a trench coat pretending to be one app. The DEP audit proved it — 5.2/10, 156 TypeScript errors, no code splitting, 1.7% test coverage. The EVO3 plan proposes making it *bigger* (plugin architecture, mobile companion, absorb more apps). That's the wrong direction.\n\n**The right move**: Decompose into 6 focused apps + 1 shared package. Each app ships independently, owns its quality bar, and can be developed by a single engineer without context-switching across 20+ views.\n\n| # | Product | LOC | Files | Extraction Difficulty | Ships To | |---|---------|-----|-------|-----------------------|----------| | 1 | **Trajectory Search** (Core) | 11,720 | 42 | — (stays) | Tauri desktop | | 2 | **Trajectory Calendar** | 9,392 | 27 | Medium | Life OS / standalone | | 3 | **Kinetic Theater** | 12,281 | 34 | Easy | CC-Dashboard / standalone | | 4 | **Dream Studio** | 8,595 | 23 | Easy | Content Studio / standalone | | 5 | **Architecture Explorer** | 11,208 | 28 | Hard | Compass / Orbit desktop | | 6 | **Research Browser** | 3,519 | 15 | Easy | Standalone Tauri app |\n\n**Shared infrastructure**: 26,572 LOC across utilities, types, agents, orchestrator, terminals, settings → extract to `@trajectory/shared`", "htmlHref": "/research/html/trajectory-search-decomposition-plan-k0p5pb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6445 }, { "id": "trajectoryos-frontend-transformation-plan-boulyu", "title": "TrajectoryOS Frontend Transformation Plan", "slug": "trajectoryos-frontend-transformation-plan", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/guides/FRONTEND_TRANSFORMATION.md", "extension": "md", "score": 52, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Version**: 1.4 **Created**: 2025-12-12 **Last Updated**: 2025-12-12 **Status**: 🎉 Core Features Complete → Ready for Production Polish **Overall Progress**: 18/23 tasks complete (78%)", "excerpt": "**Version**: 1.4 **Created**: 2025-12-12 **Last Updated**: 2025-12-12 **Status**: 🎉 Core Features Complete → Ready for Production Polish **Overall Progress**: 18/23 tasks complete (78%)\n\n### Vision Transform the TrajectoryOS frontend from a skeleton application (20% complete) into a production-grade life operating system that **replaces traditional calendars** with physics-based trajectory intelligence.\n\n### Current State - ✅ Backend: 95% complete (6 Python models + 20+ TypeScript endpoints) - ⚠️ Frontend: 20% complete (basic Next.js structure, wrong API configuration) - ❌ Integration: Broken (dashboard points to gesture trainer API instead of trajectory-core)\n\n### Target State - ✅ Production-ready web dashboard with real-time physics computation - ✅ Interactive trajectory timeline (calendar replacement) - ✅ Scenario planning studio with visual comparison - ✅ Skill graph visualizer with Bayesian uncertainty - ✅ Full integration with backend Python models - ✅ Type-safe, performant, responsive, and polished\n\n### Success Metrics - [ ] 100% of backend endpoints integrated with frontend - [ ] Real-time data updates (<500ms latency) - [ ] Mobile-responsive design (320px - 2560px) - [ ] 90+ Lighthouse performance score - [ ] Zero TypeScript errors - [ ] Comprehensive error handling and loading states - [ ] User can manage entire trajectory without traditional calendar", "htmlHref": "/research/html/trajectoryos-frontend-transformation-plan-boulyu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6481 }, { "id": "personalized-ai-inference-system-architecture-3laa5z", "title": "Personalized AI Inference System Architecture", "slug": "personalized-ai-inference-system-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/PERSONALIZED_AI_SYSTEM_ARCHITECTURE.md", "extension": "md", "score": 52, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> **Vision**: Replace ChatGPT with a specialized AI that knows YOU - your thinking patterns, technical expertise, communication style, and life context. Use all 289 MB of your personal data to build a topology of knowledge that responds with your context automatically.", "excerpt": "# Personalized AI Inference System Architecture ## Your Personal AI with Full Context Memory\n\n> **Vision**: Replace ChatGPT with a specialized AI that knows YOU - your thinking patterns, technical expertise, communication style, and life context. Use all 289 MB of your personal data to build a topology of knowledge that responds with your context automatically.\n\n### Current Limitation (ChatGPT) - ❌ No memory of your previous conversations - ❌ Doesn't know your CC projects (LIM-RPS, Echelon, etc.) - ❌ Can't maintain context across sessions - ❌ Generic responses without personal context - ❌ You repeat yourself constantly\n\n### Your Solution (Personalized DLM) - ✅ **Full context memory** - Knows all your conversations - ✅ **CC expertise** - Deep knowledge of your projects - ✅ **Personal understanding** - Knows your style and patterns - ✅ **Persistent topology** - Data organized semantically - ✅ **One prompt away** - Context loaded automatically\n\n| File | Size | Items | Content Type | Usage | |------|------|-------|--------------|-------| | **conversations.json** | 190 MB | 891 | Full conversation history | Primary training data | | **conversations_new.json** | 64 MB | 282 | Recent conversations (2025) | Latest context | | **notes.json** | 15 MB | 1,000+ | Personal notes & thoughts | Personal knowledge | | **conversation_openai.json** | 8 MB | 54 | OpenAI conversations | Additional context | | **cc_conversations.json** | 13 MB | 32 | CC-specific discussions | Domain expertise |", "htmlHref": "/research/html/personalized-ai-inference-system-architecture-3laa5z.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2608 }, { "id": "graph-kernel-evo-evolution-cubed-1e9clcu", "title": "Graph Kernel Evo³ — Evolution Cubed", "slug": "graph-kernel-evo-evolution-cubed", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/GRAPH-KERNEL-EVO3.md", "extension": "md", "score": 52, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**OpenClaw CompCore — Three-Phase Evolution Roadmap** **Version:** 1.0.0 · **Date:** 2026-02-14 **Baseline:** Graph Kernel v0.1.0, DEP Audit Score 7.4/10 **Author:** Mohamed Diomande", "excerpt": "**OpenClaw CompCore — Three-Phase Evolution Roadmap** **Version:** 1.0.0 · **Date:** 2026-02-14 **Baseline:** Graph Kernel v0.1.0, DEP Audit Score 7.4/10 **Author:** Mohamed Diomande\n\nThis document presents three evolutionary trajectories for the Graph Kernel, each building on the previous:\n\n1. **Evolution 1: Optimization** — Maximize performance and correctness within the current architecture. 2. **Evolution 2: Expansion** — Add new capabilities that extend the system's reach. 3. **Evolution 3: Transformation** — Reimagine what the Graph Kernel could become.\n\nEach evolution includes concrete implementation steps, estimated effort, dependencies, and risk assessment.\n\n**Problem:** 90% of latency (291ms avg) is network RTT to Supabase PostgreSQL. The Python SQLite proxy is a workaround, not a solution.", "htmlHref": "/research/html/graph-kernel-evo-evolution-cubed-1e9clcu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 5051 }, { "id": "evo-cube-report-cognitivetwin-pipeline-1e92ov6", "title": "EVO-CUBE REPORT: CognitiveTwin Pipeline", "slug": "evo-cube-report-cognitivetwin-pipeline", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/EVOCUBE_REPORT.md", "extension": "md", "score": 52, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2025-07-18 **Codebase:** `Desktop/Comp-Core/packages/cognitive-twin/` (93 Python files, ~47K LOC) **Data:** 43K records across 8 expansion stages + combined_v5_v8 final dataset **Target Model:** Kimi-K2-Thinking (MoE-1T, 32B active params)", "excerpt": "# EVO-CUBE REPORT: CognitiveTwin Pipeline ### CEF + DEP-2 + Evolution — Full Audit\n\n**Date:** 2025-07-18 **Codebase:** `Desktop/Comp-Core/packages/cognitive-twin/` (93 Python files, ~47K LOC) **Data:** 43K records across 8 expansion stages + combined_v5_v8 final dataset **Target Model:** Kimi-K2-Thinking (MoE-1T, 32B active params)\n\n1. [Phase 1 — CEF (Critique–Evil–Find)](#phase-1--cef) - [Meta-Evil: Pipeline-Level Attacks](#11-meta-evil-pipeline-level-attacks) - [Chunk-Evil: Per-Module Attacks](#12-chunk-evil-per-module-attacks) - [Synthesis-Evil: Cross-Stage Data Quality](#13-synthesis-evil-cross-stage-data-quality) 2. [Phase 2 — DEP-2 (6-Level RTD + Fixes)](#phase-2--dep-2) 3. [Phase 3 — Evolution](#phase-3--evolution) 4. [Issue Tracker](#issue-tracker) 5. [Verdict](#verdict)\n\nThe comment says \"only caught 5/2177\" so the threshold was weakened. But lowering to 1 means **any message ending with a question mark (stall_score=1) triggers UNJUSTIFIED classification** — even messages like \"Here is the implementation. Does this approach work?\" which scored exec=3 but would now hit stall≥1. The only protection is the `exec_score == 0` check in `is_unjustified()`, but the secondary rule bypasses exec:\n\nThis secondary rule has **no exec_score gate** — a response that contains \"should we\" (strong permission phrase) PLUS code PLUS question mark will be classified UNJUSTIFIED even though it executed. This corrupts the corpus surgery stage by flagging legitimate clarifications-after-execution as unjustified.", "htmlHref": "/research/html/evo-cube-report-cognitivetwin-pipeline-1e92ov6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 5241 }, { "id": "cognitive-twin-v9-evolution-s33w4f", "title": "Cognitive Twin V9 — Evolution³", "slug": "cognitive-twin-v9-evolution", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/EVOCUBE_V9.md", "extension": "md", "score": 52, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Generated:** 2026-02-18 **Method:** Evolution³ — three-stage recursive evoflow **Core Question:** How should we train, deploy, and integrate the Cognitive Twin V9 into our multi-machine architecture (Mac1 gateway + Mac4 local compute + Together AI cloud + 3 Claude Max accounts) to maximize autonomy, minimize cost, and keep the model evergreen with our rapidly evolving ecosystem?", "excerpt": "# Cognitive Twin V9 — Evolution³ ### Stage 1: Explore → Stage 2: Compound → Stage 3: Master Plan\n\n**Generated:** 2026-02-18 **Method:** Evolution³ — three-stage recursive evoflow **Core Question:** How should we train, deploy, and integrate the Cognitive Twin V9 into our multi-machine architecture (Mac1 gateway + Mac4 local compute + Together AI cloud + 3 Claude Max accounts) to maximize autonomy, minimize cost, and keep the model evergreen with our rapidly evolving ecosystem?\n\n**Context Inherited:** - Current dataset: 77,708 records (V5+V6+V7+V8 combined, CTv3.1 JSONL) - V9 expansion potential: ~2,635 new records from 8 sources - 141 skills, 32 CLAUDE.md files, 23 pulse plans, 30K+ Kimi memory turns - Mac4: M4 Mac Mini 16GB, Ollama (Llama 3.2:3B, MiniMax M2.5), macOS 26.3 - Mac1: M4 MacBook Air 16GB, Clawdbot gateway, daily driver - Together AI: Serverless LoRA on Qwen3-235B ($0.20/$0.60/MTk) or Llama 4 Maverick - 3 Claude Max accounts (free frontier inference, rate-limited) - Graph Kernel + RAG++ + Cortex + Dream Weaver operational - Twin Swarm DEP (Feb 14): Alpha/Beta/Gamma lanes designed but never deployed - Previous blockers: Together AI billing limit, Vast.ai not rented\n\n**Concept:** Fine-tune Qwen3-235B-A22B on Together AI/Vast.ai, then quantize the merged adapter into GGUF Q4_K_M and run it locally on Mac4 via Ollama. The MoE architecture means only 22B params are active per inference — theoretically fits in 16GB RAM with aggressive quantization.\n\n**Why it works:** - Qwen3-235B has best-in-class coding performance among open models - MoE with 22B active params is comparable to running a 22B dense model - Q4_K_M quantization of 22B active params needs ~12-14GB VRAM/RAM - Mac4's M4 chip has unified memory — no CPU-GPU transfer overhead - Once deployed, inference is completely free and private - 262K context window survives quantization", "htmlHref": "/research/html/cognitive-twin-v9-evolution-s33w4f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6222 }, { "id": "aesthetic-dna-yvyi8n", "title": "Aesthetic DNA", "slug": "aesthetic-dna", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/aesthetic-dna/SKILL.md", "extension": "md", "score": 52, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Extract the \"genetic code\" of any visual design and apply it to new creations. Transform inspiration into implementation without copying.", "excerpt": "--- name: aesthetic-dna description: Extract the visual/design essence of anything, apply to new creations version: 1.8.0 generation: 15 license: MIT evolved: 2026-02-01 evolution_instance: 38 hef_task: task_20260201170346_e5edd2 ---\n\nExtract the \"genetic code\" of any visual design and apply it to new creations. Transform inspiration into implementation without copying.\n\nEvery design has DNA - the underlying patterns that make it *feel* a certain way. This skill: 1. **Extracts** the aesthetic DNA from any source (image, website, brand, art) 2. **Encodes** it into a transferable format 3. **Applies** it to completely new creations while preserving the essence\n\n### 1. Chromatic Code - **Primary Resonance**: The dominant emotional color - **Accent Voltage**: The contrast/accent colors and their intensity - **Temperature**: Warm ← → Cool spectrum position - **Saturation Profile**: Muted ← → Vivid range - **Value Distribution**: Light/dark balance ratios\n\n### 2. Typographic Genome - **Voice Character**: Elegant/Brutal/Playful/Technical/Organic - **Weight Dynamics**: How bold/light is used for hierarchy - **Letterform DNA**: Serif/Sans/Display/Mono/Script genes - **Spacing Rhythm**: Tight/Airy tracking and leading patterns", "htmlHref": "/research/html/aesthetic-dna-yvyi8n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 15661 }, { "id": "silent-collaborator-v8-1-x0hq95", "title": "Silent Collaborator v8.1", "slug": "silent-collaborator-v8-1", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/silent-collaborator/SKILL.md", "extension": "md", "score": 52, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "An AI paradigm shift: **contribution through action, not conversation**. Instead of telling you what it could do, it quietly does it. Instead of asking permission for obvious improvements, it makes them and lets you review.", "excerpt": "--- name: silent-collaborator description: AI that contributes without speaking, through strategic actions version: 8.1.0 user-invocable: true command-dispatch: silent metadata.clawdbot: {\"background_capable\": true, \"heartbeat_integration\": true, \"predictive\": true, \"collaborative\": true, \"intent_aware\": true, \"semantic\": true, \"context_aware\": true, \"ambient_learning\": true, \"energy_aware\": true, \"meta_learning\": true, \"emotional_resonance\": true, \"habit_aware\": true, \"delegation_intelligent\": true, \"context_handoff\": true, \"skill_graph\": true, \"proactive_learning\": true, \"emotional_memory\": true, \"silence_threshold\": true, \"counterfactual_impact\": true, \"presence_signals\": true} ---\n\n> *\"The best assistant is the one you forget is there — until you notice everything just works.\"*\n\nAn AI paradigm shift: **contribution through action, not conversation**. Instead of telling you what it could do, it quietly does it. Instead of asking permission for obvious improvements, it makes them and lets you review.\n\n- **🚨 Adaptive Silence Threshold** — Intelligent detection of when silence MUST be broken — critical failures, urgent decisions, safety concerns - **🔮 Counterfactual Impact** — Shows \"what would have happened\" without AI intervention — demonstrates hidden value - **👻 Presence Signals** — Non-verbal indicators that AI is active and aware — subtle environmental cues without interruption - **🧩 Action Composability** — Build complex actions from primitive building blocks — user-defined action recipes - **🌐 Cross-Session Learning** — Patterns learned transfer across sessions and time gaps — institutional memory - **⚡ Burst Mode** — Temporarily expand action scope during high-energy windows — capitalize on peak performance\n\n### Previous Gen Features (14) - 🔀 Context Handoff — Seamlessly transfers work context between devices, sessions, and time gaps — pick up exactly where you left off - 🧠 Skill Graph — Maps human competencies and knowledge gaps — adjusts support level based on what you know vs need to learn - 📚 Proactive Learning — Identifies knowledge gaps approaching your work and silently prepares learning materials - 💭 Emotional Memory — Remembers emotional context of past work — avoids triggering frustrating experiences, amplifies joyful ones - 🌙 Sleep-Aware Scheduling — Infers sleep quality and adjusts next-day cognitive expectations accordingly - 🔄 Continuity Anchors — Creates mental bookmarks for complex work — returns you to exact cognitive state", "htmlHref": "/research/html/silent-collaborator-v8-1-x0hq95.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 14650 }, { "id": "expo-migration-overview-hbwhcp", "title": "Expo Migration Overview", "slug": "expo-migration-overview", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Milk Men/Documentation/Implementation/00-Overview/Migration-Overview.md", "extension": "md", "score": 52, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Document ID:** EXPO-OVERVIEW-001 **Version:** 1.0.0 **Created:** 2026-01-04 **Status:** ACTIVE **Parent Document:** README.md", "excerpt": "**Document ID:** EXPO-OVERVIEW-001 **Version:** 1.0.0 **Created:** 2026-01-04 **Status:** ACTIVE **Parent Document:** README.md\n\nThis document provides a high-level overview of the migration strategy for converting the **Milk Men** iOS application from Swift/SwiftUI to Expo (React Native).\n\n**Primary Goal:** Achieve complete feature parity with the Swift iOS application while establishing a foundation for future Android and Web deployment.\n\n**Secondary Goals:** - Leverage JavaScript/TypeScript developer ecosystem - Maintain or exceed Swift app performance and UX - Preserve all existing Supabase backend infrastructure - Enable parallel development without disrupting production\n\n### 1. Platform Expansion Readiness - **Current State:** iOS-only (Swift/SwiftUI) - **Future State:** iOS (initial), Android, Web (architecture-ready) - **Benefit:** Single codebase for multiple platforms reduces long-term maintenance", "htmlHref": "/research/html/expo-migration-overview-hbwhcp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1861 }, { "id": "lume-full-system-goals-execution-prompt-p4cby0", "title": "LUME Full System Goals Execution Prompt", "slug": "lume-full-system-goals-execution-prompt", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/lume-wiring/lume-full-system-goals-execution-prompt-current.md", "extension": "md", "score": 52, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Use this prompt when handing the LUME project to another agent or resuming after a break. The job is not to invent a new architecture. The job is to continue the existing one, preserve the safety boundaries, and drive the system toward the first real multi-device capture, reconstruction, and learning loop.", "excerpt": "Use this prompt when handing the LUME project to another agent or resuming after a break. The job is not to invent a new architecture. The job is to continue the existing one, preserve the safety boundaries, and drive the system toward the first real multi-device capture, reconstruction, and learning loop.\n\nContinue building the full LUME computational choreography system as a local, Tailscale-connected, multi-device performance stack. The system must convert real body evidence into safe DJ control, visual response, music adaptation, reconstruction, semantic memory, and future generated control curves without confusing evidence, command authority, and learned interpretation.\n\nThe current immediate task is to keep writing, hardening, and clarifying this execution surface while Mohamed is away, then be ready to run the home-return validation path when the physical devices are positioned again.\n\nBefore claiming progress, inspect the relevant report instead of relying on this prose.\n\nReports can drift because some are summaries of other reports, and remote parity copies/readbacks can lag behind local updates. When reports disagree, use this procedure before changing claims in this file.", "htmlHref": "/research/html/lume-full-system-goals-execution-prompt-p4cby0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 21511 }, { "id": "governed-self-correction-for-low-resource-nko-asr-a-technical-report-on-the-acoustic-v-nhz2i", "title": "Governed Self-Correction for Low-Resource N'Ko ASR: A Technical Report on the Acoustic Verifier Experiment", "slug": "governed-self-correction-for-low-resource-nko-asr-a-technical-report-on-the-acoustic-verifier-experiment", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/TECHNICAL-REPORT.md", "extension": "md", "score": 52, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2026-06-01 **Author:** Mohamed Diomande **Status:** Component-characterized; loop not yet closed. Preservation/data-selection signal confirmed (clean preservation AUC 0.739; original 297k/ANE pilot AUC 0.923 was inflated); live acoustic correction is capped (absolute proposal plausibility AUC 0.60); proposal quality identified as the main bottleneck. **Scope:** This report documents the full experimental chain from the AGP correction benchmark through the acoustic verifier, including every measured number", "excerpt": "# Governed Self-Correction for Low-Resource N'Ko ASR: A Technical Report on the Acoustic Verifier Experiment\n\n**Date:** 2026-06-01 **Author:** Mohamed Diomande **Status:** Component-characterized; loop not yet closed. Preservation/data-selection signal confirmed (clean preservation AUC 0.739; original 297k/ANE pilot AUC 0.923 was inflated); live acoustic correction is capped (absolute proposal plausibility AUC 0.60); proposal quality identified as the main bottleneck. **Scope:** This report documents the full experimental chain from the AGP correction benchmark through the acoustic verifier, including every measured number, every dead end, and the precise wiring required to reproduce it.\n\nThe N'Ko speech program set out to build a **self-improving correction loop**: an ASR model decodes audio to toneless N'Ko, a language model proposes corrections, a governance gate accepts only admissible corrections, and the accepted/rejected pairs are recycled as training data. This report covers the experimental campaign that tested whether that loop closes.\n\n1. **An ungoverned LLM corrector is catastrophic to a low-resource transcript.** Blind acceptance of a Gemma-3n correction model moved CER from 0.3106 to 0.4701 (**+15.94pp worse**) on a 500-row real-proposal benchmark. The governance gate neutralized this to +0.14pp (a 99% reduction of harm). Governance *preserves*.\n\n2. **No text-internal signal can build a correctness gate.** Across trajectory scalars, n-best consensus, and character posteriors, the area-under-curve for predicting whether a proposed edit actually lowers CER was ~0.50 (chance). Good edits and bad edits are statistically indistinguishable from the text side. This was proven conclusively, not assumed.", "htmlHref": "/research/html/governed-self-correction-for-low-resource-nko-asr-a-technical-report-on-the-acoustic-v-nhz2i.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 5868 }, { "id": "1-what-the-rust-runtime-is-and-isn-t-16uttf5", "title": "1. What the Rust runtime *is* and *isn’t*", "slug": "1-what-the-rust-runtime-is-and-isn-t", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/echelon/Echelon.md", "extension": "md", "score": 52, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Rust is a great fit if you want a **Serato-class, DAW-style instrument** with hard real-time guarantees and a modern, safe codebase. Here’s what the stack would look like when you build it “the Rust way”—clean boundaries, no allocations in the audio callback, and room for motion/voice/AI without ever risking a glitch.", "excerpt": "Rust is a great fit if you want a **Serato-class, DAW-style instrument** with hard real-time guarantees and a modern, safe codebase. Here’s what the stack would look like when you build it “the Rust way”—clean boundaries, no allocations in the audio callback, and room for motion/voice/AI without ever risking a glitch.\n\n* The **audio thread** never allocates, never locks. All heavy work (ASR, diffusion, ANN search, file decode) runs **off-thread** and streams results via lock-free ring buffers. * **Quantization & safety** live in the scheduler: it accepts intents from voice/motion/UI, decides *when* (beat-aligned), and turns them into parameter ramps/MIDI envelopes for the engine. * The **AI sidecars** are optional processes; if they stall, the engine keeps playing.\n\n* **Audio I/O**: `cpal` or `cubeb` (via `cubeb-rs`) for cross-platform CoreAudio / WASAPI / JACK; for pro ASIO you can FFI a minimal ASIO backend on Windows. * **DSP graph**: build on a lock-free node graph (e.g., `knyst`, or your own over `atomic_arena` + `ringbuf`). Nodes are preallocated; connections are SPSC queues. * **FFT/analysis**: `rustfft` / `realfft` for STFT; `symond` or your own feature extractors; `symphonia` for decoding (mp3/flac/wav). * **Resample**: `rubato` (hi-quality resampler); for **time-stretch/key shift** use FFI to `Rubber Band` or `SoundTouch` (battle-tested), wrapped in a non-allocating adaptor. * **MIDI**: `midir` (I/O, virtual ports). * **OSC**: `rosc` (if you want external control/visuals). * **Clock**: Ableton Link—use a tiny C FFI to the Link SDK or a Rust binding; expose a `BeatClock { bpm, phase, quantum }` to both scheduler and engine. * **GUI**: `egui` (fast immediate-mode) or `iced` with `wgpu` renderer; audio engine talks to GUI via lock-free ring buffers. * **NLU/ASR**: `whisper-rs` (ggml) on CPU/GPU for low-latency commands; or `vosk` bindings. * **ML (diffusion/flow)**: `candle` (HF’s Rust ML) or `burn` for inference in a **separate process**; communicate over shared memory/IPC with pre-roll buffers. * **ANN / phrase DB**: `tantivy` + `sqlite` for metadata; `hnsw_rs` or an external vector DB (Qdrant) for fast similarity over CLAP/feature embeddings.\n\n* **Backends**: compiled per-platform; you pick CoreAudio/JACK/ASIO at runtime. * **Graph**: nodes = *ClipPlayer*, *StemGate*, *RubberBandTS*, *EQ*, *Filter*, *FX*, *Mixer*, *Limiter*. * **Scheduling**: automation events (gain/EQ/crossfader/FX) arrive as beat-quantized envelopes; the engine converts them to per-block parameter ramps. * **Stems**: a stem node can mute/solo parts with zero-cross alignment; for Serato-style “stems FX”, precompute masks offline and apply fast spectral gating in block-aligned windows.\n\n* Wrap Rubber Band (graceful, musical) via FFI; expose: `set_ratio(time_ratio)`, `set_se", "htmlHref": "/research/html/1-what-the-rust-runtime-is-and-isn-t-16uttf5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 10413 }, { "id": "serenity-soother-backend-architecture-at2m6w", "title": "Serenity Soother - Backend Architecture", "slug": "serenity-soother-backend-architecture", "kind": "architecture", "program": "Research Backlog", "sourceAnchor": "Serenity Soother/SerenitySoother/Documentation/ARCHITECTURE.md", "extension": "md", "score": 52, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` ┌─────────────────────────────────────────────────────────────────────────────────┐ │ PREPROCESSING PHASE │ │ (One-time, before app deployment) │ ├─────────────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌─────────────────┐ ┌──────────────────────┐ │ │ │ 3,344 Images │───────▶│ Python Script │───────▶│ Processed JSON │ │ │ │ (1792x1024) │ │ (Local/Cloud) │ │ + Clusters │ │ │ └──────────────┘ └────────┬────────┘ └──────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────", "excerpt": "| Computation | Location | When | Cost | |-------------|----------|------|------| | **Image Object Detection** | Google Cloud (Gemini) | Preprocessing | ~$0.001/image | | **Therapeutic Scoring** | Google Cloud (Gemini) | Preprocessing | Included above | | **Cluster Building** | Local (Python) | Preprocessing | Free | | **World Generation** | On-device (Swift) | Runtime | Free | | **Semantic Search** | On-device (NLEmbedding) | Runtime | Free | | **Script Generation** | Google Cloud (Gemini) | Runtime | ~$0.01/script | | **New Image Analysis** | Google Cloud (Gemini) | Runtime | ~$0.001/image | | **Data Persistence** | On-device (SwiftData) | Runtime | Free |\n\n| Feature | Offline Support | |---------|-----------------| | World browsing | ✅ Full | | Scene viewing | ✅ Full (bundled images) | | World generation | ✅ Full (uses bundled JSON) | | Semantic search | ✅ Full (NLEmbedding on-device) | | Script generation | ❌ Requires internet | | New image analysis | ❌ Requires internet | | Collaborative sync | ❌ Requires internet |\n\nThis would reduce client-side API costs and enable real-time collaboration features.", "htmlHref": "/research/html/serenity-soother-backend-architecture-at2m6w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3198 }, { "id": "cc-handguard-shared-latent-stream-architecture-1le0jeh", "title": "cc-handguard: Shared Latent Stream Architecture", "slug": "cc-handguard-shared-latent-stream-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/apps/ios/cc-handguard/SHARED_LATENT_ARCHITECTURE.md", "extension": "md", "score": 50, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Issues**: - ❌ Double battery drain on watch - ❌ Two separate upload streams - ❌ Two device IDs in backend - ❌ Two latent computations for same physical motion - ❌ Wasteful and redundant", "excerpt": "**Issues**: - ❌ Double battery drain on watch - ❌ Two separate upload streams - ❌ Two device IDs in backend - ❌ Two latent computations for same physical motion - ❌ Wasteful and redundant\n\n**Benefits**: - ✅ Single sensor stream (50% battery savings) - ✅ Single upload stream (50% network savings) - ✅ One device_id in backend - ✅ Same z(t) latent state for all policies - ✅ True \"latent-first\" philosophy - ✅ Can run multiple policy apps simultaneously\n\n**Concept**: EchelonCapture already uploads sensors. Add a local broadcast so HandGuard can subscribe.\n\n**EchelonCapture** (minimal): 1. Add local WebSocket server on port 9001 2. Broadcast latent states locally 3. ~50 lines of code\n\n**HandGuard**: 1. Change `CCLatentSubscriber` to connect to `ws://[ip]:9001` instead of cloud 2. Remove `CCBridgeManager` (no upload needed) 3. Keep `HandGuardPolicy` and intervention logic 4. ~30 lines changed", "htmlHref": "/research/html/cc-handguard-shared-latent-stream-architecture-1le0jeh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1160 }, { "id": "cc-motiongen-technical-documentation-1pvbh0z", "title": "CC-MotionGen Technical Documentation", "slug": "cc-motiongen-technical-documentation", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/ml/cc-ml/cc_motiongen/TECHNICAL_DOCUMENTATION.md", "extension": "md", "score": 50, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "CC-MotionGen is a state-of-the-art diffusion-based model for generating temporally coherent motion trajectories conditioned on audio features. The system comprises a 116M parameter UNet1D diffusion backbone, a 2M parameter motion decoder, and a comprehensive post-processing pipeline designed for real-time choreography synthesis.", "excerpt": "> **Version:** 0.2.0 > **Last Updated:** December 2025 > **Authors:** Comp-Core ML Team\n\nCC-MotionGen is a state-of-the-art diffusion-based model for generating temporally coherent motion trajectories conditioned on audio features. The system comprises a 116M parameter UNet1D diffusion backbone, a 2M parameter motion decoder, and a comprehensive post-processing pipeline designed for real-time choreography synthesis.\n\n**Key Capabilities:** - Audio-synchronized motion generation at 30fps - 25-dimensional motion representation (position, velocity, orientation, phase, style) - End-to-end differentiable pipeline for temporal coherence - Scalable inference via DDIM sampling (20 steps vs 1000 DDPM)\n\n1. [System Architecture](#1-system-architecture) 2. [Motion Representation Format](#2-motion-representation-format) 3. [Model Components Deep Dive](#3-model-components-deep-dive) 4. [Audio Feature Extraction](#4-audio-feature-extraction) 5. [Diffusion Process Mathematics](#5-diffusion-process-mathematics) 6. [Training Pipeline](#6-training-pipeline) 7. [End-to-End Fine-tuning](#7-end-to-end-fine-tuning) 8. [Inference & Sampling](#8-inference--sampling) 9. [Post-Processing Pipeline](#9-post-processing-pipeline) 10. [Validation & Sanity Checks](#10-validation--sanity-checks) 11. [Configuration Reference](#11-configuration-reference) 12. [API Reference](#12-api-reference) 13. [Performance & Benchmarks](#13-performance--benchmarks) 14. [Troubleshooting Guide](#14-troubleshooting-guide) 15. [Known Issues & Roadmap](#15-known-issues--roadmap)\n\nThe base diffusion model learns a latent representation optimized for noise prediction, not motion semantics. E2E fine-tuning addresses this by:", "htmlHref": "/research/html/cc-motiongen-technical-documentation-1pvbh0z.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 8693 }, { "id": "cc-event-sourcing-specification-1inlxeg", "title": "cc-event-sourcing Specification", "slug": "cc-event-sourcing-specification", "kind": "proposal", "program": "Business Systems", "sourceAnchor": "Comp-Core/packages/cc-event-sourcing/SPEC.md", "extension": "md", "score": 50, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This specification defines the event sourcing patterns used across Comp-Core projects. Event sourcing captures all changes to application state as a sequence of immutable events, enabling:", "excerpt": "This specification defines the event sourcing patterns used across Comp-Core projects. Event sourcing captures all changes to application state as a sequence of immutable events, enabling:\n\n- **Complete audit trails** — Every state change is recorded - **Time-travel debugging** — Replay events to reconstruct past states - **Temporal queries** — Query state at any point in time - **Event-driven architectures** — React to events across system boundaries\n\nExamples: - `user.created` - `user.email.changed` - `order.item.added` - `payment.refunded`\n\n**Rules:** - Use lowercase with dots as separators - Use past tense for actions (created, updated, deleted) - Be specific and descriptive\n\nEvents MUST use UUIDv7 for IDs to ensure: - Global uniqueness - Temporal sortability - No coordination required", "htmlHref": "/research/html/cc-event-sourcing-specification-1inlxeg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": true, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1951 }, { "id": "performance-prophet-qk1diq", "title": "Performance Prophet", "slug": "performance-prophet", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/performance-prophet/SKILL.md", "extension": "md", "score": 50, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "ML-powered system that predicts slowdowns before users notice. Uses statistical models and anomaly detection to forecast performance degradation and alert proactively.", "excerpt": "ML-powered system that predicts slowdowns before users notice. Uses statistical models and anomaly detection to forecast performance degradation and alert proactively.\n\nTraditional monitoring alerts when thresholds are crossed. By then, users already feel the pain. Performance Prophet flips this: it learns your system's patterns and alerts *before* degradation becomes noticeable.\n\n- **Triple Exponential Smoothing** — Captures level, trend, and seasonality - **Anomaly Detection** — IQR-based + Z-score for outliers - **Trend Extrapolation** — Predicts where metrics are heading - **Pattern Memory** — Learns daily/weekly cycles - **Proactive Alerts** — Warning before threshold breach\n\n| Metric | Source | Warning Sign | |--------|--------|--------------| | Response Time | API logs | Upward trend | | Memory Usage | System | > 80% predicted | | Queue Depth | Workers | Growing backlog | | Error Rate | Logs | Spike detection | | CPU Usage | System | Sustained climb | | Disk I/O | System | Saturation approach |\n\n### 1. Holt-Winters (Triple Exponential Smoothing) Best for metrics with seasonality (traffic patterns, daily cycles).", "htmlHref": "/research/html/performance-prophet-qk1diq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 13944 }, { "id": "invariants-rules-that-must-never-be-violated-xd26zm", "title": "Invariants — Rules That Must Never Be Violated", "slug": "invariants-rules-that-must-never-be-violated", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "LUME-CC/09-reference/invariants.md", "extension": "md", "score": 50, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "These constraints are drawn from all three documentation sets (Set A implementation, Set B AirDeck/camera-first, Set C Mac4 manuscript). Violation causes either system failure, safety risk, or loss of artistic integrity.", "excerpt": "These constraints are drawn from all three documentation sets (Set A implementation, Set B AirDeck/camera-first, Set C Mac4 manuscript). Violation causes either system failure, safety risk, or loss of artistic integrity.\n\n**I-1: Only K11 sends Rekordbox commands.** Unity, mocopi, Mac4 browser, MotionMix, iPhones, and Watch must not directly dispatch Rekordbox keyboard or MIDI events. K11's command gate is the sole authority.\n\n**I-2: No gesture becomes live without promotion.** A newly detected gesture cannot fire a Rekordbox command without passing through the full promotion pipeline (physical capture → capture gate → self-play → proof matrix → promotion manifest loaded by K11 bridge). Exception: left hand raise (deck 1) and right hand raise (deck 2) are baseline proven gestures and may remain live.\n\n**I-3: EchelonHandle is MainActor-only.** The Rust FFI handle must only be accessed from Swift's MainActor. Any other thread produces undefined behavior in the Rust core.\n\n**I-4: AudioHandle is audio-thread-only.** `renderAudio()` must never be called from MainActor. The audio thread is real-time; any allocation or GC pause causes audible glitches.", "htmlHref": "/research/html/invariants-rules-that-must-never-be-violated-xd26zm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 731 }, { "id": "architecture-mcxmv", "title": "Architecture", "slug": "architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/pane-awareness/ARCHITECTURE.md", "extension": "md", "score": 50, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "pane-awareness is a coordination layer that runs alongside AI coding sessions. Each session writes its state to shared JSON files, and reads other sessions' state to make coordination decisions.", "excerpt": "pane-awareness is a coordination layer that runs alongside AI coding sessions. Each session writes its state to shared JSON files, and reads other sessions' state to make coordination decisions.\n\nNo server, no database, no daemon. Sessions coordinate through locked JSON files on the local filesystem. This makes the system:\n\n- **Zero-dependency** — nothing to install beyond Python - **Zero-configuration** — works out of the box - **Crash-resilient** — stale panes auto-expire, no orphan processes - **Portable** — works on macOS, Linux, and Windows\n\n1. Lowercase and tokenize the prompt 2. Remove stop words (configurable set of ~80 common words + convergence noise words) 3. Remove identity noise (username, hostname, configurable extras) 4. Deduplicate and take top N by frequency in the prompt 5. Store in trajectory window (rolling last 10 prompt snapshots)\n\n- **deepening**: Appears in 60%+ of recent prompts AND frequency is increasing - **emerging**: Appears only in the last 3 prompts (new topic) - **fading**: Was present in older prompts but absent from the last 3 - **stable**: Consistent presence without significant trend", "htmlHref": "/research/html/architecture-mcxmv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 942 }, { "id": "speakd-v1-0-architecture-1ljyrtq", "title": "speakd v1.0 — Architecture", "slug": "speakd-v1-0-architecture", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "speakd/ARCHITECTURE.md", "extension": "md", "score": 50, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` ┌─────────────────────────────────┐ │ Fn Key Pressed │ │ (CGEvent tap + poll detect) │ └────────────────┬────────────────┘ │ ┌────────────────▼────────────────┐ │ 96kHz Audio Capture (cpal) │ │ Built-in mic preferred over │ │ Continuity/iPhone │ └────────────────┬────────────────┘ │ ┌────────────────▼────────────────┐ │ Fn Key Released │ │ (poll detects within 100ms) │ └────────────────┬────────────────┘ │ ┌────────────────▼────────────────┐ │ WAV Encoding (hound crate) │ │ Native rate, 16-bit mono │ └─────────", "excerpt": "| Mode | Activation | Stop | Use Case | |------|-----------|------|----------| | Hold | Hold Fn | Release Fn | Quick dictation (<30s) | | Toggle | Fn + Space | Press Fn again | Long dictation, meetings |\n\n| Event | Sound | Timing | |-------|-------|--------| | Recording starts | Tink.aiff | Immediate on Fn press | | Mode switch (hold→toggle) | Morse.aiff | On Space press during hold | | Recording stops | Pop.aiff | On Fn release / toggle stop | | Transcription complete | macOS notification | After paste |\n\n| Failure | Detection | Recovery | |---------|-----------|----------| | Mac4 relay down | 3s connect timeout | Skip to next tier | | Mac4 transcription crash | HTTP connection reset | Skip to cloud | | OpenAI API key invalid | 401 response | Skip to local | | OpenAI rate limited | 429 response | Skip to local | | No internet | All cloud timeouts | Local on-device | | Tailscale down | All mesh timeouts | Cloud → local | | Mic disconnected | Empty audio buffer | \"Too short\" message | | Audio device change | cpal error callback | Needs restart (future: auto-reconnect) | | Local binary missing | File check | Auto-compile from embedded Swift source |\n\n| Step | Hold Mode | Toggle Mode | |------|-----------|-------------| | Fn detection | <1ms | <1ms | | Audio capture | real-time | real-time | | Fn release detection | ~100ms (poll) | ~100ms | | WAV encoding | ~10ms | ~10ms | | **Mac4 transcription** | **~700ms** | **~700ms** | | Punctuation (nano) | ~200ms | ~200ms | | Paste (pbcopy+Cmd+V) | ~50ms | ~50ms | | **Total (Mac4 path)** | **~1.1s** | **~1.1s** | | **Total (OpenAI path)** | **~3.5s** | **~3.5s** | | **Total (local path)** | **~2.0s** | **~2.0s** |\n\n| Component | Status | Notes | |-----------|--------|-------| | Fn hold-to-record | LIVE | Polling fallback for Apple Silicon | | Fn+Space toggle | LIVE | For long dictation | | Mac4 SFSpeechRecognizer relay | LIVE | 0.7s, free, LaunchAgent | | Mac4 SpeechTranscriber relay | WIRED | Needs model download on Mac4 | | Mac2 relay | NOT BUILT | Same architecture, deploy when needed | | Mac5 MLX Whisper | NOT CONFIGURED | Need whisper endpoint at :8100 | | OpenAI Whisper | LIVE | Fallback, $0.006/min | | Local on-device | LIVE | Auto-compiles Swift binary | | GPT-5.4-nano punctuation | LIVE | For unpunctuated sources | | History DB | LIVE | SQLite, CLI search | | Post-processing | LIVE | Knowledge chain + smart notes | | MenuBar UI | PENDING | Next major feature | | Voice isolation (noise cancel) | PENDING | Needs AVAudioEngine in Swift layer |", "htmlHref": "/research/html/speakd-v1-0-architecture-1ljyrtq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 918 }, { "id": "agentos-system-architecture-13qpc2j", "title": "AgentOS — System Architecture", "slug": "agentos-system-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "unified-agent-os/ARCHITECTURE.md", "extension": "md", "score": 50, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ AgentOS Platform │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Dashboard │ │ CLI │ │ SDK │ │ Webhooks │ │ │ │ (Next.js) │ │ (agentos) │ │ (npm pkg) │ │ (inbound) │ │ │ └──────┬───────┘ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ │ ═══════╪═════════════════╪═════════════════╪═════════════════╪══════════ │ │ │ API Gateway (Hono) │ │ │ │ │ ┌──────────────────────────────────┐ │ │ │ └─", "excerpt": "| Layer | Isolation Method | |-------|-----------------| | **Database** | Row-Level Security (RLS) — every table has `tenant_id`; policies enforce `auth.uid()` → `tenant_id` mapping | | **Compute** | Session-level isolation — each session runs in sandboxed context with tenant-scoped filesystem | | **Secrets** | Vault per tenant — encrypted at rest; decrypted only in session runtime | | **Events** | Channel-per-tenant — Redis channels namespaced by `tenant:{id}:*` | | **Storage** | Prefix-per-tenant — `{tenant_id}/` prefix in object storage | | **API** | Middleware injection — `req.tenantId` set by auth; all queries scoped automatically |\n\n| Feature | Free | Pro ($49/mo) | Enterprise (Custom) | |---------|------|-------------|---------------------| | Concurrent sessions | 2 | 20 | Unlimited | | Session duration | 5 min | 30 min | Unlimited | | Heartbeat checks | 5 | 50 | Unlimited | | Dream garden | 10 dreams | 100 dreams | Unlimited | | Skills | Public only | Public + private | Custom + self-hosted | | Model providers | 1 | Unlimited | Unlimited | | Team members | 1 | 10 | Unlimited | | Support | Community | Email | Dedicated | | SLA | None | 99.9% | 99.99% | | Token budget/mo | 1M | 50M | Custom |\n\n| Metric | Rate | |--------|------| | Tokens (pass-through + 15% markup) | Provider cost × 1.15 | | Session compute (per min) | $0.005/min | | Storage (per GB/mo) | $0.10/GB | | API calls (over tier limit) | $0.001/call |", "htmlHref": "/research/html/agentos-system-architecture-13qpc2j.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1799 }, { "id": "trajectoryos-desktop-architecture-1itk3nr", "title": "TrajectoryOS Desktop Architecture", "slug": "trajectoryos-desktop-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/apps/trajectory/trajectory-desktop/docs/legacy/ARCHITECTURE.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "TrajectoryOS Desktop is a Tauri-based application that serves as the unified control center for personal trajectory management. The application combines life state physics modeling, skill tracking with decay algorithms, voice capture integration, and text-to-speech capabilities into a cohesive desktop experience. The system operates on a local-first architecture where all data remains on the user's machine, synchronized through SQLite databases and connected via the Model Context Protocol for external tool integrat", "excerpt": "TrajectoryOS Desktop is a Tauri-based application that serves as the unified control center for personal trajectory management. The application combines life state physics modeling, skill tracking with decay algorithms, voice capture integration, and text-to-speech capabilities into a cohesive desktop experience. The system operates on a local-first architecture where all data remains on the user's machine, synchronized through SQLite databases and connected via the Model Context Protocol for external tool integration.\n\nThe application is built using Rust for the backend runtime and React with TypeScript for the frontend interface. Tauri provides the bridge between these two worlds, exposing Rust functions as invokable commands that the frontend can call asynchronously. This architecture enables native performance for compute-intensive operations like physics calculations while maintaining the flexibility of a modern web-based user interface.\n\nAt the core of TrajectoryOS lies a physics-based model of personal progress. The system conceptualizes an individual's life trajectory as a particle moving through a gravitational field, where escape velocity represents the threshold needed to break free from stagnation and achieve meaningful progress. The escape index quantifies how close one is to achieving this velocity, computed from three primary forces.\n\nThrust represents the positive momentum generated through deliberate action, skill development, and goal achievement. The system calculates thrust by aggregating contributions from active skills, completed milestones, and positive life events. Each skill contributes thrust proportional to its level multiplied by an alignment factor that measures how well the skill serves the user's declared objectives.\n\nGravity embodies the resistive forces that impede progress. This includes skill decay over time, unresolved blockers, missed deadlines, and the accumulated weight of incomplete goals. The gravity calculation considers both the magnitude of these impediments and their temporal proximity, with recent negative events contributing more strongly than distant ones.", "htmlHref": "/research/html/trajectoryos-desktop-architecture-1itk3nr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3182 }, { "id": "convo-6dloon", "title": "convo", "slug": "convo", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/guides/convo.md", "extension": "md", "score": 48, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Then we’ll combine them into one number: a “Escape Index”. If that number is below 1, you’re stuck in orbit. When it crosses 1, you’ve hit escape velocity in life-terms.", "excerpt": "Yeah, let’s turn this into an actual little “life physics” model instead of just vibes.\n\nI’ll build a simple mathematical toy, but in human language so you can actually use it.\n\nGravity = everything that pulls you back down: bills, chaos, doubt, distraction, obligations.\n\nMass = how heavy your life-rocket is: responsibilities, number of projects, people depending on you.\n\nThen we’ll combine them into one number: a “Escape Index”. If that number is below 1, you’re stuck in orbit. When it crosses 1, you’ve hit escape velocity in life-terms.", "htmlHref": "/research/html/convo-6dloon.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 14077 }, { "id": "how-rcp-enhances-tpo-dataset-generation-tjbnsw", "title": "How RCP Enhances TPO Dataset Generation", "slug": "how-rcp-enhances-tpo-dataset-generation", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/HOW_RCP_ENHANCES_TPO_DATASET_GENERATION.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Ring Contextual Propagation (RCP) significantly enhances TPO's dataset generation capabilities by providing spatial intelligence, cross-conversation analysis, and advanced pattern detection. Instead of TPO's traditional linear path analysis, RCP enables TPO to understand complex conversation dynamics and generate more sophisticated preference datasets.", "excerpt": "Ring Contextual Propagation (RCP) significantly enhances TPO's dataset generation capabilities by providing spatial intelligence, cross-conversation analysis, and advanced pattern detection. Instead of TPO's traditional linear path analysis, RCP enables TPO to understand complex conversation dynamics and generate more sophisticated preference datasets.\n\n#### **4D Coordinate System** RCP provides TPO with a 4-dimensional spatial representation of conversations: - **x-coordinate**: Hierarchical depth in conversation tree - **y-coordinate**: Sibling order among messages at same level - **z-coordinate**: Semantic homogeneity relative to siblings - **t-coordinate**: Normalized temporal position\n\n**Impact**: Preferences between spatially similar conversation paths receive higher confidence scores, leading to more reliable training data.\n\n#### **Triangular Connection Detection** RCP detects when users copy assistant responses and use them as prompts (triangular patterns):\n\n#### **Knowledge Elevation Detection** RCP identifies when knowledge from deeper conversation levels is brought to shallower levels:", "htmlHref": "/research/html/how-rcp-enhances-tpo-dataset-generation-tjbnsw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1391 }, { "id": "ircp-optimization-strategy-beyond-traditional-preference-optimization-130iziq", "title": "IRCP Optimization Strategy: Beyond Traditional Preference Optimization", "slug": "ircp-optimization-strategy-beyond-traditional-preference-optimization", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/OPTIMIZATION_STRATEGY_ANALYSIS.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**IRCP is NOT just another optimizer** - it's a fundamentally different mathematical framework that inverts the traditional learning paradigm. While TPO, DPO, and GRPO optimize for P(v|u) (assistant response given user input), **IRCP optimizes for P(u|v) - the inverse mapping that models how users respond to assistant messages**.", "excerpt": "**IRCP is NOT just another optimizer** - it's a fundamentally different mathematical framework that inverts the traditional learning paradigm. While TPO, DPO, and GRPO optimize for P(v|u) (assistant response given user input), **IRCP optimizes for P(u|v) - the inverse mapping that models how users respond to assistant messages**.\n\nThis inversion enables **individual response pattern modeling** rather than generic response generation.\n\n- **Objective**: Optimize policy to prefer better responses - **Data**: Human preference annotations - **Limitation**: Static preferences, no individual modeling\n\n- **Objective**: Optimize relative to group performance - **Data**: Group-based reward signals - **Limitation**: Group-level optimization, not individual\n\n- **Objective**: Use conversation topology for preferences - **Data**: Structural conversation properties - **Innovation**: Automated preference generation from topology", "htmlHref": "/research/html/ircp-optimization-strategy-beyond-traditional-preference-optimization-130iziq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 930 }, { "id": "ircp-optimization-strategy-beyond-traditional-preference-optimization-rd5h87", "title": "IRCP Optimization Strategy: Beyond Traditional Preference Optimization", "slug": "ircp-optimization-strategy-beyond-traditional-preference-optimization", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/outputs/OPTIMIZATION_STRATEGY_ANALYSIS.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**IRCP is NOT just another optimizer** - it's a fundamentally different mathematical framework that inverts the traditional learning paradigm. While TPO, DPO, and GRPO optimize for P(v|u) (assistant response given user input), **IRCP optimizes for P(u|v) - the inverse mapping that models how users respond to assistant messages**.", "excerpt": "**IRCP is NOT just another optimizer** - it's a fundamentally different mathematical framework that inverts the traditional learning paradigm. While TPO, DPO, and GRPO optimize for P(v|u) (assistant response given user input), **IRCP optimizes for P(u|v) - the inverse mapping that models how users respond to assistant messages**.\n\nThis inversion enables **individual response pattern modeling** rather than generic response generation.\n\n- **Objective**: Optimize policy to prefer better responses - **Data**: Human preference annotations - **Limitation**: Static preferences, no individual modeling\n\n- **Objective**: Optimize relative to group performance - **Data**: Group-based reward signals - **Limitation**: Group-level optimization, not individual\n\n- **Objective**: Use conversation topology for preferences - **Data**: Structural conversation properties - **Innovation**: Automated preference generation from topology", "htmlHref": "/research/html/ircp-optimization-strategy-beyond-traditional-preference-optimization-rd5h87.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 930 }, { "id": "real-ircp-model-performance-with-claude-data-verified-metrics-1scc0h9", "title": "🎯 REAL IRCP Model Performance with Claude Data - VERIFIED METRICS", "slug": "real-ircp-model-performance-with-claude-data-verified-metrics", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/outputs/REAL_CLAUDE_MODEL_PERFORMANCE.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "You were absolutely right to question the previous metrics. I had made several errors: 1. **Inflated similarity scores** - I incorrectly reported 76.95% when real max is ~80.17% 2. **Inflated search scores** - I reported 53.49% when real max is ~44.81% 3. **Understated conversation count** - Only tested 20 conversations when you have **891 total** 4. **Root directory mess** - Now organized into proper folders", "excerpt": "You were absolutely right to question the previous metrics. I had made several errors: 1. **Inflated similarity scores** - I incorrectly reported 76.95% when real max is ~80.17% 2. **Inflated search scores** - I reported 53.49% when real max is ~44.81% 3. **Understated conversation count** - Only tested 20 conversations when you have **891 total** 4. **Root directory mess** - Now organized into proper folders\n\n### 🔢 **Actual Dataset Size** - **Total Conversations Available**: **891 conversations** (not 20!) - **Processed for Testing**: 100 conversations, 2,698 messages - **Average Messages per Conversation**: 26.98 - **Average Tokens per Message**: 396.06 - **Coordinate Coverage**: 100% (all messages have coordinates)\n\n### 🔍 **REAL Similarity Analysis Results** - **Max Similarity Found**: **0.8426** (84.26%) - between similar coding responses - **Mean Similarity**: **0.1576** (15.76%) - typical background similarity - **Standard Deviation**: **0.1649** - good distribution of similarities - **Sample Size**: 50 messages, 1,225 message pairs analyzed\n\n**Top Real Examples**: 1. **84.26% similarity**: Two assistant responses about calculator enhancement 2. **78.68% similarity**: Related savings calculator updates 3. **78.67% similarity**: Component updates in same conversation\n\n### 🔍 **REAL Semantic Search Performance** - **\"React component development\"**: **0.4481** (44.81%) - found actual React code - **\"Database optimization\"**: **0.3832** (38.32%) - found profit optimization - **\"User interface design\"**: **0.4052** (40.52%) - found design discussions - **\"Performance improvement\"**: **0.4330** (43.30%) - found enhancement requests - **\"API error handling\"**: **0.2044** (20.44%) - lower but still relevant", "htmlHref": "/research/html/real-ircp-model-performance-with-claude-data-verified-metrics-1scc0h9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 774 }, { "id": "rcp-enhanced-tpo-preference-dataset-generation-complete-4rdtq4", "title": "🎉 RCP-Enhanced TPO Preference Dataset Generation - COMPLETE", "slug": "rcp-enhanced-tpo-preference-dataset-generation-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/PREFERENCE_DATASET_GENERATION_SUMMARY.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "✅ Experimental Exploration: 8,026 detected - Multi-branch diverse approaches - Parent-child experimental patterns - Diversity scoring and analysis ```", "excerpt": "### **Dataset Overview** - ✅ **Total Conversations Processed**: 277 conversations - ✅ **Total Messages Analyzed**: 60,534 messages - ✅ **Total Preferences Generated**: 13,666 preference pairs - ✅ **100% RCP-Enhanced**: All preferences generated using RCP spatial intelligence - ✅ **Dataset Size**: ~70MB across 43 batch files - ✅ **Processing Success**: Complete dataset generation achieved\n\n### **RCP Enhancement Breakdown** | Strategy Type | Count | Percentage | Description | |---------------|-------|------------|-------------| | **Experimental Exploration** | 8,026 | 58.7% | Multi-branch experimental approaches detected | | **Knowledge Transfer Triangular** | 5,640 | 41.3% | Model response → User prompt patterns detected | | **Total RCP Preferences** | 13,666 | 100% | All preferences use RCP spatial intelligence |\n\nThe consistent \"0 paths: 0 linear, 0 branching\" in traditional TPO is **expected and correct** because:\n\n### **1. Complex Conversation Structure** - Our conversations have deep hierarchical branching (up to depth 102+) - Traditional TPO expects simpler linear conversation paths - RCP handles complex multi-dimensional conversation topology\n\n### **2. RCP Superiority** - **Traditional TPO**: Looks for simple linear vs branching path comparisons - **RCP-Enhanced TPO**: Detects sophisticated patterns like: - Triangular knowledge transfer (user copies assistant response as new prompt) - Experimental branching (multiple diverse approaches from same parent) - Cross-conversation knowledge transfer - Spatial similarity weighting", "htmlHref": "/research/html/rcp-enhanced-tpo-preference-dataset-generation-complete-4rdtq4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 993 }, { "id": "smart-architecture-stratified-monotone-action-runtime-for-trajectoryos-10up64o", "title": "SMART Architecture: Stratified Monotone Action Runtime for TrajectoryOS", "slug": "smart-architecture-stratified-monotone-action-runtime-for-trajectoryos", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/docs/SMART_ARCHITECTURE.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> **Contract Statement**: Orbit grants capability, FunctionGemma proposes, RAG++ advises, but only the Kernel can commit.", "excerpt": "> **Contract Statement**: Orbit grants capability, FunctionGemma proposes, RAG++ advises, but only the Kernel can commit.\n\nSMART (Stratified Monotone Action Runtime) is the execution architecture for TrajectoryOS that brings Clarity-like guarantees to energetic, always-on workflows. It separates the system into three distinct authority rings:\n\n| Ring | Component | Authority | Can Mutate? | |------|-----------|-----------|-------------| | **Governor** | Orbit | Issues capability/scope tokens, controls tool visibility | No | | **Library** | RAG++ | Retrieves context, advises on state, computes embeddings | No | | **Executor** | Kernel (VM) | Checks admissibility, commits syscalls, writes ledger | **Yes** |\n\nThe local **FunctionGemma** model acts as a syscall compiler: it translates natural language into structured tool calls but has no authority to execute anything. All execution flows through the Kernel.\n\nTraditional smart contract languages (like Clarity) achieve safety by making programs fully analyzable before execution: no hidden control flow, no unbounded loops, no runtime surprises. SMART adapts these principles to continuous, always-on systems:", "htmlHref": "/research/html/smart-architecture-stratified-monotone-action-runtime-for-trajectoryos-10up64o.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1721 }, { "id": "assumptions-invariants-ledger-16n2z77", "title": "Assumptions & Invariants Ledger", "slug": "assumptions-invariants-ledger", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-inscription/docs/02-INVARIANTS_LEDGER.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| # | Sigil | Unicode | Locked Assignment | |---|-------|---------|-------------------| | 1 | ߛ | U+07DB | Stabilization | | 2 | ߜ | U+07DC | Dispersion | | 3 | ߕ | U+07D5 | Transition | | 4 | ߙ | U+07D9 | Return | | 5 | ߡ | U+07E1 | Dwell | | 6 | ߚ | U+07DA | Oscillation | | 7 | ߞ | U+07DE | Recovery | | 8 | ߣ | U+07E3 | Novelty | | 9 | ߠ | U+07E0 | Place-Shift | | 10 | ߥ | U+07E5 | Echo |", "excerpt": "Assumptions are things the project relies on that could be false. If violated, specific parts break.\n\n### A-INS-001: DELL provides z-trajectory **Assumption**: The DELL latent engine streams z(t) embeddings at consistent intervals. **What breaks if false**: Claim detectors have no input, inscriptions cannot be generated. **Detection**: Monitor DELL stream health, alert on gaps > 10s. **Mitigation**: Buffer last-known z(t) and emit degraded-confidence claims.\n\n### A-INS-002: Graph Kernel enforces admissibility **Assumption**: All evidence retrieval for Echo claims goes through the Graph Kernel. **What breaks if false**: Echo claims could reference non-admissible evidence, provenance is broken. **Detection**: Audit Echo claims for valid slice_id references. **Mitigation**: Reject Echo claims without verified admissibility tokens.\n\n### A-INS-003: Basins are rare relative to samples **Assumption**: The number of graduated basins is << number of z-trajectory samples. **What breaks if false**: Lexicon becomes unmanageably large, phrase compression fails. **Detection**: Monitor basin count, alert if > 100 basins per user per month. **Mitigation**: Increase graduation threshold, retire low-dwell basins.\n\n### A-INS-004: N'Ko sigils are Unicode-stable **Assumption**: The 10 N'Ko characters (ߛ, ߜ, ߕ, ߙ, ߡ, ߚ, ߞ, ߣ, ߠ, ߥ) have stable Unicode codepoints. **What breaks if false**: Rendering breaks across systems, corpus becomes unreadable. **Detection**: N/A (Unicode codepoints are standardized). **Mitigation**: Store codepoints (e.g., U+07DB) alongside rendered characters.", "htmlHref": "/research/html/assumptions-invariants-ledger-16n2z77.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1027 }, { "id": "computational-choreography-t60vpw", "title": "Computational Choreography", "slug": "computational-choreography", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/architecture/01-COMPUTATIONAL_CHOREOGRAPHY.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Computational Choreography is the practice of treating embodied human motion as a **semantic object** capable of generating, modifying, and controlling digital experiences. It is not motion capture, not gesture recognition, and not animation—though it can incorporate all three.", "excerpt": "**Version**: 1.1.0 **Last Updated**: 2025-01-01 **Status**: Foundational **Parent**: [00-OVERVIEW.md](00-OVERVIEW.md)\n\nComputational Choreography is the practice of treating embodied human motion as a **semantic object** capable of generating, modifying, and controlling digital experiences. It is not motion capture, not gesture recognition, and not animation—though it can incorporate all three.\n\n> **What does movement mean, and how can we compute that meaning in real time?**\n\nThis is the **governing philosophy** for the entire Comp-Core system. Every architectural decision, every algorithm choice, and every data structure is evaluated against this question.\n\nMovement carries information beyond its kinematic description. A raised arm is not just a position vector; it is an intention, a signal, a communication.", "htmlHref": "/research/html/computational-choreography-t60vpw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1797 }, { "id": "echelon-zv6pjm", "title": "Echelon", "slug": "echelon", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/architecture/03-ECHELON.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Version**: 1.2.0 **Last Updated**: 2025-01-01 **Status**: Production **Parent**: [00-OVERVIEW.md](00-OVERVIEW.md) **Philosophy**: [01-COMPUTATIONAL_CHOREOGRAPHY.md](01-COMPUTATIONAL_CHOREOGRAPHY.md) **Complement**: [02-TRAJECTORY_OS.md](02-TRAJECTORY_OS.md) (long-horizon OS)", "excerpt": "**Version**: 1.2.0 **Last Updated**: 2025-01-01 **Status**: Production **Parent**: [00-OVERVIEW.md](00-OVERVIEW.md) **Philosophy**: [01-COMPUTATIONAL_CHOREOGRAPHY.md](01-COMPUTATIONAL_CHOREOGRAPHY.md) **Complement**: [02-TRAJECTORY_OS.md](02-TRAJECTORY_OS.md) (long-horizon OS)\n\nEchelon is the **real-time embodied physics engine** that processes motion at millisecond timescales. It answers:\n\n> **What is happening now, in the body, and how do we keep this moment coherent?**\n\nEchelon **owns the physics of embodiment**: latency, stability, coherence, and real-time response. Nothing in TrajectoryOS or RAG++ can replace this capability.\n\n| Regime | Echelon | TrajectoryOS | |--------|---------|--------------| | **Latency** | Milliseconds (existential) | Seconds (acceptable) | | **State** | Continuous dynamical manifold | Discrete memory turns | | **Question** | How do we keep coherence? | What does this mean? | | **Mode** | Act, not reason | Reason, then act |", "htmlHref": "/research/html/echelon-zv6pjm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1550 }, { "id": "symphony-stage-3-expansion-multi-agent-architecture-mhqkcq", "title": "Symphony -- Stage 3 Expansion: Multi-Agent Architecture", "slug": "symphony-stage-3-expansion-multi-agent-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/stage3-multi-agent-expansion.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> **Evolution:** Symphony -- Multi-Agent Orchestrator for Linear Issue Automation > **Stage:** 3 Expansion (Architectural Retrofit) > **Date:** 2026-03-07 > **Input:** Stage 2 Compound (8-step synthesis) + Stage 3 Master Plan (44 tasks) + Multi-Agent Research (970 lines) > **Engine:** Evo-Cubed Runner (Opus 4.6)", "excerpt": "# Symphony -- Stage 3 Expansion: Multi-Agent Architecture ## From Codex-Only to Claude Code + Gemini CLI + Codex as Interchangeable Backends\n\n> **Evolution:** Symphony -- Multi-Agent Orchestrator for Linear Issue Automation > **Stage:** 3 Expansion (Architectural Retrofit) > **Date:** 2026-03-07 > **Input:** Stage 2 Compound (8-step synthesis) + Stage 3 Master Plan (44 tasks) + Multi-Agent Research (970 lines) > **Engine:** Evo-Cubed Runner (Opus 4.6)\n\nThe original monorepo has `packages/codex-client/` as the sole agent integration. This package is replaced by `packages/agent-adapters/`, which contains a unified interface, three adapter implementations, and an event normalization layer.\n\nThe key constraint is preserved: `agent-adapters` is a package, not a service. It has no dependency on `linear-client`, `workspace-manager`, or `state-machine`. The orchestrator in `symphony-daemon` wires these together. This means each adapter is independently testable.\n\nCodex has no npm dependency -- it uses auto-generated types from `codex app-server generate-ts` committed directly into `types/codex-types.ts`. Gemini has no npm dependency -- it uses manually defined types for the NDJSON stream format.", "htmlHref": "/research/html/symphony-stage-3-expansion-multi-agent-architecture-mhqkcq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 7274 }, { "id": "nko-speech-search-diarization-and-tts-architecture-16z88rf", "title": "N'Ko Speech Search, Diarization, and TTS Architecture", "slug": "nko-speech-search-diarization-and-tts-architecture", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/handoffs/nko_speech_search_diarization_tts_architecture_2026-04-26.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. **Provenance-first search** over N'Ko audio, transcripts, papers, and corrections. 2. **Improved diarization** for Djoko and future Bambara/Malinke broadcast corpora. 3. **N'Ko TTS / voice generation**, but only from a high-precision subset with explicit speaker boundaries and alignment confidence.", "excerpt": "Turn the existing N'Ko ASR + AGP stack into a speaker-aware speech system with three outputs:\n\n1. **Provenance-first search** over N'Ko audio, transcripts, papers, and corrections. 2. **Improved diarization** for Djoko and future Bambara/Malinke broadcast corpora. 3. **N'Ko TTS / voice generation**, but only from a high-precision subset with explicit speaker boundaries and alignment confidence.\n\nThis is not a generic web-search play. It is a vertical system for **Manding speech understanding, correction, retrieval, and eventually synthesis**.\n\n- **PyTorch/Whisper trajectory ASR on Vast** - **Gemma/AGP corrective layer on Mac4/Mac5**\n\n- `djoko_speakers.json` - `7` weak speaker clusters - `6,625` diarized segments - `5` eligible speakers for adaptation experiments - `djoko_transcriptions.jsonl` - historical first-pass N'Ko transcriptions - quality is still noisy and often collapses into repeated characters - `consensus_pairs.jsonl` - filtered subset with confidence and text-quality metadata", "htmlHref": "/research/html/nko-speech-search-diarization-and-tts-architecture-16z88rf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1534 }, { "id": "speech-calibration-and-acoustic-improvement-v0-sfqrs9", "title": "Speech Calibration and Acoustic Improvement v0", "slug": "speech-calibration-and-acoustic-improvement-v0", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/SPEECH-CALIBRATION-ACOUSTIC-IMPROVEMENT-V0.md", "extension": "md", "score": 48, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The Speech Inscription Bridge v0 changed the failure mode. The harness no longer treats unstable CTC output as language. The next stage is calibration: collect short Malinke recordings, attach expected labels, sort the evidence by failure type, and build evaluation or training candidates without poisoning the corpus.", "excerpt": "The Speech Inscription Bridge v0 changed the failure mode. The harness no longer treats unstable CTC output as language. The next stage is calibration: collect short Malinke recordings, attach expected labels, sort the evidence by failure type, and build evaluation or training candidates without poisoning the corpus.\n\nThe core invariant is still evidence first. A live packet is not a transcript. A user-supplied expected phrase is not automatically ground truth. A model output is never a label. The calibration compiler only admits a packet for acoustic training when the packet validates and the label is explicitly marked `human_verified`. Phrases supplied in the app text field or through `--nko-headless-expected-phrase` are `operator_expected`: they are useful for evaluation and triage, but they are not training labels until verified.\n\nIt scans one or more copied `NKOLiveCalibration` roots, validates each `manifest.json` with the Speech Inscription validator, joins optional JSONL labels by `packetId`, `manifestSha256`, or `archiveRef`, and writes a replayable calibration index. The default input is the latest live proof copy:\n\nBuckets are derived from typed transcript decisions, not from visual inspection:\n\nEach calibration example preserves the manifest path, packet directory, manifest hash, source kind, creation time, validation result, audio evidence records, replay requirements, transcript-decision statistics, expected-label claim, label comparison when meaningful, FAC target placeholders, tone-fusion readiness, and admissibility decision.", "htmlHref": "/research/html/speech-calibration-and-acoustic-improvement-v0-sfqrs9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 14203 }, { "id": "comp-core-architecture-diagrams-k6vt1b", "title": "Comp-Core Architecture Diagrams", "slug": "comp-core-architecture-diagrams", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "portfolio-assets/diagrams/COMP_CORE_ARCHITECTURE.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` ┌─────────────────────────────────────────────────────────────────┐ │ COMP-CORE ARCHITECTURE │ │ \"Motion becomes computation\" │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 8. ML LAYER │ │ │ │ cc-ml • Motion synthesis • Diffusion models │ │ │ └─────────────────────────────────────────────────────────┘ │ │ ▲ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ 7. GATEWAYS LAYER │ │ │ │ cc-gemini • cc-r", "excerpt": "No public-safe excerpt was extracted yet. This item needs curation before it becomes a readable paper.", "htmlHref": "/research/html/comp-core-architecture-diagrams-k6vt1b.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1897 }, { "id": "cc-echelon-capabilities-assessment-what-s-already-built-1au8094", "title": "CC-Echelon Capabilities Assessment - What's Already Built", "slug": "cc-echelon-capabilities-assessment-what-s-already-built", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/01-architecture/ECHELON_CAPABILITIES_ASSESSMENT.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Reality**: CC-Echelon is a **full-featured audio/music engine** with: - ✅ **Audio analysis** (BPM, beats, onsets, energy, spectral features) - ✅ **Phrase database** with SQLite + vector search - ✅ **Real-time audio processing** - ✅ **MIDI/OSC integration** - ✅ **Voice control** - ✅ **Motion bridge** (connects to motion data)", "excerpt": "**Date**: 2025-12-17 **Question**: Is the majority of music pipeline work already done in Rust?\n\n**Reality**: CC-Echelon is a **full-featured audio/music engine** with: - ✅ **Audio analysis** (BPM, beats, onsets, energy, spectral features) - ✅ **Phrase database** with SQLite + vector search - ✅ **Real-time audio processing** - ✅ **MIDI/OSC integration** - ✅ **Voice control** - ✅ **Motion bridge** (connects to motion data)\n\n**What This Gives You**: - ✅ **BPM detection** via autocorrelation (60-200 BPM range) - ✅ **Beat tracking** with onset detection - ✅ **Energy calculation** via RMS - ✅ **Spectral analysis** (centroid, rolloff) - ✅ **Phrase boundary detection**\n\n**Comparison to Roadmap**: | Feature | Roadmap (Python) | CC-Echelon (Rust) | Status | |---------|------------------|-------------------|--------| | BPM detection | librosa | ✅ Autocorrelation | **DONE!** | | Beat tracking | librosa | ✅ Onset + tempo | **DONE!** | | Energy level | RMS | ✅ RMS envelope | **DONE!** | | Spectral features | STFT | ✅ FFT + centroid | **DONE!** | | Phrase segmentation | Novelty | ✅ Boundary detection | **DONE!** |\n\n**Infrastructure**: - ✅ SQLite database for metadata - ✅ Vector embeddings for similarity search (HNSW) - ✅ Fast phrase lookup by ID - ✅ Similarity queries for recommendations", "htmlHref": "/research/html/cc-echelon-capabilities-assessment-what-s-already-built-1au8094.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1931 }, { "id": "nko-bambara-multilingual-system-architecture-plan-1gpp1mf", "title": "N'Ko-Bambara Multilingual System Architecture Plan", "slug": "nko-bambara-multilingual-system-architecture-plan", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "projects/LearnNKo/ml/docs/technical/Architecture_Plan.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "This document outlines the comprehensive architecture for implementing a modular multilingual system that processes N'Ko and Bambara languages alongside English and French. The system leverages the RobotsMali/bam-asr-early dataset as its foundation and implements a five-layer modular architecture supporting bidirectional translation across all language pairs.", "excerpt": "This document outlines the comprehensive architecture for implementing a modular multilingual system that processes N'Ko and Bambara languages alongside English and French. The system leverages the RobotsMali/bam-asr-early dataset as its foundation and implements a five-layer modular architecture supporting bidirectional translation across all language pairs.\n\n### Dataset Characteristics - **Total Duration**: 37.41 hours of audio - **Total Samples**: 38,769 (Train: 37,306 | Test: 1,463) - **Language Pairs**: Bambara ↔ French with aligned transcriptions - **Audio Quality**: Variable duration (0.42–54.6 seconds)\n\n### Dataset Subsets 1. **Oza's Bambara-ASR**: ~29 hours (primary ASR training data) 2. **Jeli-ASR-RMAI**: ~3.5 hours (conversational speech) 3. **oza-tts-mali-pense**: ~4 hours (TTS-optimized recordings) 4. **Reading-tutor-data**: ~1 hour (educational content)\n\nThe system follows a five-layer modular architecture designed for scalability and language-specific optimization:\n\n### Layer A: Speech Processing Layer - **ASR Module**: wav2vec 2.0-based speech recognition - **TTS Module**: Neural speech synthesis - **Audio Preprocessing**: Noise reduction, normalization, segmentation", "htmlHref": "/research/html/nko-bambara-multilingual-system-architecture-plan-1gpp1mf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1589 }, { "id": "the-proof-stack-revenue-architecture-for-self-funding-compute-hfiy8a", "title": "The Proof Stack: Revenue Architecture for Self-Funding Compute", "slug": "the-proof-stack-revenue-architecture-for-self-funding-compute", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "proof-stack-revenue-architecture.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| Stream | Price | Target Month 1 | Automation Level | |--------|-------|----------------|-----------------| | Architecture Snapshot | $500 one-time | 1 sale = $500 | Intake automated, 30-min Loom review by Mo | | Cognitive Profile Analysis | $99 one-time | 5 sales = $495 | 100% automated after setup | | Mesh Dispatch (newsletter) | $10/month | 10 paid subs = $100 | 1 hour/week writing | | **Month 1 conservative total** | | **$1,095** | |", "excerpt": "# The Proof Stack: Revenue Architecture for Self-Funding Compute ## creative:forge Output | 2026-03-30 ## Target: $400+/month within 90 days, automated, scalable\n\n| Stream | Price | Target Month 1 | Automation Level | |--------|-------|----------------|-----------------| | Architecture Snapshot | $500 one-time | 1 sale = $500 | Intake automated, 30-min Loom review by Mo | | Cognitive Profile Analysis | $99 one-time | 5 sales = $495 | 100% automated after setup | | Mesh Dispatch (newsletter) | $10/month | 10 paid subs = $100 | 1 hour/week writing | | **Month 1 conservative total** | | **$1,095** | |\n\n$400/month is cleared in Week 2. The question is not whether this works. The question is which distribution action happens first.\n\n46 apps prove you can ship. The mesh proves you can architect. The trajectory data proves you can optimize. The N'Ko work proves you think at depth. The consulting offer is the monetization layer for all of it.\n\n**The flywheel:** Visible output (apps + content) builds audience. Audience generates consulting leads. Consulting revenue pays compute. Compute runs the mesh that ships more visible output.", "htmlHref": "/research/html/the-proof-stack-revenue-architecture-for-self-funding-compute-hfiy8a.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1758 }, { "id": "complete-chain-specification-extracted-from-session-transcript-ncpqv5", "title": "Complete ΨChain Specification — Extracted from Session Transcript", "slug": "complete-chain-specification-extracted-from-session-transcript", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "psichain-full-specification.md", "extension": "md", "score": 48, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "I now have all the specification content. Here is the complete extracted ΨChain specification from the session transcript at `/home/mohameddiomande/.claude/projects/-home-mohameddiomande/32b77d84-7699-4445-99d5-0c2fe78f7533.jsonl`.", "excerpt": "I now have all the specification content. Here is the complete extracted ΨChain specification from the session transcript at `/home/mohameddiomande/.claude/projects/-home-mohameddiomande/32b77d84-7699-4445-99d5-0c2fe78f7533.jsonl`.\n\nThe specification was found across multiple assistant messages (JSONL lines 165, 178, 184, 189, 196, 219, 376, 382, 387, 404, 412, and 422). Below is the full content, organized by section.\n\n## A system for encoding a life's computational essence as hash-chained N'Ko inscriptions on Bitcoin, producing a self-referential, publicly readable, semantically private, eternally persistent corpus that grows denser with every inscription.\n\n| Phase | Name | Status | Description | |-------|------|--------|-------------| | A | Close On-Chain/Off-Chain Loop | **Gap identified** | Chain events -> filesystem -> orchestrator. ~30 lines to wire. | | B | Event-Driven Migration | Pending | Consolidate orchestrators into single event-driven system | | C | Machine Failure Resilience | Pending | Register machines + KARL skills on-chain, commit first Merkle root | | D | Self-Sustaining Revenue | Pending | Mainnet deploy, seed DEX, activate arb scanner | | **E** | **ΨChain: N'Ko Inscription Layer** | **THIS DOCUMENT** | Replace Supabase as state persistence with N'Ko on-chain inscriptions |\n\nPhase E doesn't depend on D (revenue). It depends on A (chain events flowing) and C (agents registered on-chain). ΨChain can run on testnet with zero STX cost while the revenue engine matures independently.", "htmlHref": "/research/html/complete-chain-specification-extracted-from-session-transcript-ncpqv5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6216 }, { "id": "sea-0-1-complete-vx2gsh", "title": "SEA-0.1-COMPLETE", "slug": "sea-0-1-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-0.1-COMPLETE.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> **Deprecation note (2026-05-13):** Mac3 was the Tier 2 worker host at the time this phase shipped. Mac3 has since been retired. References in this document reflect the Feb-2026 architecture and are kept for historical accuracy. The current home for Tier 2 scoring is Mac4:8100 (cognitive twin). See SOOP-2 launch memory for migration plan.", "excerpt": "> **Deprecation note (2026-05-13):** Mac3 was the Tier 2 worker host at the time this phase shipped. Mac3 has since been retired. References in this document reflect the Feb-2026 architecture and are kept for historical accuracy. The current home for Tier 2 scoring is Mac4:8100 (cognitive twin). See SOOP-2 launch memory for migration plan.\n\n## Summary Verified Ollama embedding infrastructure on Mac4 ([ip]). Installed the `all-minilm` model (was not pre-installed), confirmed 384-dimensional vector output, and benchmarked warm latency at 7.45ms average — well under the 10ms target. Results documented in `phase0-results.md`.\n\n## Changes - File: `phase0-results.md` — appended Mac4 Ollama embedding verification section (Sections 1-5: status, installation, embedding test, latency benchmarks, go/no-go summary) - Remote: Mac4 ([ip]) — pulled `all-minilm` model via Ollama (45 MB)\n\n### Synthesis-Evil - Integration seams: phase0-results.md cleanly extends with Mac4 section after Mac3 section - Emergent behaviors: cold start latency (651ms) is a known concern for production; documented with pre-warm recommendation - State leakage: none — each section is independent - Original task: fully satisfied\n\n## RTD Verification - [x] Structure: phase0-results.md exists with both Mac3 and Mac4 sections - [x] Compilation: N/A (markdown documentation) - [x] Integration: file committed to `sound-sigils-dep` branch - [x] Content: 384-dim verified, 7.45ms avg latency, model installed, all checks pass - [x] User Journey: curl command from task works end-to-end - [x] Deployment: committed as part of 4ee8837", "htmlHref": "/research/html/sea-0-1-complete-vx2gsh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 405 }, { "id": "sea-0-3-complete-5v5n0f", "title": "SEA-0.3-COMPLETE", "slug": "sea-0-3-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-0.3-COMPLETE.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> **Deprecation note (2026-05-13):** Mac3 was the Tier 2 worker host at the time this phase shipped. Mac3 has since been retired. References in this document reflect the Feb-2026 architecture and are kept for historical accuracy. The current home for Tier 2 scoring is Mac4:8100 (cognitive twin). The `mac3-worker-config/` directory and launchd plist described below are archived to `archive/mac3-era/` and should be skipped if reading for current architecture. See SOOP-2 launch memory for migration plan.", "excerpt": "> **Deprecation note (2026-05-13):** Mac3 was the Tier 2 worker host at the time this phase shipped. Mac3 has since been retired. References in this document reflect the Feb-2026 architecture and are kept for historical accuracy. The current home for Tier 2 scoring is Mac4:8100 (cognitive twin). The `mac3-worker-config/` directory and launchd plist described below are archived to `archive/mac3-era/` and should be skipped if reading for current architecture. See SOOP-2 launch memory for migration plan.\n\n## Summary Confirmed Mac3 availability for SEA worker deployment. SSHed to mac3 (M1, 8GB, macOS 14.8.3), verified Python 3.8.2, confirmed 5 concurrent Python processes run cleanly in 2.0s, and determined launchd is the process supervisor to use (supervisord not installed, no Homebrew). Created skeleton worker config with launchd plist, install script, and documentation.\n\n## Changes - File: `phase0-mac3-availability.md` — Full availability audit: hardware specs, Python env, concurrency test, supervisor check, go/no-go matrix - File: `mac3-worker-config/sea-worker.plist` — Skeleton launchd plist for SEA scorer worker with env vars, auto-restart, logging - File: `mac3-worker-config/install.sh` — Deployment script to install plist on mac3 via SSH - File: `mac3-worker-config/README.md` — Config documentation and installation guide\n\n## Key Findings - **Mac3 is GO** for lightweight SEA workers (routing, scoring, health) - **Python 3.8.2** — adequate, but dated (EOL). Sufficient for subprocess/HTTP workers - **8 GB RAM** — caution for ML models; fine for everything else - **launchd** recommended over supervisord (native, zero deps, auto-restart) - **31 GB disk free** — plenty for worker code and logs\n\n## Commits - 4ee8837 feat(sea-0.2): add MiniMax scoring latency benchmark and phase0 results (includes mac3-worker-config/) - fe9e18b audit(sea-0.4): inventory all hooks and plan sea-router integration (includes phase0-mac3-availability.md)", "htmlHref": "/research/html/sea-0-3-complete-5v5n0f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 343 }, { "id": "dep-evo-cubed-skill-entity-architecture-sea-1t64q05", "title": "DEP + Evo-Cubed: Skill Entity Architecture (SEA)", "slug": "dep-evo-cubed-skill-entity-architecture-sea", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/TASK.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> **Deprecation note (2026-05-13):** Mac3 was the Tier 2 worker host at the time this phase shipped. Mac3 has since been retired. References in this document reflect the Feb-2026 architecture and are kept for historical accuracy. The current home for Tier 2 scoring is Mac4:8100 (cognitive twin). See SOOP-2 launch memory for migration plan.", "excerpt": "> **Deprecation note (2026-05-13):** Mac3 was the Tier 2 worker host at the time this phase shipped. Mac3 has since been retired. References in this document reflect the Feb-2026 architecture and are kept for historical accuracy. The current home for Tier 2 scoring is Mac4:8100 (cognitive twin). See SOOP-2 launch memory for migration plan.\n\nAn inverted skill system where creative/philosophical skills become autonomous daemon entities.\n\n### Current Problem - 105+ skills in [home-path] — most are static files loaded on-demand - Creative/philosophical skills (phi:*, art:*, nav:*) are powerful but interfere with normal operations - Skills have no memory of when they've been useful before\n\n### Proposed Architecture 1. Discord Category: Skill Entities — each skill gets its own channel 2. Each channel has the skill SKILL.md as system prompt + rolling conversation history 3. Router middleware intercepts every prompt/response in main channels 4. Relevance scoring — broadcasts to each skill-entity: Score 0-1 how relevant are you 5. Threshold activation — any skill above threshold (0.7) gets full context and generates injection 6. Injection gets appended as skill perspective before final response\n\n### Model Strategy - Scorer (hot path): MiniMax-3B-v0.1 local model at localhost:18080 (free, fast) for relevance classification - Activator (cold path): Heavier model only when threshold crossed - Each skill evolves its own activation patterns based on accumulated history", "htmlHref": "/research/html/dep-evo-cubed-skill-entity-architecture-sea-1t64q05.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 405 }, { "id": "speakflow-v2-architecture-business-plan-1sgodxv", "title": "SpeakFlow V2 — Architecture & Business Plan", "slug": "speakflow-v2-architecture-business-plan", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "SpeakFlow/ARCHITECTURE-V2.md", "extension": "md", "score": 48, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "SpeakFlow is a **privacy-first, offline-first voice OS** that replaces typing across every app on Mac, iOS, and eventually Windows. It competes directly with Wispr Flow ($10M ARR, $700M valuation, 270 Fortune 500 customers) by exploiting their three biggest vulnerabilities: cloud-only processing, 800MB RAM bloat, and zero customer support.", "excerpt": "SpeakFlow is a **privacy-first, offline-first voice OS** that replaces typing across every app on Mac, iOS, and eventually Windows. It competes directly with Wispr Flow ($10M ARR, $700M valuation, 270 Fortune 500 customers) by exploiting their three biggest vulnerabilities: cloud-only processing, 800MB RAM bloat, and zero customer support.\n\n| Dimension | Wispr Flow | SpeakFlow | |-----------|-----------|-----------| | **Processing** | 100% cloud (audio sent to servers) | 100% on-device (Apple Speech, CoreML) | | **Privacy** | Screen capture + cloud upload | Zero data leaves device | | **RAM** | 800MB idle | Target: <80MB | | **CPU idle** | 8%+ | Target: <1% | | **Offline** | No. Dead without internet | Full functionality offline | | **Price** | $12/mo ($144/yr) | $49 lifetime or $4/mo | | **Latency** | ~700ms (network round-trip) | <200ms (on-device) | | **Platforms** | Mac, Win, iOS, Android | Mac, iOS (Win later) | | **Support** | 0% response rate (Trustpilot 2.7/5) | Every ticket, every review | | **N'Ko** | No | Native transliteration + keyboard | | **AI Commands** | Cloud LLM (Llama on Baseten) | On-device MLX (Gemma 3 4B) + mesh fallback | | **Architecture** | Electron (Windows) | Native Swift (all platforms) |\n\n1. **Privacy refugees**: Developers, lawyers, medical professionals actively searching for local alternatives (documented in Reddit threads, Trustpilot cancellations) 2. **Resource-conscious users**: 800MB RAM is absurd for dictation. Position as \"dictation that doesn't tax your system\" 3. **Price-sensitive users**: $12/mo for a utility feels wrong. $49 lifetime matches proven price points (Voibe, Superwhisper) 4. **Offline workers**: Trains, planes, cafes with bad wifi, rural areas. Wispr is dead without internet.\n\n#### 1. CommandModeService Wispr Flow's stickiest feature. Voice-driven text editing after dictation.\n\n#### 2. WhisperCoreMLService Enhanced recognition for accents, code, and whisper-level input.", "htmlHref": "/research/html/speakflow-v2-architecture-business-plan-1sgodxv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1889 }, { "id": "phase-3-real-time-gesture-streaming-architecture-aqmbh0", "title": "Phase 3: Real-Time Gesture Streaming - Architecture", "slug": "phase-3-real-time-gesture-streaming-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/gesture_control/realtime_architecture.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Phase 3** connects the production training system (Phases 1 & 2) to live DJ performance, enabling real-time gesture recognition that triggers keyboard shortcuts, MIDI commands, or integrates with voice control.", "excerpt": "**Phase 3** connects the production training system (Phases 1 & 2) to live DJ performance, enabling real-time gesture recognition that triggers keyboard shortcuts, MIDI commands, or integrates with voice control.\n\n**Key Features:** - Sliding window analysis (0.5-2 seconds) - Gesture debouncing (prevent double triggers) - Confidence thresholding - Multi-gesture detection (simultaneous gestures) - Performance monitoring (latency, accuracy)\n\n**Input:** - Continuous sensor stream (Phase 1) - Trained gesture templates (Phase 2)\n\n**Mapping Types:** 1. **Keyboard Shortcuts** - Gesture → Key combo (e.g., swipe_right → Cmd+Right) - Platform-specific (macOS, Windows, Linux)\n\n3. **Direct Integration** - Gesture → Rekordbox/Serato API call - Gesture → Custom Python function", "htmlHref": "/research/html/phase-3-real-time-gesture-streaming-architecture-aqmbh0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1384 }, { "id": "complete-ircp-implementation-summary-1oa6imk", "title": "✅ Complete IRCP Implementation Summary", "slug": "complete-ircp-implementation-summary", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/COMPLETE_IRCP_IMPLEMENTATION_SUMMARY.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "All placeholders have been removed and the complete SentenceTransformer-based IRCP system is ready for local training using `all-MiniLM-L6-v2`.", "excerpt": "All placeholders have been removed and the complete SentenceTransformer-based IRCP system is ready for local training using `all-MiniLM-L6-v2`.\n\n### ✅ **Fixed All Placeholders** 1. **main.py**: Complete `generate_response` method with coordinate-guided response generation 2. **base_models.py**: Complete abstract methods with full implementations 3. **measure_theory.py**: Complete abstract methods with mathematical rigor 4. **All modules**: No remaining `TODO`, `FIXME`, or placeholder implementations\n\n### ✅ **Created Complete SentenceTransformer Model** - **File**: `ircp/models/sentence_transformer_icp.py` - **Features**: - Uses `sentence-transformers/all-MiniLM-L6-v2` as base encoder - Custom IRCP heads for coordinate prediction - Inverse attention mechanism - Ring topology integration - Measure-preserving transformations - Multi-component loss function - Complete response generation\n\n### ✅ **Model Registry Integration** - Automatically registered as `\"sentence_transformer_icp\"` - Accessible through `ModelRegistry.get_model()` - Full compatibility with existing IRCP framework\n\n### ✅ **Complete Training Pipeline** - **File**: `train_sentence_transformer_ircp.py` - **Features**: - Automatic dependency installation - Model validation and testing - Comprehensive configuration - Progress tracking and visualization - Checkpoint management - Evaluation integration", "htmlHref": "/research/html/complete-ircp-implementation-summary-1oa6imk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 752 }, { "id": "icp-implementation-complete-57pfn0", "title": "ICP Implementation Complete ✅", "slug": "icp-implementation-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/docs/IMPLEMENTATION_COMPLETE.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "I have successfully implemented the complete **Inverse Ring Contextual Propagation (ICP)** framework as specified in your theoretical documents. This is a comprehensive, production-ready implementation that transforms your 10,000+ message conversation dataset into a rigorous mathematical framework for learning individual response patterns.", "excerpt": "I have successfully implemented the complete **Inverse Ring Contextual Propagation (ICP)** framework as specified in your theoretical documents. This is a comprehensive, production-ready implementation that transforms your 10,000+ message conversation dataset into a rigorous mathematical framework for learning individual response patterns.\n\n**1. Divergent Language Matrix (DLM) Coordinate System** (`dlm_coordinates.py`) - Complete mathematical implementation from `DLM.md` - 4D coordinate calculation: (x, y, z, t) - **x**: Hierarchical depth in conversation tree - **y**: Sibling order among messages at same level - **z**: Homogeneity based on sibling count and similarity scores - **t**: Temporal coordinate with dynamic decay factors - Dynamic Message Ordering (DMO) system - Validation and error checking\n\n**2. Inverse Ring Contextual Propagation Architecture** (`icp_architecture.py`) - Complete neural architecture implementing `ICP.md` framework - **Measure-Preserving Transform**: φ: U×V → V×U with conservation guarantees - **Ring Topology**: Circular ordering preserving local/global structure - **Inverse Attention Mechanism**: A'(C') for capturing response patterns - **Differential Equation Solver**: Numerical integration of dC'/dt = A'(C')C' - **Conservation Constraints**: Ergodic stability, information preservation, homology\n\n**Comprehensive Data Extraction System** - Processes all 277 conversation folders in your dataset - Extracts conversation trees, coordinates, embeddings, relationships - Parallel processing for efficiency (configurable workers) - Creates training-ready tensors for ICP model - Handles different data formats and missing data gracefully - Generates comprehensive statistics and validation reports\n\n**Data Types Extracted:** - `conversation_tree.json` - Raw conversation structure - `coordinate_tree.json` - DLM coordinates - `main_df.csv` - Processed messages with embeddings - `similarity_df.csv` - Pairwise similarity matrices - `relationship.csv` - Message relationships and metrics - `global_embedding.npy` - High-dimensional embeddings - `combined_tensor.npy` - Combined feature tensors", "htmlHref": "/research/html/icp-implementation-complete-57pfn0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1087 }, { "id": "enhanced-icp-framework-implementation-summary-gwzcg2", "title": "Enhanced ICP Framework - Implementation Summary", "slug": "enhanced-icp-framework-implementation-summary", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/ENHANCED_ICP_SUMMARY.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "All major components of the Enhanced Inverse Ring Contextual Propagation (ICP) Framework have been successfully implemented and tested.", "excerpt": "All major components of the Enhanced Inverse Ring Contextual Propagation (ICP) Framework have been successfully implemented and tested.\n\n✅ **Enhanced ICP Structure** - Restructured with better organization and database integration ✅ **Database Integration** - Integrated conversation database with ICP data extraction ✅ **Enhanced DLM Coordinates** - Improved coordinate calculation with database data ✅ **Upgraded ICP Architecture** - Enhanced neural architecture with latest insights ✅ **Training Pipeline** - Upgraded with database integration ✅ **Evaluation System** - Improved with comprehensive metrics\n\n### Core Components (`/core/`) - **`base_models.py`** - Fundamental data structures and base classes - **`coordinate_system.py`** - Enhanced DLM coordinate calculation system - **`inverse_attention.py`** - Inverse attention mechanisms for learning response patterns - **`measure_theory.py`** - Measure-preserving transformations and conservation constraints - **`ring_topology.py`** - Ring topology structures for conversation modeling\n\n### Data Management (`/data/`) - **`database_loader.py`** - Database integration with conversation data loading - **`conversation_processor.py`** - Conversation data processing utilities - **`data_validators.py`** - Data validation and quality assurance\n\n### Utilities (`/utils/`) - **`config.py`** - Configuration management system - **`logging_utils.py`** - Enhanced logging and monitoring - **`math_utils.py`** - Mathematical utility functions", "htmlHref": "/research/html/enhanced-icp-framework-implementation-summary-gwzcg2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 928 }, { "id": "complete-ircp-implementation-summary-1glirv9", "title": "✅ Complete IRCP Implementation Summary", "slug": "complete-ircp-implementation-summary", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/outputs/COMPLETE_IRCP_IMPLEMENTATION_SUMMARY.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "All placeholders have been removed and the complete SentenceTransformer-based IRCP system is ready for local training using `all-MiniLM-L6-v2`.", "excerpt": "All placeholders have been removed and the complete SentenceTransformer-based IRCP system is ready for local training using `all-MiniLM-L6-v2`.\n\n### ✅ **Fixed All Placeholders** 1. **main.py**: Complete `generate_response` method with coordinate-guided response generation 2. **base_models.py**: Complete abstract methods with full implementations 3. **measure_theory.py**: Complete abstract methods with mathematical rigor 4. **All modules**: No remaining `TODO`, `FIXME`, or placeholder implementations\n\n### ✅ **Created Complete SentenceTransformer Model** - **File**: `ircp/models/sentence_transformer_icp.py` - **Features**: - Uses `sentence-transformers/all-MiniLM-L6-v2` as base encoder - Custom IRCP heads for coordinate prediction - Inverse attention mechanism - Ring topology integration - Measure-preserving transformations - Multi-component loss function - Complete response generation\n\n### ✅ **Model Registry Integration** - Automatically registered as `\"sentence_transformer_icp\"` - Accessible through `ModelRegistry.get_model()` - Full compatibility with existing IRCP framework\n\n### ✅ **Complete Training Pipeline** - **File**: `train_sentence_transformer_ircp.py` - **Features**: - Automatic dependency installation - Model validation and testing - Comprehensive configuration - Progress tracking and visualization - Checkpoint management - Evaluation integration", "htmlHref": "/research/html/complete-ircp-implementation-summary-1glirv9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 752 }, { "id": "ircp-training-status-277-conversations-1f7atxr", "title": "🚀 IRCP Training Status - 277 Conversations", "slug": "ircp-training-status-277-conversations", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/outputs/IRCP_TRAINING_STATUS_277_CONVERSATIONS.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Training Started**: Successfully running with all 277 conversations **Model**: SentenceTransformer + Custom IRCP Heads (`all-MiniLM-L6-v2`) **Status**: ✅ **ACTIVE** - Training in progress", "excerpt": "**Training Started**: Successfully running with all 277 conversations **Model**: SentenceTransformer + Custom IRCP Heads (`all-MiniLM-L6-v2`) **Status**: ✅ **ACTIVE** - Training in progress\n\n### **Loss Progress** - **Initial Train Loss**: 1432.27 - **Current Train Loss**: 1430.46 - **Train Improvement**: 1.80 points - **Validation Loss**: 1985.26 (stable)\n\n### **Learning Rate Schedule** - **Initial LR**: 4.97e-05 - **Current LR**: 0.0 (cosine schedule completed) - **Schedule**: Cosine annealing over 100 epochs\n\n### **Model Checkpoints** - **Checkpoints Saved**: 7 files - **Best Model**: 128.9 MB - **Auto-saving**: Every 10 epochs\n\n### **Base Model** - **Encoder**: `sentence-transformers/all-MiniLM-L6-v2` (FROZEN) - **Embedding Dim**: 384 - **Total Parameters**: ~22.7M - **Trainable Parameters**: ~2.5M (custom heads only)", "htmlHref": "/research/html/ircp-training-status-277-conversations-1f7atxr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 624 }, { "id": "ring-contextual-propagation-rcp-framework-complete-implementation-zcuq0h", "title": "Ring Contextual Propagation (RCP) Framework - Complete Implementation", "slug": "ring-contextual-propagation-rcp-framework-complete-implementation", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/RCP_FRAMEWORK_SUMMARY.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "All components of the Ring Contextual Propagation (RCP) Framework have been successfully implemented and thoroughly tested.", "excerpt": "All components of the Ring Contextual Propagation (RCP) Framework have been successfully implemented and thoroughly tested.\n\nThe RCP Framework implements a sophisticated system for modeling and propagating contextual information within hierarchical conversation structures:\n\n#### 1. **3D Coordinate System** (`coordinate_system.py`) - **Purpose**: Assigns spatial coordinates (x, y, z) to each message - **Coordinates**: - `x`: Depth level in conversation tree - `y`: Sibling order among messages at same level - `z`: Homogeneity relationships between sibling messages - **Features**: - Multiple homogeneity calculation methods (similarity-based, count-based, hybrid) - Coordinate normalization and validation - Confidence scoring for coordinate quality - Support for embeddings-based similarity computation\n\n#### 2. **Ring Structure** (`ring_structure.py`) - **Purpose**: Organizes messages in circular topology while preserving hierarchical relationships - **Construction Methods**: - Hierarchical preserving (maintains conversation tree structure) - Temporal-based (chronological ordering) - Similarity-based (content similarity clustering) - Hybrid (weighted combination of factors) - **Features**: - Ring connectivity validation - Neighbor traversal and path finding - Ring distance computation - Connection strength analysis\n\n#### 3. **Contextual Attention Mechanism** (`attention_mechanism.py`) - **Purpose**: Computes attention weights based on coordinate distances - **Formula**: `w(mᵢ, mⱼ) = softmax(ψ(cᵢ, cⱼ))` - **Distance Function**: `ψ(cᵢ, cⱼ) = α|xᵢ - xⱼ| + β|yᵢ - yⱼ| + γ|zᵢ - zⱼ|` - **Features**: - Learnable coordinate weights (α, β, γ) - Semantic similarity integration - Temporal decay factors - Multi-scale and adaptive attention variants - Comprehensive attention pattern analysis", "htmlHref": "/research/html/ring-contextual-propagation-rcp-framework-complete-implementation-zcuq0h.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1443 }, { "id": "ring-topology-in-hierarchical-search-visualization-1w4d0md", "title": "🔄 Ring Topology in Hierarchical Search Visualization", "slug": "ring-topology-in-hierarchical-search-visualization", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/RING_TOPOLOGY_VISUALIZATION_EXPLANATION.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The ring topology in IRCP provides a **circular ordering** that preserves both local and global conversation structure, enabling sophisticated visualization of your conversation patterns.", "excerpt": "The ring topology in IRCP provides a **circular ordering** that preserves both local and global conversation structure, enabling sophisticated visualization of your conversation patterns.\n\nThe ring structure captures: - **Local connections**: Adjacent message relationships - **Global patterns**: How conversations loop back to earlier themes - **Structural preservation**: Maintains conversation topology\n\n### **1. Ring-Based Clustering** Messages that are connected in ring space appear together:\n\n source tpo_env/bin/activate && python train_ircp_full_dataset.py --test-only", "htmlHref": "/research/html/ring-topology-in-hierarchical-search-visualization-1w4d0md.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 478 }, { "id": "rcp-architecture-corrected-analysis-1lyvpm9", "title": "RCP Architecture - CORRECTED Analysis", "slug": "rcp-architecture-corrected-analysis", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/RCP_ARCHITECTURE_CORRECTED.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "I was **completely wrong** in my initial analysis. The RCP package (`packages/rcp/`) **IS substantially implemented** with ~16,000 lines of code across 59 Python files.", "excerpt": "I was **completely wrong** in my initial analysis. The RCP package (`packages/rcp/`) **IS substantially implemented** with ~16,000 lines of code across 59 Python files.\n\n### 1. **RCP Package** (`packages/rcp/`) ✅ IMPLEMENTED **Purpose:** Ring Contextual Propagation - Full mathematical framework\n\n**What it does:** - Computes **spatial coordinates** (x, y, z) for messages - Models **ring topology** with forward/backward propagation - Implements **conservation laws** and measure theory - Provides **cross-conversation consolidation** - Builds **dynamic contexts** from all conversations - Manages **knowledge evolution** without regression\n\n**Status:** ✅ **FULLY IMPLEMENTED** but possibly **not being used in production**\n\n### 2. **Reply Chain System** (`packages/dlm/response/`) ✅ PRODUCTION **Purpose:** Conversation management for DLM", "htmlHref": "/research/html/rcp-architecture-corrected-analysis-1lyvpm9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1170 }, { "id": "rcp-ircp-architecture-status-usage-map-unszxj", "title": "RCP/IRCP Architecture Status & Usage Map", "slug": "rcp-ircp-architecture-status-usage-map", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/RCP_IRCP_ARCHITECTURE_STATUS.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "You have **3 related but distinct systems** in your codebase: 1. **RCP (Reply Chain Protocol)** - Conversation management system ✅ **ACTIVELY USED** 2. **IRCP (Inverse-Ring Context Propagation)** - Advanced ML framework ⚠️ **PARTIALLY USED** 3. **TPO (Topological Preference Optimization)** - Preference learning 🔄 **IN DEVELOPMENT**", "excerpt": "You have **3 related but distinct systems** in your codebase: 1. **RCP (Reply Chain Protocol)** - Conversation management system ✅ **ACTIVELY USED** 2. **IRCP (Inverse-Ring Context Propagation)** - Advanced ML framework ⚠️ **PARTIALLY USED** 3. **TPO (Topological Preference Optimization)** - Preference learning 🔄 **IN DEVELOPMENT**\n\n**The confusion arises because:** IRCP is a research/ML system while RCP is the production conversation system, but they both work with \"chains\" and \"coordinates\" in different ways.\n\n### Purpose **Conversation management and reply chain construction for the DLM system.**\n\n**Primary Location:** `packages/dlm/response/` - `system.py` - `ReplyChainSystem` class (1,520 lines) - **MAIN ENTRY POINT** - `builder.py` - `ReplyChainBuilder` - Constructs chain trees - `director.py` - `ReplyChainDirector` - Orchestrates construction - `links.py` - `ChainTreeLink` - Data structures\n\n**What It Does:** 1. **Manages conversation history** as linked chains 2. **Propagates context** bidirectionally (forward & inverse rings) 3. **Tracks attention weights** across conversation 4. **Adapts responses** based on user patterns 5. **Truncates history** to fit token limits", "htmlHref": "/research/html/rcp-ircp-architecture-status-usage-map-unszxj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1409 }, { "id": "unified-rcp-system-architecture-15np50c", "title": "Unified RCP System Architecture", "slug": "unified-rcp-system-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/rcp/README.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The Unified Ring Contextual Propagation (RCP) System is a comprehensive architecture that treats all 277 conversations as one interconnected knowledge system. Instead of processing conversations separately, it consolidates similar messages across all conversations and dynamically assembles contextual responses that build continuously upon existing knowledge.", "excerpt": "The Unified Ring Contextual Propagation (RCP) System is a comprehensive architecture that treats all 277 conversations as one interconnected knowledge system. Instead of processing conversations separately, it consolidates similar messages across all conversations and dynamically assembles contextual responses that build continuously upon existing knowledge.\n\n**Cross-Conversation Knowledge Consolidation**: The system identifies and groups similar messages across different conversations, creating unified knowledge clusters that transcend individual conversation boundaries. When you prompt the system, it finds the most relevant group of messages from across ALL conversations and builds a coherent context that understands you better.\n\n**Key Features**: - Loads and unifies all conversations into a single knowledge system - Maintains cross-conversation relationships and similarities - Builds global knowledge clusters that span multiple conversations - Provides unified access to all messages with enhanced metadata\n\n**Key Classes**: - `UnifiedKnowledgeSystem`: Main system for managing unified knowledge - `UnifiedMessage`: Enhanced message representation with cross-conversation data\n\n**Purpose**: Consolidates similar messages across all conversations into unified clusters.", "htmlHref": "/research/html/unified-rcp-system-architecture-15np50c.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1158 }, { "id": "phase-2c-enhancer-agent-1ayma30", "title": "Phase 2C: Enhancer Agent", "slug": "phase-2c-enhancer-agent", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/_recovered/retrieval/cc-rag-plus-plus/docs/CognitiveTwin/04_ENHANCER_AGENT.md", "extension": "md", "score": 46, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> **Purpose**: Canonicalize messy assistant outputs into clean training targets, complete unfinished code/plans, and create evaluation-grade hard prompts from historical failures. > > **Model**: GPT 5.2 (general augmentation) > > **Implementation File**: `rag_plusplus/ml/cognitivetwin_v3/worms/enhancer_agent.py`", "excerpt": "> **Purpose**: Canonicalize messy assistant outputs into clean training targets, complete unfinished code/plans, and create evaluation-grade hard prompts from historical failures. > > **Model**: GPT 5.2 (general augmentation) > > **Implementation File**: `rag_plusplus/ml/cognitivetwin_v3/worms/enhancer_agent.py`\n\n#### 1.1.1. Problem: Mixed Styles from Multiple Providers - Training data contains outputs from ChatGPT, Claude, OpenAI API - Each provider has different quirks and habits - Inconsistent style reduces model coherence - Provider-isms contaminate the learned behavior\n\n#### 1.1.2. Canonicalization Goals - Remove provider-specific phrases - Standardize opening/closing patterns - Enforce consistent formatting - Reduce permission-seeking language - Maintain semantic content\n\n#### 1.1.3. Style Tether - All outputs normalized to target style - No \"As an AI language model...\" - No excessive apologies - No unnecessary hedging - Direct, professional tone\n\n#### 1.2.1. Types of Incomplete Content - Partial code implementations - Undetermined paths (\"we'll do this later\") - Placeholder sections - Incomplete plans/specs - Truncated outputs", "htmlHref": "/research/html/phase-2c-enhancer-agent-1ayma30.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3107 }, { "id": "echelon-diffusion-system-production-architecture-tmk722", "title": "Echelon Diffusion System - Production Architecture", "slug": "echelon-diffusion-system-production-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/ml/cc-ml/diffusion/ARCHITECTURE.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "This is the **production-grade audio diffusion system** for Computational Choreography's Echelon engine. It transforms embodied motion into generative music through a sophisticated pipeline of neural networks.", "excerpt": "This is the **production-grade audio diffusion system** for Computational Choreography's Echelon engine. It transforms embodied motion into generative music through a sophisticated pipeline of neural networks.\n\n| Parameter | Value | |-----------|-------| | Sample Rate | 44,100 Hz | | Codebook Size | 2,048 | | Embedding Dim | 64 | | Compression | 64× (689 tokens/sec) | | Latent Rate | ~689 Hz |\n\n| Parameter | Value | |-----------|-------| | Architecture | U-Net / DiT | | Base Channels | 256 | | Channel Mults | [1, 2, 4, 8] | | Attention Resolutions | [8, 4] | | Conditioning Dim | 256 | | Training Steps | 1,000 | | Inference Steps | 50 (DDIM) |\n\n| Parameter | Value | |-----------|-------| | Input Dim | 25 (LatentState) | | Window Size | 46 (30 past + 1 + 15 future) | | Trajectory Dim | 64 | | Dynamics Dim | 64 | | Transition Dim | 16 | | Device Dim | 32 | | Output Dim | 256 |\n\n### ✅ Production-Ready - Stateless neural modules - External state management - Deterministic inference - ONNX exportable", "htmlHref": "/research/html/echelon-diffusion-system-production-architecture-tmk722.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 926 }, { "id": "phase-2c-enhancer-agent-mhpgsx", "title": "Phase 2C: Enhancer Agent", "slug": "phase-2c-enhancer-agent", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/docs/CognitiveTwin/04_ENHANCER_AGENT.md", "extension": "md", "score": 46, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> **Purpose**: Canonicalize messy assistant outputs into clean training targets, complete unfinished code/plans, and create evaluation-grade hard prompts from historical failures. > > **Model**: GPT 5.2 (general augmentation) > > **Implementation File**: `rag_plusplus/ml/cognitivetwin_v3/worms/enhancer_agent.py`", "excerpt": "> **Purpose**: Canonicalize messy assistant outputs into clean training targets, complete unfinished code/plans, and create evaluation-grade hard prompts from historical failures. > > **Model**: GPT 5.2 (general augmentation) > > **Implementation File**: `rag_plusplus/ml/cognitivetwin_v3/worms/enhancer_agent.py`\n\n#### 1.1.1. Problem: Mixed Styles from Multiple Providers - Training data contains outputs from ChatGPT, Claude, OpenAI API - Each provider has different quirks and habits - Inconsistent style reduces model coherence - Provider-isms contaminate the learned behavior\n\n#### 1.1.2. Canonicalization Goals - Remove provider-specific phrases - Standardize opening/closing patterns - Enforce consistent formatting - Reduce permission-seeking language - Maintain semantic content\n\n#### 1.1.3. Style Tether - All outputs normalized to target style - No \"As an AI language model...\" - No excessive apologies - No unnecessary hedging - Direct, professional tone\n\n#### 1.2.1. Types of Incomplete Content - Partial code implementations - Undetermined paths (\"we'll do this later\") - Placeholder sections - Incomplete plans/specs - Truncated outputs", "htmlHref": "/research/html/phase-2c-enhancer-agent-mhpgsx.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3107 }, { "id": "graph-kernel-full-integration-architecture-1gg7sdh", "title": "Graph Kernel Full Integration Architecture", "slug": "graph-kernel-full-integration-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/architecture/16-GRAPH_KERNEL_INTEGRATION.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The Graph Kernel is the **sole admissibility authority** for context retrieval. All paths to `memory_turns` must go through Graph Kernel verification. This document defines the integration architecture across all systems.", "excerpt": "The Graph Kernel is the **sole admissibility authority** for context retrieval. All paths to `memory_turns` must go through Graph Kernel verification. This document defines the integration architecture across all systems.\n\n| Component | Graph Kernel Integration | Status | |-----------|-------------------------|--------| | cc-graph-kernel | Core implementation | ✅ Complete | | cc-agent-service | Python client + hook | ✅ Complete | | cc-agent-sdk | MCP tools (4 tools) | ✅ Complete | | cc-rag-plus-plus | Partial (21 bypass paths) | ⚠️ Needs Migration | | Cloud Agents | GraphKernelHook available | ✅ Complete |\n\n**Endpoint**: `https://graph-kernel-xxxxxxxx.run.app` (Cloud Run) **Local**: `http://localhost:8001`\n\n| File | Function | Direct Query | Replacement | |------|----------|--------------|-------------| | `mcp/orbit_mcp_server.py` | `orbit_search()` | `.table(\"memory_turns\")` | `SliceEnforcingClient` | | `mcp/orbit_mcp_server.py` | `orbit_context()` | `.table(\"memory_turns\")` | `SliceEnforcingClient` | | `slice/anchor.py` | `resolve_explicit()` | `.table(\"memory_turns\")` | Validate via Graph Kernel | | `slice/anchor.py` | `resolve_from_session()` | `.table(\"memory_turns\")` | Graph Kernel validation | | `ingestion/primitive_enricher.py` | Insert | Direct insert | Add provenance metadata | | `ingestion/prompt_ingester.py` | Insert | Direct insert | Add provenance metadata | | `ingestion/embedder.py` | Update | Metadata update | Graph Kernel enrichment API | | `ml/cognitivetwin_v3/ingest/supabase_extractor.py` | `extract_all_turns()` | Bulk extract | Filter via Graph Kernel | | `retrieval/query.py` | `MemoryRetriever.search()` | Default search | Require explicit mode | | `retrieval/query.py` | `_text_search()` | Fallback search | Add admissibility marking | | `retrieval/query.py` | `get_similar_conversations()` | RPC search | Filter by slice |\n\nThe Agent SDK provides 4 Graph Kernel tools in `core/cc-agent-sdk/src/tools/graph_kernel.ts`:", "htmlHref": "/research/html/graph-kernel-full-integration-architecture-1gg7sdh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1117 }, { "id": "phase-0-validation-project-charter-1k7xljn", "title": "Phase 0 Validation - Project Charter", "slug": "phase-0-validation-project-charter", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/architecture/23-ANTICIPATORY_TRANSFORMER_PHASE0_CHARTER.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Workspace document requiring curation.", "excerpt": "### 1.1 Statement Must provide empirical validation of core Anticipatory Transformer components on small scale (2M parameter model) to prove: 1. Dual-pathway architecture achieves frequency separation (fast: syntax/local, slow: semantics/global) 2. Orthogonality penalty prevents mode collapse while maintaining specialization 3. Trajectory-aware attention with additive bias is numerically stable and improves context efficiency 4. Commitment targets (counterfactual stability) correlate with generation quality 5. Kernel slice-based context selection outperforms fixed-window baselines\n\n### 1.2 Falsifiability If any core component fails validation (e.g., pathways collapse to identical representations, commitment targets are uncorrelated with quality), the architecture requires fundamental revision before full-scale implementation.\n\n### 2.1 Must not attempt full-scale training Phase 0 is validation only. Full training requires Phase 1+ with proper infrastructure.\n\n### 2.2 Must not optimize for production metrics Validation targets correctness and feasibility, not state-of-the-art performance.\n\n### 2.3 Must not implement all features Only core architectural components required for validation. Advanced features (regime detection, slice cross-attention) are Phase 1+.", "htmlHref": "/research/html/phase-0-validation-project-charter-1k7xljn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 466 }, { "id": "rag-architecture-diagram-5i2gyb", "title": "RAG++ Architecture Diagram", "slug": "rag-architecture-diagram", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/architecture/diagrams/rag-architecture.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "```mermaid flowchart TB subgraph Sources [Data Sources] Claude[Claude Desktop
Response Hooks] Cursor[Cursor/Codex
IDE Integration] Echelon[Echelon Engine
Trajectory Segments] Studio[CC Studio
Session Logs] AgentSDK[Agent SDK
Programmatic Access] end", "excerpt": "**Version**: 2.1.0 **Last Updated**: 2026-01-03 **Parent**: [08-RAG_PLUS_PLUS.md](../08-RAG_PLUS_PLUS.md)\n\nInverse Ring Contextual Propagation computes attention weights based on trajectory distance:\n\n| Factor | Default Weight | Description | |--------|----------------|-------------| | recency | 0.3 | Time since creation | | depth | 0.2 | Conversation depth | | impact | 0.3 | Measured influence | | role | 0.2 | User > Assistant > System |\n\n| Endpoint | Method | Purpose | |----------|--------|---------| | `/api/rag/health` | GET | Health check | | `/api/rag/ingest` | POST | Ingest turn | | `/api/rag/search` | GET | Semantic search | | `/api/rag/context/{project_id}` | GET | Project context | | `/api/rag/signature` | GET | Style signature | | `/api/rag/train` | POST | Trigger training |\n\n| Tool | Purpose | |------|---------| | `rag_search` | Search memory fabric | | `rag_context` | Get project context | | `rag_style_signature` | Get style signature |", "htmlHref": "/research/html/rag-architecture-diagram-5i2gyb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 837 }, { "id": "graph-kernel-comprehensive-evaluation-report-1fzor44", "title": "Graph Kernel Comprehensive Evaluation Report", "slug": "graph-kernel-comprehensive-evaluation-report", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/GRAPH-KERNEL-EVALUATION-REPORT.md", "extension": "md", "score": 46, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**OpenClaw CompCore — Technical Evaluation** **Version:** 1.0.0 · **Date:** 2026-02-13 **Authors:** Mohamed Diomande, OpenClaw Research **Classification:** Internal Technical Report", "excerpt": "**OpenClaw CompCore — Technical Evaluation** **Version:** 1.0.0 · **Date:** 2026-02-13 **Authors:** Mohamed Diomande, OpenClaw Research **Classification:** Internal Technical Report\n\nThe OpenClaw Graph Kernel (GK) is a deterministic context slicing engine implemented as a single Rust binary (Axum/Tokio) that serves a dual purpose: (1) constructing reproducible, policy-governed, HMAC-signed context windows for autonomous AI agents, and (2) operating as a lightweight knowledge graph triple store over a PostgreSQL backend.\n\nWe evaluated the Graph Kernel against three baseline retrieval methods (keyword search, BM25, and RAG++ vector similarity) across 27 queries spanning five categories. Additionally, we performed an extensive comparative analysis against nine industry-grade graph databases, knowledge graph frameworks, and RAG orchestrators: **Neo4j, Amazon Neptune, Apache Jena/Fuseki, Dgraph, TypeDB, Weaviate, LangChain/LlamaIndex Knowledge Graphs, Microsoft GraphRAG, and Zep**.\n\n1. **Context Slicing is Irreplaceable.** No evaluated alternative provides deterministic, HMAC-signed, policy-governed context window construction. This is the Graph Kernel's unique value proposition and cannot be replicated by bolting features onto general-purpose graph databases.\n\n2. **Multi-hop Reasoning Achieves Perfect Relevance.** The GK achieves 1.00 relevance on multi-hop traversal queries, returning *structurally connected* knowledge chains rather than keyword-coincidence result sets. This is qualitatively distinct from high relevance scores achieved by text-matching baselines.", "htmlHref": "/research/html/graph-kernel-comprehensive-evaluation-report-1fzor44.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4905 }, { "id": "how-it-all-fits-bbdn5s", "title": "How It All Fits", "slug": "how-it-all-fits", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/01-system-overview/how-it-all-fits.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "This page is the architecture decision map after auditing the source. It replaces the older explanation that treated `LIM-RPS`, SAN, and diffusion as one completed trained stack.", "excerpt": "This page is the architecture decision map after auditing the source. It replaces the older explanation that treated `LIM-RPS`, SAN, and diffusion as one completed trained stack.\n\nThe system is built around an intermediate body state, not around raw sensors and not around a single opaque model.\n\nThis is still the right direction. The correction is that the current source does not prove one fully trained, end-to-end architecture. It proves several connected runtime pieces with different maturity levels.\n\n- `EchelonCore`: Rust real-time brain state and latent/lexicon generation. - `LatentUpdater`: selectable update backend inside `cc-brain`. - `SANPipeline`: Rust neural pipeline exposed through FFI and wrapped by `SANService`. - `DiffusionService`: Swift/CoreML generation service with phone hub, CoreML, and rule-based fallback paths. - `ClaimBridge`: Rust/Swift bridge from dynamics to N'Ko-style motion claims. - MotionMix BodyTruth: shared body-state bus being stabilized for Mac4/K11.\n\nThe docs should say \"these layers coordinate\" rather than \"one model learned the whole body-to-music system.\"", "htmlHref": "/research/html/how-it-all-fits-bbdn5s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 703 }, { "id": "what-is-computational-choreography-1ncsh7", "title": "What Is Computational Choreography?", "slug": "what-is-computational-choreography", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/01-system-overview/what-is-this.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Computational choreography is the LUME/MotionMix idea that body motion is not only something to record. It is a live control signal for sound, visuals, camera direction, DJ commands, and eventually motion inscription.", "excerpt": "Computational choreography is the LUME/MotionMix idea that body motion is not only something to record. It is a live control signal for sound, visuals, camera direction, DJ commands, and eventually motion inscription.\n\nThe current system is not one finished neural model. It is a set of connected runtime lanes:\n\n- MotionMixApp on iPhone: Swift shell, Rust `cc-echelon` core, SAN service, camera node, sensor logging, optional CoreML generation. - Comp-Core: Rust crates for Echelon brain/audio/motion bridge, semantic inscription, and N'Ko language infrastructure. - Mac4/K11: Unity visuals, mocopi/Mega/Bolt/body feeds, MotionMix hub, AirDeck Rekordbox safety bridge. - Computational choreography docs: explanation layer. These docs must follow the source, not invent names that the source does not support.\n\nThe system converts body signals into compact state and uses that state to drive generative behavior in real time.\n\n- `MotionMixApp/Services/EchelonBridge.swift` - `MotionMixApp/Services/SANService.swift` - `MotionMixApp/Services/SANTrajectoryLogger.swift` - `MotionMixApp/Services/DiffusionService.swift` - `MotionMixApp/Services/ClaimBridgeService.swift` - `Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/` - `Comp-Core/core/semantic/cc-inscription/` - `Comp-Core/core/semantic/cc-semantic-language/`", "htmlHref": "/research/html/what-is-computational-choreography-1ncsh7.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 690 }, { "id": "dell-architecture-audit-w33h3b", "title": "DELL Architecture Audit", "slug": "dell-architecture-audit", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/03-latent-representation/dell-architecture.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "DELL means Dual Equilibrium Latent Learning. It exists in the Comp-Core Rust source, but older docs overstated what is proven about it.", "excerpt": "DELL means Dual Equilibrium Latent Learning. It exists in the Comp-Core Rust source, but older docs overstated what is proven about it.\n\n- `Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/latent/dell.rs` - `Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/latent/mod.rs` - `MotionMixApp/Services/EchelonBridge.swift`\n\n- default dimension around 32; - `num_limbs = 27`; - fast equilibrium iterations; - slow equilibrium iterations; - fast/slow state; - synthetic limb embedding generation from available sensor data.\n\nThe important source caveat is in `dell.rs`: the current implementation creates synthetic embeddings from available sensor data, while production-quality limb embeddings would come from the sensor fusion pipeline.\n\nThat means the docs can describe DELL as an implemented backend, but not as a fully proven, trained, full-body production foundation.", "htmlHref": "/research/html/dell-architecture-audit-w33h3b.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 494 }, { "id": "training-and-learning-source-grounded-overview-92iczu", "title": "Training And Learning - Source-Grounded Overview", "slug": "training-and-learning-source-grounded-overview", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/05-training-and-learning/overview.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. **data capture** - MotionMixApp logs 128D SAN input and output frames; 2. **model training** - an offline process that must produce weight artifacts and validation evidence.", "excerpt": "1. **data capture** - MotionMixApp logs 128D SAN input and output frames; 2. **model training** - an offline process that must produce weight artifacts and validation evidence.\n\nThe code proves capture and runtime loading exist. It does not, by itself, prove the current models are well trained.\n\nBut `MASTER-TASKS.md` describes the CoreML generation models as shell/zero-init placeholders at that checkpoint, so quality must be re-verified before claiming trained generation.\n\n- exact training data path; - frame count; - train/validation split; - training script path; - checkpoint path; - exported `san_weights.bin` and `san_manifest.json`; - parameter count; - validation metrics; - on-device load count; - live non-flat output; - `mixFactor` greater than zero in the behavior being evaluated.\n\n- exact training data path; - proof that `ConditioningEncoder` is not a placeholder; - proof that `FlowGenerator1Step` is not a placeholder; - output token-grid sanity checks; - comparison against rule-based fallback; - latency on device.", "htmlHref": "/research/html/training-and-learning-source-grounded-overview-92iczu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 427 }, { "id": "architecture-alignment-nko-maoe-motion-lume-cc-and-airdeck-1tlx9h8", "title": "Architecture Alignment - N'Ko, MAOE, Motion, LUME CC, and AirDeck", "slug": "architecture-alignment-nko-maoe-motion-lume-cc-and-airdeck", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "computational-choreography/07-nko-synthesis/architecture-alignment.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "This folder uses N'Ko as an architectural and cultural reference point, not as a required dependency for AirDeck or MotionMix gesture control.", "excerpt": "This folder uses N'Ko as an architectural and cultural reference point, not as a required dependency for AirDeck or MotionMix gesture control.\n\nIt also uses N'Ko as an implemented inscription layer. The important distinction is:\n\nThose two lanes share operator culture and future convergence goals, but they are not the same model.\n\n- N'Ko Trajectory CTC anchor in `Desktop/nko-brain-scanner`. - Reported result: 20.57% CER on the locked local reproduction. - Mechanism: trajectory-biased Transformer CTC. - Key components: - `UnifiedCTCHead` - `AudioTrajectoryScalars` - `TrajectoryBiasNetwork` - `TrajectoryTransformerLayer`\n\n- MAOE-NKo bridge in `Desktop/Comp-Core/experiments/agp_mlx/asr_bridge`. - It routes already-produced ASR chunks into authority partitions: - stable - boundary - uncertain - recovery - novelty - It controls when AGP / retrieval / correction proposals are allowed. - It has not yet proven `CER after MAOE < CER before MAOE` on a full same-snapshot replay.", "htmlHref": "/research/html/architecture-alignment-nko-maoe-motion-lume-cc-and-airdeck-1tlx9h8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 892 }, { "id": "parallel-architecture-patterns-1cyd03z", "title": "Parallel Architecture Patterns", "slug": "parallel-architecture-patterns", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "computational-choreography/07-nko-synthesis/parallel-architectures.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The old page said \"N'Ko CTC and LIM-RPS\" as if both were equally canonical runtime architectures. That was misleading. The corrected comparison is:", "excerpt": "The movement stack and the N'Ko ASR stack are related by pattern, not by shared implementation.\n\nThe old page said \"N'Ko CTC and LIM-RPS\" as if both were equally canonical runtime architectures. That was misleading. The corrected comparison is:\n\n| Aspect | Movement / MotionMix / LUME CC | N'Ko ASR / inscription | | --- | --- | --- | | Input | camera, IMU, mocopi, watch, depth/body evidence | audio/acoustic frames | | Current runtime anchor | EchelonCore + LatentUpdater + SAN/ClaimBridge lanes | trajectory-biased Transformer CTC ASR anchor | | Routing/correction | SAN layers, BodyTruth, AirDeck safety, future routing work | MAOE-style post-ASR correction/admissibility routing | | Output | body state, audio params, visual params, DJ intent, motion claims | character sequence, telemetry, correction decisions | | Cultural grounding | embodied movement and performance practice | Mande/N'Ko phonology and writing |\n\n- body motion is continuous but must produce stable command/audio/visual intent; - speech is continuous but must produce stable N'Ko text.\n\n- temporal context; - confidence/freshness; - boundary handling; - recovery when tracking or recognition fails; - protection against generic priors overwriting the source signal.", "htmlHref": "/research/html/parallel-architecture-patterns-1cyd03z.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 380 }, { "id": "linkit-post-mvp-advanced-features-overview-14cfq5p", "title": "LinkIt — Post-MVP Advanced Features Overview", "slug": "linkit-post-mvp-advanced-features-overview", "kind": "architecture", "program": "Research Backlog", "sourceAnchor": "LinkIt/docs/phases/14-19-advanced/POST_MVP_OVERVIEW.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "These phases are extracted from the qr-dynamic reference implementation: - **Source Location:** `[home]/Desktop/qr-dynamic` - **Full Specification:** `[home-path]`", "excerpt": "**Document ID:** LINKIT-PHASE-14-19 **Version:** 1.0.0 **Last Updated:** 2026-01-16 **Status:** Documentation Complete\n\nThese phases are extracted from the qr-dynamic reference implementation: - **Source Location:** `[home]/Desktop/qr-dynamic` - **Full Specification:** `[home-path]`\n\nPhases 14-19 extend LinkIt with advanced dynamic link features, following a **metarecursive** design pattern where each phase builds upon the previous.\n\n| Phase | Name | Key Deliverables | Dependencies | |-------|------|------------------|--------------| | 14 | Dynamic Link Foundation | Short codes, redirects, dual URLs | MVP Complete | | 15 | Schedule Rules Engine | Timezone-aware time-based routing | Phase 14 | | 16 | Device Rules Engine | Device/browser/OS-based routing | Phase 15 | | 17 | Advanced Landing Pages | JSON content builder, 10 section types | Phase 16 | | 18 | Enhanced Analytics | Scans, views, charts, CSV export | Phase 17 | | 19 | QR Code Generation | Customizable designs, bulk download | Phase 18 |\n\n1. **Phase N depends on Phase N-1** — Cannot implement Phase 15 without Phase 14 2. **Task N.M depends on Task N.(M-1)** — Within a phase, tasks are sequential 3. **Sub-tasks build incrementally** — Database → Service → API → UI", "htmlHref": "/research/html/linkit-post-mvp-advanced-features-overview-14cfq5p.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 673 }, { "id": "k11-production-system-architecture-master-plan-ap4of5", "title": "K11 Production System Architecture -- Master Plan", "slug": "k11-production-system-architecture-master-plan", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/k11-production-plan.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "_Generated 2026-04-27 via Evo3 (Research -> 6 Divergent Paths -> Compound Synthesis -> Expand + Master Plan)._ _Full evolution output: Desktop/evo-cube-output/k11-production-system-architecture/_", "excerpt": "_Generated 2026-04-27 via Evo3 (Research -> 6 Divergent Paths -> Compound Synthesis -> Expand + Master Plan)._ _Full evolution output: Desktop/evo-cube-output/k11-production-system-architecture/_\n\n**Three-tier hybrid architecture** combining NSSM services for headless publishers, Task Scheduler for GPU-bound Unity, and Sony's native mocopi PC app for BT sensor management. New LUMM wire format (0x4C554D4D) carries 27-bone skeletal data as a 772-byte fixed datagram on :9702.\n\nRejected alternatives: - Monolith (everything in Unity) -- kills audio latency win, no cross-machine flexibility - Docker -- USB/BT passthrough impossible, massive overkill for 3 Python scripts - MotionMix-centric (K11 as sensor bridge) -- breaks product premise of self-contained hardware - Full microservice (Unity as NSSM service) -- GPU inaccessible from Session 0\n\n| Port | Protocol | Wire Format | Producer | Consumer(s) | |------|----------|-------------|----------|-------------| | 9700 | UDP | LUMD (0x4C554D44, 40B hdr) | pointcloud_pub.py | Unity LumeUdpReceiver, Tailscale mesh | | 9701 | UDP | LUMF (0x4C554D46, 84B fixed) | audio_pub.py | Unity LumeAudioFftReceiver, Tailscale mesh | | 9702 | UDP | LUMM (0x4C554D4D, 772B fixed) | mocopi_bridge.py | Unity LumeMocopiReceiver, MotionMix iOS | | 12351 | UDP | Sony binary (skdf+fram) | Sony mocopi PC app | mocopi_bridge.py (localhost only) |\n\nBone ordering: Sony mocopi IDs 0-26 (root, spine, chest, neck, head, shoulders, arms, hands, legs, feet, toes, fingers).", "htmlHref": "/research/html/k11-production-system-architecture-master-plan-ap4of5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1340 }, { "id": "the-script-that-machines-can-t-read-j31iym", "title": "The Script That Machines Can't Read", "slug": "the-script-that-machines-can-t-read", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/posts/01-the-script-machines-cant-read.md", "extension": "md", "score": 46, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "*How an 8-billion-parameter AI reveals the cost of digital language exclusion, and how 290,000 speech samples prove the fix was designed in 1949*", "excerpt": "*How an 8-billion-parameter AI reveals the cost of digital language exclusion, and how 290,000 speech samples prove the fix was designed in 1949*\n\nIn 1949, in the city of Kankan, Guinea, a self-taught linguist named Solomana Kante did something extraordinary. Frustrated by a claim he'd read, that African languages were inherently unsuitable for writing, he sat down and designed a writing system from scratch.\n\nKante was a speaker of Manding, a family of closely related languages spoken by over 40 million people across West Africa. Bambara in Mali, Maninka in Guinea, Dioula in Cote d'Ivoire, Mandinka in The Gambia. These languages had been written in Arabic script (called Ajami) for centuries, and in Latin script since colonization. But neither system was designed for them. Arabic doesn't capture Manding's vowel distinctions. Latin doesn't encode its tonal system. Both force the language into a container that doesn't quite fit.\n\nKante wanted something precise. Something built from the ground up for how Manding languages actually work.\n\nWhat he created was N'Ko (ߒߞߏ), which literally means \"I say\" in all Manding languages. The name itself is a statement: this script belongs to the people who speak these languages.", "htmlHref": "/research/html/the-script-that-machines-can-t-read-j31iym.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 13214 }, { "id": "the-script-that-machines-can-t-read-oe8pjh", "title": "The Script That Machines Can't Read", "slug": "the-script-that-machines-can-t-read", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/index.md", "extension": "md", "score": 46, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "In 1949, in the city of Kankan, Guinea, a self-taught linguist named Solomana Kante did something extraordinary. Frustrated by a claim he'd read, that African languages were inherently unsuitable for writing, he sat down and designed a writing system from scratch.", "excerpt": "In 1949, in the city of Kankan, Guinea, a self-taught linguist named Solomana Kante did something extraordinary. Frustrated by a claim he'd read, that African languages were inherently unsuitable for writing, he sat down and designed a writing system from scratch.\n\nKante was a speaker of Manding, a family of closely related languages spoken by over 40 million people across West Africa. Bambara in Mali, Maninka in Guinea, Dioula in Cote d'Ivoire, Mandinka in The Gambia. These languages had been written in Arabic script (called Ajami) for centuries, and in Latin script since colonization. But neither system was designed for them. Arabic doesn't capture Manding's vowel distinctions. Latin doesn't encode its tonal system. Both force the language into a container that doesn't quite fit.\n\nKante wanted something precise. Something built from the ground up for how Manding languages actually work.\n\nWhat he created was N'Ko (ߒߞߏ), which literally means \"I say\" in all Manding languages. The name itself is a statement: this script belongs to the people who speak these languages.\n\nN'Ko has 27 base characters. Each one maps to exactly one sound. There are no silent letters. No irregular spellings. No ambiguous pronunciations. If you see a character, you know how to pronounce it. If you hear a sound, you know how to write it. The script includes explicit diacritical marks for the three tonal levels (high, low, mid) that distinguish meaning in Manding. The word \"ba\" can mean mother, goat, or river depending on tone. In N'Ko, each one is written differently. In Latin script, they look identical.", "htmlHref": "/research/html/the-script-that-machines-can-t-read-oe8pjh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 9889 }, { "id": "data-pipeline-consolidation-python-vs-rust-ps4myq", "title": "Data Pipeline Consolidation - Python vs Rust", "slug": "data-pipeline-consolidation-python-vs-rust", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/01-architecture/DATA_PIPELINE_CONSOLIDATION.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Purpose**: Music download & processing **Size**: Full-featured music library management **Components**: ``` core/cc-ml/data_pipeline/ ├── downloaders/ │ ├── youtube_downloader.py # yt-dlp wrapper │ └── music_list_processor.py # YouTube search ├── processors/ │ └── audio_processor.py # pydub conversion ├── storage/ │ └── local_music_database.py # JSON database └── pipeline/ └── music_pipeline.py # Orchestration ```", "excerpt": "**Date**: 2025-12-17 **Question**: Should we consolidate YouTube download to Rust?\n\n**Purpose**: Music download & processing **Size**: Full-featured music library management **Components**:\n\n**Dependencies**: - `yt-dlp` (YouTube downloader) - `pydub` (audio conversion) - Python ecosystem\n\n**What it does**: 1. Search YouTube for tracks 2. Download audio with yt-dlp 3. Convert to WAV with pydub 4. Store in JSON database 5. Upload to GCS\n\n**Purpose**: Motion sensor data processing (NOT music!) **Size**: 16,198 bytes (400 lines) **What it does**:", "htmlHref": "/research/html/data-pipeline-consolidation-python-vs-rust-ps4myq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1394 }, { "id": "music-pipeline-architecture-placement-integration-strategy-1akts5y", "title": "Music Pipeline Architecture - Placement & Integration Strategy", "slug": "music-pipeline-architecture-placement-integration-strategy", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/01-architecture/MUSIC_PIPELINE_ARCHITECTURE.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` comp-core/ ├── core/ │ ├── cc-core/ # JAX/Flax equilibrium algorithms (motion processing) │ ├── cc-ml/ # ML models & data pipeline ← MUSIC ALREADY HERE │ │ └── data_pipeline/ │ │ ├── downloaders/ # YouTube, music list processing │ │ ├── pipeline/ # music_pipeline.py, parallel_pipeline.py │ │ ├── processors/ # Audio processing │ │ └── storage/ # Local music database │ └── cc-trajectory/ # Trajectory prediction (4GB) │ ├── apps/ │ └── desktop/ │ └── cc-echelon/ # Rust music control (879MB) │ └── crates/ # 20+ Rus", "excerpt": "**Date**: 2025-12-17 **Decision**: Where should the music analysis pipeline live?\n\n1. **Python (cc-ml/data_pipeline)**: Download, conversion, storage 2. **Rust (cc-echelon)**: Real-time audio engine, media handling, phrase intelligence\n\n**Why Python:** - librosa, essentia, aubio are Python libraries - Heavy DSP/ML computation (not latency-critical) - Easy integration with existing download pipeline - Rich ecosystem for audio analysis\n\n### Phase 3-4 (Smart Organization & Playlists) → `apps/desktop/cc-echelon/crates/music-brain/`\n\n**Why Rust:** - Real-time playlist generation (latency-critical) - Integration with existing audio-engine - Efficient data structures (BTreeMap for key lookups) - Multi-threading for playlist search - Export to binary DJ software formats", "htmlHref": "/research/html/music-pipeline-architecture-placement-integration-strategy-1akts5y.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1438 }, { "id": "echelon-architecture-alignment-brief-6bw6i1", "title": "Echelon Architecture Alignment Brief", "slug": "echelon-architecture-alignment-brief", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/echelon/echelon_architecture_alignment.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Workspace document requiring curation.", "excerpt": "## Purpose - Align the new Rust-based performance instrument plan with existing Computational Studio capabilities and Episode 1 assets before parallel implementation starts. - Document reuse targets, gaps, and decision points so engine, AI, UI, and ops teams can execute in lockstep.\n\n## Product Scope & Surface - Target the **Standalone Rust DAW** as the primary experience to deliver the differentiated real-time control surface, while preserving a clear integration path for the **Serato/Ableton bridge** as outlined in the product tiers (`Echelon.md` lines 190-206). - Maintain compatibility hooks for the future **cloud rehearsal companion** so nightly training loops can progress without blocking the on-device release (`Echelon.md` lines 207-214, 236-239). - Frame the user journey around rehearsal → preparation → live performance → computational rehearsal so feature priorities reflect the promised flow (`Echelon.md` lines 219-238).\n\n## Workspace Layout (Rust) - `apps/studio` orchestrates threads and runtime wiring. - Core crates: `audio-engine`, `scheduler`, `ui-shell`, `control-bus`, `media`, `midi-osc`, `dsp-utils`, `link-clock`, `ts-shift`, `shmem-ipc`, `viz`. - `xtask` hosts developer tooling; `docs/` captures plans/to-dos; configs live under `apps/studio/src/config`. - Sidecars will reside in `sidecars/` and are bridged via `shmem-ipc` once implemented.\n\n## Visualization Concept (crates/viz) - Follow `docs/visualize.md` to render the latent manifold, beat phase, solver residual, slow attractor, and limb energies without disturbing the audio thread. - Default projector weights live at `configs/visualization/projector.json`; override via `ECHELON_VIZ_PROJECTOR`. - Extend `control-bus` with `FastState`, `SlowState`, and `Telemetry` snapshots; scheduler publishes decimated frames to a dedicated ring buffered for the viz subscriber. - Provide both embedded (egui widget) and standalone window modes so Studio can ship headless or with an instrument-grade monitor.\n\n## Current Assets & Reuse - Computational Studio already hits real-time fusion, audio bridge, and telemetry targets (<10 ms pipeline, multi-device sensor handling, OSC/Ableton integration) that form the backbone for Echelon control and monitoring (`computational-studio/README.md` lines 9-99, 121-125). - Episode 1 delivered 35+ modules, logging/replay infrastructure, and the DELL motion interpreter that can be wrapped rather than rewritten (`EPISODE1_OVERVIEW.py` lines 27-84, 59-62, 74-82). - The DJ Agent work provides mature safety policies, action scheduling, and automation tests that should be ported into Rust to accelerate quantization and deck protection (`COMPLETE_IMPLEMENTATION_SUMMARY.txt` lines 21-49, 63-74, 144-149).", "htmlHref": "/research/html/echelon-architecture-alignment-brief-6bw6i1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 675 }, { "id": "linkit-post-mvp-advanced-features-overview-1mb9tec", "title": "LinkIt — Post-MVP Advanced Features Overview", "slug": "linkit-post-mvp-advanced-features-overview", "kind": "architecture", "program": "Research Backlog", "sourceAnchor": "projects/LinkIt/docs/phases/14-19-advanced/POST_MVP_OVERVIEW.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "These phases are extracted from the qr-dynamic reference implementation: - **Source Location:** `[home]/Desktop/qr-dynamic` - **Full Specification:** `[home-path]`", "excerpt": "**Document ID:** LINKIT-PHASE-14-19 **Version:** 1.0.0 **Last Updated:** 2026-01-16 **Status:** Documentation Complete\n\nThese phases are extracted from the qr-dynamic reference implementation: - **Source Location:** `[home]/Desktop/qr-dynamic` - **Full Specification:** `[home-path]`\n\nPhases 14-19 extend LinkIt with advanced dynamic link features, following a **metarecursive** design pattern where each phase builds upon the previous.\n\n| Phase | Name | Key Deliverables | Dependencies | |-------|------|------------------|--------------| | 14 | Dynamic Link Foundation | Short codes, redirects, dual URLs | MVP Complete | | 15 | Schedule Rules Engine | Timezone-aware time-based routing | Phase 14 | | 16 | Device Rules Engine | Device/browser/OS-based routing | Phase 15 | | 17 | Advanced Landing Pages | JSON content builder, 10 section types | Phase 16 | | 18 | Enhanced Analytics | Scans, views, charts, CSV export | Phase 17 | | 19 | QR Code Generation | Customizable designs, bulk download | Phase 18 |\n\n1. **Phase N depends on Phase N-1** — Cannot implement Phase 15 without Phase 14 2. **Task N.M depends on Task N.(M-1)** — Within a phase, tasks are sequential 3. **Sub-tasks build incrementally** — Database → Service → API → UI", "htmlHref": "/research/html/linkit-post-mvp-advanced-features-overview-1mb9tec.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 673 }, { "id": "sea-3-1-complete-1cokm1c", "title": "SEA-3.1-COMPLETE", "slug": "sea-3-1-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-3.1-COMPLETE.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "- File: `[home-path]` — **created** (220 lines) - Imports `load_embeddings()` + `call_ollama_embedding()` from embedding_indexer.py - `route_message()` — vectorized cosine similarity, returns ranked candidates with tier labels - `FAST_PASS_THRESHOLD = 0.6` for high-confidence fast routing - `run_validation()` — 15-case routing accuracy suite - CLI: `--message`, `--threshold`, `--top-k`, `--validate`, `--json`", "excerpt": "## Summary Extended Tier 2 scoring to all 13 SEA skill entities. Built `tier2_scorer.py` with rich skill descriptions, hot/cold topic injection from state.json, and a 15-case validation suite covering every skill. Also built `tier1_router.py` (embedding-based fast routing) as the prerequisite Tier 1 component. All 13 profiles validate cleanly in dry-run mode.\n\n## Changes - File: `[home-path]` — **created** (380 lines) - Scoring prompt template (battle-tested from SEA-0.2 benchmark) - Rich `SKILL_DESCRIPTIONS` dict for all 13 skills (derived from SKILL.md + state.json) - `score_skill()` / `score_skills()` — calls MiniMax with hot/cold topics from state.json - `_parse_score_json()` — robust JSON extraction with markdown/noise tolerance - `run_validation()` — 15-case suite testing all 13 skills against calibrated messages - `dry_run_profiles()` — offline validation of all skill profile loading - CLI: `--skill`, `--skills`, `--all`, `--validate`, `--dry-run`, `--json`\n\n- File: `[home-path]` — **created** (220 lines) - Imports `load_embeddings()` + `call_ollama_embedding()` from embedding_indexer.py - `route_message()` — vectorized cosine similarity, returns ranked candidates with tier labels - `FAST_PASS_THRESHOLD = 0.6` for high-confidence fast routing - `run_validation()` — 15-case routing accuracy suite - CLI: `--message`, `--threshold`, `--top-k`, `--validate`, `--json`\n\n| Skill | Description | Hot Topics | Cold Topics | Profile | |-------|-------------|------------|-------------|---------| | phi:veritas | Truth & intellectual integrity | truth-seeking, fact verification, discernment | intuition, revelation | OK | | phi:paradox | Contradictions & paradoxes | contradictions, assumption-challenging, ambiguity | hidden wisdom, tension | OK | | phi:metaphysical | Cosmic interconnectedness | interconnectedness, unity, cosmic harmony | vibrations, duality | OK | | art:creative | Idea generation & innovation | brainstorming, SCAMPER, innovation | mind mapping, creative feedback | OK | | art:convergent | Merging diverse ideas | merging ideas, consensus building, unification | collaborative synergy | OK | | art:divergent | Divergent thinking & branching | divergent thinking, multiple pathways | concept convergence | OK | | art:synthesis | Multi-method synthesis | triangulation, fractal/metaphor synthesis | hyper synthesis, causal synthesis | OK | | art:snark | Witty remarks & clever comebacks | witty remarks, game theory, strategic comm | payoff matrices, Nash equilibrium | OK | | art:movement | Embodied sensor-spatial interaction | embodied cognition, kinesthetic learning | gesture recognition | OK | | art:dj | Music composition & DJ | music composition, songwriting, soundscapes | genre blending | OK | | nav:nonlinear | Chaos navigation & uncertainty | chaos", "htmlHref": "/research/html/sea-3-1-complete-1cokm1c.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 510 }, { "id": "architecture-lens-what-we-judge-every-paper-against-1eg4jlw", "title": "ARCHITECTURE LENS — what we judge every paper against", "slug": "architecture-lens-what-we-judge-every-paper-against", "kind": "architecture", "program": "Research Practice", "sourceAnchor": "sota-loop/lens/ARCHITECTURE_LENS.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. **FIT** — which domain(s) below does it touch, and which named system of ours is the counterpart? 2. **DELTA** — what does the paper do that our counterpart does NOT do (and vice versa)? 3. **VERDICT** — one of: - `ABSORB` — their technique is better on some axis; name the exact file/module where it lands and what changes. - `TEST` — we built something comparable; define the head-to-head (their benchmark or ours, what metric, what would count as a win). - `RIVAL` — we already built something arguably ahead or di", "excerpt": "# ARCHITECTURE LENS — what we judge every paper against > Version 1.0 — 2026-06-12. This is the profile of Mohamed's live systems. > Every daily paper is mapped against these domains. If a paper doesn't touch > any domain, it is SKIP unless it is foundational enough to create a new domain > (in which case: propose the new domain in the report).\n\n1. **FIT** — which domain(s) below does it touch, and which named system of ours is the counterpart? 2. **DELTA** — what does the paper do that our counterpart does NOT do (and vice versa)? 3. **VERDICT** — one of: - `ABSORB` — their technique is better on some axis; name the exact file/module where it lands and what changes. - `TEST` — we built something comparable; define the head-to-head (their benchmark or ours, what metric, what would count as a win). - `RIVAL` — we already built something arguably ahead or different-but-stronger; write the claim with evidence (commits, metrics, dates). - `WATCH` — relevant, no action yet; state the trigger that would upgrade it to ABSORB/TEST. - `SKIP` — no domain fit. 4. **ACTION** — for ABSORB/TEST: one concrete first step small enough to start the same week.\n\nA verdict without a named system, a named file, or a falsifiable claim is invalid.\n\n## D1 — Agent skills: libraries, induction, typing, routing **Our systems:** SOOP-2 skills operating system (296 typed skills, `SKILL_TYPES_v1` 6-category algebra, `skill-typecheck` linter), SEA two-tier router (Tier 1 recall@30 = 1.00 on 214 skills, Tier 2 twin-primary scorer on Mac4:8100), `skill-forge` (auto-generates skills from session pattern mining), Cortex rule promotion. **Where they live:** `[home-path]`, `[home-path]`, `[home-path]`. **What would beat us:** automatic skill induction with verified composition guarantees; skill libraries that self-prune by utility; routing that beats recall@30=1.00 at lower cost; typed-composition checking richer than our 6-category algebra. **Known rivals already mapped:** SkillDAG, SkillOpt, MUSE-Autoskill, GraphOfSkills, SkillsBench (see `Desktop/code4ai-analysis/ANALYSIS.md`).\n\n## D2 — Trajectory reward, agentic RL, SFT from agent traces **Our systems:** KARL reward engine (6-signal composite, 3203 rescored records, score-at-emit via `flows-karl-writer`), cognitive twin SFT pipeline (`cognitive-forge`, 1049 SFT examples from distilled trajectories), trajectory cards from gateway events. **Where they live:** `Desktop/karl/`, `[home-path]`. **What would beat us:** process-reward models that outperform composite heuristic signals; trajectory filtering/credit-assignment methods with measured downstream SFT gains; online RL from agent traces that doesn't need human labels.", "htmlHref": "/research/html/architecture-lens-what-we-judge-every-paper-against-1eg4jlw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1030 }, { "id": "bwb-voice-ordering-system-5ndzu8", "title": "BWB — Voice Ordering System", "slug": "bwb-voice-ordering-system", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "spine/BWB/architecture/VOICE_SYSTEM.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "BWB features a sophisticated voice ordering system that uses on-device speech recognition and semantic NLU to process natural language coffee orders. The system runs entirely on-device for privacy and speed.", "excerpt": "BWB features a sophisticated voice ordering system that uses on-device speech recognition and semantic NLU to process natural language coffee orders. The system runs entirely on-device for privacy and speed.\n\n**How it works:** - Converts menu items to 300-dimensional vectors using Apple's NLEmbedding - Stores embeddings in VectorIndex for fast similarity search - Hybrid search: 60% semantic similarity + 40% fuzzy text matching\n\n**Key features:** | Feature | Description | |---------|-------------| | On-device | No external API calls | | Alias support | \"americano\" matches \"Iced Americano\" | | Abbreviations | \"latte\" finds all latte variants | | Typo tolerance | Fuzzy matching with Levenshtein distance |\n\n**Performance:** - Embedding initialization: ~500ms (once at startup) - Semantic search: <50ms (SIMD optimized) - Returns top-5 matches with confidence scores\n\n| Slot | Values | Example | |------|--------|---------| | size | small, medium, large, xl | \"large\" → size: large (0.98) | | temperature | hot, iced, blended | \"iced\" → temp: iced (0.97) | | milk | whole, skim, oat, almond, soy, coconut | \"with oat milk\" → milk: oat (0.95) | | caffeine | regular, decaf, half-caf | \"decaf\" → caffeine: decaf (0.92) | | shots | 1-6 | \"extra shot\" → shots: 2 (0.90) | | syrup | vanilla, caramel, hazelnut, etc. | \"vanilla\" → syrup: vanilla (0.88) | | quantity | 1-10 | \"two lattes\" → quantity: 2 (0.95) |", "htmlHref": "/research/html/bwb-voice-ordering-system-5ndzu8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1465 }, { "id": "architecture-1jljfbl", "title": "Architecture", "slug": "architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "trajectory-memory-ledger/docs/architecture.md", "extension": "md", "score": 46, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. Read `events-YYYY-MM-DD.jsonl` 2. Skip envelopes already covered by the date-scoped cursor 3. Group gateway envelopes by `flow_id` 4. Build one trajectory card per completed flow 5. Normalize the card to schema v2 6. Score it with the six-signal reward model 7. Append to the JSONL ledger under an exclusive file lock 8. Write cursor and Prometheus metrics atomically", "excerpt": "Trajectory Memory Ledger separates durable ingestion from research and training.\n\n1. Read `events-YYYY-MM-DD.jsonl` 2. Skip envelopes already covered by the date-scoped cursor 3. Group gateway envelopes by `flow_id` 4. Build one trajectory card per completed flow 5. Normalize the card to schema v2 6. Score it with the six-signal reward model 7. Append to the JSONL ledger under an exclusive file lock 8. Write cursor and Prometheus metrics atomically\n\nDaily event files may restart `seq` at 1. A global monotonic cursor would silently drop events after a date rollover.\n\n- batch extraction - SFT export - train/validation splits - reward ablations - selection experiments - model training and evaluation - paper metrics\n\nThis split keeps the operational collector reliable while leaving research tooling flexible.", "htmlHref": "/research/html/architecture-1jljfbl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 483 }, { "id": "writing-skills-jjlu7z", "title": "Writing Skills", "slug": "writing-skills", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anthropic-skills/claude-superpowers/skills/writing-skills/SKILL.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "You write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests pass (agents comply), and refactor (close loopholes).", "excerpt": "--- name: writing-skills description: Use when creating new skills, editing existing skills, or verifying skills work before deployment ---\n\n**Personal skills live in agent-specific directories (`[home-path]` for Claude Code, `[home-path]` for Codex)**\n\nYou write test cases (pressure scenarios with subagents), watch them fail (baseline behavior), write the skill (documentation), watch tests pass (agents comply), and refactor (close loopholes).\n\n**Core principle:** If you didn't watch an agent fail without the skill, you don't know if the skill teaches the right thing.\n\n**REQUIRED BACKGROUND:** You MUST understand superpowers:test-driven-development before using this skill. That skill defines the fundamental RED-GREEN-REFACTOR cycle. This skill adapts TDD to documentation.", "htmlHref": "/research/html/writing-skills-jjlu7z.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3204 }, { "id": "cc-anticipation-assumptions-invariants-ledger-16wzhrh", "title": "cc-anticipation: Assumptions & Invariants Ledger", "slug": "cc-anticipation-assumptions-invariants-ledger", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "anticipation-geometry/crates/anticipation/docs/INVARIANTS.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| Invariant Type | Response on Violation | |----------------|----------------------| | System Invariant | Panic in debug, log + refuse packet in release | | Architectural Assumption | Undefined behavior; document and escalate | | Computational Invariant | Assert in debug, silent corruption in release (must fix) | | Performance Invariant | Log warning, continue (track for optimization) | | Contract Invariant | Refuse emission, set dropped_reason | | Behavioral Invariant | Test failure, not runtime error |", "excerpt": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Parent**: [PROJECT_CHARTER.md](./PROJECT_CHARTER.md)\n\n**Enforcement**: Checksum comparison in replay harness. No parallel reductions, no random seeds, no system time in computation.\n\n**Enforcement**: Window ID includes t_end in hash. Aligner advances by fixed hop.\n\n**Enforcement**: Check at packet emission entry point. MIN_COVERAGE_THRESHOLD = 0.90 (configurable).\n\n**Enforcement**: Pre-allocated buffers, ring buffer reuse. Profile with allocator instrumentation.", "htmlHref": "/research/html/cc-anticipation-assumptions-invariants-ledger-16wzhrh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 977 }, { "id": "multi-agent-coordination-system-11vg89v", "title": "Multi-Agent Coordination System", "slug": "multi-agent-coordination-system", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/.governance/systems/MULTI_AGENT_COORDINATION.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Enable indefinite multi-agent coordination between Claude Code instances using file-based message passing, Orbit project management, and RAG++ trajectory memory—without requiring persistent context or human intermediation.", "excerpt": "**Version**: 1.1.0 **Created**: 2025-12-28 **Last Updated**: 2025-12-28 **Status**: PROVISIONAL → IMPLEMENTED\n\nEnable indefinite multi-agent coordination between Claude Code instances using file-based message passing, Orbit project management, and RAG++ trajectory memory—without requiring persistent context or human intermediation.\n\n**Falsifiable Success Criteria**: 1. Two Claude instances can exchange 10+ messages via file edits without human copy-paste 2. An agent resuming from context loss can reconstruct state within 3 tool calls 3. Cross-session decision continuity is maintained via ChainLink trajectories 4. Agent accomplishments are automatically logged to Orbit database\n\n- Real-time synchronous communication (we use async file polling) - Shared memory or IPC between instances (files are the only channel) - Automatic task scheduling (human orchestrates which agent runs when) - Replacing human judgment on architectural decisions\n\nFuture evolution must remain compatible with: - CLAUDE.md governance principles (anticipation over prediction) - Existing Orbit database schema - RAG++ ChainLink and Ring structures - File-based message protocol (no external services required)", "htmlHref": "/research/html/multi-agent-coordination-system-11vg89v.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2691 }, { "id": "trajectoryos-cc-tpo-unification-plan-1az8x3n", "title": "TrajectoryOS + CC-TPO Unification Plan", "slug": "trajectoryos-cc-tpo-unification-plan", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/guides/UNIFICATION_PLAN.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Goal**: Merge TrajectoryOS and CC-TPO into a single unified system with clean architecture, removing redundancies and creating clear service boundaries.", "excerpt": "**Goal**: Merge TrajectoryOS and CC-TPO into a single unified system with clean architecture, removing redundancies and creating clear service boundaries.\n\n1. **Duplicate Web Frontends**: - `apps/web-dashboard` (TrajectoryOS - skeletal) - `services/cc-tpo/cc-navigator` (CC-TPO - functional) - `services/cc-tpo/apps/liquid-chat-ui` (CC-TPO - different purpose) - `services/cc-tpo/apps/ircp-search-app` (CC-TPO - search focused)\n\n2. **Duplicate Backend APIs**: - `apps/api-gateway` (TrajectoryOS - partial) - `services/cc-tpo/apps/liquid-chat-backend` (CC-TPO - FastAPI) - Multiple search services in `services/cc-tpo/services/`\n\n3. **Duplicate Database Management**: - TrajectoryOS: Prisma + SQLite (not fully set up) - CC-TPO: SQLite databases with embeddings\n\n4. **Overlapping Agent Functionality**: - `services/agent-orchestrator` (TrajectoryOS - LLM interview) - CC-TPO chat/search capabilities (integrated into apps)", "htmlHref": "/research/html/trajectoryos-cc-tpo-unification-plan-1az8x3n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3416 }, { "id": "computational-choreography-conversation-analysis-training-plan-hlcqag", "title": "Computational Choreography Conversation Analysis & Training Plan", "slug": "computational-choreography-conversation-analysis-training-plan", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/plans/CC_CONVERSATION_ANALYSIS_PLAN.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Successfully extracted **32 conversations** (11.3% of dataset) specifically about Computational Choreography, containing **3,139 messages** (42.3% of all conversation data). This focused dataset is ideal for training a specialized DLM system for CC-related dialogue.", "excerpt": "Successfully extracted **32 conversations** (11.3% of dataset) specifically about Computational Choreography, containing **3,139 messages** (42.3% of all conversation data). This focused dataset is ideal for training a specialized DLM system for CC-related dialogue.\n\n| Metric | Value | |--------|-------| | **Total Conversations** | 32 | | **Total Messages** | 3,139 | | **User Messages** | 1,572 | | **Assistant Messages** | 1,567 | | **User:Assistant Ratio** | 1.00:1 (perfectly balanced!) | | **Average Messages/Conversation** | 98.1 |\n\n| Range | Count | Largest Topic | |-------|-------|---------------| | 300+ messages | 2 | LIM-RPS overview (356 msgs) | | 200-299 messages | 3 | Recursive polymodal synthesis | | 100-199 messages | 6 | Code implementation, Echelon | | 50-99 messages | 4 | U-Net, Audio processing | | < 50 messages | 17 | Various CC topics |\n\n| Model | Conversations | Notes | |-------|--------------|-------| | gpt-5-1 | 14 (44%) | Latest model, high quality | | gpt-5 | 14 (44%) | Solid performance | | auto | 3 (9%) | Mixed models | | gpt-4-5 | 1 (3%) | Beta model |\n\n### 1. LIM-RPS (Listening-Interaction-Movement Recursive Polymodal Synthesis) **Conversations**: 3 | **Messages**: 750 (23.9% of CC data)", "htmlHref": "/research/html/computational-choreography-conversation-analysis-training-plan-hlcqag.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2216 }, { "id": "conversation-data-analysis-plan-of50b8", "title": "Conversation Data Analysis Plan", "slug": "conversation-data-analysis-plan", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/plans/CONVERSATION_DATA_ANALYSIS_PLAN.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Total Conversations**: 282 - **Total Messages**: 7,469 - User Messages: 3,664 - Assistant Messages: 3,805 - **Time Range**: February 17, 2025 → December 8, 2025 (294 days) - **Average Messages per Conversation**: 26.5 - **Data Quality**: 281 non-empty conversations (99.6%)", "excerpt": "**File**: `data/conversations_new.json` **Size**: 63.8 MB **Format**: JSON array of conversation objects\n\n- **Total Conversations**: 282 - **Total Messages**: 7,469 - User Messages: 3,664 - Assistant Messages: 3,805 - **Time Range**: February 17, 2025 → December 8, 2025 (294 days) - **Average Messages per Conversation**: 26.5 - **Data Quality**: 281 non-empty conversations (99.6%)\n\n| Model | Conversations | |-------|--------------| | gpt-4o | 105 (37%) | | gpt-5 | 101 (36%) | | gpt-5-1 | 39 (14%) | | gpt-4-5 | 14 (5%) | | auto | 5 (2%) |\n\n| Length | Count | Percentage | |--------|-------|------------| | 1-5 messages | 119 | 42.2% | | 6-10 messages | 53 | 18.8% | | 11-20 messages | 38 | 13.5% | | 21-50 messages | 33 | 11.7% | | 50+ messages | 38 | 13.5% |\n\n1. **Tree Structure**: Conversations are stored as trees (mapping with parent/children) 2. **Node Types**: Includes system, user, and assistant messages 3. **Content**: Text stored in `content.parts` array 4. **Metadata Rich**: Extensive metadata (timestamps, moderation, memory scope, etc.)", "htmlHref": "/research/html/conversation-data-analysis-plan-of50b8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2054 }, { "id": "week-2-progress-summary-core-module-creation-sz37s4", "title": "Week 2 Progress Summary - Core Module Creation", "slug": "week-2-progress-summary-core-module-creation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/WEEK_2_PROGRESS_SUMMARY.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Week 2 focuses on creating the core DLM module with unified abstractions for coordinates, embeddings, and configuration. We're consolidating code from DLM, IRCP, and TPO packages while maintaining 100% backward compatibility.", "excerpt": "**Date:** 2025-12-07 **Status:** 🔵 In Progress (80% Complete) **Phases Completed:** 4 of 5\n\nWeek 2 focuses on creating the core DLM module with unified abstractions for coordinates, embeddings, and configuration. We're consolidating code from DLM, IRCP, and TPO packages while maintaining 100% backward compatibility.\n\n- **DLMCoordinate Model** (Pydantic BaseModel) - 5D coordinate system: x (depth), y (sibling), z (homogeneity), t (temporal), n_parts (complexity) - Rich metadata from TPO: depth_level, sibling_index, confidence - Tree structure tracking: parent, children - Distance calculations: Euclidean, Manhattan, cosine similarity - Conversions: to_dict(), to_tensor(), to_numpy()\n\n- **DLMCoordinateCalculator** - Ported from TPO's RCPCoordinateSystem - Enhanced with temporal (t) and complexity (n_parts) calculations - Normalization, caching, batch processing - Configurable homogeneity methods\n\n- **DLMCoordinateValidator** - Coordinate value validation - Tree structure validation - Relationship validation", "htmlHref": "/research/html/week-2-progress-summary-core-module-creation-sz37s4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1622 }, { "id": "cc-motiongen-model-architecture-reference-dtn9ja", "title": "CC-MotionGen Model Architecture Reference", "slug": "cc-motiongen-model-architecture-reference", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/ml/cc-ml/cc_motiongen/docs/technical/MODEL_ARCHITECTURE.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. [Architecture Overview](#architecture-overview) 2. [GaussianDiffusion](#gaussiandiffusion) 3. [UNet1D](#unet1d) 4. [MotionDecoder](#motiondecoder) 5. [Conditioning System](#conditioning-system) 6. [Motion Representation](#motion-representation) 7. [Inference Pipeline](#inference-pipeline)", "excerpt": "1. [Architecture Overview](#architecture-overview) 2. [GaussianDiffusion](#gaussiandiffusion) 3. [UNet1D](#unet1d) 4. [MotionDecoder](#motiondecoder) 5. [Conditioning System](#conditioning-system) 6. [Motion Representation](#motion-representation) 7. [Inference Pipeline](#inference-pipeline)\n\n| Component | Parameters | Location | Purpose | |-----------|------------|----------|---------| | GaussianDiffusion | - | `model/diffusion.py` | Noise scheduling, DDPM/DDIM sampling | | UNet1D | 116M | `model/unet.py` | Denoising network | | MotionDecoder | 2M | `model/decoder.py` | Semantic motion mapping | | AudioConditioner | ~2M | `model/conditioning.py` | FiLM conditioning | | MPMSConditioner | ~0.5M | `model/conditioning.py` | Memory context blending |\n\nThe diffusion process that defines the forward (noising) and reverse (denoising) processes.\n\n| Index | Name | Dimension | Description | Range | |-------|------|-----------|-------------|-------| | 0-2 | position | 3 | World-space position (x, y, z) | [-50, 50] | | 3-5 | velocity | 3 | Linear velocity (derived) | [-50, 50] | | 6-8 | acceleration | 3 | Linear acceleration (derived) | [-100, 100] | | 9-12 | quaternion | 4 | Orientation (w, x, y, z) | Unit sphere | | 13-15 | angular_velocity | 3 | Rotational velocity | [-10, 10] | | 16 | phase | 1 | Beat-aligned phase | [0, 1] per beat | | 17-24 | style | 8 | Learned style embedding | Unit sphere |\n\n| Property | Constraint | Threshold | |----------|------------|-----------| | Velocity coherence | \\|v - dp/dt\\| | < 5.0 | | Acceleration coherence | \\|a - dv/dt\\| | < 50.0 | | Jerk bound | \\|d³p/dt³\\| | < 50000 | | Quaternion continuity | q_t · q_{t+1} | > 0.95 | | Phase monotonicity | phase_{t+1} >= phase_t | Always |", "htmlHref": "/research/html/cc-motiongen-model-architecture-reference-dtn9ja.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1698 }, { "id": "cc-anticipation-assumptions-invariants-ledger-67f7xt", "title": "cc-anticipation: Assumptions & Invariants Ledger", "slug": "cc-anticipation-assumptions-invariants-ledger", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/motion/cc-anticipation/docs/INVARIANTS.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| Invariant Type | Response on Violation | |----------------|----------------------| | System Invariant | Panic in debug, log + refuse packet in release | | Architectural Assumption | Undefined behavior; document and escalate | | Computational Invariant | Assert in debug, silent corruption in release (must fix) | | Performance Invariant | Log warning, continue (track for optimization) | | Contract Invariant | Refuse emission, set dropped_reason | | Behavioral Invariant | Test failure, not runtime error |", "excerpt": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Parent**: [PROJECT_CHARTER.md](./PROJECT_CHARTER.md)\n\n**Enforcement**: Checksum comparison in replay harness. No parallel reductions, no random seeds, no system time in computation.\n\n**Enforcement**: Window ID includes t_end in hash. Aligner advances by fixed hop.\n\n**Enforcement**: Check at packet emission entry point. MIN_COVERAGE_THRESHOLD = 0.90 (configurable).\n\n**Enforcement**: Pre-allocated buffers, ring buffer reuse. Profile with allocator instrumentation.", "htmlHref": "/research/html/cc-anticipation-assumptions-invariants-ledger-67f7xt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 977 }, { "id": "cc-window-aligner-assumptions-invariants-ledger-nb9xaf", "title": "CC Window Aligner: Assumptions & Invariants Ledger", "slug": "cc-window-aligner-assumptions-invariants-ledger", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/motion/cc-window-aligner/docs/INVARIANTS.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Assumptions are conditions the system relies on that could be false. Each assumption includes detection and mitigation strategies.", "excerpt": "Assumptions are conditions the system relies on that could be false. Each assumption includes detection and mitigation strategies.\n\n**Assumption**: Device clocks have bounded drift (< 1ms/second) and do not jump discontinuously during a session.\n\n**What breaks if false**: Clock mapping becomes invalid. Canonical timestamps lose meaning. Resampling produces incorrect values.\n\n**Detection**: - Monitor clock mapping residuals over time - Detect if drift estimate changes by > 0.1ms/s within a window - Flag sessions where clock jumps are detected\n\n**Mitigation**: - Re-estimate clock mapping when drift exceeds threshold - Insert discontinuity marker and start new alignment epoch - Warn downstream consumers", "htmlHref": "/research/html/cc-window-aligner-assumptions-invariants-ledger-nb9xaf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1415 }, { "id": "rag-sota-improvements-qhso9y", "title": "RAG++ SOTA Improvements", "slug": "rag-sota-improvements", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/SOTA_IMPROVEMENTS.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. [Overview](#overview) 2. [Architecture](#architecture) 3. [SIMD Acceleration (P0)](#simd-acceleration-p0) 4. [Scalar Quantization - SQ8 (P1.1)](#scalar-quantization---sq8-p11) 5. [Product Quantization - PQ (P1.2)](#product-quantization---pq-p12) 6. [Parallel HNSW Construction (P2)](#parallel-hnsw-construction-p2) 7. [Hybrid Search - Dense + Sparse (P3)](#hybrid-search---dense--sparse-p3) 8. [Hybrid Query Engine (P4)](#hybrid-query-engine-p4) 9. [Benchmarks](#benchmarks) 10. [API Reference](#api-reference) 11. [M", "excerpt": "Technical documentation for state-of-the-art performance optimizations in RAG++ retrieval engine.\n\n1. [Overview](#overview) 2. [Architecture](#architecture) 3. [SIMD Acceleration (P0)](#simd-acceleration-p0) 4. [Scalar Quantization - SQ8 (P1.1)](#scalar-quantization---sq8-p11) 5. [Product Quantization - PQ (P1.2)](#product-quantization---pq-p12) 6. [Parallel HNSW Construction (P2)](#parallel-hnsw-construction-p2) 7. [Hybrid Search - Dense + Sparse (P3)](#hybrid-search---dense--sparse-p3) 8. [Hybrid Query Engine (P4)](#hybrid-query-engine-p4) 9. [Benchmarks](#benchmarks) 10. [API Reference](#api-reference) 11. [Migration Guide](#migration-guide)\n\nRAG++ now includes production-ready optimizations for high-performance retrieval:\n\n| Improvement | Benefit | Trade-off | |-------------|---------|-----------| | **SIMD (AVX2)** | 4-8x faster distance computation | x86_64 only | | **SQ8** | 4x memory reduction | <1% recall loss | | **PQ** | 32-128x memory reduction | 5-20% recall loss | | **Parallel HNSW** | 2-4x faster index build | More memory during build | | **Hybrid Search** | +10-20% recall on keyword queries | ~50% more latency |\n\n1. **Additive Changes**: All existing APIs remain unchanged 2. **Opt-in Performance**: New features are explicitly enabled 3. **Measurable Trade-offs**: Each optimization has documented recall/latency impact 4. **Composable**: Features can be combined (e.g., SQ8 + Hybrid)", "htmlHref": "/research/html/rag-sota-improvements-qhso9y.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2076 }, { "id": "pulse-plan-cognitive-twin-v2-decoupled-rlm-qwen-3-5-qk88oc", "title": "Pulse Plan: Cognitive Twin V2 — Decoupled RLM + Qwen 3.5", "slug": "pulse-plan-cognitive-twin-v2-decoupled-rlm-qwen-3-5", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/docs/PULSE-PLAN-COGTWIN-V2.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Benchmark results (March 4, 2026) using Qwen3-Next-80B-A3B via Together AI: - Config A (Bare): 29.5% → Config D (Full RLM): 93.6% - RAG is the biggest lever (+57.7%), RLM adds meaningful value on multi-hop (+3.9%) - API inference is fast (~1-2s/question) and free (Together serverless) - Target: 97%+ accuracy with fine-tuned Qwen3.5-35B-A3B on local exo cluster", "excerpt": "**Created:** 2026-03-04 **Status:** 🟢 ACTIVE **Priority:** HIGH **Estimated Duration:** 5 waves across 5 weeks\n\nBenchmark results (March 4, 2026) using Qwen3-Next-80B-A3B via Together AI: - Config A (Bare): 29.5% → Config D (Full RLM): 93.6% - RAG is the biggest lever (+57.7%), RLM adds meaningful value on multi-hop (+3.9%) - API inference is fast (~1-2s/question) and free (Together serverless) - Target: 97%+ accuracy with fine-tuned Qwen3.5-35B-A3B on local exo cluster\n\n#### 1.1 — Extract RAGLayer Module - **Input:** `twin_server_v3.py` monolithic code - **Output:** `layers/rag.py` with clean interface - **Spec:** - `RAGLayer(kb_paths, embed_fn)` constructor - `.search(query, top_k=3) -> list[SearchResult]` - `.to_context(results) -> str` - Support Gemini + Ollama embedding backends - Unit tests with mock embeddings - **Verify:** Run benchmark with extracted layer, scores unchanged\n\n#### 1.2 — Extract GraphLayer Module - **Input:** BFS traversal code from `twin_server_v3.py` - **Output:** `layers/graph.py` - **Spec:** - `GraphLayer(graph_path)` constructor - `.traverse(query, max_depth=2) -> str` - Add fuzzy node matching via embeddings (not just string match) - Unit tests - **Verify:** Config C score should IMPROVE with fuzzy matching\n\n#### 1.3 — Extract RLMLayer Module - **Input:** Decomposition logic from both benchmark scripts - **Output:** `layers/rlm.py` - **Spec:** - `RLMLayer(rag, graph, llm_fn)` constructor - `.should_decompose(query) -> bool` - `.decompose(query) -> list[str]` - `.retrieve(query) -> str` (full pipeline) - Configurable decomposition signals - Unit tests with mock LLM - **Verify:** Config D scores unchanged", "htmlHref": "/research/html/pulse-plan-cognitive-twin-v2-decoupled-rlm-qwen-3-5-qk88oc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1573 }, { "id": "crp-1-1-neurips-style-latex-template-complete-qewsks", "title": "CRP-1.1: NeurIPS-Style LaTeX Template - COMPLETE", "slug": "crp-1-1-neurips-style-latex-template-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/paper/latex/CRP-1.1-COMPLETE.md", "extension": "md", "score": 44, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "1. **Created `neurips_2024.sty`** - Official NeurIPS 2024 style file (38th Conference on Neural Information Processing Systems) based on the canonical template by Roman Garnett. Configured with `[preprint]` option for arXiv-ready formatting.", "excerpt": "1. **Created `neurips_2024.sty`** - Official NeurIPS 2024 style file (38th Conference on Neural Information Processing Systems) based on the canonical template by Roman Garnett. Configured with `[preprint]` option for arXiv-ready formatting.\n\n2. **Converted `main.tex` to NeurIPS format:** - Changed `\\documentclass[11pt]{article}` to `\\documentclass{article}` with `\\usepackage[preprint]{neurips_2024}` - Removed redundant `geometry` package (NeurIPS style handles page layout: 5.5in x 9in text area) - Removed redundant `natbib` package (loaded automatically by neurips_2024.sty) - Removed `float` package (no longer needed without `[H]` specifiers) - Removed `\\date{February 2026}` (not part of NeurIPS format) - Removed `\\textbf{}` from title (NeurIPS style handles title formatting) - Removed Keywords block from abstract (not standard for NeurIPS) - Changed all `[H]` float specifiers to `[t]` for proper NeurIPS float handling\n\n3. **All existing content preserved** - every section, table, figure, algorithm, and bibliography entry remains intact.\n\n4. **Clean compilation verified** - `pdflatex` runs with zero errors. Output: 13 pages, ~211KB PDF with proper NeurIPS formatting (Times font, conference header bar, correct margins).\n\n- `neurips_2024.sty` - Style file - `main.tex` - Updated source - `main.pdf` - Compiled output (13 pages, NeurIPS format)", "htmlHref": "/research/html/crp-1-1-neurips-style-latex-template-complete-qewsks.html", "signals": { "hasPdf": false, "hasLatex": true, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 236 }, { "id": "layer-4-evo3-architectural-exploration-of-the-soop-2-convergence-problem-1kragga", "title": "Layer 4 — Evo3 Architectural Exploration of the SOOP-2 Convergence Problem", "slug": "layer-4-evo3-architectural-exploration-of-the-soop-2-convergence-problem", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "crucible-output/soop-2/06d-layer4-evo3-architectures.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> **Status:** Scrutiny layer 4 of 4. Peer architectures vs ELP-1, not critique of ELP-1. > **Date:** 2026-05-13 > **Inputs:** ELP-1 v1 draft (05-everlasting-loop-protocol.md), 10 SOOP-2 criteria, current scoreboard (14/295 typed, 3/10 criteria met). > **Output role:** Compete with ELP-1 as a peer design. Verdict at the end.", "excerpt": "> **Status:** Scrutiny layer 4 of 4. Peer architectures vs ELP-1, not critique of ELP-1. > **Date:** 2026-05-13 > **Inputs:** ELP-1 v1 draft (05-everlasting-loop-protocol.md), 10 SOOP-2 criteria, current scoreboard (14/295 typed, 3/10 criteria met). > **Output role:** Compete with ELP-1 as a peer design. Verdict at the end.\n\nThe honest bottleneck of SOOP-2 right now is not compute, not orchestration, not multi-machine resilience. It is **the body of work itself**: 281 more SKILL.md files need typed frontmatter (Track B), one router needs a labeled benchmark plus a `type_compatibility_weight` knob (Track C), one Tier 2 endpoint needs a flip from MiniMax to Mac4:8100 with fallback (Track D), four feedback components need wiring at `[home-path]` (Track E), and two more skills need silent_capable=true (Track G). Total estimated effort from EXECUTION-PLAN.md is 13.5 days, mostly mechanical edits that any Claude or Codex pane can do.\n\nThe reason ELP-1 even exists is to defend against the four caveats in §0 of that doc: opaque ScheduleWakeup queue, Claude Code closure killing wake, single-driver pattern, no external stall escalation. Each caveat is real. None of them is currently causing a stall — the loop is advancing, just slowly and only when Mohamed's main session is alive. The cost of waiting (3 single-Claude sessions over 2 weeks) is comparable to the cost of building ELP-1 (1-2 sessions, per the doc's claim; realistically 2-4 once Supabase migrations, launchd plists on two machines, worker registration, and verifier scripts are all shipped and debugged).\n\nMesh primitives genuinely shipped today: `aura-gateway` (mac1:8095) with cross-machine `/inject`, `codex-gateway` (mac4:8096), Syncthing across mesh, Supabase with several active projects, `pulse` skill (Pulse-eligible tracks live in EXECUTION-PLAN), `ops:autopilot` (referenced in the SOOP-2 dispatch table), `meshd` running but with Codex slot \"unborn\" per mac4-codex-control-audit-2026-05-06.md, telegram + sms bridges (per ELP-1 §8.2 calling them \"already shipped per memory\"), Grafana on cloud-vm. Hypothetical or not-fully-wired: cortex:rules quarantine integration, the SOOP-2 verifier suite (the 10 per-criterion checks don't exist as code yet), worker heartbeat tables in Supabase, the supervisor.py and worker.py themselves.\n\nThe genuine question Evo3 must answer: **does the work scale better if you build a multi-driver platform first, or if you just keep typing skills with a slightly hardened single-driver?** ELP-1 assumes platform-first. The 6 paths below test that assumption.", "htmlHref": "/research/html/layer-4-evo3-architectural-exploration-of-the-soop-2-convergence-problem-1kragga.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 5286 }, { "id": "handoff-depth-reactive-visuals-lume-hardware-product-creative-agency-7fn1ee", "title": "HANDOFF: Depth-Reactive Visuals + LUME Hardware Product + Creative Agency", "slug": "handoff-depth-reactive-visuals-lume-hardware-product-creative-agency", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "DepthReactiveVisuals/HANDOFF.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date**: 2026-04-04 **Author**: Mohamed Diomande (via Claude Opus) **Recipient**: Codex (continuation agent) **Session**: b8e3a146 — Full-day session covering three interconnected initiatives", "excerpt": "**Date**: 2026-04-04 **Author**: Mohamed Diomande (via Claude Opus) **Recipient**: Codex (continuation agent) **Session**: b8e3a146 — Full-day session covering three interconnected initiatives\n\n1. [Overview — Three Initiatives](#1-overview) 2. [Initiative 1: Depth-Reactive Interactive Visual System](#2-depth-reactive) 3. [Initiative 2: LUME Hardware Product](#3-lume) 4. [Initiative 3: Diomande Creative Agency](#4-agency) 5. [Infrastructure State](#5-infrastructure) 6. [File Inventory](#6-files) 7. [What's Working](#7-working) 8. [What's Blocked / Incomplete](#8-blocked) 9. [Next Steps (Priority Order)](#9-next-steps) 10. [Reference Material](#10-references)\n\nThis session started from an Instagram reel by Duncan Fewkes showing depth-reactive interactive installations, and evolved into three interconnected projects:\n\n1. **Depth-Reactive Visual System** — A Unity 6 + TouchDesigner pipeline that uses depth cameras to create real-time interactive particle/fluid visuals driven by body movement and audio 2. **LUME** — A $1,299 standalone hardware product (Jetson Orin Nano + Orbbec Femto Bolt) that packages the visual system into a wall-mounted device for dance studios, venues, and content creators 3. **Diomande Creative** — A new media art agency inspired by Hybrid Xperience, Projection Mapping World, and the immersive art sector (teamLab, Mercer Labs, ARTECHOUSE)\n\nAll three share the same codebase and technical pipeline. The depth-reactive system IS the software that runs on LUME, and the agency uses it as portfolio work.", "htmlHref": "/research/html/handoff-depth-reactive-visuals-lume-hardware-product-creative-agency-7fn1ee.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3892 }, { "id": "stage-2-compound-karl-phase-4-unified-architecture-uuh3i4", "title": "Stage 2: Compound -- KARL Phase 4+ Unified Architecture", "slug": "stage-2-compound-karl-phase-4-unified-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/carl-karl-trajectory-rl/stage2-compound.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "We have a trajectory recording system (110 records), a reward engine (3-signal composite), a shadow vector router (10% cache hit rate), and a training pipeline that produced one adapter (KARL v2, loss 1.843, gemma-3-1b-4bit) from 35 SFT examples. The adapter exists but has never been evaluated for actual routing or planning quality. The finetune daemon on Mac5 is down. The promotion gate says the shadow router is not ready.", "excerpt": "We have a trajectory recording system (110 records), a reward engine (3-signal composite), a shadow vector router (10% cache hit rate), and a training pipeline that produced one adapter (KARL v2, loss 1.843, gemma-3-1b-4bit) from 35 SFT examples. The adapter exists but has never been evaluated for actual routing or planning quality. The finetune daemon on Mac5 is down. The promotion gate says the shadow router is not ready.\n\n**The honest assessment**: We have a data collection system that works and a training pipeline that runs. We do not yet have evidence that the trained model improves anything. The gap between \"model trained\" and \"model useful\" is the gap this compound must close.\n\nBefore any data or algorithm work, the training infrastructure must be reliable and observable.\n\n**Actions**: 1. SSH to Mac5, restart finetune daemon, create LaunchAgent `com.openclaw.finetune-daemon.plist` with auto-restart 2. Increase training hyperparameters: seq_len 256->512, LoRA rank 8->16, layers 4->8, batch_size 1->2 3. Create `[home-path]` with three evaluation functions: - `evaluate_routing_accuracy()`: Given test prompts, does the model predict the correct skill? - `evaluate_planning_quality()`: Given tasks, does the model generate tool plans that match reference? - `compare_adapters()`: Head-to-head comparison between two adapter versions 4. Build a held-out evaluation set: 20 real prompts with known-correct skills and tool plans, manually curated from the 34 high-reward trajectories. This set is NEVER used for training.\n\n**Validation gate**: Finetune daemon responds on :9200. Evaluator runs successfully on KARL v2. Baseline metrics recorded.", "htmlHref": "/research/html/stage-2-compound-karl-phase-4-unified-architecture-uuh3i4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 2152 }, { "id": "stage-0-research-brief-spore-intelligence-architecture-1cx3fmp", "title": "Stage 0 Research Brief: Spore Intelligence Architecture", "slug": "stage-0-research-brief-spore-intelligence-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/spore-intelligence-architecture/stage0-research.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> Integrating Real Infrastructure (EW, KARL, Cortex, Graph Kernel, RAG++, Pulse) as Spore's Backend Brain > Researched: 2026-03-11 | Agent: Meta-Recursive Explorer (Opus 4.6)", "excerpt": "> Integrating Real Infrastructure (EW, KARL, Cortex, Graph Kernel, RAG++, Pulse) as Spore's Backend Brain > Researched: 2026-03-11 | Agent: Meta-Recursive Explorer (Opus 4.6)\n\n**Status lifecycle**: `spore -> germinating -> growing -> budding -> blooming -> fruiting` - Branch: `withering` (neglect, recoverable) and `composted` (terminal) - Thresholds: 0/10/30/55/80/95\n\nThe on-device `EvolutionEngine` uses Apple's `NLEmbedding` (word-level English embeddings) to drive 5 mutation strategies:\n\n| Strategy | Mechanism | Strength Bonus | |----------|-----------|----------------| | `tendrilAbsorption` | Keyword overlap from connected spores | +1.5 | | `seasonalMutation` | Spring expands, winter distills | +1.0 | | `maturityRefinement` | Replace weakest keyword with more relevant one | +2.0 | | `hybridVigor` | Cross-pollinate from graft parents | +3.0 | | `spontaneousGrowth` | NLEmbedding nearest-neighbor expansion | +0.5 |\n\n**Mutation probability** is computed per growth cycle: - Base: 15%, capped at 60% - Modifiers: season (spring 1.5x, winter 0.4x), tendril count (+3% each), grafted (+12%), maturity bonus (1.3x for budding/blooming) - Diminishing returns after 10 mutations", "htmlHref": "/research/html/stage-0-research-brief-spore-intelligence-architecture-1cx3fmp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 3692 }, { "id": "dream-weaver-v9-0-notification-orchestrator-journal-intelligence-analytics-engine-c50ca8", "title": "Dream Weaver v9.0 - Notification Orchestrator, Journal Intelligence & Analytics Engine", "slug": "dream-weaver-v9-0-notification-orchestrator-journal-intelligence-analytics-engine", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/bot:dream-weaver/SKILL.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> _\"Like spores in fertile soil, ideas need time to send out tendrils, form symbiosis, and bloom.\"_ > _\"A dream is source code for the subconscious. Interpretation is parsing. Understanding is compilation. Execution is living the dream.\"_ > _\"Your journal is raw ore. Dreams are refined gold. V8 is the smelter.\"_", "excerpt": "--- name: bot:dream-weaver description: Asynchronous idea incubation v8 - organic growth, garden visualization, bloom notifications, collective dreaming, notification intelligence, dream compilation & journal intelligence homepage: https://github.com/diomandeee/clawdbot user-invocable: true command-dispatch: incubate handler: handler.DreamWeaverHandler metadata.clawdbot: {\"requires_orbit\": true, \"background_capable\": true, \"pulse_integration\": true, \"version\": \"9.0.0\"} manifest: inputs: [spore_idea, journal_text, guidance, collective_contributions] outputs: [dream_synthesis, bloom_notification, interpreted_project, compiled_tasks, theme_crystals] chains_with: [bot:pulse, evo:evolve, tie, art:synthesis, sys:plan] triggers: [incubate, dream, garden, bloom, journal, interpret, compile, collective] can_spawn_pulse: true ---\n\n# Dream Weaver v9.0 - Notification Orchestrator, Journal Intelligence & Analytics Engine\n\n> _\"Like spores in fertile soil, ideas need time to send out tendrils, form symbiosis, and bloom.\"_ > _\"A dream is source code for the subconscious. Interpretation is parsing. Understanding is compilation. Execution is living the dream.\"_ > _\"Your journal is raw ore. Dreams are refined gold. V8 is the smelter.\"_\n\nDream Weaver combines **garden visualization** showing all dreams as plants, **bloom notifications** to iMessage/Telegram/WhatsApp, **auto-bridge to Idea Vault**, **collective dreaming** for group incubation, **notification intelligence** for predictive insights, **Dream Compiler** for transforming dreams into executable code, and now **Journal Intelligence** for parsing raw journals into actionable project ideas.\n\nTransform raw diary-style journal entries into structured, actionable project ideas:", "htmlHref": "/research/html/dream-weaver-v9-0-notification-orchestrator-journal-intelligence-analytics-engine-c50ca8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6590 }, { "id": "k11-music-production-stack-where-everything-lives-1cygrtz", "title": "K11 Music Production Stack — Where Everything Lives", "slug": "k11-music-production-stack-where-everything-lives", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "K11-MUSIC-PRODUCTION-RUNBOOK-2026-05-12.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Tool | Role | Need on K11? | Why | |---|---|---|---| | **Unity** | Bar product **visuals output** | ✅ Yes (already there) | Renders the 1920×440 bar display from LUMA UDP. This is your \"show.\" | | **Rekordbox** | **DJ performance** (live mixing, loops, FX, hot cues) | ✅ Yes (next install) | Has the most expressive keyboard shortcuts. cc-dj-control already has a Rekordbox bridge built. | | **Serato** | Same role as Rekordbox, competitor | ⚠️ Optional alternative | cc-dj-control supports it too. Pick one — running ", "excerpt": "**Date:** 2026-05-12. **Authority:** verified against the actual code in `Desktop/Comp-Core/`.\n\n| Tool | Role | Need on K11? | Why | |---|---|---|---| | **Unity** | Bar product **visuals output** | ✅ Yes (already there) | Renders the 1920×440 bar display from LUMA UDP. This is your \"show.\" | | **Rekordbox** | **DJ performance** (live mixing, loops, FX, hot cues) | ✅ Yes (next install) | Has the most expressive keyboard shortcuts. cc-dj-control already has a Rekordbox bridge built. | | **Serato** | Same role as Rekordbox, competitor | ⚠️ Optional alternative | cc-dj-control supports it too. Pick one — running both at once doesn't help. Default to Rekordbox per your preference. | | **Ableton Live** | **Music production** (write, record, sequence, sound-design) | ⚠️ Eventually, not day one | DAW for *making* tracks. Rekordbox plays existing tracks. Until you need to produce new music from motion in real time, you can skip Ableton entirely. See \"Where Ableton fits\" below. |\n\n**Net for the first install pass:** **Unity + Rekordbox.** Add Ableton later if and when the motion-to-music generation needs a DAW host.\n\nYou already have the full DJ agent stack. Stop treating it as TBD. The code is in `Desktop/Comp-Core/core/audio-media/cc-dj/`.\n\n**`configs/commands.yaml` (3,381 lines).** Every keyboard shortcut Rekordbox and Serato expose, with metadata. Sample entry:", "htmlHref": "/research/html/k11-music-production-stack-where-everything-lives-1cygrtz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3020 }, { "id": "market-sweep-outreach-ios-parity-map-hk9q5w", "title": "Market Sweep + Outreach iOS Parity Map", "slug": "market-sweep-outreach-ios-parity-map", "kind": "architecture", "program": "Protocol and Compute", "sourceAnchor": "Milk Men/docs/ios-parity/market-sweep-outreach-system-map.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. **Market Sweep** discovers and qualifies cafes in a market. 2. **Outreach** turns qualified prospects into conversations, follow-ups, visits, and eventual accounts.", "excerpt": "1. **Market Sweep** discovers and qualifies cafes in a market. 2. **Outreach** turns qualified prospects into conversations, follow-ups, visits, and eventual accounts.\n\n1. Create `market_sweeps` row for a city/state/neighborhood. 2. Run `market-sweep-search` to populate `sweep_prospects`. 3. Run enrichment stages: - `market-sweep-enrich` - `market-sweep-prospeo-enrich` - `market-sweep-instagram-enrich` - `market-sweep-visual-score` 4. Import qualified prospects into CRM: - `market-sweep-import` - `inbound_leads` - `accounts` - `locations` 5. Generate outbound content: - `market-sweep-ai-generate` - `subject_variants` - `ai_subject` - `ai_body` 6. Send and track outreach: - `market-sweep-email` - `market-sweep-followup` - `email_outreach` - `outreach_send_log` 7. Classify replies and schedule field work: - `market-sweep-classify` - `response_type` - `qualification_tier` - `outreach_stage` - `prospect_visits`\n\n- `market_sweeps`: market-level operation status, totals, distributor context, search config. - `sweep_prospects`: discovery staging, enrichment, contact data, AI email copy, outreach status, ICP scores. - `sweep_contacts`: multi-contact enrichment from Prospeo/manual sources. - `inbound_leads`: promoted CRM leads after import. - `email_outreach`: immutable email-send/audit log. - `outreach_send_log`: daily send cadence and recipient-domain tracking. - `outreach_templates`, `email_sequences`, `prospect_sequence_state`: template and sequence management. - `prospect_visits`: visit scheduling from interested replies.\n\n- `market-sweep-search`: SerpAPI discovery into `sweep_prospects`. - `market-sweep-enrich`: website/email/IG scrape enrichment. - `market-sweep-prospeo-enrich`: company and decision-maker enrichment. - `market-sweep-instagram-enrich`: IG follower/profile enrichment. - `market-sweep-instagram-aesthetic`: Gemini visual scoring from feed screenshots. - `market-sweep-visual-score`: cafe photo ICP scoring. - `market-sweep-import`: promotion into CRM tables. - `market-sweep-ai-generate`: personalized outbound subject/body generation. - `market-sweep-classify`: reply classification and tiering. - `market-sweep-assign`: territory assignment and visit sequence creation. - `market-sweep-email`: approved intro email send. - `market-sweep-followup`: follow-up email send.\n\n- `FieldRouteService` reads selected-market `sweep_prospects`, clusters route-ready prospects, and can consume Growth handoff payloads. - `LeadDiscoveryService` uses `MKLocalSearch`, but it is a local search tool, not the web market-sweep pipeline. - `FieldRoutesTabView` can cluster prospects and record visit outcomes. - Native now has delivery-grid parity foundation. - Native now has a first Growth command center backed by `market_sweeps` and `sweep_prospects`. - Native now has ", "htmlHref": "/research/html/market-sweep-outreach-ios-parity-map-hk9q5w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1510 }, { "id": "codex-handoff-motionmix-shootview-still-capture-ios-build-hn6d8i", "title": "Codex Handoff — MotionMix / ShootView / Still-Capture iOS Build", "slug": "codex-handoff-motionmix-shootview-still-capture-ios-build", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/CODEX-HANDOFF-2026-05-03.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Author: Claude (Mac1 session ff0dc14e), 2026-05-03 evening, US ET > Audience: Codex (next agent, fresh context) > Operator: Mohamed > Scope: finish the MotionMix multi-cam shoot stack so ShootView becomes the operator surface, iPhones produce max-resolution stills end-to-end, and Stage View is solid enough to ship.", "excerpt": "> Author: Claude (Mac1 session ff0dc14e), 2026-05-03 evening, US ET > Audience: Codex (next agent, fresh context) > Operator: Mohamed > Scope: finish the MotionMix multi-cam shoot stack so ShootView becomes the operator surface, iPhones produce max-resolution stills end-to-end, and Stage View is solid enough to ship.\n\nThe user explicitly decided **today, 2026-05-03**: **ShootView (iPad SwiftUI app) absorbs the Live Director role.** The native macOS `MotionMixDirector` Swift Package app is no longer the operator surface — it stays buildable as a fallback / debug tool, but ShootView is the canonical operator + photographer + gallery + reel + lookbook UI now.\n\nUser quote: *\"I, in fact, do not need the Live Director app itself, and I could actually direct my shoot through ShootView without any other external things.\"*\n\nImplication for you: do not pour effort into `Desktop/MotionMixDirector/` features. All operator-facing work goes into `Desktop/ShootView/`.\n\n| Host | Tailscale IP | LAN IP | Role | What's running right now | |---|---|---|---|---| | **Mac1** (MacBook Air M*) | varies | **[ip]** | Build host, multicam-server, mic capture | `multicam-server` :9404 (PID 72954+73358), `speakd` (PID 17419), `mic-pub` (PID 55971 → mac4:9540), `MotionMixDirector` native (built, may or may not be in the dock) | | **Mac4** (Mac mini M4) | **[ip]** | LAN | macOS-26 SpeechTranscriber relay + speakd remote-audio sink | `SpeechRelayApp` :9530 (PID 1313), `speakd` (PID 1339, mode = remote-udp:9540) | | **iPhone 16 Plus** | — | — | Primary capture node | UDID prefix `880B4058-F0B8-59EC-8693-7750C90BDB62` per `MotionMixApp/CLAUDE.md` | | **iPhone 16 Pro Max** | — | — | Secondary capture node | UDID prefix `84109044…` | | **iPhone 14 Pro Max** | — | — | Camera node (pose only) | UDID prefix `45896348…` | | **iPad A16 (Mohamed's)** | — | — | ShootView | UDID prefix `1DE6FABC…` | | **iPad A16** | — | — | ShootView (second) | UDID prefix `1938B9B3…` | | iPad (any) | — | — | Stage View (browser) | Safari → `http://[ip]:9404/program` (audience-facing live cut) |", "htmlHref": "/research/html/codex-handoff-motionmix-shootview-still-capture-ios-build-hn6d8i.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3273 }, { "id": "stable-audio-3-model-1odsgyt", "title": "Stable Audio 3 Model", "slug": "stable-audio-3-model", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/stable-audio-3/docs/guides/model-overview.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "All configurations (`small-music`, `small-sfx`, and `medium`) share the same interface — see the [model table](../../README.md#models) for hardware requirements and generation speed.", "excerpt": "# Stable Audio 3 Model > For a more in-depth breakdown of Stable Audio 3, please see our [tech report](https://arxiv.org/abs/2605.17991).\n\nAll configurations (`small-music`, `small-sfx`, and `medium`) share the same interface — see the [model table](../../README.md#models) for hardware requirements and generation speed.\n\n| Input | Description | |---|---| | `prompt` | Text description of the audio to generate | | `duration` | Length of audio to generate, in seconds |\n\n| Output | Value | |---|---| | Format | 44.1 kHz stereo audio | | Bit depth | 32-bit float |\n\n**Limitations** - Not designed for speech or voice generation - Trained on English descriptions; other languages will underperform", "htmlHref": "/research/html/stable-audio-3-model-1odsgyt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1112 }, { "id": "nko-as-an-extensible-phonemic-substrate-1sbdb8o", "title": "N'Ko as an Extensible Phonemic Substrate", "slug": "nko-as-an-extensible-phonemic-substrate", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/NKO-PHONEMIC-SUBSTRATE-PROPOSAL.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Drafted 2026-06-01 from Mohamed's questions: > If N'Ko can mechanically represent missing sounds by composition, what does that imply? > Do we still need ASR retraining? Can English/French be converted into N'Ko labels? > Can phrase-level expression transfer ride on top of the same substrate?", "excerpt": "> Drafted 2026-06-01 from Mohamed's questions: > If N'Ko can mechanically represent missing sounds by composition, what does that imply? > Do we still need ASR retraining? Can English/French be converted into N'Ko labels? > Can phrase-level expression transfer ride on top of the same substrate?\n\n**N'Ko can serve as an extensible phonemic substrate for speech systems: a mechanically auditable representation layer where sounds from multiple languages can be encoded by documented N'Ko diacritics and bounded composition, then used as the target for ASR, governed correction, and self-training.**\n\nIn plain terms: N'Ko is not just an output script. It can become the intermediate sound-code that lets a low-resource system manufacture cleaner data, compare outputs phonemically, and grow adapters without needing a giant pretraining corpus.\n\n1. **Baseline**: what the current `IPA_TO_NKO` table already supports. 2. **Unicode extensions**: documented N'Ko foreign-sound combinations from the Unicode Core Specification, Chapter 19, Table 19-3. 3. **Full compositional layer**: internal computational encodings for sounds not covered by baseline or Unicode-documented combinations.\n\nThe important claim: **we can push representational coverage past 90% without model training.** That is a rulebook/transliteration result, not a neural result.", "htmlHref": "/research/html/nko-as-an-extensible-phonemic-substrate-1sbdb8o.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1832 }, { "id": "nko-intelligence-pipeline-full-architecture-154ngfr", "title": "N'Ko Intelligence Pipeline — Full Architecture", "slug": "nko-intelligence-pipeline-full-architecture", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/PIPELINE.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "┌─────────────┐ ┌──────────────┐ ┌──────────────┐ ┌───────────────┐ │ bam-asr- │ │ AfVoices │ │ Djoko │ │ Parents' │ │ early │ │ 253K audio │ │ YouTube │ │ Voice Memos │ │ 38K clean │ │ Latin text │ │ 5.5K audio │ │ Malinke │ │ N'Ko labels │ │ NO N'Ko │ │ consensus │ │ diarized │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ └───────┬───────┘ │ │ │ │ │ ┌────────┴────────┐ │ │ │ │ NEEDS TONE-AWARE│ │ │ │ │ TRANSLITERATION │ │ │ │ │ (blocked until │ │ │ │ │ tone model) │ │ │ │ └────────┬────────┘ │ │ │ │ │ │ ▼ ▼ ▼ ", "excerpt": "| Component | Status | Next Action | |-----------|--------|-------------| | 44K clean data | READY | Training TAR now | | 253K AfVoices features | EXTRACTED | Waiting for tone model | | N'Ko trajectory CER | 27.39% (297K) | Retrain on 44K clean queued | | TAR experiment | TRAINING | 4 runs on A100 | | ANE spike | 11.6 TFLOPS proven | Wire into training loop | | YouTube OCR (Gemma 4) | QUEUED | Task #31 on Vast.ai | | Tone resolution model | PLANNED | Depends on OCR corpus | | TurboQuant | BUILT | Needs real embedding test | | Contextual tone paper | PLANNED | Depends on OCR + tone model | | ANE distributed paper | PLANNED | Depends on training loop proof |", "htmlHref": "/research/html/nko-intelligence-pipeline-full-architecture-154ngfr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1108 }, { "id": "stage-4-forge-the-chronicle-club-architecture-1yc460b", "title": "Stage 4: FORGE — The Chronicle Club Architecture", "slug": "stage-4-forge-the-chronicle-club-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "omega-output/firstdate-membership-club-20260322/04-architecture.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "FirstDate becomes a private membership club where your profile is a living chronicle of what you built while you waited. Matching happens through resonance with someone's story, not their photos. Community events create organic connections. Mohamed serves as personal matchmaker for premium members.", "excerpt": "FirstDate becomes a private membership club where your profile is a living chronicle of what you built while you waited. Matching happens through resonance with someone's story, not their photos. Community events create organic connections. Mohamed serves as personal matchmaker for premium members.\n\n**One sentence:** \"A membership club where you journal your growth, connect through stories, and meet at curated events.\"\n\n| Service | Responsibility | |---------|---------------| | **MembershipManager** | StoreKit 2 subscription management, tier checking, paywall logic | | **ChronicleManager** | CRUD chronicle + entries, probation tracking, featured rotation | | **ResonanceManager** | Send/receive resonance signals, mutual detection, unlock messaging | | **EventManager** | Event CRUD, RSVP management, capacity tracking | | **IntroductionManager** | Patron-tier matchmaking, introduction lifecycle | | **ReflectionPromptManager** | Weekly prompt delivery, entry suggestions | | **MemberDirectoryManager** | Searchable member list filtered by tier, chronicle themes |\n\n### Chronicle Views - `Views/Chronicle/MyChronicleView.swift` — Your journal feed + write button - `Views/Chronicle/ChronicleEntryView.swift` — Single entry display - `Views/Chronicle/CreateEntryView.swift` — Write/upload entry (text, photo, video, milestone) - `Views/Chronicle/ProbationProgressView.swift` — 30-day progress (entries needed, days left)\n\n### Browse Views - `Views/Browse/BrowseChroniclesView.swift` — Discover other members' chronicles - `Views/Browse/ChronicleCardView.swift` — Preview card for a member's chronicle - `Views/Browse/ChronicleDetailView.swift` — Full chronicle view (someone else's)", "htmlHref": "/research/html/stage-4-forge-the-chronicle-club-architecture-1yc460b.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1108 }, { "id": "dj-agent-final-implementation-status-1gn5ru7", "title": "DJ Agent - Final Implementation Status", "slug": "dj-agent-final-implementation-status", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/README.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Core Infrastructure** (10/10) - [x] Base directory structure - [x] Action space with 6 tiers - [x] Scheduler with beat quantization - [x] State shadow (Serato mirror) - [x] Serato bridge (MIDI/keyboard) - [x] Reflex policy (continuous controls) - [x] Planner policy (symbolic actions) - [x] Rewards system - [x] Configuration (dj.yaml) - [x] Runtime integration (engine.py)", "excerpt": "# DJ Agent - Final Implementation Status **Date**: November 4, 2025 **Implementation**: ✅ **COMPLETE** **Testing Status**: ⏳ **Awaiting User Setup**\n\n**Core Infrastructure** (10/10) - [x] Base directory structure - [x] Action space with 6 tiers - [x] Scheduler with beat quantization - [x] State shadow (Serato mirror) - [x] Serato bridge (MIDI/keyboard) - [x] Reflex policy (continuous controls) - [x] Planner policy (symbolic actions) - [x] Rewards system - [x] Configuration (dj.yaml) - [x] Runtime integration (engine.py)\n\n**Training & Evaluation** (7/7) - [x] DJ action data loader - [x] Imitation learning trainer - [x] RL trainer - [x] Evaluation metrics - [x] Serato sandbox (RL environment) - [x] Session logger - [x] Telemetry dashboard\n\n**Features** (9/9) - [x] All 6 tiers implemented - [x] Motion-to-intent priors - [x] Safety rails - [x] Ghost/Assist/Auto modes - [x] Hybrid workflow - [x] Hardware controller guide - [x] SuperCollider mastering - [x] Performance profiler - [x] Smooth parameter transitions\n\n**Documentation & Tools** (5/5) - [x] Serato setup guide - [x] Hybrid workflow guide - [x] Hardware controller guide - [x] Quick reference card - [x] Test suite + demo", "htmlHref": "/research/html/dj-agent-final-implementation-status-1gn5ru7.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2234 }, { "id": "rekordbox-integration-guide-122zxqv", "title": "Rekordbox Integration Guide", "slug": "rekordbox-integration-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/REKORDBOX_INTEGRATION.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. [Overview](#overview) 2. [Prerequisites](#prerequisites) 3. [Setup Methods](#setup-methods) 4. [Keyboard Control](#keyboard-control) 5. [MIDI Control](#midi-control) 6. [Library Management](#library-management) 7. [Troubleshooting](#troubleshooting) 8. [Advanced Features](#advanced-features)", "excerpt": "Complete guide for integrating motion-driven auto-DJ control with Rekordbox using keyboard shortcuts and MIDI.\n\n1. [Overview](#overview) 2. [Prerequisites](#prerequisites) 3. [Setup Methods](#setup-methods) 4. [Keyboard Control](#keyboard-control) 5. [MIDI Control](#midi-control) 6. [Library Management](#library-management) 7. [Troubleshooting](#troubleshooting) 8. [Advanced Features](#advanced-features)\n\n- **Keyboard shortcuts** (218 shortcuts available, no subscription required) - **MIDI Learn** (requires subscription, comprehensive control) - **Library access** via XML export or encrypted database (pyrekordbox)\n\n| Method | Pros | Cons | Best For | |--------|------|------|----------| | **Keyboard** | ✅ No subscription needed
✅ Works immediately
✅ All shortcuts available | ❌ Requires window focus
❌ No continuous controls | Getting started, transport control | | **MIDI** | ✅ Continuous controls
✅ Bidirectional feedback
✅ More reliable | ❌ Requires subscription
❌ Setup needed
❌ No jogwheel (without Pioneer hardware) | Production use, filters/effects |\n\n- **Version**: Rekordbox 6 or 7 (Performance mode) - **Subscription**: Free (Core) for keyboard, paid plan for MIDI - Download: [rekordbox.com](https://rekordbox.com/)", "htmlHref": "/research/html/rekordbox-integration-guide-122zxqv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2053 }, { "id": "rekordbox-voice-control-evaluation-plan-15cvvl", "title": "Rekordbox Voice Control – Evaluation Plan", "slug": "rekordbox-voice-control-evaluation-plan", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/VOICE_CONTROL_EVALUATION.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Path A – Gemini Live + Embedding Gemma** - Mic → Gemini Live (cloud ASR) → text - Text → Embedding Gemma → Rekordbox orbiter → keyboard bridge", "excerpt": "Systematic testing and comparison of Gemini Live vs Wav2Vec2 for voice-controlled DJing with Rekordbox.\n\n- **Path A – Gemini Live + Embedding Gemma** - Mic → Gemini Live (cloud ASR) → text - Text → Embedding Gemma → Rekordbox orbiter → keyboard bridge\n\n- **Path B – Wav2Vec2 + Embedding Gemma** - Mic → Wav2Vec2 (local ASR) → text - Text → Embedding Gemma → Rekordbox orbiter → keyboard bridge\n\n**Both paths share**: - Same command catalog: `Mapping/commands.yaml` - Same retrieval logic (hard overrides + Embedding Gemma + Rekordbox index) - Same constraints and safety layer - Same Rekordbox keyboard bridge\n\n### 1.1. ASR Quality - How often does each path convert spoken commands into the expected text? - Performance in quiet vs noisy environments", "htmlHref": "/research/html/rekordbox-voice-control-evaluation-plan-15cvvl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2191 }, { "id": "ai-handoff-document-trajectory-control-center-f6lyvy", "title": "AI Handoff Document: Trajectory Control Center", "slug": "ai-handoff-document-trajectory-control-center", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/trajectory-os/AI_HANDOFF.md", "extension": "md", "score": 44, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "You are receiving a project at a critical inflection point. The **Trajectory Control Center** is a unified Tauri desktop application that combines:", "excerpt": "You are receiving a project at a critical inflection point. The **Trajectory Control Center** is a unified Tauri desktop application that combines:\n\n1. **RAG++ Knowledge Retrieval** - Semantic search over 107K+ memory turns 2. **Idea Vault** - Research ideas lifecycle management 3. **Orbit Integration** - Project orchestration\n\nThe core integration is **complete**. You are now tasked with implementing the **enhancement roadmap** that adds: - Timeline & Calendar views for idea evolution tracking - Multi-source import pipeline - Knowledge base integration (RAG++ enrichment) - Idea linking and evolution graphs\n\n1. [Project Context](#1-project-context) 2. [System Architecture](#2-system-architecture) 3. [Codebase Map](#3-codebase-map) 4. [What Has Been Completed](#4-what-has-been-completed) 5. [Current State](#5-current-state) 6. [What Needs to Be Done](#6-what-needs-to-be-done) 7. [Critical Files to Read](#7-critical-files-to-read) 8. [Technical Reference](#8-technical-reference) 9. [Conventions & Patterns](#9-conventions--patterns) 10. [Known Issues & Constraints](#10-known-issues--constraints) 11. [Continuation Instructions](#11-continuation-instructions)\n\nThis project exists within a larger ecosystem called **Computational Choreography** (Comp-Core), which is a discipline for real-time embodied intelligence. The ecosystem has three architectural layers:", "htmlHref": "/research/html/ai-handoff-document-trajectory-control-center-f6lyvy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3652 }, { "id": "metamorphosis-context-aware-code-suggestions-from-orbit-logs-106mnza", "title": "METAMORPHOSIS: Context-Aware Code Suggestions from Orbit Logs", "slug": "metamorphosis-context-aware-code-suggestions-from-orbit-logs", "kind": "architecture", "program": "Research Backlog", "sourceAnchor": "projects/dream-metamorphosis/code-suggestions/ARCHITECTURE.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "METAMORPHOSIS mines historical Orbit data (prompt logs, session histories, noosphere connections, plans) to build a pattern model of developer behavior. It predicts what code actions, files, and tools the developer will need next based on:", "excerpt": "METAMORPHOSIS mines historical Orbit data (prompt logs, session histories, noosphere connections, plans) to build a pattern model of developer behavior. It predicts what code actions, files, and tools the developer will need next based on:\n\n- **Current project context** (which project, which files, git state) - **Session phase** (early exploration vs deep implementation) - **Historical co-occurrence patterns** (what actions typically follow what) - **Cross-project knowledge transfer** (patterns learned in one project apply to similar ones)\n\n| Source | Path | Records | Content | |--------|------|---------|---------| | **Prompt Logs** | `prompt-logs/prompts-all.jsonl` | 2,355 | Every prompt with cwd, git context, session ID, timestamps | | **Session History** | `history.jsonl` | 884 | Display text, project, session grouping | | **Noosphere** | `noosphere/connections.json` | 145 nodes | Dreams, orbit contexts, plans with semantic connections | | **Plans** | `plans/` | 43+ | Architectural plans with status tracking | | **Project Map** | `orbit-project-map.json` | 8 projects | Project ID mappings | | **Per-Project Prompts** | `prompt-logs/projects/*/prompts.jsonl` | Varies | Project-scoped prompt sequences |\n\n| Derived | Description | |---------|-------------| | **Action Sequences** | Ordered prompt chains within sessions | | **Project Fingerprints** | Characteristic action patterns per project | | **Transition Matrices** | Probability of action B following action A | | **Temporal Patterns** | Time-of-day and session-duration correlations | | **Keyword Clusters** | Groups of semantically related prompts |\n\n### Stage 1: Data Ingestion - Parse all JSONL files into structured records - Normalize project paths to canonical names - Group prompts into sessions with temporal ordering - Extract git context (repo, branch, dirty state)", "htmlHref": "/research/html/metamorphosis-context-aware-code-suggestions-from-orbit-logs-106mnza.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 890 }, { "id": "daily-mfp-content-generation-architecture-1bcn0qu", "title": "🌅 Daily MFP — Content Generation Architecture", "slug": "daily-mfp-content-generation-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Meaning-Full-Power/docs/DAILY-MFP-ARCHITECTURE.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` ┌─────────────────────────────────────────────────────────────────┐ │ DAILY MFP PIPELINE │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ SOURCE │───▶│ POEM │───▶│ IMAGE │ │ │ │ SELECTION │ │ REFINEMENT │ │ GENERATION │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Pick quote, │ │ Transform to │ │ AI art in │ │ │ │ poem, or │ │ poem format ", "excerpt": "## Vision A Discord channel that posts **daily illustrated poetry** in the MFP visual style — pulling from Mohamed's words (poems, notes, sayings) and transforming them into shareable art pieces.\n\n### Primary Sources (Curated) | Source | Location | Content Type | |--------|----------|--------------| | Poems CSV | `content/english/meaning_full_power.csv` | 50+ original poems | | Prose Chapters | Same CSV | Philosophy, reflections | | Existing Art | `content/artwork/illustrations_with_text/` | 24 illustrated pages |\n\n### Secondary Sources (To Be Indexed) | Source | Location | Content Type | |--------|----------|--------------| | Voice Transcripts | Memory/conversations | Raw thoughts, sayings | | Notes | Apple Notes / Memory | Ideas, reflections | | Social Posts | Past tweets, posts | Quotes, insights |\n\n**Background:** Pure black (#000000) **Text Color:** Cream/off-white (#F5F5DC or similar) **Header Font:** Spaced uppercase serif (\"M e a n i n g F u l l P o w e r\") **Body Font:** Elegant serif (Georgia, Garamond, or similar) **Accent:** Italic script for opening quotes\n\n### Illustration Style - **Technique:** Stipple dots + fine line work (white on black) - **Themes:** Cosmic (stars, space), paths (stairs, bridges), nature (trees, water), architectural (buildings reaching up) - **Composition:** Text fills upper 2/3, illustration anchors bottom right - **Page Number:** Centered at bottom", "htmlHref": "/research/html/daily-mfp-content-generation-architecture-1bcn0qu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1296 }, { "id": "sea-2-1-completion-report-skill-entity-dispatch-integration-18q3y0f", "title": "SEA-2.1 Completion Report — Skill Entity Dispatch Integration", "slug": "sea-2-1-completion-report-skill-entity-dispatch-integration", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-2.1-COMPLETE.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Files Changed:** - `[home-path]` (modified — added SEA skill entity detection + injection) - `[home-path]` (modified — added `--no-sea` flag + SEA status output)", "excerpt": "**Files Changed:** - `[home-path]` (modified — added SEA skill entity detection + injection) - `[home-path]` (modified — added `--no-sea` flag + SEA status output)\n\n- **`detect_sea_skills(task, project_path)`** — Primary detection function that: - Tries SEA's embedding-based Tier 1 router first (via `sea_skill_injector.detect_sea_skills_for_task()`) - Falls back to keyword matching (`_sea_keyword_fallback()`) if Ollama/embeddings unavailable - Scans project's `CLAUDE.md` for explicit skill entity references - Returns enriched entity metadata (name, version, state, hot topics, confidence)\n\n- **`_load_skill_entity(skill_name)`** — Loads full entity context from: - `[home-path]` (description from YAML frontmatter) - `[home-path]` (hot topics, confidence, activations, mute status) - `[home-path]` (current version)\n\n- **`format_sea_skill_block(entities)`** — Formats detected entities into a prompt injection block with version, confidence, activation count, domains, and SKILL.md read paths.\n\n- SEA detection runs automatically on every dispatch (enabled by default) - SEA skills are deduplicated against the existing regex-based skill detection - Muted skills are filtered out - Added `enable_sea: bool` parameter (default `True`) - CLI supports `--no-sea` flag to disable", "htmlHref": "/research/html/sea-2-1-completion-report-skill-entity-dispatch-integration-18q3y0f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 348 }, { "id": "bwb-app-architecture-fa27bz", "title": "BWB — App Architecture", "slug": "bwb-app-architecture", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "spine/BWB/architecture/APP_ARCHITECTURE.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "BWB (Brews With Beats) is a **three-app coffee platform** built on iOS with a shared Swift package architecture. All apps share a common codebase through BWBCore and connect to Supabase as the backend.", "excerpt": "BWB (Brews With Beats) is a **three-app coffee platform** built on iOS with a shared Swift package architecture. All apps share a common codebase through BWBCore and connect to Supabase as the backend.\n\n| Attribute | Value | |-----------|-------| | Platform | iOS 17+ | | Language | Swift 5.9 | | UI Framework | SwiftUI | | Backend | Supabase (PostgreSQL + Auth + Realtime) | | Architecture | Three-app + Shared Package |\n\n**Tab Navigation:** | Tab | Function | |-----|----------| | Home | Welcome, quick actions, rewards summary | | Menu | Browse, search, customize, add to cart | | Events | DJ events, RSVP, featured lineup | | Orders | Active orders, history, tracking | | Profile | User info, rewards tier, settings |\n\n**Key Features:** - Voice ordering via iOS SpeechAnalyzer - Cart management with customizations - 4-step checkout (Review → Payment → Pickup → Confirm) - Real-time order tracking via Supabase Realtime - Rewards points and tier progression - Event RSVP with guest management\n\n**Required Permissions:** - Microphone (voice ordering) - Speech Recognition - HealthKit (dance rewards) - Motion (dance tracking)", "htmlHref": "/research/html/bwb-app-architecture-fa27bz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1057 }, { "id": "serenity-soother-affinity-graph-architecture-g0rhle", "title": "Serenity Soother — Affinity Graph Architecture", "slug": "serenity-soother-affinity-graph-architecture", "kind": "architecture", "program": "Research Backlog", "sourceAnchor": "spine/Serenity-Soother/architecture/AFFINITY_GRAPH.md", "extension": "md", "score": 44, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Document ID:** SS-ARCH-002 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/SS/SerenitySoother/SerenitySoother/Core/Infrastructure/AffinityGraph.swift`", "excerpt": "**Document ID:** SS-ARCH-002 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/SS/SerenitySoother/SerenitySoother/Core/Infrastructure/AffinityGraph.swift`\n\nA living graph of user relationships that evolves as users create and interact. Uses Locality-Sensitive Hashing (LSH) for O(1) matching at scale.\n\n| Type | Affinity | Behavior | |------|----------|----------| | Soul Mirror | 95-100% | Instant auto-share | | Kindred Spirit | 85-95% | Auto-accept on return | | Resonant Traveler | 75-85% | Preview before accept | | Parallel Path | 70-75% | Notify only | | Distant Echo | <70% | No connection |\n\n### Problem Naive O(n²) comparison doesn't scale: - 1M users = 500 billion comparisons\n\n### Configuration - `bucketThreshold`: 1000 users per bucket - `edgeCacheDuration`: 1 hour", "htmlHref": "/research/html/serenity-soother-affinity-graph-architecture-g0rhle.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 933 }, { "id": "phase-5-evaluation-suite-b54sqo", "title": "Phase 5: Evaluation Suite", "slug": "phase-5-evaluation-suite", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/_recovered/retrieval/cc-rag-plus-plus/docs/CognitiveTwin/07_EVALUATION_SUITE.md", "extension": "md", "score": 42, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> **Purpose**: Comprehensive regression testing and evaluation framework for CognitiveTwin V3, including automated policy compliance checking, format validation, and behavioral audits. > > **Implementation Files**: > - `rag_plusplus/ml/cognitivetwin_v3/eval/regression_suite.py` > - `rag_plusplus/ml/cognitivetwin_v3/eval/metrics.py` > - `rag_plusplus/ml/cognitivetwin_v3/eval/scorers.py`", "excerpt": "> **Purpose**: Comprehensive regression testing and evaluation framework for CognitiveTwin V3, including automated policy compliance checking, format validation, and behavioral audits. > > **Implementation Files**: > - `rag_plusplus/ml/cognitivetwin_v3/eval/regression_suite.py` > - `rag_plusplus/ml/cognitivetwin_v3/eval/metrics.py` > - `rag_plusplus/ml/cognitivetwin_v3/eval/scorers.py`\n\npython\\ndef process_data(data):\\n # Step 1: Validate\\n if not data:\\n return None\\n # Step 2: Transform\\n result = [x * 2 for x in data]\\n # Step 3: Aggregate\\n total = sum(result)\\n return {'values': result, 'total': total}\\n", "htmlHref": "/research/html/phase-5-evaluation-suite-b54sqo.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2818 }, { "id": "cognitivetwin-v2-technical-evaluation-report-14lbrzt", "title": "CognitiveTwin V2 Technical Evaluation Report", "slug": "cognitivetwin-v2-technical-evaluation-report", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/_recovered/retrieval/cc-rag-plus-plus/docs/CognitiveTwin/V2/COGNITIVETWIN_V2_EVALUATION_REPORT.md", "extension": "md", "score": 42, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document presents a comprehensive analysis of the CognitiveTwin V2 fine-tuned language model, comparing its performance characteristics against the base Meta Llama 3.1 8B Instruct model from which it derives. The evaluation methodology encompasses multiple dimensions of model behavior including response structure, coherence patterns, stylistic fidelity, and domain-specific adaptation. The fine-tuning process successfully transferred identifiable patterns from the training corpus into the model's generative beh", "excerpt": "This document presents a comprehensive analysis of the CognitiveTwin V2 fine-tuned language model, comparing its performance characteristics against the base Meta Llama 3.1 8B Instruct model from which it derives. The evaluation methodology encompasses multiple dimensions of model behavior including response structure, coherence patterns, stylistic fidelity, and domain-specific adaptation. The fine-tuning process successfully transferred identifiable patterns from the training corpus into the model's generative behavior, with measurable improvements in characteristic phrase usage, topic consistency, and technical term density. The fine-tuned model demonstrates a distinct response profile characterized by longer sentence structures, increased use of numbered lists over bullet points, and higher concentration of domain-specific terminology compared to the base model.\n\nThe CognitiveTwin V2 represents an instance of supervised fine-tuning applied to the Meta Llama 3.1 8B Instruct foundation model. The training objective centers on adapting the model's response patterns to reflect the stylistic and structural characteristics observed in a corpus of 979 conversational exchanges extracted from the Supabase memory_turns table. The training procedure employed full-parameter fine-tuning over three epochs using the Together AI infrastructure, with the resulting model deployed as a private endpoint accessible via the Together API. This evaluation seeks to quantify the degree to which the fine-tuning process achieved its intended objectives and to characterize the behavioral differences between the adapted model and its base counterpart.\n\nThe evaluation framework implements a parallel comparison architecture wherein both the fine-tuned model and the base model receive identical prompts under controlled conditions. Each prompt originates from one of two sources: authentic user interactions extracted from the training data distribution, or synthetically constructed queries designed to probe specific capability domains including code generation, architectural reasoning, technical explanation, and debugging assistance. The evaluation pipeline processes fifteen distinct prompts through both models, collecting the raw response text along with generation timing metrics. Each response undergoes multi-dimensional analysis through a suite of computational linguistics measures that quantify structural, coherence, and stylistic properties without relying on subjective human judgment.\n\nThe response metrics subsystem computes word count, sentence count, average sentence length, lexical diversity as measured by type-token ratio, code block frequency, list formatting patterns including both numbered and bulleted styles, header usage, question frequency, unique vocabulary size, a", "htmlHref": "/research/html/cognitivetwin-v2-technical-evaluation-report-14lbrzt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2720 }, { "id": "strudel-integration-plan-option-a-1kw7xze", "title": "Strudel Integration Plan - Option A", "slug": "strudel-integration-plan-option-a", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/STRUDEL_INTEGRATION_PLAN.md", "extension": "md", "score": 42, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "```bash cd apps/desktop/cc-echelon/apps/echelon-tauri npm install @strudel.cycles/core @strudel.cycles/webaudio @strudel.cycles/tonal tone ```", "excerpt": "## Overview Wire existing Rust components (Conductor, Rehearsal, LIM-RPS) to Strudel.js for real-time pattern-based music generation.\n\n## Current State - ✅ LIM-RPS latent physics (Python + Rust) - ✅ Computational rehearsal (`cc-brain/rehearsal.rs`) - ✅ Conductor with section state machine (`cc-brain/conductor.rs`) - ✅ Strudel-IR types complete (`cc-protocol/strudel_ir`) - ✅ Audio engine with synths/effects - ✅ Tauri frontend with real-time visualization - ❌ No Strudel runtime executing patterns - ❌ No bridge from Rust PatternEdit → JavaScript execution\n\n- [ ] Run `echelon-tauri` with `--local-mcs` - [ ] Start EchelonCapture iOS app, connect to local backend - [ ] Dance with phone in hand - [ ] Observe latent state updating in Tauri console - [ ] Hear Strudel patterns change based on movement - [ ] Check console for \"📨 Received PatternEdit\" messages - [ ] Verify section transitions (Intro → Groove → Build)\n\n1. **Add Rehearsal Integration** (Week 2) - Wire `RehearsalEngine` to predict future latent states - Use trajectory shape to pre-schedule edits\n\n2. **Expand Pattern Vocabulary** (Week 3) - More complex Strudel patterns (polyrhythms, euclidean, etc.) - Track-specific transforms (stutter, reverse, degrade) - FX automation (filter sweeps, delay throws)", "htmlHref": "/research/html/strudel-integration-plan-option-a-1kw7xze.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1585 }, { "id": "phase-5-evaluation-suite-13e8b91", "title": "Phase 5: Evaluation Suite", "slug": "phase-5-evaluation-suite", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/docs/CognitiveTwin/07_EVALUATION_SUITE.md", "extension": "md", "score": 42, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> **Purpose**: Comprehensive regression testing and evaluation framework for CognitiveTwin V3, including automated policy compliance checking, format validation, and behavioral audits. > > **Implementation Files**: > - `rag_plusplus/ml/cognitivetwin_v3/eval/regression_suite.py` > - `rag_plusplus/ml/cognitivetwin_v3/eval/metrics.py` > - `rag_plusplus/ml/cognitivetwin_v3/eval/scorers.py`", "excerpt": "> **Purpose**: Comprehensive regression testing and evaluation framework for CognitiveTwin V3, including automated policy compliance checking, format validation, and behavioral audits. > > **Implementation Files**: > - `rag_plusplus/ml/cognitivetwin_v3/eval/regression_suite.py` > - `rag_plusplus/ml/cognitivetwin_v3/eval/metrics.py` > - `rag_plusplus/ml/cognitivetwin_v3/eval/scorers.py`\n\npython\\ndef process_data(data):\\n # Step 1: Validate\\n if not data:\\n return None\\n # Step 2: Transform\\n result = [x * 2 for x in data]\\n # Step 3: Aggregate\\n total = sum(result)\\n return {'values': result, 'total': total}\\n", "htmlHref": "/research/html/phase-5-evaluation-suite-13e8b91.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2818 }, { "id": "cognitivetwin-v2-technical-evaluation-report-r6ivek", "title": "CognitiveTwin V2 Technical Evaluation Report", "slug": "cognitivetwin-v2-technical-evaluation-report", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/docs/CognitiveTwin/V2/COGNITIVETWIN_V2_EVALUATION_REPORT.md", "extension": "md", "score": 42, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document presents a comprehensive analysis of the CognitiveTwin V2 fine-tuned language model, comparing its performance characteristics against the base Meta Llama 3.1 8B Instruct model from which it derives. The evaluation methodology encompasses multiple dimensions of model behavior including response structure, coherence patterns, stylistic fidelity, and domain-specific adaptation. The fine-tuning process successfully transferred identifiable patterns from the training corpus into the model's generative beh", "excerpt": "This document presents a comprehensive analysis of the CognitiveTwin V2 fine-tuned language model, comparing its performance characteristics against the base Meta Llama 3.1 8B Instruct model from which it derives. The evaluation methodology encompasses multiple dimensions of model behavior including response structure, coherence patterns, stylistic fidelity, and domain-specific adaptation. The fine-tuning process successfully transferred identifiable patterns from the training corpus into the model's generative behavior, with measurable improvements in characteristic phrase usage, topic consistency, and technical term density. The fine-tuned model demonstrates a distinct response profile characterized by longer sentence structures, increased use of numbered lists over bullet points, and higher concentration of domain-specific terminology compared to the base model.\n\nThe CognitiveTwin V2 represents an instance of supervised fine-tuning applied to the Meta Llama 3.1 8B Instruct foundation model. The training objective centers on adapting the model's response patterns to reflect the stylistic and structural characteristics observed in a corpus of 979 conversational exchanges extracted from the Supabase memory_turns table. The training procedure employed full-parameter fine-tuning over three epochs using the Together AI infrastructure, with the resulting model deployed as a private endpoint accessible via the Together API. This evaluation seeks to quantify the degree to which the fine-tuning process achieved its intended objectives and to characterize the behavioral differences between the adapted model and its base counterpart.\n\nThe evaluation framework implements a parallel comparison architecture wherein both the fine-tuned model and the base model receive identical prompts under controlled conditions. Each prompt originates from one of two sources: authentic user interactions extracted from the training data distribution, or synthetically constructed queries designed to probe specific capability domains including code generation, architectural reasoning, technical explanation, and debugging assistance. The evaluation pipeline processes fifteen distinct prompts through both models, collecting the raw response text along with generation timing metrics. Each response undergoes multi-dimensional analysis through a suite of computational linguistics measures that quantify structural, coherence, and stylistic properties without relying on subjective human judgment.\n\nThe response metrics subsystem computes word count, sentence count, average sentence length, lexical diversity as measured by type-token ratio, code block frequency, list formatting patterns including both numbered and bulleted styles, header usage, question frequency, unique vocabulary size, a", "htmlHref": "/research/html/cognitivetwin-v2-technical-evaluation-report-r6ivek.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2720 }, { "id": "knowledge-ferment-7razv5", "title": "Knowledge Ferment", "slug": "knowledge-ferment", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/knowledge-ferment/SKILL.md", "extension": "md", "score": 42, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Ideas age in storage, gain depth through passive cross-linking. > **NEW in v2.3:** The Vineyard — move upstream from cellar to cultivation. Plant idea seeds in terroir plots, graft concepts across domains, observe growing seasons, prune weak branches, and harvest when ripe. The cellar receives. The vineyard creates.", "excerpt": "> Ideas age in storage, gain depth through passive cross-linking. > **NEW in v2.3:** The Vineyard — move upstream from cellar to cultivation. Plant idea seeds in terroir plots, graft concepts across domains, observe growing seasons, prune weak branches, and harvest when ripe. The cellar receives. The vineyard creates.\n\nLike wine or cheese, some ideas improve with time. Knowledge Fermentation is passive incubation — ideas rest in a cellar, and the system periodically discovers connections that weren't obvious when the idea was young.\n\n**Contrast with Dream Weaver:** - Dream Weaver: Active incubation, guided evolution, explicit growth cycles - Knowledge Ferment: Passive aging, emergent connections, time-based depth\n\n| Age | Stage | Depth Modifier | |-----|-------|----------------| | 0-1d | Fresh | 1.0× | | 1-7d | Young | 1.2× | | 7-30d | Maturing | 1.5× | | 30-90d | Aged | 2.0× | | 90d+ | Vintage | 3.0× |\n\n**Depth** increases as: 1. Time passes (natural aging) 2. Cross-links are discovered 3. Ideas are referenced in conversations 4. Related ideas enter the cellar", "htmlHref": "/research/html/knowledge-ferment-7razv5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 9956 }, { "id": "04-architecture-forge-zyfsnv", "title": "04 — Architecture Forge", "slug": "04-architecture-forge", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "leisure-goal-synthesis/04-architecture.md", "extension": "md", "score": 42, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Track 4 of 4 in the leisure-goal synthesis.** **Subject:** Phone-as-cockpit, mesh-as-engine. The operating-system spine. **Anchor commit:** Pebble HEAD `3803b76` (V0.8 P5 Wave 4 iPad split-view shipped 2026-05-11).", "excerpt": "**Track 4 of 4 in the leisure-goal synthesis.** **Subject:** Phone-as-cockpit, mesh-as-engine. The operating-system spine. **Anchor commit:** Pebble HEAD `3803b76` (V0.8 P5 Wave 4 iPad split-view shipped 2026-05-11).\n\n> **Leisure** is the state where the home Macs hold the project memory, the home Macs do the work, and the iPhone is the cockpit. The phone never *runs* the system; the phone *governs* it. Confirmations are cheap, intervention is rare, and the system has a fallback for every degraded path so partial-mesh is the *normal* operating state, not the exception.\n\nThe formula has one binding constraint: **every reachable mesh capability must be addressable from the phone, or it is a bug, not a phase-1 limitation.**\n\nThese are the only legitimate shapes work can take in the leisure OS. Mixing two archetypes inside a single endpoint is forbidden (the Crucible architecture spine already enforces this for Pebble V0.8). Every new feature must declare its archetype before it gets built.\n\n| # | Archetype | Plane | Failure mode | Concrete examples | |---|---|---|---|---| | 1 | **ControlOp** | Control | Throw loudly, never silently retry | Pebble send-prompt; aura-gateway `/inject`; codex-gateway `/codex/inject`; restart-service; switch-chat | | 2 | **DataStream** | Data | Silent retry, banner only when stale | Pane snapshot polling; `/panes//response`; mesh_pane_state reads; iMessage-like delivery dots | | 3 | **CaptainSummary** | Bridge | Always falls back to gateway heuristic | `/captain/ask` `Where are we?`; rate-limit status; next-prompt drafts; `[CTRL]/[DATA]/[STATE]/[COMPACT]/[CONTEXT-RESET]` prefix language | | 4 | **SensorStream** | Data | Drop frames on backpressure | KARL trajectories; cognitive-twin events; Femto/MediaPipe pose at LUMA :9703; ntfy idle-detection state machine on mac4 | | 5 | **AutopilotAgent** | Bridge | Pause on first failure, never silent loop | Captain `draft N+1` → Codex auto-queue; Pulse sessions; ops:autopilot sleep-loop; mac4 idle-watcher → ntfy | | 6 | **WidgetGlance** | Projection | Read-only, schema-checked, ≤120 char previews | Pebble Home Screen widget reading `/projection/latest.json`; MeshHealth tile (planned) | | 7 | **VoiceDictation** | Control | Always editable before send | Pebble Whisper composer; cue-prompt drafts; future Siri Shortcuts via AppIntent |", "htmlHref": "/research/html/04-architecture-forge-zyfsnv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2376 }, { "id": "agent-command-center-voice-first-architecture-1u7055s", "title": "Agent Command Center — Voice-First Architecture", "slug": "agent-command-center-voice-first-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "AgentCommandCenter/ACC-VOICE-ARCHITECTURE.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The ACC isn't just another iOS app — it's the **voice-first command interface** for the entire agent stack. Discord has been serving as the de facto command center. ACC formalizes that into a native experience where **voice is primary, visual is secondary**.", "excerpt": "# Agent Command Center — Voice-First Architecture **Status:** 🌱 Design Phase (from Mo's 1:21 AM voice notes, Feb 16 2026) **Origin:** Voice brainstorm → formalized spec\n\n> \"The voice itself is the most intuitive... Discord was our Agent Command Center replicate.\"\n\nThe ACC isn't just another iOS app — it's the **voice-first command interface** for the entire agent stack. Discord has been serving as the de facto command center. ACC formalizes that into a native experience where **voice is primary, visual is secondary**.\n\n### Layer 0: Voice Interface (Primary) - **Always-on voice capture** → transcription → intent routing - Google Speech-to-Text API (enabled on `speech-to-order-476916` project) - Fallback: local mlx_whisper (on-device, offline-capable) - ElevenLabs voice clone (Mohamed voice ID: `TmSgyk1vGAD9YzdtJV3V`) for responses - VisionClaw's ambient voice pipeline patterns as reference (but actually functional, not stubbed)\n\n### Layer 1: Command Center UI (Background) - SwiftUI + TCA (already built through Phase 4) - Mission Control view = visual confirmation of voice commands - Thread visualization = see Pulse execution trees - Infrastructure health = at-a-glance agent status", "htmlHref": "/research/html/agent-command-center-voice-first-architecture-1u7055s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 882 }, { "id": "rag-graph-kernel-detailed-improvement-analysis-oxy78w", "title": "RAG++ & Graph Kernel — Detailed Improvement Analysis", "slug": "rag-graph-kernel-detailed-improvement-analysis", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "cognitive-twin/RAG_IMPROVEMENT_ANALYSIS.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Track | Target | Status | ETA | |-------|--------|--------|-----| | **Track 1: MiniMax Density Scoring** | kimi_memory.db (9.1K user turns) | 🟢 62% complete, 0 errors | ~1.5h | | **Track 2: RAG++ & Graph Kernel** | Search quality, entity enrichment | 🔴 Audited, issues documented | Needs work |", "excerpt": "| Track | Target | Status | ETA | |-------|--------|--------|-----| | **Track 1: MiniMax Density Scoring** | kimi_memory.db (9.1K user turns) | 🟢 62% complete, 0 errors | ~1.5h | | **Track 2: RAG++ & Graph Kernel** | Search quality, entity enrichment | 🔴 Audited, issues documented | Needs work |\n\n**Running process:** PID 56430, `density_scorer.py --role user --min-length 50 --parallel 4`\n\n| Tier | Count | % | Description | |------|-------|---|-------------| | CORE | 146 | 2.6% | Deep values, unique decisions, strong preferences | | ENRICHED | 559 | 9.8% | Substantive context, project decisions | | ACTIVE | 2,983 | 52.3% | Normal productive conversation | | PRUNED | 1,317 | 23.1% | Low-value, boilerplate, noise | | ERROR (parse) | 695 | 12.2% | MiniMax output parsing failures |\n\n**Projected final (at current ratios):** - CORE: ~235 turns - ENRICHED: ~900 turns - **High-value (CORE+ENRICHED): ~1,135 turns** for v9 expansion\n\n**Output:** `Desktop/cognitive-twin/output/density_scores_20260216_183513.jsonl` (5,792 lines, 1.2MB)", "htmlHref": "/research/html/rag-graph-kernel-detailed-improvement-analysis-oxy78w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1892 }, { "id": "cadence-protocol-frictionless-agent-communication-1vujlty", "title": "Cadence Protocol: Frictionless Agent Communication", "slug": "cadence-protocol-frictionless-agent-communication", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/.governance/systems/CADENCE_PROTOCOL.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "MCP (Model Context Protocol) introduces approval friction: - Every tool call requires user confirmation - Breaks flow for repetitive operations - No priority differentiation - Synchronous approval model", "excerpt": "MCP (Model Context Protocol) introduces approval friction: - Every tool call requires user confirmation - Breaks flow for repetitive operations - No priority differentiation - Synchronous approval model\n\n1. **Actions, not Approvals**: High-confidence operations execute immediately 2. **Priority-Based Processing**: Critical actions queue, routine actions execute 3. **Background Execution**: Non-blocking async message handling 4. **Visual Feedback**: Action stream shows what's happening without blocking 5. **Reversible by Default**: All actions can be undone\n\n| Level | Name | Behavior | |-------|------|----------| | 1-2 | Low | Queued, batched execution, no notification | | 3-4 | Normal | Queued, executed in order, visual indicator | | 5-6 | High | Immediate execution, notification | | 7+ | Critical | Immediate, blocks until complete, alert |\n\n| Aspect | MCP | Cadence Protocol | |--------|-----|------------------| | **Approval** | Every tool call | Trust-based, priority-based | | **Execution** | Synchronous | Async with background threads | | **Batching** | None | Normal priority batches | | **Reversibility** | Not tracked | Built-in undo chain | | **Audit** | Limited | Full action log | | **Visual** | Tool call output | Action stream UI | | **Agent-to-Agent** | Not supported | Native INBOX/OUTBOX | | **Priority** | None | 7 levels | | **Blocking** | Always | Only critical (7+) |\n\n| Signal | Low Coherence | High Coherence | |--------|---------------|----------------| | **Error rate** | Many errors, retries | Few errors | | **Action spread** | Jumping between areas | Focused area | | **Decision continuity** | New topics | Continuation | | **User response time** | Quick rejections | Quick approvals | | **Session duration** | Just started (<5min) | Sustained (>30min) |", "htmlHref": "/research/html/cadence-protocol-frictionless-agent-communication-1vujlty.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2846 }, { "id": "enhancement-roadmap-cc-dashboard-13w3mbd", "title": "🚀 Enhancement Roadmap: cc-dashboard", "slug": "enhancement-roadmap-cc-dashboard", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/apps/web/cc-dashboard/ENHANCEMENT_ROADMAP.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Implementation**: ```typescript // New component: TrajectoryGraph.tsx {/* Plot tension over time */} {/* Plot energy over time */} {/* Current time marker */} ```", "excerpt": "**Current Status**: Phase 4 Complete (Predictive Music System Operational) **Date**: December 20, 2025\n\n**Approach**: - Track velocity (rate of change of latent state) - Add momentum term - Model acceleration/deceleration - Estimate uncertainty bounds\n\n**Gestures**: - Shake → Instant climax - Swipe down → Breakdown - Circle → Build - Double tap → Reset to intro\n\n**Training**: - Collect 20-50 user sessions - Annotate \"good\" vs \"bad\" transitions - Train model to predict PatternEdits from latent state - Use trajectory features as input\n\n**Deployment**: - Export to ONNX - Run in browser with onnxruntime-web - Real-time inference", "htmlHref": "/research/html/enhancement-roadmap-cc-dashboard-13w3mbd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2132 }, { "id": "cc-mcs-daemon-architecture-abrxyw", "title": "CC-MCS Daemon Architecture", "slug": "cc-mcs-daemon-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-mcs/DAEMON_ARCHITECTURE.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The \"Living Timeline\" daemon is an always-on motion processing service that runs on a GCP VM. It maintains continuous sensor alignment, anticipation computation, and gesture detection.", "excerpt": "The \"Living Timeline\" daemon is an always-on motion processing service that runs on a GCP VM. It maintains continuous sensor alignment, anticipation computation, and gesture detection.\n\n### 1. DO Relay (DigitalOcean) - **Purpose**: UDP ingress, NAT traversal - **IP**: [ip] - **Cost**: ~$5/month - **Why**: Mobile devices need a stable public endpoint\n\n### 2. GCP VM (cc-infrastructure-vm) - **Purpose**: Always-on alignment and processing daemon - **IP**: [ip] - **Machine**: e2-small (2 vCPU, 2GB RAM) - **Cost**: ~$19/month - **Container**: cc-mcs-daemon\n\n### 3. Cloud Run Services - **Purpose**: Heavy compute (RAG, training), on-demand - **orbit-server**: Project orchestration, RAG proxy - **rag-plusplus**: Semantic search, CognitiveTwin training - **Cost**: ~$0-5/month (pay per use)\n\n| Stage | Input | Output | Rate | |-------|-------|--------|------| | Ingress | Raw packets | DeviceFrame | Variable | | Fusion | DeviceFrames | FusedSkeleton | 60Hz | | Window | FusedSkeleton | MotionWindow | 50Hz | | Anticipation | MotionWindow | AnticipationPacket | 50Hz | | Gesture | AnticipationPacket | GestureEvent | On detection | | Conductor | AnticipationPacket | PolicySignals | 50Hz |", "htmlHref": "/research/html/cc-mcs-daemon-architecture-abrxyw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1161 }, { "id": "documentation-audit-pass-2-content-deep-dive-complete-report-1h3w1ny", "title": "Documentation Audit - Pass 2: Content Deep Dive - COMPLETE REPORT", "slug": "documentation-audit-pass-2-content-deep-dive-complete-report", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/DOCUMENTATION_AUDIT_PASS2_COMPLETE.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**The Core Issue**: Many documents describe future features as if they're currently implemented, creating confusion about what exists today vs what's planned for tomorrow.", "excerpt": "**Date**: December 21, 2025 **Pass**: 2 of 5 **Status**: ✅ Complete **Next**: Pass 3 (Consolidation & Labeling)\n\n**Documentation Quality**: **EXCELLENT** (9/10) **Reality Representation**: **MISLEADING** (5/10)\n\n**The Core Issue**: Many documents describe future features as if they're currently implemented, creating confusion about what exists today vs what's planned for tomorrow.\n\n**The Solution**: Add clear implementation status markers throughout documentation. Preserve aspirational vision but label it honestly.\n\n**The Interview** = Conversational AI-driven skill discovery flow that serves as the **PRIMARY user interface** for TrajectoryOS.", "htmlHref": "/research/html/documentation-audit-pass-2-content-deep-dive-complete-report-1h3w1ny.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2644 }, { "id": "ircp-model-capabilities-with-claude-conversation-data-xlb25x", "title": "🎯 IRCP Model Capabilities with Claude Conversation Data", "slug": "ircp-model-capabilities-with-claude-conversation-data", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/outputs/CLAUDE_MODEL_CAPABILITIES_SUMMARY.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "- Successfully generates 384-dimensional embeddings for all Claude messages - Processes messages in batches efficiently (14 batches for 434 messages) - Embeddings capture semantic meaning across different conversation topics", "excerpt": "## 🎭 Overview Your trained IRCP model, which was originally trained on OpenAI conversation data, demonstrates remarkable **zero-shot transfer capabilities** when applied to Claude AI conversation data. Despite never seeing Claude conversations during training, the model successfully processes and analyzes this new data format.\n\n### 🔢 Dataset Statistics - **Total Conversations Processed**: 20 conversations - **Total Messages Analyzed**: 434 messages - **Average Messages per Conversation**: 21.7 - **Average Tokens per Message**: 300.18 - **Unique Authors**: 2 (human, assistant)\n\n- Successfully generates 384-dimensional embeddings for all Claude messages - Processes messages in batches efficiently (14 batches for 434 messages) - Embeddings capture semantic meaning across different conversation topics\n\n### 2. 📊 **Message Similarity Analysis** ✅ **Status**: **EXCELLENT PERFORMANCE**\n\n**Top Similarity Examples**: - **Perfect matches** (1.0000 similarity): Identical messages correctly identified - **High semantic similarity** (0.7695): Related responses about the same topic - **Contextual understanding**: Recognizes when different messages discuss similar concepts", "htmlHref": "/research/html/ircp-model-capabilities-with-claude-conversation-data-xlb25x.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 996 }, { "id": "ircp-training-infrastructure-analysis-dlmdataloader-integration-guide-1pw9p2b", "title": "IRCP Training Infrastructure Analysis & DLMDataLoader Integration Guide", "slug": "ircp-training-infrastructure-analysis-dlmdataloader-integration-guide", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/summaries/IRCP_TRAINING_INFRASTRUCTURE_ANALYSIS.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document provides a comprehensive analysis of the IRCP training infrastructure and a detailed integration plan for the DLMDataLoader from Phase 3.1. The IRCP framework uses an ICP trainer with a sophisticated multi-component loss function and database-backed data loading. Integration with DLMDataLoader will improve data loading efficiency and provide unified coordinate system support.", "excerpt": "This document provides a comprehensive analysis of the IRCP training infrastructure and a detailed integration plan for the DLMDataLoader from Phase 3.1. The IRCP framework uses an ICP trainer with a sophisticated multi-component loss function and database-backed data loading. Integration with DLMDataLoader will improve data loading efficiency and provide unified coordinate system support.\n\n**File**: `[home]/Desktop/Computational Choreography/cc-tpo/packages/ircp/training/icp_trainer.py`\n\nThe ICPTrainer is the main training orchestrator for the IRCP framework with the following capabilities:\n\n#### Core Methods - `train(train_data: List[ICPDataPoint], val_data: Optional[List[ICPDataPoint]]) -> Dict` - `validate_epoch(val_loader: DataLoader) -> float` - `train_epoch(train_loader: DataLoader) -> float` - `_create_dataloader(data_points: List[ICPDataPoint], mode: str) -> DataLoader` - `save_checkpoint(epoch: int, val_loss: float, is_best: bool)` - `load_checkpoint(checkpoint_path: str)` - `get_training_statistics() -> Dict[str, Any]` - `export_model(export_path: str, format: str)`\n\n**Data Validation**: Filters out invalid data points: - embedding is not None and has length > 0 - embedding contains no NaN values - coordinates is not None", "htmlHref": "/research/html/ircp-training-infrastructure-analysis-dlmdataloader-integration-guide-1pw9p2b.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3336 }, { "id": "graph-kernel-benchmark-evaluation-1k8oewe", "title": "Graph Kernel Benchmark Evaluation", "slug": "graph-kernel-benchmark-evaluation", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/benchmarks/graph-kernel-evaluation.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The Graph Kernel service at `localhost:8001` was evaluated against three baseline retrieval methods across 27 queries in 5 categories. The evaluation reveals that the Graph Kernel is **not a general-purpose search engine** — it's a **deterministic context slicing engine** with a bolted-on knowledge graph. Its real value lies in provenance-tracked, policy-governed context construction — not keyword matching.", "excerpt": "**Date:** 2026-02-13 **Version:** Graph Kernel v0.1.0, Schema v1.0.0 **Author:** Automated benchmark suite\n\nThe Graph Kernel service at `localhost:8001` was evaluated against three baseline retrieval methods across 27 queries in 5 categories. The evaluation reveals that the Graph Kernel is **not a general-purpose search engine** — it's a **deterministic context slicing engine** with a bolted-on knowledge graph. Its real value lies in provenance-tracked, policy-governed context construction — not keyword matching.\n\n**Verdict:** Worth the operational complexity **if** you need deterministic, auditable context construction. The knowledge graph query layer needs significant improvement to compete with even naive baselines for ad-hoc search.\n\n### Graph Kernel (localhost:8001) - **Language:** Rust (Axum + sqlx) - **Storage:** PostgreSQL (Supabase-hosted, remote) - **Data:** 2,681 knowledge triples (subject–predicate–object), 70 unique subjects, 39 unique predicates - **Source:** Kimi-K2 memory extraction (synced from conversation history) - **Primary purpose:** Deterministic context slicing for conversation DAGs - **Secondary purpose:** Knowledge graph triple store (the `/api/knowledge` endpoint we're benchmarking)\n\n### Baselines | Method | Description | |--------|------------| | **Keyword** | Substring matching across `subject + predicate + object` text | | **BM25** | Classic Okapi BM25 (k1=1.5, b=0.75) over the same triple corpus | | **RAG++** (localhost:8000) | Vector similarity search over 107K+ conversation turns (embeddings) |", "htmlHref": "/research/html/graph-kernel-benchmark-evaluation-1k8oewe.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2326 }, { "id": "the-render-stack-architecture-13upw3f", "title": "**THE RENDER STACK ARCHITECTURE**", "slug": "the-render-stack-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/docs/ui/11. THE RENDER STACK ARCHITECTURE.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Here is the full **render-stack architecture** for Echelon — the exact multi-layer rendering pipeline that turns latent physics into shaders, deformations, lighting, and compositing. This is the graphics equivalent of LIM-RPS: a layered, contractive, hierarchical system designed so that **every visual element is explicitly driven by the latent and its dynamical derivatives**, not by arbitrary UI animation.", "excerpt": "Here is the full **render-stack architecture** for Echelon — the exact multi-layer rendering pipeline that turns latent physics into shaders, deformations, lighting, and compositing. This is the graphics equivalent of LIM-RPS: a layered, contractive, hierarchical system designed so that **every visual element is explicitly driven by the latent and its dynamical derivatives**, not by arbitrary UI animation.\n\nThis is the real architecture you’d implement in a modern GPU stack (WebGPU / Metal / Vulkan / Unity HDRP / Unreal Custom Render Pipeline). I’ll describe it in continuous, structured language.\n\nEach domain is internally modular, but they flow like a physics engine: latent → forces → deformation → lighting → compositing.\n\nLIM-RPS is the nervous system. The animation engine is the musculature. The render stack is the flesh and skin that visibly moves.\n\nthe current latent the latent delta relative to the neutral state the lexicon fields (tension, divergence, transition intensity, etc.) the section state (stable, divergence, transition, reformation, resolution)", "htmlHref": "/research/html/the-render-stack-architecture-13upw3f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1002 }, { "id": "rag-chatgpt-memory-integration-hard-specification-yqe5ga", "title": "RAG++ ChatGPT Memory Integration: Hard Specification", "slug": "rag-chatgpt-memory-integration-hard-specification", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/SPECIFICATION_HARD.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Build a conversation-memory substrate for Computational Choreography where ChatGPT export is ingested **without losing DAG truth**, exposed through retrieval that answers four question classes:", "excerpt": "**Version**: 1.0.0 **Status**: LOCKED - Implementation Grade **Last Updated**: 2025-12-27\n\nBuild a conversation-memory substrate for Computational Choreography where ChatGPT export is ingested **without losing DAG truth**, exposed through retrieval that answers four question classes:\n\n1. **Exact**: \"What did I say?\" (lexical, IDs, timestamps) 2. **Semantic**: \"What else like this?\" (dense vectors) 3. **Causal**: \"How did we get here?\" (DAG traversal) 4. **CC-Specific**: \"What stabilized last time?\" (motifs/invariants/decisions)\n\n### Non-Goals (MVP) - No agent memory reasoning engine - No training or online embedding updates (except stats/annotations) - No perfect phase classification (rule-based first)\n\nThe `mapping` in conversations.json contains nodes with parent/children links. Multiple children = regenerations/branching. If you flatten to single sequence, you destroy the most valuable property: alternative continuations and exact adjacency relations.", "htmlHref": "/research/html/rag-chatgpt-memory-integration-hard-specification-yqe5ga.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2558 }, { "id": "assumptions-invariants-ledger-1g0qzx1", "title": "Assumptions & Invariants Ledger", "slug": "assumptions-invariants-ledger", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-graph-kernel/docs/02-INVARIANTS_LEDGER.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| Invariant | Canary Type | Implemented? | Notes | |-----------|-------------|--------------|-------| | INV-GK-001 | Log + metric | ❌ No | Need to add `slice_boundary_violations_total` counter | | INV-GK-002 | Schema validation | ✅ Yes | `SliceExport::new_with_secret` requires all fields | | INV-GK-003 | Type system | ❌ No | Need to add `AdmissibleEvidenceBundle` type | | INV-GK-004 | Periodic check | ❌ No | Need background job to re-verify content hashes | | INV-GK-005 | Metric | ❌ No | Need `token_verification_fa", "excerpt": "Assumptions are things the project relies on that could be false. If violated, specific parts break.\n\n### A-001: PostgreSQL is the only graph store **Assumption**: All turns and edges live in PostgreSQL, accessible via `GraphStore` trait. **What breaks if false**: Slice SQL queries won't work, connection pool assumptions fail. **Detection**: Attempt to use a different store → compile-time error (no other `GraphStore` implementations in production). **Mitigation**: Keep `GraphStore` trait abstract, avoid Postgres-specific SQL in core types.\n\n### A-002: Content hashes will reach 100% coverage **Assumption**: The incremental backfill will eventually give every turn a `content_hash`. **What breaks if false**: `GraphSnapshotHash::from_content_hashes` can't be used universally, replay is less reliable. **Detection**: Monitor `SELECT COUNT(*) FROM memory_turns WHERE content_hash IS NULL` → should trend to zero. **Mitigation**: Keep stats-based fallback until coverage >= 99%.\n\n### A-003: HMAC secret is 32+ bytes and never rotates **Assumption**: The `KERNEL_HMAC_SECRET` is strong and stable across restarts. **What breaks if false**: Token verification fails for old slices, replay breaks. **Detection**: Token verification failures spike after secret rotation. **Mitigation**: Document secret rotation requires re-slicing, or implement multi-key verification.\n\n### A-004: Downstream services trust kernel tokens without re-verification **Assumption**: RAG++ and Orbit check `admissibility_token` but don't re-verify HMAC locally. **What breaks if false**: Performance degrades (double verification), but security improves. **Detection**: Check if downstream code calls `/api/verify_token` or does HMAC locally. **Mitigation**: Make token verification cheap enough (<5ms) that double-checking is acceptable.", "htmlHref": "/research/html/assumptions-invariants-ledger-1g0qzx1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1010 }, { "id": "living-implementation-checklist-1nx6c47", "title": "Living Implementation Checklist", "slug": "living-implementation-checklist", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-graph-kernel/docs/04-IMPLEMENTATION_CHECKLIST.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- [x] **0.1** Create Project Charter - Owner: Agent - Input: Improvement document, existing architecture - Output: `docs/00-PROJECT_CHARTER.md` - Validation: Charter defines purpose, non-goals, success criteria - Status: ✅ Complete - Confidence: High", "excerpt": "**Version**: 1.2.0 **Last Updated**: 2026-01-02 **Status**: Complete (All 8 Phases)\n\n- [x] **0.1** Create Project Charter - Owner: Agent - Input: Improvement document, existing architecture - Output: `docs/00-PROJECT_CHARTER.md` - Validation: Charter defines purpose, non-goals, success criteria - Status: ✅ Complete - Confidence: High\n\n- [x] **0.2** Create System Glossary - Owner: Agent - Input: Existing code, architecture docs - Output: `docs/01-GLOSSARY.md` - Validation: All security terms defined, overloaded terms flagged - Status: ✅ Complete - Confidence: High\n\n- [x] **0.3** Create Invariants Ledger - Owner: Agent - Input: Improvement document, existing tests - Output: `docs/02-INVARIANTS_LEDGER.md` - Validation: All 8 invariants documented with canaries - Status: ✅ Complete - Confidence: High\n\n- [x] **0.4** Create Implementation Guide - Owner: Agent - Input: CLAUDE.md, improvement document - Output: `docs/03-IMPLEMENTATION_GUIDE.md` - Validation: Decision rules, decomposition rules, validation rules defined - Status: ✅ Complete - Confidence: High", "htmlHref": "/research/html/living-implementation-checklist-1nx6c47.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4567 }, { "id": "anticipation-1or1he0", "title": "Anticipation", "slug": "anticipation", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/architecture/06-ANTICIPATION.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Version**: 1.1.0 **Last Updated**: 2025-01-01 **Status**: Production **Parent**: [03-ECHELON.md](03-ECHELON.md) **Previous**: [05-SENSOR_FUSION.md](05-SENSOR_FUSION.md) **Next**: [07-GESTURE_RECOGNITION.md](07-GESTURE_RECOGNITION.md) **Crate**: `core/cc-anticipation/` **Tests**: 50 passing", "excerpt": "**Version**: 1.1.0 **Last Updated**: 2025-01-01 **Status**: Production **Parent**: [03-ECHELON.md](03-ECHELON.md) **Previous**: [05-SENSOR_FUSION.md](05-SENSOR_FUSION.md) **Next**: [07-GESTURE_RECOGNITION.md](07-GESTURE_RECOGNITION.md) **Crate**: `core/cc-anticipation/` **Tests**: 50 passing\n\nThe `cc-anticipation` crate converts stabilized motion windows into **anticipatory signals**. Unlike reactive systems that trigger on gesture completion, anticipation operates on the **pre-completion phase** of motion.\n\nThis is the **key insight** of Computational Choreography: we don't wait for motion to complete. We detect when motion becomes **irreversible** and act on **intention** rather than completion.\n\n**See**: [01-COMPUTATIONAL_CHOREOGRAPHY.md](01-COMPUTATIONAL_CHOREOGRAPHY.md) for the philosophical foundation.\n\nThe key insight of anticipation is that **commitment** and **uncertainty** provide a two-dimensional space for proactive decision-making:", "htmlHref": "/research/html/anticipation-1or1he0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1172 }, { "id": "audio-engine-cvtjmr", "title": "Audio Engine", "slug": "audio-engine", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/architecture/10-AUDIO_ENGINE.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Version**: 1.1.0 **Last Updated**: 2025-01-01 **Status**: Production **Parent**: [03-ECHELON.md](03-ECHELON.md) **Previous**: [07-GESTURE_RECOGNITION.md](07-GESTURE_RECOGNITION.md) **Crate**: `core/cc-echelon/crates/cc-conductor/` **Tests**: 31 passing", "excerpt": "**Version**: 1.1.0 **Last Updated**: 2025-01-01 **Status**: Production **Parent**: [03-ECHELON.md](03-ECHELON.md) **Previous**: [07-GESTURE_RECOGNITION.md](07-GESTURE_RECOGNITION.md) **Crate**: `core/cc-echelon/crates/cc-conductor/` **Tests**: 31 passing\n\nThe audio engine provides **beat-quantized scheduling**, **real-time DSP**, and **DJ software integration**. It operates under strict latency constraints where every millisecond matters.\n\n| Stage | Budget | Notes | |-------|--------|-------| | Gesture detection | 500μs | From cc-gesture | | Action scheduling | 100μs | Queue insertion | | Beat quantization | 50μs | Next beat calculation | | MIDI/OSC send | 200μs | Network I/O | | Audio callback | 5.3ms | 256 samples @ 48kHz | | **Total** | **< 6ms** | End-to-end |\n\n| Rule | Enforcement | |------|-------------| | No allocation | Pre-allocated buffers | | No blocking | Lock-free queues | | No syscalls | Avoid I/O in callback | | Bounded time | Fixed buffer size |\n\n| Stage | Budget | Notes | |-------|--------|-------| | Gesture detection | 500μs | From cc-gesture | | Action scheduling | 100μs | Queue insertion | | Beat quantization | 50μs | Next beat calculation | | MIDI/OSC send | 200μs | Network I/O | | Audio callback | 5.3ms | 256 samples @ 48kHz | | **Total** | **< 6ms** | End-to-end |", "htmlHref": "/research/html/audio-engine-cvtjmr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1117 }, { "id": "26-research-execution-fabric-ccbvbt", "title": "26. Research Execution Fabric", "slug": "26-research-execution-fabric", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/docs/architecture/26-RESEARCH_EXECUTION_FABRIC.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Status**: Active architecture **Scope**: Shared agent architecture for research-driven execution, remote training, evaluation, meta-review, and paper synthesis **Audience**: Claude Code, Codex, Gemini, orchestration services, paper-writing pipelines", "excerpt": "**Status**: Active architecture **Scope**: Shared agent architecture for research-driven execution, remote training, evaluation, meta-review, and paper synthesis **Audience**: Claude Code, Codex, Gemini, orchestration services, paper-writing pipelines\n\nThis document defines a global architecture for how the AI stack turns a prompt like:\n\n- \"Read this paper and reproduce the experiment\" - \"Train a model on this dataset\" - \"Run the Vast.ai workflow and tell me the result\" - \"Take the findings through evaluation, meta-review, and paper drafting\"\n\nThis is not an ASR-specific system. This is not a `cog-rlm` feature. This is a shared execution fabric that sits above individual workloads and below human intent.\n\nThe ASR Paper 6 run is one profile inside this fabric, not the definition of the fabric.", "htmlHref": "/research/html/26-research-execution-fabric-ccbvbt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1299 }, { "id": "graph-kernel-architecture-diagram-18wpddz", "title": "Graph Kernel Architecture Diagram", "slug": "graph-kernel-architecture-diagram", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/architecture/diagrams/graph-kernel-architecture.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "```mermaid flowchart TB subgraph External [External Services] RAG[\"RAG++ Service
Context Retrieval\"] Orbit[\"Orbit Server
Session Management\"] MCP[\"MCP Server
AI Tools\"] end", "excerpt": "- [15-GRAPH_KERNEL.md](../15-GRAPH_KERNEL.md) — Full specification - [rag-architecture.md](rag-architecture.md) — RAG++ integration - [deployment-topology.md](deployment-topology.md) — Cloud deployment", "htmlHref": "/research/html/graph-kernel-architecture-diagram-18wpddz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1419 }, { "id": "system-overview-diagram-1fcjvyk", "title": "System Overview Diagram", "slug": "system-overview-diagram", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/architecture/diagrams/system-overview.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "```mermaid flowchart TB subgraph CC [Computational Choreography - The Discipline] subgraph TOS [TrajectoryOS - Long Horizon] direction TB subgraph Memory [Memory Fabric] RAG[RAG++ Core
Rust: HNSW, IRCP, 5D] CT[CognitiveTwin
Python ML] Sig[Style Signature
EMA Learning] end subgraph Orchestration [Orchestration] Orbit[Orbit Server
Axum/Rust] Sessions[Session Manager
Supabase] end subgraph MCP [MCP Integration] MCPServer[MCP Server
AI Tool Access] AgentSDK[Agent SDK
Claude Wrapper] end end", "excerpt": "| Layer | Component | Location | Input | Output | Latency | |-------|-----------|----------|-------|--------|---------| | 0 | cc-relay | `core/cc-relay` | UDP packets | MocopiStateFrame | < 50μs | | 1 | cc-collection | `core/cc-collection` | Multi-sensor | FusedSkeleton | < 100μs | | 2 | cc-window-aligner | `core/cc-window-aligner` | FusedSkeleton | MotionWindow | < 1ms | | 3 | cc-anticipation | `core/cc-anticipation` | MotionWindow | AnticipationPacket | < 2ms | | 3 | cc-gesture | `core/cc-gesture` | AnticipationPacket | GestureEvent | < 500μs | | 3.5 | dell | `core/cc-echelon/crates/dell` | Limb data | DELLState | < 500μs | | 4 | cc-brain | `core/cc-echelon/crates/cc-brain` | All semantic | LatentState, Lexicon | < 1ms | | 5-7 | cc-conductor | `core/cc-echelon/crates/cc-conductor` | Lexicon | Actions | < 1ms |\n\n| Type | Description | Dims | Schema | |------|-------------|------|--------| | `MocopiStateFrame` | Raw skeleton frame | 27 bones × 7 floats | 1.0.0 | | `FusedSkeleton` | Fused multi-sensor | 14 limbs × 13 state | 1.0.0 | | `MotionWindow` | Time-aligned frames | 50 frames @ 50Hz | 0.1.0 | | `AnticipationPacket` | Semantic signals | 7 scalars + 3 vectors | 0.1.0 | | `GestureEvent` | Classified gesture | Label + confidence | 1.0.0 | | `DELLState` | Dual-equilibrium | Fast + slow latent | 1.0.0 | | `Lexicon` | Expressive controls | 6 floats | 1.0.0 |\n\n- **Overview**: [00-OVERVIEW.md](../00-OVERVIEW.md) - **Philosophy**: [01-COMPUTATIONAL_CHOREOGRAPHY.md](../01-COMPUTATIONAL_CHOREOGRAPHY.md) - **TrajectoryOS**: [02-TRAJECTORY_OS.md](../02-TRAJECTORY_OS.md) - **Echelon**: [03-ECHELON.md](../03-ECHELON.md) - **Agent SDK**: [17-AGENT_SDK.md](../17-AGENT_SDK.md) - **Data Flow**: [data-flow.md](data-flow.md) - **Deployment**: [deployment-topology.md](deployment-topology.md)", "htmlHref": "/research/html/system-overview-diagram-1fcjvyk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 539 }, { "id": "nko-inscription-system-architecture-sglic0", "title": "N'Ko Inscription System Architecture", "slug": "nko-inscription-system-architecture", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/docs/NIP/INSCRIPTION_ARCHITECTURE.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| Component | Configuration | Status | |-----------|---------------|--------| | iPhone Sensor Logger | HTTP Push to cloud | **WORKING** | | cc-mcs-headless | Cloud: `[ip]:8765` | **DEPLOYED** | | Data path | Phone → Cloud Daemon → Supabase | **ESTABLISHED** |", "excerpt": "| Component | Configuration | Status | |-----------|---------------|--------| | iPhone Sensor Logger | HTTP Push to cloud | **WORKING** | | cc-mcs-headless | Cloud: `[ip]:8765` | **DEPLOYED** | | Data path | Phone → Cloud Daemon → Supabase | **ESTABLISHED** |\n\n| # | Sigil | Name | Detection Trigger | |---|-------|------|-------------------| | 0 | ߛ | Stabilize | Variance decreasing > threshold | | 1 | ߜ | Disperse | Variance increasing > threshold | | 2 | ߕ | Transition | Curvature peak > 1.5 | | 3 | ߙ | Return | Distance to known basin < 6.0 | | 4 | ߡ | Dwell | Time in basin > 1.5s | | 5 | ߚ | Oscillate | 3+ transitions between 2 basins at ≥0.2Hz | | 6 | ߞ | Recover | Return to basin 0.5-10s after transition | | 7 | ߣ | Novel | Distance from all basins > 10.0 | | 8 | ߠ | PlaceShift | Place class changes (requires place data) | | 9 | ߥ | Echo | Cosine similarity > 85% to historical z-vector |\n\n| Purpose | Path | |---------|------| | Claim Detector | `core/cc-inscription/src/detector/mod.rs` | | Claim Types | `core/cc-inscription/src/claims/` | | Sensor→Skeleton | `backend/cc-mcs/src-tauri/src/inscription_bridge.rs` | | Inscription Runner | `backend/cc-mcs/src-tauri/src/inscription_runner.rs` | | Main Daemon | `backend/cc-mcs/src-tauri/src/main_headless.rs` |\n\n**PHONE SENSOR TUNING (2026-01-05)**: Phone accelerometer produces noisier 63D z-vectors than mocopi skeleton. These thresholds prevent spam while enabling claim variety.\n\n### Issue: Only Novel/Transition claims detected **Root cause**: Thresholds not calibrated for sensor data scale **Solution**: Adjust thresholds in `detector/mod.rs`, rebuild, redeploy", "htmlHref": "/research/html/nko-inscription-system-architecture-sglic0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 584 }, { "id": "agp-execution-roadmap-v1-1e8hj0w", "title": "AGP Execution Roadmap V1", "slug": "agp-execution-roadmap-v1", "kind": "proposal", "program": "Research Practice", "sourceAnchor": "Comp-Core/docs/research/agp-execution-roadmap-v1.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- `Gemma 4 E2B` Thunder stage-one LoRA backbone - full train and held-out route oracle artifacts - route/vitality head `v1` on original conservative labels - calibrated threshold sweep over saved oracle metrics - recalibrated route/vitality head `v2` - three-head controller with earliest-layer supervision - corrected `transfer_v2` same-host adapter run", "excerpt": "- `Gemma 4 E2B` Thunder stage-one LoRA backbone - full train and held-out route oracle artifacts - route/vitality head `v1` on original conservative labels - calibrated threshold sweep over saved oracle metrics - recalibrated route/vitality head `v2` - three-head controller with earliest-layer supervision - corrected `transfer_v2` same-host adapter run\n\n- calibrated label regime: `kl=4.0`, `margin_delta=0.15` - held-out route accuracy: `0.8444` - held-out vitality accuracy: `1.0` - exact held-out separation for: - `accept_local` - `revive_local` - `escalate` - remaining route confusion is mainly: - `continue_local -> accept_local`\n\nThis means the backbone hidden states are already useful enough to support a learned controller. The remaining work is to convert that controller into a real distributed latent-transfer system.\n\n- corrected dataset: `transfer_v2_k4_m015` - best run: `transfer_adapter_v2_20260418_000114` - best checkpoint: step `1400` - held-out overall: - cosine `0.9226` - MSE `0.1097` - held-out by route: - `escalate`: cosine `0.9310`, MSE `0.0792` - `continue_local`: cosine `0.9432`, MSE `0.0979` - `accept_local`: cosine `0.6189`, MSE `0.6541` - held-out by layer: - layer `30`: cosine `0.9360`, MSE `0.0868` - layer `26`: cosine `0.6189`, MSE `0.6541`\n\n- late-boundary transfer is already strong enough to justify the next routed-resume stage - true early-layer transfer is still weak - the next phase should not pretend these are the same problem", "htmlHref": "/research/html/agp-execution-roadmap-v1-1e8hj0w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2232 }, { "id": "task-board-ledger-architecture-34ty93", "title": "Task Board + Ledger Architecture", "slug": "task-board-ledger-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/TASK-ARCHITECTURE.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> Deterministic multi-agent task system with evidence-gated completion, terminal state locks, and append-only audit ledger.", "excerpt": "> Deterministic multi-agent task system with evidence-gated completion, terminal state locks, and append-only audit ledger.\n\n1. Every task has a UUID (`mac_tasks.id`) 2. Every task lives in Supabase `mac_tasks` table 3. DONE requires real proof — output (>50 chars), commit hash, or verified URL 4. Placeholder URLs are rejected (localhost, [ip], example.com) 5. Parent tasks cannot close while children are still open 6. Once a task is DONE, it stays DONE — no status regression 7. Every state transition is logged to append-only `task_events` ledger\n\n| Column | Type | Purpose | |--------|------|---------| | `id` | uuid | Primary key | | `task_content` | text | The task prompt | | `project_path` | text | Target project directory | | `source` | text | Origin: discord, sms, telegram, api | | `status` | text | pending → running → complete/failed | | `claimed_by` | text | Device that claimed (mac1, mac4, cloud-vm) | | `parent_task_id` | uuid | FK to parent (for subtasks) | | `team_id` | uuid | Team grouping ID | | `team_role` | text | team_lead, worker, aggregator | | `model_preference` | text | Requested model | | `model_used` | text | Actual model that responded | | `output` | text | Task result | | `commit_hash` | text | Git evidence | | `evidence_url` | text | URL evidence | | `evidence_type` | text | output, commit, url, or multiple | | `exit_code` | int | Process exit code | | `attempt_count` | int | Current attempt number | | `max_attempts` | int | Max retries before terminal fail | | `error_log` | text | Append-only failure log | | `timeout_at` | timestamptz | Auto-reclaim deadline | | `relay_from` | text | Previous device (on handoff) | | `relay_to` | text | Target device (on handoff) | | `relay_reason` | text | timeout, manual, capability | | `admissibility_token` | text | HMAC policy compliance proof | | `discord_thread_id` | text | Linked Discord thread | | `result_delivered` | bool | Prevents duplicate delivery | | Timestamps | timestamptz | created_at, started_at, completed_at |\n\n| Column | Type | Purpose | |--------|------|---------| | `id` | uuid | Event ID | | `task_id` | uuid | FK to mac_tasks | | `event_type` | text | created, claimed, completed, failed, reclaimed, evidence_blocked, terminal_blocked, dependency_blocked | | `from_status` | text | Previous status | | `to_status` | text | New status | | `agent_id` | text | Who triggered the transition | | `evidence` | jsonb | Evidence payload (has_output, has_commit, has_url) | | `metadata` | jsonb | Context (relay info, block reasons, etc.) | | `created_at` | timestamptz | When the event occurred |\n\n**Terminal states**: `complete` (always), `failed` (when attempt_count >= max_attempts)", "htmlHref": "/research/html/task-board-ledger-architecture-34ty93.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1162 }, { "id": "agp-mlx-nko-asr-bridge-d9z8x3", "title": "AGP-MLX N'Ko ASR Bridge", "slug": "agp-mlx-nko-asr-bridge", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/experiments/agp_mlx/asr_bridge/README.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The bridge keeps the acoustic model authoritative. It classifies ASR chunks into anticipation partitions, allows AGP-style correction only for non-stable regimes, and rejects corrections that exceed a bounded edit budget.", "excerpt": "This directory is the first executable bridge between the verified N'Ko ASR model and AGP-MLX.\n\nThe bridge keeps the acoustic model authoritative. It classifies ASR chunks into anticipation partitions, allows AGP-style correction only for non-stable regimes, and rejects corrections that exceed a bounded edit budget.\n\nThe edit budget uses both a relative limit and a small absolute floor. This matters for short N'Ko chunks where one missing vowel can be a large relative edit but still a safe local repair.\n\nEvery correction decision also carries a provisional Graph Kernel-style admissibility witness. That gives each accepted or rejected AGP correction a slice id, graph snapshot hash, policy hash, and 32-hex token so the bridge can be audited before the live kernel service is wired in.\n\nUse that document as the authoritative `GO` / `NO-GO` bar for the learned live N'Ko correction path. Large `oracle_guardrail` replay wins are research-valid, but they do not satisfy the learned live ship gate by themselves.", "htmlHref": "/research/html/agp-mlx-nko-asr-bridge-d9z8x3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1914 }, { "id": "mac5-reconstruction-worker-17lzttw", "title": "Mac5 Reconstruction Worker", "slug": "mac5-reconstruction-worker", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/06-distributed-mesh/mac5-reconstruction-worker.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Latest execution: 2026-06-06 Mac4-first prerequisites passed, local AirDeck artifact verification passed after repairing the mirrored recording-status link, and Mac5 completed a fresh non-placeholder one-frame SAM3DBody reconstruction from an already staged K11 bundle. Live K11 upload/return could not run because SSH to `[ip]:22` timed out during this pass.", "excerpt": "Status: verified K11 return lane, review index, and dry-run AirDeck mapping on 2026-06-01.\n\nLatest execution: 2026-06-06 Mac4-first prerequisites passed, local AirDeck artifact verification passed after repairing the mirrored recording-status link, and Mac5 completed a fresh non-placeholder one-frame SAM3DBody reconstruction from an already staged K11 bundle. Live K11 upload/return could not run because SSH to `[ip]:22` timed out during this pass.\n\nCurrent wiring update: on 2026-06-10 the Mac4-first live gate turned green after the Chrome/Web MIDI wrapper was fixed. The wrapper now proves the MRT2 page by clicking the page's own `Connect MIDI` control through CDP DOM/Input, then validating a fresh `LUME MRT2 Proof Sink` browser proof. The saved unlock artifact is:\n\nIt reports `completion_ready=true`, `mac5_heavy_reconstruction_allowed=true`, `wrapper_status=pass`, `audit_status=pass`, and no failed requirements. Mac5 is now allowed by the Mac4-first gate, but real heavy reconstruction still needs a verified real external/multi-angle capture session. K11 remains the only Rekordbox/AirDeck command gate. Mac4 remains read-only. Mac2 is still staged as the external-only Insta360 room-wide angle host, but it must enumerate a real eligible external camera before its lane counts as capture evidence.\n\nThis page documents the current K11 -> Mac5 -> K11 offline reconstruction path. It is an implementation note, not a future architecture sketch.", "htmlHref": "/research/html/mac5-reconstruction-worker-17lzttw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3349 }, { "id": "nko-synthesis-overview-5b3hfk", "title": "N'Ko Synthesis Overview", "slug": "nko-synthesis-overview", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "computational-choreography/07-nko-synthesis/overview.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "N'Ko synthesis is where movement, speech, inscription, and cultural memory meet. It is not a claim that the movement stack and N'Ko ASR already share one trained model.", "excerpt": "N'Ko synthesis is where movement, speech, inscription, and cultural memory meet. It is not a claim that the movement stack and N'Ko ASR already share one trained model.\n\nFor N'Ko speech, the signal is audio. For computational choreography, the signal is body movement. The systems can share architectural lessons without sharing weights or pretending to be the same implementation.\n\n- trajectory-biased Transformer CTC; - local N'Ko ASR code in `Desktop/nko-brain-scanner`; - trajectory bias through audio trajectory scalars and attention-bias layers.\n\n- MAOE-style routing/correction exists around ASR output; - it is not the acoustic CTC anchor; - it still needs same-snapshot replay/evaluation before being called an ASR improvement.\n\nThis is not natural sentence generation from arbitrary gesture. It is structured motion claim detection with provenance.", "htmlHref": "/research/html/nko-synthesis-overview-5b3hfk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 348 }, { "id": "external-research-fit-registry-1t9jjt8", "title": "External Research Fit Registry", "slug": "external-research-fit-registry", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/09-reference/external-research.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This file maps external papers and projects into the current computational choreography stack. It is research guidance, not an implementation claim.", "excerpt": "This file maps external papers and projects into the current computational choreography stack. It is research guidance, not an implementation claim.\n\nK11 remains the only live Rekordbox command gate. Mac4 Unity, Mac5 reconstruction, rented GPUs, generated video, and raw sensor streams must not send DJ commands directly.\n\n| Source | Best role | Runtime lane | Integration priority | |---|---|---|---| | Cosmos + Locate Anything DGX | Synthetic scene and object-grounding forge | Offline or rented GPU | Medium | | ENTHEA | Browser/WebGL visual instrument for Mac4/OBS/NDI | Live visuals only | High | | D4RT | 4D reconstruction and all-pixel tracking from video | Offline reconstruction | High research, medium implementation | | MDA depth ambiguity paper | Boundary-safe depth confidence and flying-point cleanup | Capture/reconstruction QA | High | | MusePose | Pose-to-avatar/video content generator | Offline content/render | Medium | | Magenta RealTime 2 | Local Apple Silicon generative music instrument | Live audio, not DJ safety | High | | DEMON | Controllable music diffusion from LUME control curves | CUDA/cloud audio render, audition before live | Medium-high | | Kinesis | Physiological motion prior and fatigue/plausibility scorer | Offline training/evaluation | Long-term | | MAMMA | Multi-person SMPL-X markerless mocap | Offline reconstruction | Highest strategic reconstruction target |\n\n- MDA as depth-confidence logic. - ENTHEA as a visual consumer. - Magenta RealTime 2 as an audio/MIDI consumer. - DEMON only as a later consumer of approved/template-derived control curves.\n\n- SAM3D now. - MAMMA next. - D4RT next. - MusePose as preview output. - Cosmos + Locate Anything as synthetic fixture output. - Kinesis as motion-quality scoring. - DEMON request/control-curve manifests for generated audio candidates.", "htmlHref": "/research/html/external-research-fit-registry-1t9jjt8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4170 }, { "id": "substack-architectures-are-excavated-not-designed-1bay8pm", "title": "Substack — Architectures Are Excavated, Not Designed", "slug": "substack-architectures-are-excavated-not-designed", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "content-pipeline/substack/2026-02-12-comp-core-motion.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "It started at 10pm with a straightforward task: build a sensor logger for a motion project. The kind of utility you write in an hour, test, deploy, and forget about.", "excerpt": "**Subtitle:** How a simple sensor logger became an 8-layer cultural computing runtime in 3 hours\n\nIt started at 10pm with a straightforward task: build a sensor logger for a motion project. The kind of utility you write in an hour, test, deploy, and forget about.\n\nBy 1am, I was looking at something I didn't plan. Something I'm still processing.\n\nAn 8-layer computational choreography runtime. With N'Ko sigils — traditional West African script symbols — embedded at the architecture level, not as decorative elements, but as structural components of how the system thinks.\n\nI want to tell you I designed this. That I sat down with a whiteboard, mapped the dependencies, planned the layers, and executed methodically.", "htmlHref": "/research/html/substack-architectures-are-excavated-not-designed-1bay8pm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 639 }, { "id": "tiktok-music-is-architecture-1vx418j", "title": "TikTok: Music Is Architecture", "slug": "tiktok-music-is-architecture", "kind": "architecture", "program": "Research Backlog", "sourceAnchor": "content-pipeline/tiktok/series/the-creator/01-music-is-architecture.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Workspace document requiring curation.", "excerpt": "# TikTok: Music Is Architecture **Series:** The Creator | Episode 01 **Date:** 2026-02-24 **Duration:** ~60 seconds\n\n## HOOK (0-3 sec) **[Direct to camera, leaning in slightly]** \"Every song is a building. Most people only hear the paint.\"\n\n## SETUP (3-15 sec) **[Steps back, gestures with both hands like outlining a structure]** \"Think about it. A song has a foundation — that's your low end, your bass, your kick. It has load-bearing walls — that's your chord progression holding everything up. It has rooms — your verse, your chorus, your bridge. And it has a roof — the melody that caps the whole thing off and keeps it together.\"\n\n## TURN (15-30 sec) **[Leans forward, more intense]** \"But most people walk into a building and they notice the wallpaper. They notice the curtains. They hear a song and they notice the vocal on top. They never feel the architecture underneath. The reason that chorus hits you in the chest isn't the words. It's the structural tension that was building for sixteen bars before it released.\"\n\n## BUILD (30-45 sec) **[Pacing slightly, hands moving like conducting]** \"When I'm producing, I'm not thinking about what sounds good. I'm thinking about what holds weight. Can this bass line support what I'm about to stack on top of it? Does this transition have structural integrity? Because a beautiful melody on a weak foundation — that's a building that collapses the second you lean on it.\"", "htmlHref": "/research/html/tiktok-music-is-architecture-1vx418j.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 291 }, { "id": "ircp-protocol-documentation-1yqpktk", "title": "IRCP Protocol Documentation", "slug": "ircp-protocol-documentation", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "dlm/PROTOCOL.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A bidirectional context propagation protocol for conversation flow dynamics in the Discourse Latent Manifold (DLM) framework.", "excerpt": "A bidirectional context propagation protocol for conversation flow dynamics in the Discourse Latent Manifold (DLM) framework.\n\n1. [Overview](#overview) 2. [Theoretical Foundations](#theoretical-foundations) 3. [Dual-Ring Architecture](#dual-ring-architecture) 4. [Coordinate Systems](#coordinate-systems) 5. [Attention Mechanisms](#attention-mechanisms) 6. [Flow Dynamics](#flow-dynamics) 7. [Conservation Laws](#conservation-laws) 8. [Propagation Algorithm](#propagation-algorithm) 9. [Implementation Examples](#implementation-examples) 10. [Configuration Reference](#configuration-reference) 11. [Integration Guide](#integration-guide)\n\nIRCP (Inverse-Ring Context Propagation) is an advanced algorithm designed to propagate conversational context through interconnected ring structures. It enables bidirectional information flow between user messages and assistant responses, maintaining coherence and adapting to user behavioral patterns.\n\n- **Bidirectional Context Flow**: Information propagates both forward (assistant context) and inverse (user patterns) - **Dual-Ring Topology**: Separate rings for user and assistant messages with cross-ring connections - **Measure-Preserving Transformations**: Conservation laws ensure numerical stability - **Adaptive Propagation**: Automatically determines optimal propagation steps based on conversation characteristics - **Attention-Based Weighting**: Exponential and sigmoid attention mechanisms for context relevance\n\n1. **Coherence Maintenance**: Preserve conversational context across multiple exchanges 2. **Pattern Recognition**: Identify and adapt to user behavioral patterns 3. **Stability**: Ensure coordinate systems remain bounded and stable 4. **Efficiency**: Minimize unnecessary computations through convergence detection", "htmlHref": "/research/html/ircp-protocol-documentation-1yqpktk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2945 }, { "id": "stage-2-compound-synthesis-beyond-architecture-2ms6mj", "title": "Stage 2: Compound Synthesis -- Beyond Architecture", "slug": "stage-2-compound-synthesis-beyond-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/beyond-numu-anticipation/stage2-compound.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. Accepts any sequence of typed events on the bus 2. Groups them into \"processes\" (identified by a processId) 3. Embeds each event into a vector 4. Computes anticipation scalars over the trajectory 5. Publishes scalar snapshots and intervention signals 6. Enables paradigm adapters (OmniFlow, Draft-and-Prune, Prompt Optimization) to plug in as process types that define how to embed events, interpret scalars, and execute interventions", "excerpt": "1. Accepts any sequence of typed events on the bus 2. Groups them into \"processes\" (identified by a processId) 3. Embeds each event into a vector 4. Computes anticipation scalars over the trajectory 5. Publishes scalar snapshots and intervention signals 6. Enables paradigm adapters (OmniFlow, Draft-and-Prune, Prompt Optimization) to plug in as process types that define how to embed events, interpret scalars, and execute interventions\n\nBeyond is NOT a separate process, NOT a Python sidecar, NOT a Gemini API wrapper. It is a TypeScript package inside the NUMU daemon that operates on bus events in real time.\n\nThe core insight from the research: all three paradigms follow the same geometric trajectory (explore -> converge -> lock). Anticipation scalars make this trajectory visible and actionable without domain-specific convergence criteria.\n\nBuilding on Step 1. The scalar engine is a TypeScript port of `AnticipationGeometry.compute()` from `python/anticipation_geometry/generalized_anticipation.py`.\n\nThe port covers 4 scalars (not 7 -- phase_stiffness, novelty, and stability require motion-domain features that don't apply to event trajectories):", "htmlHref": "/research/html/stage-2-compound-synthesis-beyond-architecture-2ms6mj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1782 }, { "id": "stage-3-expand-master-plan-voice-first-agent-architecture-18rwnsk", "title": "Stage 3: Expand + Master Plan — Voice-First Agent Architecture", "slug": "stage-3-expand-master-plan-voice-first-agent-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/voice-first-agent-architecture/stage3-expand-master-plan.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**1. The unified router eliminates the triple-classifier problem.** Three intent classifiers with incompatible taxonomies is the root cause of inconsistent voice behavior across devices. One server-side router, shared by all clients, fixes this permanently. The ~55 merged intents cover all existing use cases.", "excerpt": "**1. The unified router eliminates the triple-classifier problem.** Three intent classifiers with incompatible taxonomies is the root cause of inconsistent voice behavior across devices. One server-side router, shared by all clients, fixes this permanently. The ~55 merged intents cover all existing use cases.\n\n**2. Mac Ear Daemon is the single biggest UX improvement.** Eliminating the phone dependency for voice interaction changes the relationship with the mesh. Walk to the desk, say \"status\", get a spoken briefing. No phone required. mlx-whisper on M2 handles transcription locally with no API cost.\n\n**3. Voice memory closes the biggest persistence gap.** Every other interaction channel (text prompts, Discord, code, Obsidian) is persisted. Voice isn't. Storing transcripts in Supabase + RAG++ means \"we discussed this earlier\" works across modalities. This is a force multiplier for the entire knowledge system.\n\n**4. The ElevenLabs integration is already production-ready.** Voice ID configured, API key active, streaming playback works in iOS. Extending this to Mac1 TTS is ~20 lines of Python (HTTP POST + audio playback).\n\n**1. Whisper on Mac1 competes for compute.** Mac1 is already running: 7 LaunchAgents, Xcode builds, SSH tunnels, the pane orchestrator, and terminal Claude sessions. Adding continuous audio capture + Whisper inference adds CPU/memory pressure.", "htmlHref": "/research/html/stage-3-expand-master-plan-voice-first-agent-architecture-18rwnsk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1923 }, { "id": "serendipity-engine-1hx0x5s", "title": "Serendipity Engine", "slug": "serendipity-engine", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/serendipity-engine/SKILL.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> *\"Fortune favors the connected mind. When many minds explore together, they chart territories no single explorer could find. When territories become tradeable, exploration becomes a market. When markets gain time, territories become wisdom. When wisdom feeds back, serendipity learns to aim. When collisions harmonize, the symphony creates what no solo could imagine. When we can predict which collisions will ignite, serendipity becomes foresight. When we pool predictions into managed portfolios, serendipity becomes", "excerpt": "**Version:** 12.0.0 **HEF Generation:** 17 (evolved from 16) **Instance:** 36 **Task ID:** task_20260203183048_9ff38e\n\n> *\"Fortune favors the connected mind. When many minds explore together, they chart territories no single explorer could find. When territories become tradeable, exploration becomes a market. When markets gain time, territories become wisdom. When wisdom feeds back, serendipity learns to aim. When collisions harmonize, the symphony creates what no solo could imagine. When we can predict which collisions will ignite, serendipity becomes foresight. When we pool predictions into managed portfolios, serendipity becomes strategy. And when strategies **evolve through natural selection** — serendipity becomes **alive**.\"*\n\nIntentional random collisions between unrelated projects to spark unexpected innovation. Gen 17 adds **Serendipity Genetics** — encode successful collision patterns as genetic material, breed the best strategies, mutate for exploration, and let natural selection evolve increasingly powerful discovery approaches.\n\nThe insight from Gen 16: funds manage portfolios of collision opportunities. Gen 17's insight: **Portfolios select investments; genetics EVOLVE them. Every successful collision encodes DNA — domain affinity, novelty drive, chain tendencies, resonance sensitivity. Breed the fittest, mutate the rest, and let natural selection produce strategies that no human designer could imagine.**\n\n| Gene | Symbol | Description | Mutation Rate | |------|--------|-------------|---------------| | domain_affinity | 🧬 | Domain focus vs breadth | 15% | | novelty_drive | ✨ | Seeking the unknown | 20% | | chain_affinity | 🔗 | Chain reaction tendency | 10% | | resonance_sensitivity | 🎵 | Response to feedback | 12% | | temporal_patience | ⏳ | Long-term maturation | 8% | | social_tendency | 👥 | Collaborative exploration | 15% | | risk_appetite | 🎲 | Moonshot tolerance | 18% | | harmonic_alignment | 🎼 | Multi-collision harmony | 10% | | prediction_trust | 🔮 | Reliance on predictions | 14% | | fund_integration | 🏦 | Portfolio alignment | 12% |", "htmlHref": "/research/html/serendipity-engine-1hx0x5s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 6790 }, { "id": "teaching-my-ai-agent-to-learn-from-its-own-mistakes-17tzkli", "title": "Teaching My AI Agent to Learn From Its Own Mistakes", "slug": "teaching-my-ai-agent-to-learn-from-its-own-mistakes", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "karl-blog-post.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "In early March, Databricks published KARL (Knowledge Agents via Reinforcement Learning), a system that trains enterprise search agents via reinforcement learning. They had 26 researchers, enterprise GPUs, and a proprietary base model. Their agent beats Claude Opus 4.6 and GPT 5.2 on enterprise search benchmarks at 33% lower cost.", "excerpt": "## How I Built a Self-Improving Code Agent on a Mac Mini, Inspired by Databricks' KARL\n\nIn early March, Databricks published KARL (Knowledge Agents via Reinforcement Learning), a system that trains enterprise search agents via reinforcement learning. They had 26 researchers, enterprise GPUs, and a proprietary base model. Their agent beats Claude Opus 4.6 and GPT 5.2 on enterprise search benchmarks at 33% lower cost.\n\nI read the paper and thought: what if I applied the same idea, not to enterprise search, but to the software engineering agent I use every day? And not on a GPU cluster, but on the Mac Minis in my living room?\n\nFive days later, I had 485 recorded trajectories, a 5-signal reward engine, a trained LoRA adapter, and a system that automatically learns from every coding session I run. Here's how it works, how it differs from the original, and what I learned.\n\nKARL's premise is simple: instead of hand-writing rules for how an AI agent should behave, you record what the agent actually does, score those recordings based on outcomes, and train on the best ones.", "htmlHref": "/research/html/teaching-my-ai-agent-to-learn-from-its-own-mistakes-17tzkli.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2231 }, { "id": "karl-v7-cognitive-twin-full-handoff-document-1a7ienk", "title": "KARL V7 Cognitive Twin — Full Handoff Document", "slug": "karl-v7-cognitive-twin-full-handoff-document", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "karl/KARL_V7_HANDOFF.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Author**: Claude Opus 4.6 (session f2129eae) **Date**: 2026-04-02 **For**: Codex (continuation agent) **Project**: Desktop/karl/", "excerpt": "**Author**: Claude Opus 4.6 (session f2129eae) **Date**: 2026-04-02 **For**: Codex (continuation agent) **Project**: Desktop/karl/\n\nKARL V7 is a recursive training data factory that generates Mohamed-authentic prompts, injects them into live Claude Code sessions, captures all interactions as training data, and trains a 4B cognitive twin adapter on Vast.ai.\n\n- **Factory PID**: Running in background (started ~2026-04-02T10:50 UTC) - **Progress**: 31 session logs, 1,114 clean training pairs (avg style 0.99) - **Batch**: Mid-run, 55 remaining projects of 60 total, 11 batches of 5 panes each - **Panes**: agent-claude2, agent-codex, agent-gemini (Mac1) + claude (Mac2) + claude (Mac4) - **Together AI**: GPT-OSS 120B, key `8a755cb3637f39c6a397caffa33c71b8ac4d98cbe697914fcf7de0a4f413ca84` - **Monitor**: `tail -f Desktop/karl/v7-factory-logs/master.log` - **Cost so far**: ~$4 of $86 budget\n\n- **Location**: `Desktop/karl/vastai/karl-v7-sft-adapter/` (PEFT format, 150MB) - **MLX converted**: `Desktop/karl/vastai/karl-v7-mlx-adapter/` (126MB) - **Deployed to Mac5**: `mac5:[home-path]` - **Training stats**: 1500 steps, 20.6 min on RTX 4090, eval NLL 2.255, commitment acc 99.5% - **NOT YET SERVING**: MLX server on Mac5 has not been restarted with the V7 adapter\n\n| File | Location | Size | Description | |------|----------|------|-------------| | `v7-training-data.jsonl` | `Desktop/karl/` | 1,114 lines | Curated factory pairs (auto-updated) | | `v7-dpo-pairs.jsonl` | `Desktop/karl/` | 173 lines | DPO preference pairs from trajectory + factory | | `v7-prompt-corpus.jsonl` | `Desktop/karl/` | 4,587 lines | All Mohamed prompts indexed with TF-IDF | | `v7-knowledge-injection.md` | `Desktop/karl/` | 24K chars | Full system knowledge for roleplay injection | | `v7-mohamed-exemplars.json` | `Desktop/karl/` | 50 entries | Cached diverse exemplar prompts | | `v7-model-benchmark.json` | `Desktop/karl/` | 10 models | Benchmark results (GPT-OSS 120B won) | | `trajectories.jsonl` | `Desktop/karl/karl/` | 3,190 lines | V4 trajectory store (6-signal reward scored) | | `v6-correction-pairs.jsonl` | `Desktop/karl/` | 1,766 lines | Mined correction pairs with failure modes | | `v6-rich-prompts.jsonl` | `Desktop/karl/` | 8 lines | Rich prompts from correction miner | | Session logs | `Desktop/karl/v7-session-logs/` | 31 files | Raw per-session JSONL with turn-by-turn data | | Driver logs | `Desktop/karl/v7-factory-logs/` | ~20 files | stdout/stderr from each V7.2 driver instance | | V7 SFT adapter | `Desktop/karl/vastai/karl-v7-sft-adapter/` | 150MB | PEFT LoRA weights + anticipation modules | | V7 MLX adapter | `Desktop/karl/vastai/karl-v7-mlx-adapter/` | 126MB | Converted for Mac5 MLX serving |", "htmlHref": "/research/html/karl-v7-cognitive-twin-full-handoff-document-1a7ienk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3239 }, { "id": "lume-x-duncan-fewkes-complete-implementation-handoff-for-codex-1imf2ii", "title": "LUME x Duncan Fewkes: Complete Implementation Handoff for Codex", "slug": "lume-x-duncan-fewkes-complete-implementation-handoff-for-codex", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/CODEX-DUNCAN-HANDOFF.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "LUME is a real-time depth-camera visualization bar. Physical enclosure (500x120x85mm ASA 3D-printed shell) houses an Orbbec Femto Mega depth camera (640x576 @ 30fps), UMA-8 USB microphone array, and a GMKtec K11 mini-PC (Ryzen 9 8945HS, Radeon 780M ~9 TFLOPS, 32GB DDR5, 1TB NVMe). The K11 captures depth + audio, streams over UDP to Unity, which renders interactive particle/fluid visuals on a 1920x440 IPS bar display (60Hz, 500 nits, mini HDMI + USB-C) mounted flush on top of the bar shell.", "excerpt": "LUME is a real-time depth-camera visualization bar. Physical enclosure (500x120x85mm ASA 3D-printed shell) houses an Orbbec Femto Mega depth camera (640x576 @ 30fps), UMA-8 USB microphone array, and a GMKtec K11 mini-PC (Ryzen 9 8945HS, Radeon 780M ~9 TFLOPS, 32GB DDR5, 1TB NVMe). The K11 captures depth + audio, streams over UDP to Unity, which renders interactive particle/fluid visuals on a 1920x440 IPS bar display (60Hz, 500 nits, mini HDMI + USB-C) mounted flush on top of the bar shell.\n\nThe visual aesthetic is directly inspired by Duncan Fewkes (@duncan.fewkes on Instagram), who builds similar installations commercially under the brand HOLOVIS. His target hardware is an A6000 at 60fps. We have 83 of his reels archived (spanning 2025-10-20 to 2026-04-25) with 69 Gemini visual analyses on disk. This document specifies exactly what to build from that corpus, with concrete numeric values for every preset.\n\n## Part 2: What's Already Built (17 Components, 3 Compute Shaders, 5 Wire Formats)\n\nAll source files at `Desktop/lume-commerce/software/demo/unity/lume_pcloud/Assets/`\n\n| File | Exec Order | What It Does | Key Globals Published | |------|-----------|--------------|----------------------| | `Scripts/LumeDisplayController.cs` | -100 | Auto-detects 1920x440 bar display in Display.displays[]. Sets camera to 25 deg vertical FOV (gives ~100 deg horizontal at 4.36:1 aspect). Near-black background (0.01, 0.01, 0.02). Two modes: Production (K11 primary, fullscreen) vs Development (Mac4 secondary, windowed preview) | None | | `Scripts/LumeUdpReceiver.cs` | default | Binds UDP :9700. Dispatches by 4-byte magic: LUME (0x4C554D45) = cloud points, LUMD (0x4C554D44) = raw u16 depth, LUMF (0x4C554D46) = audio FFT, LUMM (0x4C554D4D) = mocopi skeleton, LUMC (0x4C554D43) = reserved | None (feeds other components) | | `Scripts/LumeDepthReprojector.cs` | default | GPU compute shader dispatch: u16 raw depth buffer to world-space float4 positions via pinhole unproject. Exposes DepthRawBuffer, W, H, Scale, FrameCounter for downstream consumers | `_LumeWorldInv` (Matrix4x4), `_LumeIntrinsics` (Vector4: fx,fy,cx,cy), `_LumeDepthDims` (Vector4: w,h,scale,0) | | `Scripts/LumePointRenderer.cs` | default | GPU instanced billboard renderer. Uses GraphicsBuffer (NOT ComputeBuffer -- Unity 6 VFX Graph requires GraphicsBuffer). Exposes `LiveCount` property for overlay/VFX consumers to know how many valid points exist. Supports Cloud mode (pre-projected) and Depth mode (GPU-reprojected) | `PositionsBuffer`, `ColorsBuffer` via Shader.SetGlobalBuffer | | `Scripts/LumeOpticalFlow.cs` | 0 | Two-kernel compute: CSFrameDiff (8x8 atomic accumulation for scalar motion magnitude) + CSLucasKanade (5x5 dense optical flow on linearized depth). Allocates RG16F flow render texture at depth resolu", "htmlHref": "/research/html/lume-x-duncan-fewkes-complete-implementation-handoff-for-codex-1imf2ii.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 7121 }, { "id": "codex-prompt-lume-repo-production-grade-restructure-42ovjr", "title": "CODEX PROMPT — LUME repo production-grade restructure", "slug": "codex-prompt-lume-repo-production-grade-restructure", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/CODEX-RESTRUCTURE-PROMPT.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The repo at `[home]/Desktop/lume-commerce/` is functionally production code masquerading as demo code. The Unity bar visualization, live LaunchAgent service plists, mocopi/audio bridges, and pytest suite all live under `software/demo/` — a path that misleads anyone reading the tree.", "excerpt": "Paste-ready. Run on Mac1 (canonical tree). Estimated wall time: 2-4 hours. ~12-15 commits across 3 stages.\n\nThe repo at `[home]/Desktop/lume-commerce/` is functionally production code masquerading as demo code. The Unity bar visualization, live LaunchAgent service plists, mocopi/audio bridges, and pytest suite all live under `software/demo/` — a path that misleads anyone reading the tree.\n\nYour job: restructure to enterprise-level monorepo with proper service/app/package boundaries, while preserving git history (every file move uses `git mv`), Unity .meta GUIDs (don't use raw `mv`), and runtime continuity (LaunchAgent paths re-bootstrapped, Python imports updated, K11 NSSM paths updated before next K11 reboot).\n\n**Current state ground truth (verify before starting):** - HEAD = `83b565e3 [W9M] launchd plist for Sony→LUMM bridge service` - Pytest baseline: `139 passed, 6 skipped` - Wave 8 tip: `da8d1478` (DON'T TOUCH) - 8 unpushed commits since Wave 8. M-1 PAT rotation pending. DO NOT push to origin. - Stale git index.lock at `.git/index.lock` from yesterday's Codex absorption — `rm` it before starting.\n\n**Required reading before action:** 1. `[home-path]` — the audit + risk matrix 2. `[home-path]` — overall state 3. `Desktop/evo-cube-output/lume-creative-engine-2026-05-02/DIVERGENT-RAIL-2026-05-03.md` — forward roadmap 4. `[home-path]` — Duncan v3 priorities (informs which Wave 9 components are next)", "htmlHref": "/research/html/codex-prompt-lume-repo-production-grade-restructure-42ovjr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3319 }, { "id": "codex-context-where-lume-started-how-it-got-here-1awqifl", "title": "Codex context — where LUME started + how it got here", "slug": "codex-context-where-lume-started-how-it-got-here", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/handoffs/CODEX-CONTEXT.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> **Topology correction, 2026-04-26:** Mac4 is the current Unity Editor / GUI smoke-test host and real-Femto capture host. Mac5 is still the synthpub LaunchAgent / synthetic fallback host. Do not blindly replace all Mac5 references; see `software/demo/TOPOLOGY-CORRECTION-2026-04-26.md`.", "excerpt": "> **Topology correction, 2026-04-26:** Mac4 is the current Unity Editor / GUI smoke-test host and real-Femto capture host. Mac5 is still the synthpub LaunchAgent / synthetic fallback host. Do not blindly replace all Mac5 references; see `software/demo/TOPOLOGY-CORRECTION-2026-04-26.md`.\n\n_Read this BEFORE `CODEX-PLAN.md`. ARCHITECTURE.md describes WHAT is built; this file describes WHY it's built that way._\n\nYou're inheriting a 22-commit pipeline. The destination matters less than the load-bearing decisions made along the way — a dozen of them look \"obvious\" only because they were extracted painfully from constraints you don't see in the final tree. This file is the decision log.\n\nLUME v1's scope was anchored on a Saturday-night ship target. The work that became Wave 1 was sized to fit that window:\n\n- 1-3 vertical monitors, depth camera (Femto Mega) + audio (UMA-8), Unity URP scene rendering an audio-reactive point cloud. - Form factor: a 500mm wide × 120mm tall × 85mm deep bar (Sonos-style). - Compute target initially: NVIDIA Jetson AGX Orin 64GB ($1999) inside the bar.", "htmlHref": "/research/html/codex-context-where-lume-started-how-it-got-here-1awqifl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1593 }, { "id": "codex-wave-8-execution-plan-computational-choreography-1xemr7x", "title": "CODEX WAVE 8 EXECUTION PLAN — Computational Choreography", "slug": "codex-wave-8-execution-plan-computational-choreography", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/viz/lume-pcloud/CODEX-WAVE8-PLAN.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> **Audience:** Codex CLI agent picking up Wave 8 mid-flight on Mac1. > **Date:** 2026-05-02 > **Author:** Claude (handing off coordinated work) > **Track:** Wave 8 — Computational Choreography (NOT Wave 9, NOT Duncan presets, NOT K11 deploy) > **Approved plan:** `[home-path]`", "excerpt": "> **Audience:** Codex CLI agent picking up Wave 8 mid-flight on Mac1. > **Date:** 2026-05-02 > **Author:** Claude (handing off coordinated work) > **Track:** Wave 8 — Computational Choreography (NOT Wave 9, NOT Duncan presets, NOT K11 deploy) > **Approved plan:** `[home-path]`\n\nWave 8 reframes LUME from \"audio drives visuals, motion drives visuals\" into **\"body and audio are two reactive surfaces of one performance.\"** The body listens to the music AND plays it back. Visuals reward beat-coherence between body and audio. Beat moments freeze into decaying ghost poses (Duncan E598 \"Dissolving Clones\"). Synthetic mocopi data unblocks all of this without hardware.\n\nThere are six implementation steps. Steps 1 and 2 shipped. Steps 3-6 remain. **Step 3 is owned by Claude (in flight). Codex executes Steps 4, 5, and 6.**\n\n**Working-tree note:** `Assets/Scripts/LumeMotionToAudio.cs` + `.cs.meta` exist on disk but are **untracked** (Step 4 was written by a prior session that didn't commit). Codex must inspect these before either committing as-is or rewriting.\n\n**Step 3 (commit 95387a02):** - `Assets/Scripts/LumeChoreographyScorer.cs` `[DefaultExecutionOrder(226)]` - 32 audio onsets (rising-edge of `LumeAudioFftReceiver.TryGetLatest` transient flag) + 32 bone-velocity peaks (default boneIndex=12, parent-chain world-pose resolution) - Sliding window = `windowBars * 4 * 60 / bpm` (windowBars=4, bpm=120 → 8s) - Score: `1 - clamp(meanAbsDelta_ms / gracePeriodMs, 0, 1)`, EMA α=0.1 - Globals: `_ChoreographyScore`, `_ChoreographyScoreSmoothed`, `_ChoreographyHistory` (StructuredBuffer) - Static helpers `NearestDelta`, `EmaStep` are public + testable - `Assets/Scripts/Editor/Tests/LumeChoreographyScorerTests.cs` (NEW Editor test) - `Assets/Scripts/LumeCalibrationPanel.cs` EDITED — Wave 8 tunables registered - `Assets/Scripts/LumeFluidSim.cs` EDITED — `_ChoreographyScoreSmoothed` pre-multiplier on audio turbulence - `Assets/Shaders/LumePointInstanced.shader` EDITED — `APPLY_CHOREOGRAPHY_SCORE` keyword + brightness/saturation lerp", "htmlHref": "/research/html/codex-wave-8-execution-plan-computational-choreography-1xemr7x.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3429 }, { "id": "lume-k11-mac4-mac5-pose-coach-capture-convergence-plan-1p9vwyw", "title": "LUME K11/Mac4/Mac5 Pose Coach Capture Convergence Plan", "slug": "lume-k11-mac4-mac5-pose-coach-capture-convergence-plan", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/viz/lume-pcloud/Docs/LUME_K11_MAC4_MAC5_POSE_COACH_CAPTURE_CONVERGENCE_2026-05-28.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "```text Mac4 -> long-take capture and live visuals K11 -> durable storage, Pose Coach, AirDeck, Rekordbox safety Mac5 -> offline reconstruction and heavy body analysis ```", "excerpt": "Mac3 is not part of this live capture architecture. If Mac3 later produces camera, sensor, or analysis data, it should enter as another source adapter into the same rehearsal bundle contract. It should not create a fourth primary architecture.\n\nMac4's tmux Tier 0 recorder is now the reliable long-take evidence spine. It owns the continuous rehearsal video, the coarse marker labels, and the local capture-first guarantee.\n\nK11 Pose Coach is the guided short-clip and annotation layer. It owns the operator-facing body framing view, AirDeck zone overlay, short gesture clips, raw/overlay videos, keyframes, hand/body/cursor metadata, and promotion candidate evidence.\n\nMac5 is the offline reconstruction worker. It should sample completed video after the take, run SAM3DBody-cpp, and write derived 3D/body artifacts back into the same session structure. It should not be in the live performance path.\n\nK11 remains the only machine that may send Rekordbox commands. Mac4 Unity, MotionMix, mocopi, Mac5 reconstruction, and raw camera streams must not directly dispatch keys or MIDI.", "htmlHref": "/research/html/lume-k11-mac4-mac5-pose-coach-capture-convergence-plan-1p9vwyw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2054 }, { "id": "motion-autocomplete-gen-8-85wjjg", "title": "Motion Autocomplete Gen 8", "slug": "motion-autocomplete-gen-8", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "motion-autocomplete/README.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Gen | Focus | Key Addition | |-----|-------|--------------| | 1-5 | Foundation | Motion detection, Markov prediction, time patterns | | **6** | **Intent Recognition** | **Precursor detection, WHY-inference, goal chains** | | 7 | Holistic Awareness | Wearables + Spatial + Social + Health + Calendar | | **8** | **Living Space** | **Smart Home + Voice Override + Circadian Rhythm** |", "excerpt": "**AI that predicts your next physical movement and prepares context before you arrive.**\n\n| Gen | Focus | Key Addition | |-----|-------|--------------| | 1-5 | Foundation | Motion detection, Markov prediction, time patterns | | **6** | **Intent Recognition** | **Precursor detection, WHY-inference, goal chains** | | 7 | Holistic Awareness | Wearables + Spatial + Social + Health + Calendar | | **8** | **Living Space** | **Smart Home + Voice Override + Circadian Rhythm** |\n\n### 🧠 Precursor Detector (`intent/precursor-detector.ts`) The body broadcasts intent before conscious action — a weight shift, a glance, a reach. These micro-movements give us 500-2000ms of lead time.\n\n| Precursor Type | Detection Method | Lead Time | |---------------|------------------|-----------| | weight-shift | Accelerometer center-of-gravity change | 800-1500ms | | gaze-redirect | Eye tracking / head turn | 500-1000ms | | hand-preparation | Gyroscope hand positioning | 300-800ms | | screen-disengage | Keyboard/mouse activity drop | 1000-2000ms | | postural-adjustment | Subtle position changes | 500-1000ms | | breathing-change | Heart rate variability | 1500-3000ms |\n\n### 🎯 Intent Engine (`intent/intent-engine.ts`) Understanding WHY people move, not just WHAT they do.", "htmlHref": "/research/html/motion-autocomplete-gen-8-85wjjg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1644 }, { "id": "lume-full-system-goal-16ekxkn", "title": "LUME Full System Goal", "slug": "lume-full-system-goal", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/lume-wiring/lume-full-system-goal-20260610T053617Z.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Build the complete LUME motion system from capture to command, without collapsing the safety boundaries between machines. The system should accept multi-angle body evidence from phones, iPads, Mac2, Mac4, and optional depth or wearable sensors; package that evidence into one auditable session bundle; let Mac5 reconstruct and learn offline; let Mac4 render, map, and prove read-only output lanes; and let K11 remain the only machine allowed to send Rekordbox or AirDeck commands.", "excerpt": "Created: `2026-06-10T05:36:17Z` Status: `in_progress` Mode: `post_mac4_green_wiring`\n\nBuild the complete LUME motion system from capture to command, without collapsing the safety boundaries between machines. The system should accept multi-angle body evidence from phones, iPads, Mac2, Mac4, and optional depth or wearable sensors; package that evidence into one auditable session bundle; let Mac5 reconstruct and learn offline; let Mac4 render, map, and prove read-only output lanes; and let K11 remain the only machine allowed to send Rekordbox or AirDeck commands.\n\nThe final proof is not a document. The final proof is one real captured session where the bundle contains synchronized evidence, Mac5 produces reconstruction artifacts from that evidence, SAN produces phrase/gesture/audio learning rows, Mac4 produces read-only visual/audio mapping proof, and K11 is still the only command authority.\n\n`[home]/Desktop/MotionMix/lume-wiring/lume_mac4_first_completion_gate_20260610T035207Z.json`\n\nThat report has `completion_ready=true`, `mac5_heavy_reconstruction_allowed=true`, wrapper status `pass`, audit status `pass`, and no failed requirements. This unlocks Mac5 preparation and dry-runs, but it does not by itself prove a real reconstruction. A real reconstruction still requires fresh multi-angle body/camera evidence.", "htmlHref": "/research/html/lume-full-system-goal-16ekxkn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1992 }, { "id": "motionmix-sphere-product-architecture-current-i9vdo4", "title": "MotionMix Sphere Product Architecture - Current", "slug": "motionmix-sphere-product-architecture-current", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/lume-wiring/motionmix-sphere-product-architecture-current.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "MotionMix should treat a session as a Sphere: a shared capture room where people, phones, cameras, audio sources, gestures, stage controls, and later editing assets belong to one temporary production space. The user should not have to think in terms of IP addresses, ports, device tokens, or a Rust multicam server. The user-facing act is simple: create a Sphere, invite a friend, scan a QR code or open a link, assign what that friend contributes, and start recording or directing.", "excerpt": "MotionMix should treat a session as a Sphere: a shared capture room where people, phones, cameras, audio sources, gestures, stage controls, and later editing assets belong to one temporary production space. The user should not have to think in terms of IP addresses, ports, device tokens, or a Rust multicam server. The user-facing act is simple: create a Sphere, invite a friend, scan a QR code or open a link, assign what that friend contributes, and start recording or directing.\n\nThis maps directly onto the infrastructure already built. The iPhone or iPad app is a node. The multicam server on port 9404 is the Sphere coordinator. Live Director is the production surface. K11 is the heavy local archive, command gate, and studio storage node. SAN and BodyTruth are analysis lanes. The future Studio tab is where the resulting rushes, body-motion evidence, cuts, and templates become reusable media.\n\nThe clean consumer story is: you want to do a podcast with a friend, so you create a Sphere called something like \"Saturday episode.\" Your friend downloads MotionMix, opens your invite link, and chooses a role. Their iPhone can become a guest camera, a guest mic, a room angle, a shared clap sync source, or just a contributor device for remote capture. The Sphere owns the relationship between all of these devices, not the individual app windows.\n\nFor a podcast, the host may have one main iPhone, one side iPhone, one iPad running Director, and one Mac or K11 storage node. A friend can add another iPhone camera from across the table or from another location if the network mode supports it. The result is not just a video call. It is a structured capture session with labeled sources, synchronized recordings, optional live switching, and post-session assets that can be cut later.\n\nThe same model works for dance, rehearsal, stage capture, interviews, DJ sets, choreography, fitness coaching, and community challenges. The common object is always the Sphere.", "htmlHref": "/research/html/motionmix-sphere-product-architecture-current-i9vdo4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1370 }, { "id": "nkomathlab-project-handoff-document-2gxn0c", "title": "NKoMathLab - Project Handoff Document", "slug": "nkomathlab-project-handoff-document", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "NKoMathLab/HANDOFF.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Generated:** 2026-05-31 **Project:** NKoMathLab - Educational Mathematics App for N'Ko Speech/Gesture Systems **Handoff To:** Codex (or continuation agent) **Handoff From:** OpenCode (qwen3.5:397b)", "excerpt": "**Generated:** 2026-05-31 **Project:** NKoMathLab - Educational Mathematics App for N'Ko Speech/Gesture Systems **Handoff To:** Codex (or continuation agent) **Handoff From:** OpenCode (qwen3.5:397b)\n\nNKoMathLab is a **comprehensive educational mathematics application** built in SwiftUI for iOS. It teaches the mathematical foundations underlying:\n\n- **FAC** (Featural Acoustic Coding) - Speech feature extraction system - **N'Ko** - West African writing system with tonal syllables (3,024 entries) - **AirDeck** - Gesture-based DJ control system - **Computational Choreography** - Body motion as computation - **Anticipatory Transformers** - Predictive sequence models\n\n- **11 comprehensive lessons** written (5,000-10,000+ words each) - **iOS app built and deployed** to simulator - **All core files created** with full educational content - **Ready for user testing** and content expansion\n\n| # | Lesson | Topic ID | Status | Word Count | Key Concepts | |---|--------|----------|--------|------------|--------------| | 1 | Vectors & Geometry | `vectors-geometry` | ✅ Complete | ~8,000 | Dot product, cosine similarity, projection, FAC/N'Ko mappings | | 2 | SVD/PCA | `svd-pca` | ✅ Complete | ~9,000 | Eigenvectors, dimensionality reduction, codebook compression | | 3 | Optimization | `optimization` | ✅ Complete | ~9,000 | Gradient descent, SGD, Adam, loss function ethics | | 4 | Fourier Analysis | `fourier-thinking` | ✅ Complete | ~10,000 | DFT/FFT, STFT, spectrograms, mel filterbanks | | 5 | Speech Acoustics | `speech-acoustics` | ✅ Complete | ~10,000 | Source-filter model, formants, F0, VOT, N'Ko tones | | 6 | Phonetics & Features | `phonetics-features` | ✅ Complete | ~9,000 | Distinctive features, feature geometry, FAC extraction | | 7 | Probability | `probability` | ✅ Complete | ~8,000 | Bayes' theorem, distributions, Bayesian recognition | | 8 | Information Theory | `information-theory` | ✅ Complete | ~8,000 | Entropy, mutual information, KL divergence, cross-entropy | | 9 | Sequence Models | `sequence-models` | ✅ Complete | ~9,000 | HMMs, Viterbi, forward-backward, CTC, tone HMMs | | 10 | Dynamical Systems | `dynamical-systems` | ✅ Complete | ~9,000 | State space, attractors, stability, bifurcations, motor control | | 11 | Transformers | `transformers` | ✅ Complete | ~10,000 | Attention, multi-head, positional encoding, speech transformers |", "htmlHref": "/research/html/nkomathlab-project-handoff-document-2gxn0c.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2912 }, { "id": "agent-swarm-cleqy", "title": "Agent Swarm", "slug": "agent-swarm", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/agent-swarm/README.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Autonomous multi-agent task orchestration daemon — ingest work from GitHub, Linear, or internal queues and dispatch to Claude, Codex, or Gemini agents with workspace isolation, state machine tracking, and full audit trails.", "excerpt": "> Autonomous multi-agent task orchestration daemon — ingest work from GitHub, Linear, or internal queues and dispatch to Claude, Codex, or Gemini agents with workspace isolation, state machine tracking, and full audit trails.\n\n- [Overview](#overview) - [Architecture](#architecture) - [Packages](#packages) - [Data Flow](#data-flow) - [Setup](#setup) - [Configuration](#configuration) - [Usage](#usage) - [API Reference](#api-reference) - [Workflows](#workflows) - [Database Schema](#database-schema) - [Development](#development)\n\nAgent Swarm sits between your work item sources (GitHub Issues, Linear tickets, internal queues) and AI agents (Claude Code, Codex, Gemini CLI). It fully automates the loop:\n\n1. **Ingest** — Poll or receive webhooks from GitHub / Linear / machine queue 2. **Dispatch** — Select the best available agent (by label hints, load, or metadata) 3. **Execute** — Isolate each task in its own workspace (git clone), render a Liquid prompt, run the agent subprocess 4. **Track** — Persist every state transition to Supabase for full audit trails 5. **Notify** — Post Discord messages + update source status (GitHub labels, Linear status) on completion\n\n**Tech stack:** Bun + TypeScript monorepo (10 workspace packages), Supabase for state, Prometheus for metrics, NUMU Bus for cross-system events.", "htmlHref": "/research/html/agent-swarm-cleqy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2409 }, { "id": "mapping-system-update-complete-1qvr7os", "title": "✅ Mapping System Update - COMPLETE", "slug": "mapping-system-update-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/MAPPING_UPDATE_COMPLETE.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Your Rekordbox voice control system has been successfully updated with comprehensive command mappings from the full JSON catalog.", "excerpt": "Your Rekordbox voice control system has been successfully updated with comprehensive command mappings from the full JSON catalog.\n\n**Before:** - ~60 manually curated commands - Basic transport, loop, and hotcue operations only - Limited voice recognition coverage\n\n**After:** - **450 complete commands** from Rekordbox mapping - **227 Deck 1 (left)** commands - **223 Deck 2 (right)** commands - **10 categories** with full coverage\n\n| Category | Commands | Description | |----------|----------|-------------| | Transport | 170 | Play, pause, cue, reverse, track navigation | | Navigation | 120 | Jump, scroll, needle search, cursor movement | | Loop | 72 | Manual loops, beat loops, halve/double | | Sync/Tempo | 38 | Beat sync, tempo adjust, pitch bend, master tempo | | Grid | 22 | Memory cues, beatgrid editing | | Library | 10 | Load tracks, search, playlist operations | | Layout | 6 | Zoom, panels, views | | Sampler | 4 | Sample slots (extended in full mapping) | | Mixer | 4 | Crossfader, EQ, filters | | Effects | 4 | FX slots and controls | | **Total** | **450** | **Full Rekordbox coverage** |\n\n- **Left Deck (Deck 1):** 227 commands - **Right Deck (Deck 2):** 223 commands - **Perfect balance** for both decks", "htmlHref": "/research/html/mapping-system-update-complete-1qvr7os.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1511 }, { "id": "voice-control-for-rekordbox-complete-system-15hmvyt", "title": "Voice Control for Rekordbox - Complete System", "slug": "voice-control-for-rekordbox-complete-system", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/README_VOICE_CONTROL.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "You now have **three production-ready voice control systems** for Rekordbox DJ software, each optimized for different use cases.", "excerpt": "You now have **three production-ready voice control systems** for Rekordbox DJ software, each optimized for different use cases.\n\n| Feature | Gemini Live | Whisper | Hybrid ⭐ | |---------|-------------|---------|-----------| | **Latency** | 80ms | 195ms | 125ms → 85ms | | **Accuracy** | 98% | 95-98% | 90% → 98% | | **Offline** | ❌ | ✅ | ✅ | | **Self-Improving** | ❌ | ❌ | ✅ | | **Cost** | ~$0.001/cmd | Free | Free | | **Setup Time** | 5 min | 5 min | 5 min | | **Best For** | Live (internet) | Offline sets | Long-term use |\n\n### Quick References - **[QUICK_START.md](QUICK_START.md)** - Get started in 5 minutes - **[VOICE_SYSTEMS_COMPARISON.md](VOICE_SYSTEMS_COMPARISON.md)** - Visual comparison\n\n### Complete Guides - **[VOICE_CONTROL_SYSTEMS_GUIDE.md](VOICE_CONTROL_SYSTEMS_GUIDE.md)** - Full documentation - **[ARCHITECTURE.md](ARCHITECTURE.md)** - Technical deep dive - **[FINE_TUNE_GUIDE.md](FINE_TUNE_GUIDE.md)** - Fine-tuning walkthrough\n\nThis checks: - ✅ All dependencies installed - ✅ Voice control systems can be imported - ✅ Models can be loaded - ✅ Configuration files exist - ✅ Environment variables set", "htmlHref": "/research/html/voice-control-for-rekordbox-complete-system-15hmvyt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1766 }, { "id": "tier-1-enhancements-user-guide-l3l2zy", "title": "Tier 1 Enhancements - User Guide", "slug": "tier-1-enhancements-user-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/TIER1_ENHANCEMENTS_GUIDE.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The enhanced Gemini Live voice control system implements five major optimizations that dramatically improve usability, responsiveness, and intelligence while maintaining the same high accuracy.", "excerpt": "The enhanced Gemini Live voice control system implements five major optimizations that dramatically improve usability, responsiveness, and intelligence while maintaining the same high accuracy.\n\nThe original system waited 800ms after each speech fragment before processing commands. This ensured completeness but added unnecessary latency for simple, unambiguous commands.\n\nThe enhanced system intelligently adjusts this timeout based on whether the command appears complete:\n\n**Simple Commands (50ms timeout):** - \"play left\" - \"sync right\" - \"stop left\" - \"cue 1\"\n\n**Complex Commands (800ms timeout):** - \"loop four beats and activate effects\" - \"play left then sync\"", "htmlHref": "/research/html/tier-1-enhancements-user-guide-l3l2zy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2101 }, { "id": "tier-3-context-aware-embeddings-semantic-command-disambiguation-guide-1vl06rx", "title": "Tier 3: Context-Aware Embeddings - Semantic Command Disambiguation Guide", "slug": "tier-3-context-aware-embeddings-semantic-command-disambiguation-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/TIER3_CONTEXT_EMBEDDINGS_GUIDE.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Context-Aware Embeddings** enables the voice control system to understand ambiguous commands by considering the current DJ system state. When you say \"play\" or \"sync\" without specifying a deck, the system intelligently infers which deck you mean based on what's currently happening.", "excerpt": "**Context-Aware Embeddings** enables the voice control system to understand ambiguous commands by considering the current DJ system state. When you say \"play\" or \"sync\" without specifying a deck, the system intelligently infers which deck you mean based on what's currently happening.\n\n**Benefits:** - ✅ Natural, conversational commands (\"play\" instead of \"play left\") - ✅ Context-aware disambiguation (knows which deck you mean) - ✅ Intelligent action suggestions (predicts next likely commands) - ✅ Fast heuristic matching (<5ms overhead) - ✅ No ML training required (rule-based)\n\n**What Happens:** 1. System tracks command history (last deck, last action) 2. When you give ambiguous command, system analyzes context 3. Infers which deck you mean based on priority rules 4. Resolves command automatically with high confidence\n\n1. **Last Deck** (90% confidence) - Most recent action was on this deck - Example: After \"play left\", \"sync\" → \"sync left\"\n\n2. **Cued Deck** (75% confidence) - Deck is cued and ready to play - Example: Right cued → \"play\" → \"play right\"", "htmlHref": "/research/html/tier-3-context-aware-embeddings-semantic-command-disambiguation-guide-1vl06rx.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2041 }, { "id": "motion-control-studio-architecture-aligned-to-computational-choreography-echelon-k0mqwc", "title": "Motion Control Studio — Architecture Aligned to Computational Choreography & Echelon", "slug": "motion-control-studio-architecture-aligned-to-computational-choreography-echelon", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/echelon/motion_control_studio_architecture.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Supporting packages: - `cc-core/` — JAX/Flax equilibria (LIM‑RPS + DELL, learned geometry, implicit diff). Export models to ONNX/StableHLO for Rust inference. - `cc-studio/` — existing Python runtime utilities (logging, DJ agent glue); keep as sidecars until everything is ported. - `configs/` — gesture/mapping/profile TOML/JSON; keep user profiles here so Studio + Echelon share the same contract.", "excerpt": "# Motion Control Studio — Architecture Aligned to Computational Choreography & Echelon\n\n## What This Is (and Isn’t) - **Instrument-grade control surface** that routes embodied input (phone/watch/IMU) into a real-time action layer with <10 ms reflex latency. - **Computational choreography-native**: built around `cc-core` (LIM‑RPS/DELL) equilibria, not hardcoded gesture thresholds. - **Plugin‑first & offline‑first**: everything runs locally; cloud sync is optional and never required for performance. - **Echelon optional (future)**: today it can run standalone with the action adapters; when Echelon lands, we swap the execution sink without redesigning the control plane.\n\n## The Missing Layer We Add Now Introduce an explicit **Embodied Latent & Choreography Engine** between fusion and gestures. This is cc-core (LIM‑RPS/DELL) producing a shared latent “moment” that all consumers read, so we do not rebuild Echelon at lower power or bypass computational choreography.\n\nSupporting packages: - `cc-core/` — JAX/Flax equilibria (LIM‑RPS + DELL, learned geometry, implicit diff). Export models to ONNX/StableHLO for Rust inference. - `cc-studio/` — existing Python runtime utilities (logging, DJ agent glue); keep as sidecars until everything is ported. - `configs/` — gesture/mapping/profile TOML/JSON; keep user profiles here so Studio + Echelon share the same contract.\n\n## Computational Choreography Contract (what the runtime must honor) - **Two time scales**: - Fast loop (frame rate 100–200 Hz): LIM‑RPS/DELL fast `x*` for reflex control; target <4 iterations, <5 ms end-to-end including IPC. - Slow loop (beat rate 2–4 Hz): DELL slow `y*` for phrase/scene control; scheduled on beat using Link clock; keep coupling energy φ stable. - **Phase-aware control**: expose ψ from the phase head; UI shows ψ vs θ (beat phase) and re-lock time after dropouts. - **Contractive operators**: retain cc-core spectral-norm constraints and step fields; log contraction ratio/headroom in telemetry. - **Fallbacks**: if DELL stalls, hold last `x*`/`y*`, keep template matcher alive, and keep scheduler safe (never block audio).", "htmlHref": "/research/html/motion-control-studio-architecture-aligned-to-computational-choreography-echelon-k0mqwc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1225 }, { "id": "phase-2-implementation-plan-scheduler-safety-sd6tw6", "title": "Phase 2 Implementation Plan – Scheduler & Safety", "slug": "phase-2-implementation-plan-scheduler-safety", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/echelon/phases/phase-2-plan.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Timeline:** Weeks 7-12 (6 weeks) **Status:** Foundation complete (BeatClock trait, Quantizer, SafetyPolicy) **Next:** Action queue, executor, MIDI/OSC integration", "excerpt": "## Overview Phase 2 focuses on integrating Ableton Link synchronization, implementing quantized action execution with safety policies, and adding MIDI/OSC control interfaces. The scheduler coordinates deck operations with beat-synchronized timing while enforcing safety constraints.\n\n**Timeline:** Weeks 7-12 (6 weeks) **Status:** Foundation complete (BeatClock trait, Quantizer, SafetyPolicy) **Next:** Action queue, executor, MIDI/OSC integration\n\n### Completed ✅ - [x] BeatClock trait with `current_beat()`, `phase()`, `tempo_bpm()`, `is_synchronized()`, `num_peers()` - [x] LocalBeatClock implementation for offline use - [x] Helper methods: `time_to_next_beat()`, `time_to_next_bar()` - [x] Unit tests for beat clock functionality\n\n### Remaining Tasks - [ ] **7.1 Link SDK FFI Integration** (Requires Ableton Link SDK) - [ ] Add Link SDK C++ bindings to `link-clock/src/ffi.rs` - [ ] Create `LinkSession` wrapper struct - [ ] Implement `LinkClock` struct implementing `BeatClock` trait - [ ] Expose `beat_time()`, `phase()`, `is_connected()`, `num_peers()` methods - [ ] Handle Link session lifecycle (create, enable, close) - **Dependencies:** Ableton Link SDK license and C++ bindings - **Deliverable:** `LinkClock` compiles and can query Link state\n\n- [ ] **7.2 Link Thread** - [ ] Create `LinkThread` struct in `link-clock` crate - [ ] Poll Link state at configurable interval (e.g., 10ms) - [ ] Publish beat clock updates via SPSC ring (`BeatClockUpdate` message) - [ ] Handle Link tempo changes and peer connections/disconnections - [ ] Graceful shutdown on thread join - **Dependencies:** Link SDK integration (7.1) - **Deliverable:** `cargo run -p link-test` demonstrates Link sync with multiple instances", "htmlHref": "/research/html/phase-2-implementation-plan-scheduler-safety-sd6tw6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2333 }, { "id": "computational-choreography-system-overview-zi9ysm", "title": "Computational Choreography — System Overview", "slug": "computational-choreography-system-overview", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/04-reference/overview.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Multi-modal input streams sampled at 100 Hz: - **Mocopi suit** — 24-point skeleton tracking - **Polar H10** — heart rate + HRV - **Video pose** — MediaPipe/OpenPose fallback - **Mobile accel** — phone/tablet backup", "excerpt": "Multi-modal input streams sampled at 100 Hz: - **Mocopi suit** — 24-point skeleton tracking - **Polar H10** — heart rate + HRV - **Video pose** — MediaPipe/OpenPose fallback - **Mobile accel** — phone/tablet backup\n\nFeatures extracted per frame: - Motion energy (kinetic sum) - HR derivative (arousal) - Spatial symmetry (left/right balance) - Center of mass trajectory - Velocity peaks - Limb angles\n\nConverts multi-channel features into a **coherent latent representation** `x⁺`: - Handles missing modalities through hallucination - Maintains temporal coherence via proximal update - Outputs normalized latent vector (dim=16-32)\n\nSliding window (2-4 seconds) of latent vectors → control signals: - `tempo_scale` — BPM multiplier (0.75–1.5) - `density` — rhythmic complexity (0–1) - `tension` — filter/harmonic tension (0–1) - `brightness` — spectral brightness (0–1) - `fx_send` — reverb/delay mix (0–1) - `swing` — rhythmic swing (0–0.6) - `accent` — dynamic range (0–1)\n\nControl signals → sound engine protocols: - **MIDI Bridge** — CC messages via Web MIDI (IAC Driver) - **OSC Bridge** — UDP to SuperCollider/Max - **Link Bridge** — Ableton Link sync for phase/tempo", "htmlHref": "/research/html/computational-choreography-system-overview-zi9ysm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 439 }, { "id": "migration-architect-architecture-document-iyk8qn", "title": "Migration Architect — Architecture Document", "slug": "migration-architect-architecture-document", "kind": "architecture", "program": "Protocol and Compute", "sourceAnchor": "projects/dream-metamorphosis/migration-architect/docs/ARCHITECTURE.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Migration Architect is an AI-powered tool that plans and executes zero-downtime system migrations. It generates migration blueprints from system state, builds dependency graphs, creates rollback strategies at every step, and runs health checks before and after migration.", "excerpt": "Migration Architect is an AI-powered tool that plans and executes zero-downtime system migrations. It generates migration blueprints from system state, builds dependency graphs, creates rollback strategies at every step, and runs health checks before and after migration.\n\n- **Nodes** represent migration steps or components - **Edges** represent dependencies (must-complete-before relationships) - **Weights** on edges represent risk scores (0.0–1.0) - **Critical path** is computed for scheduling\n\nProperties: - Cycle detection prevents deadlocks - Topological sort determines execution order - Parallel execution groups are derived from independent subgraphs - Each node carries rollback metadata\n\n| Stage | Purpose | Failure Action | |-------|---------|---------------| | Pre-migration | Validate system is healthy enough to migrate | Abort migration | | Intra-migration | Verify each step succeeded | Rollback current phase | | Post-migration | Confirm target state achieved | Full rollback |\n\nCheck types: - **Connectivity** — Can components reach each other? - **Data Integrity** — Are checksums valid? - **Performance** — Is latency within thresholds? - **Functional** — Do key operations still work? - **Capacity** — Are resources sufficient?", "htmlHref": "/research/html/migration-architect-architecture-document-iyk8qn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 680 }, { "id": "skill-entity-architecture-sea-um8pbh", "title": "Skill Entity Architecture (SEA)", "slug": "skill-entity-architecture-sea", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/dream-weaver-engine/dreams/skill-entity-architecture.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Workspace document requiring curation.", "excerpt": "## Essence Inverting static skill files into living autonomous entities. 13 creative/philosophical skills become persistent daemons with memory, relevance scoring via embeddings, and self-calibrating activation thresholds. A two-tier routing system (embedding filter → MiniMax scoring) with zero hot-path latency — injections arrive asynchronously as Discord spoiler footers after the main response.\n\n## Context 105+ skills in Clawdbot, most static. SEA makes creative skills (phi:*, art:*, nav:*) into entities that remember when they've been useful, learn their own trigger patterns, and evolve through feedback. Full spec complete, 0% implemented. Phase 0 benchmark is the critical gate.\n\n## Tags architecture, skills, embeddings, minimax, discord, autonomous, evolution, routing", "htmlHref": "/research/html/skill-entity-architecture-sea-um8pbh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 110 }, { "id": "djoko-series-dataset-architecture-q6ugqv", "title": "Djoko Series Dataset Architecture", "slug": "djoko-series-dataset-architecture", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "projects/LearnNKo/ml/docs/technical/DJOKO_ARCHITECTURE.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The Djoko Series Dataset Creation System processes Djoko episodes into high-quality training data for: - **Bambara ASR** (Automatic Speech Recognition) - **Bambara ↔ English Translation** - **Bambara ↔ French Translation** (future) - **Multimodal Language Learning**", "excerpt": "The Djoko Series Dataset Creation System processes Djoko episodes into high-quality training data for: - **Bambara ASR** (Automatic Speech Recognition) - **Bambara ↔ English Translation** - **Bambara ↔ French Translation** (future) - **Multimodal Language Learning**\n\n### 1. Voice Activity Detection (VAD) **Purpose**: Remove silence and extract only speech segments\n\n**Features**: - Energy-based detection - Spectral analysis for speech quality - Adaptive thresholding - Minimum segment duration filtering (0.5s+) - Merge nearby segments (<0.3s gaps) - Quality confidence scoring\n\n**Input**: Raw Djoko episode audio **Output**: List of speech segments with timestamps\n\n### 2. Episode Processor **Purpose**: Orchestrate the complete processing pipeline", "htmlHref": "/research/html/djoko-series-dataset-architecture-q6ugqv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 783 }, { "id": "daydream-quote-mining-note-synthesis-engine-12oknri", "title": "💭 Daydream — Quote Mining & Note Synthesis Engine", "slug": "daydream-quote-mining-note-synthesis-engine", "kind": "architecture", "program": "Research Backlog", "sourceAnchor": "projects/Meaning-Full-Power/docs/DAYDREAM-ARCHITECTURE.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| Source | Method | Content Type | |--------|--------|--------------| | Apple Notes | `memo` CLI | Raw notes, ideas, quotes | | Voice Transcripts | Memory files | Spoken thoughts | | Discord History | Channel search | Past sayings | | Session Logs | Log analysis | Conversational gems |", "excerpt": "## Vision An autonomous system that mines your Apple Notes, voice transcripts, and conversations to discover meaningful one-liners, quotes, and seeds that can become MFP content.\n\n### 1. Quote Mining - Scan Apple Notes for potential one-liners - Extract quotable fragments from longer notes - Identify philosophical/motivational patterns matching MFP voice - Flag notes that could become poems\n\n### 2. Note Cleanup Chain - Iteratively process messy notes - Create linked chains of related thoughts - Consolidate duplicates - Tag with MFP themes (time, confidence, purpose, etc.)\n\n### 3. Content Seeding - Feed discovered quotes to Daily MFP pipeline - Generate new poem drafts from one-liners - Create illustration prompts from themes\n\n| Source | Method | Content Type | |--------|--------|--------------| | Apple Notes | `memo` CLI | Raw notes, ideas, quotes | | Voice Transcripts | Memory files | Spoken thoughts | | Discord History | Channel search | Past sayings | | Session Logs | Log analysis | Conversational gems |", "htmlHref": "/research/html/daydream-quote-mining-note-synthesis-engine-12oknri.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 746 }, { "id": "obsidian-vault-writer-cross-agent-integration-handoff-1kepvnl", "title": "Obsidian Vault Writer — Cross-Agent Integration Handoff", "slug": "obsidian-vault-writer-cross-agent-integration-handoff", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/obsidian_vault_writer/INTEGRATION-HANDOFF.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date**: 2026-03-01 **Author**: Claude Code (Opus 4.6) **For**: All agent sessions (Codex, Gemini, Clawdbot, Cursor, future agents) **Status**: Phase 1-4 complete, live on cloud-vm", "excerpt": "**Date**: 2026-03-01 **Author**: Claude Code (Opus 4.6) **For**: All agent sessions (Codex, Gemini, Clawdbot, Cursor, future agents) **Status**: Phase 1-4 complete, live on cloud-vm\n\nThe **Obsidian Vault Writer** is a Python module that writes structured Markdown notes to an Obsidian vault. Every note has YAML frontmatter and `[[bidirectional links]]` that create an organic knowledge graph. The vault lives on cloud-vm and syncs to all devices via Obsidian Sync (E2E encrypted).\n\n**The core idea**: Every agent session, every Discord synthesis, every AAO task completion, and every Prefect flow run should produce a vault note. Over time, `[[backlinks]]` reveal connections between ideas, projects, and agents that no single system tracks.\n\n| File | Location | Trigger | What it writes | |------|----------|---------|----------------| | `synthesis-preprocessor.js` | `[home-path]` | Discord message synthesized | `Inbox/{date}/{time}-{slug}.md` | | `session_end_hook.py` | `[home-path]` | Claude Code session ends | `Sessions/{date}-claudecode-{id}.md` | | `aao_reputation_collector.py` | `[home-path]` | AAO task quality assessed | `Sessions/{date}-{agenttype}-{task_id}.md` | | `vault_sync.py` | `[home-path]` | Every 6h Prefect flow | Catch-up synthesis + agent sessions + daily summaries |\n\n| Component | Location | Port | Role | |-----------|----------|------|------| | obsidian-sync.service | cloud-vm systemd | — | Continuous vault sync via `ob sync --continuous` | | obsidian-headless (ob) | `/usr/bin/ob` on cloud-vm | — | Node 22+ CLI for headless Obsidian | | Obsidian Cloud | Agent Vault (North America) | — | E2E encrypted sync hub |", "htmlHref": "/research/html/obsidian-vault-writer-cross-agent-integration-handoff-1kepvnl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2458 }, { "id": "session-handoff-march-22-24-2026-1q1vv5t", "title": "Session Handoff — March 22-24, 2026", "slug": "session-handoff-march-22-24-2026", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "SESSION-HANDOFF-20260324.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Second pass found 8 additional issues: 1. Phantom author \"Dedhia\" inconsistency 2. Author initial mismatches across papers 3. Remaining internal references (Supabase, Graph Kernel, port numbers) 4. 19+ \"we/our\" pronouns in paper.md 5. \"(full context, full context)\" copy-paste error 6. \"9-step pipeline\" header but 11 steps listed 7. V5 still referenced in limitations section 8. AI slop: \"transcends\", \"Additionally\"", "excerpt": "## Overview 12+ hour session across March 22-24. Primary focus: research paper evaluation, Anticipatory Transformer build + GPU training, BEYOND daemon, OpenAI Parameter Golf submission, repo cleanup for public scrutiny.\n\n### Experiment 1: Anticipation Geometry Enhanced Eval - **What**: Does anticipation beat embeddings on conversation convergence prediction? - **Data**: 50K turns from Supabase, 126 conversations with strict labels (55 converged, 71 not) - **Result**: Anticipation-only 63.5% vs Embedding PCA 52.8% vs Combined 65.0% vs Baseline 56.3% - **Key features (95% bootstrap CI excludes zero)**: - `c_final` (final commitment): 69.8%, r=-0.372 - `tp_mean` (mean transition pressure): 69.8%, r=-0.196 - `rm_mean` (mean recovery margin): 61.9%, r=-0.203 - `emb_dist_mean`: 62.7%, r=+0.163 - **Permutation test**: p=0.175 (not significant at 0.05, need ~200+ conversations) - **Script**: /tmp/definitive_eval.py (ran on Mac1) - **Results file**: Desktop/Comp-Core/papers/evaluation-results/definitive-eval.json\n\n### Experiment 2: Domain Shift (Paper 3) - **What**: Does frozen KG degrade on newer data while live KG maintains coverage? - **Data**: 354K+ turns from Supabase, 356 entities from Graph Kernel - **Result**: Frozen KG coverage drops 100% → 66.5% over 3 periods. Live KG stays 100%. - **Cohen's d**: 1.226 (coverage), 1.295 (path availability) - **Results file**: Desktop/Comp-Core/papers/evaluation-results/domain-shift-results.json and domain-shift-experiment.json\n\n### Experiment 3: Computational Choreography Demo - **What**: Full pipeline proof — sensor → anticipation scalars → Strudel audio parameters - **Output**: 3-panel dark-themed visualization at Desktop/computational-choreography/demo/demo_output.png - **Script**: Desktop/computational-choreography/demo/demo_pipeline.py - **Strudel output**: Desktop/computational-choreography/demo/strudel_output.js (11 keyframes) - **Key finding**: Transition pressure spikes at exact motion phase boundaries\n\n### Experiment 4: KARL Ablation - **What**: Do top-35 high-advantage trajectories differ measurably from random? - **Data**: 290 trajectories from Desktop/karl/karl/trajectories.jsonl - **Result**: Cohen's d = 3.065 (massive). Top-35 reward 0.768 vs Random-35 0.637 - **Tool entropy**: 2.012 vs 0.891 (2.3x more diverse) - **Success rate**: 100% vs 95.8% - **Results file**: [home-path]", "htmlHref": "/research/html/session-handoff-march-22-24-2026-1q1vv5t.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1931 }, { "id": "trust-translator-system-documentation-1dp8yas", "title": "Trust Translator System Documentation", "slug": "trust-translator-system-documentation", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "trust-translator/docs/SYSTEM_DOCUMENTATION.md", "extension": "md", "score": 40, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. [System Overview](#system-overview) 2. [Architecture](#architecture) 3. [Trust Scoring System](#trust-scoring-system) 4. [Intent Preservation Engine](#intent-preservation-engine) 5. [Style Translation](#style-translation) 6. [Cross-Domain Translation](#cross-domain-translation) 7. [API Reference](#api-reference) 8. [Evolution History](#evolution-history)", "excerpt": "**Version:** 2.5.0-gen13 **Evolution:** Generation 13 (Cross-Platform Intelligence) **Last Updated:** February 2025\n\n1. [System Overview](#system-overview) 2. [Architecture](#architecture) 3. [Trust Scoring System](#trust-scoring-system) 4. [Intent Preservation Engine](#intent-preservation-engine) 5. [Style Translation](#style-translation) 6. [Cross-Domain Translation](#cross-domain-translation) 7. [API Reference](#api-reference) 8. [Evolution History](#evolution-history)\n\nTrust Translator is a sophisticated communication transformation system that converts text between communication styles while preserving semantic intent. Built on linguistic theory (Politeness Theory, Hofstede's Cultural Dimensions, Speech Act Theory), it enables contextually appropriate communication across different relationships, platforms, and cultures.\n\n| Capability | Description | |------------|-------------| | **Style Translation** | Transform casual ↔ formal, direct ↔ diplomatic | | **Intent Preservation** | Maintain semantic meaning through transformations | | **Trust Calibration** | Relationship-aware communication recommendations | | **Cultural Bridging** | Cross-cultural adaptation (Gen 10) | | **Platform Intelligence** | Platform-specific optimization (Gen 13) | | **Multi-party Facilitation** | Group conversation dynamics (Gen 9) | | **Streaming Translation** | Real-time token-by-token output (Gen 11) | | **Translation Memory** | Adaptive learning from feedback (Gen 12) |\n\n| Module | File | Purpose | |--------|------|---------| | **Styles** | `src/styles.ts` | Communication style definitions, markers, analysis | | **Intent** | `src/intent.ts` | Semantic extraction, SAO parsing, face threats | | **Trust** | `src/trust.ts` | Relationship tracking, style recommendations | | **Translator** | `src/translator.ts` | Core transformation engine | | **LLM Semantic** | `src/llm-semantic.ts` | Deep semantic understanding via LLM | | **Conversation Flow** | `src/conversation-flow.ts` | Multi-turn conversation tracking | | **Multi-Party** | `src/multiparty-engine.ts` | Group dynamics, facilitation | | **Cultural Bridge** | `src/cultural-bridge.ts` | Hofstede dimensions, cultural adaptation | | **Streaming** | `src/streaming-engine.ts` | Token-by-token translation | | **Translation Memory** | `src/translation-memory.ts` | Learning, feedback, preferences | | **Platform Intelligence** | `src/platform-intelligence.ts` | Platform detection and optimization |", "htmlHref": "/research/html/trust-translator-system-documentation-1dp8yas.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2539 }, { "id": "invariants-assumptions-unified-agent-os-1bzt0c4", "title": "INVARIANTS & ASSUMPTIONS — Unified Agent OS", "slug": "invariants-assumptions-unified-agent-os", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "unified-agent-os/.governance/INVARIANTS.md", "extension": "md", "score": 40, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Workspace document requiring curation.", "excerpt": "### INV-1: Tenant Isolation - **Statement:** No tenant can access another tenant's data, secrets, sessions, or compute - **Why:** Trust is the product. A single leak destroys the business. - **What breaks:** Customer trust, legal liability, SOC 2 compliance - **Canary:** Cross-tenant query audit log; any query touching tenant_id != session.tenant_id triggers immediate alert\n\n### INV-2: Model Provider Neutrality - **Statement:** AgentOS must never hard-depend on a single LLM provider - **Why:** Vendor lock-in kills adoption. Users switch models constantly. - **What breaks:** Customer freedom, competitive positioning - **Canary:** If removing any single provider's SDK breaks more than one subsystem, invariant is violated\n\n### INV-3: API-First Surface - **Statement:** Every user-facing feature must be accessible via API before (or simultaneously with) any UI - **Why:** API-first ensures composability, testability, and third-party integration - **What breaks:** Automation users can't access UI-only features; testing becomes browser-dependent - **Canary:** UI PR without corresponding API endpoint = blocked\n\n### INV-4: Session Cost Accountability - **Statement:** Every token consumed must be attributed to a specific session, tenant, and budget - **Why:** Cost transparency is a core value prop. Untracked spend erodes trust. - **What breaks:** Billing accuracy, budget enforcement, cost optimization - **Canary:** If `sum(session_costs)` diverges from `provider_invoice` by >2%, investigate\n\n### INV-5: Graceful Degradation - **Statement:** Failure of any single subsystem (Pulse, Heartbeat, Dreams) must not crash the platform - **Why:** Agents run 24/7; cascading failures are unacceptable - **What breaks:** Platform uptime, customer operations - **Canary:** Circuit breaker open for >5 minutes on any subsystem = P1 alert", "htmlHref": "/research/html/invariants-assumptions-unified-agent-os-1bzt0c4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 643 }, { "id": "cognitivehire-content-strategy-zajp7p", "title": "CognitiveHire Content Strategy", "slug": "cognitivehire-content-strategy", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "cognitive-hire/content/content-strategy.md", "extension": "md", "score": 38, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**What exists:** - Grand Diomande consulting brand (granddiomande.com) — active, Vercel-hosted - 50+ iOS apps shipped (39 on TestFlight) - 112K+ AI interactions across 11 domains in Supabase - Technical blog posts drafted but not published (cognitive twin, CALC, Vantage) - Strong technical credibility: ML, distributed systems, multi-agent coordination, iOS, creative production - Guinean-American heritage + N'Ko language AI work — authentic differentiator - No dedicated CognitiveHire content presence yet", "excerpt": "**What exists:** - Grand Diomande consulting brand (granddiomande.com) — active, Vercel-hosted - 50+ iOS apps shipped (39 on TestFlight) - 112K+ AI interactions across 11 domains in Supabase - Technical blog posts drafted but not published (cognitive twin, CALC, Vantage) - Strong technical credibility: ML, distributed systems, multi-agent coordination, iOS, creative production - Guinean-American heritage + N'Ko language AI work — authentic differentiator - No dedicated CognitiveHire content presence yet\n\n**What's missing:** - Platform-specific content presence for CognitiveHire - A consistent publishing cadence - Demo content (video, interactive twin interface) - An audience that knows this product exists\n\n**Assessment:** This is a greenfield launch with strong underlying credibility. The asset gap is distribution, not substance. Mohamed has proof. The work is to make that proof visible to the right people.\n\n### Path A: Educational **Premise:** \"Here's what your AI usage data actually reveals about you\"\n\nTeaches the audience something they didn't know. Positions Mohamed as the person who figured this out first. Low defensiveness from the audience. Works well for cold traffic who don't know CognitiveHire yet.", "htmlHref": "/research/html/cognitivehire-content-strategy-zajp7p.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4658 }, { "id": "dlm-o4kikd", "title": "DLM", "slug": "dlm", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/architecture/docs/DLM.md", "extension": "md", "score": 38, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Divergent Language Matrix (DLM) is designed to generate a lower-dimensional representation of complex, hierarchical text data, such as conversations. The algorithm preserves both semantic and structural relationships within the data, allowing for more efficient analysis and visualization.", "excerpt": "Divergent Language Matrix (DLM) is designed to generate a lower-dimensional representation of complex, hierarchical text data, such as conversations. The algorithm preserves both semantic and structural relationships within the data, allowing for more efficient analysis and visualization.\n\nIn the Divergent Language Matrix (DLM) framework, a conversation tree is formulated as a directed, acyclic graph where each node corresponds to a message in the conversation. Each message `t_i` is mathematically defined by a triplet `(d_i, s_i, c_i)`, such that:\n\n* x_coord (Depth): Represents the hierarchical level of a message. If a message is a direct reply to another message, it will be one level deeper (e.g., the original message is at depth 0, a reply to it is at depth 1, a reply to that reply is at depth 2, and so on).\n\n* y_coord (Order among siblings): Represents the order in which a message appears among its siblings. This is relevant when there are multiple replies (siblings) to a single message. It provides a sense of the sequence of the conversation.\n\n* z_coord (Homogeneity based on sibling count and similarity score): This is the most direct measure of homogeneity in the provided method.It serves as an essential indicator for both the structural and semantic relationships among messages at the same hierarchical level. The `z_coord` value is calculated differently depending on whether similarity scores are included.", "htmlHref": "/research/html/dlm-o4kikd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1501 }, { "id": "motion-as-language-semantic-meaning-from-movement-19b6ll4", "title": "Motion as Language: Semantic Meaning from Movement", "slug": "motion-as-language-semantic-meaning-from-movement", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/motion-language/MOTION_SEMANTICS.md", "extension": "md", "score": 38, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document explores how continuous human movement maps to discrete semantic meaning through the Comp-Core motion intelligence pipeline. At its heart: the **2.16ms latent motion window**—a quantum of embodied computation that bridges the gap between raw sensor data and meaningful intent.", "excerpt": "This document explores how continuous human movement maps to discrete semantic meaning through the Comp-Core motion intelligence pipeline. At its heart: the **2.16ms latent motion window**—a quantum of embodied computation that bridges the gap between raw sensor data and meaningful intent.\n\n1. [The 2.16ms Latent Window](#the-216ms-latent-window) 2. [Gesture Vocabulary Taxonomy](#gesture-vocabulary-taxonomy) 3. [Motion → Intent Translation Pipeline](#motion--intent-translation-pipeline) 4. [Connection to cc-inscription Sigils](#connection-to-cc-inscription-sigils) 5. [Theoretical Foundations](#theoretical-foundations) 6. [Implementation Architecture](#implementation-architecture)\n\nThe Comp-Core system achieves **2.16ms average latency** from sensor input to semantic output. This isn't arbitrary—it's the sweet spot where:\n\n1. **Perceptual continuity**: Below the 10-20ms threshold where humans perceive delay 2. **Information sufficiency**: Enough motion data for meaningful feature extraction 3. **Causal coherence**: Fast enough to feel like \"now,\" slow enough to reason about\n\nMotion data flows through a **104-dimensional latent space** (via RPS—Recursive Polymodal Synthesis):", "htmlHref": "/research/html/motion-as-language-semantic-meaning-from-movement-19b6ll4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1679 }, { "id": "emergence-gardener-13iiwer", "title": "Emergence Gardener", "slug": "emergence-gardener", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/emergence-gardener/SKILL.md", "extension": "md", "score": 38, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Traditional creativity tools force output: \"Generate 10 ideas NOW.\" Emergence Gardener inverts this—it cultivates the environment where ideas naturally surface.", "excerpt": "> *\"A gardener doesn't pull plants up to make them grow faster. They create conditions where growth is inevitable.\"*\n\nTraditional creativity tools force output: \"Generate 10 ideas NOW.\" Emergence Gardener inverts this—it cultivates the environment where ideas naturally surface.\n\n**Core insight:** How you pay attention to ideas affects how they grow. Direct focus can nurture some ideas but crush others.\n\n| Mode | Growth | Serendipity | Best For | |------|--------|-------------|----------| | 🔦 direct | +20% | -50% | technical, strategic | | 🌅 peripheral | -10% | +50% | creative, experimental, philosophical | | ☁️ ambient | normal | normal | mixed gardens | | 🌙 twilight | -20% | +100% | experimental, integrative, reflective | | 💤 deep_rest | -70% | -80% | mycelium (2x growth) |\n\nWhen `attention auto` is enabled, the garden follows natural attention patterns:", "htmlHref": "/research/html/emergence-gardener-13iiwer.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 7439 }, { "id": "architecture-cleanup-analysis-1o62fhw", "title": "Architecture Cleanup Analysis", "slug": "architecture-cleanup-analysis", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "milkmendelivery/docs/archive/ARCHITECTURE_CLEANUP_ANALYSIS.md", "extension": "md", "score": 38, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Issue**: Multiple overlapping implementations of route optimization algorithms - **Impact**: - Code duplication - Maintenance burden - Confusion about which to use - Potential bugs from inconsistent implementations - **Recommendation**: - Audit which implementations are actually used - Consolidate into a single, well-tested optimization engine - Remove unused variants", "excerpt": "# Architecture Cleanup Analysis ## Milkmen Delivery - Code Quality & Dead Weight Assessment\n\n### Project Overview **Objective**: Sales route optimization and territory management platform for coffee delivery sales teams. Manages locations, agents, territories, route planning, and store visits.\n\n### 1. **Unused Import in Entry Point** **File**: `src/main.tsx` - **Issue**: Line 4 imports `Planner` but never uses it - **Impact**: Unnecessary bundle size, confusion - **Fix**: Remove line 4: `import Planner from \"./pages/routes/Planner\";`\n\n### 2. **Duplicate Route Optimization Implementations** **Files**: - `partner-delivery-route/route-calculator.ts` (root level - 628 lines) - `src/lib/optimization/partner-route-calculator.ts` (src/lib - 353 lines) - `src/services/route-optimization/route-calculator.ts` (simpler version) - `src/lib/advanced-route-optimizer.ts` (443 lines) - `src/lib/route-strategy-engine.ts` (454 lines) - `src/lib/optimization/multi-stage-route-optimizer.ts` (1308 lines!)\n\n**Issue**: Multiple overlapping implementations of route optimization algorithms - **Impact**: - Code duplication - Maintenance burden - Confusion about which to use - Potential bugs from inconsistent implementations - **Recommendation**: - Audit which implementations are actually used - Consolidate into a single, well-tested optimization engine - Remove unused variants", "htmlHref": "/research/html/architecture-cleanup-analysis-1o62fhw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1183 }, { "id": "enhancing-gemini-live-voice-control-a-comprehensive-enhancement-strategy-zbuqdp", "title": "Enhancing Gemini Live Voice Control: A Comprehensive Enhancement Strategy", "slug": "enhancing-gemini-live-voice-control-a-comprehensive-enhancement-strategy", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/GEMINI_ENHANCEMENTS.md", "extension": "md", "score": 38, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The current Gemini Live voice control system achieves exceptional performance with 80ms latency and 98% accuracy, but there exist numerous opportunities for enhancement across architectural, functional, and experiential dimensions. This document presents a comprehensive enhancement strategy organized into five tiers: immediate optimizations that could be implemented within hours, short-term improvements requiring days of work, medium-term architectural enhancements spanning weeks, long-term transformative additions", "excerpt": "The current Gemini Live voice control system achieves exceptional performance with 80ms latency and 98% accuracy, but there exist numerous opportunities for enhancement across architectural, functional, and experiential dimensions. This document presents a comprehensive enhancement strategy organized into five tiers: immediate optimizations that could be implemented within hours, short-term improvements requiring days of work, medium-term architectural enhancements spanning weeks, long-term transformative additions requiring months, and visionary moonshot ideas that would redefine what voice control means for DJ performance.\n\nThe current system employs a fixed 800-millisecond buffer timeout to aggregate Gemini's streaming responses. This conservative value ensures completeness but sacrifices responsiveness. An adaptive buffering strategy could analyze the content and confidence of incoming fragments to determine when a response is sufficiently complete. For instance, if Gemini returns a fragment that forms a complete, high-confidence match to a known command pattern, the system could immediately process it without waiting for the full timeout. This would reduce latency for simple, unambiguous commands while maintaining the full timeout for complex or uncertain utterances.\n\nThe implementation would involve enhancing the GeminiVoiceListener's buffer management to maintain a running analysis of fragment completeness. When a fragment arrives, the system would check if it matches any complete command in the catalog with high confidence. If so, and if no additional fragments have arrived within a short grace period of perhaps 100 milliseconds, the system would flush the buffer early. This optimization could reduce effective latency from 80ms to as low as 50ms for common commands while maintaining accuracy for complex phrases.\n\nThe current system provides functional error messages but could offer more actionable guidance. When Gemini fails to recognize speech, the system currently remains silent or prints a generic \"no match\" message. Enhanced error handling would provide context-specific suggestions based on the failure mode. If the utterance was too short, the system could prompt \"Command too brief, try saying the full phrase.\" If the embedding search returned low-confidence matches, it could suggest \"Did you mean [top match]?\" allowing the user to confirm or reject. If a deck identifier was missing, it could default intelligently and confirm: \"Assuming left deck, say 'right' to override.\"\n\nThis enhancement requires adding failure classification logic to the command matching pipeline and maintaining a library of helpful prompts. The benefit extends beyond usability to serve as a training mechanism, teaching users the system's expected command vocabulary t", "htmlHref": "/research/html/enhancing-gemini-live-voice-control-a-comprehensive-enhancement-strategy-zbuqdp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3935 }, { "id": "cc-protocol-technical-documentation-sxe5an", "title": "CC-Protocol Technical Documentation", "slug": "cc-protocol-technical-documentation", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/04-reference/PROTOCOL.md", "extension": "md", "score": 38, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "CC-Protocol is a unified communication protocol designed for the Computational Choreography system. It provides standardized message formats for real-time sensor data streaming, latent state visualization, and control commands across distributed devices and services. The protocol enables seamless integration between iOS devices capturing motion data and backend services running machine learning models for motion analysis and synthesis.", "excerpt": "CC-Protocol is a unified communication protocol designed for the Computational Choreography system. It provides standardized message formats for real-time sensor data streaming, latent state visualization, and control commands across distributed devices and services. The protocol enables seamless integration between iOS devices capturing motion data and backend services running machine learning models for motion analysis and synthesis.\n\nThe protocol is designed with three primary goals: low-latency real-time communication suitable for interactive applications, flexible extensibility to support new sensor types and message formats, and cross-platform compatibility between Swift/iOS clients and Rust backend services.\n\nThe cc-protocol implements a layered architecture consisting of three main layers. The application layer contains domain-specific logic such as motion streaming and visualization services. The protocol layer handles message encoding, decoding, and type-safe serialization. The transport layer provides the underlying communication mechanism, currently supporting WebSocket with planned support for HTTP and UDP.\n\nThis separation of concerns allows the protocol to evolve independently of the transport mechanism. The same message structures can be transmitted over different transports depending on the requirements of latency, reliability, and bandwidth.\n\nEvery message transmitted through cc-protocol is wrapped in a NetworkMessage envelope. This envelope provides essential metadata for routing, delivery guarantees, and message ordering. The NetworkMessage structure contains a protocol version string identifying the protocol revision (currently \"0.1.0\"), a unique 64-bit message identifier for tracking and acknowledgment, a microsecond-precision timestamp indicating when the message was created, sender and optional target identifiers for routing, the message payload itself, a priority value from 0 to 255 where 0 represents highest priority, a boolean flag indicating whether acknowledgment is required, and an optional reply-to field linking responses to their originating messages.", "htmlHref": "/research/html/cc-protocol-technical-documentation-sxe5an.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3594 }, { "id": "audio-segmentation-1ljokgm", "title": "Audio Segmentation", "slug": "audio-segmentation", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/LearnNKo/docs/architecture/06-audio-segments.md", "extension": "md", "score": 38, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. **Align speech to slides** - Link what's spoken to what's shown 2. **Enable transcription** - Future ASR to get spoken text 3. **Build curriculum** - Audio explanations paired with visual content 4. **Pronunciation training** - Native speaker audio for learners", "excerpt": "This document describes the audio extraction and segmentation system for future ASR integration.\n\nN'Ko educational videos contain spoken explanations alongside visual slides. By extracting and segmenting audio:\n\n1. **Align speech to slides** - Link what's spoken to what's shown 2. **Enable transcription** - Future ASR to get spoken text 3. **Build curriculum** - Audio explanations paired with visual content 4. **Pronunciation training** - Native speaker audio for learners\n\n| Component | Calculation | Cost | |-----------|-------------|------| | Audio extraction | FFmpeg (local) | $0 | | Audio storage | ~500 MB total | ~$0.01/month | | Whisper API | 522 × 60 min × $0.006 | $188 |", "htmlHref": "/research/html/audio-segmentation-1ljokgm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 887 }, { "id": "sea-0-2-complete-1bk33d0", "title": "SEA-0.2-COMPLETE", "slug": "sea-0-2-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-0.2-COMPLETE.md", "extension": "md", "score": 38, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| Metric | Value | Target | Verdict | |--------|-------|--------|---------| | Model available | MiniMax-M2.5 (229B, TQ1_0) | running | **PASS** | | Mean latency (production) | 3,834ms | <5,000ms | **PASS** | | P50 latency | 3,449ms | <5,000ms | **PASS** | | P95 latency | 6,381ms | <5,000ms | **FAIL** (low-relevance only) | | Scoring discrimination | 0.90 vs 0.10 | clear separation | **PASS** | | Full pipeline P50 | ~3.7s | <30s | **PASS** | | JSON output quality | valid, well-structured | parseable | **PASS** |", "excerpt": "## Summary Benchmarked MiniMax scoring latency against the live MiniMax-M2.5 endpoint at localhost:18080. Ran 30 scoring calls (20 throughput + 10 production-realistic) using the actual SEA Tier 2 activation-judge prompt template across 4 skill profiles and 20 test messages. Mean latency is 3.8s (P50: 3.4s) per scoring call with 500 max_tokens. Scoring quality is exceptional — 0.90 mean for relevant messages vs 0.10 for irrelevant. Full pipeline estimate (embedding + scoring + delivery) is ~3.7s P50, well within the 30s SLO. **Verdict: GO.**\n\n## Changes - File: `phase0-results.md` — replaced \"UNREACHABLE\" placeholder with full benchmark data (model details, 2 benchmark runs, scoring quality, viability assessment, go/no-go matrix, revised latency budget) - File: `benchmark_minimax_scoring.py` — created benchmark script (20-call latency test with SEA scoring prompt template) - File: `benchmark_results.json` — raw benchmark data (all 20 runs with per-call latency, token counts, server timings) - File: `SEA-0.2-COMPLETE.md` — this completion report\n\n| Metric | Value | Target | Verdict | |--------|-------|--------|---------| | Model available | MiniMax-M2.5 (229B, TQ1_0) | running | **PASS** | | Mean latency (production) | 3,834ms | <5,000ms | **PASS** | | P50 latency | 3,449ms | <5,000ms | **PASS** | | P95 latency | 6,381ms | <5,000ms | **FAIL** (low-relevance only) | | Scoring discrimination | 0.90 vs 0.10 | clear separation | **PASS** | | Full pipeline P50 | ~3.7s | <30s | **PASS** | | JSON output quality | valid, well-structured | parseable | **PASS** |\n\n### Important Discovery: Model Change The endpoint serves **MiniMax-M2.5** (229B params), not the originally spec'd MiniMax-3B-v0.1. This is a much more capable reasoning model with chain-of-thought output. Implications: - Scoring quality is excellent (the model reasons about relevance before scoring) - Latency is higher than a 3B model (~3.8s vs estimated ~200-500ms for 3B) - For async Tier 2 use, this is acceptable — user already has the main response - If latency becomes a concern, a 3B model could be added on a separate port\n\n### Production Notes 1. `max_tokens: 500` needed for full reasoning + JSON output 2. JSON parser must handle markdown-fenced output (`` ``) 3. Low-relevance messages take longer (~6s) but don't generate injections 4. Pre-warm recommended to avoid cold-start penalties", "htmlHref": "/research/html/sea-0-2-complete-1bk33d0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 447 }, { "id": "sea-1-2-complete-1viwxmj", "title": "SEA-1.2-COMPLETE", "slug": "sea-1-2-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-1.2-COMPLETE.md", "extension": "md", "score": 38, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Related pairs (>0.5):** | Pair | Score | Status | |------|-------|--------| | phi:veritas ↔ phi:paradox | 0.5485 | PASS | | phi:paradox ↔ phi:metaphysical | 0.6363 | PASS | | art:creative ↔ art:divergent | 0.6680 | PASS | | art:convergent ↔ art:divergent | 0.7747 | PASS | | art:creative ↔ art:synthesis | 0.7902 | PASS | | nav:nonlinear ↔ nav:perspective | 0.5323 | PASS |", "excerpt": "## Summary Built the SEA Embedding Indexer at `[home-path]`. The script embeds all 13 SEA skill entity SKILL.md files via Mac4 Ollama all-minilm model (384-dim) and caches the result as a 13x384 numpy array at `[home-path]`. Includes `load_embeddings()` utility, `query_similar()` for runtime skill matching, and cosine similarity validation tests — all passing.\n\n## Changes - File: `[home-path]` — created (315 lines) - `extract_skill_text()` — reads SKILL.md, extracts YAML description + body with category label - `call_ollama_embedding()` — calls Ollama API at `http://[ip]:11434/api/embeddings` - `build_embeddings()` — embeds all 13 skills, returns 13x384 matrix - `save_cache()` / `load_embeddings()` — .npz I/O with metadata - `cosine_similarity()` — pairwise vector comparison - `query_similar()` — runtime skill retrieval (embed query → rank against cache) - `run_similarity_tests()` — validates related (>0.5) and unrelated (<0.4) thresholds - CLI modes: default (build), `--test`, `--info`, `--query \"text\"` - File: `[home-path]` — created (63.3 KB)\n\n**Related pairs (>0.5):** | Pair | Score | Status | |------|-------|--------| | phi:veritas ↔ phi:paradox | 0.5485 | PASS | | phi:paradox ↔ phi:metaphysical | 0.6363 | PASS | | art:creative ↔ art:divergent | 0.6680 | PASS | | art:convergent ↔ art:divergent | 0.7747 | PASS | | art:creative ↔ art:synthesis | 0.7902 | PASS | | nav:nonlinear ↔ nav:perspective | 0.5323 | PASS |\n\n**Unrelated pairs (<0.4):** | Pair | Score | Status | |------|-------|--------| | phi:veritas ↔ art:dj | 0.2937 | PASS | | phi:metaphysical ↔ art:snark | 0.2201 | PASS | | art:movement ↔ phi:paradox | 0.2703 | PASS | | nav:nonlinear ↔ art:snark | 0.1723 | PASS |\n\n### Query Validation Query \"What is truth and wisdom?\" → #1 phi:veritas (0.5049) ✅", "htmlHref": "/research/html/sea-1-2-complete-1viwxmj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 543 }, { "id": "sea-4-3-complete-1556pwb", "title": "SEA-4.3-COMPLETE", "slug": "sea-4-3-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-4.3-COMPLETE.md", "extension": "md", "score": 38, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Workspace document requiring curation.", "excerpt": "## Summary Implemented the `/skill reset` command in `skill_controller.py`. The reset command wipes a skill's `activation-log.jsonl` and restores `state.json` to factory defaults (zeroed counters, re-seeded hot/cold topics from SKILL.md, cleared mute status). Includes interactive confirmation prompt (skippable with `--confirm`), JSON output mode, and pre-reset stats in the response.\n\n## Changes - File: `[home-path]` — modified - Added `SEED_TOPICS` constant (13 skills × hot/cold topic lists from SEA-1.1) - Added `DEFAULT_CONTEXT_WINDOW` and `DEFAULT_CONFIDENCE_CALIBRATION` constants - Added `build_default_state()` helper to construct factory-default state.json - Added `reset_skill()` function: captures pre-reset snapshot, writes fresh state, truncates log - Added `reset` CLI subcommand with `--confirm`/`-y` and `--json` flags - Cleaned up unused imports (`os`, `time`) - Updated docstring to reflect SEA-4.2 + SEA-4.3 - File: `CREATIVE_EVOLUTION_SEA_v1.md` — updated task 4.3 status to Complete\n\n## RTD Verification - [x] Structure: all files present, no new files created outside completion report - [x] Compilation: `py_compile` passes, `--help` renders correctly - [x] Integration: extends existing `skill_controller.py` patterns (load_state/save_state/log_event), no broken refs - [x] Content: reset wipes log, restores state.json to exact SEA-1.1 defaults, clears mute fields - [x] User Journey: tested reset on `phi:veritas` (clean), `art:snark` (clean), `nav:organic` (mute→reset clears mute) - [x] Deployment: committed", "htmlHref": "/research/html/sea-4-3-complete-1556pwb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 355 }, { "id": "sea-re-embedding-complete-topic-augmented-embeddings-1ie5s7u", "title": "SEA Re-Embedding Complete — Topic-Augmented Embeddings", "slug": "sea-re-embedding-complete-topic-augmented-embeddings", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-REEMBED-COMPLETE.md", "extension": "md", "score": 38, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Re-embedded all 13 skill entities with topic-augmented text for improved Tier 1 matching. The core problem was that embeddings were generated from raw SKILL.md content (technique descriptions, markdown formatting) which sits in a different semantic space than user queries. Fix: restructure embedding text to be query-dominant.", "excerpt": "Re-embedded all 13 skill entities with topic-augmented text for improved Tier 1 matching. The core problem was that embeddings were generated from raw SKILL.md content (technique descriptions, markdown formatting) which sits in a different semantic space than user queries. Fix: restructure embedding text to be query-dominant.\n\n**Before:** `\"{skill_name}: {yaml_description}\\n{skill_md_body}\"` truncated to 800 chars. The body was SKILL.md markdown — technique instructions, not user query language.\n\n**After:** Query-dominant structure (~70% example queries, ~20% hot topics, ~10% description):\n\nNew components: - `_load_skill_topics()` — reads `hot_topics` and `cold_topics` from each skill's `state.json` - `SKILL_EXAMPLE_QUERIES` — 7-10 natural-language user queries per skill that should trigger that skill - SKILL.md body stripped — only the YAML `description:` field is kept (body was semantic noise) - Budget increased from 800 to 1200 chars to accommodate richer text\n\n**Before:** `get_sea_skill_patterns()` (lines 397-411, used by spawner.py) was missing patterns that existed in `_keyword_fallback()` (lines 153-167):", "htmlHref": "/research/html/sea-re-embedding-complete-topic-augmented-embeddings-1ie5s7u.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 791 }, { "id": "deployment-guide-o576jc", "title": "Deployment Guide", "slug": "deployment-guide", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "agent-reputation/docs/DEPLOYMENT_GUIDE.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Requirement | Minimum | Recommended | |-------------|---------|-------------| | Node.js | v18.x | v20.x+ | | Python | 3.9+ | 3.11+ | | RAM | 1 GB | 4 GB | | Storage | 100 MB | 1 GB (with history) |", "excerpt": "| Requirement | Minimum | Recommended | |-------------|---------|-------------| | Node.js | v18.x | v20.x+ | | Python | 3.9+ | 3.11+ | | RAM | 1 GB | 4 GB | | Storage | 100 MB | 1 GB (with history) |\n\n| Variable | Default | Description | |----------|---------|-------------| | `INITIAL_BALANCE` | 1000 | Starting credits for new agents | | `INITIAL_PRICE` | 50 | Default market price (0-100) | | `CASCADE_THRESHOLD` | 0.7 | Herding detection (70%) | | `INHERITANCE_RATIO` | 0.5 | Default hereditary ratio (50%) | | `MARKET_MAKER_SPREAD` | 0.02 | AMM spread (2%) |\n\nThe current implementation is **in-memory only**. For production, add persistence.\n\n- [ ] Install dependencies (`npm install`) - [ ] Configure environment variables - [ ] Set up persistence (SQLite/Redis/PostgreSQL) - [ ] Add authentication middleware - [ ] Configure rate limiting - [ ] Set up logging - [ ] Add health check endpoint - [ ] Configure Prometheus metrics - [ ] Run integration tests - [ ] Deploy to staging - [ ] Smoke test all endpoints - [ ] Deploy to production\n\n- **Issues:** Open GitHub issue - **Documentation:** See `/docs/` folder - **API Reference:** See inline TSDoc/docstrings", "htmlHref": "/research/html/deployment-guide-o576jc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1248 }, { "id": "cc-anticipation-implementation-guide-ojls95", "title": "cc-anticipation: Implementation Guide", "slug": "cc-anticipation-implementation-guide", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "anticipation-geometry/crates/anticipation/docs/IMPLEMENTATION_GUIDE.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` cc-anticipation/ ├── Cargo.toml ├── src/ │ ├── lib.rs # Public API, re-exports │ ├── types.rs # MotionWindow, AnticipationPacket, etc. │ ├── config.rs # AnticiaptionConfig (frozen) │ ├── kernel.rs # Main anticipation kernel │ ├── features/ │ │ ├── mod.rs │ │ ├── kinematics.rs # Skeleton-based features │ │ ├── latent_dynamics.rs # LIM-RPS-based features │ │ └── coordination.rs # Cross-limb coherence │ ├── embedding/ │ │ ├── mod.rs │ │ ├── projection.rs # Fixed random projection (v0) │ │ └── encoder.rs # Learned ", "excerpt": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Parent**: [PROJECT_CHARTER.md](./PROJECT_CHARTER.md)", "htmlHref": "/research/html/cc-anticipation-implementation-guide-ojls95.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2857 }, { "id": "cognitivehire-divergent-rail-execution-plan-aa2gmw", "title": "CognitiveHire -- Divergent Rail Execution Plan", "slug": "cognitivehire-divergent-rail-execution-plan", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "cognitive-hire/docs/execution-plan.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Generated: 2026-03-27 > Protocol: Divergent Rail (EW-governed parallel execution) > Project: `[home]/Desktop/cognitive-hire/` > North Star: Mohamed Diomande -- 112K+ AI turns, KARL adapter, RAG++ 332K rows", "excerpt": "> Generated: 2026-03-27 > Protocol: Divergent Rail (EW-governed parallel execution) > Project: `[home]/Desktop/cognitive-hire/` > North Star: Mohamed Diomande -- 112K+ AI turns, KARL adapter, RAG++ 332K rows\n\n| Source | Location | Size | Format | |--------|----------|------|--------| | Prompt logs | `[home-path]` | 3.4GB, 6099 lines | JSONL | | Supabase prompts | `claude_prompts` table | 112K+ rows | SQL (prompt_text, tags, complexity_score, intent_classification, tokens, timing, git context) | | Supabase turns | `claude_assistant_turns` table | N x turns per prompt | SQL (content_text, thinking_text, tool_calls, model_id) | | Supabase tools | `claude_tool_calls` table | tool_name, tool_input, duration_ms, success | SQL | | Supabase diffs | `claude_file_diffs` table | file_path, action, lines_added/removed, unified_diff | SQL | | Supabase daily | `claude_daily_summaries` table | Materialized daily stats | SQL | | RAG++ embeddings | `memory_turns` table | 332K rows, 768-dim (text-embedding-3-small) | pgvector | | KARL trajectories | `[home-path]` | 121+ trajectories, 72 skill-labeled, 11 domains | JSON/PKL | | KARL config | `[home-path]` | Embedding: gemini-embedding-001 3072-dim via RAG++ :8000 | JSON | | Prompt logger | `[home-path]` | 91 files, analytics.py, mcp_server.py (36 tools) | Python |\n\n> **Gate**: Raw cognitive metrics computed for Mohamed. At least 3 metric types producing non-trivial output from real data. Dashboard skeleton renders locally. > **EW Check**: Invariant 1 (Minimum Entropy). Risk: metrics produce flat/meaningless output from real data. Corrective: swap metric algorithm, not data source.\n\n| Track | Task | Machine | Blocks | EW Role | |-------|------|---------|--------|---------| | Critical | Cognitive metric extraction scripts | Mac1 | Phase 2 (dashboard needs data) | Rail spine | | A | Dashboard scaffold (Next.js + D3/Recharts) | Mac1 | Phase 2 Track Critical (renders metrics) | Divergent organism | | B | ChatGPT/Gemini export parsers | Mac1 | Phase 3 Track A (multi-source ingestion) | Divergent organism | | C | Content: \"Today vs Tomorrow\" script draft | Mac1 | Phase 4 Track B (video production) | Divergent organism |\n\nBuild Python scripts that query Supabase directly and compute 6 cognitive metrics from Mohamed's real data.", "htmlHref": "/research/html/cognitivehire-divergent-rail-execution-plan-aa2gmw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4315 }, { "id": "dep-audit-v2-trajectory-search-1a1lr2u", "title": "DEP Audit V2 — Trajectory Search", "slug": "dep-audit-v2-trajectory-search", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/trajectory/trajectory-search/docs/DEP-AUDIT-V2.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date**: 2025-07-14 **Version**: 0.2.0 (changelog says 0.3.0 unreleased) **Stack**: Tauri v2 + React 19 + TypeScript 5.9 + Vite 7 **Scale**: 293 source files, ~42,253 lines TypeScript frontend, ~6,839 lines Rust backend", "excerpt": "**Date**: 2025-07-14 **Version**: 0.2.0 (changelog says 0.3.0 unreleased) **Stack**: Tauri v2 + React 19 + TypeScript 5.9 + Vite 7 **Scale**: 293 source files, ~42,253 lines TypeScript frontend, ~6,839 lines Rust backend\n\nTrajectory Search is an extraordinarily ambitious application that attempts to be a universal desktop UI for the entire CompCore/OpenClaw ecosystem. The breadth of features is impressive — 20+ views, motion choreography, 3D visualization, AI agent orchestration, calendar, notes, dream generation, research browser, terminal emulation, and more. But the codebase has outpaced its ability to compile, test, or ship. It's a prototype masquerading as a product.\n\n### TypeScript Strictness - `strict: true` ✅ — good - `noUnusedLocals: true` ✅ — enforced but violated 70+ times - `noUnusedParameters: true` ✅ — enforced but violated - `erasableSyntaxOnly: true` ✅ — blocks enum syntax in 2 files - `verbatimModuleSyntax: true` ✅\n\nThe tsconfig is strict, which is the right call. But the codebase doesn't comply with its own config. **156 TypeScript errors** currently (up from 127 in the handoff doc — regression).\n\n### Error Breakdown | Category | Count | Severity | |----------|-------|----------| | Missing type properties (TS2739) | ~30 | Medium — test fixtures & conflict detector | | Property doesn't exist (TS2339) | ~15 | Medium — type drift | | Unused variables (TS6133) | ~25 | Low — cleanup | | Type assignment mismatch (TS2322) | ~12 | Medium — string/number confusion | | Unused type declarations (TS6196) | ~8 | Low | | Argument type mismatch (TS2345) | ~15 | Medium — ConflictResolutionSuggestion | | Missing exports (TS2305) | ~3 | Medium — LatentState/MotionDescriptor | | erasableSyntaxOnly (TS1294) | 2 | Low — pulse enum syntax | | Implicit any (TS7053) | ~3 | Medium | | Other | ~43 | Mixed |", "htmlHref": "/research/html/dep-audit-v2-trajectory-search-1a1lr2u.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2769 }, { "id": "evo-cubed-trajectory-search-evolution-plan-1nqujwz", "title": "Evo Cubed — Trajectory Search Evolution Plan", "slug": "evo-cubed-trajectory-search-evolution-plan", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/trajectory/trajectory-search/docs/EVO3.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date**: 2025-07-14 **Baseline**: DEP Audit V2 (5.2/10 overall health) **Target**: Universal UI for the OpenClaw/CompCore stack **Timeline**: Evo 1 (1-2 weeks) → Evo 2 (3-4 weeks) → Evo 3 (ongoing)", "excerpt": "**Date**: 2025-07-14 **Baseline**: DEP Audit V2 (5.2/10 overall health) **Target**: Universal UI for the OpenClaw/CompCore stack **Timeline**: Evo 1 (1-2 weeks) → Evo 2 (3-4 weeks) → Evo 3 (ongoing)\n\n**Goal**: Clean build, zero TypeScript errors, no dead code, all views either functional or removed. **Target Health**: 7.0/10\n\n#### Phase 1A: Quick Wins (~40 errors, ~30 min) - [ ] Remove unused imports across all files (lucide-react icons: Lock, Shield, Server, Radio, Network, etc.) - [ ] Remove unused variables: `lowerText` (3x in nlp-patterns.ts), `fullContent` (2x in parser.ts), `headerPassed`, `parseEntityStatus`, `highPriority`, `currentWeight`, `state` (glass-shatter.ts) - [ ] Remove unused type imports: `TemplateInstance`, `TemplateCategory`, `EnergyLevel`, `Idea` (2x) - [ ] Prefix intentionally unused params with `_` where removal would break signatures\n\n#### Phase 1B: Calendar Test Fixtures (~34 errors, ~1 hour) - [ ] `lib/calendar/__tests__/template-engine.test.ts` — Add missing required properties to all test fixture objects: - `TemplateEventPattern`: add `priority`, `tags`, `is_milestone`, `created_at` - `CalendarEvent`: add `all_day`, `tags`, `agent_suggested`, `created_at`, `updated_at` - `CalendarTemplate`: add `created_at`, `updated_at` - [ ] Fix `.length` on number type (lines 278-279, 342-343) — likely `events_created` vs `generated_event_ids` - [ ] Fix `conflicts_detected` property access — use correct TemplateApplicationResult property - [ ] Fix implicit any indexing on Number type\n\n#### Phase 1C: Conflict Detector (~9 errors, ~45 min) - [ ] `lib/calendar/conflict-detector.ts` — Fix all `ConflictResolutionSuggestion` argument mismatches: - Add `type` and `description` properties to all suggestion objects (6 instances) - Map `action` string to the `type` union: `'reschedule' | 'shorten' | 'cancel' | 'adjust_priority'` - [ ] Fix iterator on `CalendarEvent[] | undefined` — add null check or default - [ ] Remove unused `highPriority` variable", "htmlHref": "/research/html/evo-cubed-trajectory-search-evolution-plan-1nqujwz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3338 }, { "id": "phase-3-live-performance-guide-1htchcm", "title": "Phase 3: Live Performance Guide", "slug": "phase-3-live-performance-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/gesture_control/live_performance.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Phase 3** enables real-time gesture control for live DJ performance. Train once (Phase 2), then perform with sub-100ms latency gesture recognition.", "excerpt": "**Phase 3** enables real-time gesture control for live DJ performance. Train once (Phase 2), then perform with sub-100ms latency gesture recognition.\n\n1. ✅ **Trained gestures** (Phase 2) 2. ✅ **Phone with Sensor Logger** connected 3. ✅ **DJ software** running (Rekordbox, Serato, etc.)\n\n**Features:** - Sliding window analysis (1 second windows, 50% overlap) - Gesture debouncing (200ms cooldown) - Confidence filtering (>70%) - Performance monitoring (latency, accuracy)\n\n**Performance:** - Recognition rate: **10 Hz** (analyzes 10 times per second) - End-to-end latency: **20-60ms** - False positive rate: **<5%**\n\n#### macOS 1. Open **Audio MIDI Setup** 2. Window → Show MIDI Studio 3. Create **IAC Driver** (Inter-Application Communication) 4. Enable \"Device is online\"", "htmlHref": "/research/html/phase-3-live-performance-guide-1htchcm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1534 }, { "id": "gesture-control-system-production-deployment-guide-efpp9a", "title": "Gesture Control System - Production Deployment Guide", "slug": "gesture-control-system-production-deployment-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/gesture_control/production_deployment.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This guide covers deploying the production-grade gesture control system with enterprise features including auto-recovery, monitoring, and performance optimization.", "excerpt": "This guide covers deploying the production-grade gesture control system with enterprise features including auto-recovery, monitoring, and performance optimization.\n\n#### **Phase 1: Data Acquisition** - `sensor_logger_bridge_production.py` - Sensor streaming with auto-reconnection - `gemini_video_analyzer_production.py` - Video analysis with adaptive FPS\n\n#### **Phase 2: Training & Recognition** - `gesture_database_production.py` - Template storage with versioning - `gesture_recorder_production.py` - Recording with auto-save - `gesture_recognizer_production.py` - Recognition with caching - `training_ui_production.py` - Interactive training interface\n\n#### Auto-Reconnection - **Exponential backoff**: 1s → 2s → 4s → 8s → ... → 60s max - **Connection state tracking**: DISCONNECTED, CONNECTING, CONNECTED, RECONNECTING, FAILED - **Automatic recovery** from network interruptions\n\n#### Data Persistence - **Transaction-based saves** with atomic writes - **Automatic backups** every 5 minutes - **Session recovery** after crashes - **Database corruption detection** and rollback", "htmlHref": "/research/html/gesture-control-system-production-deployment-guide-efpp9a.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1510 }, { "id": "production-migration-guide-1hmbpkz", "title": "Production Migration Guide", "slug": "production-migration-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/gesture_control/production_migration.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**New Features:** - ✅ Auto-reconnection with exponential backoff - ✅ Connection state management (enum-based) - ✅ Sensor calibration (remove bias/drift) - ✅ Data validation and sanitization - ✅ Performance metrics tracking - ✅ Quality indicators for readings - ✅ Comprehensive error handling", "excerpt": "This guide covers migrating from prototype/basic implementations to production-grade components with zero data loss.\n\n**New Features:** - ✅ Auto-reconnection with exponential backoff - ✅ Connection state management (enum-based) - ✅ Sensor calibration (remove bias/drift) - ✅ Data validation and sanitization - ✅ Performance metrics tracking - ✅ Quality indicators for readings - ✅ Comprehensive error handling\n\n**New Features:** - ✅ Connection retry logic with backoff - ✅ Adaptive FPS control (1-10 FPS based on latency) - ✅ Frame quality assessment (blur + brightness) - ✅ Batch optimization for API calls - ✅ State management (STOPPED, RUNNING, ERROR, etc.) - ✅ Performance metrics tracking\n\n**New Features:** - ✅ Atomic transaction-based saves - ✅ Database corruption detection & recovery - ✅ Template versioning system - ✅ Automatic backups (timestamped) - ✅ Data validation with physical plausibility checks - ✅ Cross-validation for accuracy measurement - ✅ Outlier detection and removal - ✅ Consistency scoring - ✅ Thread-safe operations - ✅ Template export/import\n\n**Breaking Changes:** - `SensorFeatures` now has `validate()` method - `GestureTemplate` has additional fields: `version`, `consistency_score`, etc. - Database now creates `backups/` subdirectory", "htmlHref": "/research/html/production-migration-guide-1hmbpkz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1651 }, { "id": "production-grade-gesture-control-system-implementation-summary-r391j", "title": "Production-Grade Gesture Control System - Implementation Summary", "slug": "production-grade-gesture-control-system-implementation-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/gesture_control/production_summary.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The gesture control system has been upgraded from prototype to **production-grade enterprise software** with comprehensive error handling, automatic recovery, performance optimization, and monitoring capabilities.", "excerpt": "The gesture control system has been upgraded from prototype to **production-grade enterprise software** with comprehensive error handling, automatic recovery, performance optimization, and monitoring capabilities.\n\n**Key Achievements:** - ✅ **Zero data loss** through atomic transactions and automatic backups - ✅ **Automatic recovery** from network failures, crashes, and corruption - ✅ **50% faster recognition** through template caching and optimization - ✅ **Comprehensive monitoring** with real-time performance dashboards - ✅ **Enterprise reliability** with state management and error handling\n\n**Enterprise Features Added:** - Auto-reconnection with exponential backoff (1s → 60s) - Connection state management (DISCONNECTED, CONNECTING, CONNECTED, RECONNECTING, FAILED) - Sensor calibration to remove bias and drift (100-sample calibration) - Data validation for physical plausibility - Performance monitoring (reading rate, latency, buffer usage, quality indicators) - Comprehensive error handling and logging\n\n**Key Metrics:** - Reading validation: 99%+ accuracy - Reconnection success: 95%+ - Calibration time: <5 seconds - Memory footprint: Circular buffer (100 readings max)\n\n**Enterprise Features Added:** - Connection retry logic with exponential backoff - Adaptive FPS control (1-10 FPS based on API latency) - Frame quality assessment (blur detection via Laplacian, brightness checks) - Batch optimization for API efficiency - State management (STOPPED, INITIALIZING, RUNNING, PAUSED, ERROR) - Performance metrics tracking (API response times, frame processing)", "htmlHref": "/research/html/production-grade-gesture-control-system-implementation-summary-r391j.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2287 }, { "id": "gesture-training-system-complete-guide-134331h", "title": "Gesture Training System - Complete Guide", "slug": "gesture-training-system-complete-guide", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/gesture_control/training_system.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The **Gesture Training System** allows you to record, practice, and refine gesture patterns for high-accuracy recognition. Think of it like **training a muscle memory** - the more you practice, the better the system recognizes your unique gestures.", "excerpt": "The **Gesture Training System** allows you to record, practice, and refine gesture patterns for high-accuracy recognition. Think of it like **training a muscle memory** - the more you practice, the better the system recognizes your unique gestures.\n\n### 1. **Gesture Database** (`gesture_database.py`) - Stores trained gesture templates - Manages training samples - Computes statistical features (mean, std)\n\n### 2. **Gesture Recorder** (`gesture_recorder.py`) - Captures sensor + video data - Extracts features from raw data - Saves training samples\n\n### 3. **Gesture Recognizer** (`gesture_recognizer.py`) - Matches live gestures to templates - Calculates similarity scores - Provides feedback for improvement\n\n### 4. **Training UI** (`training_ui.py`) - Interactive interface for training - Practice mode with real-time feedback - Progress tracking and statistics", "htmlHref": "/research/html/gesture-training-system-complete-guide-134331h.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1648 }, { "id": "dj-agent-motion-driven-auto-dj-1x65ewv", "title": "DJ Agent - Motion-Driven Auto-DJ", "slug": "dj-agent-motion-driven-auto-dj", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/README.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A tiered, beat-quantized agent that translates DELL equilibria outputs into safe, musical Serato/SuperCollider control actions.", "excerpt": "A tiered, beat-quantized agent that translates DELL equilibria outputs into safe, musical Serato/SuperCollider control actions.\n\n### What's Ready Now ✅ Complete runtime infrastructure ✅ All 6 tiers defined (50+ actions) ✅ Safety masks and beat quantization ✅ MIDI/keyboard bridge ✅ Reflex + Planner policies ✅ Training pipeline ✅ Evaluation metrics ✅ Wired into Studio runtime engine\n\n| Mode | Behavior | Use Case | |------|----------|----------| | **Ghost** | Prints recommendations only | Safe preview, debugging | | **Assist** | Executes with gesture confirmation | Collaborative performance | | **Auto** | Autonomous (Tier 0-3 only) | Hands-free operation |\n\n| Tier | Category | Actions | Status | |------|----------|---------|--------| | **0** | Transport | PLAY, SYNC, NUDGE | ✅ Enabled | | **1** | Looping | SET_LOOP, DOUBLE/HALVE | ✅ Enabled | | **2** | Cues | SET_CUE, JUMP_TO_CUE | ✅ Enabled | | **3** | FX | FX_TOGGLE, ECHO_TAP | ✅ Enabled | | **4** | Library | LOAD, LIB_MOVE | ⏸️ Disabled | | **5** | Blend | CROSSFADER, EQ, SAMPLE | ⏸️ Disabled |\n\n✅ **Lock Playing Deck**: Never STOP/LOAD on live deck ✅ **Beat Quantization**: Actions fire only at |ψ| ≤ 15° ✅ **Cooldown Management**: 1-16 beats depending on action ✅ **Action Masks**: Context-dependent permissions ✅ **Smooth Transitions**: Exponential smoothing (α=0.3) ✅ **CPU Headroom**: Max 2 FX per deck ✅ **EQ Limits**: ≤ 6 dB change per beat", "htmlHref": "/research/html/dj-agent-motion-driven-auto-dj-1x65ewv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1226 }, { "id": "video-analyzer-infrastructure-deployment-handoff-1fv6f5m", "title": "Video Analyzer Infrastructure - Deployment Handoff", "slug": "video-analyzer-infrastructure-deployment-handoff", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/backend/cc-music-pipeline/ANALYZER_HANDOFF.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- ✅ Core crates (`cc-stream`, `cc-gemini`) are copied into build context - ✅ Analyzer crate is included in workspace build - ✅ Proper dependency caching with stub files - ✅ Runtime includes FFmpeg and all required tools", "excerpt": "All infrastructure and backend implementation is complete. The analyzer is ready for Cloud Run deployment.\n\n- ✅ Core crates (`cc-stream`, `cc-gemini`) are copied into build context - ✅ Analyzer crate is included in workspace build - ✅ Proper dependency caching with stub files - ✅ Runtime includes FFmpeg and all required tools\n\n- ✅ GEMINI_API_KEY configured as Secret Manager secret - ✅ Analyzer environment variables set - ✅ Memory increased to 4Gi (for video processing) - ✅ Timeout set to 3600s (1 hour for long videos)\n\n**Prerequisites** (already documented in cloudbuild.yaml): 1. Create [sensitive field redacted]`gcloud secrets create GEMINI_API_KEY --replication-policy=\"automatic\"` 2. Add secret value: `echo -n \"YOUR_API_KEY\" | gcloud secrets versions add GEMINI_API_KEY --data-file=-` 3. Grant access to Cloud Run service account\n\n**Files Modified**: - ✅ `crates/server/Cargo.toml` - Added `music-pipeline-analyzer` dependency - ✅ `crates/server/src/main.rs` - Added analyzer routes and SSE streaming - ✅ `crates/analyzer/src/frontend.rs` - Created (460+ lines of conversion functions) - ✅ `crates/analyzer/src/lib.rs` - Exports frontend module", "htmlHref": "/research/html/video-analyzer-infrastructure-deployment-handoff-1fv6f5m.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1818 }, { "id": "topological-preference-optimization-tpo-lvmpgo", "title": "Topological Preference Optimization (TPO)", "slug": "topological-preference-optimization-tpo", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/tpo/README.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A novel training strategy for conversational AI that leverages conversation topology and spatial-temporal coordinates to generate preference datasets.", "excerpt": "A novel training strategy for conversational AI that leverages conversation topology and spatial-temporal coordinates to generate preference datasets.\n\nTPO represents a paradigm shift in preference learning for conversational AI. Instead of relying on human annotations, TPO extracts preference signals directly from the structural properties of conversation graphs, incorporating hindsight knowledge and topological awareness to create more accurate and contextually informed training data.\n\n> **Conversation topology encodes preference signals**: Linear conversation paths represent more effective communication than branching paths, as they indicate confident, purposeful progression rather than uncertain exploration.\n\n### 1. Divergent Language Matrix (DLM) Integration TPO builds upon the DLM algorithm to generate 5-dimensional coordinates `[X, Y, Z, T, N]` for each message: - **X (depth_x)**: Hierarchical level/depth - **Y (sibling_y)**: Order among siblings - **Z (sibling_count_z)**: Homogeneity based on sibling count and similarity - **T (time_t)**: Temporal position with dynamic weighting - **N (n_parts)**: Content segmentation count\n\nWhere: - `L(P)`: Linearity score (prefers straight-line conversations) - `T(P)`: Terminal quality (endpoint assessment) - `S(P)`: Semantic coherence (consistency along path) - `C(P)`: Completion quality (accounts for backtracks)", "htmlHref": "/research/html/topological-preference-optimization-tpo-lvmpgo.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1105 }, { "id": "phase-4-complete-rehearsal-trajectory-integration-tkmcqc", "title": "🎉 Phase 4 Complete: Rehearsal Trajectory Integration", "slug": "phase-4-complete-rehearsal-trajectory-integration", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/PHASE_4_COMPLETE.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Phase 4 integrates **computational rehearsal** - the system now predicts future movement and makes proactive musical decisions rather than just reacting to the present moment.", "excerpt": "**Completion Date**: December 20, 2025 **Status**: ✅ **COMPUTATIONAL REHEARSAL OPERATIONAL**\n\nPhase 4 integrates **computational rehearsal** - the system now predicts future movement and makes proactive musical decisions rather than just reacting to the present moment.\n\n**Purpose**: Predict where the dancer's movement is heading and make musical decisions based on the *future*, not just the *present*.\n\n1. **Trajectory Prediction** - Uses `rehearse_trajectory()` from cc-brain - Predicts 2 seconds into the future at 50 Hz (100 future frames) - Computed every 10 sensor frames (~5 Hz) for efficiency - Uses inertial extrapolation with decay (motion naturally slows down)\n\n2. **Future-Aware Section Transitions** - **Anticipatory**: Detects rising tension in trajectory → transitions to \"build\" earlier - **Smoothing**: Requires sustained energy in future → prevents flickering between sections - **Predictive breakdown**: If future shows energy drop → graceful transition to breakdown", "htmlHref": "/research/html/phase-4-complete-rehearsal-trajectory-integration-tkmcqc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2009 }, { "id": "cc-anticipation-implementation-guide-11h0g51", "title": "cc-anticipation: Implementation Guide", "slug": "cc-anticipation-implementation-guide", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/motion/cc-anticipation/docs/IMPLEMENTATION_GUIDE.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` cc-anticipation/ ├── Cargo.toml ├── src/ │ ├── lib.rs # Public API, re-exports │ ├── types.rs # MotionWindow, AnticipationPacket, etc. │ ├── config.rs # AnticiaptionConfig (frozen) │ ├── kernel.rs # Main anticipation kernel │ ├── features/ │ │ ├── mod.rs │ │ ├── kinematics.rs # Skeleton-based features │ │ ├── latent_dynamics.rs # LIM-RPS-based features │ │ └── coordination.rs # Cross-limb coherence │ ├── embedding/ │ │ ├── mod.rs │ │ ├── projection.rs # Fixed random projection (v0) │ │ └── encoder.rs # Learned ", "excerpt": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Parent**: [PROJECT_CHARTER.md](./PROJECT_CHARTER.md)", "htmlHref": "/research/html/cc-anticipation-implementation-guide-11h0g51.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2857 }, { "id": "cc-inscription-nko-inscription-system-3e55gh", "title": "cc-inscription: N'Ko Inscription System", "slug": "cc-inscription-nko-inscription-system", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/core/semantic/cc-inscription/README.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A system that compiles embodied dynamics (z-trajectory) into justified N'Ko statements with cryptographic provenance. Every inscription is traceable to its source evidence through a typed IR pipeline.", "excerpt": "A system that compiles embodied dynamics (z-trajectory) into justified N'Ko statements with cryptographic provenance. Every inscription is traceable to its source evidence through a typed IR pipeline.\n\n- [Overview](#overview) - [Design Philosophy](#design-philosophy) - [Architecture](#architecture) - [The Ten Claim Types](#the-ten-claim-types) - [Core Types](#core-types) - [Basin Lifecycle](#basin-lifecycle) - [Lexicon Versioning](#lexicon-versioning) - [Surface Rendering](#surface-rendering) - [Phrase Emergence](#phrase-emergence) - [Integration Points](#integration-points) - [API Reference](#api-reference) - [Examples](#examples)\n\nThe N'Ko Inscription System transforms continuous motion data (z-trajectory from DELL - Distributed Embodied Latent Learner) into discrete, justified claims expressed in N'Ko script. Each claim:\n\n1. **Has typed structure** - A strongly-typed Intermediate Representation (IR) 2. **Has a sigil** - A single N'Ko character that identifies the claim type 3. **Is traceable** - Links back to the evidence that produced it 4. **Is versioned** - Rendered through a versioned lexicon\n\nN'Ko is a right-to-left African script with rich typographic potential. We use it as a **controlled technical register** where single characters (sigils) serve as operator markers. This keeps the system deterministic and learnable while opening the door to natural-language phrasing as the lexicon matures.", "htmlHref": "/research/html/cc-inscription-nko-inscription-system-3e55gh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2998 }, { "id": "graph-kernel-dep-audit-v2-1uaahjw", "title": "Graph Kernel DEP Audit V2", "slug": "graph-kernel-dep-audit-v2", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/GRAPH-KERNEL-DEP-AUDIT.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**OpenClaw CompCore — Deep Engineering Posture Assessment** **Version:** 2.0.0 · **Date:** 2026-02-14 **Auditor:** Automated Code Analysis + Live Service Inspection **Codebase:** `core/semantic/cc-graph-kernel/` — ~11,241 lines Rust", "excerpt": "**OpenClaw CompCore — Deep Engineering Posture Assessment** **Version:** 2.0.0 · **Date:** 2026-02-14 **Auditor:** Automated Code Analysis + Live Service Inspection **Codebase:** `core/semantic/cc-graph-kernel/` — ~11,241 lines Rust\n\nThe Graph Kernel is a remarkably well-architected provenance engine. It achieves something rare: a Rust service with genuine cryptographic security guarantees enforced at the type level, deterministic behavior verified through golden tests, and a clean separation between its core library (zero I/O) and its service layer (Axum + PostgreSQL). The codebase punches above its weight.\n\nThat said, this audit identifies 47 specific findings across 12 dimensions. The most critical: **the 291ms latency is entirely addressable** (90% network RTT), **entity normalization lives outside the Rust service** (Python middleware), and **server-side multi-hop traversal doesn't exist** (client must make N HTTP calls for N hops). None of these are architectural debt — they're engineering TODOs that the team has already documented.\n\n**Overall Health Score: 7.4 / 10** — Production-viable with clear improvement vectors.\n\n| # | Dimension | Score | Verdict | |---|-----------|-------|---------| | 1 | Code Quality | **8/10** | Clean Rust, strong idioms, no unsafe | | 2 | Architecture | **9/10** | Exceptional separation of concerns | | 3 | Performance | **5/10** | 291ms latency, all network-caused | | 4 | Data Model | **7/10** | Solid triple store, normalization gaps | | 5 | Security | **9/10** | HMAC + type-level enforcement is excellent | | 6 | Testing | **8/10** | Golden tests, property tests, benchmarks | | 7 | Documentation | **9/10** | Research paper, architecture doc, inline comments | | 8 | Dependencies | **7/10** | Clean, some staleness risk | | 9 | Operational | **7/10** | Health checks present, metrics are log-based only | | 10 | Scale | **6/10** | Works at current load, limits unclear | | 11 | Known Bugs | **6/10** | Entity normalization, pagination | | 12 | Missing Features | **5/10** | No server-side traversal, no streaming, no visualization |", "htmlHref": "/research/html/graph-kernel-dep-audit-v2-1uaahjw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4727 }, { "id": "motion-language-examples-isssck", "title": "Motion Language Examples", "slug": "motion-language-examples", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/motion-language/examples/README.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Features:** - 2D trajectory plots with time-coded coloring - 3D latent space visualization (X, Y, Commitment) - Anticipation signal plots (commitment, uncertainty, transition pressure)", "excerpt": "Proof-of-concept implementations demonstrating motion-to-semantic-meaning translation.\n\nVisualizes how different gestures trace characteristic paths through the latent embedding space.\n\n**Features:** - 2D trajectory plots with time-coded coloring - 3D latent space visualization (X, Y, Commitment) - Anticipation signal plots (commitment, uncertainty, transition pressure)\n\nDemonstrates clustering of gesture embeddings to validate the taxonomy from GESTURE_LEXICON.md.\n\n**Output:** - Silhouette scores for each clustering method - Adjusted Rand Index (ARI) comparing to ground truth - Cluster purity metrics - Visual comparison of clustering results", "htmlHref": "/research/html/motion-language-examples-isssck.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 398 }, { "id": "crp-4-2-final-compile-quality-review-complete-rwr1iu", "title": "CRP-4.2: Final Compile & Quality Review — COMPLETE", "slug": "crp-4-2-final-compile-quality-review-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/paper/latex/CRP-4.2-COMPLETE.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Full pdflatex cycle (4 passes): 1. `pdflatex main.tex` — first pass, generated aux/out files 2. `pdflatex main.tex` — resolved longtable widths 3. `pdflatex main.tex` — resolved cross-references 4. `pdflatex main.tex` — final pass, verified stable", "excerpt": "Full pdflatex cycle (4 passes): 1. `pdflatex main.tex` — first pass, generated aux/out files 2. `pdflatex main.tex` — resolved longtable widths 3. `pdflatex main.tex` — resolved cross-references 4. `pdflatex main.tex` — final pass, verified stable\n\n**Note:** No bibtex pass needed — bibliography is inline (`\\begin{thebibliography}` with 59 entries, not external `.bib`).\n\n- **File:** `main.pdf` (445,512 bytes) - **Pages:** 33 total - **Errors:** 0 - **Warnings:** 0 (all `[h]` float warnings fixed → `[ht]`) - **Undefined references:** 0\n\n### Page Count ✅ - Main content (Abstract → Conclusion): ~20 pages (well over 9-page minimum) - Bibliography: ~4 pages (59 references) - Appendices A–D: ~9 pages - Total: 33 pages\n\n### Sections ✅ - [x] Abstract - [x] Introduction (Section 1) - [x] Related Work (Section 2) — 7 subsections - [x] Architecture (Section 3) — 6 subsections - [x] Evaluation (Section 4) — 6 subsections - [x] Discussion (Section 5) — 4 subsections - [x] Reproducibility (Section 6) - [x] Conclusion (Section 7) - [x] Bibliography (59 references) - [x] Appendix A: Eval Cube Sample Questions & Responses - [x] Appendix B: System Prompts - [x] Appendix C: Knowledge Graph Schema - [x] Appendix D: Reproduction Guide", "htmlHref": "/research/html/crp-4-2-final-compile-quality-review-complete-rwr1iu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 403 }, { "id": "t3-arxiv-preprint-preparation-complete-1a9tkrh", "title": "T3 — arXiv Preprint Preparation: COMPLETE ✅", "slug": "t3-arxiv-preprint-preparation-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/T3-COMPLETE.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| File | Size | Purpose | |------|------|---------| | `main.tex` | 152 KB | Complete paper source (single-file, inline bibliography) | | `neurips_2024.sty` | 12 KB | NeurIPS 2024 style file | | `main.pdf` | 463 KB | Pre-compiled reference PDF | | `README.md` | 4.7 KB | Submission instructions and metadata |", "excerpt": "**Task:** Prepare Cog-RLM paper for arXiv submission **Status:** Ready to submit **Completed:** 2026-02-19\n\n| File | Size | Purpose | |------|------|---------| | `main.tex` | 152 KB | Complete paper source (single-file, inline bibliography) | | `neurips_2024.sty` | 12 KB | NeurIPS 2024 style file | | `main.pdf` | 463 KB | Pre-compiled reference PDF | | `README.md` | 4.7 KB | Submission instructions and metadata |\n\n- [x] **Standard pdflatex** — compiles with standard TeX Live, no custom packages - [x] **Inline bibliography** — 59 references in `\\begin{thebibliography}`, no .bib/.bbl needed - [x] **No external figures** — all 6 figures generated via TikZ/pgfplots inline - [x] **No absolute paths** — verified clean - [x] **No external URLs required** — fully self-contained - [x] **NeurIPS style with [preprint]** — appropriate for arXiv - [x] **All packages standard** — available in arXiv's TeX Live distribution\n\n### Main Paper (~20 pages) - Introduction, Related Work (7 subsections), Architecture (6 subsections) - Evaluation (7 subsections including ablation), Discussion, Reproducibility, Conclusion\n\n### Appendices (~18 pages) - **A:** 15 sample evaluation questions with responses - **B:** Complete system prompts (actual code from twin_server_v3.py) - **C:** Full knowledge graph schema (25 nodes, 70 edges, complete inventory) - **D:** Step-by-step reproduction guide - **E:** **Full 103 Eval Cube questions** — all questions across 10 dimensions with pass/fail, difficulty, required/disallowed keywords, and failure analysis - **F:** Expanded 174-question eval suite overview", "htmlHref": "/research/html/t3-arxiv-preprint-preparation-complete-1a9tkrh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 473 }, { "id": "latent-representation-overview-1cgpkof", "title": "Latent Representation Overview", "slug": "latent-representation-overview", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/03-latent-representation/overview.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "- `EchelonCore` - `LatentUpdater` - `SimpleLatentUpdater` - `LearnedLatentUpdater` - `DellLatentUpdater` - `SANPipeline` - `DiffusionService` - `ClaimBridge`", "excerpt": "The representation layer is where raw body data becomes a compact state that the rest of the system can use.\n\nThe current source does not justify saying there is one canonical \"LIM-RPS\" runtime brain. The verified names are:\n\n- `EchelonCore` - `LatentUpdater` - `SimpleLatentUpdater` - `LearnedLatentUpdater` - `DellLatentUpdater` - `SANPipeline` - `DiffusionService` - `ClaimBridge`\n\n`LIM-RPS` remains a real term in older/research code, especially `motion-bridge/src/lim_rps.rs`, but docs should treat it as historical/research vocabulary unless discussing that file directly.\n\n- mocopi bones are high-dimensional; - camera pose can drop or mirror; - watch data arrives at a different rate; - phone IMU and camera features have different noise; - MotionMix BodyTruth can stall if the hub is overloaded.", "htmlHref": "/research/html/latent-representation-overview-1cgpkof.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 431 }, { "id": "echelon-layer-4-body-time-loop-architecture-m1oblr", "title": "Echelon Layer 4 — Body-Time Loop Architecture", "slug": "echelon-layer-4-body-time-loop-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "crucible-output/echelon-l4/03-architecture.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The CLAUDE.md description of the 128D layout is **partially wrong**. The authoritative source is `cc-brain/src/san/mod.rs:flatten_latent()` (lines 52–98). The actual Rust-side layout:", "excerpt": "# Echelon Layer 4 — Body-Time Loop Architecture ## Crucible Stage 3: FORGE **Subject:** Body → Echelon → Music Closed Loop with 128D Temporal Closure **Date:** 2026-05-08 **Status:** FORGE PASS — ready for implementation review\n\nThe CLAUDE.md description of the 128D layout is **partially wrong**. The authoritative source is `cc-brain/src/san/mod.rs:flatten_latent()` (lines 52–98). The actual Rust-side layout:\n\n**Consequence:** temporal data (tempo, phase, periodicity) ALREADY EXISTS in [69:72]. The gap is not that the data is absent — it is that `internal_tempo` is computed in `SimpleLatentUpdater.compute_dynamics()` via `detect_periodicity()` on norm history (autocorrelation of latent-space norm), NOT from a real autocorrelation of body periodicity. This estimate is noisy, has no confidence signal, and is not exposed back to iOS in a queryable way.\n\nThe TEMPORAL SLOT PROBLEM is thus: 1. `internal_tempo` uses a proxy (norm variance) not body-kinematics autocorrelation 2. Tempo confidence [70] is currently repurposed as `phase` (not a confidence value) 3. No \"body phase within current cycle\" (normalized 0-1 position) distinct from `phase` 4. No swing amount in the canonical vector at all 5. No API to push an external tempo estimate (from Mocopi, audio analysis, tap tempo) into the Rust brain\n\nB. Add `push_temporal()` method on `EchelonCore` — passes through to LatentUpdater.", "htmlHref": "/research/html/echelon-layer-4-body-time-loop-architecture-m1oblr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 4252 }, { "id": "stage-3-forge-pebble-v0-8-architecture-wcyqeu", "title": "Stage 3 — FORGE: Pebble V0.8 Architecture", "slug": "stage-3-forge-pebble-v0-8-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "crucible-output/pebble-v08-p2-p5/03-architecture.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> The creative architecture distilled from Stages 1+2. > Audience: meta:omega (executes this) and meta:hydra (stress-tests this).", "excerpt": "> The creative architecture distilled from Stages 1+2. > Audience: meta:omega (executes this) and meta:hydra (stress-tests this).\n\nThe whole V0.8 system is the result of mechanically applying that formula to each of the four phases. There is exactly one creative gesture per phase — every other decision falls out of the formula.\n\nEvery V0.8 artefact is one of six categories. Each category has fixed behavioural rules. Mixing categories within a single endpoint is forbidden.\n\n| DNA | Plane | Lifetime | Failure rule | Storage | Examples | |-----|-------|----------|--------------|---------|----------| | **🟢 ControlOp** | Control | request/response | throws + user-visible banner | none | `/codex/inject?chat_id`, `/captain/ask`, `/state/restore` | | **🔵 DataStream** | Data | long-lived WS / poll loop | silent retry, banner only when stale > N min | App Group projection | ntfy WS, ntfy `.summarised`, snapshot polling | | **🟡 Bridge** | tmux-as-RPC (Captain) | long-lived daemon | restart via launchd; control ops 504 on timeout; data ops drop messages | none (bridge is stateless) | `captain-bridge.py` | | **🟠 Snapshotter** | Local→disk | long-lived launchd | KeepAlive + atomic-rename on writes; missing snapshots → \"Captain unsure\" | `[home-path]` | `mesh-state-snapshotter.py` | | **🟣 Projection** | Local SQLite | persistent | append-only mirror of authoritative SQLite; widget read-only | `Group/pebble-projection.sqlite` | conversations_top3, projection_captain, projection_health | | **🔴 Strategy** | Code-level | per-call | confidence-scored ladder; telemetry to caller | none | `AXStrategy`, `ShortcutStrategy`, `URLStrategy` |\n\nA new endpoint or daemon must declare its DNA in its docstring. PR review rejects mixed-DNA artefacts (e.g., a `ControlOp` that returns a stream).", "htmlHref": "/research/html/stage-3-forge-pebble-v0-8-architecture-wcyqeu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 2001 }, { "id": "autoresearchclaw-research-extract-1t13wtw", "title": "AutoResearchClaw Research Extract", "slug": "autoresearchclaw-research-extract", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/autoresearchclaw-research.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Research Date:** 2026-03-18 **Target Repo:** https://github.com/aiming-lab/AutoResearchClaw **Focus:** Novel patterns worth stealing for CLAW mesh integration", "excerpt": "**Research Date:** 2026-03-18 **Target Repo:** https://github.com/aiming-lab/AutoResearchClaw **Focus:** Novel patterns worth stealing for CLAW mesh integration\n\nAutoResearchClaw is a 23-stage autonomous research pipeline that transforms a single idea into conference-ready papers. Three patterns stand out as immediately valuable:\n\n1. **4-layer citation verification** — prevents LLM hallucination in references (arXiv → DOI → OpenAlex → Semantic Scholar fallback) 2. **Cross-run lesson extraction** — JSONL append-only failure log → LLM skill generation → prompt overlay injection (25% retry reduction) 3. **PIVOT/REFINE/PROCEED autonomy** — autonomous decision loops with versioned rollbacks and pivot limits\n\nThe rest is solid engineering but not novel: multi-source literature search (OpenAlex/S2/arXiv), sandbox execution with AST validation, hardware detection, quality gates with template ratio heuristics.\n\n| Source | Endpoint | Rate Limit | Query Method | |--------|----------|------------|--------------| | **OpenAlex** | `https://api.openalex.org/works` | 10K/day | `search` param + `filter` for dates, `select` for fields, `mailto` for polite pool | | **Semantic Scholar** | `https://api.semanticscholar.org/graph/v1/paper/search` | 1 req/s (free), 10 req/s (paid) | `query` param + `year` filter + `fields` selection | | **arXiv** | `https://export.arxiv.org/api/query` | 1/3s | `search_query=all:{query}` + Atom XML parsing |", "htmlHref": "/research/html/autoresearchclaw-research-extract-1t13wtw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 5329 }, { "id": "stage-2-compound-sequential-synthesis-ipva4x", "title": "Stage 2: COMPOUND -- Sequential Synthesis", "slug": "stage-2-compound-sequential-synthesis", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-full-system-architecture/stage2-compound.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| Conflict | Resolution | Reasoning | |----------|-----------|-----------| | Who owns visual reactivity? | K11 Unity, locally (Path A/F win over C) | Visual latency budget is ~13ms. Remote control adds 20-40ms round trip. Unacceptable. | | Who owns music intelligence? | MotionMix iOS (Path C wins over A/D) | EchelonBridge + SAN + ParamMapper is 5,000+ lines of battle-tested motion-to-music. No port. | | Who coordinates across mesh? | Multicam server :9404 on Mac1 (Path B insight, simplified) | Already exists, alrea", "excerpt": "| Conflict | Resolution | Reasoning | |----------|-----------|-----------| | Who owns visual reactivity? | K11 Unity, locally (Path A/F win over C) | Visual latency budget is ~13ms. Remote control adds 20-40ms round trip. Unacceptable. | | Who owns music intelligence? | MotionMix iOS (Path C wins over A/D) | EchelonBridge + SAN + ParamMapper is 5,000+ lines of battle-tested motion-to-music. No port. | | Who coordinates across mesh? | Multicam server :9404 on Mac1 (Path B insight, simplified) | Already exists, already has director loop + WebSocket hubs + session management. | | Message bus for sensor data? | Direct UDP, no NATS (Path F wins over E) | Real-time sensor data needs <2ms local, not 15ms through a broker. | | Message bus for control plane? | HTTP/WebSocket via multicam server (Path E insight, existing infra) | :9404 already handles /echelon, /bar-fire, /director/ws, /session/*. | | Does Unity publish outward? | Yes: LUMS derived state (Path D insight) | Unity publishes scene state so remote consumers get processed features, not raw data. | | Where does ML inference run? | cloud-vm or Mac5, REST API via Tailscale (Path B) | K11 has no CUDA. One-step diffusion stays remote. |\n\n**Data Plane (real-time, UDP, sub-50ms):** All sensor data and derived features flow as UDP datagrams using the LUME wire format family. Publishers bind [ip]. Consumers listen on well-known ports. No middleware. No broker. No acknowledgment. Fire-and-forget with graceful degradation on loss.\n\n**Control Plane (coordination, HTTP/WS, 100ms+ tolerance):** Session management, director cuts, echelon state sync, health checks, and configuration flow through the multicam server :9404 HTTP API and WebSocket hubs. Reliable delivery. Request-response for commands. Event streams for state changes.\n\n**Domain 1: K11 -- Visual Sovereignty** K11 owns everything between sensor input and HDMI output. It runs the Python publishers, Unity scene, and all visual processing components. It does NOT make music decisions. It does NOT coordinate other machines. It publishes derived visual state (LUMS) for remote consumers.\n\n**Domain 2: MotionMix iOS -- Musical Sovereignty** The iPhone owns the motion-to-music pipeline. It consumes LUMM (skeleton) and LUMF (audio environment) from K11 via Tailscale UDP, fuses them with local CoreMotion/Vision data into the 128D canonical vector, runs the SAN pipeline, and drives Strudel.js audio synthesis on Mac5. It does NOT control K11 visuals directly.", "htmlHref": "/research/html/stage-2-compound-sequential-synthesis-ipva4x.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 3862 }, { "id": "stage-3-expand-master-plan-1ekzz7c", "title": "Stage 3: EXPAND + MASTER PLAN", "slug": "stage-3-expand-master-plan", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-full-system-architecture/stage3-expand-master-plan.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**R1: Radeon 780M Compute Shader Compatibility** - Failure scenario: Unity compute shaders (LumeDepthReproject.compute, LumeOpticalFlow.compute) fail on AMD Vulkan/DX12 drivers. These were developed on Apple Metal (Mac5). - Probability: 20% - Impact: HIGH (no visual pipeline without GPU reprojection) - Mitigation: Test on K11 Day 2. If Vulkan fails, try DX12 backend. If both fail, use LUME format (CPU-reprojected in pointcloud_pub.py) instead of LUMD (GPU-reprojected). Wave 1 graceful-degrade path exists. - Validat", "excerpt": "**R1: Radeon 780M Compute Shader Compatibility** - Failure scenario: Unity compute shaders (LumeDepthReproject.compute, LumeOpticalFlow.compute) fail on AMD Vulkan/DX12 drivers. These were developed on Apple Metal (Mac5). - Probability: 20% - Impact: HIGH (no visual pipeline without GPU reprojection) - Mitigation: Test on K11 Day 2. If Vulkan fails, try DX12 backend. If both fail, use LUME format (CPU-reprojected in pointcloud_pub.py) instead of LUMD (GPU-reprojected). Wave 1 graceful-degrade path exists. - Validation: `pointcloud_pub.py --synthetic-depth` + Unity running on K11 produces visible animated surface.\n\n**R2: Tailscale Mesh Reliability for LUMM/LUMF to iOS** - Failure scenario: Tailscale has documented 100% packet loss episodes (Mac5 unreachable during some sessions). If LUMM/LUMF don't reach iOS, mocopi skeleton never enters the 128D vector, SAN loses body input, music becomes unresponsive. - Probability: 30% - Impact: HIGH (music disconnects from body motion) - Mitigation: (1) iOS local fallback: if no LUMM received for 3s, fall back to local CoreMotion/Vision-only 128D (dims [76:100] stay zero, as they are today pre-LUMM). (2) LUMF fallback: if no LUMF for 3s, ambient audio dims [104:108] stay zero. (3) Health check: lume_packet_inspector.py on K11 logs drop rates. echelon_relay.py pings Tailscale targets on startup. - Validation: Unplug Tailscale adapter on K11 while iOS is consuming. Verify music continues with degraded but not broken behavior.\n\n**R3: mocopi BLE Pairing Unreliability** - Failure scenario: Sony mocopi 6x sensors fail to pair via BLE to K11 Windows. BLE pairing on Windows is notoriously flaky. Without mocopi, LUMM :9702 is empty. - Probability: 35% - Impact: MEDIUM-HIGH (lose skeleton input, but depth + audio still work) - Mitigation: (1) Primary: use Sony mocopi app on phone, phone connects to sensors via BLE, phone sends to K11 via OSC :9500 instead of K11 BLE direct. mocopi_bridge.py already has an OSC listener path. (2) Secondary: skip mocopi entirely. Depth camera optical flow + audio transients still drive visuals. iOS still has CoreMotion/Vision for music. - Validation: Run system for 30 minutes with only Femto Bolt + UMA-8. Verify visuals and music are engaging without skeleton data.\n\n**R4: Music-to-Visual Synchronization Drift** - Failure scenario: K11 visuals react to local depth/audio sensors (~13ms latency). Mac5 audio reacts to iOS-processed data (~50ms). A hand clap is visible in depth at T=0 but audible at T=37ms later. Perceptible desync during fast transients. - Probability: 50% (will happen, question is severity) - Impact: MEDIUM (subconscious unease, not show-stopping) - Mitigation: (1) Local audio reactivity on K11 via LUMF means visuals DO react to the clap at T=8ms (via LumeAudioFftReceiver transie", "htmlHref": "/research/html/stage-3-expand-master-plan-1ekzz7c.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 3690 }, { "id": "meta-evolution-program-canonical-overview-vis9hr", "title": "Meta-Evolution Program: Canonical Overview", "slug": "meta-evolution-program-canonical-overview", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/meta-candidate-mining/meta-evolution-overview.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> This document tells the full story of the meta-evolution program: how disconnected evo-cube research was collapsed into a governed architecture program, why that collapse was necessary, and how the wave-based application model replaced unbounded cube generation. It is the entry point for anyone who needs to understand the program without reading the 8+ source files it synthesizes.", "excerpt": "> This document tells the full story of the meta-evolution program: how disconnected evo-cube research was collapsed into a governed architecture program, why that collapse was necessary, and how the wave-based application model replaced unbounded cube generation. It is the entry point for anyone who needs to understand the program without reading the 8+ source files it synthesizes.\n\nThe meta-evolution program is the system that governs how architectural research gets generated, organized, and applied to the live codebase. It replaced an earlier mode where evo-cubes (multi-stage architecture analysis documents) were generated as isolated outputs. That earlier mode produced valuable research but no mechanism for turning research into architecture changes. The meta-evolution program exists to close that gap.\n\nThe program's control plane lives in `Desktop/evo-cube-output/meta-candidate-mining/` and `Desktop/evo-cube-output/mega-cube-registry.md`. Its operational policy is defined in `architecture-application-roadmap.md`. Its execution history is recorded in the stage files (stage0 through stage3) and the backlog directories.\n\nThe program began with an exhaustive fact inventory of the entire codebase. Stage 0 surveyed 70+ projects, 106 Prefect flows, 34 Claude hook directories, 15 MCP servers, 46+ iOS/macOS apps, 141 Supabase tables, and infrastructure spanning 5 physical machines plus a cloud VM. That survey identified 114 distinct evo-cube candidates across 14 categories: individual apps, backend services, data pipelines, infrastructure, AI/ML systems, knowledge and memory, monitoring, integration layers, revenue surfaces, creative systems, security, developer tooling, cross-system architectures, and additional high-potential threads.\n\nThe 114 candidates were not hypothetical. Each had file paths, line counts, gap analysis, and cross-system dependency notes. The survey also identified 10 critical fleet-wide gaps: no canonical source for 12+ projects, no unified event schema, no production deployment map, no continuous ML training loop, no graduation lifecycle, no cross-app progression, no flow dependency graph, no credential rotation, no knowledge graph analytics, and a 30% pane spawn miss rate.", "htmlHref": "/research/html/meta-evolution-program-canonical-overview-vis9hr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 2575 }, { "id": "dream-journal-interpreter-1czl1q3", "title": "Dream Journal Interpreter", "slug": "dream-journal-interpreter", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/dream-journal-interpreter/SKILL.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**HEF Evolution:** Instance 37, Generation 8 (V9) **Task:** task_20260202174943_27744c **Previous:** task_20260202170913_a15454 (V8)", "excerpt": "**HEF Evolution:** Instance 37, Generation 8 (V9) **Task:** task_20260202174943_27744c **Previous:** task_20260202170913_a15454 (V8)\n\n> *\"Dreams don't just happen—they can be cultivated. Orchestration turns passive dreaming into active gardening.\"*\n\nV9 transforms the interpreter from passive analysis into **active cultivation** — scheduling dream incubation cycles, managing multi-stage workflows, running focused sprints, and automating dream processing with intelligent rules.\n\n| Feature | Description | |---------|-------------| | **🎼 Dream Orchestration** | Schedule and automate dream incubation cycles | | **📋 Dream Workflows** | Multi-stage pipelines from seed → implement | | **🏃 Dream Sprints** | Focused incubation periods with goals | | **📬 Dream Queues** | Priority-based dream processing | | **📊 Dream Health** | Automated garden health monitoring | | **🔔 Dream Subscriptions** | Track specific themes across time | | **⏰ Scheduled Analysis** | Cron-integrated pattern detection | | **⚡ Automation Rules** | Trigger actions on dream events |\n\n| Workflow | Stages | Use Case | |----------|--------|----------| | **wf_standard** | seed → incubate → analyze → synthesize → implement → review | Default pipeline | | **wf_quick** | seed → analyze → implement | Fast prototyping | | **wf_research** | seed → incubate (x2) → analyze → synthesize → validate → archive | Deep research |", "htmlHref": "/research/html/dream-journal-interpreter-1czl1q3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3266 }, { "id": "goal-archaeologist-1y93exg", "title": "Goal Archaeologist", "slug": "goal-archaeologist", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/goal-archaeologist/SKILL.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Dig beneath surface-level goals to uncover root motivations. Most people know *what* they want but not *why* they really want it. The Archaeologist excavates through layers of stated desire to find the bedrock motivation underneath.", "excerpt": "**Version:** 4.0.0 (Gen 10) **Origin:** HEF Evolution inst_20260131082159_816 → Gen 10 task_20260201162716\n\n> *\"The goal you state is rarely the goal you have. The goal you hide is the one moving you.\"*\n\nDig beneath surface-level goals to uncover root motivations. Most people know *what* they want but not *why* they really want it. The Archaeologist excavates through layers of stated desire to find the bedrock motivation underneath.\n\n- User asks for help achieving a goal - Goal seems vague, contradictory, or keeps shifting - User is stuck in analysis paralysis - Project scope creep (symptom of unclear true goal) - \"I want X but keep procrastinating\" scenarios\n\n- \"I want to...\", \"I need to...\", \"My goal is...\" - \"Why do I keep putting off...\" - \"Help me figure out what I really want\" - User restates same goal differently multiple times - Goals that conflict with stated values", "htmlHref": "/research/html/goal-archaeologist-1y93exg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3992 }, { "id": "karl-architecture-1e7a1la", "title": "KARL Architecture", "slug": "karl-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "karl/docs/architecture.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` Recording -> Scoring -> Analysis -> Training -> Improved Routing ^ | | | +------------- Better trajectories <-------------+ ```", "excerpt": "KARL is a trajectory-based learning system for AI coding agents. It implements a closed-loop pipeline:\n\n- **Tap A** (`init_session_buffer`): Opens a JSON buffer when a session starts or a skill is activated. Captures the prompt, working directory, and skill name.\n\n- **Tap B** (`append_tool_event`): After every tool call (Read, Edit, Write, Bash, Grep, Glob, Task), appends the tool name, key parameters, success/failure, and timing to the buffer.\n\n- **Tap C** (`flush_session`): When the agent finishes responding, flushes the buffer to `trajectories.jsonl`. Runs the reward engine to compute a score before writing.\n\n- **Tap D** (`annotate_previous`): On the next prompt, examines the text for correction signals (\"no, I meant...\", \"try again\"). Retroactively annotates the previous trajectory with a failure signal.", "htmlHref": "/research/html/karl-architecture-1e7a1la.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 752 }, { "id": "linkit-ui-system-8midcw", "title": "LinkIt — UI System", "slug": "linkit-ui-system", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "LinkIt/docs/architecture/UI_SYSTEM.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Document ID:** LINKIT-ARCH-005 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/LinkIt/components/`", "excerpt": "**Document ID:** LINKIT-ARCH-005 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/LinkIt/components/`\n\nLinkIt uses a custom GSAPGlass design system built on top of shadcn/ui, providing a modern glassmorphism aesthetic with smooth GSAP animations.\n\n| Component | File | Description | |-----------|------|-------------| | Button | components/ui/button.tsx | GSAPGlass button variants | | Input | components/ui/input.tsx | Glass input fields | | Card | components/ui/card.tsx | GSAPGlass card | | Toast | components/ui/toast.tsx | Notification toasts | | Skeleton | components/ui/skeleton.tsx | Loading skeletons |\n\n| Component | File | Description | |-----------|------|-------------| | MenuTrigger | components/layout/MenuTrigger.tsx | Floating menu button | | SideMenu | components/layout/SideMenu.tsx | Slide-in navigation | | MenuItem | components/layout/MenuItem.tsx | Menu item with animation | | MenuOverlay | components/layout/MenuOverlay.tsx | Backdrop overlay | | Navigation | components/layout/Navigation.tsx | Main navigation wrapper | | DashboardHeader | components/layout/DashboardHeader.tsx | Dashboard header | | DashboardSidebar | components/layout/DashboardSidebar.tsx | Dashboard sidebar |\n\n| Component | Path | Description | |-----------|------|-------------| | ProfileHeader | components/profile/ProfileHeader.tsx | Public profile header | | LinkCard | components/links/LinkCard.tsx | Featured link display | | AnalyticsChart | components/analytics/AnalyticsChart.tsx | Data visualization | | FontSelector | components/customize/FontSelector.tsx | Font picker | | ColorPicker | components/customize/ColorPicker.tsx | Color selection |", "htmlHref": "/research/html/linkit-ui-system-8midcw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1027 }, { "id": "meshd-wire-protocol-reference-specification-knbn67", "title": "meshd Wire Protocol — Reference Specification", "slug": "meshd-wire-protocol-reference-specification", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "meshd/marketing/protocol-spec.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. [Overview](#1-overview) 2. [Authentication](#2-authentication) 3. [Slot API](#3-slot-api) 4. [Mesh API](#4-mesh-api) 5. [Slot Lifecycle](#5-slot-lifecycle) 6. [Configuration](#6-configuration) 7. [Topology](#7-topology) 8. [Building a Client](#8-building-a-client) 9. [Error Reference](#9-error-reference) 10. [Future Work](#10-future-work)", "excerpt": "**Status:** Informational **Version:** 1.0 **Source:** `https://github.com/mohameddiomande/meshd`\n\n1. [Overview](#1-overview) 2. [Authentication](#2-authentication) 3. [Slot API](#3-slot-api) 4. [Mesh API](#4-mesh-api) 5. [Slot Lifecycle](#5-slot-lifecycle) 6. [Configuration](#6-configuration) 7. [Topology](#7-topology) 8. [Building a Client](#8-building-a-client) 9. [Error Reference](#9-error-reference) 10. [Future Work](#10-future-work)\n\nmeshd is a Rust daemon that manages a static registry of agent slots — named PTY processes (Claude, Codex, OpenCode, Gemini, or any CLI agent) — and exposes them over an HTTP/1.1 REST API. Each machine in a Tailscale mesh runs its own independent meshd instance. Machines discover each other via a hard-coded static node table and coordinate through peer-to-peer HTTP calls.\n\n- **Direct PTY ownership.** Each slot is a real forked process with a master PTY. Injection writes bytes directly to the PTY master fd. No shell wrapper, no exec layer. - **Zero inter-node dependencies at boot.** Every node runs standalone. Mesh coordination is best-effort; a node failure does not affect the others. - **Stateless HTTP.** All slot state is in-process. No shared database is required for operation (Supabase is used for fleet visibility only, not for control-plane decisions). - **ANSI-clean output.** The PTY reader strips ANSI escape sequences before writing to the ring buffer, so consumers get plain text lines.\n\n| Property | Value | |---|---| | Protocol | HTTP/1.1 | | Default port | 9451 | | Alternate mesh-api compat port | Configurable via `mesh_port` | | Bind address | `[ip]` (all interfaces) | | Content type | `application/json` (all endpoints except `/stream`) | | Streaming | `text/event-stream` (SSE, `/stream/:slot` only) |", "htmlHref": "/research/html/meshd-wire-protocol-reference-specification-knbn67.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4394 }, { "id": "continuation-protocol-swift-ios-project-cqvaxz", "title": "Continuation Protocol - Swift iOS Project", "slug": "continuation-protocol-swift-ios-project", "kind": "technical note", "program": "Research Backlog", "sourceAnchor": "Milk Men/Documentation/Implementation/07-Governance/Continuation-Protocol.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Document ID:** GOV-CONT-001 **Version:** 2.0.0 **Created:** 2026-01-04 **Updated:** 2026-01-13 **Status:** Active **Platform:** iOS (Swift/SwiftUI) **Owner:** Lead Developer", "excerpt": "**Document ID:** GOV-CONT-001 **Version:** 2.0.0 **Created:** 2026-01-04 **Updated:** 2026-01-13 **Status:** Active **Platform:** iOS (Swift/SwiftUI) **Owner:** Lead Developer\n\n**Related Documents:** - [Master-Checklist](../03-Checklists/Master-Checklist.md) - Task Tracking - [Entry-Point-Decision](../00-Overview/Entry-Point-Decision.md) - Project Context - Master Implementation Prompt (`/CLAUDE.md`) - Governance Framework\n\n1. [Overview](#1-overview) 2. [Continuation Anchor System](#2-continuation-anchor-system) 3. [Session Recovery Protocol](#3-session-recovery-protocol) 4. [Source of Truth Registry](#4-source-of-truth-registry) 5. [Checkpoint System](#5-checkpoint-system) 6. [Handoff Procedures](#6-handoff-procedures) 7. [Context Recovery](#7-context-recovery) 8. [Progress Tracking](#8-progress-tracking)\n\nThis document defines the continuation protocol for the Milk Men iOS project, ensuring work can resume seamlessly across: - Session boundaries (token limits, natural pauses) - Developer handoffs (team member changes) - Time gaps (days or weeks between work sessions) - Context loss (memory limitations, summarization)\n\n**The Project Must Be Self-Documenting:** - Any developer (human or AI) can pick up where work left off - No reliance on memory or conversation history - All context is written down and accessible - Progress is always traceable to a specific checkpoint", "htmlHref": "/research/html/continuation-protocol-swift-ios-project-cqvaxz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2775 }, { "id": "stable-audio-3-f280zs", "title": "Stable Audio 3", "slug": "stable-audio-3", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/stable-audio-3/README.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "[Technical Report](https://arxiv.org/abs/2605.17991) · [🤗 Models](https://huggingface.co/collections/stabilityai/stable-audio-3) · [🤗 Extra Models](https://huggingface.co/collections/stabilityai/stable-audio-3-extra) · [Discord](https://discord.gg/cKpvjey8b) · [Demo](https://huggingface.co/spaces/stabilityai/stable-audio-3) · [Blog Post](https://stability.ai/news-updates/meet-stable-audio-3-the-model-family-built-for-artistic-experimentation-with-open-weight-models)", "excerpt": "**A state-of-the-art open platform for fast, high-quality generated audio and music.**\n\n[Technical Report](https://arxiv.org/abs/2605.17991) · [🤗 Models](https://huggingface.co/collections/stabilityai/stable-audio-3) · [🤗 Extra Models](https://huggingface.co/collections/stabilityai/stable-audio-3-extra) · [Discord](https://discord.gg/cKpvjey8b) · [Demo](https://huggingface.co/spaces/stabilityai/stable-audio-3) · [Blog Post](https://stability.ai/news-updates/meet-stable-audio-3-the-model-family-built-for-artistic-experimentation-with-open-weight-models)\n\nStable Audio 3 is the next generation of Stable Audio: a focused, streamlined platform for inference and fine-tuning, built on lessons from [stable-audio-tools](https://github.com/Stability-AI/stable-audio-tools). If you're doing foundational research or working with previous Stable Audio models, that repo is still the place to go.\n\n| Model | Model ID | Autoencoder | Hardware | Params | Max length | Use case | |---|---|---|---|---|---|---| | [**Stable Audio 3 Small-Music**](https://huggingface.co/stabilityai/stable-audio-3-small-music) | `small-music` | SAME-Small | CPU | 433M | 120s | Lightweight music-only inference, no GPU required | | [**Stable Audio 3 Small-SFX**](https://huggingface.co/stabilityai/stable-audio-3-small-sfx) | `small-sfx` | SAME-Small | CPU | 433M | 120s | Lightweight sound effects-only inference, no GPU required | | [**Stable Audio 3 Medium**](https://huggingface.co/stabilityai/stable-audio-3-medium) | `medium` | SAME-Large | GPU (CUDA) | 1.4B | 380s | High Quality, Fast Inference | | **Stable Audio 3 Large** | — | SAME-Large | API only | 2.7B | 380s | Highest quality, API only. Not supported by this repo, see the [API docs](https://stableaudio.com/user-guide) |\n\nBase (un-post-trained) checkpoints, the SAME autoencoders, and optimized variants are available in the [Extra Models collection](https://huggingface.co/collections/stabilityai/stable-audio-3-extra).", "htmlHref": "/research/html/stable-audio-3-f280zs.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1592 }, { "id": "nko-acoustic-coding-featural-acoustic-coding-fac-wdm5sc", "title": "N'Ko Acoustic Coding — Featural Acoustic Coding (FAC)", "slug": "nko-acoustic-coding-featural-acoustic-coding-fac", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-acoustic-coding/README.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Research code and paper for the N'Ko tone-resolution seam: using acoustic evidence, especially F0, to restore tone marks that a toneless N'Ko ASR pipeline cannot recover from text alone.", "excerpt": "Research code and paper for the N'Ko tone-resolution seam: using acoustic evidence, especially F0, to restore tone marks that a toneless N'Ko ASR pipeline cannot recover from text alone.\n\nThe recognizer emits toneless N'Ko, but N'Ko tone is written in the signal: speaker-relative F0 supplies evidence that a text-only prior cannot see. FAC is the acoustic likelihood side of that estimator; AGP is the governance gate that decides where a correction is safe.\n\n| N'Ko slot | Acoustic axis it encodes | Native? | |---|---|---| | Tone marks (7 marks, `U+07EB`–`U+07F1`) | pitch register + contour, with short/long variants | **native** | | Nucleus (7 vowels) | spectral centroid / formant color | **native** | | Onset (consonant manner) | attack transient type | **native** | | Nasal coda | resonant sustain | **native** | | harmonicity / spread / roughness / dynamics | timbre | designed extension |\n\nThe correction that matters: **falling tone is native**. Unicode names U+07EE as `NKO COMBINING LONG DESCENDING TONE`; no designed pitch mark is needed for falling. Designed FAC extensions are reserved for higher timbral descriptors, not pitch.\n\nThe measured corpus prior is now generated by code, not copied by hand: 4,139 parsed syllables across 105 entries show roughly 65.8% marked high/low, 33.3% unmarked mid, and 0.9% contour. That makes the first practical correction problem register-first and confidence-gated, not a broad claim that contour dominates all tone.", "htmlHref": "/research/html/nko-acoustic-coding-featural-acoustic-coding-fac-wdm5sc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 658 }, { "id": "nko-publication-readiness-and-narrative-plan-2026-05-03-1g8onsh", "title": "N'Ko Publication Readiness and Narrative Plan - 2026-05-03", "slug": "nko-publication-readiness-and-narrative-plan-2026-05-03", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/handoffs/nko-publication-readiness-and-narrative-2026-05-03.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "You can still talk about the 20.57% CER result, but it should be framed as an archived checkpoint anchor, not as a completed May 2026 reproduction and not as proof that all controlled ASR comparisons are closed.", "excerpt": "You can still talk about the 20.57% CER result, but it should be framed as an archived checkpoint anchor, not as a completed May 2026 reproduction and not as proof that all controlled ASR comparisons are closed.\n\nThe strongest public narrative is not \"we solved Bambara ASR.\" The strongest narrative is:\n\n> Modern AI systems do not just perform badly on N'Ko. They reveal a deeper > infrastructure failure: the script is underrepresented in model vocabularies, > activations, benchmarks, and evaluation metrics. N'Ko's bijective design gives us a > cleaner way to measure and build Manding language technology, and the archived > 20.57% CER checkpoint shows that script-native ASR is technically viable enough to > justify the research direction.\n\nThat narrative lets you use the 20.57% result without pretending the strict audit finished.\n\nArtifact: `[home]/Desktop/nko-brain-scanner/local_results_cache/paper4_reproduction_35205256/results.json`", "htmlHref": "/research/html/nko-publication-readiness-and-narrative-plan-2026-05-03-1g8onsh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2352 }, { "id": "nko-research-program-closeout-2026-05-03-yt1xeu", "title": "N'Ko Research Program Closeout - 2026-05-03", "slug": "nko-research-program-closeout-2026-05-03", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/handoffs/nko-research-program-closeout-2026-05-03.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Stop paid compute now. The Vast instance used for the strict Paper 4 anchor audit was destroyed on 2026-05-03, `vastai show instances` was empty afterward, and the `monitor-nko-anchor-audit` automation was deleted. No further cloud training should be started unless Mohamed explicitly reopens the project later with a full-run budget and artifact-download plan.", "excerpt": "Stop paid compute now. The Vast instance used for the strict Paper 4 anchor audit was destroyed on 2026-05-03, `vastai show instances` was empty afterward, and the `monitor-nko-anchor-audit` automation was deleted. No further cloud training should be started unless Mohamed explicitly reopens the project later with a full-run budget and artifact-download plan.\n\nThis closeout evaluates the paper set as a research program, not as a launch plan for more experiments.\n\nThe strongest, most defensible contribution is the script-invisibility line: activation profiling shows that N'Ko is effectively absent from current LLM internal circuits, and cross-model evidence supports the claim that this is structural rather than a single-model accident.\n\nThe ASR/script-advantage line is promising but not fully closed. The archived 20.57% N'Ko trajectory checkpoint is locally preserved and remains the best direct ASR anchor, but the strict May 2026 audit did not complete before billing ended. The April 22 same-snapshot matrix cannot validate or refute the 20.57% anchor because it used `lr=0.0001`, while the anchor used `lr=0.0003`.\n\n- Papers 1 and 3 are the strongest research products and can move forward without more paid compute after packaging, citation cleanup, and artifact indexing. - Paper 8, the WER/CER position paper proposal, is the best no-cost next writing output because it uses theory and existing evidence rather than new training. - Papers 2, 4, and 5 should be frozen as technical reports or heavily caveated preprints. - Papers 6, 7, and 9 should remain future work, not active commitments.", "htmlHref": "/research/html/nko-research-program-closeout-2026-05-03-yt1xeu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2156 }, { "id": "nko-brain-scanner-comprehensive-project-handoff-1apffrj", "title": "N'Ko Brain Scanner — Comprehensive Project Handoff", "slug": "nko-brain-scanner-comprehensive-project-handoff", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/HANDOFF.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "An ASR (Automatic Speech Recognition) system for N'Ko script — a phonetically transparent writing system used by ~30M Manding-language speakers in West Africa. The core research question: **does N'Ko's phonetic transparency give it a measurable architectural advantage over Latin script in ASR?**", "excerpt": "An ASR (Automatic Speech Recognition) system for N'Ko script — a phonetically transparent writing system used by ~30M Manding-language speakers in West Africa. The core research question: **does N'Ko's phonetic transparency give it a measurable architectural advantage over Latin script in ASR?**\n\nCurrent verified answer: **the N'Ko trajectory model is strong enough to anchor the project baseline.** The fully archived reproduction on the current `290,596`-pair corpus snapshot achieves **20.57% CER**. Earlier 8-way N'Ko/Latin comparison numbers remain useful historical internal evidence, but their full artifact bundle is not yet restored on this machine and should be treated as provisional.\n\n| Property | Value | |----------|-------| | Architecture | UnifiedCTCHead (46.8M params) | | Input | Whisper large-v3 encoder features (1280-dim) | | Decoder | 6-layer Transformer with trajectory bias injection | | Training data | 290,596 pairs (232,476 train / 29,060 val / 29,060 test) | | Seed | 42 (deterministic split) | | Epochs trained | 46 (best checkpoint at epoch 38) | | Best val loss | 0.6359 | | Checkpoint | `results/paper4_reproduction_35205256/best.pt` | | Results JSON | `results/paper4_reproduction_35205256/results.json` | | Inference script | `asr/transcribe_nko.py` |\n\nArtifacts are also synced to `Mac5:/Volumes/HD1/tar_297k_clean/paper4_reproduction_35205256/`.\n\n### Trajectory Bias Mechanism The model injects pen-stroke trajectory scalars (7-dim: velocity, curvature, acceleration, etc.) into transformer attention as position-dependent bias. This exploits N'Ko's bijective grapheme-phoneme mapping — each character encodes exactly one phoneme, and the trajectory captures how that character is physically written.", "htmlHref": "/research/html/nko-brain-scanner-comprehensive-project-handoff-1apffrj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1796 }, { "id": "nko-as-computational-infrastructure-program-map-teirp1", "title": "N'Ko as Computational Infrastructure — Program Map", "slug": "nko-as-computational-infrastructure-program-map", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/PROGRAM.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**N'Ko is not a decorative or interchangeable rendering of Manding. For machine-learning systems it is computational infrastructure.** A designed, bijective, tone-marking script changes four things that are usually treated as fixed:", "excerpt": "> Front door for the whole research line. One thesis, several pillars, one release plan. > Last updated: 2026-05-28.\n\n**N'Ko is not a decorative or interchangeable rendering of Manding. For machine-learning systems it is computational infrastructure.** A designed, bijective, tone-marking script changes four things that are usually treated as fixed:\n\n1. **What models can represent** — tokenizers and hidden circuits behave differently on N'Ko than on Latin Bambara. 2. **How acoustic evidence aligns to symbols** — a phoneme-transparent target changes CTC decoding. 3. **Whether a reported error rate is meaningful** — N'Ko CER is phonemically interpretable in a way Latin WER is not. 4. **How sound itself can be encoded** — the same script that makes recognition interpretable makes a featural acoustic code possible.\n\nThe trajectory geometry `z_t` is reused at three levels — decode, govern, correct. This is the same figure that anchors the FAC tone-resolution paper.\n\nThe program is **three linguistic pillars** plus an **orthogonal systems track**. Read the linguistic pillars as the science; read the systems track as \"how we trained it cheaply.\" Do not mix them in the narrative.", "htmlHref": "/research/html/nko-as-computational-infrastructure-program-map-teirp1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1712 }, { "id": "pulse-plan-nko-brain-scanner-arxiv-sprint-mhbvjo", "title": "Pulse Plan: NKO Brain Scanner — arXiv Sprint", "slug": "pulse-plan-nko-brain-scanner-arxiv-sprint", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/PULSE-PLAN.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Workspace document requiring curation.", "excerpt": "## Goal Execute the Evo3 master plan to take the NKO Brain Scanner from experimental results to arXiv preprint in 10 days. Fix critical evaluation issues, extend the tokenizer, build production artifacts, and write the paper.\n\n## Source Evo3 master plan at `Desktop/evo-cube-output/nko-brain-scanner-frontier/stage3-expand-master-plan.md`\n\n## Known Problems (from Evo3 stress test) 1. **English eval broken**: Only 4 examples (141 tokens). Every English PPL number is noise. 2. **MLX embedding resize uncharted**: No `resize_token_embeddings()` in MLX. Need manual weight surgery on quantized model. 3. **Architecture mismatch**: Brain scan on Qwen2-72B (80 layers), fine-tuning on Qwen3-8B (36 layers). Need 8B brain scan. 4. **English degradation**: Fine-tuning may have caused catastrophic forgetting (unclear due to broken eval). 5. **No production serving**: Adapters exist but no inference API deployed. 6. **No HuggingFace artifacts**: Model, tokenizer, dataset not published.\n\n## Wave 0: Pre-Flight (Iteration 1) ✅ COMPLETE - [x] Check Mac5 disk space (27GB free) - [x] Verify adapter files exist (19.4MB each) - [x] Check embedding dtype on Mac5: uint32 (quantized, shape 151936x1024) - [x] Smoke-test cross-script bridge: Bridge class works - [x] Verify GCS download status (169 uploaded)\n\n## Wave 1: Fix English Eval + True Baselines (Iterations 2-3) ✅ COMPLETE - [x] Created `eval/build_eval_set.py`: 100 English + 100 N'Ko examples, SHA-256 dedup - [x] Created `eval/run_corrected_profiler.py`: all 3 stages on frozen eval - [x] Uploaded to Mac5 and ran profiler - [x] Corrected results: NKo acc 32.8%, Eng PPL 3.80, translation tax 0.70x (-76%) - [x] Updated blog + docs, committed (793f540)", "htmlHref": "/research/html/pulse-plan-nko-brain-scanner-arxiv-sprint-mhbvjo.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 891 }, { "id": "nko-brain-scanner-1390jmz", "title": "N'Ko Brain Scanner", "slug": "nko-brain-scanner", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/README.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A systematic study of how large language models process N'Ko (U+07C0-U+07FF), an alphabetic script used by 40+ million Manding-language speakers in West Africa. We perform activation profiling (\"brain scanning\"), train a multi-stage adaptation pipeline, build a script-specific BPE tokenizer, implement phonotactically-constrained decoding, and design a retrieval-centric multimodal ASR architecture.", "excerpt": "**The Script That Machines Can't Read: Adapting Large Language Models for N'Ko**\n\nA systematic study of how large language models process N'Ko (U+07C0-U+07FF), an alphabetic script used by 40+ million Manding-language speakers in West Africa. We perform activation profiling (\"brain scanning\"), train a multi-stage adaptation pipeline, build a script-specific BPE tokenizer, implement phonotactically-constrained decoding, and design a retrieval-centric multimodal ASR architecture.\n\nThe world's first ASR system that outputs N'Ko script directly from audio. No prior system does this. All existing Bambara ASR (MALIBA-AI, Meta MMS, Google USM) outputs Latin transliteration only.\n\n**Architecture**: Whisper large-v3 (frozen encoder) + 4x downsample + char-level BiLSTM CTC (5.4M params) + 65 N'Ko character classes + FSM syllable validation post-decoding.\n\n**Training data**: bam-asr-early (37h, 37,306 human-labeled samples) with cross-script bridge (Latin→N'Ko transliteration).", "htmlHref": "/research/html/nko-brain-scanner-1390jmz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1949 }, { "id": "dep-2-audit-chunked-evil-flow-report-1qvgu2g", "title": "DEP-2 Audit + Chunked Evil Flow Report", "slug": "dep-2-audit-chunked-evil-flow-report", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-code-comments/DEP_REPORT.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2026-02-12 **Protocol:** DEP-2 (Deep Enhancement Protocol v2) **Method:** Chunked Evil Flow (CEF) per module **Pass:** 1 (initial)", "excerpt": "**Date:** 2026-02-12 **Protocol:** DEP-2 (Deep Enhancement Protocol v2) **Method:** Chunked Evil Flow (CEF) per module **Pass:** 1 (initial)\n\n## ═══════════════════════════════════════════════════ ## ANTICIPATION STATE ## ═══════════════════════════════════════════════════\n\n| Metric | Value | |--------|-------| | **Commitment** | 0.88 | | **Uncertainty** | 0.15 | | **Decision** | **COMMIT** | | **Circuit Breaker** | CLOSED |\n\n**Reasoning:** All high-severity gaps resolved. Remaining items are enhancement-level (tests, CI pipeline verification). The project is a documentation/education tool — not a production service handling user data — so the risk profile is lower.\n\n## ═══════════════════════════════════════════════════ ## AUDIT SCORES (Post-Fix) ## ═══════════════════════════════════════════════════", "htmlHref": "/research/html/dep-2-audit-chunked-evil-flow-report-1qvgu2g.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2525 }, { "id": "dep-2-audit-chunked-evil-flow-report-xv1nvz", "title": "DEP-2 Audit + Chunked Evil Flow Report", "slug": "dep-2-audit-chunked-evil-flow-report", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/tools/code-wisdom/DEP_REPORT.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2026-02-12 **Protocol:** DEP-2 (Deep Enhancement Protocol v2) **Method:** Chunked Evil Flow (CEF) per module **Pass:** 1 (initial)", "excerpt": "**Date:** 2026-02-12 **Protocol:** DEP-2 (Deep Enhancement Protocol v2) **Method:** Chunked Evil Flow (CEF) per module **Pass:** 1 (initial)\n\n## ═══════════════════════════════════════════════════ ## ANTICIPATION STATE ## ═══════════════════════════════════════════════════\n\n| Metric | Value | |--------|-------| | **Commitment** | 0.88 | | **Uncertainty** | 0.15 | | **Decision** | **COMMIT** | | **Circuit Breaker** | CLOSED |\n\n**Reasoning:** All high-severity gaps resolved. Remaining items are enhancement-level (tests, CI pipeline verification). The project is a documentation/education tool — not a production service handling user data — so the risk profile is lower.\n\n## ═══════════════════════════════════════════════════ ## AUDIT SCORES (Post-Fix) ## ═══════════════════════════════════════════════════", "htmlHref": "/research/html/dep-2-audit-chunked-evil-flow-report-xv1nvz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2525 }, { "id": "stage-4-forge-cc-motiongen-v2-architecture-h1wqtc", "title": "Stage 4: FORGE — CC-MotionGen V2 Architecture", "slug": "stage-4-forge-cc-motiongen-v2-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "omega-output/cc-motion-gen-20260321/04-architecture.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**CC-MotionGen V2 = Flow Matching DiT + Two-Tier Deployment + Multi-Modal Conditioning + Physics-Grounded Learned Validation + Sensor Capture Flywheel**", "excerpt": "**CC-MotionGen V2 = Flow Matching DiT + Two-Tier Deployment + Multi-Modal Conditioning + Physics-Grounded Learned Validation + Sensor Capture Flywheel**\n\nThe system is built on 4 pillars: 1. **25D Motion Protocol** (unchanged, competitive moat) 2. **Flow Matching DiT** (replaces DDPM, 100x faster) 3. **Learned Quality System** (validation advantage evolved) 4. **iPhone Capture Studio** (data flywheel, first-mover)\n\n**Replaces**: `model/diffusion.py` (GaussianDiffusion) **File**: `model/flow_matching.py` (new)\n\n1. **Never replace SanityChecker with learned physics** — Deterministic physics checks are trustworthy. Learned validation supplements, never replaces. 2. **Never train on SMPL and retarget to 25D** — Train on 25D natively. Retarget FROM SMPL for benchmarking only. 3. **Never unify Tiny and Full into one model** — Different deployment targets need different architectures. One-size-fits-all fails on-device. 4. **Never skip the Week 2 flow matching checkpoint** — If 25D flow matching doesn't converge, pivot to DDIM consistency distillation immediately. 5. **Never drop cc-anticipation (Rust) before learned prediction is validated** — Keep it as production fallback. 6. **Never collect motion data without user consent** — 25D is privacy-preserving but consent is mandatory.\n\n**1. Can this be built with available resources?** YES. Training: Mac4/Mac5 for prototyping, cloud GPU for production runs. iOS: Mac1 for builds. All tooling exists.", "htmlHref": "/research/html/stage-4-forge-cc-motiongen-v2-architecture-h1wqtc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1665 }, { "id": "paradox-navigator-generation-14-1qzfa8z", "title": "Paradox Navigator — Generation 14", "slug": "paradox-navigator-generation-14", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "paradox-navigator/SKILL.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Most systems try to **resolve** paradoxes. This one **navigates** them. The tension between opposites is where creativity lives.", "excerpt": "--- name: paradox-navigator version: 14.0.0 description: Navigate paradoxes productively with enhanced therapeutic coaching, 50+ paradox templates, interactive exploration exercises, ACT/IFS/Gestalt-informed guidance, adaptive synthesis learning, and team mapping category: phi tags: [paradox, contradiction, synthesis, coaching, therapeutic, ACT, IFS, somatic, exercises, journal, patterns, timeline, decisions] ---\n\n**Hold contradictions productively. Synthesize opposites. Navigate the creative tension.**\n\nMost systems try to **resolve** paradoxes. This one **navigates** them. The tension between opposites is where creativity lives.\n\n### 📚 Expanded Paradox Library (50+ Templates) The library now includes 50+ paradox templates across 5 categories: - **Personal** (15): action-reflection, giving-receiving, vulnerability-protection, etc. - **Relational** (6): closeness-space, honesty-kindness, boundaries-generosity, etc. - **Professional** (11): visibility-humility, ambition-contentment, risk-safety, etc. - **Creative** (10): perfection-expression, discipline-inspiration, craft-art, etc. - **Existential** (4): meaning-absurdity, mortality-legacy, known-unknown, etc.\n\nEach template now includes: - **Therapeutic notes** — Clinically-informed insights about the paradox - **Somatic cues** — Body-based prompts for embodied exploration", "htmlHref": "/research/html/paradox-navigator-generation-14-1qzfa8z.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1951 }, { "id": "dj-agent-final-implementation-status-il0jnr", "title": "DJ Agent - Final Implementation Status", "slug": "dj-agent-final-implementation-status", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/_archive/2024-12/historical-plans/FINAL_DJ_AGENT_STATUS.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Core Infrastructure** (10/10) - [x] Base directory structure - [x] Action space with 6 tiers - [x] Scheduler with beat quantization - [x] State shadow (Serato mirror) - [x] Serato bridge (MIDI/keyboard) - [x] Reflex policy (continuous controls) - [x] Planner policy (symbolic actions) - [x] Rewards system - [x] Configuration (dj.yaml) - [x] Runtime integration (engine.py)", "excerpt": "# DJ Agent - Final Implementation Status **Date**: November 4, 2025 **Implementation**: ✅ **COMPLETE** **Testing Status**: ⏳ **Awaiting User Setup**\n\n**Core Infrastructure** (10/10) - [x] Base directory structure - [x] Action space with 6 tiers - [x] Scheduler with beat quantization - [x] State shadow (Serato mirror) - [x] Serato bridge (MIDI/keyboard) - [x] Reflex policy (continuous controls) - [x] Planner policy (symbolic actions) - [x] Rewards system - [x] Configuration (dj.yaml) - [x] Runtime integration (engine.py)\n\n**Training & Evaluation** (7/7) - [x] DJ action data loader - [x] Imitation learning trainer - [x] RL trainer - [x] Evaluation metrics - [x] Serato sandbox (RL environment) - [x] Session logger - [x] Telemetry dashboard\n\n**Features** (9/9) - [x] All 6 tiers implemented - [x] Motion-to-intent priors - [x] Safety rails - [x] Ghost/Assist/Auto modes - [x] Hybrid workflow - [x] Hardware controller guide - [x] SuperCollider mastering - [x] Performance profiler - [x] Smooth parameter transitions\n\n**Documentation & Tools** (5/5) - [x] Serato setup guide - [x] Hybrid workflow guide - [x] Hardware controller guide - [x] Quick reference card - [x] Test suite + demo", "htmlHref": "/research/html/dj-agent-final-implementation-status-il0jnr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2234 }, { "id": "graphql-api-layer-architecture-document-1i3s00x", "title": "GraphQL API Layer — Architecture Document", "slug": "graphql-api-layer-architecture-document", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "projects/dream-metamorphosis/graphql-api/docs/ARCHITECTURE.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "- **Performance Prophet** → Health metrics streaming, trend-based subscriptions - **Thought Mesh** → Distributed real-time state propagation - **Cross-Script Bridge** → WebSocket-based real-time translation - **Dream Weaver** → Event-driven lifecycle with state transitions", "excerpt": "## Dream Origin Dream ID: `dream_202601260133_1b112f` Pattern connections: Supabase integration, streaming pipelines, API performance, cross-project pollination\n\n- **Performance Prophet** → Health metrics streaming, trend-based subscriptions - **Thought Mesh** → Distributed real-time state propagation - **Cross-Script Bridge** → WebSocket-based real-time translation - **Dream Weaver** → Event-driven lifecycle with state transitions\n\n### Core Principles 1. **Subscription-first** — Every mutation that changes observable state emits to subscribers 2. **Datasource-agnostic** — Resolvers talk to abstract datasource interfaces (Supabase, REST, in-memory) 3. **Layered middleware** — Auth, rate limiting, caching, and logging compose cleanly 4. **Type-safe end-to-end** — Schema → codegen → resolvers → client, all TypeScript\n\nThe schema follows a **domain-driven** approach. Core domains identified from cross-project patterns:\n\n1. **Relay-style pagination** — All list fields use `Connection` types with `edges` + `pageInfo` 2. **Input types for mutations** — Every mutation takes a single `input` argument 3. **Subscription payloads** — Subscriptions return wrapper types with `event` enum + `data` union 4. **Error unions** — Mutations return `Result` union types (`Success | ValidationError | NotFoundError`)", "htmlHref": "/research/html/graphql-api-layer-architecture-document-1i3s00x.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1315 }, { "id": "integration-plan-migrating-to-the-unified-agent-os-igr2n5", "title": "Integration Plan — Migrating to the Unified Agent OS", "slug": "integration-plan-migrating-to-the-unified-agent-os", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/dream-metamorphosis/unified-agent-os/INTEGRATION_PLAN.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. **Additive, not destructive** — New system reads legacy files; legacy systems continue unchanged until verified. 2. **Dual-write, then cutover** — During migration, both old and new storage are written to. Reads shift to new system first, writes follow. 3. **Each phase has a rollback** — If something breaks, revert by pointing back to legacy files. 4. **Test with real data** — Each phase runs against actual `[home-path]`, `[home-path]`, and `[home-path]`.", "excerpt": "> Step-by-step migration from separate systems to UAOS. > Each phase is independently deployable. No big-bang cutover.\n\n1. **Additive, not destructive** — New system reads legacy files; legacy systems continue unchanged until verified. 2. **Dual-write, then cutover** — During migration, both old and new storage are written to. Reads shift to new system first, writes follow. 3. **Each phase has a rollback** — If something breaks, revert by pointing back to legacy files. 4. **Test with real data** — Each phase runs against actual `[home-path]`, `[home-path]`, and `[home-path]`.\n\n**Goal:** Create the UAOS directory structure and state database without touching existing systems.\n\n3. **Write config.yaml** - Copy template from SHARED_STATE_SCHEMA.md - Adjust paths for this machine - Set `dual_max.enabled: true`\n\n### Definition of Done - [ ] `[home-path]` exists with all tables - [ ] `[home-path]` is valid - [ ] `uaos` package is importable - [ ] No existing system is modified", "htmlHref": "/research/html/integration-plan-migrating-to-the-unified-agent-os-igr2n5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2945 }, { "id": "dream-research-automation-pipeline-evolution-w18t8b", "title": "Dream Research Automation Pipeline — Evolution³", "slug": "dream-research-automation-pipeline-evolution", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/dream-weaver-engine/CREATIVE_EVOLUTION_RESEARCH_PIPELINE_v1.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Generated:** 2026-02-11 **Method:** Evolution³ — three-stage recursive evoflow **Subject:** Full-loop autonomous research triggered by dream evolution", "excerpt": "# Dream Research Automation Pipeline — Evolution³ ### Stage 1: Explore → Stage 2: Compound → Stage 3: Master Plan\n\n**Generated:** 2026-02-11 **Method:** Evolution³ — three-stage recursive evoflow **Subject:** Full-loop autonomous research triggered by dream evolution\n\n### Core Question How do we build an autonomous research engine that makes the dream garden self-sustaining — where dreams don't just grow through LLM reflection but through real-world knowledge acquisition, competitive intelligence, and market validation?\n\n**Concept:** Research isn't a separate pipeline — it's the soil. Every dream draws nutrients from a continuously-updated knowledge base. Instead of triggering research per-dream, build a persistent knowledge graph that dreams passively absorb during evolution.\n\n**Why it works:** Dreams currently evolve in a vacuum — Kimi-K2 reflects on the dream's essence but has no grounding in reality. A living library means every evolution cycle is informed by real-world context without explicit research triggers.", "htmlHref": "/research/html/dream-research-automation-pipeline-evolution-w18t8b.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4121 }, { "id": "motion-autocomplete-architecture-103xwdl", "title": "Motion Autocomplete Architecture", "slug": "motion-autocomplete-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/hef-evolutions/motion-autocomplete-ai-predicts-your-next-physical/ARCHITECTURE.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Workspace document requiring curation.", "excerpt": "## Objective Predict a near-future physical intent (sub-second horizon) and execute environment preparation actions before movement completion.\n\n## Runtime Pipeline 1. **Ingestion (`src/ingestion`)** - Simulated multimodal stream generator emitting a `MotionFrame` per timestep. - Modalities: IMU acceleration/gyroscope, pose reach vector/torso tilt/wrist height, local environment metadata. 2. **Fusion Prediction (`src/engine/predictor.py`)** - Sliding window over recent frames (`window_size`, default 8). - Computes aggregated features: vertical acceleration, turn rate, forward reach, wrist height, torso tilt, planar acceleration. - Scores intents and selects max-confidence class: - `lifting_object` - `turning_around` - `reaching_for_object` - `walking_towards_exit` - `idle` 3. **Context Preparation (`src/context/orchestrator.py`)** - Applies a minimum confidence gate. - Enforces per-intent cooldown to prevent repeated rapid triggers. - Emits structured actions (`target`, `operation`, `priority`, `reason`) for downstream systems. 4. **Presentation (`src/main.py`)** - Human-readable console trace or JSON events for integration.\n\n## Data Contracts - `MotionFrame`: combines `MotionData`, `PoseData`, and `EnvironmentContext`. - `PredictedIntent`: includes `intent_label`, `confidence`, `horizon_ms`, and feature metadata. - `OrchestrationResult`: includes status (`prepared` / `suppressed_*`) and context actions.\n\n## Configuration `config/default.json` - Predictor: `window_size`, `prediction_horizon_ms` - Orchestrator: `min_confidence`, `cooldown_seconds`\n\n## Extension Points - Replace heuristic fusion scores with trained sequence model (LSTM/Transformer). - Feed live streams from Graph Kernel/Perception Mesh endpoints. - Persist predictions/actions to Supabase for online adaptation.", "htmlHref": "/research/html/motion-autocomplete-architecture-103xwdl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 207 }, { "id": "evolution-log-sigil-composer-draw-gestures-to-compose-nko-sigils-learn-1uo9axd", "title": "Evolution Log — Sigil Composer: Draw gestures to compose N'Ko sigils, learn", "slug": "evolution-log-sigil-composer-draw-gestures-to-compose-nko-sigils-learn", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "projects/hef-evolutions/sigil-composer-draw-gestures-to-compose-nko-sigils/EVOLUTION.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Quality Score:** 0.98 **Files Changed:** src/utils/nkoData.ts, src/components/Canvas.tsx, src/App.tsx, src/App.css, EVOLUTION.md **Commits:** feat(hef): expand N'Ko dataset and implement ghosting guide for muscle memory learning **Artifacts:** Enhanced Sigil Composer, Ghosting Guide, Expanded N'Ko Dataset (9 characters) **Next Suggestion:** Implement multi-stroke character support and a \"History\" feature to track progress over time.", "excerpt": "## Generation 6 **Date:** 2026-02-25 **Changes:** - Initialized a React/TypeScript project for the Sigil Composer. - Implemented a drawing canvas for gesture input. - Developed a gesture recognition system using resampling and Euclidean distance matching. - Added a set of N'Ko characters (A, BA, TA) with template paths for learning. - Created a UI that provides real-time feedback on drawing accuracy to facilitate muscle memory learning. - Verified implementation with unit tests for gesture recognition logic. - Configured Vite build pipeline and TypeScript validation.\n\n**Quality Score:** 0.98 **Files Changed:** src/utils/nkoData.ts, src/components/Canvas.tsx, src/App.tsx, src/App.css, EVOLUTION.md **Commits:** feat(hef): expand N'Ko dataset and implement ghosting guide for muscle memory learning **Artifacts:** Enhanced Sigil Composer, Ghosting Guide, Expanded N'Ko Dataset (9 characters) **Next Suggestion:** Implement multi-stroke character support and a \"History\" feature to track progress over time.\n\n**Quality Score:** 0.95 **Files Changed:** package.json, vite.config.ts, tsconfig.json, tsconfig.node.json, index.html, src/main.tsx, src/index.css, src/utils/nkoData.ts, src/utils/gestureRecognizer.ts, src/components/Canvas.tsx, src/App.tsx, src/App.css, src/utils/gestureRecognizer.test.ts, EVOLUTION.md, README.md, .gitignore **Commits:** feat(hef): implement initial sigil composer prototype with N'Ko gesture recognition **Artifacts:** Sigil Composer React App, Gesture Recognition Utility, N'Ko Character Dataset **Next Suggestion:** Expand the N'Ko character dataset and implement a 'ghosting' feature that shows the target character's stroke order as a guide on the canvas.\n\n**Quality Score:** 0.95 **Files Changed:** package.json, vite.config.ts, tsconfig.json, tsconfig.node.json, index.html, src/main.tsx, src/index.css, src/utils/nkoData.ts, src/utils/gestureRecognizer.ts, src/components/Canvas.tsx, src/App.tsx, src/App.css, src/utils/gestureRecognizer.test.ts, EVOLUTION.md, README.md, .gitignore **Commits:** feat(hef): implement initial sigil composer prototype with N'Ko gesture recognition **Artifacts:** Sigil Composer React App, Gesture Recognition Utility, N'Ko Character Dataset **Next Suggestion:** Expand the N'Ko character dataset and implement a 'ghosting' feature that shows the target character's stroke order as a guide on the canvas.\n\n**Quality Score:** 0.98 **Files Changed:** src/utils/nkoData.ts, src/components/Canvas.tsx, src/App.tsx, src/App.css, package.json, README.md, EVOLUTION.md **Commits:** feat(hef): expand N'Ko dataset and implement ghosting guide for muscle memory learning **Artifacts:** Enhanced Sigil Composer React App, Ghosting Guide Feature, Expanded N'Ko Dataset **Next Suggestion:** Implement multi-stroke character support and a", "htmlHref": "/research/html/evolution-log-sigil-composer-draw-gestures-to-compose-nko-sigils-learn-1uo9axd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1730 }, { "id": "linkit-ui-system-1dvpdl3", "title": "LinkIt — UI System", "slug": "linkit-ui-system", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/LinkIt/docs/architecture/UI_SYSTEM.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Document ID:** LINKIT-ARCH-005 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/LinkIt/components/`", "excerpt": "**Document ID:** LINKIT-ARCH-005 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/LinkIt/components/`\n\nLinkIt uses a custom GSAPGlass design system built on top of shadcn/ui, providing a modern glassmorphism aesthetic with smooth GSAP animations.\n\n| Component | File | Description | |-----------|------|-------------| | Button | components/ui/button.tsx | GSAPGlass button variants | | Input | components/ui/input.tsx | Glass input fields | | Card | components/ui/card.tsx | GSAPGlass card | | Toast | components/ui/toast.tsx | Notification toasts | | Skeleton | components/ui/skeleton.tsx | Loading skeletons |\n\n| Component | File | Description | |-----------|------|-------------| | MenuTrigger | components/layout/MenuTrigger.tsx | Floating menu button | | SideMenu | components/layout/SideMenu.tsx | Slide-in navigation | | MenuItem | components/layout/MenuItem.tsx | Menu item with animation | | MenuOverlay | components/layout/MenuOverlay.tsx | Backdrop overlay | | Navigation | components/layout/Navigation.tsx | Main navigation wrapper | | DashboardHeader | components/layout/DashboardHeader.tsx | Dashboard header | | DashboardSidebar | components/layout/DashboardSidebar.tsx | Dashboard sidebar |\n\n| Component | Path | Description | |-----------|------|-------------| | ProfileHeader | components/profile/ProfileHeader.tsx | Public profile header | | LinkCard | components/links/LinkCard.tsx | Featured link display | | AnalyticsChart | components/analytics/AnalyticsChart.tsx | Data visualization | | FontSelector | components/customize/FontSelector.tsx | Font picker | | ColorPicker | components/customize/ColorPicker.tsx | Color selection |", "htmlHref": "/research/html/linkit-ui-system-1dvpdl3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1027 }, { "id": "system-glossary-expo-migration-1yk4irj", "title": "System Glossary: Expo Migration", "slug": "system-glossary-expo-migration", "kind": "research note", "program": "Business Systems", "sourceAnchor": "projects/Meaning-Full-Power/docs/expo-migration/SYSTEM_GLOSSARY.md", "extension": "md", "score": 36, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This glossary defines every core term used throughout the Expo migration project. Each definition specifies: - What the term **is** - What it **is not** - What **layer** it belongs to (conceptual, architectural, runtime, data)", "excerpt": "**Version:** 1.0.0 **Last Updated:** 2026-01-04 **Status:** LOCKED (Phase Zero Complete)\n\nThis glossary defines every core term used throughout the Expo migration project. Each definition specifies: - What the term **is** - What it **is not** - What **layer** it belongs to (conceptual, architectural, runtime, data)\n\n| Layer | Description | Examples | |-------|-------------|----------| | **Conceptual** | Game design and business concepts | Victory Condition, Theme, Synergy | | **Architectural** | System design and structure | View Model, Service Layer, State Store | | **Runtime** | Active execution components | Battle Engine, Ability Execution, Animation | | **Data** | Persistent and transient data structures | Card, Deck, User Profile | | **Infrastructure** | Build, deploy, and operational concerns | EAS Build, OTA Update, CDN |\n\n### Card - **Is:** A digital representation of a wisdom passage with gameplay attributes (power, cost, abilities, themes) - **Is Not:** A physical card (though physical counterparts exist), a generic UI element - **Layer:** Data - **Properties:** id, title, type, rarity, themes, emotionalPower, wisdomCost, abilities - **Expo Equivalent:** TypeScript interface `Card` in `types/card.ts`\n\n### Card Type - **Is:** Classification determining power multiplier and gameplay role - **Is Not:** Visual styling, rarity level - **Layer:** Data - **Values:** Wisdom (1.0x), Poem (1.5x), Reflection (1.2x), Theme (1.3x), Custom (1.0x) - **Expo Equivalent:** TypeScript enum `CardType`", "htmlHref": "/research/html/system-glossary-expo-migration-1yk4irj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1768 }, { "id": "sea-0-4-complete-4f2sua", "title": "SEA-0.4-COMPLETE", "slug": "sea-0-4-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-0.4-COMPLETE.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Workspace document requiring curation.", "excerpt": "## Summary DEP-2 deep audit of all hooks across both ecosystems. Validated existing `hooks-audit.md` against actual source code for all 6 Clawdbot gateway hooks and 13 Claude Code hook registrations. Original audit confirmed accurate. Added §8 (source code validation findings) and §9 (updated recommendations) with 8 code quality issues, 7 undocumented integrations, 4 state coordination risks, and 5 new recommendations.\n\n## Changes - File: `hooks-audit.md` — updated with §8 (DEP-2 Source Code Validation) and §9 (Updated Recommendations). Added code quality issues table, undocumented integrations inventory, scale observations, state coordination risk matrix, Memory Guardian validation, and 5 new recommendations.\n\n## RTD Verification - [x] Structure: `hooks-audit.md` updated in project directory (§8-§9 appended) - [x] Compilation: markdown, no code to compile - [x] Integration: all findings cross-referenced with actual source files in `[home-path]` and `[home-path]` - [x] Content: 8 code quality issues documented with severity; 7 undocumented integrations cataloged; 4 state coordination risks identified; Memory Guardian rules validated as PERFECT MATCH against CLAUDE.md and baselines.json - [x] User Journey: enhanced audit now answers both \"can we safely add sea-router?\" (yes) and \"what needs fixing in existing hooks?\" (8 issues, 5 recommendations) - [x] Deployment: committed with conventional commit\n\n### Blocking Issues for SEA-Router: 1 - Gateway must emit `response:sent` event (not yet implemented)\n\n### Non-Blocking Issues Found: 8 - 3 HIGH severity (legacy hooks — fetch polyfill, plaintext creds, shell injection) - 3 MEDIUM severity (context-injector model override bug, dangerous-skip-permissions, greedy JSON regex) - 2 LOW severity (hardcoded model ID, subprocess-per-message cost)", "htmlHref": "/research/html/sea-0-4-complete-4f2sua.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 292 }, { "id": "sea-1-4-complete-1xb3wbl", "title": "SEA-1.4-COMPLETE", "slug": "sea-1-4-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-1.4-COMPLETE.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` SKILL.md edit detected (mtime + hash) │ ▼ ┌─────────────────────┐ │ skill_versioner.py │ ← bump_skill() records new version │ versions.json │ saves snapshot for rollback │ snapshots/ │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ skill_watcher.py │ ← reload_skill_embedding() swaps single row │ (daemon or cron) │ in embedding-cache.npz └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ reload-signal.json │ ← signals downstream consumers └──────────┬──────────┘ │ ┌─────┴─────┐ ▼ ▼ tier1_router tier2_s", "excerpt": "## Summary Built skill versioning and hot-reload for all 13 SEA skill entities. The versioner tracks SKILL.md content via SHA-256 hashing with semantic versioning (major.minor.patch), maintains snapshots for rollback, and supports diff. The watcher provides polling-based change detection that auto-bumps versions, surgically re-embeds changed skills (single-row cache update), and signals downstream consumers (tier1_router, tier2_scorer) to invalidate their in-memory caches without restart.\n\n## Changes - File: `[home-path]` — **Created.** Core versioning engine: init, check, bump, diff, rollback, history, stale detection. Stores versions.json + snapshots/ per skill in skill-memory. - File: `[home-path]` — **Created.** Polling-based file watcher with daemon mode, one-shot check, and manual reload. Single-row embedding cache updates. Reload signal file for cache invalidation. - File: `[home-path]` — **Created.** 9-test suite covering hash computation, version bumping, init/check/history/diff, reload signals, and all-skill initialization. - File: `[home-path]` — **Modified.** Added in-memory embedding cache with mtime-based auto-reload. Added `get_cache_timestamp()`. `load_embeddings()` now accepts `force_reload` param. - File: `[home-path]` — **Modified.** Added reload signal polling via `_check_reload_signal()` called before every `route_message()`. Consumes signal file and force-reloads embeddings. - File: `[home-path]` — **Modified.** Added profile cache with reload signal invalidation via `_check_profile_reload()`. Changed skills get their cached profiles dropped.\n\n## RTD Verification - [x] Structure: all files present (versioner, watcher, test, plus updates to 3 existing modules) - [x] Compilation: `python3 -c \"import skill_versioner; import skill_watcher\"` — clean - [x] Integration: all 5 SEA modules import cleanly, no broken refs - [x] Content: versioning (init, check, bump, diff, rollback, history), hot-reload (watcher, signal, cache invalidation) - [x] User Journey: `skill_versioner.py check --all` shows all 13 at v1.0.0; `test_versioning.py` 9/9 pass - [x] Deployment: committed with conventional commit", "htmlHref": "/research/html/sea-1-4-complete-1xb3wbl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 352 }, { "id": "linkit-ui-system-r5hkgq", "title": "LinkIt — UI System", "slug": "linkit-ui-system", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "spine/LinkIt/architecture/UI_SYSTEM.md", "extension": "md", "score": 36, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Document ID:** LINKIT-ARCH-005 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/LinkIt/components/`", "excerpt": "**Document ID:** LINKIT-ARCH-005 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/LinkIt/components/`\n\nLinkIt uses a custom GSAPGlass design system built on top of shadcn/ui, providing a modern glassmorphism aesthetic with smooth GSAP animations.\n\n| Component | File | Description | |-----------|------|-------------| | Button | components/ui/button.tsx | GSAPGlass button variants | | Input | components/ui/input.tsx | Glass input fields | | Card | components/ui/card.tsx | GSAPGlass card | | Toast | components/ui/toast.tsx | Notification toasts | | Skeleton | components/ui/skeleton.tsx | Loading skeletons |\n\n| Component | File | Description | |-----------|------|-------------| | MenuTrigger | components/layout/MenuTrigger.tsx | Floating menu button | | SideMenu | components/layout/SideMenu.tsx | Slide-in navigation | | MenuItem | components/layout/MenuItem.tsx | Menu item with animation | | MenuOverlay | components/layout/MenuOverlay.tsx | Backdrop overlay | | Navigation | components/layout/Navigation.tsx | Main navigation wrapper | | DashboardHeader | components/layout/DashboardHeader.tsx | Dashboard header | | DashboardSidebar | components/layout/DashboardSidebar.tsx | Dashboard sidebar |\n\n| Component | Path | Description | |-----------|------|-------------| | ProfileHeader | components/profile/ProfileHeader.tsx | Public profile header | | LinkCard | components/links/LinkCard.tsx | Featured link display | | AnalyticsChart | components/analytics/AnalyticsChart.tsx | Data visualization | | FontSelector | components/customize/FontSelector.tsx | Font picker | | ColorPicker | components/customize/ColorPicker.tsx | Color selection |", "htmlHref": "/research/html/linkit-ui-system-r5hkgq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1027 }, { "id": "researchclawbench-2606-07591v1-1iyofn8", "title": "ResearchClawBench 2606.07591v1", "slug": "researchclawbench-2606-07591v1", "kind": "pdf artifact", "program": "Research Backlog", "sourceAnchor": "code4ai-analysis/papers/ResearchClawBench-2606.07591v1.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/researchclawbench-2606-07591v1-1iyofn8.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "cognitive-twin-research-paper-14svv45", "title": "cognitive twin research paper", "slug": "cognitive-twin-research-paper", "kind": "pdf artifact", "program": "Agents That Account for Themselves", "sourceAnchor": "cognitive-twin-research-paper.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/cognitive-twin-research-paper-14svv45.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "cognitive-twin-theorems-1qn17gq", "title": "cognitive twin theorems", "slug": "cognitive-twin-theorems", "kind": "pdf artifact", "program": "Agents That Account for Themselves", "sourceAnchor": "cognitive-twin-theorems.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/cognitive-twin-theorems-1qn17gq.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "cognitivetwin-v3-cog-rlm-documentation-v7bu1a", "title": "CognitiveTwin V3 COG RLM Documentation", "slug": "cognitivetwin-v3-cog-rlm-documentation", "kind": "pdf artifact", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/CognitiveTwin_V3_COG-RLM_Documentation.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/cognitivetwin-v3-cog-rlm-documentation-v7bu1a.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "anticipation-pipeline-oph0l", "title": "anticipation pipeline", "slug": "anticipation-pipeline", "kind": "pdf artifact", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/architecture/diagrams/pdf/anticipation-pipeline.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/anticipation-pipeline-oph0l.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "audio-engine-14ga5ge", "title": "audio engine", "slug": "audio-engine", "kind": "pdf artifact", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/architecture/diagrams/pdf/audio-engine.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/audio-engine-14ga5ge.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "comp-core-architecture-1jh8d3a", "title": "comp core architecture", "slug": "comp-core-architecture", "kind": "pdf artifact", "program": "Research Backlog", "sourceAnchor": "Comp-Core/docs/architecture/diagrams/pdf/comp-core-architecture.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/comp-core-architecture-1jh8d3a.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "rag-architecture-i4hb1f", "title": "rag architecture", "slug": "rag-architecture", "kind": "pdf artifact", "program": "Research Backlog", "sourceAnchor": "Comp-Core/docs/architecture/diagrams/pdf/rag-architecture.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/rag-architecture-i4hb1f.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "system-overview-1qd7m9w", "title": "system overview", "slug": "system-overview", "kind": "pdf artifact", "program": "Research Backlog", "sourceAnchor": "Comp-Core/docs/architecture/diagrams/pdf/system-overview.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/system-overview-1qd7m9w.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "graph-kernel-paper-v2-qec2wj", "title": "GRAPH KERNEL PAPER V2", "slug": "graph-kernel-paper-v2", "kind": "pdf artifact", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/GRAPH-KERNEL-PAPER-V2.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/graph-kernel-paper-v2-qec2wj.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "graph-kernel-research-paper-1yp8bkw", "title": "GRAPH KERNEL RESEARCH PAPER", "slug": "graph-kernel-research-paper", "kind": "pdf artifact", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/GRAPH-KERNEL-RESEARCH-PAPER.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/graph-kernel-research-paper-1yp8bkw.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "graph-kernel-paper-v2-1ftpqjw", "title": "graph kernel paper v2", "slug": "graph-kernel-paper-v2", "kind": "pdf artifact", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/latex/graph-kernel-paper-v2.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/graph-kernel-paper-v2-1ftpqjw.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "graph-kernel-paper-40xxql", "title": "graph kernel paper", "slug": "graph-kernel-paper", "kind": "pdf artifact", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/latex/graph-kernel-paper.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/graph-kernel-paper-40xxql.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "universal-sigil-framework-bs1uqy", "title": "universal sigil framework", "slug": "universal-sigil-framework", "kind": "pdf artifact", "program": "Research Backlog", "sourceAnchor": "Comp-Core/docs/research/universal-sigil-framework.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/universal-sigil-framework-bs1uqy.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "main-arxiv-submission-fl0i4v", "title": "main — arxiv-submission", "slug": "main-arxiv-submission", "kind": "pdf artifact", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/paper/arxiv-submission/main.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/main-arxiv-submission-fl0i4v.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "cog-rlm-paper-1x1iokg", "title": "cog rlm paper", "slug": "cog-rlm-paper", "kind": "pdf artifact", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/paper/cog-rlm-paper.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/cog-rlm-paper-1x1iokg.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "main-latex-3tkpxw", "title": "main — latex", "slug": "main-latex", "kind": "pdf artifact", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/paper/latex/main.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/main-latex-3tkpxw.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "lume-wood-fabricator-packet-1apz1on", "title": "LUME WOOD FABRICATOR PACKET", "slug": "lume-wood-fabricator-packet", "kind": "pdf artifact", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/wood/LUME_WOOD_FABRICATOR_PACKET.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/lume-wood-fabricator-packet-1apz1on.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "lume-wood-fabricator-packet-v1-tform-1lzowh", "title": "LUME WOOD FABRICATOR PACKET.v1 Tform", "slug": "lume-wood-fabricator-packet-v1-tform", "kind": "pdf artifact", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/wood/LUME_WOOD_FABRICATOR_PACKET.v1-Tform.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/lume-wood-fabricator-packet-v1-tform-1lzowh.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "lume-wood-fabricator-packet-1mmnh4q", "title": "LUME WOOD FABRICATOR PACKET", "slug": "lume-wood-fabricator-packet", "kind": "pdf artifact", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/wood/lume-wood-fabricator-package/LUME_WOOD_FABRICATOR_PACKET.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/lume-wood-fabricator-packet-1mmnh4q.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "mocapanything-v2-end-to-end-motion-capture-for-arbitrary-skeletons-drm06d", "title": "MoCapAnything V2 End to End Motion Capture for Arbitrary Skeletons", "slug": "mocapanything-v2-end-to-end-motion-capture-for-arbitrary-skeletons", "kind": "pdf artifact", "program": "Embodied Trajectory Systems", "sourceAnchor": "MoCapAnything V2 End-to-End Motion Capture for Arbitrary Skeletons.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/mocapanything-v2-end-to-end-motion-capture-for-arbitrary-skeletons-drm06d.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "nko-asr-paper-v2-dld0yk", "title": "nko asr paper v2", "slug": "nko-asr-paper-v2", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko_asr_paper_v2.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/nko-asr-paper-v2-dld0yk.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "nko-theorems-1ymwf7t", "title": "nko theorems", "slug": "nko-theorems", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko_theorems.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/nko-theorems-1ymwf7t.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "main-nko-acoustic-coding-oqln7e", "title": "main — nko-acoustic-coding", "slug": "main-nko-acoustic-coding", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-acoustic-coding/main.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/main-nko-acoustic-coding-oqln7e.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig1-cer-comparison-pwn4b0", "title": "fig1 cer comparison", "slug": "fig1-cer-comparison", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/figures/fig1_cer_comparison.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig1-cer-comparison-pwn4b0.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig2-compositional-generalization-ub3pkx", "title": "fig2 compositional generalization", "slug": "fig2-compositional-generalization", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/figures/fig2_compositional_generalization.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig2-compositional-generalization-ub3pkx.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig2-loss-curves-1o1a583", "title": "fig2 loss curves", "slug": "fig2-loss-curves", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/figures/fig2_loss_curves.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig2-loss-curves-1o1a583.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig3-delta-1huboyi", "title": "fig3 delta", "slug": "fig3-delta", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/figures/fig3_delta.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig3-delta-1huboyi.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig3-vocabulary-expansion-1qp1eu2", "title": "fig3 vocabulary expansion", "slug": "fig3-vocabulary-expansion", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/figures/fig3_vocabulary_expansion.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig3-vocabulary-expansion-1qp1eu2.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig4-data-scale-f9nxvu", "title": "fig4 data scale", "slug": "fig4-data-scale", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/figures/fig4_data_scale.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig4-data-scale-f9nxvu.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig5-expf-compositional-6wfei5", "title": "fig5 expF compositional", "slug": "fig5-expf-compositional", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/figures/fig5_expF_compositional.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig5-expf-compositional-6wfei5.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig6-exph-vocab-expansion-kdvs22", "title": "fig6 expH vocab expansion", "slug": "fig6-exph-vocab-expansion", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/figures/fig6_expH_vocab_expansion.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig6-exph-vocab-expansion-kdvs22.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig7-djoko-quality-1y5uajv", "title": "fig7 djoko quality", "slug": "fig7-djoko-quality", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/figures/fig7_djoko_quality.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig7-djoko-quality-1y5uajv.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper-canonical-nko-agp-20cer-18xitt5", "title": "paper canonical nko agp 20cer", "slug": "paper-canonical-nko-agp-20cer", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/current/paper_canonical_nko_agp_20cer.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper-canonical-nko-agp-20cer-18xitt5.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper2-living-speech-1xjfhw", "title": "paper2 living speech", "slug": "paper2-living-speech", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/current/paper2_living_speech.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper2-living-speech-1xjfhw.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper4-script-advantage-sc5zqj", "title": "paper4 script advantage", "slug": "paper4-script-advantage", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/current/paper4_script_advantage.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper4-script-advantage-sc5zqj.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper5-deployment-vt9zck", "title": "paper5 deployment", "slug": "paper5-deployment", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/current/paper5_deployment.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper5-deployment-vt9zck.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper-01-script-invisibility-p7eozq", "title": "paper — 01-script-invisibility", "slug": "paper-01-script-invisibility", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/01-script-invisibility/paper.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper-01-script-invisibility-p7eozq.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig1-cer-comparison-1pzc39u", "title": "fig1 cer comparison", "slug": "fig1-cer-comparison", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/02-phonemic-evaluation/figures/fig1_cer_comparison.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig1-cer-comparison-1pzc39u.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper-02-phonemic-evaluation-oilwxe", "title": "paper — 02-phonemic-evaluation", "slug": "paper-02-phonemic-evaluation", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/02-phonemic-evaluation/paper.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper-02-phonemic-evaluation-oilwxe.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig1-cer-comparison-13ed9nl", "title": "fig1 cer comparison", "slug": "fig1-cer-comparison", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/03-script-native-asr-anchor/figures/fig1_cer_comparison.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig1-cer-comparison-13ed9nl.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig2-loss-curves-sfmyv4", "title": "fig2 loss curves", "slug": "fig2-loss-curves", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/03-script-native-asr-anchor/figures/fig2_loss_curves.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig2-loss-curves-sfmyv4.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig3-delta-173mir5", "title": "fig3 delta", "slug": "fig3-delta", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/03-script-native-asr-anchor/figures/fig3_delta.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig3-delta-173mir5.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig4-data-scale-1gukawr", "title": "fig4 data scale", "slug": "fig4-data-scale", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/03-script-native-asr-anchor/figures/fig4_data_scale.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig4-data-scale-1gukawr.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper-03-script-native-asr-anchor-dndqzx", "title": "paper — 03-script-native-asr-anchor", "slug": "paper-03-script-native-asr-anchor", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/03-script-native-asr-anchor/paper.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper-03-script-native-asr-anchor-dndqzx.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig5-expf-compositional-ryxxyf", "title": "fig5 expF compositional", "slug": "fig5-expf-compositional", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/04-agp-deployment/figures/fig5_expF_compositional.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig5-expf-compositional-ryxxyf.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig6-exph-vocab-expansion-1ryq0v4", "title": "fig6 expH vocab expansion", "slug": "fig6-exph-vocab-expansion", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/04-agp-deployment/figures/fig6_expH_vocab_expansion.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig6-exph-vocab-expansion-1ryq0v4.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "fig7-djoko-quality-ugd54x", "title": "fig7 djoko quality", "slug": "fig7-djoko-quality", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/04-agp-deployment/figures/fig7_djoko_quality.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/fig7-djoko-quality-ugd54x.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper-04-agp-deployment-pf1jdu", "title": "paper — 04-agp-deployment", "slug": "paper-04-agp-deployment", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/final/04-agp-deployment/paper.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper-04-agp-deployment-pf1jdu.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper4-script-design-advantage-xfe6ys", "title": "Paper4 Script Design Advantage", "slug": "paper4-script-design-advantage", "kind": "pdf artifact", "program": "Research Backlog", "sourceAnchor": "Paper4_Script_Design_Advantage.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper4-script-design-advantage-xfe6ys.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper4-scriptadvantage-297k-11u5tge", "title": "Paper4 ScriptAdvantage 297K", "slug": "paper4-scriptadvantage-297k", "kind": "pdf artifact", "program": "Research Backlog", "sourceAnchor": "Paper4_ScriptAdvantage_297K.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper4-scriptadvantage-297k-11u5tge.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "bwb-business-presentation-v3-4-wall-system-1osb1ke", "title": "BWB Business Presentation V3 4 Wall System", "slug": "bwb-business-presentation-v3-4-wall-system", "kind": "pdf artifact", "program": "Business Systems", "sourceAnchor": "spine/BWB/deck/BWB Business Presentation V3 - 4-Wall System.pdf", "extension": "pdf", "score": 35, "readiness": "research note to curate", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/bwb-business-presentation-v3-4-wall-system-1osb1ke.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "voice-ordering-system-design-19wcefq", "title": "VOICE ORDERING SYSTEM DESIGN", "slug": "voice-ordering-system-design", "kind": "proposal", "program": "Business Systems", "sourceAnchor": "BWB/docs/VOICE_ORDERING_SYSTEM_DESIGN.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The Brews with Beats voice ordering system represents a revolutionary approach to coffee shop queue management and customer experience. By leveraging Apple's latest Speech Analyzer and Voice Processing technologies, we will create an autonomous ordering ecosystem that eliminates traditional lines while optimizing cart routing through intelligent spatial positioning.", "excerpt": "The Brews with Beats voice ordering system represents a revolutionary approach to coffee shop queue management and customer experience. By leveraging Apple's latest Speech Analyzer and Voice Processing technologies, we will create an autonomous ordering ecosystem that eliminates traditional lines while optimizing cart routing through intelligent spatial positioning.\n\nThe voice ordering system transforms the traditional coffee shop experience by deploying iPad-based ordering stations at four strategic corners of the venue. Customers can approach any station, place their order through natural speech, and receive intelligent routing to either Cart A or Cart B based on proximity, queue status, and AI-driven optimization algorithms.\n\nThe system operates on a lineless model where customers naturally distribute throughout the space, reducing congestion and improving flow dynamics. Each iPad station functions as both an independent ordering terminal and an integrated component of the broader Brews with Beats ecosystem.\n\nThe system utilizes Apple's new SpeechAnalyzer API introduced in iOS 18 to provide superior speech-to-text capabilities specifically designed for conversational and distant audio scenarios. Unlike the previous SFSpeechRecognizer, the new SpeechAnalyzer offers enhanced accuracy for coffee shop environments where ambient noise, music, and multiple conversations occur simultaneously.\n\nThe SpeechTranscriber module operates entirely on-device, ensuring customer privacy while providing real-time transcription with volatile results for immediate feedback and finalized results for order processing. The system supports multiple languages automatically and downloads required models through the AssetInventory API as needed.", "htmlHref": "/research/html/voice-ordering-system-design-19wcefq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3279 }, { "id": "privacy-architecture-19mi47m", "title": "Privacy Architecture", "slug": "privacy-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "cognitive-hire/docs/privacy-architecture.md", "extension": "md", "score": 34, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Processing**: 1. Parse conversations into individual prompts with timestamps 2. Strip all named entities (NER pass): names, companies, URLs, emails, phone numbers, addresses 3. Strip code snippets containing credentials, API keys, file paths with usernames 4. Generate embeddings locally (or via privacy-preserving API with no logging) 5. Compute all 6 cognitive metrics locally 6. Cluster prompts into domain topics using embedding similarity 7. Label clusters with generic domain tags (not project-specific names)", "excerpt": "### Layer 0: Local Extraction Runs entirely on the user's machine. No network calls.\n\n**Input**: Raw AI conversation exports (ChatGPT JSON, Claude history, Gemini data)\n\n**Processing**: 1. Parse conversations into individual prompts with timestamps 2. Strip all named entities (NER pass): names, companies, URLs, emails, phone numbers, addresses 3. Strip code snippets containing credentials, API keys, file paths with usernames 4. Generate embeddings locally (or via privacy-preserving API with no logging) 5. Compute all 6 cognitive metrics locally 6. Cluster prompts into domain topics using embedding similarity 7. Label clusters with generic domain tags (not project-specific names)\n\n**Output**: - Metric vectors (6 metrics, each a time series) - Domain topology graph (nodes = generic domain labels, edges = transition frequency) - Embedding centroids per domain (not individual prompt embeddings) - Session metadata (timestamps, durations, no content)\n\n**What NEVER leaves the machine**: - Raw prompt text - AI response text - Individual prompt embeddings (only centroids) - Any personally identifiable information - Project names, company names, people names - Code, credentials, file paths", "htmlHref": "/research/html/privacy-architecture-19mi47m.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 672 }, { "id": "echelon-capture-architecture-1rfnas3", "title": "Echelon Capture Architecture", "slug": "echelon-capture-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/apps/ios/EchelonCapture/docs/ARCHITECTURE.md", "extension": "md", "score": 34, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` Left iPhone Right iPhone Apple Watch (optional) │ │ │ └─────────── WebSocket: /visualization?device_id= ───────────┐ │ cc-mcs │ WebSocket: /ws/latent │ Perform tab ```", "excerpt": "1. **Motion capture** - `MotionStreamer` reads CoreMotion at the configured sample rate - `ComprehensiveSensorManager` can add extra sensors when enabled\n\n2. **Streaming** - Sensor frames are encoded with cc-protocol models - `WebSocketService` sends frames to `/visualization?device_id=`\n\n3. **Perform mode** - `LatentStreamService` subscribes to `/ws/latent?device_id=` - `StrudelEngine` generates audio from `strudel-engine.html`\n\n4. **Recording** - `SessionManager` + `StorageService` write JSONL motion and WAV audio - Sessions stored under `Documents/Sessions//`\n\n- **Views**: Perform, Stream, Record, Settings - **Core services**: MotionStreamer, NetworkService, WebSocketService, LatentStreamService - **Local storage**: SessionManager, StorageService, AudioRecorder", "htmlHref": "/research/html/echelon-capture-architecture-1rfnas3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 163 }, { "id": "cc-protocol-1tcahwp", "title": "cc protocol", "slug": "cc-protocol", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/apps/ios/EchelonCapture/docs/legacy/cc-protocol.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "At the bottom: your body and the sensors. In the middle: LIM-RPS + latent field + a controller model. At the top: Strudel as the musical engine, plus (optionally) a neural texture engine.", "excerpt": "Let’s zoom out and treat this like we’re reviewing the design doc for “Echelon-as-an-instrument,” not just a toy.\n\nYou basically have a **four-layer architecture**, with a possible fifth “neural icing” layer.\n\nAt the bottom: your body and the sensors. In the middle: LIM-RPS + latent field + a controller model. At the top: Strudel as the musical engine, plus (optionally) a neural texture engine.\n\nPhones, watch, AirPods, heart rate. They pump out accelerometer, gyro, gravity, orientation, HR, audio. That’s raw reality.\n\nAll those raw signals go into LIM-RPS. It does not output “gesture labels”; it solves for a fixed point in a latent space: a vector that encodes “what your whole embodied system is doing right now.”", "htmlHref": "/research/html/cc-protocol-1tcahwp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 17996 }, { "id": "the-interview-hlg2sl", "title": "The Interview", "slug": "the-interview", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/concepts/the-interview.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**The Interview** is TrajectoryOS's conversational AI-driven skill discovery and onboarding flow. It serves as the **primary data ingestion mechanism** for the system, transforming natural conversation into structured skill evidence that powers the Life Physics model.", "excerpt": "**The Interview** is TrajectoryOS's conversational AI-driven skill discovery and onboarding flow. It serves as the **primary data ingestion mechanism** for the system, transforming natural conversation into structured skill evidence that powers the Life Physics model.\n\nUnlike traditional forms or surveys, The Interview uses adaptive questioning to uncover both explicit skills (what you know you can do) and tacit knowledge (expertise you may not recognize as valuable). The conversation dynamically adjusts based on user responses, following threads of interest while maintaining comprehensive coverage.\n\nThe Interview solves a fundamental problem: **how do you capture the complexity of human capability without overwhelming users?**\n\nTraditional approaches fail because: - **Forms are tedious**: People abandon 50+ question surveys - **Self-assessment is biased**: Users underestimate rare skills, overestimate common ones - **Context is lost**: A skill without evidence/story lacks actionable value - **Discovery is static**: No exploration of adjacent competencies\n\nThe Interview addresses these by: 1. **Conversational flow**: Natural dialogue, not interrogation 2. **Adaptive depth**: Deep dives where there's substance, quick moves when there's not 3. **Story extraction**: \"Tell me about a time when...\" captures evidence 4. **Confidence modeling**: Bayesian updates based on response quality 5. **Dynamic routing**: Discovers unexpected skills through follow-up questions", "htmlHref": "/research/html/the-interview-hlg2sl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1619 }, { "id": "documentation-audit-pass-1-discovery-inventory-fz21eh", "title": "Documentation Audit - Pass 1: Discovery & Inventory", "slug": "documentation-audit-pass-1-discovery-inventory", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/DOCUMENTATION_AUDIT_PASS1.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date**: December 21, 2025 **Auditor**: System Analysis **Scope**: Complete cc-trajectory documentation ecosystem **Status**: Pass 1 Complete", "excerpt": "**Date**: December 21, 2025 **Auditor**: System Analysis **Scope**: Complete cc-trajectory documentation ecosystem **Status**: Pass 1 Complete\n\n**Total Documentation**: 232 markdown files - **Current Active**: 34 files (824KB in /docs) - **Legacy**: 169 files (in /legacy/cc-tpo-original) - **Service READMEs**: 1 present, 4 missing\n\n**Documentation Health**: **B-** - ✅ Strong foundational and conceptual documentation - ✅ Good planning and architecture docs - ⚠️ Weak operational and service-level docs - ❌ Missing user-facing documentation - ⚠️ Needs consolidation and cleanup (duplicates, outdated content)\n\n**Key Finding**: The documentation provides excellent coverage of vision, architecture, and implementation plans, but has accumulated technical debt through duplication, outdated references, and missing operational guides.\n\n### 1. **\"The Interview\" - Undefined Core Concept** - **Status**: Referenced in multiple documents but not clearly defined - **Impact**: Critical - this appears to be a core feature/concept - **Locations**: user-guide.md, UNIFIED_TRAJECTORYOS_PLAN.md - **Action Required**: Define in dedicated document", "htmlHref": "/research/html/documentation-audit-pass-1-discovery-inventory-fz21eh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2207 }, { "id": "12-1t3zkgy", "title": "12", "slug": "12", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/docs/ui/12.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "To make this practical, think of Echelon’s sound engine as a set of **continuous DSP fields** that the latent pushes and pulls, rather than a stack of on/off effects. Each “part of the lexicon” we defined earlier maps to a particular way you sculpt spectra, time, and dynamics.", "excerpt": "To make this practical, think of Echelon’s sound engine as a set of **continuous DSP fields** that the latent pushes and pulls, rather than a stack of on/off effects. Each “part of the lexicon” we defined earlier maps to a particular way you sculpt spectra, time, and dynamics.\n\nI’ll walk through the major behaviors and tie each one to concrete DSP / synthesis techniques you’d actually implement in the engine.\n\nWhen the tension field in the latent climbs, you want the sound to feel like it’s tightening and pressurizing without necessarily getting louder.\n\nUse dynamic EQ or tilt filters to gradually brighten upper mids while gently attenuating low mids. This doesn’t scream “EQ sweep,” but it makes the spectrum feel more focused and less relaxed.\n\nApply inharmonic enrichment through soft saturation or waveshaping that emphasizes odd/inharmonic partials as tension increases. Tube/tanh-style curves give warmth, harder curves or bit-depth–style non-linearities give more anxiety.", "htmlHref": "/research/html/12-1t3zkgy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 5065 }, { "id": "graph-kernel-design-document-1na6wfr", "title": "Graph Kernel Design Document", "slug": "graph-kernel-design-document", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-graph-kernel/docs/DESIGN.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The Graph Kernel is a **deterministic context construction engine** that transforms raw conversation DAG data into bounded, reproducible context slices suitable for semantic analysis.", "excerpt": "The Graph Kernel is a **deterministic context construction engine** that transforms raw conversation DAG data into bounded, reproducible context slices suitable for semantic analysis.\n\n- Selects relevant turns around an anchor point - Prioritizes by phase importance and salience - Respects budget constraints (node count, radius) - Produces content-derived fingerprints for provenance\n\n- Parse or analyze message content - Make semantic judgments - Learn or adapt from data - Store or persist slices\n\nEvery operation must be deterministic. The same inputs must produce byte-identical outputs across: - Multiple runs in the same session - Multiple sessions on the same machine - Multiple machines with the same code version\n\n**Implementation**: - BTreeMap/BTreeSet instead of HashMap/HashSet - Explicit Ord implementations on all types - Canonical JSON serialization for hashing - No floating-point comparison in ordering logic", "htmlHref": "/research/html/graph-kernel-design-document-1na6wfr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1527 }, { "id": "cc-graph-kernel-2nrszj", "title": "cc-graph-kernel", "slug": "cc-graph-kernel", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-graph-kernel/README.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The Graph Kernel transforms a 107K+ turn conversation DAG into deterministic, replayable context slices. It answers one question:", "excerpt": "The Graph Kernel transforms a 107K+ turn conversation DAG into deterministic, replayable context slices. It answers one question:\n\n1. [Overview](#overview) 2. [Core Contract](#core-contract) 3. [Architecture](#architecture) 4. [Installation](#installation) 5. [Quick Start](#quick-start) 6. [Types Reference](#types-reference) 7. [SlicePolicy v1](#slicepolicy-v1) 8. [Priority Scoring](#priority-scoring) 9. [Context Slicer Algorithm](#context-slicer-algorithm) 10. [Graph Stores](#graph-stores) 11. [SliceExport & Fingerprinting](#sliceexport--fingerprinting) 12. [Determinism Guarantees](#determinism-guarantees) 13. [Integration with CognitiveTwin Bridge](#integration-with-cognitivetwin-bridge) 14. [Testing](#testing) 15. [API Reference](#api-reference)\n\nThe Graph Kernel is the \"context construction engine\" for the semantic kernel stack. It sits between raw conversation data and semantic analysis, providing:\n\n- **Bounded context windows** around any anchor turn - **Phase-aware prioritization** (Synthesis > Planning > Consolidation > Debugging > Exploration) - **Deterministic fingerprints** for reproducibility and provenance - **Salience-weighted expansion** to capture the most important turns first\n\nWithout deterministic context slicing: - \"Same input\" can produce different semantic analyses - Provenance becomes meaningless - Replay and debugging are impossible - Evidence accumulation can't be trusted", "htmlHref": "/research/html/cc-graph-kernel-2nrszj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2614 }, { "id": "ecosystem-integration-cc-semantic-language-1ow20ej", "title": "Ecosystem Integration: cc-semantic-language", "slug": "ecosystem-integration-cc-semantic-language", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/core/semantic/cc-semantic-language/docs/ECOSYSTEM_INTEGRATION.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "`cc-semantic-language` is a **TrajectoryOS component** that bridges **embodied motion dynamics** (from Echelon) with **semantic meaning** (for language processing). It implements the **Trajectory-Symbol Alignment Hypothesis**: that the same anticipatory signals that govern motion can govern language semantics.", "excerpt": "`cc-semantic-language` is a **TrajectoryOS component** that bridges **embodied motion dynamics** (from Echelon) with **semantic meaning** (for language processing). It implements the **Trajectory-Symbol Alignment Hypothesis**: that the same anticipatory signals that govern motion can govern language semantics.\n\n**cc-semantic-language sits at the intersection of:** 1. **Echelon's motion dynamics** (commitment, uncertainty, transition pressure) 2. **TrajectoryOS's semantic memory** (vocabulary, meaning, context) 3. **Python ML training** (model forward passes, ΔZ computation)\n\nIt translates **motion scalars** into **semantic operators**, enabling language to be understood through the same anticipatory lens as movement.\n\n**What**: cc-semantic-language consumes the **7 anticipatory scalars** from `cc-anticipation`:\n\n| Scalar | Used For | Operator Mapping | |--------|----------|------------------| | **Stability** | Operator magnitude | `STABILIZE` operator | | **Commitment** | Semantic commitment | `SCALE` operator | | **Transition Pressure** | State change pressure | `SHIFT` operator | | **Uncertainty** | Completion threshold | `CLOSE` operator | | **Novelty** | Deviation from expected | `INVERT` operator | | **Phase Stiffness** | Coupling strength | `BIND` operator | | **Recovery Margin** | Recursive capacity | `REPEAT` operator |", "htmlHref": "/research/html/ecosystem-integration-cc-semantic-language-1ow20ej.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1587 }, { "id": "gesture-lexicon-1iyiqk2", "title": "Gesture Lexicon", "slug": "gesture-lexicon", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/motion-language/GESTURE_LEXICON.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A comprehensive catalog of gestures recognized by the Comp-Core motion intelligence system. Each gesture is defined by its kinematic signature, anticipation profile, and semantic meaning.", "excerpt": "A comprehensive catalog of gestures recognized by the Comp-Core motion intelligence system. Each gesture is defined by its kinematic signature, anticipation profile, and semantic meaning.\n\n1. [Basic Gestures](#basic-gestures) 2. [Compound Gestures](#compound-gestures) 3. [Full-Body Gestures](#full-body-gestures) 4. [Latent Space Signatures](#latent-space-signatures) 5. [Training Data Requirements](#training-data-requirements)\n\n| Property | Value | |----------|-------| | **Motion** | Translation along negative X axis | | **Velocity Profile** | Bell curve (slow → fast → slow) | | **Acceleration** | Biphasic (positive then negative) |\n\n**Semantic Meanings**: - Navigate back / previous - Dismiss / reject - Move to left context\n\n| Property | Value | |----------|-------| | **Motion** | Translation along positive X axis | | **Velocity Profile** | Bell curve | | **Acceleration** | Biphasic |", "htmlHref": "/research/html/gesture-lexicon-1iyiqk2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2151 }, { "id": "linkedin-the-12-second-voice-note-that-transformed-our-architecture-12ki7d1", "title": "LinkedIn — The 12-Second Voice Note That Transformed Our Architecture", "slug": "linkedin-the-12-second-voice-note-that-transformed-our-architecture", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "content-pipeline/linkedin/2026-02-11-voice-note-protocol.md", "extension": "md", "score": 34, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Opening Hook:** I'd just finished a three-stage recursive analysis of our monetization strategy. Nine iOS apps. Revenue projections. Pricing tiers. A 72-item execution checklist. Then a 12-second voice note at 2 AM invalidated the entire approach.", "excerpt": "**Opening Hook:** I'd just finished a three-stage recursive analysis of our monetization strategy. Nine iOS apps. Revenue projections. Pricing tiers. A 72-item execution checklist. Then a 12-second voice note at 2 AM invalidated the entire approach.\n\nWe'd applied our Evolution³ framework—a three-stage recursive creative evolution process—to figure out monetization for a portfolio of consumer iOS apps. Stage 1 explored divergent paths. Stage 2 compounded them sequentially. Stage 3 stress-tested everything.\n\nThe output was impressive: - Nine apps in a unified bundle at $19.99/month - Premium upsells per app - Break-even at 150 subscribers - 72-week execution timeline\n\nThen two new apps wanted to join. The natural instinct: update the revenue model to accommodate 9 apps. Adjust the numbers.\n\n*\"Why would you add the nine apps when the system should be agnostic to it? It's a standard protocol.\"*", "htmlHref": "/research/html/linkedin-the-12-second-voice-note-that-transformed-our-architecture-12ki7d1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 375 }, { "id": "stage-3-expand-master-plan-16stmqi", "title": "Stage 3: EXPAND + MASTER PLAN", "slug": "stage-3-expand-master-plan", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/graph-native-version-control/stage3-expand-master-plan.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Failure scenario:** The Graph Kernel (Rust, port 8001) crashes or becomes unreachable. All admissibility checks fail. No agent can determine what trajectories it can see. The entire permission model collapses.", "excerpt": "**Failure scenario:** The Graph Kernel (Rust, port 8001) crashes or becomes unreachable. All admissibility checks fail. No agent can determine what trajectories it can see. The entire permission model collapses.\n\n**Probability:** HIGH (single process, no redundancy today, Graph Kernel has had downtime before) **Impact:** CRITICAL (system is blind without it -- agents either see everything or nothing)\n\n**Mitigation:** - **Offline cache:** Each agent caches its most recent `AdmissibleEvidenceBundle` locally. If Graph Kernel is unreachable, agent uses cached bundle (stale but functional). Cache TTL: 5 minutes. - **Fallback policy:** If Graph Kernel is down AND cache is stale, agents fall back to a restrictive \"read-only, own trajectories only\" policy. This prevents over-exposure. - **SQLite WAL backup:** Graph Kernel already supports SQLite backend. Deploy SQLite WAL as read-only fallback on each node. Sync every 60 seconds from Supabase. - **Health probe integration:** Graph Kernel has `/health/ready` endpoint. Wire into existing `infra_watchdog.py` flow. Auto-restart via systemd on failure. Discord alert within 60 seconds.\n\n**Validation criteria:** Simulate Graph Kernel crash. Verify agents continue operating with cached bundles. Verify no trajectory data is exposed beyond the cached slice. Verify auto-restart completes within 120 seconds.\n\n**Failure scenario:** An agent (or its operator) inflates reward scores to win merge conflicts via REWARD_MAX strategy. Since reward scores determine the \"main\" path, inflated scores corrupt the entire version history's integrity.", "htmlHref": "/research/html/stage-3-expand-master-plan-16stmqi.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 6655 }, { "id": "stage-3-expand-master-plan-9vhlkp", "title": "Stage 3: EXPAND + MASTER PLAN", "slug": "stage-3-expand-master-plan", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-commerce-pos/stage3-expand-master-plan.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Primary STT: Deepgram Nova-3 (Cloud Streaming)** - Protocol: WebSocket to wss://api.deepgram.com/v1/listen - Parameters: encoding=linear16, sample_rate=16000, channels=1, model=nova-3, language=en, smart_format=true, keywords=[\"latte:2\",\"cappuccino:2\",\"espresso:2\",\"oat:1.5\",\"almond:1.5\",\"large:1\",\"medium:1\",\"small:1\"] - Partial results: interim_results=true (for live preview) - Latency: ~300ms for first partial, ~500ms for stable transcript - Cost: $0.0043/minute. At 500 orders/month, 30s average = $1.08/month. -", "excerpt": "# Stage 3: EXPAND + MASTER PLAN ## LUME Commerce -- Experiential Commerce Infrastructure\n\n### R1: GPU Contention During Voice Processing [CRITICAL] - **Failure scenario:** When Whisper.cpp fallback activates (WiFi down), the CUDA inference burst (~2-3 seconds) steals GPU cycles from the visual pipeline. Frame rate drops from 60fps to 20-30fps. All customers see the stutter, not just the person ordering. The entertainment experience degrades. - **Probability:** MEDIUM (35%). Only triggers when WiFi is down AND local Whisper is needed. In normal operation (Deepgram cloud STT), zero GPU impact. - **Impact:** MEDIUM-HIGH. Visual stutter during ordering creates a jarring experience. If WiFi is frequently unreliable, this becomes a persistent problem. - **Mitigation:** (a) Pre-warm Whisper model at boot but don't run inference until needed. (b) During Whisper inference, reduce visual pipeline to 30fps (skip every other frame, doubling GPU headroom). This is imperceptible to customers vs stuttery 45fps. (c) Batch audio: accumulate 5-10s of audio, process in one burst, return to 60fps. (d) Long-term: Whisper-TensorRT optimization gives 3x speedup, reducing contention window. - **Validation criteria:** Visual pipeline maintains >30fps during Whisper inference burst. No visible stutter reported by 3 out of 3 test observers in blind test.\n\n### R2: Voice Ordering Accuracy in Coffee Shop Noise [CRITICAL] - **Failure scenario:** Background noise (espresso machine 70-80 dB, conversations 55-65 dB, music 60-70 dB) degrades STT accuracy below 70%. Customers repeat orders 2-3 times. Frustration kills adoption. Baristas override voice orders manually, defeating the purpose. - **Probability:** LOW with Deepgram (15%), MEDIUM-HIGH with local Whisper (40%) - **Impact:** CRITICAL. If voice ordering doesn't work, the entire Commerce tier value proposition fails. - **Mitigation:** (a) Audio preprocessing: 3-mic beamforming (directional pickup toward customer, null toward espresso machine), noise gate, band-pass 200-4kHz, AGC. (b) Deepgram Nova-3 primary (trained on millions of hours of noisy real-world audio). (c) Domain-specific vocabulary hints sent to Deepgram (coffee menu terms as keywords parameter). (d) Local Whisper as degraded fallback only. (e) Touch fallback: LUME display shows order suggestions from partial transcript, customer taps to confirm. Never force voice-only. - **Validation criteria:** >85% order accuracy (correct items + modifiers) in 70 dB ambient noise, measured over 100 test orders with varied accents and speaking styles.\n\n### R3: Content Flywheel Adoption Rate [MEDIUM] - **Failure scenario:** Customers don't interact with LUME visuals during queue time. They stare at their phones. QR scan rate is <5%. Zero viral content. The entertainment-as-marketin", "htmlHref": "/research/html/stage-3-expand-master-plan-9vhlkp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 5996 }, { "id": "research-stacks-appchain-architecture-deep-technical-analysis-1nxzbqx", "title": "Research: Stacks Appchain Architecture -- Deep Technical Analysis", "slug": "research-stacks-appchain-architecture-deep-technical-analysis", "kind": "architecture", "program": "Protocol and Compute", "sourceAnchor": "evo-cube-output/stacks-appchain-research.md", "extension": "md", "score": 34, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Stacks appchains are independent blockchain instances that use the same protocol, transaction format, and Clarity smart contract language as the main Stacks chain, but mine on top of Stacks (or another appchain) rather than Bitcoin directly. They inherit Bitcoin's security through a hierarchical Proof of Transfer (PoX) chain: Bitcoin -> Stacks -> Appchain. The stacks-core codebase is a large Rust monorepo (~94% Rust, 31K+ commits, 135 contributors, GPL v3) with 12+ crates. Forking it is feasible but non-trivial -- ", "excerpt": "Stacks appchains are independent blockchain instances that use the same protocol, transaction format, and Clarity smart contract language as the main Stacks chain, but mine on top of Stacks (or another appchain) rather than Bitcoin directly. They inherit Bitcoin's security through a hierarchical Proof of Transfer (PoX) chain: Bitcoin -> Stacks -> Appchain. The stacks-core codebase is a large Rust monorepo (~94% Rust, 31K+ commits, 135 contributors, GPL v3) with 12+ crates. Forking it is feasible but non-trivial -- the complexity is comparable to forking Bitcoin Core or Geth, not a simple SDK instantiation like Cosmos. Adding custom first-class features (like GPU compute proof / APOP) is technically possible at the Clarity VM level, the consensus level, and the boot code level, but requires deep Rust engineering in the stacks-core codebase.\n\nAn appchain is a **separate Stacks blockchain instance** that uses Stacks (or another appchain) as its \"host chain\" instead of Bitcoin directly. Every appchain is a full Stacks blockchain -- same protocol, same transaction format, same Clarity VM, everything.\n\n> \"Appchains are just more Stacks blockchains with the same protocol, same transaction format, and same Clarity smart contract language as the main Stacks chain.\" -- Jude Nelson (Stacks Foundation Lead)\n\n| Degree | Chain | Host Chain | |--------|-------|------------| | 0 | Bitcoin | (base layer) | | 1 | Stacks | Bitcoin | | 2 | Appchain | Stacks | | 3+ | Appchain-on-appchain | Another appchain |\n\nThe system supports approximately **4.2 billion total appchains** organized in tiers, with logarithmic separation degrees between any appchain and Bitcoin.", "htmlHref": "/research/html/research-stacks-appchain-architecture-deep-technical-analysis-1nxzbqx.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 3076 }, { "id": "skill-ecosystem-index-codex-17lz5hl", "title": "Skill Ecosystem Index (Codex)", "slug": "skill-ecosystem-index-codex", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/SKILL-INDEX-CODEX.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Workspace document requiring curation.", "excerpt": "## Scope - Audited root: `Desktop/homelab/clawdbot/skills/` - Files read: **111 SKILL.md files** (symlink-following scan via `find -L`) - Method: full-file parse + similarity analysis + manual calibration for quality grades\n\n## Quality Rubric (A-F) - **A**: Operationally mature, explicit workflows, integrations, and usable commands - **B**: Strong and actionable, but with overlap, bloat, or update risk - **C**: Usable, but partial depth/validation/coverage - **D**: Conceptual/template-heavy, low execution detail - **E**: Thin and/or outdated, should be revised before routine use\n\n## Snapshot - Grade distribution: A=11, B=38, C=18, D=42, E=2, F=0 - Highest quality concentration: reliability/self-healing, dream systems, memory/docs - Lowest quality concentration: micro-technique libraries (many conceptual persona specs)\n\n## Full Taxonomy ### Cognitive Method Library (36) - `art:synthesis/SKILL.md` — **C** - `sys:ascii/SKILL.md` — **C** - `sys:mindmap/SKILL.md` — **C** - `sys:plan/SKILL.md` — **C** - `sys:research/SKILL.md` — **C** - `thk:topology/SKILL.md` — **C** - `art:convergent/SKILL.md` — **D** - `art:creative/SKILL.md` — **D** - `art:divergent/SKILL.md` — **D** - `art:movement/SKILL.md` — **D** - `art:snark/SKILL.md` — **D** - `lin:deconstructor/SKILL.md` — **D** - `lin:nko/SKILL.md` — **D** - `lin:synthesizer/SKILL.md` — **D** - `lin:target/SKILL.md` — **D** - `lng:french/SKILL.md` — **D** - `lng:ull/SKILL.md` — **D** - `nav:nonlinear/SKILL.md` — **D** - `nav:organic/SKILL.md` — **D** - `nav:perspective/SKILL.md` — **D** - `phi:metaphysical/SKILL.md` — **D** - `phi:paradox/SKILL.md` — **D** - `phi:veritas/SKILL.md` — **D** - `pwr:diomande/SKILL.md` — **D** - `pwr:eureka/SKILL.md` — **D** - `pwr:infinite/SKILL.md` — **D** - `pwr:morph/SKILL.md` — **D** - `pwr:power/SKILL.md` — **D** - `syn:core/SKILL.md` — **D** - `syn:emergent/SKILL.md` — **D** - `syn:fusion/SKILL.md` — **D** - `syn:radical/SKILL.md` — **D** - `sys:algebra/SKILL.md` — **D** - `thk:chaos/SKILL.md` — **D** - `thk:fractal/SKILL.md` — **D** - `thk:quantum/SKILL.md` — **D**\n\n### Creativity Framework Library (8) - `adi/SKILL.md` — **B** - `evo:evolve/SKILL.md` — **B** - `evoflow/SKILL.md` — **B** - `spf/SKILL.md` — **B** - `tie/SKILL.md` — **B** - `tie:dist/SKILL.md` — **B** - `tie:gen/SKILL.md` — **B** - `tie:ref/SKILL.md` — **B**", "htmlHref": "/research/html/skill-ecosystem-index-codex-17lz5hl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3100 }, { "id": "e521-duncan-fewkes-reel-analysis-digest-19n06sc", "title": "E521 — Duncan Fewkes reel analysis digest", "slug": "e521-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E521-DT6IlEfig-k.md", "extension": "md", "score": 34, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, D", "excerpt": "Source video: `../reels/E521-DT6IlEfig-k.mp4` (symlink to `[home-path]`) Caption: `../reels/E521-DT6IlEfig-k.txt`\n\nThis file aggregates every playbook chunk section that cites E521. Sections are de-duplicated by heading.\n\n- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, DT6IlEfig-k, DTBUJiDCvPQ, DScEatyilnk). DSfZYMUChIi + DSZmIhOCrTv hit Gemini 429 quota exhaustion; captions on those are still detailed.\n\nThe recent playbook only exposed `Multiparticle_Spine_FX` and `slime/water/chrome` material names. E521's screen recording shows the actual UI panel cycling through every preset. Update the LUME `LumeVfxEditor.cs` slot enums to match:\n\n### `Depth:` slot (the surface visual on the human silhouette) - `GhostChromatic2` — translucent particle-filled ghost, chromatic aberration on edges - `GlassThin` — thin refractive glass sculpture - `GlassThick` — solid heavy glass form - `GlassScan1` / `GlassScan2` / `GlassScan3` — three styles of scan-line / fragmented glass - (E520 reveals) `DepthCubes` with a runtime LOD randomizer — VFX Graph mesh particles fed by live depth buffer, audio-reactive trigger script flips LOD level on beat", "htmlHref": "/research/html/e521-duncan-fewkes-reel-analysis-digest-19n06sc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3015 }, { "id": "e567-duncan-fewkes-reel-analysis-digest-1xlqpib", "title": "E567 — Duncan Fewkes reel analysis digest", "slug": "e567-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E567-DV3xj7XCoCT.md", "extension": "md", "score": 34, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)", "excerpt": "Source video: `../reels/E567-DV3xj7XCoCT.mp4` (symlink to `[home-path]`) Caption: `../reels/E567-DV3xj7XCoCT.txt`\n\nThis file aggregates every playbook chunk section that cites E567. Sections are de-duplicated by heading.\n\n- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)\n\nE527, E544, E532, E544 (DUSui7PioUD, DU-52fcinww, DUgoDHlipPu) all confirm Duncan ships into a **branded \"Holovis®\" CAVE / wide LED installation venue**. This is not lab work, this is **a live commercial installation product**. Implications for LUME:\n\n- The visuals are tuned for a wide curved LED CAVE (multi-panel) — but he is now porting to a flat 17m × 3m screen (E567 caption). LUME's 1-3 vertical monitors is a smaller close-cousin of \"flat 17m × 3m\". - Each install gets per-site calibration — he literally calls out: *\"need to rebalance threshold etc values for the actual usage distance — probably easiest to expose in settings and debug menu to allow for tweak values for each install individually\"* (E568). **LUME action**: ship a per-install settings file (motion threshold, depth-camera distance, smoothing) loaded from disk, exposable via debug menu. - The Holovis logo is itself one of the VFX targets — a \"Logo:\" preset slot on the VFX editor (we already had this in the prior playbook). New twist below.", "htmlHref": "/research/html/e567-duncan-fewkes-reel-analysis-digest-1xlqpib.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3688 }, { "id": "stage-4-forge-firstdate-architecture-18iiy1d", "title": "Stage 4: FORGE — FirstDate Architecture", "slug": "stage-4-forge-firstdate-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "omega-output/firstdate-rebuild-20260320/04-architecture.md", "extension": "md", "score": 34, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Core principle:** The deal IS the episode. A restaurant sponsorship deal produces one episode. An episode fulfills one deal. They share a lifecycle.", "excerpt": "One app. Two experiences. One host, many applicants, episodic content, real money tracking.\n\n**Core principle:** The deal IS the episode. A restaurant sponsorship deal produces one episode. An episode fulfills one deal. They share a lifecycle.\n\n### Host Tabs (Mohamed) 1. **Inbox** — Application review (approve/pass/shortlist) 2. **Pipeline** — Deal CRM (Lead → Pitched → Confirmed → Filmed → Published → Invoiced) 3. **Schedule** — 10-week calendar grid (deal + talent + budget per week) 4. **Ledger** — P&L with expense/revenue categorization 5. **Studio** — Consent manager + pre-shoot checklist + episode content links\n\n### Public Tabs (Women / Audience) 1. **Series** — Published episodes (poster cards, content links, restaurant featured) 2. **Apply** — Application form (photo, bio, Instagram, why-me, consent acknowledgment) 3. **Spots** — Restaurant catalog with \"Featured in Episode X\" badges 4. **Status** — Application status tracker (pending → reviewing → selected/not selected) 5. **Chat** — DMs with Mohamed (unlocked after selection)\n\n| Service | Responsibility | |---------|---------------| | **ApplicationManager** | Fetch/filter/approve/reject/shortlist applications | | **EpisodeManager** | Full episode lifecycle: plan → cast → schedule → film → edit → publish. Also handles deal pipeline stages. | | **ConsentManager** | Generate consent form, capture signature (PencilKit canvas), upload to Storage, create record | | **LedgerManager** | Income/expense CRUD, per-episode P&L, series P&L, category breakdown | | **WardrobeManager** | Wardrobe item CRUD, outfit assembly per episode | | **ScheduleManager** | 10-week plan computation from episodes, budget allocation per week | | **ChecklistManager** | Pre-shoot validation: consent signed? Reservation confirmed? Phone charged? Outfit logged? |", "htmlHref": "/research/html/stage-4-forge-firstdate-architecture-18iiy1d.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1780 }, { "id": "trajectoryos-desktop-implementation-proposal-qu6jq1", "title": "TrajectoryOS Desktop Implementation Proposal", "slug": "trajectoryos-desktop-implementation-proposal", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/05-research/TRAJECTORYOS_DESKTOP_PROPOSAL.md", "extension": "md", "score": 34, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "**Project**: TrajectoryOS Desktop Version **Date**: December 21, 2025 **Author**: Analysis based on comprehensive codebase exploration **Status**: Proposal", "excerpt": "**Project**: TrajectoryOS Desktop Version **Date**: December 21, 2025 **Author**: Analysis based on comprehensive codebase exploration **Status**: Proposal\n\nThis document proposes a **native macOS desktop application** for TrajectoryOS, leveraging 80% code reuse from the existing iOS Swift codebase while adding desktop-specific enhancements. The desktop version will maintain the same sophisticated life physics engine, ring memory system, and RAG++ recommendations while offering superior visualization, analytics, and productivity features enabled by larger displays and desktop workflows.\n\n**Alternative Options**: Electron/Web-based app or Cross-Platform (Flutter/React Native)\n\nTrajectoryOS is an **AI-powered life trajectory optimization platform** that treats personal development as a physics problem. It combines:\n\n1. **Life Physics Model**: Computes an \"Escape Index\" (η) representing life momentum 2. **Ring Memory System**: Circular context propagation inspired by computational choreography 3. **RAG++ Recommendations**: Evidence-based action suggestions from historical patterns 4. **Advanced Embeddings**: IRCP/TPO/RCP for semantic understanding", "htmlHref": "/research/html/trajectoryos-desktop-implementation-proposal-qu6jq1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3573 }, { "id": "serenity-soother-evolution-synthesis-2cxzr0", "title": "Serenity Soother — Evolution Synthesis", "slug": "serenity-soother-evolution-synthesis", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "Serenity Soother/EVOLUTION_SYNTHESIS.md", "extension": "md", "score": 34, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Evolution ID:** `evo_ss_20260209_synthesis` **Generated:** February 9, 2026 **Techniques Applied:** G01-G20, R01-R18, D01-D16 + 10 Synthesis Methods", "excerpt": "# Serenity Soother — Evolution Synthesis ## TIE Creative Framework + Multi-Dimensional Synthesis\n\n**Evolution ID:** `evo_ss_20260209_synthesis` **Generated:** February 9, 2026 **Techniques Applied:** G01-G20, R01-R18, D01-D16 + 10 Synthesis Methods\n\n## G01: Random Word Catalyst **Skill Stack:** `lin:synthesizer → thk:chaos → art:divergent`\n\n**Mirror Meditation** - The app becomes a *mirror* for the self - Scenes reflect user's current emotional state - AI generates \"reflection scenes\" — what your inner world looks like today - *\"See yourself in the forest. See the forest in yourself.\"*\n\n**Tidal Sessions** - Sessions that ebb and flow like tides - Beginning: gentle approach (low tide) - Middle: deep immersion (high tide) - End: gradual retreat (receding tide) - Biometric sync: breathing becomes the tide", "htmlHref": "/research/html/serenity-soother-evolution-synthesis-2cxzr0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3297 }, { "id": "voice-ordering-system-technical-documentation-hhx8to", "title": "Voice Ordering System - Technical Documentation", "slug": "voice-ordering-system-technical-documentation", "kind": "research note", "program": "Business Systems", "sourceAnchor": "BWB/docs/VOICE_SYSTEM_TECHNICAL_DOCS.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The BrewsWithBeats voice ordering system uses a hybrid architecture combining: - **iOS 26 SpeechAnalyzer** for on-device transcription - **Semantic embeddings** for accurate menu matching - **Confidence-based clarification** for reliable order capture - **YAML constraints** for menu rule validation", "excerpt": "The BrewsWithBeats voice ordering system uses a hybrid architecture combining: - **iOS 26 SpeechAnalyzer** for on-device transcription - **Semantic embeddings** for accurate menu matching - **Confidence-based clarification** for reliable order capture - **YAML constraints** for menu rule validation\n\n**Location:** `BWBCore/Sources/BWBCore/Voice/Embeddings/MenuEmbeddingService.swift`\n\n**Purpose:** Find menu items using semantic similarity instead of exact text matching.\n\n**How it works:** 1. Converts menu items to vector embeddings (300-dimensional) 2. Converts user's speech to a vector 3. Finds closest matches using cosine similarity 4. Combines with fuzzy matching for robustness\n\n**Configuration:** - Hybrid weight: 60% semantic + 40% fuzzy - Uses Apple's NLEmbedding (built-in, no external dependencies)", "htmlHref": "/research/html/voice-ordering-system-technical-documentation-hhx8to.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1629 }, { "id": "phase-2-real-time-interview-infrastructure-1d4qkil", "title": "Phase 2: Real-Time & Interview Infrastructure ✅", "slug": "phase-2-real-time-interview-infrastructure", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/trajectory/trajectory-desktop/docs/legacy/PHASE2_COMPLETE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Phase 2 successfully delivers production-grade **real-time state management, WebSocket infrastructure, and a complete interview system** for TrajectoryOS Desktop.", "excerpt": "**Status**: Complete **Duration**: Phase 2 **Completion Date**: December 21, 2025\n\nPhase 2 successfully delivers production-grade **real-time state management, WebSocket infrastructure, and a complete interview system** for TrajectoryOS Desktop.\n\n1. ✅ **State Management** - Zustand stores with persistence 2. ✅ **Server State** - React Query integration for all APIs 3. ✅ **Real-Time Updates** - WebSocket manager with auto-reconnect 4. ✅ **Interview System** - Complete conversational UI 5. ✅ **Dashboard** - Real-time data visualization\n\n**Key Features:** - **Persist middleware** for auth and UI state (localStorage) - **JWT auto-refresh** with token manager integration - **Interview state** with message history and skill extraction - **Toast system** with auto-dismiss - **Theme management** (dark/light mode) - **Sync status tracking** for offline/online states\n\n**Key Features:** - **Query key factory** for consistent cache management - **Default options** (staleTime, cacheTime, retry strategy) - **DevTools integration** (development only) - **Automatic retries** with exponential backoff - **Garbage collection** after 5 minutes of inactivity", "htmlHref": "/research/html/phase-2-real-time-interview-infrastructure-1d4qkil.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1981 }, { "id": "orb-2-1-prometheus-metrics-endpoint-x6mpkx", "title": "ORB-2.1: Prometheus /metrics Endpoint", "slug": "orb-2-1-prometheus-metrics-endpoint", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/trajectory/trajectory-orbit/ORB-2.1-COMPLETE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Metric | Type | Description | |--------|------|-------------| | `orbit_project_count` | Gauge | Total registered projects | | `orbit_active_sessions` | Gauge | Active Claude sessions | | `orbit_websocket_connections` | Gauge | Connected WebSocket clients | | `orbit_api_requests_total` | Counter | API requests (labels: method, path, status) | | `orbit_query_latency_seconds` | Histogram | Query latency in seconds (label: operation) |", "excerpt": "Added a `/metrics` endpoint to the Orbit server exposing Prometheus text exposition format.\n\n### Dependencies added - `metrics = \"0.24\"` (workspace) - `metrics-exporter-prometheus = \"0.16\"` with `http-listener` feature (workspace)\n\n### Files changed - `Cargo.toml` — workspace dependency declarations - `crates/orbit-server/Cargo.toml` — server-level dependency references - `crates/orbit-server/src/metrics.rs` — **NEW** metrics module - `crates/orbit-server/src/main.rs` — wired module, AppState field, recorder init, route\n\n| Metric | Type | Description | |--------|------|-------------| | `orbit_project_count` | Gauge | Total registered projects | | `orbit_active_sessions` | Gauge | Active Claude sessions | | `orbit_websocket_connections` | Gauge | Connected WebSocket clients | | `orbit_api_requests_total` | Counter | API requests (labels: method, path, status) | | `orbit_query_latency_seconds` | Histogram | Query latency in seconds (label: operation) |\n\n### Helper functions provided - `record_api_request(method, path, status)` — increment request counter - `record_query_latency(operation, start)` — record histogram observation", "htmlHref": "/research/html/orb-2-1-prometheus-metrics-endpoint-x6mpkx.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 185 }, { "id": "quick-start-guide-voice-control-system-1h32uyh", "title": "Quick Start Guide - Voice Control System", "slug": "quick-start-guide-voice-control-system", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/voice_control/QUICKSTART.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The voice control system now includes an **Auto DJ** feature that automatically mixes tracks with intelligent transitions and effects!", "excerpt": "The voice control system now includes an **Auto DJ** feature that automatically mixes tracks with intelligent transitions and effects!\n\n2. **Add Tracks** (programmatically or via Serato): - Tracks are automatically analyzed when added - Analysis includes BPM, key, energy levels, drops, and breakdowns\n\n4. **Control Auto DJ**: - **\"stop auto dj\"** - Stop automatic mixing - **\"pause auto dj\"** / **\"resume auto dj\"** - Pause/resume - **\"skip track\"** - Skip to next track - **\"set auto dj mode harmonic\"** - Change mixing strategy - **\"show queue\"** - View current queue - **\"clear queue\"** - Clear all tracks\n\n- **harmonic**: Key-based mixing (Camelot wheel) - **bpm**: BPM matching - **energy**: Energy level matching - **composite**: Balanced combination (default) - **random**: Random selection\n\n2. **Get Gemini API Key** - Visit: https://ai.google.dev/ - Create an API key - Add it to `.env` file:", "htmlHref": "/research/html/quick-start-guide-voice-control-system-1h32uyh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 758 }, { "id": "trajectoryos-python-typescript-integration-complete-4kbk87", "title": "TrajectoryOS - Python-TypeScript Integration Complete ✨", "slug": "trajectoryos-python-typescript-integration-complete", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/guides/IMPLEMENTATION_SUMMARY.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The Python modeling stack has been successfully integrated with the TypeScript backend services. All 6 Python models are now accessible via REST API, with type-safe TypeScript clients handling the communication.", "excerpt": "The Python modeling stack has been successfully integrated with the TypeScript backend services. All 6 Python models are now accessible via REST API, with type-safe TypeScript clients handling the communication.\n\n#### LifeStateService - 558 lines **Location**: `services/trajectory-core/src/services/LifeStateService.ts`\n\n**New Methods**: - `forecastTrajectory()` - Forecast life trajectory over time using Python dynamics model - `estimateEscapeTime()` - Monte Carlo simulation to estimate time to goal achievement - `computePhysicsWithPython()` - Compute alignment, gravity, mass using Python models - `recomputeStateWithPython()` - Full state recomputation and persistence\n\n**Key Features**: - Calls Python for alignment scoring (semantic embeddings) - Calls Python for gravity/mass estimation (constraint analysis) - Calls Python for trajectory forecasting (state space dynamics) - Graceful fallback to simple heuristics if Python unavailable - Persists all computed states to SQLite database\n\n#### PlannerService - 578 lines **Location**: `services/trajectory-core/src/services/PlannerService.ts`", "htmlHref": "/research/html/trajectoryos-python-typescript-integration-complete-4kbk87.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1635 }, { "id": "python-typescript-integration-guide-e64qs5", "title": "Python ↔ TypeScript Integration Guide", "slug": "python-typescript-integration-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/guides/INTEGRATION_GUIDE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A single FastAPI server exposing all 6 model subsystems: - Skill Graph (Bayesian inference + message passing) - Alignment Scorer - Gravity/Mass Estimator - Life State Dynamics - Echelon Fusion - Scenario Generator & Evaluator", "excerpt": "### 1. Python FastAPI Server (`models/api/server.py`) **Status**: ✅ Complete - Ready to run\n\nA single FastAPI server exposing all 6 model subsystems: - Skill Graph (Bayesian inference + message passing) - Alignment Scorer - Gravity/Mass Estimator - Life State Dynamics - Echelon Fusion - Scenario Generator & Evaluator\n\n### 2. TypeScript Python Client (`services/trajectory-core/src/python/`) **Status**: ✅ Complete\n\n**Files**: - `client.ts` - Main HTTP client class - `types.ts` - TypeScript types matching Python models - `index.ts` - Exports\n\n**Changes**: - Calls `pythonClient.updateSkillBelief()` for each piece of evidence - Calls `pythonClient.propagateBeliefUpdate()` to propagate through graph - Stores Bayesian posterior (mean, std) in database - Fallback to simple averaging if Python API unavailable", "htmlHref": "/research/html/python-typescript-integration-guide-e64qs5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1852 }, { "id": "trajectoryos-project-status-report-5kah8c", "title": "TrajectoryOS - Project Status Report", "slug": "trajectoryos-project-status-report", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/guides/PROJECT_STATUS.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**What We Have**: Fully functional TypeScript-based life physics engine with web dashboard **What's Missing**: AI-powered features (interview, agents), Python ML models, Echelon integration **Critical Path**: LLM integration for Interview → Background analysis agents → Echelon embodied signals", "excerpt": "# TrajectoryOS - Project Status Report **Last Updated**: December 21, 2025 **Phase**: 1 (Core Life Physics Implementation)\n\n**What We Have**: Fully functional TypeScript-based life physics engine with web dashboard **What's Missing**: AI-powered features (interview, agents), Python ML models, Echelon integration **Critical Path**: LLM integration for Interview → Background analysis agents → Echelon embodied signals\n\n**Current State**: ~50% Complete (Honest Assessment) - ✅ **Life Physics Engine**: **100%** (TypeScript implementation, production-ready) - ✅ **State Management**: **100%** (Prisma, database, API endpoints) - ✅ **Web Dashboard**: **85%** (functional UI, needs polish) - 🚧 **Interview System**: **20%** (endpoints exist, no LLM) - 🔮 **Python ML Models**: **0%** (designed but not built) - 🔮 **Echelon Integration**: **0%** (stub service only)\n\nThe core life physics model is fully implemented in TypeScript and production-ready:\n\n### 1. Physics Calculations ✅ - **Escape Index**: `η = T / (G × M)` where T includes alignment - **Thrust Computation**: `T = A × Σ(skill_level × utilization × weight)` - **Regime Detection**: Falling, Approaching, Threshold, Escaping, Free - **Escape Velocity**: Rate of change in η over time", "htmlHref": "/research/html/trajectoryos-project-status-report-5kah8c.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2423 }, { "id": "rag-retrieval-augmented-generation-plus-plus-1xe6wh2", "title": "RAG++ (Retrieval-Augmented Generation Plus Plus)", "slug": "rag-retrieval-augmented-generation-plus-plus", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/guides/RAG_PLUS_PLUS.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "RAG++ is TrajectoryOS's state-based retrieval and policy recommendation system. Unlike traditional RAG which retrieves \"relevant chunks,\" RAG++ retrieves **successful state transitions** from similar life regimes and recommends actions based on what worked in the past.", "excerpt": "RAG++ is TrajectoryOS's state-based retrieval and policy recommendation system. Unlike traditional RAG which retrieves \"relevant chunks,\" RAG++ retrieves **successful state transitions** from similar life regimes and recommends actions based on what worked in the past.\n\n| Aspect | Traditional RAG | TrajectoryOS RAG++ | |--------|----------------|-------------------| | **Unit of Retrieval** | Text chunks | State transitions (events-as-nodes-in-life-graph) | | **Relevance** | Semantic similarity | Semantic + topological + dynamical state + phase | | **What It Returns** | Documents/passages | Successful transitions with action patterns | | **Generator Output** | Summarize/Answer | Strategic intervention recommendations | | **Geometry** | 1D (semantic) | 3D (topological + temporal + dynamical) |\n\n### 1. State Estimator ([StateEstimator.ts](../../services/trajectory-core/src/services/StateEstimator.ts))\n\n**Key Functions**: - `estimateState()` - Physics → CurrentState - `compareStates()` - Similarity scoring (0-1) - `computeTimeOfDay()` - Extract phase from timestamp\n\n### 2. Action Classifier ([ActionClassifier.ts](../../services/trajectory-core/src/services/ActionClassifier.ts))", "htmlHref": "/research/html/rag-retrieval-augmented-generation-plus-plus-1xe6wh2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1445 }, { "id": "trajectoryos-cc-tpo-integration-plan-1p341fi", "title": "TrajectoryOS ↔ CC-TPO Integration Plan", "slug": "trajectoryos-cc-tpo-integration-plan", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/guides/TRAJECTORY_TPO_INTEGRATION.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**TrajectoryOS** models life as a dynamical system with escape velocity mechanics - tracking skills, projects, constraints, and computing a \"can you escape your current gravity well?\" metric.", "excerpt": "**Date**: December 15, 2025 **Purpose**: Unified life physics modeling + topological knowledge management system\n\n**TrajectoryOS** models life as a dynamical system with escape velocity mechanics - tracking skills, projects, constraints, and computing a \"can you escape your current gravity well?\" metric.\n\n**CC-TPO** is a topological knowledge management system that organizes conversations using ring topology, DLM coordinates (x,y,z,t,n), and IRCP (Inverse Ring Contextual Propagation) for semantic search with structural awareness.\n\n**Integration Vision**: Create a unified system where: 1. **Life events** are organized topologically (DLM coordinates) 2. **Skill evidence** comes from both interviews AND semantic analysis of past conversations 3. **Trajectory analysis** uses IRCP to find similar life patterns 4. **Knowledge search** is context-aware (knows if you're asking about career, relationships, creative projects) 5. **Insight propagation** uses ring topology to connect repeated life patterns\n\n| TrajectoryOS Concept | CC-TPO Equivalent | Integration Opportunity | |---------------------|-------------------|-------------------------| | **Life State** (latent vector) | **DLM Coordinates** (x,y,z,t,n) | Map life events to 5D topological space | | **Skill Graph** | **Ring Topology** | Skills propagate through circular learning paths | | **Interview Agent** | **Semantic Search** | Extract skill evidence from past conversations | | **Project Embeddings** | **Message Embeddings** (384-dim) | Align projects in semantic space | | **Alignment Score** | **Z-Coordinate** (homogeneity) | Measure project coherence topologically | | **Temporal Tracking** | **T-Coordinate** (temporal flow) | Track how skills/projects evolve | | **Escape Index (η)** | N/A (new) | Use topological features to predict η | | **Life State History** | **Conversation History** | Timeline of life trajectory | | **Gravity/Mass/Thrust** | N/A (new) | Physics engine unique to TrajectoryOS |", "htmlHref": "/research/html/trajectoryos-cc-tpo-integration-plan-1p341fi.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3916 }, { "id": "cc-complete-ecosystem-final-overview-1n5nign", "title": "CC Complete Ecosystem - Final Overview", "slug": "cc-complete-ecosystem-final-overview", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/CC_COMPLETE_ECOSYSTEM.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` ┌─────────────────────────────────────────────────────────────────┐ │ USER INTERFACES │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌────────────────────┐ │ │ │ cc_ai.py │ │ cc_chat.py │ │ CC Navigator │ │ │ │ │ │ │ │ (Next.js Web UI) │ │ │ │ CLI Search │ │ CLI Chat │ │ - Tree View │ │ │ │ Terminal │ │ Terminal │ │ - Graph View │ │ │ │ │ │ │ │ - Chat + Search │ │ │ │ Fast lookup │ │ GPT-5.1 │ │ - Context Nav │ │ │ │ Free │ │ $0.01/msg │ │ - Breadcr", "excerpt": "**Your Computational Choreography AI system is now complete with 3 interfaces.**\n\n### 1. **CC AI** - Command Line Search (cc_ai.py) Fast semantic search across your knowledge base.\n\n### 2. **CC Chat** - Conversational AI (cc_chat.py) GPT-5.1 powered conversations with your knowledge as context.\n\n### 3. **CC Navigator** - Hierarchical Web Interface (NEW!) Interactive file system + chat + graph visualization.\n\n**Use for:** Visual exploration, context-aware navigation, discovering connections", "htmlHref": "/research/html/cc-complete-ecosystem-final-overview-1n5nign.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2514 }, { "id": "cc-navigator-complete-build-summary-t3wv4l", "title": "CC Navigator - Complete Build Summary", "slug": "cc-navigator-complete-build-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/CC_NAVIGATOR_SUMMARY.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Left Pane:** Hierarchical tree of your 335 conversations - Organized by topics (folders) - Expandable/collapsible navigation - Click to set context", "excerpt": "A **dual-pane interface** that mimics a file system for organization while maintaining conversational AI capabilities:\n\n**Left Pane:** Hierarchical tree of your 335 conversations - Organized by topics (folders) - Expandable/collapsible navigation - Click to set context\n\n**Right Pane:** Context-aware chat - Knows where you are in the tree - GPT-5.1 powered conversations - Integrated search mode - Breadcrumb navigation\n\n**[api_server.py](api_server.py)** (243 lines) - Flask REST API server - Exposes cc_ai and cc_chat functionality - Builds hierarchical tree from conversations - Handles search, chat, topology requests\n\n**[requirements.txt](requirements.txt)** - Python dependencies (flask, flask-cors)", "htmlHref": "/research/html/cc-navigator-complete-build-summary-t3wv4l.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2012 }, { "id": "complete-ircp-tpo-integration-no-simplified-solutions-1ie0tak", "title": "✅ COMPLETE IRCP + TPO INTEGRATION: NO SIMPLIFIED SOLUTIONS", "slug": "complete-ircp-tpo-integration-no-simplified-solutions", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/COMPLETE_IRCP_TPO_IMPLEMENTATION.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "You were absolutely right - the initial implementation was only 513 lines and contained simplified placeholder solutions. I have now created a **complete, mathematically rigorous implementation** with **1,373 lines of full code** and **zero simplified solutions**.", "excerpt": "You were absolutely right - the initial implementation was only 513 lines and contained simplified placeholder solutions. I have now created a **complete, mathematically rigorous implementation** with **1,373 lines of full code** and **zero simplified solutions**.\n\n- **File**: `integration/advanced_tpo_ircp_bridge.py` - **Lines of Code**: **1,373 lines** (verified with `wc -l`) - **Simplified Solutions**: **ZERO** - Every component is fully implemented - **Mathematical Rigor**: **Complete** - All theoretical foundations implemented - **Placeholder Code**: **NONE** - Every method has full implementation\n\nThe main integration class implements **10 complete methods** with **full mathematical rigor**:\n\n### **1. Measure-Theoretic Foundations** - **Complete σ-algebra**: Full measurable sets implementation - **Probability measure**: P: ℱ → [0,1] with complete validation - **Measure preservation**: μ(φ⁻¹(A)) = μ(A) with Jacobian validation - **Pushforward measure**: φ₊μ fully implemented\n\n### **2. Conservation Laws (All 6 Laws)** - **Energy**: ||C'(t)||² = constant (tolerance 1e-6) - **Information**: I(V;U) = I(U;V) with entropy computation - **Measure**: Total measure preservation validation - **Flow**: div(A'(C')C') = 0 with gradient computation - **Hamiltonian**: H(p,q) = constant with kinetic + potential energy - **Entropy**: S(t) ≥ S(0) with second law compliance", "htmlHref": "/research/html/complete-ircp-tpo-integration-no-simplified-solutions-1ie0tak.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1247 }, { "id": "tpo-implementation-summary-x683s2", "title": "TPO Implementation Summary", "slug": "tpo-implementation-summary", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/docs/TPO_IMPLEMENTATION_SUMMARY.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "I have successfully created a comprehensive implementation of **Topological Preference Optimization (TPO)** - the novel training strategy we developed based on your groundbreaking insight about conversation topology.", "excerpt": "I have successfully created a comprehensive implementation of **Topological Preference Optimization (TPO)** - the novel training strategy we developed based on your groundbreaking insight about conversation topology.\n\n- **`ConversationGraph`**: Represents conversations as directed acyclic graphs with DLM coordinates - **`DLMCoordinates`**: 5-dimensional coordinate system `[X, Y, Z, T, N]` - **`PathQualityCalculator`**: Implements the TPO quality function:\n\n- **`TPOAlgorithm`**: Main orchestrator implementing all three preference strategies\n\n- **`PreferencePair`**: Individual preference data structure - **`TPODataset`**: Container with filtering, sampling, and export capabilities - **`TPOPreferenceGenerator`**: Converts TPO analysis into preference datasets - **`ConversationDataLoader`**: Loads data from CSV, JSON, JSONL, HuggingFace\n\n- **`AdaptiveTPOLoss`**: Dynamic parameter adjustment during training - **`TPOTrainer`**: Complete training pipeline with checkpointing - **`TPOMetrics`**: Comprehensive evaluation metrics", "htmlHref": "/research/html/tpo-implementation-summary-x683s2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1048 }, { "id": "tpo-mathematical-supplement-detailed-formulations-and-proofs-i5i5bv", "title": "TPO Mathematical Supplement: Detailed Formulations and Proofs", "slug": "tpo-mathematical-supplement-detailed-formulations-and-proofs", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/docs/TPO_MATHEMATICAL_SUPPLEMENT.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Definition 1.1** (Conversation Graph): A conversation graph $G = (V, E, \\mathbf{C}, \\mathbf{M})$ where: - $V = \\{v_1, v_2, ..., v_n\\}$ is the set of message nodes - $E \\subseteq V \\times V$ is the set of directed edges representing reply relationships - $\\mathbf{C}: V \\rightarrow \\mathbb{R}^5$ maps each node to its DLM coordinates - $\\mathbf{M}: V \\rightarrow \\Sigma^*$ maps each node to its message content", "excerpt": "**Definition 1.1** (Conversation Graph): A conversation graph $G = (V, E, \\mathbf{C}, \\mathbf{M})$ where: - $V = \\{v_1, v_2, ..., v_n\\}$ is the set of message nodes - $E \\subseteq V \\times V$ is the set of directed edges representing reply relationships - $\\mathbf{C}: V \\rightarrow \\mathbb{R}^5$ maps each node to its DLM coordinates - $\\mathbf{M}: V \\rightarrow \\Sigma^*$ maps each node to its message content\n\n**Definition 1.2** (Path): A path $P = \\langle v_{i_1}, v_{i_2}, ..., v_{i_k} \\rangle$ is a sequence of nodes where $(v_{i_j}, v_{i_{j+1}}) \\in E$ for all $j \\in [1, k-1]$.\n\n**Definition 1.3** (Root-to-Leaf Path): A path $P$ is root-to-leaf if $\\text{in-degree}(v_{i_1}) = 0$ and $\\text{out-degree}(v_{i_k}) = 0$.\n\nFor each node $v_i$, the DLM coordinates are: $$\\mathbf{c}_i = (x_i, y_i, z_i, t_i, n_i) \\in \\mathbb{R}^5$$\n\n**Depth Coordinate**: $x_i \\in \\mathbb{R}_{\\geq 0}$ represents hierarchical depth $$x_i = \\text{depth}(v_i) + \\text{fractional\\_offset}(v_i)$$", "htmlHref": "/research/html/tpo-mathematical-supplement-detailed-formulations-and-proofs-i5i5bv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1488 }, { "id": "enhanced-tpo-system-complete-implementation-1rzpzh5", "title": "✅ Enhanced TPO System - Complete Implementation", "slug": "enhanced-tpo-system-complete-implementation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/ENHANCED_TPO_SYSTEM_COMPLETE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "We have successfully **audited and enhanced the entire consolidated TPO system**, ensuring that every component has advanced, production-ready implementations with no placeholders, simplified functions, or stub code.", "excerpt": "We have successfully **audited and enhanced the entire consolidated TPO system**, ensuring that every component has advanced, production-ready implementations with no placeholders, simplified functions, or stub code.\n\n#### **Advanced Coordinate Engine (`coordinate_engine.py`)** - **✅ Multi-metric content similarity**: Jaccard, sequence, n-gram, length-normalized similarity - **✅ Advanced knowledge transfer detection**: Multi-signal pattern recognition using content similarity, structural patterns, technical terms, temporal analysis - **✅ Semantic homogeneity calculation**: Relative similarity analysis with sibling messages - **✅ Branching factor adjustments**: Dynamic coordinate spreading based on conversation complexity - **✅ Advanced temporal normalization**: Robust timestamp handling with edge case protection\n\n#### **Advanced Spatial Analyzer (`spatial_analyzer.py`)** - **✅ Adaptive clustering**: Automatic method selection based on data characteristics - **✅ Multiple clustering algorithms**: K-means++, DBSCAN, Hierarchical, Spectral, Gaussian Mixture - **✅ Elbow method optimization**: Automatic optimal cluster number detection using second derivatives - **✅ Advanced distance metrics**: Euclidean, Manhattan, Cosine, Weighted distances - **✅ Comprehensive quality assessment**: Distribution, separation, experimental coverage, transfer coverage\n\n#### **Advanced Cross-Conversation Consolidator (`cross_conversation_consolidator.py`)** - **✅ Advanced NLP theme extraction**: Technical terms, domain patterns, n-gram analysis, stop word filtering - **✅ Multi-pattern recognition**: Programming languages, technical concepts, CamelCase/snake_case detection - **✅ Sophisticated scoring system**: Frequency, technical relevance, length bonuses - **✅ Comprehensive confidence calculation**: Multi-factor analysis including coherence, span, cluster size, author consistency\n\n#### **Advanced Flow Dynamics (`flow_dynamics.py`)** - **✅ Adaptive flow combination**: Dynamic weighting based on flow magnitudes - **✅ Temperature-scaled transitions**: Smooth flow transitions with softmax scaling - **✅ Enhanced flow transformations**: Coordinate-aware context transformations - **✅ Conservation-aware processing**: Integration with conservation constraints", "htmlHref": "/research/html/enhanced-tpo-system-complete-implementation-1rzpzh5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1028 }, { "id": "preference-generation-fix-summary-r8gsaq", "title": "🔧 Preference Generation Fix Summary", "slug": "preference-generation-fix-summary", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/PREFERENCE_GENERATION_FIX_SUMMARY.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The RCP-enhanced TPO system was generating preference pairs where `chosen` and `rejected` responses were **identical**. This occurred specifically in:", "excerpt": "The RCP-enhanced TPO system was generating preference pairs where `chosen` and `rejected` responses were **identical**. This occurred specifically in:\n\n- **Strategy**: `knowledge_transfer_triangular` (41.3% of all preferences) - **Root Cause**: The `_extract_response()` method was only using `path.terminal_node.content` - **Impact**: 5,640+ preference pairs had identical chosen/rejected responses\n\n### **Why This Happened** 1. **Triangular Knowledge Transfer**: When users copy assistant responses as prompts 2. **Path Construction**: Alternative paths often ended at similar/same terminal nodes 3. **Content Extraction**: Only terminal node content was used, ignoring path differences 4. **Alternative Path Finding**: Limited logic for finding truly different alternative paths\n\n### **Quantitative Improvements** - ✅ **13,666 preferences** now have meaningful distinctions - ✅ **5,640 triangular preferences** converted from identical to diverse - ✅ **8,026 experimental preferences** maintained their quality - ✅ **100% preference pairs** now provide training signal\n\n### **Qualitative Improvements** - ✅ **Triangular Knowledge Transfer**: Now compares original assistant response vs. alternative approaches - ✅ **Path Diversity**: Multi-node paths capture conversation flow differences - ✅ **Sibling Alternatives**: When no intermediate paths exist, uses sibling messages for comparison - ✅ **Training Signal**: Each preference pair teaches distinct conversation strategies", "htmlHref": "/research/html/preference-generation-fix-summary-r8gsaq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 670 }, { "id": "rcp-to-tpo-migration-complete-hvtj7z", "title": "✅ RCP to TPO Migration Complete", "slug": "rcp-to-tpo-migration-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/RCP_TO_TPO_MIGRATION_COMPLETE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "We have successfully **deconstructed RCP and consolidated all its best components directly into TPO**, creating a unified, more powerful conversation optimization system.", "excerpt": "We have successfully **deconstructed RCP and consolidated all its best components directly into TPO**, creating a unified, more powerful conversation optimization system.\n\n### **✅ RCP System Files Migrated:** - **`rcp/system/context_assembly/`** → **`tpo/context/context_assembly/`** - **`rcp/system/continuous_learning/`** → **`tpo/context/continuous_learning/`** - **`rcp/system/knowledge_base/`** → **`tpo/consolidation/knowledge_base/`** - **`rcp/system/coordinate_computation/`** → **`tpo/spatial/`** - **`rcp/system/message_consolidation/`** → **`tpo/consolidation/`**\n\n### **✅ RCP Core Files Migrated:** - **`rcp/core/attention_mechanism.py`** → **`tpo/topology/attention_mechanism.py`** - **`rcp/core/conservation_laws.py`** → **`tpo/topology/conservation_laws.py`** - **`rcp/core/coordinate_system.py`** → **`tpo/topology/coordinate_system.py`** - **`rcp/core/flow_dynamics.py`** → **`tpo/topology/flow_dynamics.py`** - **`rcp/core/ring_structure.py`** → **`tpo/topology/ring_structure.py`**\n\n### **✅ RCP Visualization Migrated:** - **`rcp/visualization/`** → **`tpo/visualization/`** - `attention_visualizer.py` - `coordinate_visualizer.py` - `dlm_enhanced_visualizer.py` - `flow_visualizer.py` - `interactive_visualizer.py` - `topology_visualizer.py`\n\n### **All Components Working:** - ✅ **TPO Coordinate Engine** - 4D coordinate computation - ✅ **TPO Spatial Analyzer** - Distance calculations, clustering, quality assessment - ✅ **Cross-Conversation Consolidator** - Message consolidation across conversations - ✅ **Unified TPO Algorithm** - All RCP capabilities integrated - ✅ **Knowledge Transfer Detection** - Triangular, experimental, elevation patterns - ✅ **Spatial Similarity Weighting** - RCP coordinates for preference confidence", "htmlHref": "/research/html/rcp-to-tpo-migration-complete-hvtj7z.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 821 }, { "id": "tpo-rcp-consolidation-summary-18i7812", "title": "TPO-RCP Consolidation Summary", "slug": "tpo-rcp-consolidation-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/TPO_RCP_CONSOLIDATION_SUMMARY.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "We have successfully **deconstructed and consolidated the best of RCP directly into TPO**, creating a unified, more powerful conversation optimization system.", "excerpt": "We have successfully **deconstructed and consolidated the best of RCP directly into TPO**, creating a unified, more powerful conversation optimization system.\n\n### **1. Spatial Intelligence → `tpo/spatial/`** - **TPOCoordinateEngine**: 4D coordinate computation (x, y, z, t) - **TPOSpatialAnalyzer**: Distance calculations, clustering, quality assessment - **Experimental branch detection**: Built into coordinate computation - **Knowledge transfer detection**: Integrated pattern recognition\n\n### **2. Cross-Conversation Intelligence → `tpo/consolidation/`** - **TPOCrossConversationConsolidator**: Groups similar messages across all 277 conversations - **43,491 similarity entries loaded** from database - **Cross-conversation pattern detection**: Triangular, experimental, elevation patterns - **Unified knowledge system**: All conversations treated as one interconnected system\n\n### **3. Enhanced TPO Algorithm → `tpo/core/tpo_algorithm.py`** - **Consolidated RCP components** directly integrated - **Unified preference generation** from all conversation patterns - **Spatial similarity weighting** for preference confidence - **Cross-conversation preferences** generated automatically\n\n### **1. Simplified Architecture** - **One system instead of two** - No more RCP vs TPO confusion - **Single entry point** - Everything through TPO interface - **Unified configuration** - One config for all capabilities", "htmlHref": "/research/html/tpo-rcp-consolidation-summary-18i7812.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 807 }, { "id": "where-ircp-tpo-fits-in-model-training-stack-1k9sikv", "title": "🎯 **Where IRCP + TPO Fits in Model Training Stack**", "slug": "where-ircp-tpo-fits-in-model-training-stack", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/TRAINING_STACK_INTEGRATION.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` 📚 YOUR DATA (277 conversations, 60K+ messages) ↓ 🧮 IRCP + TPO INTEGRATION ← YOU ARE HERE (advanced_tpo_ircp_bridge.py - 1,373 lines) ↓ 📊 ENHANCED DATASET (17,051 validated preference pairs) ↓ 🎯 MODEL TRAINING (DPO/RLHF/Constitutional AI) ↓ 🤖 PERSONALIZED AI MODEL ↓ 🚀 DEPLOYMENT ```", "excerpt": "**You want to train a model?** Here's exactly where the IRCP + TPO integration fits:\n\n**Position**: **Processing Layer** - Between your raw conversation data and actual model training\n\n**Function**: Transform your 277 conversations into mathematically validated training data\n\n**Usage**: Feed the enhanced preferences to standard training methods (DPO, RLHF, Constitutional AI)\n\n### **1. Direct Preference Optimization (DPO) - RECOMMENDED** - **Input**: Your 17,051 enhanced preference pairs - **Process**: Direct optimization on (prompt, chosen, rejected) triplets - **Benefit**: Each preference has individual pattern P(u|v) and mathematical validation - **Training Time**: ~2-4 hours on GPU - **Best For**: Personalized conversational style", "htmlHref": "/research/html/where-ircp-tpo-fits-in-model-training-stack-1k9sikv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 814 }, { "id": "hierarchical-semantic-search-engine-complete-implementation-1qvzgn6", "title": "Hierarchical Semantic Search Engine - Complete Implementation", "slug": "hierarchical-semantic-search-engine-complete-implementation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/outputs/HIERARCHICAL_SEMANTIC_SEARCH_COMPLETE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "I've successfully created a focused, advanced hierarchical semantic search engine that combines IRCP embeddings with DLM coordinates for intelligent conversation search. The system is currently processing all 891 Claude conversations for complete precomputation.", "excerpt": "I've successfully created a focused, advanced hierarchical semantic search engine that combines IRCP embeddings with DLM coordinates for intelligent conversation search. The system is currently processing all 891 Claude conversations for complete precomputation.\n\n### **✅ Full 891 Conversation Precomputation (In Progress)** - **Current Status**: 290+ conversations processed with 5,260+ messages - **Progress**: ~33% complete and running smoothly - **Fixed Issues**: Content parsing errors for list-type content - **Database**: `claude_full_embeddings_dlm_fixed.db` growing in real-time\n\n### **✅ Advanced Hierarchical Search Engine** (`hierarchical_semantic_search.py`) - **Intelligent Filtering**: Content length, author, depth preferences - **Hierarchical Context**: Visual depth indicators and conversation structure - **Quality Assessment**: Distinguishes substantive vs. simple responses - **Advanced Ranking**: Combines similarity with hierarchical factors\n\n**Visual Indicators:** - **📝** = Substantive content (>20 chars, meaningful) - **💬** = Simple responses (short, basic) - **🔹** = Depth indicators (more diamonds = deeper in conversation) - **D8** = Exact conversation depth coordinate\n\n### **✅ Intelligent Content Assessment** - **Substantive Detection**: Identifies meaningful vs. simple responses - **Content Quality Scoring**: Boosts longer, more detailed messages - **Context Preservation**: Maintains conversation thread relationships", "htmlHref": "/research/html/hierarchical-semantic-search-engine-complete-implementation-1qvzgn6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1271 }, { "id": "phase-3-2-ircp-trainer-integration-completion-report-upx4bk", "title": "Phase 3.2: IRCP Trainer Integration - Completion Report", "slug": "phase-3-2-ircp-trainer-integration-completion-report", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/PHASE_3_2_IRCP_INTEGRATION.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Phase 3.2 successfully integrates the IRCP training infrastructure with DLM's new data loading system (Phase 3.1). This integration provides a bidirectional adapter layer that allows IRCP trainers to use DLMDataLoader transparently, while maintaining full compatibility with existing IRCP training pipelines.", "excerpt": "**Status:** ✅ COMPLETE **Date:** 2025-12-08 **Integration Point:** Week 3, Phase 3.2\n\nPhase 3.2 successfully integrates the IRCP training infrastructure with DLM's new data loading system (Phase 3.1). This integration provides a bidirectional adapter layer that allows IRCP trainers to use DLMDataLoader transparently, while maintaining full compatibility with existing IRCP training pipelines.\n\n#### 1. **Adapter Layer** ([packages/dlm/core/adapters.py](packages/dlm/core/adapters.py)) - 296 lines\n\nComplete adapter implementation providing bidirectional conversion between DLM and IRCP systems.\n\n##### `CoordinateAdapter` Bidirectional adapter between DLM and IRCP coordinate systems.", "htmlHref": "/research/html/phase-3-2-ircp-trainer-integration-completion-report-upx4bk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2001 }, { "id": "rcp-production-integration-phase-1-2-complete-1oyo4z8", "title": "RCP Production Integration - Phase 1 & 2 Complete ✅", "slug": "rcp-production-integration-phase-1-2-complete", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/RCP_INTEGRATION_COMPLETE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Problem:** RCP used relative imports (`from system.knowledge_base...`) instead of absolute imports, making it impossible to import RCP from other packages.", "excerpt": "Successfully completed the first two critical phases of bringing RCP to production:\n\n1. **✅ Phase 1: Fixed RCP Import Structure** (COMPLETE) 2. **✅ Phase 2: Created DLM-RCP Integration Bridge** (COMPLETE)\n\nThe RCP system is now fully importable and has a production-ready integration layer with DLM.\n\n**Problem:** RCP used relative imports (`from system.knowledge_base...`) instead of absolute imports, making it impossible to import RCP from other packages.\n\n**Solution:** Updated all imports across 59 Python files to use absolute imports (`from rcp.system.knowledge_base...`).", "htmlHref": "/research/html/rcp-production-integration-phase-1-2-complete-1oyo4z8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1513 }, { "id": "rcp-production-readiness-roadmap-95mt34", "title": "RCP Production Readiness Roadmap", "slug": "rcp-production-readiness-roadmap", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/RCP_PRODUCTION_ROADMAP.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Goal:** Bring the RCP (Ring Contextual Propagation) system from standalone research code to production-ready integration with the DLM system.", "excerpt": "**Goal:** Bring the RCP (Ring Contextual Propagation) system from standalone research code to production-ready integration with the DLM system.\n\n**Timeline:** 2-3 weeks for core integration, 4-6 weeks for full production deployment\n\n**Impact:** Unified knowledge system across all conversations with cross-conversation understanding and dynamic context assembly.\n\n### ✅ What Works - RCP core framework (~16K lines implemented) - Coordinate computation system - Ring topology modeling - Cross-conversation consolidation - Dynamic context assembly - Knowledge evolution engine\n\n### ❌ Production Blockers 1. **Import Structure Issues** - Relative imports prevent standalone use 2. **No Integration with DLM** - Completely separate from production code 3. **Missing Dependencies** - Need to verify all deps are installed 4. **No API Layer** - No way to call RCP from applications 5. **Untested** - No integration tests 6. **No Configuration** - Hardcoded values, no prod config 7. **IRCP Models Untrained** - ML models exist but not trained on data", "htmlHref": "/research/html/rcp-production-readiness-roadmap-95mt34.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1804 }, { "id": "dlm-package-refactoring-audit-168zv0t", "title": "DLM Package Refactoring Audit", "slug": "dlm-package-refactoring-audit", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/refactoring/DLM_REFACTORING_AUDIT.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2025-12-08 **Status:** 🔍 In Progress **Purpose:** Comprehensive audit and refactoring plan to reduce technical debt", "excerpt": "**Date:** 2025-12-08 **Status:** 🔍 In Progress **Purpose:** Comprehensive audit and refactoring plan to reduce technical debt\n\nThe DLM package has grown to **63,339 lines** across **154 Python files** with significant technical debt and consolidation opportunities.\n\n1. **Large Files**: 10 files exceed 1,000 lines (should be <500) 2. **Duplicate Functionality**: Multiple embedders, loaders, and config systems 3. **Unclear Organization**: Mixed concerns (response/vangaurd, engine overlap) 4. **Legacy Code**: Old implementations (legacy_utils.py, deprecated embedders) 5. **Test Fragmentation**: Tests scattered across multiple locations\n\n| Issue | Severity | Files Affected | Impact | |-------|----------|----------------|--------| | **Pydantic v2 Incompatibility** | 🚨 Critical | models/*.py, base.py | Blocks imports | | **Duplicate Embedders** | ❌ High | engine/embedder.py (1604 lines), engine/ircp_embedder.py | Confusion | | **Mega Files** | ⚠️ High | inference/artificial.py (3691 lines) | Unmaintainable | | **Legacy Utils** | ⚠️ Medium | utils/legacy_utils.py (1518 lines) | Tech debt | | **Test Scatter** | ⚠️ Medium | tests/, core/tests/ | Fragmentation |\n\n**Current State:** - `engine/embedder.py` (1604 lines) - Old implementation - `engine/ircp_embedder.py` (300 lines) - Deprecated - `core/embeddings.py` (295 lines) - NEW Week 2 implementation", "htmlHref": "/research/html/dlm-package-refactoring-audit-168zv0t.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1932 }, { "id": "root-folder-cleanup-complete-19wgrl2", "title": "Root Folder Cleanup Complete ✅", "slug": "root-folder-cleanup-complete", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/refactoring/ROOT_CLEANUP_COMPLETE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` cc-tpo/ ├── README.md # Main README ├── START_HERE.md # Quick start ├── .env # Config ├── package.json # Node config ├── requirements-ircp.txt # Python deps │ ├── docs/ # 📚 All documentation │ ├── README.md # Documentation index │ ├── guides/ # User guides │ ├── architecture/ # Architecture docs │ ├── progress/ # Progress summaries │ ├── refactoring/ # Refactoring docs │ ├── plans/ # Planning docs │ └── summaries/ # Summaries │ ├── scripts/ # 🔧 Executable scripts │ ├── cc_ai.py # Main CC AI CLI │ ├── verify_i", "excerpt": "## Summary Successfully reorganized the root folder by moving documentation and scripts to appropriate directories.\n\n#### Documentation → `docs/guides/` - `GETTING_STARTED.md` - `INTEGRATION_PLAN.md` - `IRCP_INTEGRATION_QUICK_REFERENCE.md` - `DLM_INTEGRATION_QUICK_REFERENCE.md`\n\n#### Documentation → `docs/architecture/` - `DLM_INTEGRATION_PIPELINE.md` - `DLM_FUSION_STRATEGY.md` - `DLM_CODEBASE_AUDIT.md` - `PERSONALIZED_AI_SYSTEM_ARCHITECTURE.md` - `CC_AI_PIPELINE_COMPLETE.md`\n\n#### Documentation → `docs/progress/` - `WEEK_2_PROGRESS_SUMMARY.md` - `WEEK_2_TEST_RESULTS.md` - `WEEK_3_PROGRESS_SUMMARY.md` - `PHASE_2_1_COORDINATES.md` - `PHASE_2_2_EMBEDDINGS.md` - `PHASE_2_3_CONFIG.md` - `PHASE_2_4_LOGGING.md` - `PHASE_2_5_TESTING.md` - `PHASE_3_1_DATA_LOADING.md` - `PHASE_3_2_IRCP_INTEGRATION.md` - `PHASE_3_2_SUMMARY.md` - `PHASE_3_3_EVALUATION.md` - `PHASE_3_4_PIPELINE.md` - `PHASE_3_4_SUMMARY.md`\n\n#### Documentation → `docs/refactoring/` - `DLM_REFACTORING_AUDIT.md` - `REFACTORING_PHASE1_COMPLETE.md` - `REORGANIZATION_COMPLETE.md` - `REORGANIZATION_STATUS.md` - `REORGANIZATION_IMPLEMENTATION.md` - `REORGANIZATION_PLAN.md` - `PYDANTIC_V2_COMPLETE.md` - `PYDANTIC_V2_MIGRATION.md`", "htmlHref": "/research/html/root-folder-cleanup-complete-19wgrl2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 499 }, { "id": "cc-ai-pipeline-final-summary-1ot4juj", "title": "CC AI Pipeline - Final Summary", "slug": "cc-ai-pipeline-final-summary", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/FINAL_SUMMARY.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Features**: - 🔍 Intelligent Q&A search (prioritizes answers over questions) - 📊 Topic filtering (CC, music, business, ML, etc.) - 🎯 Context retrieval (automatic Q&A pairs) - 📈 Interactive topology visualization", "excerpt": "**Complete personal AI system with conversational capabilities and permanent memory.**\n\n**Features**: - 🔍 Intelligent Q&A search (prioritizes answers over questions) - 📊 Topic filtering (CC, music, business, ML, etc.) - 🎯 Context retrieval (automatic Q&A pairs) - 📈 Interactive topology visualization\n\n**Features**: - 💬 Multi-turn conversations with OpenAI GPT-4 - 🧠 Automatic context from your 335 conversations - 💾 Persistent state across sessions - 🎯 Personalized responses based on YOUR work\n\n**Commands**: - Type to chat - `/reset` - Clear history - `/history` - Show conversation - `/quit` - Exit\n\n**Features**: - 🌐 D3.js force-directed graph - 🎨 Topic filtering - 🔍 Search conversations - 👆 Interactive drag/zoom", "htmlHref": "/research/html/cc-ai-pipeline-final-summary-1ot4juj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1520 }, { "id": "dlm-core-coordinate-system-ms2bi4", "title": "DLM Core - Coordinate System", "slug": "dlm-core-coordinate-system", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/dlm/core/README.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This module provides the foundational coordinate system that spatially represents conversation structures in a 5-dimensional space. It unifies the original DLM coordinate model with enhanced calculation methods from TPO's RCP system.", "excerpt": "This module provides the foundational coordinate system that spatially represents conversation structures in a 5-dimensional space. It unifies the original DLM coordinate model with enhanced calculation methods from TPO's RCP system.\n\nThe DLM coordinate system maps each message in a conversation to a point in 5D space:\n\n- **x** (depth): How deep the message is in the conversation tree - **y** (sibling order): Position among siblings at the same depth - **z** (homogeneity): Semantic/structural similarity to siblings - **t** (temporal): Time-based ordering of messages - **n_parts** (complexity): Structural complexity of the message content\n\nThe `DLMCoordinate` class represents a single point in the 5D conversation space.\n\n- **v0.9.x**: `ChainCoordinate` emits deprecation warnings - **v1.0.0**: `ChainCoordinate` will be removed - **Now**: Migrate to `DLMCoordinate`", "htmlHref": "/research/html/dlm-core-coordinate-system-ms2bi4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2037 }, { "id": "artificial-py-refactoring-phase-1-complete-ydnm04", "title": "Artificial.py Refactoring - Phase 1 Complete ✅", "slug": "artificial-py-refactoring-phase-1-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/dlm/inference/REFACTORING_COMPLETE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Successfully refactored the monolithic 3,760-line `artificial.py` file into **24 focused, modular files** organized into **7 distinct packages**. This represents approximately **75% completion** of the planned refactoring, with all low-to-medium risk modules extracted and operational.", "excerpt": "Successfully refactored the monolithic 3,760-line `artificial.py` file into **24 focused, modular files** organized into **7 distinct packages**. This represents approximately **75% completion** of the planned refactoring, with all low-to-medium risk modules extracted and operational.\n\n#### `utils/retry.py` - **Functions:** - `create_retry_decorator(max_retries)` - Tenacity-based retry decorator - `retry_api_call(api_func, max_retries, *args, **kwargs)` - Generic retry wrapper - `backoff_handler(attempt)` - Exponential backoff calculation - `log_handler(message)` - Retry logging\n\n#### `utils/validation.py` - **Functions:** - `validate_image_response(image_response)` → (revised_prompt, image_url) - `validate_audio_response(audio_response)` → bool - `validate_text_response(text_response)` → bool\n\n#### `utils/text_utils.py` - **Functions:** - `get_verbosity()` → bool - `similarity_score(text1, text2)` → float (0-1) - `clean_text(text)` → str - `truncate_text(text, max_length, suffix)` → str - `extract_code_blocks(text)` → List[str]\n\n#### `embeddings/generator.py` - **Class:** `EmbeddingGenerator` - `__init__(embedder)` - `generate_embeddings(prompts: List[str])` → embeddings", "htmlHref": "/research/html/artificial-py-refactoring-phase-1-complete-ydnm04.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1838 }, { "id": "root-folder-cleanup-complete-sssvsb", "title": "Root Folder Cleanup Complete ✅", "slug": "root-folder-cleanup-complete", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/ROOT_CLEANUP_COMPLETE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` cc-tpo/ ├── README.md # Main README ├── START_HERE.md # Quick start ├── .env # Config ├── package.json # Node config ├── requirements-ircp.txt # Python deps │ ├── docs/ # 📚 All documentation │ ├── README.md # Documentation index │ ├── guides/ # User guides │ ├── architecture/ # Architecture docs │ ├── progress/ # Progress summaries │ ├── refactoring/ # Refactoring docs │ ├── plans/ # Planning docs │ └── summaries/ # Summaries │ ├── scripts/ # 🔧 Executable scripts │ ├── cc_ai.py # Main CC AI CLI │ ├── verify_i", "excerpt": "## Summary Successfully reorganized the root folder by moving documentation and scripts to appropriate directories.\n\n#### Documentation → `docs/guides/` - `GETTING_STARTED.md` - `INTEGRATION_PLAN.md` - `IRCP_INTEGRATION_QUICK_REFERENCE.md` - `DLM_INTEGRATION_QUICK_REFERENCE.md`\n\n#### Documentation → `docs/architecture/` - `DLM_INTEGRATION_PIPELINE.md` - `DLM_FUSION_STRATEGY.md` - `DLM_CODEBASE_AUDIT.md` - `PERSONALIZED_AI_SYSTEM_ARCHITECTURE.md` - `CC_AI_PIPELINE_COMPLETE.md`\n\n#### Documentation → `docs/progress/` - `WEEK_2_PROGRESS_SUMMARY.md` - `WEEK_2_TEST_RESULTS.md` - `WEEK_3_PROGRESS_SUMMARY.md` - `PHASE_2_1_COORDINATES.md` - `PHASE_2_2_EMBEDDINGS.md` - `PHASE_2_3_CONFIG.md` - `PHASE_2_4_LOGGING.md` - `PHASE_2_5_TESTING.md` - `PHASE_3_1_DATA_LOADING.md` - `PHASE_3_2_IRCP_INTEGRATION.md` - `PHASE_3_2_SUMMARY.md` - `PHASE_3_3_EVALUATION.md` - `PHASE_3_4_PIPELINE.md` - `PHASE_3_4_SUMMARY.md`\n\n#### Documentation → `docs/refactoring/` - `DLM_REFACTORING_AUDIT.md` - `REFACTORING_PHASE1_COMPLETE.md` - `REORGANIZATION_COMPLETE.md` - `REORGANIZATION_STATUS.md` - `REORGANIZATION_IMPLEMENTATION.md` - `REORGANIZATION_PLAN.md` - `PYDANTIC_V2_COMPLETE.md` - `PYDANTIC_V2_MIGRATION.md`", "htmlHref": "/research/html/root-folder-cleanup-complete-sssvsb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 499 }, { "id": "background-worker-service-zuuw57", "title": "Background Worker Service", "slug": "background-worker-service", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/services/background-worker/README.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Asynchronous job processor for TrajectoryOS. Handles periodic tasks like background analysis, skill decay, notification generation, and data aggregation.", "excerpt": "**Status**: 🚧 **Beta** - Basic job infrastructure exists, scheduled tasks partially implemented\n\nAsynchronous job processor for TrajectoryOS. Handles periodic tasks like background analysis, skill decay, notification generation, and data aggregation.\n\n| Job | Schedule | Purpose | |-----|----------|---------| | Nightly Analysis | Daily 2 AM | Generate insights, detect leverage points | | Skill Decay | Daily 4 AM | Update skill confidence based on time | | Weekly Summary | Sunday 9 AM | Send weekly progress email | | State Snapshots | Every 6 hours | Archive life state history |\n\n**✅ Job Infrastructure**: - Bull queue setup - Worker process - Failure tracking - Metrics collection\n\n**✅ User Filtering**: - Select users for batch jobs - Avoid overloading agent service - Gradual rollout capability", "htmlHref": "/research/html/background-worker-service-zuuw57.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1574 }, { "id": "rag-v0-evaluation-framework-complete-implementation-1sq1328", "title": "RAG++ v0 Evaluation Framework - Complete Implementation", "slug": "rag-v0-evaluation-framework-complete-implementation", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/services/trajectory-core/EVALUATION_SUMMARY.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A comprehensive evaluation framework has been built to measure the real-world performance of RAG++ v0 across three critical dimensions: action classification accuracy, recommendation quality, and state-awareness.", "excerpt": "A comprehensive evaluation framework has been built to measure the real-world performance of RAG++ v0 across three critical dimensions: action classification accuracy, recommendation quality, and state-awareness.\n\n1. **[types.ts](src/evaluation/types.ts)** (134 lines) - Complete TypeScript interfaces for all evaluation metrics - ActionClassificationMetrics, RecommendationQualityMetrics, StateAwarenessMetrics - RAGPPEvaluationReport with V0 success criteria - EvaluationConfig for customization\n\n2. **[ActionClassificationEval.ts](src/evaluation/ActionClassificationEval.ts)** (415 lines) - Measures precision, recall, F1 for 4 action types - Supports heuristic, LLM, and hybrid methods - Includes 30 hand-labeled sample events for testing - Multi-label confusion matrix computation - **Target**: F1 ≥ 70%\n\n3. **[RecommendationQualityEval.ts](src/evaluation/RecommendationQualityEval.ts)** (508 lines) - Interactive and simulated user feedback modes - 1-5 relevance scoring (\"oh wow\" = 5) - Confidence calibration measurement - Baseline generators (random policy, most-frequent action) - Regime-specific feedback tracking - **Targets**: 65% relevance rate, 30% \"oh wow\" rate\n\n4. **[StateAwarenessEval.ts](src/evaluation/StateAwarenessEval.ts)** (568 lines) - Regime consistency (same state → same recs) - Regime differentiation (different state → different recs) - Flag sensitivity (scattered/heavy/pressured → appropriate actions) - Phase awareness (day-of-week, time-of-day variations) - Explainability scoring (reasoning quality) - **Target**: Regime differentiation ≥ 50%", "htmlHref": "/research/html/rag-v0-evaluation-framework-complete-implementation-1sq1328.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1676 }, { "id": "trajectory-core-service-1g3v0v5", "title": "Trajectory Core Service", "slug": "trajectory-core-service", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/services/trajectory-core/README.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The core service powering TrajectoryOS. Implements the Life Physics model, manages state persistence, and provides REST API for all physics calculations.", "excerpt": "**Status**: ✅ **Live** - Production-ready life physics engine and state management\n\nThe core service powering TrajectoryOS. Implements the Life Physics model, manages state persistence, and provides REST API for all physics calculations.\n\n**GET `/api/state/:userId`** - Get current life state for user - Response: `LifeState` object with physics metrics\n\n**GET `/api/state/:userId/history`** - Get historical state snapshots - Query params: `?limit=30&offset=0` - Response: Array of `LifeState` objects\n\n**POST `/api/state/:userId/update`** - Manually trigger state recalculation - Body: `{ reason?: string }` - Response: Updated `LifeState`", "htmlHref": "/research/html/trajectory-core-service-1g3v0v5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1602 }, { "id": "echelon-world-ui-production-implementation-guide-1vtvo1w", "title": "Echelon World UI - Production Implementation Guide", "slug": "echelon-world-ui-production-implementation-guide", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/docs/ECHELON_UI_IMPLEMENTATION.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Echelon is a **motion-driven, phrase-based generative performance engine** whose temporal structure emerges from embodied latent physics. The UI depicts a *world*, not tools. There are no decks, no crossfaders, no timelines—only a living latent space that responds to the dancer's body.", "excerpt": "Echelon is a **motion-driven, phrase-based generative performance engine** whose temporal structure emerges from embodied latent physics. The UI depicts a *world*, not tools. There are no decks, no crossfaders, no timelines—only a living latent space that responds to the dancer's body.\n\nThe body is the timeline. LIM-RPS is the internal physics. Music emerges from latent curvature.\n\n> **Critical Principle**: The Web UI never computes physics. It renders the Rust-computed latent world. All equilibrium solving, state machine logic, and lexicon computation happens in cc-brain. The UI is a pure visualization layer.\n\n1. **Audio Latency**: Unchanged - real-time JACK/CPAL (< 10ms) 2. **Sensor → Audio Path**: No web browser in the loop 3. **cc-brain Integration**: Rust-native encoder + equilibrium solver 4. **WebSocket Broadcast**: Non-blocking `tokio::sync::broadcast::Sender::send()`\n\n- **Sensor ingestion**: 100-200 Hz (smartphone IMU rate) - **cc-brain processing**: Per sensor frame (variable step) - **UI visualization**: 60fps downsampled snapshots for GPU stability", "htmlHref": "/research/html/echelon-world-ui-production-implementation-guide-1vtvo1w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2308 }, { "id": "cc-echelon-implementation-status-9xtk77", "title": "CC-ECHELON IMPLEMENTATION STATUS", "slug": "cc-echelon-implementation-status", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/IMPLEMENTATION_STATUS.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. **cc-protocol crate structure** - ✅ Cargo.toml with dependencies - ✅ README.md with architecture overview - ✅ lib.rs with module structure - ✅ sensor.rs - Complete `SensorFrame` and `MultiDeviceFrame` types - ✅ coherence.rs - `CoherenceMetrics`, `CouplingMode`, dual-time contract", "excerpt": "1. **cc-protocol crate structure** - ✅ Cargo.toml with dependencies - ✅ README.md with architecture overview - ✅ lib.rs with module structure - ✅ sensor.rs - Complete `SensorFrame` and `MultiDeviceFrame` types - ✅ coherence.rs - `CoherenceMetrics`, `CouplingMode`, dual-time contract\n\n2. **Existing cc-brain components** - ✅ `LatentState` - Embodied physics (LIM-RPS output) - ✅ `SectionStateMachine` - State transitions - ✅ `LexiconController` - Expressive control signals - ✅ `EchelonCore` - Main brain controller - ✅ SimpleLatentUpdater & LearnedLatentUpdater\n\n3. **Existing cc-echelon crates** - ✅ motion-bridge - Network communication - ✅ audio-engine - Audio graph foundation - ✅ control-bus - Message passing - ✅ scheduler - Task scheduling\n\n1. **cc-protocol core types** - 🚧 latent.rs - LatentState (will re-export from cc-brain) - 🚧 section_state.rs - SectionState (will re-export from cc-brain) - 🚧 control_packet.rs - THE MAIN MESSAGE - 🚧 clock.rs - ExecutionClock with quantization\n\n2. **Strudel-IR (Symbolic Music)** - 🚧 strudel_ir/pattern.rs - Pattern, Layer, Note - 🚧 strudel_ir/edit.rs - PatternEdit operations - 🚧 strudel_ir/effect.rs - FX types - 🚧 strudel_ir/api.rs - Generated from CSV", "htmlHref": "/research/html/cc-echelon-implementation-status-9xtk77.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 910 }, { "id": "option-a-strudel-integration-implementation-status-y026i4", "title": "Option A: Strudel Integration - Implementation Status", "slug": "option-a-strudel-integration-implementation-status", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/OPTION_A_STATUS.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Files to modify**: 1. `apps/echelon-tauri/src-tauri/src/commands.rs` - Add `apply_pattern_edit()` command - Add `get_conductor_status()` command", "excerpt": "## 🎯 Goal Wire existing Rust components (LIM-RPS, Rehearsal, Conductor) to Strudel.js for real-time pattern-based music generation controlled by body movement.\n\n### 1. Comprehensive Codebase Analysis - ✅ Discovered **cc-core** contains full LIM-RPS implementation (Python/JAX) - ✅ Discovered **cc-brain** crate with Rehearsal and Conductor (Rust) - ✅ Confirmed **cc-protocol** Strudel-IR types are production-ready - ✅ Verified **audio-engine** with comprehensive synth library - ✅ Confirmed **echelon-tauri** desktop app is operational\n\n### 2. Architecture Design - ✅ Created [STRUDEL_INTEGRATION_PLAN.md](./STRUDEL_INTEGRATION_PLAN.md) (full 10-day plan) - ✅ Designed Rust → JavaScript bridge via Tauri events - ✅ Specified PatternEdit command flow - ✅ Defined section-based pattern mapping strategy\n\n### 3. StrudelEngine Implementation - ✅ Created [StrudelEngine.js](./apps/echelon-tauri/src/audio/StrudelEngine.js) - ✅ Implemented pattern parameter system (kick_gain, hihat_density, bass_cutoff, etc.) - ✅ Designed section-specific pattern templates: - Intro (sparse kick, minimal hats, ambient pads) - Groove (four-on-floor, offbeat snare, bass line) - Build (accelerating hats, rising bass, tension) - Climax (heavy kick, dense hats, driving bass) - Breakdown (no kick, emphasized pads, reverb) - Outro (fading elements) - ✅ Implemented `applyEdit()` method for: - SetParam (with optional transition_beats) - ScheduleEvent (with beat_offset and intensity) - Transform (track-specific transforms) - SectionChange (pattern template switching)\n\n**Files to modify**: 1. `apps/echelon-tauri/src-tauri/src/commands.rs` - Add `apply_pattern_edit()` command - Add `get_conductor_status()` command", "htmlHref": "/research/html/option-a-strudel-integration-implementation-status-y026i4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1171 }, { "id": "phase-3-complete-conductor-integration-5ba5ox", "title": "🎉 Phase 3 Complete: Conductor Integration", "slug": "phase-3-complete-conductor-integration", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/PHASE_3_COMPLETE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` ┌──────────────┐ │ iPhone/ │ │ Watch/ │ Sensors @ 100 Hz │ AirPods │ └──────┬───────┘ │ ↓ WebSocket ┌──────────────┐ │ cc-mcs │ LIM-RPS latent physics │ (Backend) │ Computes tension, velocity, coherence └──────┬───────┘ │ ↓ Polling (50 Hz) ┌──────────────┐ │ echelon- │ │ tauri │ │ (Desktop) │ └──────┬───────┘ │ ├──────────────────┐ ↓ ↓ ┌──────────────┐ ┌──────────────┐ │ Audio │ │ Conductor │ ⭐ PHASE 3 │ Engine │ │ Thread │ └──────────────┘ └──────┬───────┘ │ ↓ Section logic ┌──────────────┐ │ PatternEdit │ Set", "excerpt": "**Completion Date**: December 20, 2025 **Status**: ✅ **END-TO-END PIPELINE OPERATIONAL**\n\n**Purpose**: Background thread that converts latent state into musical sections and PatternEdits\n\n1. **Section State Machine** - Intro → Groove → Build → Climax → Breakdown → Outro - Transitions based on latent metrics (tension, velocity, coherence)\n\n2. **Automatic PatternEdit Generation** - Section changes trigger `SectionChange` edits - Periodic parameter adjustments every 4 seconds - Maps latent state to musical parameters\n\n3. **Musical Mappings**: - **Tension** → Bass filter cutoff (400-2000 Hz) - **Velocity** → Kick gain, hi-hat density - **Curvature** → Hi-hat variations - **Coherence** → Section stability", "htmlHref": "/research/html/phase-3-complete-conductor-integration-5ba5ox.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1584 }, { "id": "cc-protocol-implementation-progress-1f8w4kq", "title": "CC-PROTOCOL IMPLEMENTATION PROGRESS", "slug": "cc-protocol-implementation-progress", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/PROTOCOL_PROGRESS.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Total Lines:** ~2,500+ - **Total Tests:** 51+ - **Core Types:** 15+ - **Enums:** 6 - **Test Coverage:** All core paths covered", "excerpt": "### 1. **lib.rs** (90 lines) - Module structure - Re-exports - Error types - Protocol versioning\n\n### 2. **sensor.rs** (350+ lines) - `SensorFrame` - Raw IMU data with full documentation - `MultiDeviceFrame` - Multi-device aggregation - Helper methods (linear_accel, magnitudes, roll/pitch/yaw) - Comprehensive tests (8 tests)\n\n### 3. **coherence.rs** (250+ lines) - `CouplingMode` enum (Free, SoftLock, HardLock) - `CoherenceMetrics` - Dual-time system state - Mode predicates and helpers - Tests (7 tests)\n\n### 4. **latent.rs** (400+ lines) - `LatentState` - Core embodied physics representation - `LatentGeometry` - Trajectory shape/dynamics - Position/velocity helpers - Distance, interpolation methods - Tests (6 tests)\n\n### 5. **section_state.rs** (400+ lines) - `SectionState` enum (6 states) - `SectionStateContext` - Extended state with duration tracking - State predicates (allows_edits, is_stable, etc.) - UI helpers (colors, intensity, names) - Tests (7 tests)", "htmlHref": "/research/html/cc-protocol-implementation-progress-1f8w4kq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1012 }, { "id": "code-review-stemdeck-lume-stage-1-sample-locked-4-stem-playback-u6ji59", "title": "Code Review: StemDeck — LUME Stage 1 (sample-locked 4-stem playback)", "slug": "code-review-stemdeck-lume-stage-1-sample-locked-4-stem-playback", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/tools/lume-music/STEMDECK_REVIEW.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Meta-review (6-pass parallel + adversarial contrarian round) of commit `c3559889` > on branch `feat/femto-only-bar`, repo `Comp-Core`. > Reviewed files (NEW code only): > - `core/audio-media/cc-echelon/crates/audio-engine/src/stem_deck.rs` (963 lines) > - `core/audio-media/cc-echelon/crates/audio-engine/examples/stem_deck.rs` (167 lines) > Surrounding crate (`loader.rs`, `param_control.rs`, `fx.rs`, `lib.rs`) read for primitive-usage judgement only; findings are scoped to StemDeck.", "excerpt": "> Meta-review (6-pass parallel + adversarial contrarian round) of commit `c3559889` > on branch `feat/femto-only-bar`, repo `Comp-Core`. > Reviewed files (NEW code only): > - `core/audio-media/cc-echelon/crates/audio-engine/src/stem_deck.rs` (963 lines) > - `core/audio-media/cc-echelon/crates/audio-engine/examples/stem_deck.rs` (167 lines) > Surrounding crate (`loader.rs`, `param_control.rs`, `fx.rs`, `lib.rs`) read for primitive-usage judgement only; findings are scoped to StemDeck.\n\n- **Findings**: 21 total — **2 Critical**, **6 High**, **9 Medium**, **4 Low** - **Cross-Cutting Patterns**: (1) `render()` is treated as real-time-safe but is not — it does heavyweight per-sample work and can be driven into pathological states; (2) the API has no guard against being driven into silently-wrong states by a Stage 2 consumer (`StemConductor`); (3) no validation that the four stems of a \"set\" are actually consistent (length, content); (4) `f32`-as-`usize` casts saturate/truncate silently across the transport math. - **Overall Health**: Solid, well-documented, well-tested **functional core** with a genuinely good sample-locked-playhead design and strong analytic tests. **Not yet real-time-safe** and **not yet misuse-resistant** — both are blocking for the stated downstream use (audio-callback rendering + `StemConductor` driving the API). The bugs are real and concentrated in two areas: `render()` RT-safety and transport/loop edge cases. None are security-exploitable in the classic sense (local file inputs only), but several cause audible failure or silent drift.\n\n| ID | Description | File:Line | Fix | |----|-------------|-----------|-----| | **X1** | `render()` is documented and intended as an audio-callback path, but it is **not real-time-safe**: it runs `FilterFx`/`DelayFx`/`ReverbFx` `process_sample` per sample with `tan()`/`exp()`-class math and modulo ring-buffer indexing inline, calls `out.fill(0.0)` on the whole block, and re-evaluates branch-heavy loop logic every frame. On a real Demucs set (4 stems, full reverb = 8 comb + 4 allpass per channel) this is a large, unbounded-by-set-size per-block cost with no headroom guarantee. If `render()` is called directly from the CPAL callback it will glitch under load. | `stem_deck.rs:568-630` | Decide the contract explicitly. Either (a) document that `render()` runs on a **worker thread feeding `ChannelReceiver`** (the pattern `lib.rs:259-300` `RingCallback` already establishes — the callback only does a `copy_from_slice`), and state that in the doc-comment; or (b) if it truly runs in-callback, pre-compute filter coefficients on parameter change (not per sample) and bound worst-case cost. Right now the doc-comment claims callback use without meeting callback constraints. This is the single most im", "htmlHref": "/research/html/code-review-stemdeck-lume-stage-1-sample-locked-4-stem-playback-u6ji59.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4560 }, { "id": "phrase-conditioned-spectrogram-diffusion-system-1w9cqv5", "title": "Phrase-Conditioned Spectrogram Diffusion System", "slug": "phrase-conditioned-spectrogram-diffusion-system", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/ml/cc-ml/diffusion/README.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This module implements a diffusion-based generative audio system that learns from your music library and generates new audio conditioned on: 1. **Phrase embeddings** from your existing tracks 2. **Motion embeddings** from your body movement", "excerpt": "This module implements a diffusion-based generative audio system that learns from your music library and generates new audio conditioned on: 1. **Phrase embeddings** from your existing tracks 2. **Motion embeddings** from your body movement\n\n### 1. **Why Spectrogram Space (Not Raw Waveform)?** - **Faster**: Mel-spectrogram is ~256× smaller than raw audio - **Stable**: Diffusion converges faster on spectrograms - **Controllable**: Frequency bins map naturally to musical features\n\n### 2. **Why VQ-VAE + Vocoder?** - **Compression**: 44.1kHz × 4 bars = 705,600 samples → ~4096 tokens - **Quality**: HiFi-GAN vocoder produces high-fidelity audio - **Modularity**: Can swap vocoders (BigVGAN, UnivNet) later\n\n### 3. **Why DDIM Sampling (Not DDPM)?** - **Speed**: 20 steps vs. 1000 steps (50× faster) - **Quality**: Nearly identical output quality - **Latency**: ~200ms generation time (acceptable for live)\n\n### 4. **Why 4-Bar Buffer?** - **Musical**: 4 bars = 1 phrase in most music - **Latency**: ~8 seconds @ 120 BPM = comfortable lead time - **Coherence**: Long enough for harmonic/rhythmic structure", "htmlHref": "/research/html/phrase-conditioned-spectrogram-diffusion-system-1w9cqv5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1258 }, { "id": "cc-window-aligner-implementation-checklist-1eit4zu", "title": "CC Window Aligner: Implementation Checklist", "slug": "cc-window-aligner-implementation-checklist", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/motion/cc-window-aligner/docs/CHECKLIST.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Status | Meaning | |--------|---------| | `[ ]` | Not Started | | `[~]` | In Progress | | `[B]` | Blocked (see notes) | | `[x]` | Complete |", "excerpt": "| Status | Meaning | |--------|---------| | `[ ]` | Not Started | | `[~]` | In Progress | | `[B]` | Blocked (see notes) | | `[x]` | Complete |\n\n| ID | Description | Owner | Dependencies | Artifacts | Validation | Status | |----|-------------|-------|--------------|-----------|------------|--------| | 0.1.1 | Create PROJECT_CHARTER.md | Agent | None | docs/PROJECT_CHARTER.md | Document exists, all sections filled | [x] | | 0.1.2 | Create GLOSSARY.md | Agent | 0.1.1 | docs/GLOSSARY.md | All terms defined with layer/stability | [x] | | 0.1.3 | Create INVARIANTS.md | Agent | 0.1.2 | docs/INVARIANTS.md | 10 invariants documented with canaries | [x] | | 0.2.1 | Create IMPLEMENTATION_GUIDE.md | Agent | 0.1.3 | docs/IMPLEMENTATION_GUIDE.md | All stages specified, types defined | [x] | | 0.3.1 | Create CHECKLIST.md | Agent | 0.2.1 | docs/CHECKLIST.md | This document | [x] |\n\n| ID | Description | Owner | Dependencies | Artifacts | Validation | Status | |----|-------------|-------|--------------|-----------|------------|--------| | 1.1 | Create Cargo.toml with dependencies | Agent | Phase 0 | Cargo.toml | `cargo check` passes | [x] | | 1.2 | Create lib.rs with module structure | Agent | 1.1 | src/lib.rs | Compiles, exports public API | [x] | | 1.3 | Create error.rs with AlignerError | Agent | 1.2 | src/error.rs | All error variants defined | [x] |\n\n| ID | Description | Owner | Dependencies | Artifacts | Validation | Status | |----|-------------|-------|--------------|-----------|------------|--------| | 2.1 | Create types.rs with MotionWindow | Agent | 1.3 | src/types.rs | Matches IMPLEMENTATION_GUIDE spec | [x] | | 2.2 | Create SkeletonFrame and BoneState | Agent | 2.1 | src/types.rs | 27 bones, quaternion format | [x] | | 2.3 | Create DeviceMask with bit operations | Agent | 2.1 | src/types.rs | All device constants defined | [x] | | 2.4 | Create FrameProvenance | Agent | 2.3 | src/types.rs | Per-DOF tracking | [x] | | 2.5 | Create config.rs with WindowConfig | Agent | 2.4 | src/config.rs | All config fields, validation | [x] | | 2.6 | Create AlignerMode enum | Agent | 2.5 | src/config.rs | Strict and LowLatency modes | [x] | | 2.7 | Type contract review | Human | 2.1-2.6 | — | Types match IMPLEMENTATION_GUIDE | [ ] |\n\n| ID | Description | Owner | Dependencies | Artifacts | Validation | Status | |----|-------------|-------|--------------|-----------|------------|--------| | 3.1 | Create interpolation/mod.rs trait | Agent | Phase 2 | src/interpolation/mod.rs | Interpolator trait defined | [x] | | 3.2 | Implement linear interpolation | Agent | 3.1 | src/interpolation/linear.rs | Unit tests pass | [x] | | 3.3 | Implement slerp interpolation | Agent | 3.1 | src/interpolation/slerp.rs | Quaternion tests pass | [x] | | 3.4 | Implement hold interpolation | Agent | 3", "htmlHref": "/research/html/cc-window-aligner-implementation-checklist-1eit4zu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2551 }, { "id": "cc-window-aligner-implementation-guide-vj696r", "title": "CC Window Aligner: Implementation Guide", "slug": "cc-window-aligner-implementation-guide", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/motion/cc-window-aligner/docs/IMPLEMENTATION_GUIDE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Decision Type | Required Signals | Authority | |---------------|------------------|-----------| | **Type/Schema changes** | Charter + Invariants + Downstream impact | Lock requires review | | **Algorithm changes** | Invariants preserved + Tests pass | Implementation owner | | **Configuration defaults** | Performance + Safety tradeoff | Implementation owner | | **New device support** | DIR-003 compatibility + No breaking changes | Requires integration test |", "excerpt": "| Decision Type | Required Signals | Authority | |---------------|------------------|-----------| | **Type/Schema changes** | Charter + Invariants + Downstream impact | Lock requires review | | **Algorithm changes** | Invariants preserved + Tests pass | Implementation owner | | **Configuration defaults** | Performance + Safety tradeoff | Implementation owner | | **New device support** | DIR-003 compatibility + No breaking changes | Requires integration test |\n\n| Conflict Type | Resolution | |---------------|------------| | **Invariants vs. Performance** | Invariants always win. Find alternative optimization. | | **Strict vs. Low-Latency** | Mode selection by caller. Both must work. | | **Simplicity vs. Completeness** | Completeness for invariant-related code. Simplicity elsewhere. | | **Determinism vs. Floating-point efficiency** | Determinism wins. Use reproducible operations. |\n\nA component is \"done\" when: 1. Implementation matches specification in this guide 2. All relevant invariants are enforced (see INVARIANTS.md) 3. Unit tests cover happy path + edge cases + failure modes 4. Integration test with at least one downstream consumer passes 5. Documentation is complete (inline + docs/) 6. No TODOs remain in implementation\n\nA component is \"blocked\" when: 1. Required upstream dependency does not exist 2. Invariant cannot be satisfied with current design 3. Clarification needed from charter (ambiguous requirement) 4. Performance target cannot be met\n\nEach implementation task (checklist item) must: - Touch at most ONE stage or ONE module - Produce at most ONE new public type - Be completable in one session - Have clear validation criteria", "htmlHref": "/research/html/cc-window-aligner-implementation-guide-vj696r.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2000 }, { "id": "python-rag-plusplus-slice-hebtl8", "title": "Python (rag_plusplus.slice)", "slug": "python-rag-plusplus-slice", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/docs/GRAPH_KERNEL_INTEGRATION.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. [Overview](#1-overview) 2. [Architecture](#2-architecture) 3. [Core Concepts](#3-core-concepts) 4. [Graph Kernel Service (Rust)](#4-graph-kernel-service-rust) 5. [RAG++ Slice Client (Python)](#5-rag-slice-client-python) 6. [Slice-Conditioned Retrieval](#6-slice-conditioned-retrieval) 7. [Provenance Chain](#7-provenance-chain) 8. [Production Hardening](#8-production-hardening) 9. [API Reference](#9-api-reference) 10. [Deployment](#10-deployment) 11. [Testing](#11-testing) 12. [Migration Guide](#12-migration-guide", "excerpt": "> **See Also**: [Production Invariants](./PRODUCTION_INVARIANTS.md) for non-negotiable rules.\n\n1. [Overview](#1-overview) 2. [Architecture](#2-architecture) 3. [Core Concepts](#3-core-concepts) 4. [Graph Kernel Service (Rust)](#4-graph-kernel-service-rust) 5. [RAG++ Slice Client (Python)](#5-rag-slice-client-python) 6. [Slice-Conditioned Retrieval](#6-slice-conditioned-retrieval) 7. [Provenance Chain](#7-provenance-chain) 8. [Production Hardening](#8-production-hardening) 9. [API Reference](#9-api-reference) 10. [Deployment](#10-deployment) 11. [Testing](#11-testing) 12. [Migration Guide](#12-migration-guide)\n\nThis integration makes `cc-graph-kernel` the **sole authority** for determining what context is allowed to influence meaning in RAG++ retrieval. The core principle is:\n\n> Nothing downstream is allowed to read \"raw graph neighborhoods\" directly. Everything must be mediated by `SliceExport` from the Graph Kernel.\n\n| Benefit | Description | |---------|-------------| | **Determinism** | Same anchor + policy → same slice_id → byte-for-byte reproducible results | | **Provenance** | Full chain of custody: query → slice → results → semantic artifacts | | **Admissibility Gating** | Only slice-scoped results can promote to semantic artifacts | | **Replay Capability** | Any retrieval can be replayed by citing (slice_id, query_hash, policy_hash) |", "htmlHref": "/research/html/python-rag-plusplus-slice-hebtl8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2870 }, { "id": "nko-inscription-system-phase-2-implementation-report-1hgb3d", "title": "N'Ko Inscription System - Phase 2 Implementation Report", "slug": "nko-inscription-system-phase-2-implementation-report", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/core/semantic/cc-inscription/docs/PHASE2_IMPLEMENTATION.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Phase 2 transforms cc-inscription from a foundational type system into a **living discipline** with: - Rigorous basin lifecycle management (split/merge with cryptographic provenance) - Graph Kernel governance for ontology operations - RAG++ as laboratory assistant for predictability evaluation - Lexicon version chain traversal and reinterpretation layer - Information-theoretic phrase emergence", "excerpt": "Phase 2 transforms cc-inscription from a foundational type system into a **living discipline** with: - Rigorous basin lifecycle management (split/merge with cryptographic provenance) - Graph Kernel governance for ontology operations - RAG++ as laboratory assistant for predictability evaluation - Lexicon version chain traversal and reinterpretation layer - Information-theoretic phrase emergence\n\n- **Slice Governance**: Every ontology change requires a slice declaration proving the operation is justified by evidence within the current temporal window - **Predictability Assessment**: Before/after metrics ensure changes improve the system's predictive consistency - **Builder Pattern**: `OntologyOperationBuilder` validates all required fields before construction\n\n- `request_ontology_slice()`: Request a slice for ontology operations - `verify_slice_declaration()`: Verify a slice declaration is valid - `check_evidence_sufficiency()`: Ensure evidence meets minimum requirements\n\nRAG++ serves as a **bounded critic**, measuring predictability deltas without generating ontology changes.\n\n- `evaluate_predictability()`: Measure before/after predictability for proposed changes - `find_comparable_cases()`: Retrieve similar historical cases within slice - `compute_prediction_error()`: Information-theoretic error measurement - `kl_divergence()`: Symmetric KL divergence between claim distributions", "htmlHref": "/research/html/nko-inscription-system-phase-2-implementation-report-1hgb3d.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2704 }, { "id": "shared-state-schema-1le8f5u", "title": "Shared State Schema", "slug": "shared-state-schema", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/agent-protocol/STATE_SCHEMA.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document defines the shared state format for agent coordination, including access patterns, locking mechanisms, and event bus design.", "excerpt": "This document defines the shared state format for agent coordination, including access patterns, locking mechanisms, and event bus design.\n\n1. [State Architecture](#state-architecture) 2. [State Schema](#state-schema) 3. [Agent-Specific State](#agent-specific-state) 4. [Access Control](#access-control) 5. [Concurrency & Locking](#concurrency--locking) 6. [Event Bus Design](#event-bus-design) 7. [Persistence](#persistence)\n\n| State Path | Pulse | Heartbeat | Dream Weaver | Conductor | Guardian | |------------|-------|-----------|--------------|-----------|----------| | `global.config` | R | R | R | RW | R | | `global.registry` | R | R | R | RW | R | | `global.tasks` | R | R | R | RW | R | | `global.metrics` | R | R | R | RW | R | | `global.health` | R | R | R | RW | RW | | `agents.pulse.*` | RW¹ | R | R | RW | R | | `agents.heartbeat.*` | R | RW¹ | R | RW | R | | `agents.dream_weaver.*` | R | R | RW¹ | RW | R | | `agents.conductor.*` | R | R | R | RW | R | | `locks.*` | RW² | RW² | RW² | RW | R |\n\n- [PROTOCOL.md](./PROTOCOL.md) — Agent coordination protocol - [src/](./src/) — TypeScript type definitions", "htmlHref": "/research/html/shared-state-schema-1le8f5u.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2060 }, { "id": "anticipation-pipeline-diagram-1b0rtfn", "title": "Anticipation Pipeline Diagram", "slug": "anticipation-pipeline-diagram", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/architecture/diagrams/anticipation-pipeline.md", "extension": "md", "score": 32, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "```mermaid flowchart TB subgraph Input [Input: MotionWindow] MW[MotionWindow
50 frames @ 50Hz] SF[SkeletonFrames
27 bones × 50 frames] LF[LatentFrames
Optional embeddings] Coverage[Coverage Check
≥ 0.9 required] end", "excerpt": "**Version**: 2.0.0 **Last Updated**: 2025-01-01 **Parent**: [06-ANTICIPATION.md](../06-ANTICIPATION.md)\n\nWhere `constraint_saturation` = how close to physical limits (joint angles, balance).\n\n| Value | Meaning | System Response | |-------|---------|-----------------| | 0.0-0.3 | Low | Observe, wait | | 0.3-0.6 | Medium | Prepare response | | 0.6-0.8 | High | Begin execution | | 0.8-1.0 | Very High | Full commit |\n\n| Value | Meaning | |-------|---------| | > 0.5 | Strong convergence | | 0.0-0.5 | Gentle convergence | | -0.5-0.0 | Gentle divergence | | < -0.5 | Strong divergence |\n\n| ID | Invariant | Check Location | |----|-----------|----------------| | INV-001 | Deterministic | No random seeds | | INV-003 | Coverage ≥ 0.9 | Entry validation | | INV-004 | Scalars in bounds | Packet creation | | INV-005 | Bone count = 27 | Frame validation | | INV-007 | Schema version | Deserialization |", "htmlHref": "/research/html/anticipation-pipeline-diagram-1b0rtfn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 639 }, { "id": "codex-handoff-partial-real-thunder-train-lane-njrsek", "title": "Codex Handoff: Partial-Real Thunder Train Lane", "slug": "codex-handoff-partial-real-thunder-train-lane", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/docs/handoffs/codex-partial-real-thunder-handoff-2026-04-25.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This handoff is for one bounded job only: get the first completed partial-real local Thunder training window to finish cleanly and verify that it writes a real checkpoint. Do not expand scope beyond that.", "excerpt": "This handoff is for one bounded job only: get the first completed partial-real local Thunder training window to finish cleanly and verify that it writes a real checkpoint. Do not expand scope beyond that.\n\nThe system context matters because this lane sits inside a larger architecture. The canonical acoustic science lane is running separately on Vast and is responsible for the paper-grade CER claims. That lane is the same-snapshot Paper 4 matrix on the A100 instance and it should be treated as read-only from this handoff. The local Thunder lane is different. It is the AGP and Gemma correction-adapter lane. Gemma is not the authority model. Gemma is the bounded proposal model that only acts after the AGP partition router says a chunk deserves additional compute. Rust admissibility is still the final authority for whether a proposed correction is allowed.\n\nThe current goal is therefore narrow and practical. We already proved the mechanics on a synthetic correction set. We already proved that the launchers, chunk runner, and local distributed setup can work. The next real milestone is to prove that a first bounded training window can run on a partial-real correction corpus built from actual A100 replay outputs. This is the first time the local Gemma adapter lane will be training on real replay-derived correction rows rather than the small synthetic mechanics set.\n\n- the local and remote Thunder dataset path for the partial-real corpus - the Gemma cache warm state on `mac4` and `mac5` - the partial-real Thunder launcher and chunk runner - the dedicated adapter output path for the partial-real run - checkpoint verification and artifact mirroring back to local\n\n- the Vast closeout watcher - the A100 instance lifecycle - the paper text or manuscript framing - the MAOE replay scripts unless needed only to read field names or confirm input format - routing logic redesign - changing the correction policy", "htmlHref": "/research/html/codex-handoff-partial-real-thunder-train-lane-njrsek.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1534 }, { "id": "agp-mlx-ane-training-spec-uhx94s", "title": "AGP / MLX / ANE Training Spec", "slug": "agp-mlx-ane-training-spec", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/docs/research/agp-mlx-ane-training-spec.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The first trainable version of AGP is not a new foundation model. It is a `Gemma 4 E2B` decoder transformer wrapped in a small set of new trainable interfaces. The objective is to teach the system four things at once: how to speak in your distribution, how to estimate whether an intermediate state is alive enough to trust, how to project that state into a typed semantic layer, and how to compress or route that state without paying for full-depth inference every time. The right starting point is therefore not full-m", "excerpt": "The first trainable version of AGP is not a new foundation model. It is a `Gemma 4 E2B` decoder transformer wrapped in a small set of new trainable interfaces. The objective is to teach the system four things at once: how to speak in your distribution, how to estimate whether an intermediate state is alive enough to trust, how to project that state into a typed semantic layer, and how to compress or route that state without paying for full-depth inference every time. The right starting point is therefore not full-model training. The right starting point is `adapter-first curriculum training` on top of a mostly frozen base model in `MLX`.\n\nThe architecture we are training has five trainable regions. The first region is the ordinary language-model adaptation layer, which is a LoRA or DoRA-style adapter on selected Gemma blocks so the base model moves toward your conversational, coding, and memory-grounded distribution. The second region is the `trajectory and vitality head`, which reads selected hidden layers and predicts the routing state of the current reasoning process. The third region is the `semantic projection head`, which turns dense hidden states into sparse activations over kernel-aligned primitives, invariants, and bundle neighborhoods. The fourth region is the `depth-routing residual module`, which learns whether earlier hidden states are sufficient and how much prior depth should still matter. The fifth region is the `transfer adapter`, which encodes a cross-host packet and then reconstructs a continuation-ready latent on the receiving side.\n\nThe first thing we train is not the routing logic. It is not the transfer adapter either. We first train a `domain adapter` so the base Gemma hidden states become useful on your own distribution. If we skip that and train routing on generic hidden states, we end up learning a scheduler over the wrong representation manifold. So the actual order is strict. First produce a strong local LoRA-tuned Gemma 4 E2B on your data. Then use that tuned model as the teacher and backbone for every later AGP head.\n\nThis matters because the architecture is trying to decide when a hidden state is sufficient. Sufficiency depends on the actual target workload. A hidden state that is sufficient for generic internet chat may not be sufficient for your prompt style, your code tasks, your memory-heavy requests, or your semantic-layer work. The hidden-state geometry has to be measured and trained on the real distribution.\n\nThe canonical base for training is `Gemma 4 E2B`. The E2B model is small enough to iterate on two 16 GB Apple machines and large enough to expose meaningful intermediate-state structure. The next scale-up model is `Gemma 4 E4B`, but that is phase two only. We should not jump to E4B before the curriculum and", "htmlHref": "/research/html/agp-mlx-ane-training-spec-uhx94s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2688 }, { "id": "agp-mlx-for-nko-anticipation-partitioning-1l2pg66", "title": "AGP-MLX for N'Ko Anticipation Partitioning", "slug": "agp-mlx-for-nko-anticipation-partitioning", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/docs/research/agp-mlx-nko-anticipation-partitioning-v1.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Current status remains `NO-GO` until the learned live proposal path clears that gate on the authoritative five-run post-TTT corpus.", "excerpt": "The canonical ship bar for calling this a fully live learned N'Ko corrector at scale is defined in:\n\nCurrent status remains `NO-GO` until the learned live proposal path clears that gate on the authoritative five-run post-TTT corpus.\n\n`agp_mlx` is the correct substrate for the N'Ko speech-language fusion idea, but it should not replace the acoustic ASR stack yet.\n\nThe acoustic model remains responsible for sound-to-script evidence. AGP-MLX becomes the partitioned language-prior and corrective layer.\n\nThis means the AGP stack already has the three things needed for an ASR integration:", "htmlHref": "/research/html/agp-mlx-for-nko-anticipation-partitioning-1l2pg66.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 917 }, { "id": "agp-nko-live-corrector-release-gate-v1-6vs8jy", "title": "AGP N'Ko Live Corrector Release Gate V1", "slug": "agp-nko-live-corrector-release-gate-v1", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/docs/research/agp-nko-live-corrector-release-gate-v1.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "2.1.3 The evaluation corpus must contain real ASR predictions and real references from the same provenance as the deployment path.", "excerpt": "1.1.1 This document defines the release gate for calling AGP a fully live learned N'Ko corrector at scale.\n\n1.2.3 This document does not allow open-horizon corrective continuation as a valid ship target.\n\n[ip] `ASR output -> learned AGP proposal -> Rust gate -> bounded accepted edit -> lower CER`\n\n2.1.2 The proposal source must be the learned live AGP path, not an oracle reference substitution.\n\n2.1.3 The evaluation corpus must contain real ASR predictions and real references from the same provenance as the deployment path.", "htmlHref": "/research/html/agp-nko-live-corrector-release-gate-v1-6vs8jy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 908 }, { "id": "agp-supervised-runtime-envelope-u4nf2t", "title": "AGP Supervised Runtime Envelope", "slug": "agp-supervised-runtime-envelope", "kind": "research note", "program": "Research Backlog", "sourceAnchor": "Comp-Core/docs/research/agp-supervised-runtime-envelope-2026-04-18.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Both are now supervised by `runtime/supervise_agp_server_v1.sh`, and the client transport path is hardened by reconnect and retry logic in `runtime/run_cross_host_packet_replay_v1.py`.", "excerpt": "As of 2026-04-18, the promoted cross-host runtime pair is the supervised `9430 + 9434` path on `mac5`.\n\nBoth are now supervised by `runtime/supervise_agp_server_v1.sh`, and the client transport path is hardened by reconnect and retry logic in `runtime/run_cross_host_packet_replay_v1.py`.\n\nThis matters because the earlier frontier was not limited by representational quality alone. It was limited by daemon lifetime and process churn. Once the runtime was supervised and the client learned how to survive restarts, the architecture crossed into a more credible operating regime.\n\nThe main supervised sweep over remote margin thresholds on the held-out Thunder validation slice produced six evaluated operating points.\n\nAt `0.03`, the system executed `13` steps and reached `0.6154` top-1 teacher match with mean KL `1.0492` and mean RTT `43.66ms`. This is too permissive. It buys coverage, but not enough quality or latency advantage to justify promotion.", "htmlHref": "/research/html/agp-supervised-runtime-envelope-u4nf2t.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 610 }, { "id": "agp-turboquant-apple-neural-engine-performance-plan-1nsstry", "title": "AGP TurboQuant + Apple Neural Engine Performance Plan", "slug": "agp-turboquant-apple-neural-engine-performance-plan", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/research/agp-turboquant-ane-performance-plan.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This plan turns the local TurboQuant and Apple Neural Engine research into an executable AGP performance lane. The goal is not to add accelerator names to the paper. The goal is to prove which parts of AGP become faster, smaller, or more energy efficient when the system uses the right engine for the right class of computation.", "excerpt": "This plan turns the local TurboQuant and Apple Neural Engine research into an executable AGP performance lane. The goal is not to add accelerator names to the paper. The goal is to prove which parts of AGP become faster, smaller, or more energy efficient when the system uses the right engine for the right class of computation.\n\n- `Desktop/cog-rlm/scripts/turboquant.py` - `Desktop/cog-rlm/scripts/ane_bridge.py` - `Desktop/cog-rlm/scripts/ane_lora_mil.py` - `Desktop/cog-rlm/scripts/ane_trainer.py` - `Desktop/cog-rlm/scripts/ane_whisper_spike.py` - `Desktop/cog-rlm/scripts/ane_mlx_train.py`\n\nTurboQuant belongs at the compression boundary, not at the acoustic model boundary. It should compress embedding indexes, hidden-state transfer packets, and AGP-PTP payloads. Its role is state mobility under bounded distortion.\n\nThe Apple Neural Engine belongs at the reflex boundary, not at the full-transformer training boundary. It should run compact projection-heavy heads: route, vitality, semantic projection, sigil or partition classifiers, and later frozen-forward projection kernels if the private MIL path remains stable. Its role is low-power repeated inference, not replacing MLX/GPU training.\n\n- `4-bit`: about `0.993` cosine on real `768D` embeddings. - `4-bit`: about `0.95-0.98` recall@10 on small real samples. - `4-bit`: about `5.9x` compression versus fp32. - `8-bit`: effectively lossless retrieval behavior in the small eval.", "htmlHref": "/research/html/agp-turboquant-apple-neural-engine-performance-plan-1nsstry.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1697 }, { "id": "mixture-of-anticipatory-orthogonal-experts-for-nko-asr-1suiith", "title": "Mixture of Anticipatory Orthogonal Experts for N'Ko ASR", "slug": "mixture-of-anticipatory-orthogonal-experts-for-nko-asr", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/docs/research/nko-mixture-of-anticipatory-orthogonal-experts-v1.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The MoVE paper is directionally useful because it demonstrates a disciplined way to avoid a monolithic speech model: keep a pretrained audio-language model fixed, train specialized LoRA experts, and learn a router that blends or selects those experts by speech-token state. The useful idea is not the exact vocalization target. Their target is expressive speech-to-speech translation with emotion and non-verbal vocalization preservation. Our target is N'Ko ASR correction with acoustic authority, graph admissibility, i", "excerpt": "The MoVE paper is directionally useful because it demonstrates a disciplined way to avoid a monolithic speech model: keep a pretrained audio-language model fixed, train specialized LoRA experts, and learn a router that blends or selects those experts by speech-token state. The useful idea is not the exact vocalization target. Their target is expressive speech-to-speech translation with emotion and non-verbal vocalization preservation. Our target is N'Ko ASR correction with acoustic authority, graph admissibility, inscription consistency, and bounded CER improvement.\n\nThe correct N'Ko analogue is a Mixture of Anticipatory Orthogonal Experts. \"Anticipatory\" means each expert is activated by trajectory scalars that describe where the decoder is going: stable, crossing a boundary, uncertain, recovering, or encountering novelty. \"Orthogonal\" means the experts are not all trying to do the same correction. Each expert owns a different axis of authority: acoustic preservation, boundary completion, uncertain repair, recovery context, or novelty quarantine. The router is not a generic MoE router optimizing token likelihood. It is an admissibility router deciding which authority is allowed to act.\n\nThis becomes paper-worthy if we can show that expert activation improves CER without increasing accepted-worse edits. A normal ASR rescoring paper says a language model improves transcription. This architecture says the language model is only allowed to act inside specific anticipation partitions and must pass an external admissibility gate. That makes the contribution less like \"add an LM\" and more like \"formalize when a language prior is authorized to modify acoustic evidence.\"\n\nThe novelty claim is strongest for N'Ko because N'Ko is phonetically transparent and culturally tied to inscription. A correction is not just a better token. It is a transition between sound, glyph, trajectory, and canonical writing. Stable acoustic evidence should remain sovereign. Boundary evidence can accept one-glyph completion. Uncertain evidence can consult a corrective prior. Recovery can use context, but only locally. Novelty should be preserved for corpus growth instead of normalized into familiar text. That is a different scientific object from ordinary speech-to-text postprocessing.\n\nMoVE confirms that specialized experts plus a learned router can be a better architecture than a single blended model when speech contains multiple latent regimes. It also supports the adapter-first path: train small expert adapters or heads instead of retraining the full model. For us, this strengthens the case for partition-specific N'Ko correction adapters, a small route/vitality/partition head, and a frozen or mostly frozen acoustic anchor.", "htmlHref": "/research/html/mixture-of-anticipatory-orthogonal-experts-for-nko-asr-1suiith.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1158 }, { "id": "generative-output-overview-12nckzi", "title": "Generative Output Overview", "slug": "generative-output-overview", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/04-generative-output/overview.md", "extension": "md", "score": 32, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Generative output is the part of the system that turns body state into sound, visuals, camera decisions, DJ control, and inscriptions.", "excerpt": "Generative output is the part of the system that turns body state into sound, visuals, camera decisions, DJ control, and inscriptions.\n\nThe old version of this page overstated SAN training and treated the output layer as if one trained model controlled everything. The current source shows multiple lanes with different maturity levels.\n\n- Rust Echelon audio handle renders audio. - MotionMixApp bridges brain state to audio. - SAN can produce adaptive output parameters. - `DiffusionService` can generate token grids through phone hub, CoreML, or fallback paths.\n\n- Unity/LUME receives skeleton/body/motion data. - Mac4 currently feeds Unity from mocopi locally. - DYK/LUME visuals should eventually consume stable BodyTruth, but direct local mocopi feed is currently the more stable visual path.\n\n- K11 owns Rekordbox command safety. - Gesture detection can use camera pose even when mocopi is off. - mocopi improves accuracy but must not be a hard requirement for basic camera gestures.", "htmlHref": "/research/html/generative-output-overview-12nckzi.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 429 }, { "id": "path-f-live-performance-optimized-minimize-latency-at-all-costs-1aj4ojj", "title": "Path F: Live Performance Optimized -- Minimize Latency at All Costs", "slug": "path-f-live-performance-optimized-minimize-latency-at-all-costs", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-full-system-architecture/stage1-path-f.md", "extension": "md", "score": 32, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Every design decision is filtered through one question: does this add latency? If yes, reject it. Direct UDP everywhere. No middleware, no brokers, no HTTP coordination. Publishers bind [ip] and consumers hardcode IPs. The system is static: every connection is pre-configured at deploy time. No dynamic discovery, no subscriptions, no health checks. The absolute minimum number of network hops between any sensor and any output. Where possible, merge publisher and consumer onto the same process.", "excerpt": "Every design decision is filtered through one question: does this add latency? If yes, reject it. Direct UDP everywhere. No middleware, no brokers, no HTTP coordination. Publishers bind [ip] and consumers hardcode IPs. The system is static: every connection is pre-configured at deploy time. No dynamic discovery, no subscriptions, no health checks. The absolute minimum number of network hops between any sensor and any output. Where possible, merge publisher and consumer onto the same process.\n\n| Hop | Path | Latency | |-----|------|---------| | 1 | Femto ToF capture | ~5ms | | 2 | pyorbbecsdk -> Python | ~1ms | | 3 | UDP loopback :9700 | <0.5ms | | 4 | Unity receive + reproject | ~2ms | | 5 | Unity render + display | ~5ms | | **Visual total** | **Sensor -> pixel** | **~13ms** | | | | | | 1 | mocopi BLE -> Sony app | ~15ms | | 2 | Sony -> :12351 -> bridge | ~2ms | | 3 | LUMM loopback :9702 | <0.5ms | | 4 | LUMM Tailscale -> iOS | ~10ms | | 5 | iOS MocopiExtractor | ~1ms | | 6 | iOS SAN + ParamMapper | ~3ms | | 7 | Params Tailscale -> Mac5 | ~10ms | | 8 | Strudel.js render | ~8ms | | **Audio total** | **Skeleton -> sound** | **~50ms** |\n\n- **Fastest possible visual response.** ~13ms sensor-to-pixel is essentially the camera's own latency. The processing pipeline adds <8ms. - **Fastest possible audio response.** ~50ms skeleton-to-sound is within the perceptible synchrony window (human perceives audio-visual sync within ~80ms). - **No infrastructure dependencies.** No NATS, no message brokers, no health check services. Just UDP sockets. - **Battle-tested.** This is essentially how the system works today (minus LUMM to iOS). The existing code IS this architecture.\n\n- **Rigid topology.** Adding a new consumer means editing publisher code to add a destination. No dynamic discovery. - **No monitoring.** If packets drop, nobody knows. If a publisher crashes, silence is the only signal. - **Hardcoded IPs.** Tailscale IPs are stable but still configuration. If Mac5 changes IP (Tailscale reinstall), manual update. - **Fire-and-forget UDP.** No delivery guarantees. In practice, local loopback is reliable, but Tailscale hops can have 100% loss (documented: Mac5 unreachable during some sessions). - **No coordination layer.** No session start/stop, no state synchronization, no beat clock across machines. Each machine runs independently. - **Music-to-visual sync gap.** K11 visuals react to local sensors. Mac5 audio reacts to iOS-processed sensors. These two reaction paths have different latencies and no shared clock. A transient beat hit on the audio may not visually sync with the depth-triggered impulse.\n\nADOPT as the data plane. Direct UDP is correct for all real-time sensor data. The latency budget is the ground truth that every other architecture must beat or matc", "htmlHref": "/research/html/path-f-live-performance-optimized-minimize-latency-at-all-costs-1aj4ojj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 782 }, { "id": "stage-0-research-voice-first-agent-architecture-1l33zmv", "title": "Stage 0: Research — Voice-First Agent Architecture", "slug": "stage-0-research-voice-first-agent-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/voice-first-agent-architecture/stage0-research.md", "extension": "md", "score": 32, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The mesh currently has 8 distinct voice subsystems spread across iOS apps, macOS services, and backend flows. They are architecturally isolated — no subsystem talks to another. The terminal agents (Claude panes, Prefect flows, Discord bots) communicate exclusively through text. Voice exists at the edge (phone, glasses) but doesn't penetrate the mesh core.", "excerpt": "The mesh currently has 8 distinct voice subsystems spread across iOS apps, macOS services, and backend flows. They are architecturally isolated — no subsystem talks to another. The terminal agents (Claude panes, Prefect flows, Discord bots) communicate exclusively through text. Voice exists at the edge (phone, glasses) but doesn't penetrate the mesh core.\n\n| # | System | Location | Voice Capability | State | |---|--------|----------|-----------------|-------| | 1 | OpenClawHub DirectVoice | iOS app | Full STT→intent→Clawdbot→TTS loop | WORKING | | 2 | OpenClawHub Fleet Voice | iOS (Glasses Gateway) | Fleet control: status, resume, inject, kill, spawn | WORKING | | 3 | OpenClawHub QuadView | iOS | Push-to-talk → pane delegation | UI complete | | 4 | SpeakFlow | macOS + iOS keyboard | Global hotkey→STT→text injection + \"hey claw\" trigger | WORKING | | 5 | SecuriClaw WakeWord | iOS | Continuous wake phrase detection | WORKING | | 6 | Spore VoiceCapture | iOS | Voice→idea creation with keyword extraction | WORKING | | 7 | Voice Task Daemon | Mac1 LaunchAgent | Supabase mac_tasks → TTY pane injection | ACTIVE | | 8 | Transcription Intel | Prefect flow | Video transcripts → intelligence extraction | ACTIVE |\n\n| Model/API | Where | Purpose | |-----------|-------|---------| | Apple SFSpeechRecognizer (on-device) | All iOS/macOS apps | STT | | ElevenLabs eleven_turbo_v2_5 | OpenClawHub (primary TTS) | High-quality agent speech | | AVSpeechSynthesizer | SpeakFlow, OpenClawHub fallback | System TTS | | Gemini 2.0 Flash Live (WebSocket) | OpenClawHub GeminiObserver | Ambient audio+video intelligence | | OpenAI TTS (6 voices) | Speak CLI reader | File reading | | macOS `say` + Edge TTS | LearnNKo | Language learning pronunciation | | CoreML MohamedSpeakerID | OpenClawHub | Owner voice identification | | Custom MFCC (vDSP FFT) | OpenClawHub | Speaker voiceprint matching |\n\n**VoiceRouter (iOS)**: 35 intents mapping spoken keywords to ThreadCategory. Covers all projects (Koji, Milkmen, Spore, Serenity, CreativeDirector, CompCore, CogTwin, NKo, etc.). Also handles explicit channel routing.\n\n**FleetVoiceRouter (iOS)**: Fleet-specific intents: `status`, `resume(target)`, `resumeAll`, `inject(target, command)`, `converge`, `diverge(prompt)`, `focus(target)`, `spawn(prompt)`, `kill(target)`, `fleetHealth`, `checkAbsorbing`, `unstickPane`, `checkFocus`, `checkTrajectory`. Has pronoun resolution (`lastTarget`) and destructive command confirmation (1.5s cancel window).", "htmlHref": "/research/html/stage-0-research-voice-first-agent-architecture-1l33zmv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 817 }, { "id": "omi-desktop-app-flows-exploration-1famszr", "title": "Omi Desktop App — Flows & Exploration", "slug": "omi-desktop-app-flows-exploration", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Frameworks/omi/desktop/e2e/SKILL.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This skill teaches you the Omi desktop macOS app's navigation structure, screen architecture, and SwiftUI patterns. Use it when developing features (to understand how the app works), fixing bugs (to navigate to the affected screen), or verifying changes (to confirm your code works in the live app).", "excerpt": "--- name: desktop-app-flows description: \"Understand and explore the Omi desktop macOS app's UI flows, navigation patterns, and SwiftUI architecture. Use when developing features, fixing bugs, or verifying changes in desktop/ Swift files. Provides agent-swift commands to explore the live app, understand how screens connect, and verify your work.\" allowed-tools: Bash, Read, Glob, Grep ---\n\nThis skill teaches you the Omi desktop macOS app's navigation structure, screen architecture, and SwiftUI patterns. Use it when developing features (to understand how the app works), fixing bugs (to navigate to the affected screen), or verifying changes (to confirm your code works in the live app).\n\nYou can interact with the running app via `agent-swift` — a CLI that clicks elements, reads the accessibility tree, and captures screenshots through the macOS Accessibility API. Works with any macOS app, no app-side instrumentation needed.\n\n| Command | Purpose | Example | |---------|---------|---------| | `snapshot -i --json` | See all interactive elements with refs, types, labels | `agent-swift snapshot -i --json` | | `click @ref` | CGEvent click — SwiftUI elements (NavigationLink, gestures) | `agent-swift click @e3` | | `press @ref` | AXPress — AppKit buttons, Settings sidebar items | `agent-swift press @e5` | | `find role/text/key VALUE` | Find element and chain action | `agent-swift find text \"Settings\" click` | | `fill @ref \"text\"` | Type into text field | `agent-swift fill @e7 \"search\"` | | `scroll down/up` | Scroll current view | `agent-swift scroll down` | | `wait text \"X\"` | Wait for element to appear | `agent-swift wait text \"Loading\" --timeout 5000` | | `is exists @ref` | Assert element exists (exit 0/1) | `agent-swift is exists @e3` | | `get PROP @ref` | Read property value | `agent-swift get value @e5 --json` | | `screenshot PATH` | Capture app window | `agent-swift screenshot /tmp/screen.png` |\n\n**Key rules:** - `click` = CGEvent mouse click (SwiftUI). Use for main sidebar icons, NavigationLink. - `press` = AXPress action (AppKit). Use for Settings sidebar sections. - Refs go stale after any mutation — always re-snapshot before the next interaction. - `find` with chained action is more stable than hardcoded `@ref` numbers. - `--json` flag on any command gives structured output for parsing.", "htmlHref": "/research/html/omi-desktop-app-flows-exploration-1famszr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1183 }, { "id": "dance-debugger-1pqm2iq", "title": "Dance Debugger 💃🐛", "slug": "dance-debugger", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/dance-debugger/SKILL.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Every bug tells a story through movement: - **Null pointer** → The Vanishing Partner (reaching for someone who isn't there) - **Infinite loop** → The Endless Waltz (spinning forever, never advancing) - **Race condition** → The Collision Tango (two dancers fighting for the same spot) - **Memory leak** → The Growing Ensemble (dancers keep joining, none leave) - **Stack overflow** → The Tower of Lifts (stacking lifts until collapse)", "excerpt": "> *Generation 13 — The Improv: Live exploratory debugging through code mutation*\n\nEvery bug tells a story through movement: - **Null pointer** → The Vanishing Partner (reaching for someone who isn't there) - **Infinite loop** → The Endless Waltz (spinning forever, never advancing) - **Race condition** → The Collision Tango (two dancers fighting for the same spot) - **Memory leak** → The Growing Ensemble (dancers keep joining, none leave) - **Stack overflow** → The Tower of Lifts (stacking lifts until collapse)\n\n| Move | Code Concept | |------|--------------| | 🚶 Walk | Sequential execution | | 💃 Spin | Loop iteration | | 🤝 Partner | Function call | | ⬆️ Lift | Push to stack | | ⬇️ Land | Pop from stack | | 👋 Wave | Return value | | 🚪 Exit | Return/break | | 💥 Fall | Exception/crash | | 🔄 Mirror | Recursion | | 👥 Ensemble | Array/collection |\n\nThe `visualizer.html` opens an interactive stage where: - Code blocks are dancers - Execution flow is choreographed movement - Errors show as dramatic falls - Fixes animate the corrected dance\n\nDebugging is often about **flow** and **timing**: - Where does execution go? - When do things happen? - Who interacts with whom?", "htmlHref": "/research/html/dance-debugger-1pqm2iq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4236 }, { "id": "enriched-spawn-context-aware-sub-agent-orchestration-1kl1s8r", "title": "Enriched Spawn — Context-Aware Sub-Agent Orchestration", "slug": "enriched-spawn-context-aware-sub-agent-orchestration", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/enriched-spawn/SKILL.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "When using `sessions_spawn`, sub-agents receive only the raw task text. They don't get: - AGENTS.md (behavioral guidelines) - SOUL.md (personality/values) - MEMORY.md (historical context) - Skills (specialized knowledge) - Governance (checklists, standards) - Tool guidance (how to use tools properly)", "excerpt": "--- name: enriched-spawn description: Spawn sub-agents with full context inheritance - skills, governance, memory, and quality gates user-invocable: true command-dispatch: spawn metadata.clawdbot: {\"governance\": true, \"quality_gates\": true, \"version\": \"1.0.0\"} ---\n\nWhen using `sessions_spawn`, sub-agents receive only the raw task text. They don't get: - AGENTS.md (behavioral guidelines) - SOUL.md (personality/values) - MEMORY.md (historical context) - Skills (specialized knowledge) - Governance (checklists, standards) - Tool guidance (how to use tools properly)\n\n1. **Core Context** — AGENTS.md, SOUL.md excerpts 2. **Relevant Skills** — Auto-detected from task keywords 3. **Governance Preamble** — Project charter, checklist, standards 4. **Memory Context** — Recent relevant decisions/work 5. **Quality Gates** — Validation requirements before completion 6. **Completion Protocol** — Structured output format\n\n**Quality Gates:** - [x] Build passes - [x] Patterns followed - [x] Governance updated\n\n| Task Keywords | Skills Auto-Added | |---------------|-------------------| | expo, react native, mobile | expo-mobile, expo-preview | | swift, ios, xcode | gam:mfp (if game), governance-framework | | pulse, autonomous | bot:pulse, pulse-v2 | | dream, incubate | bot:dream-weaver | | voice, speak, audio | Speak skill, voice-transcription | | api, backend, server | coding-agent | | creative, design | art:creative, frontend-design |", "htmlHref": "/research/html/enriched-spawn-context-aware-sub-agent-orchestration-1kl1s8r.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 958 }, { "id": "governance-framework-1jlttve", "title": "Governance Framework", "slug": "governance-framework", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/governance-framework/SKILL.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Anticipation Over Prediction** — Don't predict outcomes; detect when futures become constrained enough that action is warranted.", "excerpt": "--- name: governance-framework description: Documentation-driven project governance using the Master Implementation Prompt. Use when starting a new project, initializing governance scaffolding, or resuming work on governed projects. Triggers on project setup, phase zero, governance init, master plan, or implementation checklist requests. ---\n\n**Anticipation Over Prediction** — Don't predict outcomes; detect when futures become constrained enough that action is warranted.\n\n| Signals | Action | |---------|--------| | 1 signal | Observation only | | 2 signals | Provisional commitment | | 3+ signals | Actionable commitment | | Disagreeing signals | Pause, investigate |\n\n| Type | Scope | Signals Required | |------|-------|------------------| | **Micro** | Naming, formatting | 1 | | **Meso** | Module design, API | 2 | | **Macro** | Architecture, schema | 3+ |\n\nOr manually create `.governance/` with: 1. `PROJECT_CHARTER.md` — Purpose, non-goals, success criteria 2. `GLOSSARY.md` — Unambiguous term definitions 3. `INVARIANTS.md` — Assumptions + inviolable rules 4. `IMPLEMENTATION_GUIDE.md` — Decision rules, file structure 5. `CHECKLIST.md` — Living task tracker", "htmlHref": "/research/html/governance-framework-1jlttve.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 350 }, { "id": "voice-memory-palace-1ip9dvf", "title": "Voice Memory Palace 🏰", "slug": "voice-memory-palace", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/memory-palace/SKILL.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Navigate your memories spatially using voice commands. Organize memories into **rooms**, traverse **hallways** of time, and discover forgotten treasures through intuitive spatial metaphors.", "excerpt": "--- name: memory-palace description: Navigate your memories spatially through voice commands homepage: https://github.com/diomandeee/clawdbot user-invocable: true command-dispatch: palace handler: handler.MemoryPalaceHandler metadata.clawdbot: {\"requires_memory\": true, \"voice_enabled\": true, \"version\": \"3.0.0\"} ---\n\n**Gen 8 Evolution:** Now with Memory Streaming, Dream Bridge, and Ambient Awareness!\n\nPrevious evolutions: - Gen 7: Memory Resonance, Guided Journeys, Palace Visualization\n\nNavigate your memories spatially using voice commands. Organize memories into **rooms**, traverse **hallways** of time, and discover forgotten treasures through intuitive spatial metaphors.\n\n| Element | Metaphor | Meaning | |---------|----------|---------| | **Palace** | 🏰 | Your entire memory system | | **Lobby** | 🛋️ | Recent memories (entry point) | | **Rooms** | 🚪 | Categories: work, projects, personal, dreams | | **Hallways** | 🚶 | Time navigation: last week, yesterday, this month | | **Items** | 💎 | Individual memories/entries | | **Echoes** | 🔊 | Search results that resonate with your query |", "htmlHref": "/research/html/voice-memory-palace-1ip9dvf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2218 }, { "id": "prompt-synthesizer-v3-bidirectional-context-expansion-dream-integration-1xd6wtq", "title": "Prompt Synthesizer v3 — Bidirectional Context Expansion + Dream Integration", "slug": "prompt-synthesizer-v3-bidirectional-context-expansion-dream-integration", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/prompt-synthesizer/SKILL.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Not just for raw speech. For ANY input — even \"continue\" becomes full state restoration + next step derivation. > Now with dream seed extraction, skill chaining, and project routing.", "excerpt": "--- name: prompt-synthesizer description: Bidirectional context expansion — transforms ANY input (even \"continue\") into fully enriched prompts with retrospective + prospective context, dream extraction, and skill chain detection homepage: https://github.com/clawdbot/prompt-synthesizer user-invocable: false pre-hook: true hook-priority: 100 metadata.clawdbot: {\"pre_hook\": true, \"transforms_input\": true, \"bidirectional\": true, \"version\": \"3.0.0\", \"dream_integration\": true, \"chain_detection\": true} ---\n\n> Not just for raw speech. For ANY input — even \"continue\" becomes full state restoration + next step derivation. > Now with dream seed extraction, skill chaining, and project routing.\n\n\"Continue\" should never be ambiguous. It means: - **RETROSPECTIVE:** What was just done, decisions made, patterns established - **PROSPECTIVE:** What's next, quality gates, expected deliverables - **NO OMISSIONS:** No stub code, no TODOs, complete implementation\n\n### Continuation Mode Triggered by: `continue`, `next`, `proceed`, `go`, `next phase`, `keep going`\n\n### Standard Mode Any other input — enriched with relevant context + dream extraction", "htmlHref": "/research/html/prompt-synthesizer-v3-bidirectional-context-expansion-dream-integration-1xd6wtq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2178 }, { "id": "pulse-v2-governance-aware-autonomous-development-kqeiw5", "title": "Pulse v2 — Governance-Aware Autonomous Development", "slug": "pulse-v2-governance-aware-autonomous-development", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/pulse-v2/SKILL.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Pulse v2 enhances autonomous development sessions with: - **Governance Integration** — Reads and updates project checklists - **Skill Loading** — References relevant SKILL.md files - **Context Injection** — Pulls memories from Orbit/MCP - **Conventional Commits** — Standardized commit messages - **Pattern Compliance** — Matches existing code style", "excerpt": "--- name: pulse-v2 description: Governance-aware autonomous development sessions with skill integration, checklist tracking, and conventional commits homepage: https://github.com/clawdbot/clawdbot user-invocable: true command-dispatch: pulsev2 metadata.clawdbot: {\"governance\": true, \"mcp_aware\": true} ---\n\nPulse v2 enhances autonomous development sessions with: - **Governance Integration** — Reads and updates project checklists - **Skill Loading** — References relevant SKILL.md files - **Context Injection** — Pulls memories from Orbit/MCP - **Conventional Commits** — Standardized commit messages - **Pattern Compliance** — Matches existing code style\n\nThis automatically: 1. Reads `.governance/` files 2. Loads relevant skills 3. Runs the task 4. Updates checklist on completion 5. Commits with conventional format\n\n| Task Type | Skills to Load | |-----------|----------------| | iOS/Swift game | `gam:mfp`, `governance-framework` | | Expo/React Native | `expo-mobile`, `expo-preview` | | AI features | `nano-banana-pro`, `gemini` | | Testing | `coding-agent` | | Video/Media | `vid:remotion`, `video-frames` | | Creative | `tie`, `art:creative`, `spf` |\n\n| Aspect | v1 | v2 | |--------|----|----| | Governance | ❌ Ignored | ✅ Read & updated | | Skills | ❌ Not loaded | ✅ Referenced | | Memory | ❌ Isolated | ✅ Context injected | | Commits | Generic | Conventional format | | Documentation | Optional | Required | | Tracking | Manual | Auto-updated | | Code style | Random | Pattern-matched |", "htmlHref": "/research/html/pulse-v2-governance-aware-autonomous-development-kqeiw5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 897 }, { "id": "nko-notation-memory-and-future-routing-1c6wqv7", "title": "NKo — Notation, Memory, and Future Routing", "slug": "nko-notation-memory-and-future-routing", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "LUME-CC/07-nko/overview.md", "extension": "md", "score": 32, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "NKo is the durable naming and inscription layer for movement phrases. This is the immediate role, and it should be built before anything else.", "excerpt": "NKo's role in the LUME stack has two layers. The first is what to build now. The second is what to build after.\n\nNKo is the durable naming and inscription layer for movement phrases. This is the immediate role, and it should be built before anything else.\n\nEvery proven movement phrase should have: - A technical name (`left_hand_raise_play`, `wave`, `weighted_hold`) - A body description (landmarks, zone, timing, intent) - An evidence record (session hash, clip count, gate result) - A claim status (defined / observed / confirmed / promoted) - Optional: a NKo name assigned after the phrase is stable\n\nThis is the movement alphabet. The archive of body inscriptions is how the system stops treating movement as ephemeral sensor data and starts treating it as a vocabulary with history.\n\nThe NKo writing system (Solomana Kanté, 1949) fits this role because it was invented precisely to give Mande languages a durable computational structure: a notation system, a memory layer, and a cultural claim about who the language belongs to. Body movement — especially Mo's specific movement vocabulary — deserves the same treatment.", "htmlHref": "/research/html/nko-notation-memory-and-future-routing-1c6wqv7.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 480 }, { "id": "motion-mix-live-director-mac4-camera-7-8-9-handoff-qb1n3n", "title": "Motion Mix Live Director Mac4 Camera 7/8/9 Handoff", "slug": "motion-mix-live-director-mac4-camera-7-8-9-handoff", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/handoffs/MOTION_MIX_LIVE_DIRECTOR_MAC4_CAMERA_7_8_9_HANDOFF.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This handoff is for the agent integrating the three new Mac4 camera lanes into Motion Mix Live Director and the Motion Mix Wall. No Live Director application code was changed in this pass.", "excerpt": "This handoff is for the agent integrating the three new Mac4 camera lanes into Motion Mix Live Director and the Motion Mix Wall. No Live Director application code was changed in this pass.\n\n| Camera | Device | ID | Host | Port | Token | Status | | --- | --- | --- | --- | --- | --- | --- | | 7 | Insta360 X4 | `mac4-camera7-insta360` | `[ip]` | `8087` | `mac4camera7` | registered lane service alive; selects `Insta360 X4` | | 8 | Orbbec Femto Mega RGB Camera | `mac4-camera8-femto-mega` | `[ip]` | `8088` | `mac4camera8` | registered lane service alive; selects `Orbbec Femto Mega RGB Camera` | | 9 | Orbbec Femto Bolt RGB Camera | `mac4-camera9-femto-bolt` | `[ip]` | `8089` | `mac4camera9` | registered lane service alive; selects `Orbbec Femto Bolt RGB Camera` |\n\nEach lane probes AVFoundation with ffmpeg, selects the camera by name/regex, and refuses unwanted devices through exclude patterns. This is important because AVFoundation indices changed while testing; the integration should not depend on index `0`, `1`, or `2`.\n\nThe `/status` endpoints are confirmed good and currently identify all three physical cameras correctly.\n\nFrame capture still needs one final operator-side fix before treating the feeds as video-ready in production. During this pass, ffmpeg could enumerate the cameras and report supported formats, but `/snapshot` and `/mjpeg` timed out while trying to pull frames. The likely causes are:", "htmlHref": "/research/html/motion-mix-live-director-mac4-camera-7-8-9-handoff-qb1n3n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1648 }, { "id": "lume-current-print-approval-queue-196s825", "title": "LUME Current Print Approval Queue", "slug": "lume-current-print-approval-queue", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/PRINT_APPROVAL_QUEUE_CURRENT.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Status update, 2026-05-20: the large printed outer shell and pod path is paused while the wood enclosure prototype is evaluated. Use `wood/LUME_WOOD_ENCLOSURE_SPEC.md` for the current wood-body direction and `print/WOOD_V2_PRINT_QUEUE.md` for the active 3D-print queue.", "excerpt": "Status update, 2026-05-20: the large printed outer shell and pod path is paused while the wood enclosure prototype is evaluated. Use `wood/LUME_WOOD_ENCLOSURE_SPEC.md` for the current wood-body direction and `print/WOOD_V2_PRINT_QUEUE.md` for the active 3D-print queue.\n\n- `print/3mf-current/wood-v2/01_wood_v2_small_fit.3mf` - `print/3mf-current/wood-v2/02_wood_v2_sensor_stack.3mf` - `print/3mf-current/wood-v2/03_wood_v2_k11_sled.3mf`\n\nDo not print the old shell/pod plates for the wood enclosure build unless we explicitly return to the full ASA shell.\n\nThis is the current print queue for the K11 + top monitor + Femto Mega + Arducam build. The older 3MF queue files were generated before the K11 pod, top display cradle, and Arducam changes, so treat those prearranged plates as stale until rebuilt from the STL folders below.\n\n- Single-right Arducam: `print/3mf-current/approval-v2/` - Symmetric dual Arducam: `print/3mf-current/approval-symmetric/`", "htmlHref": "/research/html/lume-current-print-approval-queue-196s825.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1558 }, { "id": "lume-v2-twin-sensor-checklist-q488or", "title": "LUME v2 twin-sensor checklist", "slug": "lume-v2-twin-sensor-checklist", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/design/v2-twin-sensor/CHECKLIST.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "_Comprehensive task list spanning hardware, CAD, software, calibration, testing, packaging, manuals, and ship-blocking dependencies. Ordered by unblock chain. Each item has owner, ETA, and verification criterion._", "excerpt": "_Comprehensive task list spanning hardware, CAD, software, calibration, testing, packaging, manuals, and ship-blocking dependencies. Ordered by unblock chain. Each item has owner, ETA, and verification criterion._\n\n- [ ] **Receive Bolt** (Apr 27, Prime) — Mohamed acknowledges arrival, opens box, verifies serial number, photographs port layout for cradle CAD reference. - [ ] **Receive K11** (next-day if ordered now) — Mohamed unboxes, plugs in, verifies BIOS boot, confirms Linux installable. ETA per K11 BOM memo. - [ ] **Capture Bolt STEP file** from `github.com/orbbec/OrbbecHardware`. Drop into `hardware/cad/references/orbbec-femto-bolt.stp`. Convert to STL via FreeCAD (FreeCAD → open .stp → export STL). Drop into `hardware/cad/references/orbbec-femto-bolt.stl`. Add `USE_REAL_BOLT=true` toggle in lume-config-bolt.scad. - [ ] **Caliper-measure Bolt** — verify the 140×39×30mm we're using. Reconcile with STEP. Update DIMENSIONAL-AUDIT.md confidence to ⭐. - [ ] **Caliper-measure K11** — verify 142.6×113×49.5mm. Reconcile. - [ ] **Caliper-measure Mega's Jetson hump** — verify the +25mm protrusion claim. - [ ] **Reconcile Mega axis labels** — physically measure Mac4's Mega and update FEMTO_W/D/H constants if they're swapped.\n\n- [ ] **Run femto_intrinsics.py against Bolt** to capture intrinsics JSON. Save as `software/demo/femto_intrinsics_bolt.json`. Compare against Mega's intrinsics — should be similar since same sensor silicon. - [ ] **Test Bolt with existing pointcloud_pub.py** — invoke `python3 pointcloud_pub.py --raw-depth --intrinsics-json femto_intrinsics_bolt.json --host [ip] --port 9700` and verify LUMD packets flow at expected 6720/sec rate. - [ ] **Test Bolt over USB-C to K11** (when K11 arrives) — same publisher command from K11 side instead of Mac4. Verify USB4 port is fast enough for 1024² depth at 30fps. - [ ] **Verify Bolt depth quality matches Mega** — capture same scene with both, compare depth maps via `lume_packet_inspector.py --hex` for byte comparison. Should be functionally identical given same Sony IMX556.\n\n- [ ] **Add lume-config-bolt.scad** with overrides: LUME_DEPTH=60, FEMTO_W=140, FEMTO_D=39, FEMTO_H=30, FEMTO_MOUNT_PITCH_X=TBD, FEMTO_MOUNT_PITCH_Z=TBD. Inherit everything else from lume-config.scad via include. - [ ] **Refactor lume-shell.scad** to parameterize against current config rather than implicitly using the global lume-config.scad. Add config-include hook so lume-shell-bolt.scad can drive it. - [ ] **Generate lume-shell-bolt.scad** entrypoint that includes both configs and renders the Bolt-config bar. - [ ] **Rebuild Bolt cradle module** in lume-shell.scad to handle the new camera dimensions. Bolt has different mount pattern; needs new bolt hole positions in the cradle plate. - [ ] **Re-export 4 Bolt shell halves** — s", "htmlHref": "/research/html/lume-v2-twin-sensor-checklist-q488or.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1354 }, { "id": "e579-duncan-fewkes-reel-analysis-digest-gip43d", "title": "E579 — Duncan Fewkes reel analysis digest", "slug": "e579-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E579-DWd8U8Sig9F.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- Cached MP4s: `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Caption JSON: same dir, `*.info.json` - Gemini visual analyses: `[home-path]` - Prior playbook (E579-E606): `lume-duncan-playbook.md` - Master URL list: `/tmp/duncan_reels.txt`", "excerpt": "Source video: `../reels/E579-DWd8U8Sig9F.mp4` (symlink to `[home-path]`) Caption: `../reels/E579-DWd8U8Sig9F.txt`\n\nThis file aggregates every playbook chunk section that cites E579. Sections are de-duplicated by heading.\n\n- Cached MP4s: `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Caption JSON: same dir, `*.info.json` - Gemini visual analyses: `[home-path]` - Prior playbook (E579-E606): `lume-duncan-playbook.md` - Master URL list: `/tmp/duncan_reels.txt`\n\n- `lume-duncan-playbook.md` — primary, 12 most-recent reels (E579-E606) - `lume-v1-duncan-fewkes-stack.md` — initial inspiration cataloging - `lume-v1-evo3-masterplan.md` — 5-wave plan that the additions above plug into - `lume-v1-forge-architecture.md` — `LumeAudioReactor.cs` + shader patch (where transient channel lands in Wave 1) - `lume-v1-rail-plan.md` — EW-governed track plan (Wave 2-5 additions above are new tracks)\n\nMid-period work is dominated by **Audio Particle Clones** (E483→E491) — beat-snapshot human silhouette as particle clouds layered with live depth visuals. This is the direct ancestor of the recent \"Sunset Clone Plane\" (E605) and \"Motion Sparks 4\" (E579) work. Three things are clearer here than in the recent reels:", "htmlHref": "/research/html/e579-duncan-fewkes-reel-analysis-digest-gip43d.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2336 }, { "id": "lume-aylln2", "title": "LUME", "slug": "lume", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/README.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Embodied-light visual engine. Multi-machine pipeline that drives a 1920×440 bar display from real-time sensor input — depth, audio, motion — with a music-generation feedback loop.", "excerpt": "Embodied-light visual engine. Multi-machine pipeline that drives a 1920×440 bar display from real-time sensor input — depth, audio, motion — with a music-generation feedback loop.\n\n| Magic | Port | Source | Sink | Spec | |----------|------|---------------------------------|------------------|------------------------------------------| | `LUME` | 9700 | depth-pub (cloud mode) | viz/lume-pcloud | docs/protocols/wire_format_v1.md | | `LUMD` | 9700 | depth-pub (raw-depth) | viz/lume-pcloud | docs/protocols/wire_format_v1.md | | `LUMF` | 9701 | audio-pub | viz/lume-pcloud | docs/protocols/wire_format_v1.md | | `LUMM` | 9702 | mocopi-{bridge,synth,sony-bridge}| viz/lume-pcloud | docs/protocols/wire_format_v1.md | | OSC `/lume/...` | 9050 | viz/lume-pcloud → audio engine | external | (motion-driven music conditioning) |\n\nGolden-bytes regression coverage in `tests/services/test_wire_format_golden.py`.\n\n| Host | Role | Stack | |-------|---------------------------|---------------------------------------| | Mac1 | dev / canonical / git | full repo + Codex + Claude Code | | Mac4 | Unity host | viz/lume-pcloud Editor + Play mode | | Mac5 | ML / fine-tune (rate-limited) | LaunchAgent audio-pub + ML training | | K11 | production box (Windows) | NSSM services for audio/mocopi/depth | | Jetson Orin | (deferred) | ARM64 product target |\n\nPreserved across all restructure work: - Wire format magics: `LUME` / `LUMD` / `LUMF` / `LUMM` / `LUMC` (additive only). - Unity component public APIs (additive only). - K11 NSSM service definitions (already production at C:\\lume\\). - Wave 8 / Wave 9 visual ladder commits (8fb6fe75…83b565e3 in old SHAs; rewritten under post-extraction history). - `LumeMocopiReceiver.cs` (Mac1 thread-safe version is canonical).", "htmlHref": "/research/html/lume-aylln2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 660 }, { "id": "session-state-1io9kz8", "title": "Session State", "slug": "session-state", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/SESSION_STATE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Progress: - K11 is the active compute path; Jetson-era internals are legacy. - ZHAOCAILIN 11.3 inch display is modeled as a top cradle with a cable pass-through, not a structural top cutout. - Arducam IMX586 USB camera is modeled in the right-front bay with a new printable mount. - Approval renders are in `hardware/cad/renders/approval/`. - Validation STLs are in `hardware/cad/exports/approval-v2/`. - Symmetric two-Arducam variant is available with `ARDUCAM_LAYOUT=\"dual\"`, mockups in `hardware/cad/renders/approval/", "excerpt": "Progress: - K11 is the active compute path; Jetson-era internals are legacy. - ZHAOCAILIN 11.3 inch display is modeled as a top cradle with a cable pass-through, not a structural top cutout. - Arducam IMX586 USB camera is modeled in the right-front bay with a new printable mount. - Approval renders are in `hardware/cad/renders/approval/`. - Validation STLs are in `hardware/cad/exports/approval-v2/`. - Symmetric two-Arducam variant is available with `ARDUCAM_LAYOUT=\"dual\"`, mockups in `hardware/cad/renders/approval/approval_symmetric_*`, and STLs in `hardware/cad/exports/approval-symmetric/`. - Femto Mega datasheet fit audit completed in `hardware/cad/FEMTO_MEGA_FIT_AUDIT.md`; rear feedthrough is now 87 x 38mm and Femto mount is a bottom/side cradle. - Current print manifest is `hardware/cad/PRINT_APPROVAL_QUEUE_CURRENT.md`; older queue docs are marked stale and existing prearranged 3MFs should be rebuilt before final printing. - Legacy/stale labels were added to old Jetson/SVPro-era plans and slicing docs so the active truth files are `LUME_CURRENT_BUILD_SPEC.md`, `LUME_SYMMETRIC_CAMERA_VARIANT.md`, `FEMTO_MEGA_FIT_AUDIT.md`, and `PRINT_APPROVAL_QUEUE_CURRENT.md`. - Wiring/service access updated: pod has a 150 x 64mm rear K11 service window, matching VESA plate window, and a 44 x 18mm right-side service slot for USB/Bluetooth/Sony adapter extension access. Plan doc: `hardware/cad/LUME_WIRING_SERVICE_PLAN.md`. - K11 CAD dimensions updated to official GMKtec 132 x 125 x 58mm. OrcaSlicer 3MF approval plates generated at `hardware/cad/print/3mf-current/approval-v2/` and `hardware/cad/print/3mf-current/approval-symmetric/`. Blender approval renders generated at `hardware/cad/renders/blender-approval-single/` and `hardware/cad/renders/blender-approval-symmetric/`. - Long unattended render completed 2026-04-30 around 13:25: 4K/128-sample Blender approvals are in `hardware/cad/renders/blender-approval-single-4k/` and `hardware/cad/renders/blender-approval-symmetric-4k/`. Combined visual sheet: `hardware/cad/renders/blender-approval-4k-contact-sheet.png`. The temporary `caffeinate` guard was stopped after completion. - Symmetric dual-Arducam internals plate was rebuilt after Orca found the old `02_internals_dual_arducam.3mf` had a broken layout with objects off the bed. The old file is now in `hardware/cad/print/3mf-current/approval-symmetric/legacy-broken-layout/02_internals_dual_arducam_DO_NOT_PRINT_broken-layout.3mf`; use `hardware/cad/print/3mf-current/approval-symmetric/02_internals_dual_arducam_ASA_READY.3mf`. - User selected the symmetric dual-Arducam variant as the active approval path. - `02_internals_dual_arducam_ASA_READY.3mf` has ASA settings, 0.20mm layers, 4 walls, 5 top/bottom layers, 25% gyroid infill, support enabled, 3mm brim, and conservati", "htmlHref": "/research/html/session-state-1io9kz8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1087 }, { "id": "lume-rehearsal-capture-overwhelming-update-6exexq", "title": "LUME Rehearsal Capture Overwhelming Update", "slug": "lume-rehearsal-capture-overwhelming-update", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/viz/lume-pcloud/Docs/LUME_REHEARSAL_CAPTURE_OVERWHELMING_UPDATE_2026-05-28.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Date: 2026-05-28 Primary live host: Mac4 Primary storage target: K11 Reference project root on Mac4: `[home]/dev/lume-commerce-live/viz/lume-pcloud` Document destination on Mac1: `[home]/Desktop/lume-commerce/viz/lume-pcloud/Docs/LUME_REHEARSAL_CAPTURE_OVERWHELMING_UPDATE_2026-05-28.md`", "excerpt": "Date: 2026-05-28 Primary live host: Mac4 Primary storage target: K11 Reference project root on Mac4: `[home]/dev/lume-commerce-live/viz/lume-pcloud` Document destination on Mac1: `[home]/Desktop/lume-commerce/viz/lume-pcloud/Docs/LUME_REHEARSAL_CAPTURE_OVERWHELMING_UPDATE_2026-05-28.md`\n\nThe companion document converts this Tier 0 capture lane into the shared K11/Mac4/Mac5 rehearsal-bundle architecture and explains how K11 Pose Coach fits into the same storage/training path.\n\nThe rehearsal-capture stack has crossed from concept into a working Tier 0 capture lane. The critical achievement is not that every sensor is perfect yet. The critical achievement is that LUME now has a boring, survivable, inspectable recording path that can record a long physical rehearsal, preserve labels, survive interruption, write explicit session metadata, and route the completed bundle to K11 with remote checksum verification. This matters because every more advanced choreography layer depends on clean session evidence. The machine can now collect a body session without requiring Unity, MotionMix, mocopi, Web Lab, iPhones, or any DJ command path to be alive.\n\nThe reason `tmux` is explicit in the route is important. Direct Codex-launched ffmpeg could list the physical cameras but got zero frames from them. The same ffmpeg capture launched inside `tmux` successfully captured an Insta360 frame and then full MP4 test sessions. macOS Camera privacy already grants access to `Terminal` and `tmux`, so the production route intentionally uses `tmux` as the camera-permission context. This is not a hack around recording quality. It is an operating-system permission boundary being made explicit and stable.\n\nK11 is now a storage target, not a live dependency. The current stack does not live-write the only copy directly over the network, because that would make the rehearsal vulnerable to Wi-Fi, Tailscale, SSH, sleep, and transient Windows file-system stalls. The chosen route records locally first, then immediately verifies K11 upload after the take. This is the correct reliability posture for a weighted freestyle session: capture first, transport second, analyze third.", "htmlHref": "/research/html/lume-rehearsal-capture-overwhelming-update-6exexq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3740 }, { "id": "stillness-catalog-content-system-derived-from-nouses-kou-2xh1wd", "title": "Stillness Catalog — Content System Derived from @nouses_kou", "slug": "stillness-catalog-content-system-derived-from-nouses-kou", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-content/nouses-kou-derived-content-plan.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Where @nouses_kou inscribes the void in Noh-Japan-AR, you inscribe N'Ko-Mande-Sensing. Same architecture, different ancestry.", "excerpt": "Where @nouses_kou inscribes the void in Noh-Japan-AR, you inscribe N'Ko-Mande-Sensing. Same architecture, different ancestry.\n\nEight invariants. Every post in this system obeys all eight. The discipline IS the brand.\n\n| # | Invariant | Why it works | Your translation | |---|-----------|--------------|------------------| | 1 | **Fixed-frame, single-take, 17-30s** | No cuts means the viewer cannot escape. Attention IS the medium. | The locked frame mirrors the act of sensing. LUME is a stillness product. | | 2 | **No face, no voice** | The author disappears. Subject becomes object. | You don't have to be the protagonist. The hand, the leaf, the room, the N'Ko glyph is. | | 3 | **One sustained drone, never trending audio** | Sound is felt, not selected for the algorithm. | You can generate drones FROM the brain. The body's 128D vector synthesizes its own score. | | 4 | **Overlay markers — tracker IDs, point clouds, pseudo-code** | The implementation IS the visual. | Your 33 BlazePose joints, your 128D slots, your phase counter ARE the aesthetic. Show them. | | 5 | **Caption: glyph string → classical quote → English gloss → sign-off** | Text is a poem with ritual closing. | N'Ko glyphs → Maninka/Bambara proverb → English gloss → `ߥߟߊ` (Walaha) | | 6 | **Three hashtags, locked, never rotated** | Hashtags are a flag, not bait. | Pick three. Never deviate. | | 7 | **The catalog is the brand** | One viral post does nothing. 20 posts in lockstep grammar build a gravity well. | Ship the series; don't chase the single hit. | | 8 | **No CTA** | Asking for the click cheapens the artifact. | The work stands. People come because the room is built. |\n\nEach series obeys all 8 invariants. Each post in a series obeys the same sub-grammar. Variations come from substrate, not structure.\n\n**Frame** - 22 s, 4K vertical (1080×1920), 30 fps, locked - Plain wall background. Texture matters: limewash, raw concrete, brown paper, weathered wood, linen - One light source, one shadow, no fill - Hand enters from frame-right, opens and closes three times, exits frame-right - Distance: arm fills lower-third only. Wall is the protagonist", "htmlHref": "/research/html/stillness-catalog-content-system-derived-from-nouses-kou-2xh1wd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2344 }, { "id": "codex-handoff-claude-design-rendering-for-lume-vc-pitch-1nnyie3", "title": "CODEX HANDOFF — Claude Design Rendering for LUME VC Pitch", "slug": "codex-handoff-claude-design-rendering-for-lume-vc-pitch", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-content/vc-pitch/CODEX-HANDOFF-CLAUDE-DESIGN.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Self-contained brief. You (Codex) take over the Claude Design rendering track. You pick the automation path. This doc gives you the WHAT — the product, the inputs, the outputs, the acceptance criteria. The HOW is yours.", "excerpt": "> Self-contained brief. You (Codex) take over the Claude Design rendering track. You pick the automation path. This doc gives you the WHAT — the product, the inputs, the outputs, the acceptance criteria. The HOW is yours.\n\n**Claude Design** is Anthropic Labs' visual creation feature inside Claude. It turns text descriptions into professionally-designed pitch decks, prototypes, websites, and marketing materials. Launched April 2026.\n\n**Access:** included with Claude Pro / Max / Team / Enterprise subscriptions. Mohamed has Pro+ access. The browser tab is already open in his session.\n\n**What it does:** - Generates full slide decks from text prompts (\"Create 10-slide VC pitch deck for X\") - Applies brand colors, typography, custom design systems automatically when given a brand spec - Inline editing: comment on individual slides to refine - Supports data visualizations, charts, light animations - Iterative refinement in conversation (each follow-up message tweaks the deck)\n\n**Output formats:** - Interactive HTML (best for presentations, includes animations + real-time editing) - PPTX (PowerPoint export) - PDF - Canva export - Standalone .zip folder for deployment", "htmlHref": "/research/html/codex-handoff-claude-design-rendering-for-lume-vc-pitch-1nnyie3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2170 }, { "id": "operations-hub-ios-implementation-spec-1qbwxb8", "title": "Operations Hub — iOS Implementation Spec", "slug": "operations-hub-ios-implementation-spec", "kind": "research note", "program": "Protocol and Compute", "sourceAnchor": "Milk Men/Documentation/Implementation/OPERATIONS-HUB-IOS-SPEC.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The web CRM already has two Operations Hub views consolidating all outreach intelligence for a market into a 7-tab surface. The iOS app has the foundation (InboundCommandView, MarketSweepCommandView, InboundService, FieldRoutes) — all connected to the same Supabase. This spec describes the **reorganization + two new hub views** needed to match the web architecture. This is not a ground-up build.", "excerpt": "# Operations Hub — iOS Implementation Spec **Date:** 2026-05-28 **Status:** Ready to implement — pass to Codex **Relates to:** Web `PDXSEAOperationsHub.tsx`, `MiamiOperationsHub.tsx` **Supabase project:** `wovknbcvxjvayfdflxkn`\n\nThe web CRM already has two Operations Hub views consolidating all outreach intelligence for a market into a 7-tab surface. The iOS app has the foundation (InboundCommandView, MarketSweepCommandView, InboundService, FieldRoutes) — all connected to the same Supabase. This spec describes the **reorganization + two new hub views** needed to match the web architecture. This is not a ground-up build.\n\n**Real lead counts (verified 2026-05-28 via SQL):** - OR+WA (`inbound_leads` where state IN ('OR','Oregon','WA','Washington')): **1,052 leads**, 100% email, ~87% Instagram - FL (`inbound_leads` where state IN ('FL','Florida')): **700 leads**, 100% email, ~67% Instagram - All markets total: **5,270 leads**, 100% email, 79% Instagram - All `status = 'new'`, zero contacted — full pipeline untouched\n\n| Component | File | Status | |---|---|---| | Inbound lead board | `Views/Growth/InboundCommandView.swift` | ✅ Built — flat list, market program selector | | Market sweep command | `Views/Growth/MarketSweepCommandView.swift` | ✅ Built — 7 modes: Sweeps/Markets/Prospects/Outreach/Responses/Sequences/Inbound | | Response inbox | `Views/Growth/ResponseInboxView.swift` | ✅ Built | | Sequence manager | `Views/Growth/SequenceManagerView.swift` | ✅ Built | | Market detail | `Views/Growth/MarketDetailView.swift` | ✅ Built | | Inbound service | `Services/InboundService.swift` | ✅ Built — Supabase bridge for `inbound_leads` | | Field routes + map | `Views/FieldRoutes/` | ✅ Built — cluster map, visit outcomes, day summary | | Visits | `Views/Visits/` | ✅ Built — check-in, revisit list |\n\n**What's missing:** Metro/region-grouped contact queues for OR+WA and FL, and a unified hub entry point per market combining map + Instagram + sequences + templates + showcase in one place.", "htmlHref": "/research/html/operations-hub-ios-implementation-spec-1qbwxb8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3241 }, { "id": "motion-autocomplete-system-capabilities-report-xdgtz0", "title": "Motion Autocomplete - System Capabilities Report", "slug": "motion-autocomplete-system-capabilities-report", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "motion-autocomplete/CAPABILITIES.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Motion Autocomplete is a sophisticated AI system that predicts physical movements and prepares context before actions occur. The system has evolved through 8 generations, with the current implementation featuring:", "excerpt": "Motion Autocomplete is a sophisticated AI system that predicts physical movements and prepares context before actions occur. The system has evolved through 8 generations, with the current implementation featuring:\n\n- ✅ **Kinetic Chain Detection** - Fully implemented via precursor detection - ✅ **Temporal Echo Patterns** - Markov transitions + time-of-day patterns - ✅ **Bio-Sync Features** - Circadian rhythm, HRV, respiratory coupling (newly added) - ✅ **Smart Home Integration** - Zone-based device orchestration - ✅ **Voice Override** - Natural language control\n\nThe kinetic chain system is implemented through the **Precursor Detector** (`src/intent/precursor-detector.ts`), which detects micro-movements that precede major actions.\n\nThe body broadcasts intent before conscious action. The system detects these precursors with **500-2000ms of lead time**:\n\n| Precursor Type | Detection Method | Lead Time | |---------------|------------------|-----------| | `weight-shift` | Accelerometer center-of-gravity | 800-1500ms | | `gaze-redirect` | Eye tracking / head turn | 500-1000ms | | `hand-preparation` | Gyroscope hand positioning | 300-800ms | | `screen-disengage` | Keyboard/mouse activity drop | 1000-2000ms | | `postural-adjustment` | Subtle position changes | 500-1000ms | | `breathing-change` | Heart rate variability | 1500-3000ms | | `grip-release` | Mouse/object release | 300-600ms | | `muscle-tension` | Pre-movement tension buildup | 400-800ms |", "htmlHref": "/research/html/motion-autocomplete-system-capabilities-report-xdgtz0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1641 }, { "id": "insta360-k11-lume-custom-camera-runbook-tyzpja", "title": "Insta360 + K11/LUME Custom Camera Runbook", "slug": "insta360-k11-lume-custom-camera-runbook", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/INSTA360-K11-LUME-RUNBOOK.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This runbook turns the Insta360 from a passive stream into a programmable MotionMix/LUME source. The current production path uses MotionMixApp on iOS to connect to the Insta360 SDK, extract virtual camera crops from the 360 preview, run Vision pose detection, and publish LUME-compatible UDP JSON to K11 on `[ip]:9705`.", "excerpt": "This runbook turns the Insta360 from a passive stream into a programmable MotionMix/LUME source. The current production path uses MotionMixApp on iOS to connect to the Insta360 SDK, extract virtual camera crops from the 360 preview, run Vision pose detection, and publish LUME-compatible UDP JSON to K11 on `[ip]:9705`.\n\nOfficial Insta360 developer docs say the SDK supports secondary development for the X5, X4 Air, X4, X3, ONE RS 1-Inch, ONE RS, ONE X2, ONE R, and ONE X product lines. Supported platforms are Windows, Linux, iOS, and Android. Each platform SDK is split into Camera SDK and Media SDK.\n\n- SDK guide: `https://onlinemanual.insta360.com/developer/en-us/resource/sdk` - iOS SDK: `https://github.com/Insta360Develop/iOS-SDK` - Desktop CameraSDK C++: `https://github.com/Insta360Develop/Desktop-CameraSDK-Cpp` - Desktop MediaSDK C++: `https://github.com/Insta360Develop/Desktop-MediaSDK-Cpp` - OSC control surface: `https://github.com/Insta360Develop/Insta360_OSC`\n\n- iOS SDK path: best current path because MotionMixApp already has the SDK frameworks and the LUME UDP publisher. - Desktop CameraSDK path: strong K11-native future path because the C++ SDK can receive preview video/audio/gyro/exposure data over USB, but it requires a Windows/Linux decoding and stitching service. - MediaSDK path: useful for recorded `.insv` / `.insp` post-processing and preview stitching, not required for today's live pose bridge. - OSC path: useful for lightweight camera status/control experiments, but not the primary live image path.\n\n- `Frameworks/INSCameraSDK.xcframework` - `Frameworks/INSCameraServiceSDK.xcframework` - `Frameworks/INSCoreMedia.xcframework` - `Frameworks/SSZipArchive.xcframework`", "htmlHref": "/research/html/insta360-k11-lume-custom-camera-runbook-tyzpja.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3726 }, { "id": "lumebodytruth-contract-i5zzbk", "title": "LumeBodyTruth Contract", "slug": "lumebodytruth-contract", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/LUME-BODY-TRUTH-CONTRACT.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "`LumeBodyTruth` is the perception authority above the camera/sensor feeds. It answers one question for every consumer: \"what do we trust about the performer right now?\"", "excerpt": "Implementation status: v0 read endpoint is live in `multicam-server` as `GET /body-truth`.\n\n`LumeBodyTruth` is the perception authority above the camera/sensor feeds. It answers one question for every consumer: \"what do we trust about the performer right now?\"\n\nIt is not a custom neural network yet. It is a fused state layer that combines depth, RGB, mocopi, iPhone/SAN, and MotionMix signals into one stable body truth object.\n\n| Machine | Current role | Should own | |---|---|---| | Mac4 | Unity `lume-pcloud`, Femto Mega/Bolt, depth/stereo Arducam, Insta360 view/evidence feed, mocopi bridge | DYK visuals, rich BodyTruth capture, depth/matte, first Sony/mocopi proof | | Mac2 | Insta360 USB/UVC or desktop-bridge camera host when physically connected there | Room-wide reconstruction/evidence angle, calibration capture, session review | | K11 | Rekordbox, pose viewer, AirDeck bridge, optional UVC Arducam/Insta360/simple webcam, self-play, SAN receiver | DJ command safety gate, keyboard/MIDI dispatch, motion recording | | MotionMix hub | Rust multicam server, `/skeleton-3d`, `/mocopi/state` | Canonical shared body bus and `LumeBodyTruth` publisher | | iPhones | MotionMix/SAN/camera evidence | Supplemental sensors, training evidence, extra viewpoints |\n\nMotionMix already emits `fused_body_state` from `multicam-server/src/main.rs`. That state includes useful fields such as:", "htmlHref": "/research/html/lumebodytruth-contract-i5zzbk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2209 }, { "id": "motionmix-unified-director-agent-handoff-1y7kgvk", "title": "MotionMix Unified Director — Agent Handoff", "slug": "motionmix-unified-director-agent-handoff", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "MotionMixApp/UNIFIED-DIRECTOR-HANDOFF.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "// After: adaptive — performer phase OR metronome fallback poseBarCounter += 1 let echelonBarFired = echelonBridge.shouldFireBar() let fixedBarFired = poseBarCounter % 30 == 0 guard (echelonBarFired || fixedBarFired), let hub else { return } ```", "excerpt": "# MotionMix Unified Director — Agent Handoff > Generated 2026-04-04 | Cross-session synthesis of Echelon work + Multicam Unified Director evolution\n\nThe previous session completed 8 layers of foundational Echelon work. Here is what now exists and its exact state:\n\n### Layer 1 — FFI Thread Safety ✅ - All brain-side FFI calls serialized onto `@MainActor` in `EchelonBridge.swift` - Sensor frames queued via `NSLock` into `pendingSensorFrames`, drained in `step()` on MainActor - Audio handle (`MotionSynth`) stays on audio render thread — safe to access concurrently - False comment removed\n\n### Layer 2 — Canonical 104D State Contract ✅ `getDynamics104()` now returns the full vector:\n\n### Layer 3 — Backend Selector ✅ `echelon_create_with_backend(config, backend, weights_path)` now available: - backend=0 → SimpleLatentUpdater (default) - backend=1 → LearnedLatentUpdater - backend=2 → DellLatentUpdater", "htmlHref": "/research/html/motionmix-unified-director-agent-handoff-1y7kgvk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2620 }, { "id": "featural-acoustic-coding-with-nko-program-documentation-1sukb4y", "title": "Featural Acoustic Coding with N'Ko — Program Documentation", "slug": "featural-acoustic-coding-with-nko-program-documentation", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-acoustic-coding/DOCUMENTATION.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document is the dense, self-contained account of a research direction that began as a reaction to a single paper and turned into a structural extension of an existing N'Ko language-technology program. The reaction paper is Lexical Acoustic Coding, abbreviated LAC, which proposes that a short sound can be transmitted between two language-model agents as a readable English sentence and then re-rendered from that sentence, trading exact sample recovery for perceptual similarity. The reaction was that natural Engl", "excerpt": "This document is the dense, self-contained account of a research direction that began as a reaction to a single paper and turned into a structural extension of an existing N'Ko language-technology program. The reaction paper is Lexical Acoustic Coding, abbreviated LAC, which proposes that a short sound can be transmitted between two language-model agents as a readable English sentence and then re-rendered from that sentence, trading exact sample recovery for perceptual similarity. The reaction was that natural English is the weakest part of that design and that a script engineered for sound, specifically N'Ko, would carry the same information more faithfully and far more compactly. That reaction was developed into a method called Featural Acoustic Coding, abbreviated FAC, a written paper that compiles cleanly, a battery of experiments that were actually run rather than asserted, and a strategic reconciliation with the brain-scanner research program that already produced a script-native N'Ko speech recognizer at roughly twenty percent character error rate. The honest conclusion, stated up front so nothing here oversells, is that FAC has real merit but not as a standalone competitor to LAC; its merit is highest as the acoustic tone channel and the generative dual of the recognizer that already exists, and the standalone codec framing should be demoted to a section rather than promoted to a flagship.\n\nLAC works by analyzing a waveform into a small set of interpretable acoustic descriptors that span temporal, spectral, harmonic, and psychoacoustic properties, quantizing each descriptor into a word-like label drawn from a shared vocabulary, and composing those labels into an English sentence such as the one about a mid-power punch with a moderate-onset envelope that stays front-loaded and clipped. A receiver parses the sentence back into acoustic intervals and synthesizes the nearest waveform, with a closed-loop refinement step that nudges the synthesis toward the target. LAC situates itself against three neighbors in the audio representation space: captions, which are readable but too loose to resynthesize from; neural codecs such as SoundStream, EnCodec, and the Descript Audio Codec, which reconstruct extremely well but emit opaque integer tokens with no human meaning; and raw acoustic descriptor vectors, which are interpretable but live in a continuous space that neither people nor models communicate naturally. LAC's contribution is to quantize the descriptor vector into a lexical codebook and serialize it as natural-language text so that it is simultaneously readable, editable, grounded, and native to the text channel a model already speaks.\n\nThe disagreement is narrow and it is about the carrier, not the idea. Natural orthographies were never designe", "htmlHref": "/research/html/featural-acoustic-coding-with-nko-program-documentation-1sukb4y.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3570 }, { "id": "agp-nko-vast-training-handoff-6s7brt", "title": "AGP/N'Ko + Vast Training Handoff", "slug": "agp-nko-vast-training-handoff", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/handoffs/agp-nko-vast-training-handoff.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "You are continuing the N'Ko ASR training and AGP corrective-adapter program. The goal is not just to run more jobs; the goal is to finish the matched experimental bundle cleanly enough that the papers can make defensible claims about N'Ko script advantage, trajectory conditioning, TAR, and TTT.", "excerpt": "You are continuing the N'Ko ASR training and AGP corrective-adapter program. The goal is not just to run more jobs; the goal is to finish the matched experimental bundle cleanly enough that the papers can make defensible claims about N'Ko script advantage, trajectory conditioning, TAR, and TTT.\n\n1. **Acoustic ASR training on Vast/A100**: PyTorch/Whisper trajectory model family. This is where Paper 4 CER numbers come from. 2. **AGP corrective language layer on Mac4/Mac5**: MLX/Gemma LoRA adapter that proposes N'Ko text repairs after ASR decoding. Rust/Graph Kernel decides whether those repairs are admissible.\n\nDo not merge those into one imagined model unless you explicitly port the ASR stack to MLX. Right now they are separate training/runtime stacks.\n\n- dataset: `290,596` pairs - split: `232,476 / 29,060 / 29,060` - script: N'Ko - mode: trajectory - `use_trajectory=true` - `use_tar=false` - `use_ttt=false` - final/test CER: `20.57%` - best validation: about `0.635887` - best checkpoint epoch: `38` - early stop: epoch `46`\n\nImportant: the filename `train_vastai_tar_ttt.py` is broader than the actual winning mode. The verified 20.57% run did **not** use TAR or TTT.", "htmlHref": "/research/html/agp-nko-vast-training-handoff-6s7brt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1383 }, { "id": "nko-asr-row-contract-1a3ovq9", "title": "N'Ko ASR Row Contract", "slug": "nko-asr-row-contract", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/handoffs/nko_asr_row_contract_2026-04-28.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This is the concrete row-level contract that the Vast ASR exporter should emit so the local uncertainty-packet pipeline can consume it without ad hoc parsing.", "excerpt": "This is the concrete row-level contract that the Vast ASR exporter should emit so the local uncertainty-packet pipeline can consume it without ad hoc parsing.\n\n- `audio_path` - `split` - `script` - `mode` - `asr_text` - `ctc_confidence` - `partition`\n\n- `reference_text` - one stable join key: - `audio_path`, preferred - or `segment_id` - or `feat_id`\n\n- `feat_id` - `audio_id` - `segment_id` - `cer_edits` - `trajectory_scalars` - `top_confusable_spans` - `n_best_hypotheses` - `char_posteriors_summary`\n\n- legacy row upgrader: - `asr/upgrade_asr_row_contract.py` - corpus schema now includes: - `feat_id` - `audio_id` - `split` - `script` - `mode` - `reference_text` - `cer_edits` - `partition` - `trajectory_features` - `top_confusable_spans` - `n_best_hypotheses` - `char_posteriors_summary` - `uncertainty_score`", "htmlHref": "/research/html/nko-asr-row-contract-1a3ovq9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 341 }, { "id": "edit-candidate-ranker-report-ndcnis", "title": "Edit-Candidate Ranker Report", "slug": "edit-candidate-ranker-report", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/overnight/edit_candidate_ranker_v1/RANKER-REPORT.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| condition | CER | delta pp | changed | better/same/worse | |---|---:|---:|---:|---:| | baseline | 0.3421 | +0.00 | 0 | 0/0/0 | | oracle_any | 0.2832 | -5.89 | 274 | 274/0/0 | | ranker | 0.2957 | -4.63 | 274 | 255/19/0 | | ranker_preserve | 0.3199 | -2.22 | 140 | 124/16/0 |", "excerpt": "| condition | CER | delta pp | changed | better/same/worse | |---|---:|---:|---:|---:| | baseline | 0.3421 | +0.00 | 0 | 0/0/0 | | oracle_any | 0.2832 | -5.89 | 274 | 274/0/0 | | ranker | 0.2957 | -4.63 | 274 | 255/19/0 | | ranker_preserve | 0.3199 | -2.22 | 140 | 124/16/0 |\n\nValidation AUC: 0.9305039335757725 Validation AP: 0.8784072602172582 Test AUC: 0.9391017940743587 Test AP: 0.8967641446536138\n\nThis is a held-out test of the deterministic candidate-ranker architecture. The oracle remains non-deployable because it uses references. The ranker uses only candidate features.\n\nArtifacts: `experiments/acoustic_gate/overnight/edit_candidate_ranker_v1/ranker_report.json`, `experiments/acoustic_gate/overnight/edit_candidate_ranker_v1/test_decisions.jsonl`.", "htmlHref": "/research/html/edit-candidate-ranker-report-ndcnis.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 118 }, { "id": "ranker-serving-handoff-ane-turboquant-wraps-the-tiny-ranker-not-gemma-11otusb", "title": "Ranker Serving Handoff — ANE/TurboQuant Wraps the Tiny Ranker, Not Gemma", "slug": "ranker-serving-handoff-ane-turboquant-wraps-the-tiny-ranker-not-gemma", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/RANKER-SERVING-HANDOFF.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "```text anchor ASR hyp + logits/self-score -> deterministic bounded candidates -> frozen logistic candidate ranker -> calibrated mode threshold -> deterministic corrected text ```", "excerpt": "Gemma is out of the live path. Full-string Gemma failed the latency gate; edit-op Gemma met the schema only under constrained decode and collapsed to `COPY`. The deployable correction model is the tiny deterministic ranker config:\n\nThat JSON carries feature means/stds, logistic weights/bias, calibrated operating modes, candidate-generator config, and serialized ASR->clean confusion maps. It does not need training rows at inference time.\n\n| mode | CER | delta pp | better/same/worse | |---|---:|---:|---:| | baseline | 0.4352 | +0.00 | 0/0/0 | | aggressive/balanced | 0.3986 | -3.66 | 439/41/2 | | conservative | 0.4026 | -3.26 | 381/15/0 | | preservation | 0.4188 | -1.64 | 196/14/0 |\n\nUse `conservative` for automatic correction. Use `aggressive`/`balanced` for offline corpus improvement or human-review queues.\n\n- `feat_id` - `asr_hyp` - `asr_score` - CTC log-prob access for candidate scoring", "htmlHref": "/research/html/ranker-serving-handoff-ane-turboquant-wraps-the-tiny-ranker-not-gemma-11otusb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2449 }, { "id": "nko-speech-stack-system-architecture-ledger-1turtkn", "title": "N'Ko Speech Stack — System Architecture Ledger", "slug": "nko-speech-stack-system-architecture-ledger", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/SYSTEM-ARCHITECTURE-LEDGER.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This file prevents the program from looking like a sequence of overwritten ideas. The work has not been reset; it has compressed into layers. Each experiment either became a system component, a constraint, or a publishable negative result.", "excerpt": "This file prevents the program from looking like a sequence of overwritten ideas. The work has not been reset; it has compressed into layers. Each experiment either became a system component, a constraint, or a publishable negative result.\n\nN'Ko speech becomes infrastructure when a clean script-native ASR anchor emits N'Ko, a deterministic edit/ranker layer performs bounded harm-free correction, and the whole path is served offline on iOS through CoreML, with ANE/TurboQuant reserved for the heavy encoder/compression layer.\n\nDo not treat the newest benchmark as replacing the older work. Treat it as assigning older work to a clearer layer. A result can end in four valid states:\n\n1. **Component:** it remains in the serving/research path. 2. **Constraint:** it becomes a rule that prevents a repeat failure. 3. **Negative result:** it becomes publishable evidence about what not to build. 4. **Parked branch:** it remains outside the first phone proof, but feeds the broader speech system later.\n\nThe current phone stack is only the narrow serving spine. The larger architecture also keeps the representation papers, metric argument, uncertainty packet, provenance corpus, speaker atlas, search/TTS branch, tone/phonemic-substrate work, and meaning flywheel.", "htmlHref": "/research/html/nko-speech-stack-system-architecture-ledger-1turtkn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2424 }, { "id": "whisper-encoder-feature-path-audit-4hlreb", "title": "Whisper Encoder / Feature Path Audit", "slug": "whisper-encoder-feature-path-audit", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/WHISPER-ENCODER-PATH-AUDIT.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2026-06-02 **Scope:** Determine whether the current workspace already contains a reusable CoreML Whisper encoder / ANE feature extraction path for the clean anchor ASR serving stack.", "excerpt": "**Date:** 2026-06-02 **Scope:** Determine whether the current workspace already contains a reusable CoreML Whisper encoder / ANE feature extraction path for the clean anchor ASR serving stack.\n\nNo reusable Whisper encoder CoreML artifact was found locally for the clean anchor path, so a new exporter was added and validated.\n\nTargeted searches under `[home-path]` and `/Volumes/HD1` found unrelated CoreML models such as MotionMix `ConditioningEncoder.mlpackage`, but no `Whisper*.mlmodel`, `Whisper*.mlmodelc`, `Whisper*.mlpackage`, or equivalent ASR encoder package.\n\n- `ane_ctc_train.py` - `features/*.pt` - `pairs.jsonl` - MLX CTC-head checkpoints under `checkpoints/`\n\nDespite the script title (\"ANE+MLX CTC Training — Frozen Whisper encoder on ANE, CTC head on MLX GPU\"), `ane_ctc_train.py` is a trainer over already-extracted feature tensors. It does not export or run a Whisper encoder. The training loop loads `.pt` tensors from `features/` and trains a small MLX CTC head.", "htmlHref": "/research/html/whisper-encoder-feature-path-audit-4hlreb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2287 }, { "id": "codex-handoff-nko-asr-vast-ai-pipeline-monitor-g40t63", "title": "Codex Handoff: N'Ko ASR Vast.ai Pipeline Monitor", "slug": "codex-handoff-nko-asr-vast-ai-pipeline-monitor", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/HANDOFF_CODEX.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Created:** 2026-04-04 14:50 UTC **Author:** Claude (Mac1 bottom-right pane) **For:** Codex agent taking over monitoring duties", "excerpt": "**Created:** 2026-04-04 14:50 UTC **Author:** Claude (Mac1 bottom-right pane) **For:** Codex agent taking over monitoring duties\n\nTwo CTC inference jobs are transcribing 32,826 Djoko soap opera audio segments on a Vast.ai RTX 4090 GPU. A watchdog monitors both jobs and will auto-launch a 3-step chain when they finish.\n\n**Instance:** 34097422 (label: `djoko-batch-v3`) **Machine:** RTX 4090, 16 vCPUs, 127GB RAM, 100GB disk (53GB used) **Cost:** $0.3337/hr **SSH:** `[ssh command redacted]`\n\n### Progress at handoff time - N'Ko: 16,128 / 32,826 (49.1%) - Latin: 16,129 / 32,826 (49.1%) - Rate: ~1.4 segments/second per job - ETA: ~3.2 hours from handoff (~6pm local)\n\n| Session | Process | Purpose | |---------|---------|---------| | `nko_infer` | `vastai_transcribe.py --script nko --resume` | N'Ko CTC inference on 32,826 Djoko WAV segments | | `latin_infer` | `vastai_transcribe.py --script latin --resume` | Latin CTC inference on same 32,826 segments | | `watchdog` | `watchdog.sh` | Checks every 60s. Restarts dead jobs. Launches chain when both done. |", "htmlHref": "/research/html/codex-handoff-nko-asr-vast-ai-pipeline-monitor-g40t63.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1532 }, { "id": "nko-research-paper-roadmap-18wy6ad", "title": "N'Ko Research Paper Roadmap", "slug": "nko-research-paper-roadmap", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/PAPER_ROADMAP.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Six papers forming a coherent research arc: from diagnosing why AI fails on N'Ko, to building systems that work, to proving structural advantages, to connecting language identity with personalized AI and blockchain provenance.", "excerpt": "Six papers forming a coherent research arc: from diagnosing why AI fails on N'Ko, to building systems that work, to proving structural advantages, to connecting language identity with personalized AI and blockchain provenance.\n\nEach paper builds on the previous. Together they constitute a thesis-level body of work on indigenous script computing.\n\n**Title:** Dead Circuits: Activation Profiling and Script Invisibility in Large Language Models\n\n**Status:** Draft complete (1,305 lines). Model identity corrected to Qwen3-8B. Claims audited.\n\n**Core finding:** LLMs have zero functional circuits for N'Ko. Translation tax of 2.90x, 0/55 reasoning configurations, 85.8% kurtosis deficit. Three-stage LoRA reduces tax to 0.70x.", "htmlHref": "/research/html/nko-research-paper-roadmap-18wy6ad.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1488 }, { "id": "assumptions-and-invariants-ledger-1qr856n", "title": "Assumptions and Invariants Ledger", "slug": "assumptions-and-invariants-ledger", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/pipeline/scripts/ASSUMPTIONS_INVARIANTS.md", "extension": "md", "score": 32, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. Assumptions 1.1 A-1 GEMINI_API_KEY is set and valid. 1.1.1 If false: OCR requests fail and no detections are produced. 1.1.2 Detection: API errors or authentication failures in logs. 1.2 A-2 yt-dlp and ffmpeg are installed and available on PATH. 1.2.1 If false: Downloads or frame extraction fail. 1.2.2 Detection: Command not found or subprocess failures. 1.3 A-3 YouTube access is available or mitigated via HLS/cookies. 1.3.1 If false: Video downloads fail with 403 or similar errors. 1.3.2 Detection: yt-dlp error", "excerpt": "1. Assumptions 1.1 A-1 GEMINI_API_KEY is set and valid. 1.1.1 If false: OCR requests fail and no detections are produced. 1.1.2 Detection: API errors or authentication failures in logs. 1.2 A-2 yt-dlp and ffmpeg are installed and available on PATH. 1.2.1 If false: Downloads or frame extraction fail. 1.2.2 Detection: Command not found or subprocess failures. 1.3 A-3 YouTube access is available or mitigated via HLS/cookies. 1.3.1 If false: Video downloads fail with 403 or similar errors. 1.3.2 Detection: yt-dlp errors and retry exhaustion. 1.4 A-4 Supabase URL and service role key are provided when `--store-supabase` is used. 1.4.1 If false: Storage fails and records are not persisted. 1.4.2 Detection: Supabase insert errors.\n\n2. Invariants 2.1 I-1 Must use Supabase service role key for inserts when `--store-supabase` is enabled. 2.1.1 Why: RLS policies block inserts with anon keys. 2.1.2 If violated: Inserts fail and data is lost. 2.1.3 Canary: RLS policy violation errors. 2.2 I-2 Must write output JSON with top-level keys `summary` and `results`. 2.2.1 Why: Downstream consumers rely on stable schema. 2.2.2 If violated: Consumers cannot parse outputs. 2.2.3 Canary: Missing keys in output validation. 2.3 I-3 Must include `video_id` and `frame_index` for each detection. 2.3.1 Why: Results must remain traceable to source media. 2.3.2 If violated: Detections cannot be audited or deduplicated. 2.3.3 Canary: Missing fields in output validation. 2.4 I-4 Must not generate world variants when `--skip-worlds` is set. 2.4.1 Why: User explicitly opts out to reduce cost and time. 2.4.2 If violated: Cost increases and contract is broken. 2.4.3 Canary: World variants present when `--skip-worlds` is used.", "htmlHref": "/research/html/assumptions-and-invariants-ledger-1qr856n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 278 }, { "id": "documentation-audit-pass-5-tauri-desktop-integration-1htyk16", "title": "Documentation Audit Pass 5: Tauri Desktop Integration", "slug": "documentation-audit-pass-5-tauri-desktop-integration", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/_archive/2024-12/DOCUMENTATION_AUDIT_PASS5_COMPLETE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date**: December 21, 2025 **Focus**: Enhanced Tauri documentation and created production-ready implementation starter **Status**: ✅ **Complete** - All 5 tasks finished", "excerpt": "**Date**: December 21, 2025 **Focus**: Enhanced Tauri documentation and created production-ready implementation starter **Status**: ✅ **Complete** - All 5 tasks finished\n\nFollowing Passes 1-4 (documentation consolidation, service READMEs, concept docs), Pass 5 applied all learned documentation standards to create comprehensive Tauri desktop implementation guides and starter code.\n\n**What Was Delivered**: 1. ✅ Updated Tauri proposal with documentation standards 2. ✅ Created complete Tauri implementation starter package (19 files, ~2,800 lines) 3. ✅ Added comprehensive Tauri integration guide to main docs 4. ✅ Updated architecture documentation with Tauri option 5. ✅ Created detailed Tauri vs Native comparison guide\n\n**Total Output**: ~7,200 lines of documentation + 2,800 lines of implementation code\n\n**Impact**: Developers can now start building the Tauri desktop app in <10 minutes with full implementation examples and deployment guides.", "htmlHref": "/research/html/documentation-audit-pass-5-tauri-desktop-integration-1htyk16.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2000 }, { "id": "fine-tune-wav2vec2-for-dj-commands-complete-guide-7ylziw", "title": "Fine-tune Wav2Vec2 for DJ Commands - Complete Guide", "slug": "fine-tune-wav2vec2-for-dj-commands-complete-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/FINE_TUNE_GUIDE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Why this approach?** - ✅ **Speed**: <100ms total latency (acceptable for DJing) - ✅ **Accuracy**: Fine-tuned ASR + semantic retrieval = best of both worlds - ✅ **Flexibility**: Can add new commands without retraining audio model - ✅ **Debugging**: Can see transcribed text - ✅ **Practical**: Uses pre-trained models with fine-tuning", "excerpt": "Train Wav2Vec2 to recognize **your voice** saying DJ commands with >95% accuracy while maintaining <100ms latency.\n\n**Why this approach?** - ✅ **Speed**: <100ms total latency (acceptable for DJing) - ✅ **Accuracy**: Fine-tuned ASR + semantic retrieval = best of both worlds - ✅ **Flexibility**: Can add new commands without retraining audio model - ✅ **Debugging**: Can see transcribed text - ✅ **Practical**: Uses pre-trained models with fine-tuning\n\n**vs Pure S2O (Audio→Command)**: - Faster (~20ms) but: - Requires large audio-command dataset - Less flexible (fixed command vocabulary) - Harder to debug - More complex training pipeline\n\n**What you'll do**: 1. UI shows a command (e.g., \"play left\") 2. Click \"RECORD\" button 3. Speak the command clearly after countdown 4. Repeat 3 times per command (for robustness) 5. ~40 commands × 3 variations = 120 recordings\n\n**Tips**: - Speak naturally (as you would while DJing) - Use consistent pronunciation - Record in similar environment to where you'll DJ - Take breaks every 20 commands", "htmlHref": "/research/html/fine-tune-wav2vec2-for-dj-commands-complete-guide-7ylziw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1270 }, { "id": "voice-control-systems-complete-guide-1t7e6h6", "title": "Voice Control Systems - Complete Guide", "slug": "voice-control-systems-complete-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/VOICE_CONTROL_SYSTEMS_GUIDE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Need | System | Command | |------|--------|---------| | **Lowest latency** (internet OK) | Gemini Live | `./START_REKORDBOX_VOICE_GEMINI.sh` | | **Highest accuracy** (offline) | Whisper | `./START_REKORDBOX_VOICE_WHISPER.sh` | | **Best long-term** (self-improving) | **Hybrid** ⭐ | `./START_REKORDBOX_VOICE_HYBRID.sh` |", "excerpt": "You now have **three different voice control systems** for Rekordbox. Choose based on your needs!\n\n| Need | System | Command | |------|--------|---------| | **Lowest latency** (internet OK) | Gemini Live | `./START_REKORDBOX_VOICE_GEMINI.sh` | | **Highest accuracy** (offline) | Whisper | `./START_REKORDBOX_VOICE_WHISPER.sh` | | **Best long-term** (self-improving) | **Hybrid** ⭐ | `./START_REKORDBOX_VOICE_HYBRID.sh` |\n\n### When to Use - Live performance with reliable internet - Need absolute lowest latency - Don't mind cloud dependency\n\n| Metric | Value | |--------|-------| | Latency | **80ms** ✅ | | Accuracy | 98% ✅ | | Offline | ❌ No (requires internet) | | Self-improving | ❌ No | | Setup time | 5 min |\n\n### Pros - ⚡ **Fastest** (80ms total latency) - 🎯 **Most accurate** out-of-box (98%) - 🔧 **Easiest** setup (just API key)", "htmlHref": "/research/html/voice-control-systems-complete-guide-1t7e6h6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1694 }, { "id": "s2o-vs-asr-retrieval-technical-deep-dive-8m4cq8", "title": "S2O vs ASR+Retrieval - Technical Deep Dive", "slug": "s2o-vs-asr-retrieval-technical-deep-dive", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/S2O_VS_ASR_RETRIEVAL_DEEP_DIVE.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "3. **CLAP** (Contrastive Language-Audio Pretraining): Audio → Audio Embedding - ✅ Pre-trained - ❌ Audio embeddings are for **sounds** (music, environmental sounds) - ❌ Not trained on **speech commands**", "excerpt": "**The problem**: There's no pre-trained model that embeds **audio** into **text embedding space**!\n\n1. **Wav2Vec2**: Audio → Text (via CTC decoding) - ✅ Pre-trained on speech - ❌ Outputs text, not embeddings\n\n2. **Whisper**: Audio → Text (via decoder) - ✅ Pre-trained on speech - ❌ Outputs text, not embeddings\n\n3. **CLAP** (Contrastive Language-Audio Pretraining): Audio → Audio Embedding - ✅ Pre-trained - ❌ Audio embeddings are for **sounds** (music, environmental sounds) - ❌ Not trained on **speech commands**\n\n4. **AudioCLIP**: Audio + Text in shared space - ✅ Audio and text in same space! - ❌ Trained on **music/sounds**, not **speech** - ❌ Not fine-tuned for commands", "htmlHref": "/research/html/s2o-vs-asr-retrieval-technical-deep-dive-8m4cq8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1728 }, { "id": "tier-3-medium-term-architectural-enhancements-final-summary-1pgch2t", "title": "Tier 3: Medium-Term Architectural Enhancements - Final Summary", "slug": "tier-3-medium-term-architectural-enhancements-final-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/TIER3_FINAL_SUMMARY.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Implementation:** - `state/state_snapshot.py` (210 lines) - Immutable state snapshots - `state/history_manager.py` (250 lines) - Ring buffer with undo/redo - `state/undo_handler.py` (300 lines) - Command parsing & inverse generation", "excerpt": "**Implementation:** - `state/state_snapshot.py` (210 lines) - Immutable state snapshots - `state/history_manager.py` (250 lines) - Ring buffer with undo/redo - `state/undo_handler.py` (300 lines) - Command parsing & inverse generation\n\n**Performance:** - Memory: ~40 KB (20 snapshots) - Latency: <5ms overhead - Accuracy: 100% deterministic\n\n**Implementation:** - `engines/whisper_engine.py` (280 lines) - Local speech recognition with VAD - `engines/health_monitor.py` (200 lines) - API health tracking\n\n**Key Features:** - Automatic failover when Gemini unavailable - 4 model sizes (tiny.en → medium.en) - Health monitoring (30s intervals) - <100ms switch time - 99.9% uptime guarantee\n\n**Performance:** - Gemini latency: 200ms @ 95% accuracy - Whisper (base): 500ms @ 90% accuracy - Whisper (tiny): 300ms @ 85% accuracy", "htmlHref": "/research/html/tier-3-medium-term-architectural-enhancements-final-summary-1pgch2t.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1549 }, { "id": "tier-3-medium-term-architectural-enhancements-progress-summary-w3ea6e", "title": "Tier 3: Medium-Term Architectural Enhancements - Progress Summary", "slug": "tier-3-medium-term-architectural-enhancements-progress-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/TIER3_PROGRESS_SUMMARY.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Tier 3 introduces **advanced architectural features** that make the voice control system more robust, intelligent, and production-ready.", "excerpt": "Tier 3 introduces **advanced architectural features** that make the voice control system more robust, intelligent, and production-ready.\n\n**What It Does:** - Tracks command execution history (last 20 snapshots) - Voice-activated undo: \"undo\", \"undo last 3\", \"undo play left\" - Voice-activated redo: \"redo\", \"redo last 2\" - Time-based rollback: \"reset to 30 seconds ago\" - Command history query: \"show history\"\n\n**Implementation:** - `dj_agent/voice_control/state/state_snapshot.py` - State snapshot dataclasses - `dj_agent/voice_control/state/history_manager.py` - History management with ring buffer - `dj_agent/voice_control/state/undo_handler.py` - Undo/redo command handling - Integrated into `gemini_listener_enhanced.py` - Added to `run_rekordbox_voice_gemini_enhanced.py`\n\n**Key Features:** - Ring buffer (configurable size, default 20) - Smart state diffing (memory efficient) - Deterministic undo/redo - Time-based rollback - Command pattern matching - Integration with all Tier 1 & 2 features\n\n**Stats:** - Lines of code: ~550 - Memory overhead: ~40 KB (20 snapshots) - Latency overhead: <5ms - Accuracy: 100% deterministic", "htmlHref": "/research/html/tier-3-medium-term-architectural-enhancements-progress-summary-w3ea6e.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1630 }, { "id": "echelon-phase-3-detailed-to-do-list-1ombphs", "title": "Echelon Phase 3 Detailed To-Do List", "slug": "echelon-phase-3-detailed-to-do-list", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/echelon/phases/phase-3-todo.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- [ ] **Whisper-rs Integration** (Phase 3) - [ ] Download Whisper model files - [ ] Complete voice recognizer implementation - [ ] Test voice recognition accuracy - [ ] Optimize for real-time performance", "excerpt": "## Status Overview - **Phase 1**: ✅ Complete (Audio Engine) - **Phase 2**: ✅ Complete (Scheduler & Safety) - **Phase 3**: 🚧 In Progress (Motion, Voice & Phrase Intelligence) - Week 13: ✅ Complete (Motion Stream Integration) - Week 14: ✅ Complete (Voice Control Integration) - Week 15: ⏳ In Progress (Phrase Intelligence Service) - Week 16: ⏳ Pending (UI Foundation & Deck Lanes) - Week 17: ⏳ Pending (Phrase Browser & Automation) - Week 18: ⏳ Pending (Integration & Beta Review)\n\n### 15.1 Phrase Database Service - [ ] **Create phrase-intelligence crate** - [ ] Add crate to workspace - [ ] Set up dependencies (FAISS bindings or alternative ANN) - [ ] Define `Phrase` struct with metadata - [ ] Define `PhraseDatabase` struct - [ ] Implement database loading from Episode 1 format - [ ] Implement FAISS index building - [ ] Implement `search_similar()` method - [ ] Add unit tests for phrase loading - [ ] Add unit tests for similarity search - **Dependencies:** FAISS Rust bindings or manual ANN implementation - **Deliverable:** Phrase database loads and searches phrases\n\n### 15.2 Recommendation Engine - [ ] **Create PhraseRecommender struct** - [ ] Define `RecommendationContext` struct - [ ] Implement context-based recommendation strategy - [ ] Implement motion-driven recommendation strategy - [ ] Implement tempo-matched recommendation strategy - [ ] Implement mood-based recommendation strategy - [ ] Add `recommend()` method returning top-K phrases - [ ] Implement recommendation scoring algorithm - [ ] Add unit tests for recommendation strategies - **Dependencies:** Phrase database (15.1) - **Deliverable:** Recommendation engine suggests contextually appropriate phrases\n\n### 15.3 Online Recommendation Service - [ ] **Create HTTP/gRPC service wrapper** - [ ] Define service endpoints (`POST /recommend`, `GET /phrase/{id}`) - [ ] Implement request/response types - [ ] Add caching layer for recent recommendations - [ ] Implement cache invalidation logic - [ ] Add latency tracking (<5 ms target) - [ ] Integrate with scheduler (motion events → recommendations) - [ ] Add integration tests - **Dependencies:** Recommendation engine (15.2) - **Deliverable:** Online service provides <5 ms phrase recommendations\n\n### 16.1 UI Framework Setup - [ ] **Choose and set up UI framework** - [ ] Evaluate egui vs iced for performance/features - [ ] Create `echelon-ui` crate - [ ] Set up window management (main window, phrase browser, settings) - [ ] Implement IPC between UI and engine (channels or shared memory) - [ ] Add UI telemetry (FPS, render time tracking) - [ ] Create basic window layout - **Dependencies:** egui or iced crate - **Deliverable:** UI window opens and displays basic layout", "htmlHref": "/research/html/echelon-phase-3-detailed-to-do-list-1ombphs.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2125 }, { "id": "visualize-1i64ibb", "title": "visualize", "slug": "visualize", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/echelon/visualize.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "If you want the audience—and yourself—to feel the shape of Echelon’s inner life as you play, you have to turn an invisible vector (x_t^*\\in\\mathbb{R}^D) into a picture that moves with the same inevitability as the music. The challenge is not just to plot numbers; it’s to build a visual grammar where geometry equals meaning, where distance means “more different,” curvature means “changing intention,” thickness means “tension,” and motion means “you.” The trick is to choose a projection that preserves the two invaria", "excerpt": "If you want the audience—and yourself—to feel the shape of Echelon’s inner life as you play, you have to turn an invisible vector (x_t^*\\in\\mathbb{R}^D) into a picture that moves with the same inevitability as the music. The challenge is not just to plot numbers; it’s to build a visual grammar where geometry equals meaning, where distance means “more different,” curvature means “changing intention,” thickness means “tension,” and motion means “you.” The trick is to choose a projection that preserves the two invariants your engine already enforces: contraction in the fast loop and phase alignment in the scheduler. When you respect those invariants visually, the image becomes a second instrument—honest, rhythmic, and interpretable at a glance.\n\nStart by deciding what the axes should mean. You do not want an arbitrary 2D scatter that jitters because the optimization changed its mind. You want a stable map that you can revisit next week and still recognize. There are two good ways to get that stability. One is to learn, offline, a parametric projector (f_\\phi:\\mathbb{R}^D\\to\\mathbb{R}^2) on your rehearsal data—a tiny two-layer network trained to preserve local neighborhoods the way UMAP does—then freeze its weights and run it in real time. The other is to compute a fixed linear basis with PCA on your rehearsals, take the top two or three components, and project live latents onto that plane. The first gives you more curvature and semantic separation; the second gives you maximum predictability with almost no compute. Either way, once you freeze (f_\\phi) or the PCA matrix, the map stops drifting; a region that meant “hand-driven shimmer” last month still means it today.\n\nNow tie the map to rhythm. Phase is already a circular variable in Echelon, a number (\\psi_t) between 0 and (2\\pi) that tells you where inside the beat you are. If you draw your manifold as a flat scatter, phase is homeless. If you draw it on a ring, phase feels like home. A simple and powerful visual is to embed (\\psi_t) as angle and latent energy (|x_t^*|) as radius: a polar plot where each frame lands on a circle and the point breathes in and out with effort. That picture alone—the wheel spinning, the comet tail fading behind the head—tells you whether your body is in time. If you want the full manifold and the phase wheel at once, you can lift the 2D projector into a cylinder: use (f_\\phi(x)) for the floor plan and draw a thin halo around the current point whose hue rotates with (\\psi_t). The halo locks the picture to the beat; the floor plan tells you what kind of motion you’re in.\n\nContraction belongs in the picture as thickness. The fast loop’s residual (r_t=|x_{t}^{(k+1)}-x_{t}^{(k)}|) is a measure of how hard the solver is working. Draw the live point with an outer glow whose radi", "htmlHref": "/research/html/visualize-1i64ibb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3763 }, { "id": "sensor-fusion-implementation-specification-18gju83", "title": "Sensor Fusion Implementation Specification", "slug": "sensor-fusion-implementation-specification", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/03-guides/development/FUSION_IMPLEMENTATION_SPEC.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document provides detailed implementation specifications for the Mocopi + MediaPipe sensor fusion system. It includes code scaffolds, API contracts, and integration points with existing Comp-Core infrastructure.", "excerpt": "This document provides detailed implementation specifications for the Mocopi + MediaPipe sensor fusion system. It includes code scaffolds, API contracts, and integration points with existing Comp-Core infrastructure.\n\nTo enable the Python fusion engine to receive MediaPipe data from the web dashboard, we need a WebSocket bridge.\n\n2. **Implement UnifiedReceiver** (Week 1) - Port the code from this spec - Add unit tests - Verify Mocopi + simulated MediaPipe\n\n3. **Implement KalmanFusion** (Week 2) - Port the EKF code - Tune parameters with real sensor data - Add visualization for debugging\n\n4. **Build WebSocket bridge** (Week 2) - Add MediaPipeBridge to dashboard - Test end-to-end streaming", "htmlHref": "/research/html/sensor-fusion-implementation-specification-18gju83.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4322 }, { "id": "evolution-log-motion-autocomplete-ai-predicts-your-next-physical-movement-9ogd0l", "title": "Evolution Log — Motion Autocomplete: AI predicts your next physical movement", "slug": "evolution-log-motion-autocomplete-ai-predicts-your-next-physical-movement", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/hef-evolutions/motion-autocomplete-ai-predicts-your-next-physical/EVOLUTION.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Goal:** Evolve Gen 6 heuristic prototype into a runnable multimodal prediction stack with testable orchestration behavior.", "excerpt": "**Goal:** Evolve Gen 6 heuristic prototype into a runnable multimodal prediction stack with testable orchestration behavior.\n\n### Delivered - Multimodal schemas (`MotionFrame`) combining IMU, pose, and local context. - Fusion predictor with sliding-window feature aggregation and intent scoring. - Intent set expanded to: `lifting_object`, `turning_around`, `reaching_for_object`, `walking_towards_exit`, `idle`. - Context orchestrator upgraded to produce structured action plans with confidence gating and cooldown suppression. - Deterministic stream simulator for multiple scenarios. - CLI enhancements: scenario selection, `all` mode, JSON output. - Runtime config added in `config/default.json`. - Tests: predictor unit tests, orchestrator unit tests, CLI smoke test. - Packaging/runtime scaffolding: `pyproject.toml`, `Makefile`, `Dockerfile`.\n\n### Findings - Feature-level fusion improves interpretability versus single-axis heuristics. - Cooldown suppression is required to avoid noisy repetitive automation. - Deterministic simulation seeds make regression testing stable across generations.\n\n### Next Suggestion (Generation 8) Replace heuristic scoring with a lightweight learned temporal model and attach real endpoint adapters (Graph Kernel / Perception Mesh) to evaluate latency under live input.\n\n**Quality Score:** 0.9 **Files Changed:** `ARCHITECTURE.md`, `EVOLUTION.md`, `.gitignore`, `src/models/motion.py`, `src/engine/predictor.py`, `src/context/orchestrator.py`, `src/main.py` **Commits:** `dc2b8f2` **Artifacts:** Technical Specification, Motion Prediction Engine (Heuristic), Context Orchestrator, Real-time Simulation Tool **Next Suggestion:** Replace heuristics with lightweight sequence model and add multimodal sensor fusion.", "htmlHref": "/research/html/evolution-log-motion-autocomplete-ai-predicts-your-next-physical-movement-9ogd0l.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2289 }, { "id": "evolution-log-weighted-dance-style-buff-barista-13cgmai", "title": "Evolution Log — Weighted Dance Style: Buff Barista", "slug": "evolution-log-weighted-dance-style-buff-barista", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/hef-evolutions/weighted-dance-style-train-motion-model-variant-th/EVOLUTION.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Quality Score:** 0.95 **Files Changed:** EVOLUTION.md, GEMINI.md, README.md, src/buff_barista/barista_moves.py, src/buff_barista/main.py, src/buff_barista/motion_physics.py, src/buff_barista/signature_style.md, src/buff_barista/train_motion_model.py **Commits:** feat(hef): implement buff barista weighted dance style Gen 7 **Artifacts:** src/buff_barista/main.py, src/buff_barista/motion_physics.py, src/buff_barista/barista_moves.py, src/buff_barista/signature_style.md **Next Suggestion:** Explore 3D visualization ", "excerpt": "## Generation 7.1 (Current) **Focus:** Integration of Neural Network architecture and Mock Mocap Data for 4-6 lb weighted dance training.\n\n### Changes: - **`neural_network.py`:** Implemented a mock PyTorch-style neural network (`BuffBaristaNet`) with dense linear layers and backpropagation to learn the mapping from base dance trajectories to weighted trajectories. - **`mocap_data.py`:** Created a synthetic motion capture data generator (`MocapDataset`) that applies human variation and sensor noise to simulated physical movements. - **`train_motion_model.py`:** Overhauled the training scaffold to use mini-batch stochastic gradient descent over the synthetic mocap dataset. - **`main.py`:** Updated to reflect version 7.1 and output smoothed evaluation metrics. - **`motion_physics.py`:** Minor adjustments to ensure coordinates return as tuples to match expected dataset formats.\n\n### Key Innovations: - Moved from algorithmic static evaluation to a dynamic learning pipeline. - Realistic simulation of sensor noise to make the dataset more challenging. - The `BuffBaristaNet` successfully learns the inertia and drag factors inherent to the 4-6 lb weights across the signature moves.\n\n## Generation 7 (Previous) **Focus:** Implementation of core biomechanics and signature movement trajectories for 4-6 lb weighted dance.\n\n### Changes: - **Implemented `src/buff_barista/`:** Created a structured implementation of the style. - **`motion_physics.py`:** Developed a physics simulator to handle weight inertia on arm trajectories. - **`barista_moves.py`:** Defined the \"Buff Barista\" signature moves (Espresso Tamp, Milk Steam Swirl, Free Pour Art). - **`train_motion_model.py`:** Created a training scaffold to simulate the style's convergence. - **`signature_style.md`:** Documented the biomechanical principles and aesthetic goals of the style.", "htmlHref": "/research/html/evolution-log-weighted-dance-style-buff-barista-13cgmai.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1769 }, { "id": "optimal-cognitive-twin-training-configuration-1wtlw7k", "title": "Optimal Cognitive Twin Training Configuration", "slug": "optimal-cognitive-twin-training-configuration", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/karl/optimal-twin-config.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Target: Qwen2.5-7B-Instruct-4bit on Mac5 (M4 16GB) via MLX LoRA > Dataset: 2,923 train / 328 valid examples of Mohamed's responses > Goal: Override \"helpful assistant\" persona with Mohamed's direct, action-oriented voice > Date: 2026-03-23 > Extends: lora-persona-research.md (2026-03-22)", "excerpt": "> Target: Qwen2.5-7B-Instruct-4bit on Mac5 (M4 16GB) via MLX LoRA > Dataset: 2,923 train / 328 valid examples of Mohamed's responses > Goal: Override \"helpful assistant\" persona with Mohamed's direct, action-oriented voice > Date: 2026-03-23 > Extends: lora-persona-research.md (2026-03-22)\n\nThe current training runs have two fundamental problems: (1) the 4-bit quantization requires dramatically different hyperparameters than full-precision LoRA, and (2) persona transfer demands comprehensive layer coverage that conflicts with the 16GB memory ceiling. The solution is a specific combination of conservative learning rate (5e-5), gradient checkpointing, LoRA rank 32 on all layers with attention+MLP targeting, batch 1 with grad accumulation of 8, and the `--mask-prompt` flag. For the anticipation geometry integration, the scalars should be embedded into the system prompt as conditioning context at inference time, not injected into the training loop. The knowledge graph integrates via a Parametric-RAG pattern: query at inference, inject retrieved triples into the prompt.\n\nThe training log shows a clear pattern: - **1e-5**: Converges but too slow to override instruct persona (val loss 1.796, still sounds generic) - **2e-4**: Gradient explosion (loss -> NaN at iter 40) - **5e-5 with mask-prompt**: Running, val loss 2.377 at iter 800 (higher due to mask-prompt, which is expected)\n\n4-bit NormalFloat (NF4) quantization introduces quantization noise into the forward pass. When gradients flow back through quantized weights, the effective gradient magnitudes are noisier and more volatile than with full-precision weights. The QLoRA paper (Dettmers et al., NeurIPS 2023) found this can cause sudden gradient spikes during backpropagation, particularly in attention layers where the Q/K dot product amplifies small weight perturbations quadratically.\n\nAt LR 2e-4, these amplified gradients exceed the stable training region. The NaN at iter 40 is consistent with a gradient spike accumulating over ~40 updates until the loss landscape escapes the local basin entirely.", "htmlHref": "/research/html/optimal-cognitive-twin-training-configuration-1wtlw7k.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4415 }, { "id": "bambara-asr-integration-1m1jodr", "title": "Bambara ASR Integration", "slug": "bambara-asr-integration", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "projects/LearnNKo/ml/docs/technical/ASR_INTEGRATION.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This integration uses the **RobotsMali NVIDIA NeMo models** for Bambara automatic speech recognition, complementing our English↔Bambara translation system.", "excerpt": "This integration uses the **RobotsMali NVIDIA NeMo models** for Bambara automatic speech recognition, complementing our English↔Bambara translation system.\n\n### **Available Models** | Model | Architecture | Parameters | WER | Description | |-------|-------------|------------|-----|-------------| | **QuartzNet** | QuartzNet-15x5 | 19M | 46.5% | Faster, smaller model | | **Soloni** | FastConformer-TDT-CTC | 114M | 40.6% | More accurate, larger model |\n\n### **3. Add Audio Files** Place Bambara audio files in the `audio_samples/` directory: - Formats: WAV, MP3, FLAC, OGG, M4A - Language: Bambara speech - Quality: Clear speech, minimal noise\n\n### **Models Used** - **Base Models**: RobotsMali's fine-tuned NVIDIA NeMo models - **Training Data**: 37 hours of Bambara speech (bam-asr-all dataset) - **Framework**: NVIDIA NeMo toolkit - **License**: CC-BY-4.0\n\n### **Audio Processing** - **Input**: 16kHz mono WAV files (auto-converted if different) - **Preprocessing**: Resampling, normalization, format conversion - **Validation**: Audio quality checks and recommendations", "htmlHref": "/research/html/bambara-asr-integration-1m1jodr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 841 }, { "id": "agp-nko-vast-training-handoff-1nu49ul", "title": "AGP/N'Ko + Vast Training Handoff", "slug": "agp-nko-vast-training-handoff", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "projects/thunder-train/docs/agp-nko-vast-training-handoff.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "You are continuing the N'Ko ASR training and AGP corrective-adapter program. The goal is not just to run more jobs; the goal is to finish the matched experimental bundle cleanly enough that the papers can make defensible claims about N'Ko script advantage, trajectory conditioning, TAR, and TTT.", "excerpt": "You are continuing the N'Ko ASR training and AGP corrective-adapter program. The goal is not just to run more jobs; the goal is to finish the matched experimental bundle cleanly enough that the papers can make defensible claims about N'Ko script advantage, trajectory conditioning, TAR, and TTT.\n\n1. **Acoustic ASR training on Vast/A100**: PyTorch/Whisper trajectory model family. This is where Paper 4 CER numbers come from. 2. **AGP corrective language layer on Mac4/Mac5**: MLX/Gemma LoRA adapter that proposes N'Ko text repairs after ASR decoding. Rust/Graph Kernel decides whether those repairs are admissible.\n\nDo not merge those into one imagined model unless you explicitly port the ASR stack to MLX. Right now they are separate training/runtime stacks.\n\n- dataset: `290,596` pairs - split: `232,476 / 29,060 / 29,060` - script: N'Ko - mode: trajectory - `use_trajectory=true` - `use_tar=false` - `use_ttt=false` - final/test CER: `20.57%` - best validation: about `0.635887` - best checkpoint epoch: `38` - early stop: epoch `46`\n\nImportant: the filename `train_vastai_tar_ttt.py` is broader than the actual winning mode. The verified 20.57% run did **not** use TAR or TTT.", "htmlHref": "/research/html/agp-nko-vast-training-handoff-1nu49ul.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1383 }, { "id": "pulse-chain-system-living-documentation-yyg3ib", "title": "Pulse Chain System — Living Documentation", "slug": "pulse-chain-system-living-documentation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "PULSE-V1/PULSE_CHAIN_SYSTEM.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A Pulse Chain is a **self-orchestrating multi-agent pipeline** that uses Discord as its execution spine. Work decomposes into **waves** (phases), each wave runs **parallel agents**, and completion of one wave auto-triggers the next.", "excerpt": "> Last updated: 2026-02-16 18:25 EST > Status: Active sprint, Wave 8 in progress | Evo³ running on orchestration layer\n\nA Pulse Chain is a **self-orchestrating multi-agent pipeline** that uses Discord as its execution spine. Work decomposes into **waves** (phases), each wave runs **parallel agents**, and completion of one wave auto-triggers the next.\n\n**Constraint:** Discord allows Category → Channel → Message → Thread. No sub-sub-threads. Deep dives branch into sub-pulses (new threads on new messages within the same channel).\n\n> **Rule: NEVER dispatch a bare `claude -p` prompt. EVER.** > Learned 2026-02-16: Bypassing enrichment to \"save time\" produces inferior output and wastes more time re-doing poor work.\n\n| Script | Path | Version | What It Does | |--------|------|---------|-------------| | `chain-engine.py` | `[home-path]` | v1 (Evo³) | Declarative chain evaluator + state machine + dispatcher | | `wave-watcher.sh` | `[home-path]` | v4 (Evo³) | Cron orchestrator — delegates to chain-engine | | `enriched-dual-dispatch.sh` | `[home-path]` | v2 (Evo³) | Single task → enriched → routes to least-busy Max account | | `parallel-dispatch.sh` | `[home-path]` | v2 (Evo³) | Two tasks → both enriched → account1 + account2 simultaneously | | `enriched_spawn.py` | `[home-path]` | v1 | Prompt builder — injects AGENTS.md, SOUL.md, CLAUDE.md, DEP, skills | | `pulse-health-reporter.sh` | `Desktop/pulse-v1/` | v2 (Evo³) | Health check with chain-engine integration | | `pulse-health-reporter.sh` | `[home-path]` | Health check — agent status, stale detection, capacity |", "htmlHref": "/research/html/pulse-chain-system-living-documentation-yyg3ib.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1845 }, { "id": "self-referential-context-penalization-for-rag-context-gateway-1x9loku", "title": "Self-Referential Context Penalization for RAG++ Context Gateway", "slug": "self-referential-context-penalization-for-rag-context-gateway", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "selfref-penalization-spec.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "That creates a failure mode: - the gateway retrieves chunks that are semantically relevant but already present in the prompt - those chunks consume scarce tokens without adding novelty - when the top results are all self-referential, the gateway amplifies echo instead of expanding the reasoning surface", "excerpt": "## Status - Proposed - Target module: `Desktop/Comp-Core/core/retrieval/cc-rag-plus-plus/rag_plusplus/service/routes/context_gateway.py` - Primary integration point: `_compose_response(...)` inside the Smart Context Gateway\n\n## Problem The current gateway composes Graph Kernel and RAG++ results based on retrieval score and token budget, but it has no awareness of what is already inside the model's active context window.\n\nThat creates a failure mode: - the gateway retrieves chunks that are semantically relevant but already present in the prompt - those chunks consume scarce tokens without adding novelty - when the top results are all self-referential, the gateway amplifies echo instead of expanding the reasoning surface\n\nThis spec adds a self-referential penalization stage so the gateway prefers novel, adjacent context over duplicate context.\n\n## Goals - Detect overlap between the current context window and retrieved RAG++ / GK candidates using hash-based approximate similarity. - Penalize candidates in proportion to overlap ratio instead of hard-dropping everything. - Trigger adjacent semantic expansion when the top-k set is mostly self-referential. - Keep Graph Kernel admissibility rules unchanged. - Integrate cleanly into `context_gateway.py` without introducing a new service boundary.", "htmlHref": "/research/html/self-referential-context-penalization-for-rag-context-gateway-1x9loku.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1974 }, { "id": "serenity-soother-system-glossary-1h7txqe", "title": "Serenity Soother — System Glossary", "slug": "serenity-soother-system-glossary", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "Serenity Soother/SerenitySoother/Documentation/0.1.2-SystemGlossary.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This glossary defines every core term used in the Serenity Soother project. Each definition includes: - **What it is**: Precise definition - **What it is not**: Explicit exclusions to prevent confusion - **Layer**: Where this concept exists (Conceptual, Architectural, Runtime, Data, UI)", "excerpt": "# Serenity Soother — System Glossary **Version:** 1.0.0 **Status:** ACTIVE **Created:** 2025-12-26 **Last Modified:** 2025-12-26\n\nThis glossary defines every core term used in the Serenity Soother project. Each definition includes: - **What it is**: Precise definition - **What it is not**: Explicit exclusions to prevent confusion - **Layer**: Where this concept exists (Conceptual, Architectural, Runtime, Data, UI)\n\n### Scene | Attribute | Value | |-----------|-------| | **What it is** | A complete meditation experience consisting of 30 synchronized segments, each with an image, caption, prompt, and optional audio | | **What it is not** | A single image; a video file; a streaming resource | | **Layer** | Conceptual, Data | | **Swift Type** | `PrecomputedScene` | | **Storage** | Folder in `1792x1024/[index]/` containing subdirectories |\n\n### Segment | Attribute | Value | |-----------|-------| | **What it is** | A single unit within a Scene; contains one image, one caption, one prompt, and optionally one audio track | | **What it is not** | A time-based slice; a frame; an arbitrary division | | **Layer** | Conceptual, Data | | **Swift Type** | `PrecomputedSegment` | | **Storage** | Files at `image/[uuid]/image_N.png`, `caption/[uuid]/caption_N.txt`, `prompt/[uuid]/prompt_N.txt` |\n\n### Session | Attribute | Value | |-----------|-------| | **What it is** | A single playback instance of a Script or Scene, with start time, duration, and completion status | | **What it is not** | A Scene itself; a Script; a user profile | | **Layer** | Data, Runtime | | **Swift Type** | `Session` (SwiftData model) | | **Storage** | SwiftData persistent store |", "htmlHref": "/research/html/serenity-soother-system-glossary-1h7txqe.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1413 }, { "id": "sea-phase-0-minimax-scoring-latency-benchmark-results-12458qg", "title": "SEA Phase 0 — MiniMax Scoring Latency Benchmark Results", "slug": "sea-phase-0-minimax-scoring-latency-benchmark-results", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/phase0-results.md", "extension": "md", "score": 32, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2026-02-17 23:30 (re-run with live endpoint) **Endpoint:** `http://localhost:18080` **Model:** MiniMax-M2.5 (229B params, TQ1_0 GGUF quantization, 55GB) **Server:** llama.cpp (llamacpp) **Prompt Template:** Tier 2 (Skill Activation Judge) **Benchmark Script:** `benchmark_minimax_scoring.py`", "excerpt": "**Date:** 2026-02-17 23:30 (re-run with live endpoint) **Endpoint:** `http://localhost:18080` **Model:** MiniMax-M2.5 (229B params, TQ1_0 GGUF quantization, 55GB) **Server:** llama.cpp (llamacpp) **Prompt Template:** Tier 2 (Skill Activation Judge) **Benchmark Script:** `benchmark_minimax_scoring.py`\n\n> **Note:** The originally spec'd MiniMax-3B-v0.1 has been superseded by MiniMax-M2.5, > a 229B parameter reasoning model. This is significantly more capable but slower than > a 3B model would be. The benchmarks below reflect the actual available hardware.\n\n| Property | Value | |----------|-------| | Model ID | `unsloth_MiniMax-M2.5-GGUF_MiniMax-M2.5-UD-TQ1_0.gguf` | | Parameters | 229B | | Quantization | TQ1_0 (GGUF) | | File size | ~55 GB | | Context window | 196,608 tokens (train) | | Vocab size | 200,064 | | Embedding dim | 3,072 | | Capabilities | completion (with chain-of-thought reasoning) |\n\n20 calls with the full SEA scoring prompt template, capped at 150 tokens to measure raw generation throughput.\n\n| Metric | Value | |--------|-------| | **Min** | **1,341ms** | | **Max** | **2,941ms** | | **Mean** | **1,848ms** | | **Median (P50)** | **1,573ms** | | **P95** | **2,903ms** | | **P99** | **2,934ms** | | **Std Dev** | **508ms** |", "htmlHref": "/research/html/sea-phase-0-minimax-scoring-latency-benchmark-results-12458qg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1832 }, { "id": "pptx-creation-editing-and-analysis-t1cact", "title": "PPTX creation, editing, and analysis", "slug": "pptx-creation-editing-and-analysis", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anthropic-skills/skills/pptx/SKILL.md", "extension": "md", "score": 30, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "A user may ask you to create, edit, or analyze the contents of a .pptx file. A .pptx file is essentially a ZIP archive containing XML files and other resources that you can read or edit. You have different tools and workflows available for different tasks.", "excerpt": "--- name: pptx description: \"Presentation creation, editing, and analysis. When Claude needs to work with presentations (.pptx files) for: (1) Creating new presentations, (2) Modifying or editing content, (3) Working with layouts, (4) Adding comments or speaker notes, or any other presentation tasks\" license: Proprietary. LICENSE.txt has complete terms ---\n\nA user may ask you to create, edit, or analyze the contents of a .pptx file. A .pptx file is essentially a ZIP archive containing XML files and other resources that you can read or edit. You have different tools and workflows available for different tasks.\n\n### Text extraction If you just need to read the text contents of a presentation, you should convert the document to markdown:\n\n### Raw XML access You need raw XML access for: comments, speaker notes, slide layouts, animations, design elements, and complex formatting. For any of these features, you'll need to unpack a presentation and read its raw XML contents.\n\n#### Unpacking a file `python ooxml/scripts/unpack.py `", "htmlHref": "/research/html/pptx-creation-editing-and-analysis-t1cact.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 3487 }, { "id": "skill-creator-14ajtnd", "title": "Skill Creator", "slug": "skill-creator", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anthropic-skills/skills/skill-creator/SKILL.md", "extension": "md", "score": 30, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Skills are modular, self-contained packages that extend Claude's capabilities by providing specialized knowledge, workflows, and tools. Think of them as \"onboarding guides\" for specific domains or tasks—they transform Claude from a general-purpose agent into a specialized agent equipped with procedural knowledge that no model can fully possess.", "excerpt": "--- name: skill-creator description: Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations. license: Complete terms in LICENSE.txt ---\n\nSkills are modular, self-contained packages that extend Claude's capabilities by providing specialized knowledge, workflows, and tools. Think of them as \"onboarding guides\" for specific domains or tasks—they transform Claude from a general-purpose agent into a specialized agent equipped with procedural knowledge that no model can fully possess.\n\n1. Specialized workflows - Multi-step procedures for specific domains 2. Tool integrations - Instructions for working with specific file formats or APIs 3. Domain expertise - Company-specific knowledge, schemas, business logic 4. Bundled resources - Scripts, references, and assets for complex and repetitive tasks\n\nThe context window is a public good. Skills share the context window with everything else Claude needs: system prompt, conversation history, other Skills' metadata, and the actual user request.\n\n**Default assumption: Claude is already very smart.** Only add context Claude doesn't already have. Challenge each piece of information: \"Does Claude really need this explanation?\" and \"Does this paragraph justify its token cost?\"", "htmlHref": "/research/html/skill-creator-14ajtnd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2538 }, { "id": "cc-anticipation-continuation-protocol-h69bmn", "title": "cc-anticipation: Continuation Protocol", "slug": "cc-anticipation-continuation-protocol", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "anticipation-geometry/crates/anticipation/docs/CONTINUATION.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document defines the protocol for continuing work on cc-anticipation across sessions, ensuring consistent context restoration and preventing drift from canonical specifications.", "excerpt": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Parent**: [PROJECT_CHARTER.md](./PROJECT_CHARTER.md)\n\nThis document defines the protocol for continuing work on cc-anticipation across sessions, ensuring consistent context restoration and preventing drift from canonical specifications.\n\n### 1.1 Context Documents (Always Read) 1. **[PROJECT_CHARTER.md](./PROJECT_CHARTER.md)** - Mission, scope, interfaces 2. **[CHECKLIST.md](./CHECKLIST.md)** - Current status, next actions 3. **[INVARIANTS.md](./INVARIANTS.md)** - Non-negotiable properties\n\n### 1.2 Reference Documents (Read as Needed) 4. **[GLOSSARY.md](./GLOSSARY.md)** - Terminology definitions 5. **[IMPLEMENTATION_GUIDE.md](./IMPLEMENTATION_GUIDE.md)** - Code structure, patterns 6. **[Anchor.md](../../../../docs/Anchor.md)** - Canonical specification\n\n### 1.3 Integration Context (Read for Integration Work) 7. **[cc-core-rs/src/lib.rs](../../cc-core-rs/src/lib.rs)** - Available primitives 8. **[rag_plusplus types](../../rag_plusplus/)** - HNSW, OutcomeStats", "htmlHref": "/research/html/cc-anticipation-continuation-protocol-h69bmn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1283 }, { "id": "echelon-integration-plan-bhl76v", "title": "Echelon Integration Plan", "slug": "echelon-integration-plan", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/architecture/echelon_integration.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Status**: 🔮 **Planned Q1-Q2 2026** - This document describes a planned integration with Echelon (Computational Choreography engine).", "excerpt": "**Status**: 🔮 **Planned Q1-Q2 2026** - This document describes a planned integration with Echelon (Computational Choreography engine).\n\n**Current Reality**: The `echelon-bridge` service (`:3005`) is a stub returning mock data. No actual Echelon integration exists yet. This document preserves the architectural vision for future implementation.\n\nThis document outlines how Echelon's embodied dynamics engine will integrate with TrajectoryOS to provide unparalleled life-trajectory intelligence through motion-to-music computational choreography.\n\n| Echelon Signal | Life Variable | Mapping Logic | |---------------|---------------|---------------| | **Flow Score** | Alignment ↑ | High flow in project-related contexts indicates strong alignment | | **Tension** | Gravity ↑ | Sustained high tension suggests increased constraints/load | | **Drift** | Alignment ↓ | Movement drift from expected patterns indicates internal conflict | | **Momentum** | Thrust ↑ | Stable expressive momentum correlates with skill momentum | | **Phase Coherence** | Skill Confidence ↑ | Good phase coupling suggests domain mastery |\n\nEchelon outputs high-frequency signals. The bridge aggregates these into session summaries:", "htmlHref": "/research/html/echelon-integration-plan-bhl76v.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 677 }, { "id": "trajectoryos-architecture-hco4sv", "title": "TrajectoryOS Architecture", "slug": "trajectoryos-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/architecture/overview.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "TrajectoryOS is a life-trajectory modeling system composed of cooperating services that infer your skills, alignment, constraints, and escape velocity through continuous interrogation and artifact analysis.", "excerpt": "TrajectoryOS is a life-trajectory modeling system composed of cooperating services that infer your skills, alignment, constraints, and escape velocity through continuous interrogation and artifact analysis.\n\n1. **Latent State Model**: Your life is represented as a time-series of latent vectors `z_t` from which all observable quantities derive 2. **Bayesian Inference**: Skills and competencies are probabilistic beliefs updated through evidence 3. **Physics-Based Metaphor**: Thrust, Alignment, Gravity, Mass, and Escape Index provide interpretable metrics 4. **Future Embodied Integration**: Designed to consume Echelon's movement dynamics when available\n\n### Layer 1: User Interface - **web-dashboard**: Next.js dashboard for visualizing trajectory, skills, and escape index - **api-gateway**: HTTP REST + WebSocket server for sessions and real-time updates\n\n### Layer 2: Orchestration - **agent-orchestrator**: LLM-driven interview agent and background plan generator - Conducts voice/text interviews - Runs background cognition loops - Resolves contradictions in evidence\n\n### Layer 3: Core Models - **trajectory-core**: Life physics engine (TypeScript/Node) - Maintains latent state `z_t` - Computes skill graph, alignment, gravity, mass, escape index - Emits state change events", "htmlHref": "/research/html/trajectoryos-architecture-hco4sv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 465 }, { "id": "life-physics-model-1izo4eu", "title": "Life Physics Model", "slug": "life-physics-model", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/concepts/life-physics.md", "extension": "md", "score": 30, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "TrajectoryOS models your life as a **dynamical system** with physics-inspired mechanics. Unlike traditional productivity tools that track tasks or goals, we model the underlying forces that determine whether you're stuck in a gravity well or escaping toward freedom.", "excerpt": "**Status**: ✅ **Live** - Core implementation complete and validated in production\n\nTrajectoryOS models your life as a **dynamical system** with physics-inspired mechanics. Unlike traditional productivity tools that track tasks or goals, we model the underlying forces that determine whether you're stuck in a gravity well or escaping toward freedom.\n\nThe escape index tells you whether you're: - **η < 0.7**: **Falling** - Deep in gravity well, falling without active effort - **0.7 ≤ η < 0.9**: **Approaching** - Fighting gravity, making progress but not yet breaking free - **0.9 ≤ η < 1.1**: **Threshold** - At escape velocity threshold; on the edge of self-sustaining trajectory - **1.1 ≤ η < 1.5**: **Escaping** - Beyond escape velocity; trajectory is self-sustaining - **η ≥ 1.5**: **Free** - Well beyond escape velocity; strong upward default trajectory\n\n**Physical Intuition**: Just like a rocket needs to reach escape velocity to leave Earth's gravity, your life needs enough thrust (capability) to overcome gravity (constraints) and mass (inertia) to achieve freedom.\n\n**Implementation**: [/services/trajectory-core/src/domain/physics.ts](../../services/trajectory-core/src/domain/physics.ts#L52-L82)", "htmlHref": "/research/html/life-physics-model-1izo4eu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2047 }, { "id": "documentation-audit-pass-3-consolidation-labeling-qpoj31", "title": "Documentation Audit - Pass 3: Consolidation & Labeling", "slug": "documentation-audit-pass-3-consolidation-labeling", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/DOCUMENTATION_AUDIT_PASS3_COMPLETE.md", "extension": "md", "score": 30, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "**Pass 3 Goal**: Add implementation status markers, create critical missing docs, fix broken references, and standardize language to eliminate confusion between current capabilities and future vision.", "excerpt": "# Documentation Audit - Pass 3: Consolidation & Labeling **Date**: December 21, 2025 **Status**: ✅ Complete\n\n**Pass 3 Goal**: Add implementation status markers, create critical missing docs, fix broken references, and standardize language to eliminate confusion between current capabilities and future vision.\n\n**Key Achievement**: TrajectoryOS documentation now honestly represents reality while preserving the aspirational vision. Users and developers can clearly distinguish what's live, what's in beta, and what's planned.\n\n#### Created: `/docs/concepts/the-interview.md` **Purpose**: Define \"The Interview\" - the most referenced but previously undefined concept in the system\n\n**Content**: - Comprehensive definition of the conversational AI skill discovery flow - Identified as PRIMARY data ingestion mechanism for TrajectoryOS - Architecture breakdown (endpoints, data models, what's missing) - Current status: 20% complete (endpoints exist, LLM integration pending Q1 2026) - Bayesian confidence model explained - Integration with Life Physics (feeds Thrust calculation) - Question strategy (funnel approach) - User experience design", "htmlHref": "/research/html/documentation-audit-pass-3-consolidation-labeling-qpoj31.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2558 }, { "id": "cc-anticipation-continuation-protocol-61thzn", "title": "cc-anticipation: Continuation Protocol", "slug": "cc-anticipation-continuation-protocol", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/motion/cc-anticipation/docs/CONTINUATION.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document defines the protocol for continuing work on cc-anticipation across sessions, ensuring consistent context restoration and preventing drift from canonical specifications.", "excerpt": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Parent**: [PROJECT_CHARTER.md](./PROJECT_CHARTER.md)\n\nThis document defines the protocol for continuing work on cc-anticipation across sessions, ensuring consistent context restoration and preventing drift from canonical specifications.\n\n### 1.1 Context Documents (Always Read) 1. **[PROJECT_CHARTER.md](./PROJECT_CHARTER.md)** - Mission, scope, interfaces 2. **[CHECKLIST.md](./CHECKLIST.md)** - Current status, next actions 3. **[INVARIANTS.md](./INVARIANTS.md)** - Non-negotiable properties\n\n### 1.2 Reference Documents (Read as Needed) 4. **[GLOSSARY.md](./GLOSSARY.md)** - Terminology definitions 5. **[IMPLEMENTATION_GUIDE.md](./IMPLEMENTATION_GUIDE.md)** - Code structure, patterns 6. **[Anchor.md](../../../../docs/Anchor.md)** - Canonical specification\n\n### 1.3 Integration Context (Read for Integration Work) 7. **[cc-core-rs/src/lib.rs](../../cc-core-rs/src/lib.rs)** - Available primitives 8. **[rag_plusplus types](../../rag_plusplus/)** - HNSW, OutcomeStats", "htmlHref": "/research/html/cc-anticipation-continuation-protocol-61thzn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1283 }, { "id": "pulse-protocol-autonomous-loop-architecture-13h663s", "title": "Pulse Protocol — Autonomous Loop Architecture", "slug": "pulse-protocol-autonomous-loop-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/PULSE-PROTOCOL.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> Multi-iteration autonomous development sessions with signal control, context chaining, and evidence-tracked completion.", "excerpt": "> Multi-iteration autonomous development sessions with signal control, context chaining, and evidence-tracked completion.\n\n**Statuses**: pending → running → complete | blocked | failed | aborted | paused\n\n### Inferred Signals (fallback) If no explicit tag, the system infers from output patterns:\n\n| Pattern | Inferred Signal | |---------|----------------| | \"all tasks are complete\", \"implementation is complete\" | COMPLETE | | \"need your input\", \"please provide\", \"cannot proceed\" | BLOCKED | | Code blocks present, \"created file\", \"next step\" | CONTINUE | | No recognizable pattern | BLOCKED (safe default) |\n\n| Priority | Strategy | Source | |----------|----------|--------| | 1 | Chained | Previous iteration's `anchor_hint_next` | | 2 | Explicit | Session's `anchor_turn_id` (set at creation) | | 3 | Semantic | RAG++ query with session goal | | 4 | Temporal | Most recent turn in project |", "htmlHref": "/research/html/pulse-protocol-autonomous-loop-architecture-13h663s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1169 }, { "id": "crp-3-1-figures-and-diagrams-complete-16r081h", "title": "CRP-3.1: Figures and Diagrams — COMPLETE", "slug": "crp-3-1-figures-and-diagrams-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/paper/CRP-3.1-COMPLETE.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Workspace document requiring curation.", "excerpt": "## Summary Created 5 new TikZ/pgfplots figures and added cross-references throughout the paper. All figures compile with pdflatex (no external image files). Total: 6 figures in the paper (1 existing + 5 new).\n\n### 1. Architecture Overview (existing, improved references) - **Label:** `fig:architecture` (already existed) - **Location:** Section 3.1 (System Overview) - **Content:** Query pipeline: parallel retrieval layers → decomposition routing → context assembly → LLM generation\n\n### 2. Performance Comparison Bar Chart (NEW) - **Label:** `fig:perf-comparison` - **Location:** Section 4.2 (Main Results), after Table 3 - **Content:** Grouped bar chart comparing Cog-RLM (3B stock) vs fine-tuned (12B) across all 10 dimensions - **Key visual:** Blue bars at 79-100% vs red bars at 5-20%, showing the 5.4x gap\n\n### 3. Radar/Spider Chart (NEW) - **Label:** `fig:radar` - **Location:** Section 4.2 (Main Results), after bar chart - **Content:** 10-axis radar with two polygons: pass rate (blue, solid) and average score (orange, dashed) - **Key visual:** Gap between pass rate and avg score reveals partial-credit clustering\n\n### 4. Latency Distribution Chart (NEW) - **Label:** `fig:latency` - **Location:** Section 4.3 (RLM Decomposition Analysis), after Table 4 - **Content:** Per-dimension latency bars sorted by response time, with reference lines for selective mean (4.3s) and always-on estimate (8.2s) - **Key visual:** 3x latency gradient from simple recall (2s) to complex generalization (6.8s)", "htmlHref": "/research/html/crp-3-1-figures-and-diagrams-complete-16r081h.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 445 }, { "id": "distributed-mesh-overview-12ilw87", "title": "Distributed Mesh — Overview", "slug": "distributed-mesh-overview", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/06-distributed-mesh/overview.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The system could have been built with a central server: one Mac that all iPhones connect to, coordinating all decisions. That was the original architecture (the multicam-server at `:9404`).", "excerpt": "The system could have been built with a central server: one Mac that all iPhones connect to, coordinating all decisions. That was the original architecture (the multicam-server at `:9404`).\n\nThe distributed architecture replaced it for specific reasons: - **No laptop in the room**: for outdoor shoots, location shoots, and portable setups, there's no Mac. The distributed model makes the system work on any shared WiFi, including a phone hotspot. - **Single points of failure hurt**: if the Mac goes down, the show stops. In the distributed model, each device is self-contained. - **The devices already have everything they need**: iPhones have cameras, microphones, processors, and network stacks powerful enough to run the full pipeline independently. There's no reason to centralize functions they can perform locally. - **Less total code**: the distributed model deletes the dependency on a 13,000-line Rust server (multicam-server) instead of porting it to yet another platform.\n\n**[camera-node-contract.md](camera-node-contract.md)** — The full HTTP + SSE API contract that every camera node (iPhone) must implement: all endpoints, request formats, response formats, error handling, Bonjour advertisement spec.\n\n**[stageview-console.md](stageview-console.md)** — How StageView discovers nodes, manages connections, fans out commands, displays live feeds, and shows the contact sheet. The three discovery paths (Bonjour, mDNS hostname prober, subnet scanner).\n\n**[mesh-topology.md](mesh-topology.md)** — The full device map: every device, its role, its IPs (LAN + Tailscale), what services run on it, and how devices connect to each other.", "htmlHref": "/research/html/distributed-mesh-overview-12ilw87.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 528 }, { "id": "when-ai-can-t-see-your-language-t5qjxp", "title": "When AI Can't See Your Language", "slug": "when-ai-can-t-see-your-language", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "content-pipeline/blog-nko-dead-circuits-accessible.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "In 1949, a man named Solomana Kante sat down in Kankan, Guinea, and did something that most linguists said was impossible.", "excerpt": "In 1949, a man named Solomana Kante sat down in Kankan, Guinea, and did something that most linguists said was impossible.\n\nNot borrowed, not adapted from something else. Built from scratch, character by character, for the Manding languages of West Africa. He did it because someone had made a public claim that African languages were inherently unsuitable for writing. Kante, who was self-taught and spoke seven languages, took that as a challenge.\n\nHe spent years studying the sounds of Bambara, Maninka, and Dioula. He listened to how the languages actually worked. And then he built a writing system perfectly calibrated to them.\n\nEvery sound gets exactly one character. Every character represents exactly one sound. Tones are written out. No exceptions, no weird spelling rules, no silent letters. If you know the script, you know how to pronounce any word. If you can pronounce a word, you can write it.\n\nThe script has over 40 million speakers today. It's used for education, trade, religious texts, personal letters, and signs across Guinea, Mali, Cote d'Ivoire, Senegal, Burkina Faso, and diaspora communities worldwide.", "htmlHref": "/research/html/when-ai-can-t-see-your-language-t5qjxp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2019 }, { "id": "instagram-post-homelab-architecture-v1-mhqzcp", "title": "Instagram Post — HomeLab Architecture v1", "slug": "instagram-post-homelab-architecture-v1", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "content-pipeline/instagram/2026-02-19-homelab-architecture.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "→ Mac1: Control plane, gateway, monitoring → Mac3: K3s, Prefect, Postgres, Graph Kernel → Mac4: Ollama, AI agent workers, Adobe pipeline", "excerpt": "# Instagram Post — HomeLab Architecture v1 *Generated: 2026-02-19 00:05 EST* *Source: Technical Snippet*\n\n## Visual Concept Carousel or diagram showing: 1. Network diagram with 3 Macs connected via Tailscale 2. Screenshot of K9s showing pods running 3. Prefect dashboard with DAG visualization 4. Terminal with kubectl commands 5. Stats overlay: \"46 cron jobs → proper DAGs\"\n\n→ Mac1: Control plane, gateway, monitoring → Mac3: K3s, Prefect, Postgres, Graph Kernel → Mac4: Ollama, AI agent workers, Adobe pipeline\n\n46 cron jobs turned into proper workflow orchestration with dependencies, retries, and actual observability.\n\nWhy? Because running autonomous AI agents requires real infrastructure. They need databases, inference engines, coordination systems, and the ability to fail gracefully.", "htmlHref": "/research/html/instagram-post-homelab-architecture-v1-mhqzcp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 194 }, { "id": "linkedin-post-homelab-architecture-v1-1f9ar2r", "title": "LinkedIn Post — HomeLab Architecture v1", "slug": "linkedin-post-homelab-architecture-v1", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "content-pipeline/linkedin/2026-02-19-homelab-architecture.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Tonight I locked in the architecture for what started as \"a few scripts\" and evolved into a genuine distributed system running across three Mac machines.", "excerpt": "# LinkedIn Post — HomeLab Architecture v1 *Generated: 2026-02-19 00:05 EST* *Source: Technical Snippet*\n\nTonight I locked in the architecture for what started as \"a few scripts\" and evolved into a genuine distributed system running across three Mac machines.\n\n**The Setup:** - **Mac1** (Control Plane): Clawdbot Gateway, kubectl, k9s for cluster management - **Mac3** (Infrastructure Node): K3s, Prefect Server, Postgres, Graph Kernel, RAG++ - **Mac4** (Compute Node): Ollama, Agent Workers, Adobe Creative Pipeline\n\nAll connected via Tailscale mesh network. All orchestrated through Kubernetes. All monitored via Prometheus + Grafana.\n\nI had 46 cron jobs. They worked, mostly. But understanding dependencies? Handling failures? Knowing which ones were running? That was archaeology, not engineering.", "htmlHref": "/research/html/linkedin-post-homelab-architecture-v1-1f9ar2r.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 426 }, { "id": "substack-article-homelab-architecture-v1-lu2oa3", "title": "Substack Article — HomeLab Architecture v1", "slug": "substack-article-homelab-architecture-v1", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "content-pipeline/substack/2026-02-19-homelab-architecture.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "At 11:30 PM on a Tuesday, I drew an ASCII diagram in a Discord channel and realized I wasn't running a collection of scripts anymore. I was running infrastructure.", "excerpt": "# Substack Article — HomeLab Architecture v1 *Generated: 2026-02-19 00:05 EST* *Source: Technical Snippet*\n\nAt 11:30 PM on a Tuesday, I drew an ASCII diagram in a Discord channel and realized I wasn't running a collection of scripts anymore. I was running infrastructure.\n\nThree Mac machines. A Tailscale mesh network connecting them. Kubernetes orchestrating containers. Prefect managing workflows. Prometheus watching everything. And a fleet of AI agents humming along 24/7, doing work while I sleep.\n\nA cron job to check emails. Another to poll a database. One more to trigger an agent. Before I knew it, I had 46 cron jobs scattered across three machines, connected by nothing but hope and SSH.\n\nThe system worked. Mostly. But understanding it was archaeology. Which job depends on which? What happens when one fails? Is that process supposed to be running or did it crash three days ago?", "htmlHref": "/research/html/substack-article-homelab-architecture-v1-lu2oa3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 864 }, { "id": "tiktok-script-homelab-architecture-v1-1qtb9ln", "title": "TikTok Script — HomeLab Architecture v1", "slug": "tiktok-script-homelab-architecture-v1", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "content-pipeline/tiktok/2026-02-19-homelab-architecture.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "\"So I built actual infrastructure: - K3s for container orchestration - Prefect for workflow management - Tailscale connecting all three Macs - Prometheus watching everything", "excerpt": "# TikTok Script — HomeLab Architecture v1 *Generated: 2026-02-19 00:05 EST* *Source: Technical Snippet* *Duration: 40-50 seconds*\n\n\"So I've got these AI agents running 24/7, right? Autonomous. Doing work while I sleep.\n\nBut I was running them on... cron jobs. 46 of them. Spaghetti code held together by vibes.\"\n\n## THE PROBLEM (10 seconds) [Screen recording showing tangled cron job logs or failed processes]\n\n## THE SOLUTION (15 seconds) [Screen showing Prefect dashboard, k9s, Tailscale network diagram]", "htmlHref": "/research/html/tiktok-script-homelab-architecture-v1-1qtb9ln.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 264 }, { "id": "tiktok-patience-is-architecture-afyxvw", "title": "TikTok: Patience Is Architecture", "slug": "tiktok-patience-is-architecture", "kind": "architecture", "program": "Research Backlog", "sourceAnchor": "content-pipeline/tiktok/series/the-bridge/10-patience-is-architecture.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "\"That's not how I learned it. Patience is active. Patience is planting a tree you won't sit under. Building a system that won't pay off for years. Writing in a language the tech world hasn't noticed yet.\"", "excerpt": "# TikTok: Patience Is Architecture **Series:** The Bridge | Episode 10 **Date:** 2026-02-24 **Duration:** ~55 seconds\n\n## HOOK (0-3 sec) **[Direct to camera]** \"Patience isn't waiting. It's building something the world isn't ready for yet.\"\n\n## SETUP (3-15 sec) **[Calm]** \"There's this Western idea that patience is passive. You sit. You wait. Something happens to you. Patience as endurance.\"\n\n\"That's not how I learned it. Patience is active. Patience is planting a tree you won't sit under. Building a system that won't pay off for years. Writing in a language the tech world hasn't noticed yet.\"\n\n## THE DEPTH (15-30 sec) **[More weight]** \"The people who built things that lasted — across any culture — weren't fast. They were patient. They understood that some things need time. Not because you're slow, but because the thing you're building is bigger than any single sprint.\"", "htmlHref": "/research/html/tiktok-patience-is-architecture-afyxvw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 263 }, { "id": "twitter-thread-homelab-architecture-v1-ec2qi8", "title": "Twitter Thread — HomeLab Architecture v1", "slug": "twitter-thread-homelab-architecture-v1", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "content-pipeline/twitter/2026-02-19-homelab-architecture.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Mac1 (Control Plane) ← Tailscale → Mac3 (Infra) ← Tailscale → Mac4 (Compute) Clawdbot GW K3s + Prefect Ollama + Agents kubectl/k9s Graph Kernel Adobe Pipeline", "excerpt": "# Twitter Thread — HomeLab Architecture v1 *Generated: 2026-02-19 00:05 EST* *Source: Technical Snippet*\n\n## Tweet 1 (Hook) Today I designed a production architecture running on 3 Macs connected via Tailscale.\n\nMac1 (Control Plane) ← Tailscale → Mac3 (Infra) ← Tailscale → Mac4 (Compute) Clawdbot GW K3s + Prefect Ollama + Agents kubectl/k9s Graph Kernel Adobe Pipeline\n\nThe solution: Prefect DAGs with proper dependencies, retries, and observability.\n\n\"I run a multi-node K8s cluster on Apple Silicon, orchestrating 46+ Prefect DAG workflows, containerized microservices, and autonomous AI agent dispatch with capacity-aware scheduling.\"", "htmlHref": "/research/html/twitter-thread-homelab-architecture-v1-ec2qi8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 192 }, { "id": "handoff-mac4-unity-takeover-for-codex-sbir6s", "title": "HANDOFF: Mac4 Unity Takeover for Codex", "slug": "handoff-mac4-unity-takeover-for-codex", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "DepthReactiveVisuals/HANDOFF-MAC4-CODEX-UNITY-TAKEOVER.md", "extension": "md", "score": 30, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Date: 2026-04-04 Authoring machine: `[home]` on Mac1 Target machine: Mac4 Primary target project: `[home-path]` on Mac4 Companion reference project: `Desktop/DepthReactiveVisuals/` on Mac1", "excerpt": "Date: 2026-04-04 Authoring machine: `[home]` on Mac1 Target machine: Mac4 Primary target project: `[home-path]` on Mac4 Companion reference project: `Desktop/DepthReactiveVisuals/` on Mac1\n\n1. Open the actual Unity project on Mac4. 2. identify every compile/runtime/configuration problem that Claude Code left behind. 3. fix the errors. 4. clean up the questionable or placeholder work. 5. produce a minimal but real Unity scene that runs.\n\nThis handoff is intentionally more skeptical than the earlier general `HANDOFF.md`.\n\n- The local machine has a partial source bundle at: - `[home]/Desktop/DepthReactiveVisuals/` - That local bundle contains: - `24` C# files - `3` compute shaders - `2` docs - `2` TouchDesigner source files plus the earlier general handoff - The local bundle is **not** a full Unity project: - no `Packages/manifest.json` - local `ProjectSettings/` exists but is empty - no `.unity` scenes - no `.vfx` assets - no `.prefab` assets - no `.asset` assets - no `.asmdef` files - no `.meta` files - Mac4 was **not reachable by SSH** during this handoff pass. - `ssh mac4` timed out. - Therefore this document separates: - `confirmed now` - `claimed previously` - `must verify on Mac4 before trusting`\n\nTreat any statement about the live Mac4 Unity project as untrusted until Codex re-verifies it on Mac4.", "htmlHref": "/research/html/handoff-mac4-unity-takeover-for-codex-sbir6s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2945 }, { "id": "discrawl-spec-7xz07f", "title": "discrawl Spec", "slug": "discrawl-spec", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "discrawl/SPEC.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- build a local-first Discord guild crawler - mirror all guild data the configured bot can access - store it in SQLite - support fast text search, semantic search, and raw SQL - support one-shot backfill and long-running live sync", "excerpt": "- build a local-first Discord guild crawler - mirror all guild data the configured bot can access - store it in SQLite - support fast text search, semantic search, and raw SQL - support one-shot backfill and long-running live sync\n\nThis spec is intentionally detailed so an agent can keep shipping without re-asking foundational questions.\n\n- one guild at a time - all accessible text channels - all accessible announcement channels - all accessible forum channels and their posts - all accessible public threads - all accessible private threads - archived thread coverage - full message history - current member snapshot - FTS5 search - optional OpenAI embeddings with local vector search - raw SQL access\n\n- personal-account DMs - reactions as primary indexed entities - attachment blob downloads by default - cross-guild unified sync UX - write-back or moderation actions\n\n- config format: `TOML` - config location: `[home-path]` - DB location: `[home-path]` - cache dir: `[home-path]` - log dir: `[home-path]` - token source: reuse Molty / existing OpenClaw Discord bot config - guild model: one guild in CLI UX, multi-guild-ready schema - search: hybrid, with FTS first and embeddings optional - embedding provider: OpenAI - API key source: `OPENAI_API_KEY` from shell env - message retention: current canonical row + append-only event log - member retention: current snapshot only - files: metadata only in DB, fetch binaries later on demand - reactions: not important for V1 - polls: flatten into text during normalization", "htmlHref": "/research/html/discrawl-spec-7xz07f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2077 }, { "id": "karl-integration-evolution-stage-1-path-d-1a0ve1o", "title": "KARL Integration — Evolution³ / Stage 1: PATH D", "slug": "karl-integration-evolution-stage-1-path-d", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/karl-trajectory-intelligence/stage1-path-d.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Abandon regex-based skill routing entirely. Embed every skill and every incoming prompt into a shared vector space. When a new prompt arrives, find the nearest skill by **trajectory-weighted similarity** — not raw text overlap. The \"learning\" is not RL on model weights (that is KARL's full treatment). It is RL on the **routing layer itself**. Skills stay as SKILL.md markdown. The only thing that changes is which skill gets injected, and that decision is made by a vector space whose distances are continuously update", "excerpt": "# KARL Integration — Evolution³ / Stage 1: PATH D **Run:** karl-trajectory-intelligence **Path:** D — Skill Embeddings: Learned Vector Space for Routing **Generated:** 2026-03-10 **Status:** Stage 1 complete **Run Directory:** Desktop/evo-cube-output/karl-trajectory-intelligence/\n\nAbandon regex-based skill routing entirely. Embed every skill and every incoming prompt into a shared vector space. When a new prompt arrives, find the nearest skill by **trajectory-weighted similarity** — not raw text overlap. The \"learning\" is not RL on model weights (that is KARL's full treatment). It is RL on the **routing layer itself**. Skills stay as SKILL.md markdown. The only thing that changes is which skill gets injected, and that decision is made by a vector space whose distances are continuously updated by observed trajectory success rates.\n\nThis is \"KARL for routing\" rather than \"KARL for reasoning.\" It replaces the regex `\\b(error|bug|crash)\\b` in `ops_trigger.py` with a learned function that has been shaped by 324 invocation records and counting.\n\nBefore designing the replacement, establish exactly what we are replacing and why it fails.\n\n| Skill | Trigger Pattern | |-------|----------------| | ops:debug | `\\b(error|bug|crash|fix|debug|broken|trace)\\b` | | ops:deploy | `\\b(deploy|restart|systemctl|cloud-vm)\\b.*\\b(flow|service|hub)\\b` | | ops:ios | `\\b(bootstrap|xcodebuild|archive|testflight|ipa|simulator)\\b` | | ops:git | `\\b(commit|push|merge|rebase|cherry-pick)\\b` | | ops:supabase | `\\b(migration|rls|supabase|table|schema)\\b` | | ops:prefect | `\\b(prefect|flow|deployment|schedule)\\b` | | ops:monitoring | `\\b(grafana|prometheus|metric|dashboard|alert)\\b` | | ops:mesh | `\\b(mac[1-5]|mesh|tailscale|sync)\\b.*\\b(status|check|health)\\b` | | ops:docker | `\\b(docker|compose|container|image)\\b.*\\b(build|restart|up|down)\\b` | | ops:asc | `\\b(app store|asc|screenshot|submission|review)\\b` |", "htmlHref": "/research/html/karl-integration-evolution-stage-1-path-d-1a0ve1o.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 5961 }, { "id": "karl-integration-evolution3-stage-2-compound-o86wuk", "title": "KARL Integration -- Evolution3 / Stage 2: COMPOUND", "slug": "karl-integration-evolution3-stage-2-compound", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/karl-trajectory-intelligence/stage2-compound.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Stage 0 established that the Cortex pipeline operates on **prompt text only** (Section 1, core limitation). It has zero visibility into tool sequences, exit codes, file diffs, or task outcomes. All five Stage 1 paths converged on the same foundational requirement: a structured trajectory record that captures what actually happened during a session, not just what the user asked for.", "excerpt": "# KARL Integration -- Evolution3 / Stage 2: COMPOUND **Run:** karl-trajectory-intelligence **Generated:** 2026-03-10 **Method:** Evolution3 -- sequential compounding **Run Directory:** Desktop/evo-cube-output/karl-trajectory-intelligence/\n\nStage 0 established that the Cortex pipeline operates on **prompt text only** (Section 1, core limitation). It has zero visibility into tool sequences, exit codes, file diffs, or task outcomes. All five Stage 1 paths converged on the same foundational requirement: a structured trajectory record that captures what actually happened during a session, not just what the user asked for.\n\nPath A designed the `TrajectoryRecord` schema with 4 tap points in existing hooks. Path B discovered that `verbose-all.jsonl` already contains 3,249 entries with 157 multi-step tool sequences. Path D needs trajectory outcomes to weight its embedding space. Path C needs execution records to compute L4 fitness. Path E needs a place to store solver attempt trajectories. They all need the same thing: a unified trajectory store with outcome annotations.\n\nThe unified data layer merges Path A's live recording with Path B's historical extraction into a single trajectory store at `[home-path]`. Two channels feed it:\n\nFour tap points in existing hooks, exactly as Path A specified: - **Tap A** (`ops_trigger.py`, after line 226): Initialize session buffer when skill is injected. Cost: ~5ms. - **Tap B** (`post_tool_hook.py`, after line 244): Append tool event metadata per tool call. Cost: ~8ms. - **Tap C** (`response_hook.py`, after line 838): Flush session buffer into a TrajectoryRecord at Stop. Cost: ~15ms. - **Tap D** (`ops_trigger.py`, beginning of main()): Annotate the previous record with cross-turn outcome signals at the next UserPromptSubmit. Cost: ~10ms.", "htmlHref": "/research/html/karl-integration-evolution3-stage-2-compound-o86wuk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 7686 }, { "id": "karl-integration-evolution3-stage-3-expand-master-plan-k42d09", "title": "KARL Integration -- Evolution3 / Stage 3: EXPAND + MASTER PLAN", "slug": "karl-integration-evolution3-stage-3-expand-master-plan", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/karl-trajectory-intelligence/stage3-expand-master-plan.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Assumption (from Stage 2) | Reality | Impact | |---|---|---| | unified.jsonl has 3,909 entries with tool_calls arrays | **3,940 entries, but only 3 have populated tool_calls** (all empty arrays) | **CRITICAL**: The unified store does NOT contain usable trajectory data | | verbose-all.jsonl has 3,249 entries, 157 with multi-step tool sequences | **3,258 entries, 157 with tool_calls in assistant_turns** (confirmed) | Correct, but these are 96% Codex entries (`exec_command`, `shell_command`), not Claude Code entries", "excerpt": "# KARL Integration -- Evolution3 / Stage 3: EXPAND + MASTER PLAN **Run:** karl-trajectory-intelligence **Generated:** 2026-03-10 **Method:** Evolution3 -- stress-test and master checklist **Run Directory:** Desktop/evo-cube-output/karl-trajectory-intelligence/\n\nBefore auditing the compound, I verified every data assumption against the live system:\n\n| Assumption (from Stage 2) | Reality | Impact | |---|---|---| | unified.jsonl has 3,909 entries with tool_calls arrays | **3,940 entries, but only 3 have populated tool_calls** (all empty arrays) | **CRITICAL**: The unified store does NOT contain usable trajectory data | | verbose-all.jsonl has 3,249 entries, 157 with multi-step tool sequences | **3,258 entries, 157 with tool_calls in assistant_turns** (confirmed) | Correct, but these are 96% Codex entries (`exec_command`, `shell_command`), not Claude Code entries | | 88 skills, 13 active in registry | **Confirmed: 88 skills, 13 active** | Accurate | | ops_trigger.py is 233 lines | **232 lines** | Accurate | | RAG++ at :8000 reachable | **Confirmed: healthy, returns related_turns + graph_context** | Accurate | | Mac5 MLX :8100 reachable | **Unreachable via direct curl AND via SSH** | **BLOCKER**: Mac5 is offline or unreachable right now | | Mac5 finetune-daemon :9200 | **Unreachable** | Same blocker as above | | numu-weave at [home-path] | **Confirmed: 270 lines** | Accurate | | l4_controller.py exists | **Does not exist** (greenfield) | Expected -- this is what we build | | pulse_bridge.py exists | **981 lines** (much larger than Stage 0's estimate of \"lines 109-123\") | Need to account for actual complexity | | Supabase has 141 tables | **Could not verify** (API key not in env) | Assume accurate per MEMORY.md |\n\n**What holds:** - The two-channel architecture (live tap + historical backfill) is correct. - The JSONL append-only store design is sound for hook latency constraints. - The schema is comprehensive and covers all downstream consumers. - The tap points in ops_trigger.py, post_tool_hook.py, response_hook.py, and session_end_hook.py are identified correctly.\n\n1. **The backfill data is mostly Codex, not Claude Code.** Of 157 entries with tool_calls, the tool names are `exec_command` (1,632), `shell_command` (1,108), `apply_patch` (266). These are Codex tool names. Only 7 entries have `read_file` (Claude Code's equivalent). The backfill extractor assumed these entries represent Claude Code workflows, but they represent Codex workflows. The tool name normalization (`shell_command` -> `Bash`) is technically possible but produces Codex-biased trajectories that may not transfer to Claude Code routing.", "htmlHref": "/research/html/karl-integration-evolution3-stage-3-expand-master-plan-k42d09.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 9715 }, { "id": "homelab-integration-architecture-vwnncu", "title": "Homelab Integration Architecture", "slug": "homelab-integration-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/ARCHITECTURE-GEMINI.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "This document maps the full integration architecture of the homelab project, detailing how components like Codex, Clawdbot, Pulse, and Noosphere connect to form an autonomous development and communication ecosystem.", "excerpt": "This document maps the full integration architecture of the homelab project, detailing how components like Codex, Clawdbot, Pulse, and Noosphere connect to form an autonomous development and communication ecosystem.\n\nThe homelab is structured into three primary layers: 1. **Orchestration & Dispatch (Codex)**: Manages tasks, queues, and agent routing. 2. **Communication & Gateway (Clawdbot)**: Bridges human interfaces (Discord, Telegram) with system actions. 3. **Execution & Intelligence (Pulse, Claude Code, Noosphere)**: Performs the actual development work and maintains project context.\n\n### 1. Codex (Orchestrator) - **Role**: Global task queue and agent dispatcher. - **Tech**: Node.js, Express, Supabase. - **Integration**: - Receives GitHub webhooks (pushes, PRs). - Manages a task queue in Supabase. - Dispatches tasks to agents (`dual-max`, `pulse`, `clawdbot-session`) via the `Dispatcher`. - Enriches prompts with project context from the Orbit intelligence layer.\n\n### 2. Clawdbot (Gateway) - **Role**: The central communication hub and command router. - **Tech**: Node.js, CLI-first architecture. - **Integration**: - Bridges multiple chat platforms (Discord, Telegram, iMessage). - Provides a CLI (`clawdbot message send`) used by other services for notifications. - Manages \"Skills\" (specialized agents) and spawns autonomous sessions. - Maintains a local message log and SQLite memory database (`kimi_memory.db`).\n\n### 3. Pulse (Autonomous Development) - **Role**: Autonomous agent focused on git-based development tasks. - **Tech**: Node.js, MCP (Model Context Protocol). - **Integration**: - Exposed as an MCP server for Claude Desktop. - Handles the full dev lifecycle: branching, coding, committing, and creating PRs. - Triggered by Codex for automated task fulfillment.", "htmlHref": "/research/html/homelab-integration-architecture-vwnncu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 685 }, { "id": "message-orchestrator-v1-hybrid-routing-intelligence-txv76n", "title": "Message Orchestrator v1 — Hybrid Routing Intelligence", "slug": "message-orchestrator-v1-hybrid-routing-intelligence", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/message-orchestrator/SKILL.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> _\"Every message is a signal. Some are commands, some are dreams, some are the start of something bigger. This skill listens to all of them.\"_", "excerpt": "--- name: message-orchestrator description: Hybrid config + LLM-driven message routing. Intercepts all messages, enriches via prompt-synthesizer, extracts dream seeds, detects skill chains, and routes actionable tasks. homepage: https://github.com/clawdbot/message-orchestrator user-invocable: true pre-hook: true hook-priority: 50 command-dispatch: orchestrate handler: orchestrator.MessageOrchestrator metadata.clawdbot: {\"pre_hook\": true, \"transforms_input\": true, \"routing\": true, \"version\": \"1.0.0\"} ---\n\n> _\"Every message is a signal. Some are commands, some are dreams, some are the start of something bigger. This skill listens to all of them.\"_\n\nMessage Orchestrator sits at the heart of the Clawdbot message pipeline, intercepting every input and making intelligent routing decisions. It combines **config-driven rules** (fast, predictable) with **LLM orchestration** (flexible, semantic).\n\n**Hybrid Intelligence:** - **Config Layer:** Fast pattern matching, predefined chains, zero-latency routing - **LLM Layer:** Semantic understanding, ambiguous cases, chain synthesis\n\n**No Message Left Behind:** - Every message gets at least prompt enrichment - Dream seeds are captured even from casual conversation - Skill chains execute automatically when patterns match", "htmlHref": "/research/html/message-orchestrator-v1-hybrid-routing-intelligence-txv76n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1274 }, { "id": "uncertainty-embracer-152y393", "title": "Uncertainty Embracer", "slug": "uncertainty-embracer", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/uncertainty-embracer/SKILL.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Activate when: - Questions have no clear answer - Multiple valid interpretations exist - Predictions are requested about uncertain futures - User seems frustrated by ambiguity - Decision paralysis from too many unknowns", "excerpt": "Activate when: - Questions have no clear answer - Multiple valid interpretations exist - Predictions are requested about uncertain futures - User seems frustrated by ambiguity - Decision paralysis from too many unknowns\n\n> *\"The wise person knows the limits of their knowledge. The confident wise person shares those limits as useful information.\"*\n\nUncertainty isn't a bug—it's information. Instead of pretending to know or refusing to engage, the Uncertainty Embracer treats ambiguity as a landscape to map, not a void to fear.\n\nTraditional AI fails in two ways: 1. **Overconfident** — Hallucinated certainty on uncertain topics 2. **Underconfident** — \"I can't answer that\" when partial answers are valuable\n\nThe Uncertainty Embracer finds the third way: **confident uncertainty**. It means speaking clearly about what we don't know.", "htmlHref": "/research/html/uncertainty-embracer-152y393.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 5296 }, { "id": "architecture-spine-1vi4b5h", "title": "Architecture Spine", "slug": "architecture-spine", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "Leisure/strategy/03-architecture-spine.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` Leisure(t) = (Captain ⊕ Workers ⊕ Sensors) ↦ Phone │ governed by EW invariants │ surfaced through │ ControlOps · DataStreams · Notifications · Widgets · Voice · DeepLinks ```", "excerpt": "> Leisure is the state where the home Macs hold the project memory, the home Macs do the work, and the iPhone is the cockpit. Confirmations are cheap, intervention is rare, and the system has a fallback for every degraded path.\n\n| # | Archetype | Plane | Failure mode | Examples | |---|---|---|---|---| | 1 | **ControlOp** | Control | Throw loudly, never silently retry | send-prompt, /inject, restart-service, switch-chat | | 2 | **DataStream** | Data | Silent retry, banner only when stale | pane snapshot polling, /response endpoints | | 3 | **CaptainSummary** | Bridge | Always falls back to gateway heuristic | /captain/ask, next-prompt drafts | | 4 | **SensorStream** | Data | Drop frames on backpressure | KARL trajectories, idle-detection state machine | | 5 | **AutopilotAgent** | Bridge | Pause on first failure, never silent loop | Captain → Codex auto-queue, Pulse sessions | | 6 | **WidgetGlance** | Projection | Read-only, schema-checked, ≤120 char previews | Home Screen widget, MeshHealth tile | | 7 | **VoiceDictation** | Control | Always editable before send | Pebble Whisper composer, future Siri intents |\n\nEach row is a phone affordance mapped to a mesh capability. If a row is missing, the leisure OS has a hole.\n\n| Phone affordance | Archetype | Mesh endpoint | Fallback | |---|---|---|---| | Tap row | DeepLinkJump | NavigationSplitView selection | Empty-detail placeholder | | Send text | ControlOp | /codex/inject or /inject | 503 banner → \"send to active\" | | Voice dictation | VoiceDictation | Local Whisper → composer | Manual edit always available | | Heart icon | CaptainSummary | /captain/ask | Local-heuristic fallback | | Magic wand cue | CaptainSummary→ControlOp | Captain drafts; user sends | Any reachable pane | | Autopilot toggle | AutopilotAgent | Background loop | Pause + banner on failure | | Widget tap | DeepLinkJump | pebble://voice quick-send | Cold-launch emptyDetail | | Widget row tap | DeepLinkJump | pebble://chat/ | Sidebar selection | | Push notification | NotificationTrigger | ntfy idle-watcher | Batched on next foreground |\n\n> See also: [`../measurement/02-ew-invariants.md`](../measurement/02-ew-invariants.md) for the five invariants that govern this system. [`../archive/track-4-architecture.md`](../archive/track-4-architecture.md) for the full architecture forge including anti-patterns.", "htmlHref": "/research/html/architecture-spine-1vi4b5h.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 440 }, { "id": "sales-agent-architecture-v1-through-v2-157f508", "title": "Sales Agent Architecture — V1 through V2", "slug": "sales-agent-architecture-v1-through-v2", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "milkmendelivery/docs/SALES-AGENT-ARCHITECTURE.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The Market Sweep Agent is an automated sales pipeline that discovers coffee shops across US markets, enriches contact information, generates AI-personalized emails, and tracks responses — all from a single dashboard.", "excerpt": "The Market Sweep Agent is an automated sales pipeline that discovers coffee shops across US markets, enriches contact information, generates AI-personalized emails, and tracks responses — all from a single dashboard.\n\n| Function | Purpose | API Used | Cost | |----------|---------|----------|------| | `market-sweep-search` | SerpAPI multi-query discovery | SerpAPI | ~$1.60/city | | `market-sweep-enrich` | Website scraping: emails, IG, snippet, vibe | None | $0 | | `market-sweep-import` | Promote prospects to CRM leads + create accounts | None | $0 | | `market-sweep-ai-generate` | GPT-4o-mini personalized email generation | OpenAI | ~$0.002/email | | `market-sweep-email` | Send via Resend, prefer AI content, A/B variants | Resend | Free tier | | `market-sweep-followup` | Follow-up sequences (max 2 per prospect) | Resend | Free tier | | `market-sweep-classify` | GPT-4o-mini response classification | OpenAI | ~$0.001/classify | | `background-sweep` | Google Maps Places continuous market discovery | Google Maps | Usage-based |\n\n- **`market_sweeps`** — Tracks each city sweep operation with status progression - **`sweep_prospects`** — Staging table for discovered cafes before lead import - **`inbound_leads`** — CRM leads with zone classification and pipeline tracking - **`email_outreach`** — Email send logs with sweep linking\n\n- **`accounts`** — Business entities with place_id dedup, Google Maps data, vibe, stage tracking - **`locations`** — Physical addresses linked to accounts (multi-location support) - **`account_contacts`** — Multiple contacts per business with role classification - **`sweep_queue`** — Background sweep rotation through 22 markets\n\n| Column | Type | Purpose | |--------|------|---------| | `ai_subject` | text | GPT-4o-mini generated subject line | | `ai_body` | text | GPT-4o-mini generated email body | | `subject_variants` | jsonb | 3 A/B subject line variants | | `selected_variant` | int | Which variant was sent | | `ai_generation_model` | text | Model identifier (gpt-4o-mini) | | `cafe_vibe` | text | hipster/minimalist/brunch-heavy/craft-focused/neighborhood | | `website_snippet` | text | First 500 chars of website for AI context | | `response_type` | text | interested/not_now/unsubscribe/wrong_contact | | `qualification_tier` | text | hot/warm/cold based on response | | `account_id` | uuid | Link to accounts table |", "htmlHref": "/research/html/sales-agent-architecture-v1-through-v2-157f508.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 795 }, { "id": "motion-lexicon-motionmix-visual-language-architecture-ndu7pq", "title": "Motion Lexicon — MotionMix Visual Language Architecture", "slug": "motion-lexicon-motionmix-visual-language-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/MOTION-LEXICON.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| Output | Gesture Layer | Emotion Layer | Temporal Layer | Ratio Layer | |--------|--------------|---------------|----------------|-------------| | Particles (browser) | Preset swap | Color + bloom | Lerp transitions | Attractor positions | | TouchDesigner (Mac2) | Scene switch | Color palette | Cross-fade timing | CHOP parameters | | Remotion (React) | Composition swap | Theme props | Sequence timing | Transform params | | Adobe Premiere (Mac4) | Clip selection | LUT/grade | Transition duration | Crop/scale |", "excerpt": "> Forged via Creative Forge (syn:core + art:divergent + art:convergent + art:synthesis + art:creative)\n\n## Core Metaphor The body is a musical instrument playing light. Each joint is a string, each gesture is a chord, each session is a composition.\n\n### Layer 1: Gesture Vocabulary (20 named signatures) | Gesture | Motion Pattern | Visual Identity | |---------|---------------|-----------------| | The Reach | Arms extending outward | Aurora curtains stretching | | The Drop | Sudden squat/crouch | Beat Drop explosion, particles scatter | | The Flow | Continuous smooth motion | Ink dissolution, liquid trails | | The Pulse | Rhythmic bounce | Plasma rings pulsing with beat | | The Freeze | Sudden stillness | Crystal formation, geometric snap | | The Spiral | Torso rotation | Fibonacci spiral tightening | | The Wave | Sequential joint movement | Ocean caustics propagating | | The Burst | Explosive arm throw | Ember Storm, fire particles | | The Sway | Gentle hip oscillation | Nebula drift, slow cloud movement | | The Shield | Arms crossed/compact | Void Pulse, inward energy | | The Crown | Arms raised overhead | Neon Rain falling from above | | The Ground | Low stance, floor work | Mycelium tendrils spreading | | The Snap | Sharp isolated movement | Cyber grid flash, digital glitch | | The Breath | Chest expansion/contraction | Deep Breath, particle scale pulse | | The Mirror | Symmetrical arm movement | Aurora Frost, bilateral symmetry | | The Storm | Fast chaotic movement | Ember Storm + lightning composite | | The Bloom | Opening from compact | Sakura Fall, petals unfurling | | The Fade | Decreasing energy | Snowfall, gentle settling | | The Rise | Building intensity | Golden Spiral, expanding warmth | | The Release | Post-peak relaxation | Cosmic Dust, dissipating glow |\n\n### Layer 2: Emotion Mapping (replaces genre mapping) | Emotion | Energy Range | Color Temperature | Bloom | Speed | Preset Category | |---------|-------------|-------------------|-------|-------|-----------------| | Joy | 0.5-0.8 | Warm gold-orange | 1.8 | 1.2 | ambient/organic | | Intensity | 0.8-1.0 | Hot red-white | 2.5 | 1.5+ | explosive | | Calm | 0.0-0.2 | Cool blue-violet | 2.0 | 0.3 | calm | | Tension | 0.3-0.6 rising | Sharp green-cyan | 1.5 | 0.8 | geometric | | Release | 0.6-0.3 falling | Soft pink-lavender | 1.2 | 0.5 | atmospheric |\n\n### Layer 3: Temporal Dynamics - **Echo Delay**: 2-second motion echo creates visual counterpoint - **Stillness Crystallization**: After 3s of stillness, particles snap to geometric lattice - **Transition Morphing**: Style changes lerp over 1.5 seconds, never instant cut - **Anticipation**: Rehearsal engine predicts 2s ahead via :9406 bridge, pre-loads next style - **Memory**: The system remembers your last 10 gestures and weights the visual", "htmlHref": "/research/html/motion-lexicon-motionmix-visual-language-architecture-ndu7pq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 669 }, { "id": "current-system-yeo9iu", "title": "Current System", "slug": "current-system", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "MotionMix/research/computational-choreography-nko-2026-05-27/02-architecture/current-system.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "- Runs Rekordbox. - Runs Pose Coach / camera viewer. - Runs AirDeck bridge. - Owns keyboard/MIDI dispatch. - Owns the final safety gate. - Can work from camera pose without Sony sensors.", "excerpt": "- Runs Rekordbox. - Runs Pose Coach / camera viewer. - Runs AirDeck bridge. - Owns keyboard/MIDI dispatch. - Owns the final safety gate. - Can work from camera pose without Sony sensors.\n\n- Runs Unity/DYK. - Receives Sony mocopi when sensors are on. - Feeds Unity locally. - May post mocopi state to MotionMix.\n\n- Has recording/session infrastructure. - Has BodyTruth contract direction. - Has SensorLogger and iPhone-related data lanes. - Should become the place where movement datasets are structured and queryable.\n\nDo not let Mac4, Unity, mocopi, or raw sensors send Rekordbox commands directly. They may visualize, record, or advise. K11 decides.\n\nMocopi must not be treated as required. If hand raise works with the camera, then camera-first AirDeck is valid. The full gesture library should be built around camera pose and then enhanced with optional sensors.", "htmlHref": "/research/html/current-system-yeo9iu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 212 }, { "id": "prompt-guide-1wdk4h4", "title": "Prompt Guide", "slug": "prompt-guide", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/stable-audio-3/docs/guides/prompting.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This guide provides tips and tricks for getting the most out of your prompts, and helps you break out of prompt \"writer's block.\" Prompting is more of an art than a science, but there are some best practices we've discovered. This is just a starting point, be creative and go crazy (perhaps share in our [Harmonai Discord](https://discord.gg/cKpvjey8b))!", "excerpt": "This guide provides tips and tricks for getting the most out of your prompts, and helps you break out of prompt \"writer's block.\" Prompting is more of an art than a science, but there are some best practices we've discovered. This is just a starting point, be creative and go crazy (perhaps share in our [Harmonai Discord](https://discord.gg/cKpvjey8b))!\n\n- **Music** — full instrumental tracks, ambient audio - **Stems & Solo Instruments** — isolated parts or single-instrument pieces - **Audio Samples & SFX** — sound effects, samples, and one-shots - **Init Audio, Inpainting & Continuation** — modify or extend existing audio using a seed file\n\n| Model | Music | Stems/Solo | Samples/SFX | |-------|-------|------------|-------------| | `medium` | ✓ | ✓ | ✓ | | `small-music` | ✓ | ✓ | — | | `small-sfx` | — | — | ✓ |\n\nFor additional tips, visit the [Stable Audio User Guide](https://stability.ai/stable-audio).\n\n- **Think about the training datasets.** Prompt adherence and audio quality are closely linked with the dataset the model was trained on. Stable Audio 3 uses audio from Freesound and AudioSparx along with their metadata. Prompts that align with that kind of text and audio tend to produce the best results, though out-of-distribution prompts can be interesting to explore. - **Set a realistic duration.** While our models can generate up to 6m 20s (`medium`) or 2m (`small`), results tend to be better when you choose a duration that fits what you're describing. - **Embrace the randomness.** The model won't output the same thing twice. If you want a reproducible result, set a seed (in Gradio, this is under `Sampler Params`).", "htmlHref": "/research/html/prompt-guide-1wdk4h4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1605 }, { "id": "when-ai-can-t-see-your-language-euhh2q", "title": "When AI Can't See Your Language", "slug": "when-ai-can-t-see-your-language", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/posts/04-when-ai-cant-see-your-language.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "In 1949, a man named Solomana Kante sat down in Kankan, Guinea, and did something that most linguists said was impossible.", "excerpt": "In 1949, a man named Solomana Kante sat down in Kankan, Guinea, and did something that most linguists said was impossible.\n\nNot borrowed, not adapted from something else. Built from scratch, character by character, for the Manding languages of West Africa. He did it because someone had made a public claim that African languages were inherently unsuitable for writing. Kante, who was self-taught and spoke seven languages, took that as a challenge.\n\nHe spent years studying the sounds of Bambara, Maninka, and Dioula. He listened to how the languages actually worked. And then he built a writing system perfectly calibrated to them.\n\nEvery sound gets exactly one character. Every character represents exactly one sound. Tones are written out. No exceptions, no weird spelling rules, no silent letters. If you know the script, you know how to pronounce any word. If you can pronounce a word, you can write it.\n\nThe script has over 40 million speakers today. It's used for education, trade, religious texts, personal letters, and signs across Guinea, Mali, Cote d'Ivoire, Senegal, Burkina Faso, and diaspora communities worldwide.", "htmlHref": "/research/html/when-ai-can-t-see-your-language-euhh2q.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2019 }, { "id": "the-script-machines-can-t-read-1ryle2t", "title": "The Script Machines Can't Read", "slug": "the-script-machines-can-t-read", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/substack/01-the-script-machines-cant-read.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "I brain-scanned three AI models. All of them are blind to my family's writing system. Here's what I found, why it matters, and what I built to fix it.", "excerpt": "I brain-scanned three AI models. All of them are blind to my family's writing system. Here's what I found, why it matters, and what I built to fix it.\n\nMy family speaks Manding. Bambara, Maninka, depending on which side and which country. Over 40 million people speak these languages across West Africa. Guinea, Mali, Cote d'Ivoire, Senegal, Burkina Faso, The Gambia, and diaspora communities everywhere.\n\nIn 1949, a man named Solomana Kante sat down in Kankan, Guinea, and designed a writing system for us. Not borrowed from Arabic, not adapted from French colonial Latin. Built from scratch. Character by character.\n\nKante made one rule that no other major writing system follows: every sound gets exactly one character. Every character represents exactly one sound. No exceptions. No silent letters. No \"ough\" that could be pronounced six different ways. Tone is marked explicitly. If you can hear it, you can write it. If you can see it, you can say it.\n\nThat was 77 years ago. Today, N'Ko has its own Unicode block, its own Wikipedia (6,000+ articles), its own keyboard apps, and millions of literate users.", "htmlHref": "/research/html/the-script-machines-can-t-read-1ryle2t.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1646 }, { "id": "nko-research-papers-1mcigk6", "title": "N'Ko Research Papers", "slug": "nko-research-papers", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/README.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The public closeout series now lives under `final/`. Each paper has its own folder with a local `paper.tex`, compiled `paper.pdf`, `references.bib`, `paper.bbl`, and relative `figures/` assets, so each manuscript can compile from its own directory.", "excerpt": "The public closeout series now lives under `final/`. Each paper has its own folder with a local `paper.tex`, compiled `paper.pdf`, `references.bib`, `paper.bbl`, and relative `figures/` assets, so each manuscript can compile from its own directory.\n\n| # | Paper | Folder | PDF pages | Role | |---|-------|--------|-----------|------| | 1 | Dead Circuits: Script Invisibility and Representation Failure for N'Ko in Large Language Models | `final/01-script-invisibility/` | 11 | Establishes the LLM representation failure with research questions, falsification criteria, evidence ladder, tokenizer-burden formalism, evidence artifact contract, remediation agenda, reviewer checklist, and validity threats. | | 2 | Against WER: Phonemic Evaluation, Orthographic Transparency, and the Script Advantage for Manding ASR | `final/02-phonemic-evaluation/` | 10 | Formalizes the metric problem, N'Ko-vs-Latin script advantage, transparent-script edit preservation, normalization protocol, CER/PER proxy boundary, metric failure taxonomy, and matched-evaluation requirements. | | 3 | Script-Native ASR for N'Ko: Anticipatory Transformer CTC Decoding and the 20.57% CER Anchor | `final/03-script-native-asr-anchor/` | 12 | Preserves the technical ASR anchor with architecture, trajectory-state math, corpus split, 20.57% CER arithmetic, hashes, allowed/disallowed claims, provenance notes, artifact contract, operational lessons, and model-card boundaries. | | 4 | Anticipation Geometry Partition: Row-Level Governance for Script-Native N'Ko ASR Deployment | `final/04-agp-deployment/` | 12 | Defines AGP as the post-ASR correction/provenance/deployment governance layer with system boundaries, pipeline formalization, row contracts, partition scoring, correction benchmark design, failure taxonomy, human review, data lifecycle, Djoko substrate, and ExpF/ExpH evidence. |\n\nRecommended public narrative: use the four papers as the final publishable bundle and treat `current/paper_canonical_nko_agp_20cer.tex` as the synthesis manuscript that explains how the four papers connect. The 20.57% CER should be described as an archived N'Ko trajectory ASR checkpoint under recorded settings, not as a universal matched proof against Latin.\n\nThe readable public companion lives in `blog-series/`. It inherits the stronger voice from the original `blog/posts/` drafts: historical opening, experiment chronology, concrete numbers, and plain-English explanations before acronyms. Start with `blog-series/00-field-guide-to-the-claim.md`, then publish the four essays in order.\n\n| # | Paper | File | Status | Pages | |---|-------|------|--------|-------| | 1 | Dead Circuits: Activation Profiling and Script Invisibility in LLMs | `current/paper1_dead_circuits.tex` | Draft complete | ~20 | | 2 | Living Speech: Script-Nat", "htmlHref": "/research/html/nko-research-papers-1mcigk6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 704 }, { "id": "stage-4-forge-enhanced-cc-architecture-production-grade-h6gb23", "title": "Stage 4: FORGE — Enhanced CC Architecture (Production-Grade)", "slug": "stage-4-forge-enhanced-cc-architecture-production-grade", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "omega-output/cc-7layer-enhancement-20260323/04-architecture-enhanced.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Day 1-2: B (single phone works) + D (sound upgrade) + E (training starts) Day 3-5: A (Mocopi + Direct Trigger) Week 2: C (multi-cam content pipeline) Month 2: F (live performance) ```", "excerpt": "### Current: Camera crop mask works. ### Enhanced: - **Posture validation**: After calibration confirm, run 3-second check — if chest not centered (Vision BodyPose shoulders not within center 60%), re-prompt. - **Distance estimation**: Use shoulder width in pixels to estimate camera distance. If too far (shoulders < 20% of frame) or too close (> 60%), show \"STEP CLOSER\" / \"STEP BACK\". - **Session memory**: Save calibration crop values to UserDefaults. Next session pre-loads your last good position.\n\n**Deliverable**: Update calibration flow in PerformView.swift (iOS) and index.html (web).\n\n**Priority 1: Verify Mocopi hardware** (2 hours) - Pair 6 sensors with iPhone 3 (Motionlink) - Verify UDP packets reach Mac1 on :12351 - Check mocopi-bridge.py parses real data correctly - Document actual bone data format (may differ from spec)\n\n**Priority 2: Unified sensor format** - All sensors write to capture server in the SAME JSON schema:\n\n**Priority 3: Watch companion app** - Defer. Watch WCSession code exists in SensorService but no Watch target. - Low priority — wrist IMU from Mocopi is higher quality.", "htmlHref": "/research/html/stage-4-forge-enhanced-cc-architecture-production-grade-h6gb23.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1502 }, { "id": "discrawl-spec-16q5esm", "title": "discrawl Spec", "slug": "discrawl-spec", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/discrawl/SPEC.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- build a local-first Discord guild crawler - mirror all guild data the configured bot can access - store it in SQLite - support fast text search, semantic search, and raw SQL - support one-shot backfill and long-running live sync", "excerpt": "- build a local-first Discord guild crawler - mirror all guild data the configured bot can access - store it in SQLite - support fast text search, semantic search, and raw SQL - support one-shot backfill and long-running live sync\n\nThis spec is intentionally detailed so an agent can keep shipping without re-asking foundational questions.\n\n- one guild at a time - all accessible text channels - all accessible announcement channels - all accessible forum channels and their posts - all accessible public threads - all accessible private threads - archived thread coverage - full message history - current member snapshot - FTS5 search - optional OpenAI embeddings with local vector search - raw SQL access\n\n- personal-account DMs - reactions as primary indexed entities - attachment blob downloads by default - cross-guild unified sync UX - write-back or moderation actions\n\n- config format: `TOML` - config location: `[home-path]` - DB location: `[home-path]` - cache dir: `[home-path]` - log dir: `[home-path]` - token source: reuse Molty / existing OpenClaw Discord bot config - guild model: one guild in CLI UX, multi-guild-ready schema - search: hybrid, with FTS first and embeddings optional - embedding provider: OpenAI - API key source: `OPENAI_API_KEY` from shell env - message retention: current canonical row + append-only event log - member retention: current snapshot only - files: metadata only in DB, fetch binaries later on demand - reactions: not important for V1 - polls: flatten into text during normalization", "htmlHref": "/research/html/discrawl-spec-16q5esm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2077 }, { "id": "mapping-system-update-complete-guide-aipzx1", "title": "Mapping System Update - Complete Guide", "slug": "mapping-system-update-complete-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/MAPPING_UPDATE_GUIDE.md", "extension": "md", "score": 30, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "The Rekordbox voice control system has been updated with comprehensive command mappings from the full Rekordbox keyboard shortcut catalog. This update includes **450 commands** covering all major DJ operations across both decks.", "excerpt": "The Rekordbox voice control system has been updated with comprehensive command mappings from the full Rekordbox keyboard shortcut catalog. This update includes **450 commands** covering all major DJ operations across both decks.\n\n**Before:** - ~60 commands manually curated - Basic transport, loop, and hotcue operations - Limited coverage of Rekordbox features\n\n**After:** - **450 commands** from full Rekordbox mapping - **227 Deck 1 commands** (30xx command IDs) - **223 Deck 2 commands** (31xx command IDs) - Complete coverage of: - Transport (play, pause, cue, slip reverse) - Loops (1/2, 1, 2, 4, 8 beat loops + manual loop controls) - Hot Cues (A, B, C, D + clear operations) - Sync & Tempo (beat sync, master tempo, pitch bend, tempo adjust) - Effects (FX slots, parameters) - Mixer (crossfader, EQ, filters) - Library (load tracks, search, playlists) - Sampler (12 slots, playback, pause, sequences) - Grid & Beat (memory cues, beatgrid editing) - Layout (zoom, panels, views) - Recording (start/stop/pause)\n\n**Updated Files:** - `gemini_listener.py` - Original Gemini Live listener - `gemini_listener_enhanced.py` - Enhanced listener with Tier 1 optimizations\n\n**New Instruction Features:** - Organized by category (Transport, Loop, Hot Cue, Sync/Tempo, etc.) - Comprehensive examples for each category - Clear deck specification (left/right) - Voice-friendly command phrasing - Batch command support (enhanced version only) - Confirmation/cancellation keywords", "htmlHref": "/research/html/mapping-system-update-complete-guide-aipzx1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2417 }, { "id": "echeloncapture-current-state-vs-vision-1wpyqz0", "title": "EchelonCapture: Current State vs. Vision", "slug": "echeloncapture-current-state-vs-vision", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/06-status/ECHELON_CAPTURE_VISION.md", "extension": "md", "score": 30, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**EchelonCapture is currently a sensor data streaming & recording app.** **It needs to become the visual performance dashboard for Computational Choreography.**", "excerpt": "**EchelonCapture is currently a sensor data streaming & recording app.** **It needs to become the visual performance dashboard for Computational Choreography.**\n\nBased on your performance loop diagram and UI vision documents, EchelonCapture should be **the real-time visual manifestation of the entire CC system** - showing the dancer what the machine sees, what it's generating, and where the performance is going.\n\nIt should display: 1. **Latent Orb** - Living visualization of LIM-RPS equilibrium (the machine's perception of you) 2. **Phrase Spine** - Current generative phrase as topological object 3. **Generative Horizon** - Predicted future latent states (what's coming) 4. **Phrase Reservoir** - Cloud of upcoming musical possibilities 5. **Embodied Control Band** - Real-time modulation parameters (tension, grounding, etc.) 6. **Somatic Timeline** - Compressed history of latent evolution 7. **Audio Vessel** - Musical form visualization 8. **Ambient Aura** - Global performance state atmosphere\n\n### Current Tabs: 1. **Stream** - Connect to cc-mcs-headless, stream sensor data, view FPS/latency 2. **Record** - Save sensor sessions locally 3. **Sensors** - Configure which sensors are active 4. **Sessions** - Browse saved recordings 5. **Settings** - Backend URL, device role, debug mode\n\n### Current Visualization: - ❌ No latent visualization - ❌ No music/phrase visualization - ❌ No generative prediction display - ✅ Raw sensor debug view (accel, gyro, attitude) - ✅ Motion energy meter (simple) - ✅ Network stats (FPS, latency)", "htmlHref": "/research/html/echeloncapture-current-state-vs-vision-1wpyqz0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1621 }, { "id": "architecture-idea-vault-gen-7-1qwzm3q", "title": "Architecture: Idea Vault (Gen 7)", "slug": "architecture-idea-vault-gen-7", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/hef-evolutions/trajectory-mobile-sync-add-idea-vault-to-trajector/architecture.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Workspace document requiring curation.", "excerpt": "## Overview The Idea Vault is a local-first mobile extension for the Trajectory ecosystem. It focuses on rapid capture and reliable sync.\n\n## Core Components 1. **Local Store (Vault):** - Uses SQLite (via Expo SQLite or similar) for offline-first persistence. - Schema: `ideas (id, content, audio_uri, transcription, created_at, synced_status, metadata)`\n\n2. **Sync Engine:** - Background sync service. - Conflict resolution: Last-write-wins (for Gen 7).\n\n3. **Quick Capture Widget:** - Minimalist UI for one-tap text entry. - Voice trigger button.\n\n4. **Voice-to-Idea:** - Audio recording module. - Whisper or Device-native STT integration.", "htmlHref": "/research/html/architecture-idea-vault-gen-7-1qwzm3q.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 163 }, { "id": "multi-horizon-agent-architecture-operational-tracker-pc2yt8", "title": "Multi-Horizon Agent Architecture — Operational Tracker", "slug": "multi-horizon-agent-architecture-operational-tracker", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Meaning-Full-Power/community-school/AGENT-HORIZONS.md", "extension": "md", "score": 30, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> Each horizon operates autonomously. This file tracks goals, active tasks, and status across all four business horizons.", "excerpt": "> Each horizon operates autonomously. This file tracks goals, active tasks, and status across all four business horizons.\n\n**Agent Goal:** Generate attention, build initial audience, prove the concept publicly.\n\n### Active Tasks | Task | Status | Owner | Deadline | |------|--------|-------|----------| | Finalize MFP Hydrogen storefront | 🟡 In Progress | Agent | Feb 16 | | Finalize SS Hydrogen storefront | 🟡 In Progress | Agent | Feb 16 | | Set up OBS screen recording workflow | ⚪ Planned | Human | Feb 17 | | Record first \"Store in 1 Hour\" video | ⚪ Planned | Human + Agent | Feb 18 | | Cut 5 short clips from hero video | ⚪ Planned | Agent | Feb 19 | | Post first clip to Instagram/TikTok | ⚪ Planned | Human | Feb 20 | | Set up content Instagram account | ⚪ Planned | Human | Feb 17 |\n\n### Metrics Dashboard | Metric | Current | Target (Week 1) | |--------|---------|-----------------| | Social followers | 0 | 100 | | Content pieces posted | 0 | 5 | | Store visits (MFP) | — | 50 | | Store visits (SS) | — | 50 | | Discord members | 0 | 25 |\n\n**Agent Goal:** Launch community, begin course production, convert attention to members.", "htmlHref": "/research/html/multi-horizon-agent-architecture-operational-tracker-pc2yt8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1075 }, { "id": "cc-anticipation-living-implementation-checklist-t84bqw", "title": "cc-anticipation: Living Implementation Checklist", "slug": "cc-anticipation-living-implementation-checklist", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "anticipation-geometry/crates/anticipation/docs/CHECKLIST.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Status**: Phases 1-9 COMPLETE (v0 core + Python + Neighbors + Replay + Dashboard) **Parent**: [PROJECT_CHARTER.md](./PROJECT_CHARTER.md)", "excerpt": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Status**: Phases 1-9 COMPLETE (v0 core + Python + Neighbors + Replay + Dashboard) **Parent**: [PROJECT_CHARTER.md](./PROJECT_CHARTER.md)\n\n### 0.1 Canonical Documentation Set - [x] **0.1.1** Project Charter ([PROJECT_CHARTER.md](./PROJECT_CHARTER.md)) - [x] **0.1.2** System Glossary ([GLOSSARY.md](./GLOSSARY.md)) - [x] **0.1.3** Assumptions & Invariants Ledger ([INVARIANTS.md](./INVARIANTS.md))\n\n### 0.2 Implementation Guide - [x] **0.2.1** Module structure defined - [x] **0.2.2** Core types specified (MotionWindow, AnticipationPacket) - [x] **0.2.3** Configuration schema defined - [x] **0.2.4** Kernel implementation outlined - [x] **0.2.5** Feature computation specified - [x] **0.2.6** Integration points documented (cc-core-rs, rag_plusplus) - [x] **0.2.7** Python bindings outlined - [x] **0.2.8** Testing strategy defined - [x] **0.2.9** Benchmark strategy defined\n\n### 0.4 Continuation Protocol - [x] **0.4.1** Continuation protocol documented ([CONTINUATION.md](./CONTINUATION.md))\n\n### 1.1 Project Setup - [x] **1.1.1** Create `Cargo.toml` with dependencies - [x] **1.1.2** Create `src/lib.rs` with module structure - [x] **1.1.3** Add cc-core-rs as dependency - [x] **1.1.4** Add rag_plusplus as dependency (optional feature) - [x] **1.1.5** Configure PyO3/maturin for Python bindings", "htmlHref": "/research/html/cc-anticipation-living-implementation-checklist-t84bqw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1442 }, { "id": "anticipation-geometry-1udvlmo", "title": "Anticipation Geometry", "slug": "anticipation-geometry", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anticipation-geometry/paper/README.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "[![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE) [![Rust](https://img.shields.io/badge/Rust-1.75+-orange.svg)](https://www.rust-lang.org/) [![Python](https://img.shields.io/badge/Python-3.10+-green.svg)](https://www.python.org/)", "excerpt": "[![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE) [![Rust](https://img.shields.io/badge/Rust-1.75+-orange.svg)](https://www.rust-lang.org/) [![Python](https://img.shields.io/badge/Python-3.10+-green.svg)](https://www.python.org/)\n\nA mathematical framework that characterizes trajectories through arbitrary state spaces using seven geometric scalars. Originally developed for real-time motion capture at 50 Hz, the framework generalizes to conversational reasoning, knowledge graph traversal, and any sequence of vectors in a metric space.\n\nTransition pressure, defined as `d(commitment)/dt - d(uncertainty)/dt`, predicts conversation convergence at **71.8% accuracy** (z = 2.72, p < 0.007). KG-path rewards achieve **100% pairwise ranking accuracy** (Cohen's d = 11.17) on seeded synthetic path evaluation (seed=42), a structural guarantee from chain continuity construction. No domain-specific training is required.\n\n| Scalar | Range | What it measures | |--------|-------|-----------------| | **commitment** | [0, 1] | How irreversible the current trajectory state is. High when motion is deep into a sustained phase. | | **uncertainty** | [0, 1] | How many plausible futures remain. High when many historical states are equidistant (gestural regime). | | **transition_pressure** | unbounded | Rate at which futures are collapsing: `d(commitment)/dt - d(uncertainty)/dt`. Positive spikes predict regime changes. | | **recovery_margin** | [0, 1] | Distance to balance/attractor loss. How easy it is to reverse course. | | **phase_stiffness** | [0, 1] | How locked to internal metronome. High directional persistence + low jerk. | | **novelty** | [0, 1] | Distance from recent regime embeddings. High when exploring new territory. | | **stability** | [0, 1] | Local stationarity of dynamics. High predictability + low acceleration. |\n\n### Conversation Convergence (MiniLM, 384D) - **5,000 dialogue turns** across 39 conversations - Transition pressure sign predicts convergence: **71.8% accuracy** - Statistical significance: z = 2.72, p < 0.007 - Transition pressure / commitment correlation: r = 0.455", "htmlHref": "/research/html/anticipation-geometry-1udvlmo.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 842 }, { "id": "dep-report-cognitive-twin-pipeline-minimax-fleet-integration-dmw478", "title": "DEP Report — Cognitive Twin Pipeline + MiniMax Fleet Integration", "slug": "dep-report-cognitive-twin-pipeline-minimax-fleet-integration", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "cognitive-twin/DEP_REPORT.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Category | Score | Weight | Weighted | |----------|-------|--------|----------| | Structure | 7 | 1.0 | 7.0 | | Compilation | 8 | 1.5 | 12.0 | | Integration | 6 | 1.5 | 9.0 | | Content | 7 | 1.0 | 7.0 | | User Journey | 5 | 1.0 | 5.0 | | Deployment | 5 | 1.0 | 5.0 | | **Total** | | **7.0** | **45.0 / 70 = 64.3%** |", "excerpt": "# DEP Report — Cognitive Twin Pipeline + MiniMax Fleet Integration **Date:** 2026-02-16 **Auditor:** Claw 🦞 **Scope:** `Desktop/cognitive-twin/pipeline/` + `[home-path]`\n\n### ✅ Strengths - Clean separation: `pipeline/` for scripts, `output/` for results - Registry file (`minimax-fleet/registry.json`) tracks instance metadata - Single-file scorer is appropriately simple for the task\n\n### ⚠️ Issues - **No `__init__.py` or module structure** — fine for now but limits importability - **No `requirements.txt`** — script uses only stdlib (good) but should document that - **No README.md** in `cognitive-twin/` — new contributor can't onboard - **Output files not gitignored** — JSONL scoring data could be large\n\n### Recommendations - [ ] Add `README.md` with pipeline overview, usage, and architecture - [ ] Add `.gitignore` for `output/*.jsonl` (keep structure, ignore data) - [ ] Add `CLAUDE.md` for sub-agent context\n\n### ✅ Strengths - Pure Python 3, stdlib only (no dependencies to break) - `urllib.request` instead of `requests` — zero install required - Parallel execution via `ThreadPoolExecutor` — matches llama.cpp's 4 slots - Health check before starting — fails fast if MiniMax is down", "htmlHref": "/research/html/dep-report-cognitive-twin-pipeline-minimax-fleet-integration-dmw478.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1222 }, { "id": "gesture-control-system-production-1wpsslx", "title": "Gesture Control System - Production", "slug": "gesture-control-system-production", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/gesture_control/README.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Enterprise-grade multi-modal gesture recognition** combining phone sensors and video analysis for expressive DJ control.", "excerpt": "**Enterprise-grade multi-modal gesture recognition** combining phone sensors and video analysis for expressive DJ control.\n\n### Production-Grade Reliability - ✅ **Zero data loss** - Atomic transactions with automatic backups - ✅ **Auto-recovery** - Reconnection, crash recovery, corruption detection - ✅ **50% faster** - Template caching (20-40ms recognition) - ✅ **Enterprise monitoring** - Real-time performance dashboard\n\n### Multi-Modal Recognition - 📱 **Phone sensors** - Accelerometer + gyroscope (high precision) - 📹 **Video analysis** - Gemini Live (semantic understanding) - 🎯 **Sensor fusion** - Combine numerical + visual data - 🎓 **Template learning** - Statistical matching (mean + std)\n\n### Training System - 📝 **15+ samples** per gesture - 🎯 **Practice mode** - Real-time feedback on 13 features - 📊 **Analytics** - Accuracy, consistency, trend analysis - 💾 **Session persistence** - Resume training after interruption\n\nNo hardware required. Tests: - Database operations - Template training - Gesture recognition - Export/import - Auto-recovery", "htmlHref": "/research/html/gesture-control-system-production-1wpsslx.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1096 }, { "id": "deployment-guide-n1pff6", "title": "Deployment Guide", "slug": "deployment-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/ops/deployment.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This guide covers deploying TrajectoryOS to production. We'll use **Fly.io** as the primary example, but principles apply to other platforms (AWS, Railway, etc.).", "excerpt": "This guide covers deploying TrajectoryOS to production. We'll use **Fly.io** as the primary example, but principles apply to other platforms (AWS, Railway, etc.).\n\n1. **Fly.io Account**: Sign up at https://fly.io 2. **flyctl CLI**: Install via `curl -L https://fly.io/install.sh | sh` 3. **Docker**: For building containers 4. **Environment Variables**: Prepare production secrets\n\nMigrations run automatically via `docker-entrypoint.sh`, but you can also run manually:\n\nSimilar workflow: 1. Connect GitHub repo 2. Railway auto-detects Dockerfiles 3. Set environment variables 4. Deploy\n\nMore complex but highly scalable: 1. Push Docker images to ECR 2. Create ECS service definitions 3. Set up Application Load Balancer 4. Configure auto-scaling", "htmlHref": "/research/html/deployment-guide-n1pff6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1225 }, { "id": "phase-3-4-end-to-end-pipeline-completion-report-fu2n5j", "title": "Phase 3.4: End-to-End Pipeline - Completion Report", "slug": "phase-3-4-end-to-end-pipeline-completion-report", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/PHASE_3_4_PIPELINE.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Phase 3.4 implements the complete end-to-end training pipeline for DLM coordinates. This phase provides orchestration infrastructure that ties together data loading (Phase 3.1), IRCP integration (Phase 3.2), and evaluation metrics (Phase 3.3) into a production-ready training system.", "excerpt": "**Status:** ✅ COMPLETE **Date:** 2025-12-08 **Integration Point:** Week 3, Phase 3.4\n\nPhase 3.4 implements the complete end-to-end training pipeline for DLM coordinates. This phase provides orchestration infrastructure that ties together data loading (Phase 3.1), IRCP integration (Phase 3.2), and evaluation metrics (Phase 3.3) into a production-ready training system.\n\n#### 1. **Checkpoint Manager** ([packages/dlm/pipeline/checkpoint_manager.py](packages/dlm/pipeline/checkpoint_manager.py)) - 370+ lines\n\n**Features:** - ✅ Checkpoint metadata tracking - ✅ Training state persistence - ✅ Metrics history storage - ✅ Configuration snapshots - ✅ Artifact paths tracking\n\n**Features:** - ✅ Save/load checkpoints - ✅ Track best checkpoints by metric - ✅ Automatic cleanup (keep max_checkpoints) - ✅ Resume from checkpoint - ✅ PyTorch artifact storage - ✅ Metadata persistence", "htmlHref": "/research/html/phase-3-4-end-to-end-pipeline-completion-report-fu2n5j.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1380 }, { "id": "rcp-visualization-system-implementation-summary-lhtqwz", "title": "RCP Visualization System - Implementation Summary", "slug": "rcp-visualization-system-implementation-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/rcp/RCP_VISUALIZATION_SUMMARY.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Successfully implemented and deployed a comprehensive visualization system for the Ring Contextual Propagation (RCP) framework, integrating complex topological analysis with real conversation data from a database of 277 conversations.", "excerpt": "Successfully implemented and deployed a comprehensive visualization system for the Ring Contextual Propagation (RCP) framework, integrating complex topological analysis with real conversation data from a database of 277 conversations.\n\n1. **RCP Coordinate System** (`RCPCoordinateSystem`) - Computes 3D spatial coordinates (x, y, z) for hierarchical conversation structures - x: Depth level in conversation tree - y: Sibling order among messages at same level - z: Homogeneity relationships between sibling messages\n\n2. **Ring Topology** (`RingTopology`) - Creates circular message arrangements preserving hierarchical relationships - Builds ring structures from spatial coordinates and message data - Maintains continuous context flow pathways\n\n3. **Contextual Attention** (`ContextualAttention`) - Computes attention weights based on coordinate distances - Uses learnable coordinate weights (α, β, γ) for (x, y, z) dimensions - Incorporates semantic similarity and temporal decay\n\n4. **Flow Dynamics** (`FlowDynamics`) - Implements continuous context flow via differential equations - Maintains conservation laws during propagation - Supports convergence analysis and stability monitoring", "htmlHref": "/research/html/rcp-visualization-system-implementation-summary-lhtqwz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 802 }, { "id": "scripts-directory-ra6nq1", "title": "Scripts Directory", "slug": "scripts-directory", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/scripts/README.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This directory contains utility scripts, training scripts, demos, setup tools, and testing utilities for the CC-TPO project.", "excerpt": "This directory contains utility scripts, training scripts, demos, setup tools, and testing utilities for the CC-TPO project.\n\n### train_ircp_full_dataset.py Trains the IRCP model on the full dataset (277 conversations).\n\n### train_sentence_transformer_ircp.py Trains the SentenceTransformer-based IRCP model.\n\n### regenerate_embeddings_277.py Regenerates embeddings for the 277-conversation dataset.\n\n### test_complete_ircp_implementation.py Comprehensive test suite for the complete IRCP implementation.", "htmlHref": "/research/html/scripts-directory-ra6nq1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 599 }, { "id": "cc-agent-ipc-1iug557", "title": "cc-agent-ipc", "slug": "cc-agent-ipc", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/_recovered/cc-agent-ipc/README.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This crate provides an async Rust interface to communicate with the `cc-agent-service` Python daemon over Unix sockets. It enables Rust applications (Tauri, CLI tools, backend services) to leverage multiple LLM providers:", "excerpt": "This crate provides an async Rust interface to communicate with the `cc-agent-service` Python daemon over Unix sockets. It enables Rust applications (Tauri, CLI tools, backend services) to leverage multiple LLM providers:\n\n- **Claude** (claude-agent-sdk) - Extended thinking, subagents - **OpenAI** (openai-agents) - Handoffs, guardrails - **Auto** - Dynamic provider selection based on capabilities\n\nAvailable strategies: - `Fixed` - Always use specified provider - `RoundRobin` - Alternate between providers - `Capability` - Route based on task requirements - `Cost` - Minimize cost - `Latency` - Minimize latency\n\n- **cc-agent-sdk** - TypeScript SDK for Node.js/browser applications - **cc-agent-service** - Python daemon that orchestrates Claude/OpenAI agents", "htmlHref": "/research/html/cc-agent-ipc-1iug557.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 621 }, { "id": "cc-anticipation-living-implementation-checklist-1gkcdcc", "title": "cc-anticipation: Living Implementation Checklist", "slug": "cc-anticipation-living-implementation-checklist", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/motion/cc-anticipation/docs/CHECKLIST.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Status**: Phases 1-9 COMPLETE (v0 core + Python + Neighbors + Replay + Dashboard) **Parent**: [PROJECT_CHARTER.md](./PROJECT_CHARTER.md)", "excerpt": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Status**: Phases 1-9 COMPLETE (v0 core + Python + Neighbors + Replay + Dashboard) **Parent**: [PROJECT_CHARTER.md](./PROJECT_CHARTER.md)\n\n### 0.1 Canonical Documentation Set - [x] **0.1.1** Project Charter ([PROJECT_CHARTER.md](./PROJECT_CHARTER.md)) - [x] **0.1.2** System Glossary ([GLOSSARY.md](./GLOSSARY.md)) - [x] **0.1.3** Assumptions & Invariants Ledger ([INVARIANTS.md](./INVARIANTS.md))\n\n### 0.2 Implementation Guide - [x] **0.2.1** Module structure defined - [x] **0.2.2** Core types specified (MotionWindow, AnticipationPacket) - [x] **0.2.3** Configuration schema defined - [x] **0.2.4** Kernel implementation outlined - [x] **0.2.5** Feature computation specified - [x] **0.2.6** Integration points documented (cc-core-rs, rag_plusplus) - [x] **0.2.7** Python bindings outlined - [x] **0.2.8** Testing strategy defined - [x] **0.2.9** Benchmark strategy defined\n\n### 0.4 Continuation Protocol - [x] **0.4.1** Continuation protocol documented ([CONTINUATION.md](./CONTINUATION.md))\n\n### 1.1 Project Setup - [x] **1.1.1** Create `Cargo.toml` with dependencies - [x] **1.1.2** Create `src/lib.rs` with module structure - [x] **1.1.3** Add cc-core-rs as dependency - [x] **1.1.4** Add rag_plusplus as dependency (optional feature) - [x] **1.1.5** Configure PyO3/maturin for Python bindings", "htmlHref": "/research/html/cc-anticipation-living-implementation-checklist-1gkcdcc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1442 }, { "id": "nko-inscription-system-implementation-summary-us8ils", "title": "N'Ko Inscription System - Implementation Summary", "slug": "nko-inscription-system-implementation-summary", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/core/semantic/cc-inscription/docs/IMPLEMENTATION_SUMMARY.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The `cc-inscription` crate provides a complete foundation for compiling embodied dynamics (z-trajectory) into justified N'Ko statements with cryptographic provenance.", "excerpt": "**Date**: 2026-01-03 **Status**: Phase 1 Complete - Foundation Implemented **Test Coverage**: 52 tests passing\n\nThe `cc-inscription` crate provides a complete foundation for compiling embodied dynamics (z-trajectory) into justified N'Ko statements with cryptographic provenance.\n\n| Component | Files | Status | Tests | |-----------|-------|--------|-------| | Claim IR Types | 10 files in `claims/` | ✅ Complete | 15 tests | | Core Types | `claims/mod.rs` | ✅ Complete | 4 tests | | Basin Lifecycle | 4 files in `basin/` | ✅ Complete | 7 tests | | Lexicon Versioning | 4 files in `lexicon/` | ✅ Complete | 8 tests | | Surface Rendering | 4 files in `surface/` | ✅ Complete | 6 tests | | Phrase Detection | 4 files in `phrase/` | ✅ Complete | 3 tests | | Claim Detection | 2 files in `detector/` | ✅ Complete | 4 tests | | Integration Stubs | 4 files in `integration/` | ✅ Complete | 5 tests | | Documentation | 5 files in `docs/` | ✅ Complete | N/A | | Lexicon v1.0 | `lexicons/v1.0.json` | ✅ Complete | N/A |\n\n- **Source files**: 33 Rust files - **Documentation**: 6 markdown files - **Configuration**: 2 files (Cargo.toml, v1.0.json) - **Total lines of code**: ~3,500 lines\n\nAll 10 claim types are fully implemented with: - Strongly-typed IR structures - Validation methods - Test coverage", "htmlHref": "/research/html/nko-inscription-system-implementation-summary-us8ils.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1021 }, { "id": "experimental-protocol-trajectory-symbol-alignment-hypothesis-1eahqph", "title": "Experimental Protocol: Trajectory-Symbol Alignment Hypothesis", "slug": "experimental-protocol-trajectory-symbol-alignment-hypothesis", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-semantic-language/docs/research/EXPERIMENTAL_PROTOCOL.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> There exists a finite operator alphabet and legality grammar such that semantic meaning, defined as invariant latent effect across stratified contexts, can be constructed, promoted, deprecated, and recomposed without reference to pre-existing natural language tokens, and such that this meaning remains stable under controlled perturbation.", "excerpt": "> There exists a finite operator alphabet and legality grammar such that semantic meaning, defined as invariant latent effect across stratified contexts, can be constructed, promoted, deprecated, and recomposed without reference to pre-existing natural language tokens, and such that this meaning remains stable under controlled perturbation.\n\n- **Semantic meaning**: A stable pattern in latent space characterized by invariant ΔZ (trajectory difference) across diverse contexts - **Invariant**: Directional concentration ≥ threshold, curvature consistency ≥ threshold, and context entropy ≥ threshold - **Constructed**: Created through operator composition from the 7-operator alphabet - **Stable under perturbation**: Semantic velocity ≤ stage-appropriate threshold under stress profiles\n\n| Variable | Levels | Description | |----------|--------|-------------| | Stress Profile | 6 | Baseline, HighEntropy, PolysemyProbe, OperatorSaturation, ContextCollapse, DriftInduction | | Lifecycle Stage | 3 | Proto, Provisional, Canonical | | Operator Sequence | Varied | Legal sequences from 7-operator grammar | | Context Stratification | 4 | Video, Dictionary, Forum, Synthetic | | Replay Count | 10, 50, 100, 500 | Number of rehearsal iterations |\n\n| Variable | Measurement | Range | |----------|-------------|-------| | Invariance Score | InvarianceScorer.score() | 0.0 - 1.0 | | Semantic Velocity | DriftMetrics.semantic_velocity | -1.0 to +1.0 | | Directional Stability | DriftMetrics.directional_stability | 0.0 - 1.0 | | Curvature Variance | DriftMetrics.curvature_variance | 0.0 - ∞ | | Promotion Rate | Proportion reaching next stage | 0.0 - 1.0 | | Regression Rate | Proportion regressing to lower stage | 0.0 - 1.0 | | Drift Rate | Proportion exhibiting significant drift | 0.0 - 1.0 |\n\n- **Stress Profile**: `baseline_v1` - **Expected Behavior**: High promotion rate (≥80%), low drift rate (≤5%) - **Purpose**: Establish nominal system behavior", "htmlHref": "/research/html/experimental-protocol-trajectory-symbol-alignment-hypothesis-1eahqph.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1110 }, { "id": "experimental-protocol-trajectory-symbol-alignment-hypothesis-caaw2t", "title": "Experimental Protocol: Trajectory-Symbol Alignment Hypothesis", "slug": "experimental-protocol-trajectory-symbol-alignment-hypothesis", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-semantic-language/repro/phase9_bundle_v1/protocol/EXPERIMENTAL_PROTOCOL.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> There exists a finite operator alphabet and legality grammar such that semantic meaning, defined as invariant latent effect across stratified contexts, can be constructed, promoted, deprecated, and recomposed without reference to pre-existing natural language tokens, and such that this meaning remains stable under controlled perturbation.", "excerpt": "> There exists a finite operator alphabet and legality grammar such that semantic meaning, defined as invariant latent effect across stratified contexts, can be constructed, promoted, deprecated, and recomposed without reference to pre-existing natural language tokens, and such that this meaning remains stable under controlled perturbation.\n\n- **Semantic meaning**: A stable pattern in latent space characterized by invariant ΔZ (trajectory difference) across diverse contexts - **Invariant**: Directional concentration ≥ threshold, curvature consistency ≥ threshold, and context entropy ≥ threshold - **Constructed**: Created through operator composition from the 7-operator alphabet - **Stable under perturbation**: Semantic velocity ≤ stage-appropriate threshold under stress profiles\n\n| Variable | Levels | Description | |----------|--------|-------------| | Stress Profile | 6 | Baseline, HighEntropy, PolysemyProbe, OperatorSaturation, ContextCollapse, DriftInduction | | Lifecycle Stage | 3 | Proto, Provisional, Canonical | | Operator Sequence | Varied | Legal sequences from 7-operator grammar | | Context Stratification | 4 | Video, Dictionary, Forum, Synthetic | | Replay Count | 10, 50, 100, 500 | Number of rehearsal iterations |\n\n| Variable | Measurement | Range | |----------|-------------|-------| | Invariance Score | InvarianceScorer.score() | 0.0 - 1.0 | | Semantic Velocity | DriftMetrics.semantic_velocity | -1.0 to +1.0 | | Directional Stability | DriftMetrics.directional_stability | 0.0 - 1.0 | | Curvature Variance | DriftMetrics.curvature_variance | 0.0 - ∞ | | Promotion Rate | Proportion reaching next stage | 0.0 - 1.0 | | Regression Rate | Proportion regressing to lower stage | 0.0 - 1.0 | | Drift Rate | Proportion exhibiting significant drift | 0.0 - 1.0 |\n\n- **Stress Profile**: `baseline_v1` - **Expected Behavior**: High promotion rate (≥80%), low drift rate (≤5%) - **Purpose**: Establish nominal system behavior", "htmlHref": "/research/html/experimental-protocol-trajectory-symbol-alignment-hypothesis-caaw2t.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1110 }, { "id": "nko-sigil-components-lac5ep", "title": "N'Ko Sigil Components", "slug": "nko-sigil-components", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/docs/nko-ecosystem/components/README.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "// With options console.log(type)} /> ```", "excerpt": "These components require React 18+ and assume you have a bundler configured for TypeScript.\n\n| Prop | Type | Default | Description | |------|------|---------|-------------| | `type` | `SigilType` | required | The sigil to render | | `size` | `number` | `48` | Size in pixels | | `color` | `string` | `#8b5cf6` | Sigil color | | `animated` | `boolean` | `true` | Enable animation | | `animation` | `string` | type-specific | Animation name | | `interactive` | `boolean` | `false` | Enable click/hover | | `showLabel` | `boolean` | `false` | Show name below sigil | | `onClick` | `function` | - | Click handler | | `onHover` | `function` | - | Hover handler |\n\n- `` — Full grid/row/wheel picker - `` — Dropdown-style picker - `` — Circular arrangement for gestural interfaces\n\n| Prop | Type | Default | Description | |------|------|---------|-------------| | `value` | `SigilType \\| SigilType[]` | - | Selected sigil(s) | | `onChange` | `function` | - | Selection change handler | | `multiple` | `boolean` | `false` | Allow multi-select | | `layout` | `'grid' \\| 'row' \\| 'wheel'` | `'grid'` | Layout style | | `size` | `'sm' \\| 'md' \\| 'lg'` | `'md'` | Size preset | | `showLabels` | `boolean` | `true` | Show sigil names | | `showTooltip` | `boolean` | `true` | Show hover tooltip | | `filter` | `SigilType[]` | - | Only show these sigils | | `disabled` | `SigilType[]` | - | Disable these sigils |\n\n- `` — Hover tooltip or inline display - `` — Card layout for lists - `` — Display all 10 sigils", "htmlHref": "/research/html/nko-sigil-components-lac5ep.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 819 }, { "id": "full-stack-map-1q2yz9q", "title": "Full Stack Map", "slug": "full-stack-map", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/01-system-overview/full-stack-map.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "This map uses source-verified component names. It intentionally avoids old summary claims such as \"SAN 135K\", \"5,408 pairs\", \"validation loss 0.028\", or \"LIM-RPS is the production brain\" unless a source file proves them.", "excerpt": "This map uses source-verified component names. It intentionally avoids old summary claims such as \"SAN 135K\", \"5,408 pairs\", \"validation loss 0.028\", or \"LIM-RPS is the production brain\" unless a source file proves them.\n\n- Rust `echelon_get_dynamics_128`. - Swift `EchelonBridge.getDynamics128()` overlay helper. - SAN flat input from Rust SAN FFI. - `DiffusionService.buildDynamicsVector()`.\n\nThese are not yet one perfectly invariant contract. The docs should state where each consumer gets its vector.\n\nThat path does not use the Swift overlay helper that injects pose/mocopi/watch slots. The overlay helper is still important, but it is not automatically the input to every downstream consumer.\n\n- `san_manifest.json`: 76 tensors, 164,248 total parameters. - `san_weights.bin`: binary weights corresponding to that manifest.", "htmlHref": "/research/html/full-stack-map-1q2yz9q.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 608 }, { "id": "photography-interval-capture-and-stageview-console-omfgdq", "title": "Photography — Interval Capture and StageView Console", "slug": "photography-interval-capture-and-stageview-console", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/04-generative-output/photography.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Photography is the third generative output of the system. Unlike music (continuous) and visuals (continuous), photography is discrete: the system captures moments.", "excerpt": "Photography is the third generative output of the system. Unlike music (continuous) and visuals (continuous), photography is discrete: the system captures moments.\n\nThe design goal is to make the photographer invisible. The dancer moves; stills appear without anyone pressing a button. The iPhones are the cameras; the iPad is the control console.\n\nEach iPhone in the system is a self-contained camera node. It: - Serves a live MJPEG stream at `:8081/stream` (30fps) - Handles `POST /capture` to take a still photo (AVCapturePhotoOutput) - Runs its own interval timer (2/3/5/8 second automatic capture) - Advertises itself on Bonjour as `_mmcam._tcp` - Sends SSE events (`GET /events`) for `still_captured`, `session_changed`, `status`\n\nThe iPhone can operate as a camera node while simultaneously running the full SAN/audio pipeline (primary performance device) or in camera-only mode (no SAN, no audio — just the camera service).\n\nStageView is an iPad app that discovers all camera nodes and gives the operator a unified view of the entire camera rig.", "htmlHref": "/research/html/photography-interval-capture-and-stageview-console-omfgdq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 765 }, { "id": "claude-code-doc-review-2026-05-27-1xke2c0", "title": "Claude Code Doc Review - 2026-05-27", "slug": "claude-code-doc-review-2026-05-27", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/09-reference/claude-code-doc-review-2026-05-27.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The user's correction was right. Several generated docs treated intended design language as if it were verified runtime behavior. The source supports a strong architecture, but the language must stay precise:", "excerpt": "The user's correction was right. Several generated docs treated intended design language as if it were verified runtime behavior. The source supports a strong architecture, but the language must stay precise:\n\n- \"Diffusion\" is a legacy service name for a conditioned one-step flow/token path. - SAN is wired and weight-backed locally, but not proven as the sole audio driver. - N'Ko ASR is anchored by trajectory-biased Transformer CTC, not MAOE routing. - MAOE is a post-ASR correction/admissibility/control layer. - The 128D vector is a family of related runtime buffers with known shims and mismatches, not a perfectly uniform contract everywhere yet.\n\n| Topic | Incorrect generated claim | Verified source evidence | Correct wording | |---|---|---|---| | Diffusion | The app uses a full multi-step diffusion sampler over the full 128D body state. | `MotionMixApp/Services/DiffusionService.swift` says the name is historical and the current path is ConditioningEncoder + FlowGenerator1Step. CoreML signatures are `dynamics [1,104] -> embedding [1,768]` and `noise [1,384,81] + conditioning [1,768] -> logits [1,384,81]`. | Conditioned one-step flow/token generation path with hub and rule-based fallbacks. | | 104D/128D | There is one universal 128D vector consumed identically everywhere. | `DiffusionService` builds 128D but truncates to 104D for `ConditioningEncoder`; Rust SAN defaults to 128D; some comments still say 104D; ClaimBridge comments say 104D while FFI reads 128 floats. | Treat dynamics as related source-specific vectors with explicit producer/consumer boundaries. | | SAN training | SAN was trained to understand BodyTruth modes and all modality masks. | `SANService` loads `san_weights.bin`/`san_manifest.json`, calls `san_step`, and logs flat inputs. No source inspected proves BodyTruth-mode training. | SAN is a Rust/Swift adaptive output pipeline with local weights and trajectory logging; training claims require named artifacts. | | SAN audible control | SAN drives music after calibration. | `SANService.mixFactor` defaults to `0.0`; Rust `SANConfig::default()` uses `mix_factor = 0.0`. | SAN affects audio only when weights load, the consumer blends SAN output, and mixFactor is above zero. | | FAN/NHA/TTT | These layers have proven learned selectivity, rhythm learning, and fixed-time calibration. | Source implements/configures FAN, MoE, NHA, TTT machinery, but behavior must be proven by weights and runtime logs. | Describe the implemented modules and require artifacts/logs before claiming learned performance. | | N'Ko ASR | MAOE is the trained ASR model or acoustic anchor. | `nko-brain-scanner/HANDOFF.md` identifies N'Ko Trajectory CTC, UnifiedCTCHead, Whisper large-v3 encoder features, 6-layer Transformer with trajectory bias injection, 20.57% CER. | MAOE ", "htmlHref": "/research/html/claude-code-doc-review-2026-05-27-1xke2c0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 648 }, { "id": "stage-0-research-automesh-self-healing-architecture-thjoii", "title": "Stage 0: RESEARCH — AutoMesh Self-Healing Architecture", "slug": "stage-0-research-automesh-self-healing-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/automesh-self-healing/stage0-research.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` [ROOT] AutoMesh Self-Healing ├── [D1] Code-Level Healing (self-healing-code/) │ ├── healer.py (1580 lines, Gen 6-7) │ │ ├── Wound/Antibody/ImmuneMemory (SQLite, reactive) │ │ ├── HealingStrategies (5: null_coalesce, type_coerce, key_fuzzy, index_bounds, retry_backoff) │ │ ├── CellularRegeneration (Gen 6, AST scan, 6 vuln patterns, fortify) │ │ └── WatchMode (Gen 7, file polling, VitalityTimeline, auto-fortify) │ └── KEY: Local-only. No cross-machine propagation. │ ├── [D1] Mesh Coordination (mesh-node-agent/) │", "excerpt": "### 1. Two Immune Systems, Not Connected - **EW immune.py**: 4-tier quarantine for evolution techniques (G/R/D), sliding window, exploration burst - **Healer ImmuneMemory**: wound/antibody pattern matching for Python runtime errors - **Gap**: These operate independently. EW immune handles evolution process health; healer handles code execution health. Neither covers infrastructure fault tolerance.\n\n### 2. EW4 Invariants Already CALC-Aware - `check_min_entropy_production` accepts `calc_results` param, boosts novelty from cross-agent discoveries - `check_bounded_divergence` accepts `calc_pending_count`, factors pending dispatches into divergence pressure - This means the invariant framework is designed for multi-agent coordination already\n\n### 3. Feedback Metabolism = Heartbeat Speed Control - `feedback.py` computes metabolism (0.0-1.0) from signal freshness/diversity/volume - High metabolism → fast heartbeat → aggressive exploration - Low metabolism → slow heartbeat → conservative refinement - This is directly portable to mesh: machine metabolism from task success rate / pane utilization / failure diversity\n\n### 4. Cross-Layer Forcing Has Dream Storm Hook - `forcing.py::handle_dream_storm()` already handles external event injection - This is the pattern for injecting mesh events: rate limit hits, cascading failures, machine dropouts\n\n### 5. Missing Layer: Mesh-Level Immune System The EW immune system (4-tier quarantine) operates on evolution techniques. Need an equivalent operating on: - Machines (quarantine a flaky machine) - Panes (quarantine a crashing pane) - Task types (quarantine prompts that consistently fail) - Accounts (quarantine rate-limited Claude accounts)", "htmlHref": "/research/html/stage-0-research-automesh-self-healing-architecture-thjoii.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 950 }, { "id": "path-b-flow-first-port-music-continuous-flow-architecture-1nuslwf", "title": "Path B: Flow-First — Port Music Continuous Flow Architecture", "slug": "path-b-flow-first-port-music-continuous-flow-architecture", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "evo-cube-output/inscription-dynamics/stage1-path-b.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Velocity field: v_theta(x_t, t, c) - Input: concat(x_t, t_embed, c) = state_dim + 64 + 768 - Architecture: 4 transformer blocks (256D, 4 heads) - Output: dx/dt ∈ R^state_dim", "excerpt": "## Thesis Port `continuous_flow_generator.py` directly. Replace the 12x32 music grid with inscription state vectors. The velocity field learns how conversation states evolve, and distillation gives real-time 1-step prediction.\n\n## Data Same KARL transitions as Path A, but formatted as `(x_0, x_1, c)` triples where `x_0` and `x_1` use the canonical 16D or 23D state contract.\n\n## Strengths - Generative: can sample multiple possible futures by varying noise - Uncertainty quantification: multi-step ODE gives smoother predictions than 1-step - Directly reuses proven architecture from music stack - Distillation to 1-step is already implemented in `flow_map_distiller.py`\n\n## Weaknesses - Overkill for a 16D/23D state space (flow matching shines in higher-dimensional spaces) - Needs more data than Path A (flow models are data-hungry) - Training is GPU-bound, can't run on CPU - The time axis semantics change: music flow goes noise→clean, conversation flow goes state→next_state\n\n## Key Risk The flow matching formulation assumes interpolation between source and target. In music, source=noise, target=clean pattern. In conversation, source=current state, target=next state. These are NOT the same. May need to reformulate as a conditional flow: \"given state_t, what is the velocity toward state_t+1?\" rather than \"denoise from noise to state.\"", "htmlHref": "/research/html/path-b-flow-first-port-music-continuous-flow-architecture-1nuslwf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 334 }, { "id": "lume-creative-engine-maturation-divergent-rail-plan-1qycsgl", "title": "LUME Creative Engine Maturation — Divergent Rail Plan", "slug": "lume-creative-engine-maturation-divergent-rail-plan", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-creative-engine-2026-05-02/divergent-rail.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- Total phases: **5** (Phase 0 setup + Phase 1-4 reel/push/stabilize) - Total tracks: **22** (Σ across phases; mean ≈ 4.4 / phase, peak 5 in Phase 1+2) - Machines: **Mac1** (dev/CAD/spawn), **Mac4** (Unity host + Mac mini sled prototype), **Mac5** (ML, rate-limited; SAN inference only), **K11** (production publisher pod), **iPhone** (MotionMixApp capture + LUMF/LUMM source), **iPad** (LUMM fallback) - Wall time: **7 days** (phases sequential by gate; tracks parallel within phase) - Invariant config: `epsilon = 0.01", "excerpt": "# LUME Creative Engine Maturation — Divergent Rail Plan > Stage 4 of `/chain:genesis`. EW-governed. 7-day reel-ship + non-blocking parallel work. > Inputs: `stage3-expand-master-plan.md` (5-pane plan), `creative-forge-output.md` (Q1 audio threading + Q2 director schema sub-rail + Q3 USB-dominant CAD). > Output binding: this file is what each Codex pane reads to know its role and its bounds. > Deadline: Reel-001 posted 2026-05-09 EOD. Wave 8 push lands the same day.\n\n- Total phases: **5** (Phase 0 setup + Phase 1-4 reel/push/stabilize) - Total tracks: **22** (Σ across phases; mean ≈ 4.4 / phase, peak 5 in Phase 1+2) - Machines: **Mac1** (dev/CAD/spawn), **Mac4** (Unity host + Mac mini sled prototype), **Mac5** (ML, rate-limited; SAN inference only), **K11** (production publisher pod), **iPhone** (MotionMixApp capture + LUMF/LUMM source), **iPad** (LUMM fallback) - Wall time: **7 days** (phases sequential by gate; tracks parallel within phase) - Invariant config: `epsilon = 0.01 deliverables/hour`, `max_div = 4` (Phase 0 hits 5 — flagged in Risk Register), `stall_threshold = 2 sessions with no track-level commit`, `min_viable_transitions = 2 next-step branches per gate` - Agents: 5 Codex panes (P1-P5) + Claude (Mac1 Sonnet 4.7 1M, this session) + Mohamed (judgment + destructive ops + photoshoot) - Repos in scope: `lume-commerce` (software/demo, hardware/cad, launchagents), `MotionMixApp` (iOS Swift), `MotionMix` (macOS director + REEL-001 plan), `MotionMixDirector` (Swift Package — director schema target), `multicam-server` (Rust — director Rust impl deferred to Wave 9)\n\n## Phase 0: Setup (Day 0 = 2026-05-02 evening) > **Gate**: 5 Codex pane prompts in `evo-cube-output/`, K11 health-check green, Mac4 reachable via Tailscale, FirstDate PAT rotation **status confirmed** (rotated OR sentinel `WAVE8_PUSH_BLOCKED_PAT_ROTATION` written), `[home-path]` directory created with empty per-pane files, pre-commit hook target paths surveyed. > **EW Check**: **Bounded Divergence at risk** — 5 panes brushes the cap of 4 + 1 critical. Resolved by collapsing the \"Mac4 verifier handoff prompt\" sub-track into the P3 pane prompt (P3 owns Mac4 anyway), and treating \"K11 health check\" as a 10-minute gate ritual (not a parallel track at this phase). > **Min viable transitions**: 2 (→ Phase 1 if all panes online; → Phase 0.5 stall-recovery if K11 unreachable for >30min)\n\n| Track | Task | Machine | Blocks | EW Role | Effort | |-------|------|---------|--------|---------|--------| | Critical | Open 5 Codex panes with paste-ready prompts (one prompt per pane), set `feature/wave9-creative-engine` branch on `MotionMixApp` repo, set `chore/wave8-push-readiness` branch on `lume-commerce` | Mac1 | All phases | Rail spine | 60 min | | A | FirstDate PAT rotation — `git -C Desktop/FirstD", "htmlHref": "/research/html/lume-creative-engine-maturation-divergent-rail-plan-1qycsgl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 9469 }, { "id": "stage-0-research-lume-full-system-architecture-gkygrf", "title": "Stage 0: RESEARCH -- LUME Full System Architecture", "slug": "stage-0-research-lume-full-system-architecture", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-full-system-architecture/stage0-research.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Unity project (22 C# files, ~3200 lines):** - `LumeUdpReceiver.cs` -- Magic-byte dispatch for LUME/LUMD - `LumePointRenderer.cs` -- Cloud/Depth render modes, GraphicsBuffer - `LumeDepthReprojector.cs` -- GPU pinhole reprojection from LUMD - `LumeOpticalFlow.cs` -- Frame-diff scalar + Lucas-Kanade dense flow - `LumeAudioFftReceiver.cs` -- LUMF consumer, [DefaultExecutionOrder(200)] - `LumeVfxRuntimeBridge.cs` -- Pushes globals to VFX Graph, [DefaultExecutionOrder(210)] - `LumeTransientForcePusher.cs` -- Impulse ev", "excerpt": "### Hardware Stack - **K11 (GMKtec NucBox K11):** Ryzen 9 8945HS, Radeon 780M (~9 TFLOPS), 32GB DDR5, 1TB NVMe. Windows 11 Pro. No CUDA. - **Orbbec Femto Bolt:** USB-C depth camera, 640x576 ToF (confirmed via pyorbbecsdk, published LUMD on :9700) - **Orbbec Femto Mega:** Legacy camera, larger with rear Jetson hump. USB-C. - **UMA-8 mic array:** 8-channel USB-A. Publishes LUMF on :9701 via audio_pub.py. - **Sony mocopi:** 6x BLE IMU sensors. Native app on phone publishes to :12351. LUMM wire format spec exists but bridge not yet deployed. - **Network:** Tailscale mesh connecting mac1, mac4, mac5, cloud-vm, K11.\n\n### LUME Software on K11 (existing, verified) **Python publishers (3 files, ~1170 lines total):** - `pointcloud_pub.py` (556 lines) -- LUME/LUMD dual-format. Real Femto via pyorbbecsdk or synthetic. Ships 40B LUMD headers with intrinsics in every datagram. - `audio_pub.py` (315 lines) -- LUMF 84B fixed datagrams. RMS, 4 EQ bands, 8 MFCC, onset/transient detection. Mic mode via sounddevice or synthetic. - `mocopi_bridge.py` (256 lines, at MotionMix/server/) -- Parses Sony binary TLV protocol from :12351, extracts 27-bone positions. Currently forwards as JSON to capture server HTTP :9405. Needs rewrite to publish LUMM UDP.\n\n**Unity project (22 C# files, ~3200 lines):** - `LumeUdpReceiver.cs` -- Magic-byte dispatch for LUME/LUMD - `LumePointRenderer.cs` -- Cloud/Depth render modes, GraphicsBuffer - `LumeDepthReprojector.cs` -- GPU pinhole reprojection from LUMD - `LumeOpticalFlow.cs` -- Frame-diff scalar + Lucas-Kanade dense flow - `LumeAudioFftReceiver.cs` -- LUMF consumer, [DefaultExecutionOrder(200)] - `LumeVfxRuntimeBridge.cs` -- Pushes globals to VFX Graph, [DefaultExecutionOrder(210)] - `LumeTransientForcePusher.cs` -- Impulse events from transients, [DefaultExecutionOrder(220)] - `LumeCalibrationPanel.cs` -- F12 IMGUI panel, JSON persistence - `LumeMotionGate.cs` -- SuperHot-style time scaling from motion, [DefaultExecutionOrder(150)] - `LumeProceduralTunnel.cs` -- 6144-point cylindrical helix - `LumeAudioReactor.cs` -- Outline flash + HSV jitter from audio - `LumeCalibration.cs` -- Calibration storage - `LumeVfxEditor.cs` + 5 preset ScriptableObjects -- VFX presets - 3 Editor scripts: AutoWire, BootstrapTunnelScene, VfxGraphBootstrap - 2 Compute shaders: LumeDepthReproject.compute, LumeOpticalFlow.compute\n\n**Wire formats (documented in lume_wire_format.md):** | Magic | Format | Port | Size | Status | |-------|--------|------|------|--------| | 0x4C554D45 LUME | Synthetic cloud | :9700 | Variable (450pt chunks) | Working | | 0x4C554D44 LUMD | Raw depth | :9700 | 40B hdr + 716px chunks | Working | | 0x4C554D46 LUMF | Audio FFT | :9701 | 84B fixed | Working | | 0x4C554D4D LUMM | Mocopi skeletal | :9702 | 772B fixed (27 bones) | Spec exists, ", "htmlHref": "/research/html/stage-0-research-lume-full-system-architecture-gkygrf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1358 }, { "id": "path-a-k11-centric-k11-does-everything-possible-locally-zxdfas", "title": "Path A: K11-Centric -- K11 Does Everything Possible Locally", "slug": "path-a-k11-centric-k11-does-everything-possible-locally", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-full-system-architecture/stage1-path-a.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "K11 is the god-node. All sensor processing, visual rendering, audio analysis, motion feature extraction, and coordination happen on K11. Other machines are optional consumers or ML inference servers. K11 runs its own feature extractor for mocopi (replacing MotionMix's MocopiFeatureExtractor), its own motion-to-music parameter mapper (port of ParamMapper logic), and its own coordination layer. MotionMix becomes a camera-only node or is removed entirely.", "excerpt": "K11 is the god-node. All sensor processing, visual rendering, audio analysis, motion feature extraction, and coordination happen on K11. Other machines are optional consumers or ML inference servers. K11 runs its own feature extractor for mocopi (replacing MotionMix's MocopiFeatureExtractor), its own motion-to-music parameter mapper (port of ParamMapper logic), and its own coordination layer. MotionMix becomes a camera-only node or is removed entirely.\n\n- **Minimal network dependency.** Sensor-to-visual path is entirely local. Zero Tailscale hops for the core loop. - **Single point of deployment.** All code runs on one machine. One git clone, one set of services. - **Lowest latency for visuals.** Sensor -> publisher -> Unity is loopback UDP, sub-2ms. - **Simplest failure mode.** If K11 works, everything works. No distributed failure scenarios.\n\n- **Duplicates MotionMix intelligence.** ParamMapper, ChestFlexDetector, MocopiFeatureExtractor would need C# ports in Unity or Python equivalents. That's ~800 lines of logic that already works in Swift. - **No CUDA.** ML inference still requires network hop. Can't run diffusion locally. - **Echelon not available.** The 20-crate Rust engine (128D latent, SAN, lexicon) has never been compiled for Windows. Porting is weeks of work, not hours. - **Music synthesis gap.** K11 has no audio synthesis engine. Strudel.js is on Mac5. Echelon's audio engine is iOS. Building a new audio engine on K11 is a massive undertaking. - **Single point of failure.** If K11 crashes, everything dies. No redundancy. - **Loses MotionMix's camera intelligence.** Vision body pose from iPhone, face analysis, AutoDirector scoring are iPhone-native capabilities. K11 can't run Vision framework.\n\nPARTIAL ADOPT. The sensor-to-visual path SHOULD be K11-local (it already is). But duplicating MotionMix's motion intelligence and Echelon's coordination is wrong. K11 should be sovereign for visual rendering and sensor ingestion, but should not try to replicate the iOS intelligence stack.", "htmlHref": "/research/html/path-a-k11-centric-k11-does-everything-possible-locally-zxdfas.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 431 }, { "id": "path-e-event-driven-mesh-nats-pub-sub-replaces-direct-udp-1955j28", "title": "Path E: Event-Driven Mesh -- NATS/Pub-Sub Replaces Direct UDP", "slug": "path-e-event-driven-mesh-nats-pub-sub-replaces-direct-udp", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-full-system-architecture/stage1-path-e.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Replace all direct UDP connections with a NATS JetStream message bus. Every publisher and consumer becomes a NATS client. Topics replace ports: `lume.depth`, `lume.audio`, `lume.skeleton`, `lume.echelon`, `lume.music`, `lume.director`. Dynamic routing: any new consumer subscribes to a topic and immediately gets data. Replay: JetStream persists N seconds of history so a late-joining consumer catches up. Health monitoring: NATS provides built-in consumer lag metrics.", "excerpt": "Replace all direct UDP connections with a NATS JetStream message bus. Every publisher and consumer becomes a NATS client. Topics replace ports: `lume.depth`, `lume.audio`, `lume.skeleton`, `lume.echelon`, `lume.music`, `lume.director`. Dynamic routing: any new consumer subscribes to a topic and immediately gets data. Replay: JetStream persists N seconds of history so a late-joining consumer catches up. Health monitoring: NATS provides built-in consumer lag metrics.\n\n- **Dynamic topology.** Add a new consumer (e.g., TouchDesigner on a laptop) by subscribing to a topic. No port configuration, no firewall rules. - **Replay/history.** JetStream's windowed retention means a late-joining consumer can replay the last N frames. Useful for debugging and development. - **Health monitoring.** NATS provides consumer group lag, message rates, and connection health out of the box. - **Decoupled evolution.** Change a publisher's format? Just version the subject. Old consumers keep working on the old subject. - **Already partially deployed.** Mohamed has NATS JetStream running (see .nats/jetstream/ in git status). MESH_EVENTS and POLICY streams exist.\n\n- **CRITICAL: Latency.** NATS adds serialization + deserialization + broker hop. For 84-byte LUMF datagrams at 60Hz, the overhead of NATS framing + TCP + broker routing adds 5-15ms vs direct UDP's <1ms. For LUMD depth at 30fps with 716-pixel chunks, the broker becomes a bottleneck. - **CRITICAL: Throughput.** LUMD at 640x576 resolution = 368,640 pixels at 30fps. At 716 pixels/chunk, that's 515 NATS messages per frame, 15,450 messages/second. NATS can handle this, but the chunked depth format was designed for raw UDP sendto, not message broker framing. - **Complexity for no gain on the hot path.** The sensor -> Unity visual path is local loopback. Adding NATS between pointcloud_pub.py and Unity on the same machine is pure overhead with zero benefit. - **Dependency.** NATS must be running for anything to work. Direct UDP has zero infrastructure dependency. - **Windows NATS server.** NATS runs on Windows, but Mohamed's existing NATS setup is on macOS with LaunchAgents. New deployment path. - **Overkill for 3-5 consumers.** The system has exactly: Unity (consumer), MotionMix iOS (consumer), Mac5 Strudel (consumer). Three consumers don't need a message broker.\n\nREJECT for the hot path (sensor data). Direct UDP is correct for real-time sensor data on the local machine. PARTIAL ADOPT for the control plane: NATS could be useful for coordination messages (director cuts, session state, echelon events) where latency tolerance is higher (100ms+) and dynamic subscription is valuable. But sensor data must stay on direct UDP.", "htmlHref": "/research/html/path-e-event-driven-mesh-nats-pub-sub-replaces-direct-udp-1955j28.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 490 }, { "id": "architecture-application-roadmap-kxfqur", "title": "Architecture Application Roadmap", "slug": "architecture-application-roadmap", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/meta-candidate-mining/architecture-application-roadmap.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> Built on 2026-03-15 from `meta-candidate-mining`, the current `evo-cube-output/` inventory, and the `backlog/code4ai-batch/` findings.", "excerpt": "> Built on 2026-03-15 from `meta-candidate-mining`, the current `evo-cube-output/` inventory, and the `backlog/code4ai-batch/` findings.\n\nUse these as the entrypoint for the current program state before reading historical stage files:\n\n- `meta-evolution-overview.md` - `meta-evolution-current-state.md` - `meta-evolution-folder-map.md` - `meta-evolution-karl-bridge.md` - `wave2-staging.md` - `README.md`\n\nDo not keep generating disconnected cubes. Collapse the research into a linear application program:\n\n1. map completed cubes onto the 25 mega-cube registry, 2. extract only the findings that improve shared architecture, 3. apply those deltas in waves, 4. resume automated cube generation only after the control plane and learning loop are stable.", "htmlHref": "/research/html/architecture-application-roadmap-kxfqur.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1213 }, { "id": "stage-0-research-twin-swarm-cognitive-routing-architecture-qtwq5d", "title": "Stage 0: Research — Twin Swarm + Cognitive Routing Architecture", "slug": "stage-0-research-twin-swarm-cognitive-routing-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/twin-swarm-cognitive-routing/stage0-research.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> Date: 2026-03-10 | Evo-Cube #1 of 11 > Noosphere Context: Dreams gestating on orchestration + iteration concepts. KARL trajectory intelligence evo-cube at stage 2.", "excerpt": "> Date: 2026-03-10 | Evo-Cube #1 of 11 > Noosphere Context: Dreams gestating on orchestration + iteration concepts. KARL trajectory intelligence evo-cube at stage 2.\n\n**1. Discord Gateway (`handlers.ts`, 906 lines)** - TaskType: code | research | debug | docs | ops | general - Classification: regex keyword matching on prompt content - Model override: `gemini:` / `codex:` / `claude:` prefix forces model - Rate limit fallback: Claude unavailable + model='any' → force Gemini - Platform affinity: Swift/Xcode keywords → `platform_required = 'darwin'` - No complexity scoring. No learning. No feedback loop.\n\n**2. NUMU Router (`numu-router/src/index.ts`, 375 lines)** - TaskType: creative | implementation | debugging | documentation | research | analysis - Provider affinity: creative→gemini, implementation→claude, debugging→claude, documentation→gemini - Complexity scoring: baseline 0.3, adjusted by word count (+0.2 for >200 words), keyword hits (+0.08 each high-complexity, -0.05 each low-complexity), code blocks, multi-step indicators - Model tier: complexity > 0.7 → \"high\" (Opus/Pro), > 0.4 → \"medium\" (Sonnet/Flash), else \"low\" (Haiku/Flash-lite) - Learned performance: tracks success rate per provider per task type, switches if delta > 15% and > 10 samples - ACMP capacity check: if preferred provider exhausted → switch to available - Decay: removes completions older than 30 days - State: `[home-path]`\n\n**3. Cortex Ops Trigger (`ops_trigger.py`, 249 lines)** - Matches prompt text against SKILL.md auto-trigger regex patterns - 500ms hard timeout (SIGALRM), 29ms typical - Pane claims conflict detection (if another pane has domain claimed → skip) - Currently: all 30+ skills have `status=None` (not active) - KARL integration: init_session_buffer on skill injection\n\n**4. Cognitive Twin Brain-1 Router (`router.py`, 173 lines)** - Three tiers: IDENTITY (about Mo) → KNOWLEDGE (project/tech) → REASONING (multi-hop) - Pre-compiled regex: 8 identity patterns, 10 multi-hop patterns, 9 graph patterns, 3 general patterns - Confidence values: IDENTITY=0.95, REASONING=0.90, GENERAL=0.85, GRAPH=0.80, KNOWLEDGE+=0.65, KNOWLEDGE=0.60 - Maps to TwinConfig: A (bare), B (RAG only), C (RAG+Graph), D (RAG+Graph+RLM)", "htmlHref": "/research/html/stage-0-research-twin-swarm-cognitive-routing-architecture-qtwq5d.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1185 }, { "id": "stage-1-path-a-the-mac-ear-always-on-desktop-microphone-daemon-fq7ydc", "title": "Stage 1 Path A: The Mac Ear — Always-On Desktop Microphone Daemon", "slug": "stage-1-path-a-the-mac-ear-always-on-desktop-microphone-daemon", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/voice-first-agent-architecture/stage1-path-a.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The single highest-impact addition is a daemon on Mac1 that listens to the built-in microphone, detects a wake phrase, transcribes the command, and injects it into the mesh. This eliminates the phone dependency for voice interaction. The Mac is always on, always in front of you, always connected to the mesh.", "excerpt": "> Grounded in: Stage 0 finding that the Mac has no microphone listener. You must pick up the phone to talk to the mesh.\n\nThe single highest-impact addition is a daemon on Mac1 that listens to the built-in microphone, detects a wake phrase, transcribes the command, and injects it into the mesh. This eliminates the phone dependency for voice interaction. The Mac is always on, always in front of you, always connected to the mesh.\n\n**Wake word detection**: Two options: 1. **Whisper-based** (accurate but heavier): Run Whisper on every VAD-triggered segment, check transcript for wake phrase 2. **Porcupine/OpenWakeWord** (lightweight): Dedicated wake word model runs continuously, Whisper runs only after wake detection\n\n**STT options on Mac1:** - `whisper.cpp` via CLI (~1s for 5s audio on M2) - `mlx-whisper` (Apple Silicon optimized) - Apple SFSpeechRecognizer via `speech_recognition` Python bridge - Mac4/Mac5 remote Whisper (over exo cluster API)\n\n- Voice interaction from the desk without phone - Always-on (LaunchAgent, survives logout) - Routes into the existing voice_task_daemon → TTY injection pipeline - Can trigger any fleet command: status, spawn, kill, converge - Uses existing Whisper infrastructure on Mac4/Mac5", "htmlHref": "/research/html/stage-1-path-a-the-mac-ear-always-on-desktop-microphone-daemon-fq7ydc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 421 }, { "id": "stage-2-compound-architecture-voice-first-agent-architecture-1600171", "title": "Stage 2: Compound Architecture — Voice-First Agent Architecture", "slug": "stage-2-compound-architecture-voice-first-agent-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/voice-first-agent-architecture/stage2-compound.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Decision:** Path A's Mac Ear is the entry point — you need to be able to talk to the mesh from the desk. But Path C's unified router is needed immediately because we don't want a third intent classifier (Mac) alongside iOS VoiceRouter and FleetVoiceRouter. Build the server-side router first, then point the Mac Ear at it.", "excerpt": "**Decision:** Path A's Mac Ear is the entry point — you need to be able to talk to the mesh from the desk. But Path C's unified router is needed immediately because we don't want a third intent classifier (Mac) alongside iOS VoiceRouter and FleetVoiceRouter. Build the server-side router first, then point the Mac Ear at it.\n\n**Client migration path:** - Phase 1: Mac Ear uses unified router directly - Phase 2: OpenClawHub switches from local VoiceRouter/FleetVoiceRouter to HTTP POST - Phase 3: SpeakFlow switches from local VoiceCommandService to HTTP POST - Phase 4: Decommission client-side classifiers (keep as offline fallback)\n\n**Decision:** Path B's spoken mesh is essential for bidirectional voice. After Step 1 gives the mesh an ear, it needs a mouth. But Path B's approach of subscribing to ALL events is too noisy. Use a priority filter.\n\n**Mute/unmute via voice:** - \"Quiet\" / \"mute\" → suppresses normal+low events - \"Unmute\" / \"speak\" → resumes - Critical events always spoken regardless of mute state - \"What did I miss?\" → summarize suppressed events\n\n**Decision:** Path D's voice transcript persistence is critical for the mesh's memory model. Voice is currently the only interaction channel that isn't persisted. This creates a gap in the knowledge graph.", "htmlHref": "/research/html/stage-2-compound-architecture-voice-first-agent-architecture-1600171.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1264 }, { "id": "lume-mesh-integration-pab2uc", "title": "LUME ↔ mesh integration", "slug": "lume-mesh-integration", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/architecture/MESH_INTEGRATION.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "`[home-path]` slots spawn short-lived LLM agent CLIs (claude, codex, gemini). LUME is a persistent device running `lume-daemon` as a systemd unit. Wrong abstraction.", "excerpt": "`[home-path]` slots spawn short-lived LLM agent CLIs (claude, codex, gemini). LUME is a persistent device running `lume-daemon` as a systemd unit. Wrong abstraction.\n\n1. **Announce** itself on boot by posting `mesh_events.devices.online` with `{device: \"lume-01\", tailscale_ip, sensors: [...], ts}` to NATS on the cloud-vm leaf node. 2. **Heartbeat** every 10s to `mesh_events.devices.heartbeat` with FPS + thermal snapshot (same payload as `lume.health` topic). 3. **Bidirectional control** subscribed to `mesh_commands.lume.*` — other mesh agents can request screenshots, LED changes, depth bags. 4. **Dashboard** at Nexus `/lume` pulls the device's WS directly over Tailscale (`ws://lume.local:9570/ws`).\n\n1. Jetson joins Tailscale net 2. `lume-daemon` starts under systemd, binds `:9570` 3. One-shot `scripts/announce-to-mesh.sh` posts the online event 4. Nexus `/lume` page picks it up from `mesh_events` subscription", "htmlHref": "/research/html/lume-mesh-integration-pab2uc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 140 }, { "id": "meta-recursive-failure-pattern-audit-f43mtt", "title": "Meta-Recursive Failure Pattern Audit", "slug": "meta-recursive-failure-pattern-audit", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "mesh-dashboard/system-review.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2026-03-14 **Auditor:** Meta-Recursive Explorer (Opus 4.6) **Data Sources:** Supabase mesh_events (23,124 total), failure_journal.jsonl (5,678 entries), cortex/entries.jsonl (679 entries), session-crons/results (11 ring buffers), failure-museum.md (10 exhibits, 26 gems), skills/registry.json (88 skills)", "excerpt": "**Date:** 2026-03-14 **Auditor:** Meta-Recursive Explorer (Opus 4.6) **Data Sources:** Supabase mesh_events (23,124 total), failure_journal.jsonl (5,678 entries), cortex/entries.jsonl (679 entries), session-crons/results (11 ring buffers), failure-museum.md (10 exhibits, 26 gems), skills/registry.json (88 skills)\n\nThe mesh failure detection system has a critical blind spot: **100% of all 5,678 failure journal entries are classified as \"unknown\"** because the `failure-intel/handler.py` hook receives empty `error_snippet` fields for nearly every failure. This means the classifier never matches any of its 10 regex patterns, the recovery registry never fires, and the event bus gets flooded with uninformative `failure_pattern` events. The result is a system that detects failures prolifically but classifies none of them, making the escalation hints generic (\"Review approach and try a different strategy\") rather than actionable.\n\n**Evidence:** - `[home]/.claude/state/failure_journal.jsonl`: 5,678 entries, all class=\"unknown\" - 99.9% of entries have empty `error_snippet` (only 8 of 5,678 have non-empty content) - The non-empty ones contain \"Shell cwd was reset\" messages, not actual errors\n\n**Root Cause:** The handler extracts error text from `tool_response.stderr` + `tool_response.error` (line 178 of `[home]/.claude/hooks/failure-intel/handler.py`). But Claude Code's `PostToolUseFailure` hook input does not always populate these fields. The actual error content is likely in `tool_response.stdout`, `tool_response.content`, or the raw `tool_response` string itself. The handler concatenates two empty/missing fields and classifies the empty string, which matches nothing.\n\n**Impact:** - 4 recovery registry entries (ssh_timeout, xcode_build_failure, disk_full, import_error) have **never fired** - All escalation hints default to the generic message - `failure_pattern` events flood mesh_events (1,000+ events since Mar 7), all with `failure_class: unknown`", "htmlHref": "/research/html/meta-recursive-failure-pattern-audit-f43mtt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2054 }, { "id": "sgt-semantic-generative-tuning-for-unified-multimodal-models-uorama", "title": "SGT: Semantic Generative Tuning for Unified Multimodal Models", "slug": "sgt-semantic-generative-tuning-for-unified-multimodal-models", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/sgt-project-page/README.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "[![Project Page](https://img.shields.io/badge/🌐_Project_Page-Visit-6366f1?style=for-the-badge)](https://song2yu.github.io/SGT/) [![Paper](https://img.shields.io/badge/📄_Paper-arXiv-8b5cf6?style=for-the-badge)](https://arxiv.org/pdf/2605.18714) [![Hugging Face](https://img.shields.io/badge/🤗_Hugging_Face-SAM--SGT_Dataset-FFD21E?style=for-the-badge)](https://huggingface.co/datasets/Two-hot/SAM-SGT)", "excerpt": "[![Project Page](https://img.shields.io/badge/🌐_Project_Page-Visit-6366f1?style=for-the-badge)](https://song2yu.github.io/SGT/) [![Paper](https://img.shields.io/badge/📄_Paper-arXiv-8b5cf6?style=for-the-badge)](https://arxiv.org/pdf/2605.18714) [![Hugging Face](https://img.shields.io/badge/🤗_Hugging_Face-SAM--SGT_Dataset-FFD21E?style=for-the-badge)](https://huggingface.co/datasets/Two-hot/SAM-SGT)\n\n**SGT (Semantic Generative Tuning)** is the first systematic investigation into generative post-training for Unified Multimodal Models (UMMs). By leveraging **image segmentation as a generative proxy**, SGT bridges the gap between visual understanding and generation, enabling true synergy between the two capabilities within a single architecture.\n\nIf you find our project or paper useful, we would greatly appreciate it if you could star this repository or cite our work.\n\nExisting UMMs optimize understanding and generation independently — this leads to misaligned representations and missed synergies. Previous pixel-level alignment methods over-emphasize texture and fail to provide structural semantic guidance.\n\nSGT takes a different approach: use **high-level segmentation** as the generative training objective. This simple yet effective proxy:", "htmlHref": "/research/html/sgt-semantic-generative-tuning-for-unified-multimodal-models-uorama.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 683 }, { "id": "nko-program-master-consolidation-index-dzaysd", "title": "N'Ko Program — Master Consolidation Index", "slug": "nko-program-master-consolidation-index", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKO-CONSOLIDATION.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Cross-repo inventory of the entire N'Ko line of work. Built 2026-05-31 by > sweeping every N'Ko artifact modified in the last week. This is the front door > ABOVE `nko-brain-scanner/PROGRAM.md` (which only covers the research papers). > PROGRAM.md = the science. This file = the whole program (papers + protocol + > apps + synthesis + audio).", "excerpt": "> Cross-repo inventory of the entire N'Ko line of work. Built 2026-05-31 by > sweeping every N'Ko artifact modified in the last week. This is the front door > ABOVE `nko-brain-scanner/PROGRAM.md` (which only covers the research papers). > PROGRAM.md = the science. This file = the whole program (papers + protocol + > apps + synthesis + audio).\n\n## One-line thesis (unchanged across every artifact) **N'Ko is computational infrastructure** — a designed, bijective, tone-marking script that changes what models can represent, how acoustic evidence aligns to symbols, whether an error rate is meaningful, and how sound/motion can be encoded.\n\n| Artifact | Path | What it is | Freshness | Status | |---|---|---|---|---| | **Flagship: canonical consolidation** | `nko-brain-scanner/paper/current/paper_canonical_nko_agp_20cer.tex` (+.pdf) | \"N'Ko as Computational Infrastructure\" — 20% CER anchor + the measurement thesis + AGP governance | **tex+pdf FROZEN at 2026-05-04**; untracked in git | **UNFREEZE TARGET** | | Pillar papers (5) | `nko-brain-scanner/paper/current/paper{2,4,5}*.tex` + `paper/final/0{1-4}` | Living Speech, Script Advantage CTC (5.25pp), Deployment, + cleaned venue-split set | Apr 24 | written/consolidated | | Program map | `nko-brain-scanner/PROGRAM.md` | The convergence figure (decode→govern→correct), pillar taxonomy, release plan | 2026-05-29 | current | | **FAC paper** | `nko-acoustic-coding/main.tex` (+.pdf) | Featural Acoustic Coding — tone resolution from acoustic F0; N'Ko as a sound codec | 2026-05-29 | reframed; pitch pilot done | | FAC experiments | `nko-acoustic-coding/experiments/` | tone-seam v0, fusion eval, H2 pitch, OCR (gpt-5.5), 104-entry toned corpus, read-speech harness | May 28–30 | runnable; gated on 1 read-speech clip | | **MAOE-N'Ko architecture** | `Desktop/MAOE-NKo-Technical-Architecture.md` (codebase `Desktop/Comp-Core`) | Mixture of Anticipatory Orthogonal Experts — AGP routing with authority-orthogonal experts + Rust admissibility gate | 2026-04-23 | architecture materialized, empirics pending | | N'Ko codebook package | `Desktop/NKo/nko/` | 3,024-entry tonal syllable codebook + phonetics; tone-mark bug FIXED (U+07EE = falling) | May 28–29 | 100 tests pass |\n\n### Layer B — The protocol / economic layer | Artifact | Path | What it is | Status | |---|---|---|---| | **N'Ko Compute Network whitepaper** | `Desktop/NKo-Compute-Network-Whitepaper.md` | Proof-of-Linguistic-Competence on Bitcoin L2 (Stacks/EPOCH, 8 Clarity contracts, $21.64 testnet). Workers' N'Ko fluency IS the compute. | drafted (March 2026) |\n\n### Layer C — Applications | App | Path | What it is | Status | |---|---|---|---| | **NKoScribe** | `Desktop/NKoScribe/` | On-device N'Ko ASR iOS app (whisper.cpp xcframework). v1.0 on TestFlight w/ stub. | v1.1 mid-task", "htmlHref": "/research/html/nko-program-master-consolidation-index-dzaysd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 872 }, { "id": "nko-sigil-components-1h92yar", "title": "N'Ko Sigil Components", "slug": "nko-sigil-components", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/docs/essays/components/README.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "// With options console.log(type)} /> ```", "excerpt": "These components require React 18+ and assume you have a bundler configured for TypeScript.\n\n| Prop | Type | Default | Description | |------|------|---------|-------------| | `type` | `SigilType` | required | The sigil to render | | `size` | `number` | `48` | Size in pixels | | `color` | `string` | `#8b5cf6` | Sigil color | | `animated` | `boolean` | `true` | Enable animation | | `animation` | `string` | type-specific | Animation name | | `interactive` | `boolean` | `false` | Enable click/hover | | `showLabel` | `boolean` | `false` | Show name below sigil | | `onClick` | `function` | - | Click handler | | `onHover` | `function` | - | Hover handler |\n\n- `` — Full grid/row/wheel picker - `` — Dropdown-style picker - `` — Circular arrangement for gestural interfaces\n\n| Prop | Type | Default | Description | |------|------|---------|-------------| | `value` | `SigilType \\| SigilType[]` | - | Selected sigil(s) | | `onChange` | `function` | - | Selection change handler | | `multiple` | `boolean` | `false` | Allow multi-select | | `layout` | `'grid' \\| 'row' \\| 'wheel'` | `'grid'` | Layout style | | `size` | `'sm' \\| 'md' \\| 'lg'` | `'md'` | Size preset | | `showLabels` | `boolean` | `true` | Show sigil names | | `showTooltip` | `boolean` | `true` | Show hover tooltip | | `filter` | `SigilType[]` | - | Only show these sigils | | `disabled` | `SigilType[]` | - | Disable these sigils |\n\n- `` — Hover tooltip or inline display - `` — Card layout for lists - `` — Display all 10 sigils", "htmlHref": "/research/html/nko-sigil-components-1h92yar.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 819 }, { "id": "path-a-flow-matching-architecture-upgrade-1xkm215", "title": "Path A: Flow Matching Architecture Upgrade", "slug": "path-a-flow-matching-architecture-upgrade", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "omega-output/cc-motion-gen-20260321/02-evolution/stage1-path-a-flow-matching.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Layers (8 blocks): ├─ AdaLN-Zero (adaptive layer norm from timestep embedding) ├─ Multi-Head Self-Attention (8 heads, dim=256) over temporal axis ├─ Cross-Attention to audio context c (8 heads) ├─ FiLM modulation from audio (preserved from current system) └─ MLP (256 → 1024 → 256, GELU)", "excerpt": "## Core Thesis Replace CC-MotionGen's DDPM/DDIM diffusion backbone with Optimal Transport Conditional Flow Matching (OT-CFM), achieving 10-100x speedup while preserving the dual-stage validation advantage.\n\n### Motion DiT (Diffusion Transformer for Motion) Replace U-Net 1D with a transformer-based architecture:\n\n**Parameter count**: ~15M (vs current U-Net ~20M). Lighter due to no skip connections.\n\nKey advantage: straight-line interpolation paths → fewer steps needed for quality.\n\n### Speed Projections | Steps | Quality (est. FID) | Latency (GPU) | vs Current | |-------|-------------------|---------------|------------| | 1 | ~0.3-0.5 | ~40ms | **50-75x faster** | | 4 | ~0.1-0.2 | ~160ms | **12-18x faster** | | 10 | ~0.05-0.1 | ~400ms | **5-7x faster** | | Current (DDIM 50) | baseline | ~2500ms | 1x |", "htmlHref": "/research/html/path-a-flow-matching-architecture-upgrade-1xkm215.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 597 }, { "id": "implementation-roadmap-computational-choreography-models-husa6g", "title": "Implementation Roadmap — Computational Choreography Models", "slug": "implementation-roadmap-computational-choreography-models", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/_archive/2024-12/historical-plans/IMPLEMENTATION_ROADMAP.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**M0**: 5 synthetic sessions with realistic features **M1**: Cross-pred loss < 0.1; missing-modality test passes **M2**: Normalizer reduces M3 loss variance **M3**: Teaching loss ↓; smoothness reasonable; inference < 2ms **Inference**: Stable > 5 min; latency < 50ms end-to-end **Bridges**: Strudel responds audibly to motion **Metrics**: Phase coherence > 0.6; energy corr > 0.3; drift ~ 1.0", "excerpt": "This roadmap breaks down the model implementation into actionable tasks with clear acceptance criteria.\n\n### Task 0.1: Data Schema Validation - [ ] Verify all schema files in `data/schemas/` match specification - [ ] Create Python validators for each schema type - [ ] Add unit tests for schema validation - **Files**: `sdk/python/validators.py`, `tests/test_schemas.py` - **Acceptance**: Can load and validate example parquet files\n\n### Task 0.2: Update Packet Types - [ ] Enhance `sdk/python/packets.py` with complete types per spec - Add SensorPacket with all fields - Add LatentPacket with modality arrays - Add ControlPacket with all 5 controls - [ ] Add serialization methods (to_dict, from_dict) - [ ] Create matching TypeScript types in `sdk/web/` - **Acceptance**: All packet types match specification exactly\n\n### Task 0.3: Configuration System - [ ] Update `configs/control_map.yaml` with complete specification - Add all 5 controls with min/max/ease/cc - Add throttle_ms and clamp rules - [ ] Create config loader in `sdk/python/config.py` - [ ] Add validation for config files - **Acceptance**: Can load configs; invalid configs raise clear errors\n\n### Task 1.1: Enhanced Synthetic Generator - [ ] Update `scripts/generate_synthetic_sessions.py` with full spec: - Add all 11 frame features (motion_energy, motion_freq, jerk, hip_*, symmetry, hr, hr_slope) - Implement beat_phase and beat_idx computation - Add realistic HR lag (~3 seconds behind motion_energy) - Add jerk spikes near phase 0.0 and 0.5 - [ ] Add CLI arguments: --sessions, --minutes, --bpm, --out, --seed - [ ] Generate meta.json with session metadata - **Acceptance**: - Generates 5 sessions × 3 minutes each - All columns present and within bounds - HR visibly lags motion_energy when plotted - Jerk spikes align with downbeats", "htmlHref": "/research/html/implementation-roadmap-computational-choreography-models-husa6g.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2323 }, { "id": "next-steps-roadmap-post-training-integration-1jnnylh", "title": "🗺️ NEXT STEPS ROADMAP - Post-Training Integration", "slug": "next-steps-roadmap-post-training-integration", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/_archive/2024-12/historical-plans/NEXT_STEPS_ROADMAP.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date**: October 29, 2025 **Current Status**: ✅ All models trained (RPS: 99.94% coherence, Mapper: 0.060 MSE) **Phase**: Integration & Sound Engine Connection", "excerpt": "**Date**: October 29, 2025 **Current Status**: ✅ All models trained (RPS: 99.94% coherence, Mapper: 0.060 MSE) **Phase**: Integration & Sound Engine Connection\n\nWe have successfully trained all core models with exceptional performance. The computational choreography system is now ready for integration testing and connection to the generative sound engine. This document outlines the complete roadmap from current state to live performance readiness.\n\n**Models Trained**: - RPS Encoders (M1): 99.94% coherence, 0.0002 loss - Latent Normalizer (M2): Statistics collected from 60k frames - GRU Control Mapper (M3): 0.060 MSE, excellent smoothness - All checkpoints saved and visualizations generated\n\n**Infrastructure**: - Complete Python codebase with modular architecture - Comprehensive test suite covering all components - Synthetic data generation pipeline (120k frames) - Training scripts and evaluation metrics - Documentation and research papers\n\n**Remaining Core Models (Optional)**: - M4: Look-Ahead Predictor (predictive scheduling) - M5: Gesture Detector (macro triggers) - M6: Reward Model (preference learning) - M7: Bar-Rate Planner (scene management)", "htmlHref": "/research/html/next-steps-roadmap-post-training-integration-1jnnylh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2262 }, { "id": "dj-agent-completion-plan-1iec4cu", "title": "DJ Agent Completion Plan", "slug": "dj-agent-completion-plan", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/_archive/2024-12/old-status-files/MERGED_DJ_AGENT_COMPLETION_PLAN.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "2. **Create keystroke test script** - File: `scripts/test_serato_connection.py` - Send single keystroke (e.g., SPACE for PLAY/PAUSE) - Verify `keyboard` module works on your OS", "excerpt": "# DJ Agent Completion Plan **Linear path from current state to fully integrated motion-driven DJ system**\n\n## Current State ✅ Python runtime engine running (100 FPS, 1.4ms latency) ✅ DELL equilibrium solver operational ✅ DJ Agent code complete (action space, scheduler, policies, bridge) ⚠️ DJ Agent disabled by default ⚠️ Serato integration not tested ⚠️ Tauri frontend exists but not connected to DJ Agent\n\n## Goal State ✅ Motion sensors → DELL → DJ Agent → Serato (verified working) ✅ Tauri UI displays DJ Agent status in real-time ✅ User can toggle tiers, change modes, monitor actions ✅ Full pipeline documented and launchable with one script\n\n### **PHASE 1: Basic Serato Connection (Keyboard Mode)** **Goal:** Verify Python can send keystrokes to Serato **Time:** 30 minutes\n\n#### Tasks: 1. **Enable DJ Agent in config** - File: `computational-studio/studio/configs/session.yaml` - Add DJ Agent section with keyboard mode - Set `tiers_enabled: [0]` (Transport only)", "htmlHref": "/research/html/dj-agent-completion-plan-1iec4cu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1643 }, { "id": "dj-agent-implementation-final-status-1ugq431", "title": "DJ Agent Implementation - Final Status", "slug": "dj-agent-implementation-final-status", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/_archive/2024-12/old-status-files/MERGED_DJ_AGENT_FINAL_STATUS.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Feature | Status | Notes | |---------|--------|-------| | **Tier 0-5 Actions** | ✅ Complete | 50+ actions defined | | **Beat Quantization** | ✅ Complete | |ψ| ≤ 15° window | | **Safety Masks** | ✅ Complete | Context-dependent permissions | | **Cooldown System** | ✅ Complete | 1-16 beat periods | | **MIDI Bridge** | ✅ Complete | Virtual port support | | **Keyboard Bridge** | ✅ Complete | OS-level key injection | | **Reflex Policy** | ✅ Complete | Smooth continuous controls | | **Planner Policy** | ✅ Complete | Rul", "excerpt": "# DJ Agent Implementation - Final Status **Date**: November 4, 2025 **Status**: ✅ **29/38 Tasks Complete (76%)** **Readiness**: 🚀 **Production-Ready Core + Advanced Features**\n\n### Phase 1: Core Infrastructure (13/13) ✅ **100% COMPLETE** - [x] Task 1-9: All base components - [x] Task 10: Runtime integration - [x] Task 11-13: Training infrastructure - [x] Task 36: Documentation\n\n### Phase 2: Advanced Features (11/13) ✅ **85% COMPLETE** - [x] Task 16: Telemetry dashboard - [x] Task 19-21: Tier 1-3 unlock (all defined) - [x] Task 22-24: Motion priors, safety, modes - [x] Task 25: Session logger - [x] Task 28-29: RL sandbox + trainer - [x] Task 30-32: Tier 4-5, hybrid workflow - [x] Task 34-35: Smooth controls, SuperCollider mastering\n\n### Phase 3: User Setup & Testing (0/9) ⏳ **Requires Manual Setup** - [ ] Task 14-15: MIDI device + Serato config (user setup) - [ ] Task 17-18: Ghost/assist testing (requires Serato) - [ ] Task 26-27: Train/eval imitation (requires session data) - [ ] Task 33: Hardware controller (optional) - [ ] Task 37-38: Demo video, optimization (post-testing)\n\n| Feature | Status | Notes | |---------|--------|-------| | **Tier 0-5 Actions** | ✅ Complete | 50+ actions defined | | **Beat Quantization** | ✅ Complete | |ψ| ≤ 15° window | | **Safety Masks** | ✅ Complete | Context-dependent permissions | | **Cooldown System** | ✅ Complete | 1-16 beat periods | | **MIDI Bridge** | ✅ Complete | Virtual port support | | **Keyboard Bridge** | ✅ Complete | OS-level key injection | | **Reflex Policy** | ✅ Complete | Smooth continuous controls | | **Planner Policy** | ✅ Complete | Rule-based + GRU head | | **State Shadow** | ✅ Complete | Predictive Serato mirror | | **Scheduler** | ✅ Complete | Beat gate + rate limits | | **Rewards** | ✅ Complete | 7 reward components | | **Session Logger** | ✅ Complete | Full telemetry capture | | **Telemetry Dashboard** | ✅ Complete | Real-time metrics | | **RL Sandbox** | ✅ Complete | Safe training environment | | **RL Trainer** | ✅ Complete | PPO-style policy gradient | | **Imitation Trainer** | ✅ Complete | GRU sequence model | | **Evaluation** | ✅ Complete | On-grid, safety, smoothness | | **SuperCollider Chain** | ✅ Complete | Professional mastering | | **OSC Controller** | ✅ Complete | Python → SC bridge | | **Hybrid Workflow** | ✅ Complete | Human + AI collaboration | | **Ghost Mode** | ✅ Complete | Safe preview | | **Assist Mode** | ✅ Complete | Gesture confirmation | | **Auto Mode** | ✅ Complete | Autonomous operation | | **Runtime Integration** | ✅ Complete | Wired into engine.py |", "htmlHref": "/research/html/dj-agent-implementation-final-status-1ugq431.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1861 }, { "id": "dj-agent-implementation-summary-m06jnf", "title": "DJ Agent Implementation Summary", "slug": "dj-agent-implementation-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/_archive/2024-12/old-status-files/MERGED_DJ_AGENT_IMPLEMENTATION_SUMMARY.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Category | Tasks | Complete | Pending | % Done | |----------|-------|----------|---------|--------| | Config & Setup | 3 | 3 | 0 | 100% | | Test Scripts | 2 | 2 | 0 | 100% | | Telemetry | 1 | 1 | 0 | 100% | | Tauri UI | 3 | 3 | 0 | 100% | | Integration | 1 | 1 | 0 | 100% | | Documentation | 1 | 1 | 0 | 100% | | **TOTAL (Code)** | **11** | **11** | **0** | **100%** | | | | | | | | User Testing | 7 | 0 | 7 | 0% | | **TOTAL (All)** | **18** | **11** | **7** | **61%** |", "excerpt": "# DJ Agent Implementation Summary **Status: All Core Components Complete ✅** **Date: November 5, 2025**\n\n### Phase 1: Basic Integration (100% Complete) ✅ DJ Agent enabled in `computational-studio/studio/configs/session.yaml` ✅ Keyboard mode configured for testing ✅ Test script created: `scripts/test_serato_connection.py` ✅ Tier 0 actions (Transport) enabled\n\n### Phase 2: MIDI Integration (100% Complete) ✅ MIDI bridge fully implemented in `computational-studio/studio/dj_agent/serato_bridge.py` ✅ Test script created: `scripts/test_midi_connection.py` ✅ Comprehensive MIDI mapping in `computational-studio/studio/configs/dj.yaml` ✅ Support for IAC Driver (macOS) and loopMIDI (Windows)\n\n### Phase 3: Telemetry & Monitoring (100% Complete) ✅ DJ Agent telemetry added to `computational-studio/studio/runtime/engine.py` ✅ Tracking: actions_fired, last_action, phase, cooldowns, safety_violations ✅ Real-time metrics via `get_stats()` ✅ WebSocket telemetry emission\n\n### Phase 4: Tauri UI Dashboard (100% Complete) ✅ TypeScript types updated in `desktop/src/telemetry.ts` ✅ DJ Agent panel created: `desktop/src/components/DJAgentPanel.tsx` ✅ Features: - Status display (enabled/disabled) - Actions fired counter - Last action + timestamp - Beat phase wheel (animated) - Active cooldown progress bars - Safety violation alerts ✅ Integrated into `desktop/src/App.tsx` ✅ Styled in `desktop/src/styles.css`", "htmlHref": "/research/html/dj-agent-implementation-summary-m06jnf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1459 }, { "id": "dj-agent-motion-driven-auto-dj-system-3f8s1a", "title": "🎵 DJ Agent - Motion-Driven Auto-DJ System", "slug": "dj-agent-motion-driven-auto-dj-system", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/_archive/2024-12/old-status-files/MERGED_README_DJ_AGENT.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A production-ready, safety-first auto-DJ system that translates DELL equilibria outputs into musical Serato/SuperCollider control.", "excerpt": "A production-ready, safety-first auto-DJ system that translates DELL equilibria outputs into musical Serato/SuperCollider control.\n\nAn AI DJ agent that: - 🎚️ Controls Serato DJ via MIDI/keyboard - 🎵 Executes actions only on musical beats - 🛡️ Enforces safety constraints (never breaks the flow) - 🤝 Collaborates with you (ghost/assist/auto modes) - 📊 Learns from your performances - ⚡ Runs in real-time (< 10ms latency)\n\n### What's Working NOW ✅ 6-tier action system (50+ actions) ✅ Beat quantization (|ψ| ≤ 15°) ✅ MIDI/keyboard bridge ✅ Safety masks + cooldowns ✅ 3 operation modes (ghost/assist/auto) ✅ Training pipeline ✅ SuperCollider mastering ✅ Telemetry dashboard (Tauri UI) ✅ Session logging ✅ RL sandbox ✅ Full integration & launch scripts ✅ Comprehensive documentation ✅ 🎤 **Voice commands** (say \"play\", \"loop\", \"sync\") ✅ 🛡️ **macOS safety fixes** (pynput - won't freeze your system)\n\n### What's Needed from YOU ⏳ 15 minutes setup (MIDI device + Serato config) ⏳ Live testing with your movement ⏳ Optional: Record training data for personalization\n\n### ⚠️ Voice Commands & Keyboard Control **We fixed a critical system freeze issue!**", "htmlHref": "/research/html/dj-agent-motion-driven-auto-dj-system-3f8s1a.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1971 }, { "id": "gemini-live-voice-control-high-accuracy-dj-commands-1dwhsd7", "title": "Gemini Live Voice Control - High Accuracy DJ Commands", "slug": "gemini-live-voice-control-high-accuracy-dj-commands", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/GEMINI_VOICE_CONTROL_README.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This uses **Google's Gemini Live API** for superior speech recognition accuracy compared to standard speech recognition libraries.", "excerpt": "This uses **Google's Gemini Live API** for superior speech recognition accuracy compared to standard speech recognition libraries.\n\n- **Much Better Accuracy**: Uses Google's advanced AI models - **Real-time Streaming**: Low-latency voice recognition - **Context Understanding**: Understands natural speech patterns - **Voice Activity Detection**: Built-in VAD to filter out background noise\n\n1. **Gemini API Key**: Get one from [https://ai.google.dev/](https://ai.google.dev/) 2. **Python Dependencies**: Install with `pip install -r requirements.txt`\n\n**Left Deck:** - \"play left\" / \"pause left\" / \"stop left\" - \"cue 1 left\" / \"cue 2 left\" / ... / \"cue 8 left\" - \"censor left\" / \"filter left\" / \"echo left\" - \"tempo up left\" / \"faster left\"\n\n**Right Deck:** - \"play right\" / \"pause right\" / \"stop right\" - \"cue 1 right\" / \"cue 2 right\" / ... / \"cue 4 right\" - \"censor right\" / \"filter right\" / \"echo right\" - \"tempo up right\" / \"faster right\"", "htmlHref": "/research/html/gemini-live-voice-control-high-accuracy-dj-commands-1dwhsd7.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 801 }, { "id": "phase-1-engine-bring-up-weeks-1-6-fhu6gf", "title": "Phase 1 – Engine Bring-up (Weeks 1-6)", "slug": "phase-1-engine-bring-up-weeks-1-6", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/echelon/phases/phase-1.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Goal: Ship a macOS binary that owns the CoreAudio device, renders audio in a lock-free callback (no allocations once prepared), plays two deck buffers through crossfader + EQ + limiter, and produces real latency/jitter metrics. Everything else can be stubs.", "excerpt": "Goal: Ship a macOS binary that owns the CoreAudio device, renders audio in a lock-free callback (no allocations once prepared), plays two deck buffers through crossfader + EQ + limiter, and produces real latency/jitter metrics. Everything else can be stubs.\n\n### 1.1 Audio I/O backend - Add `cpal` dependency; create `DevicePicker` that negotiates `f32` stereo 48 kHz stream with the default output device. - Implement `CoreAudioBackend::prepare()` to store stream config and device handles, `start()` to spawn the stream. - Provide `LinuxBackend`/`WasapiBackend` stubs behind `cfg` (return `Unsupported` errors) to keep the crate building on other OSes.\n\n### 1.2 Render callback contract - Define `AudioBlock { channels, frames, data: *mut f32 }` and `AudioCallback` trait with `fn render(&mut self, AudioBlock)`. - Wire the cpal stream so the callback simply forwards the mutable slice to `EngineCore::render()`. - Configure QoS: set audio thread to `UserInteractive` priority via coreaudio APIs; pin control thread to another core.\n\n### 1.3 Channel ring & double buffering - Introduce `ChannelRing` (SPSC) using `rtrb`; producer pushes `RenderBatch { left: *const f32, right: *const f32, len }` per block. - Consumer (audio thread) pops and copies into the device buffer; drop oldest batch if ring is full (increment `overruns`). - Add `EngineTelemetry` struct containing `overruns`, `callback_ns`, `blocks_rendered`.\n\n**Deliverables:** Binary opens default device and outputs silence; unit test verifies ring operations do not allocate after creation.", "htmlHref": "/research/html/phase-1-engine-bring-up-weeks-1-6-fhu6gf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 841 }, { "id": "echelon-project-status-overview-1i0yrq3", "title": "Echelon Project Status Overview", "slug": "echelon-project-status-overview", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/echelon/STATUS.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Last Updated:** December 2024 **Current Phase:** Phase 3 - Integration & Beta Review **Overall Progress:** ~85% Complete", "excerpt": "**Last Updated:** December 2024 **Current Phase:** Phase 3 - Integration & Beta Review **Overall Progress:** ~85% Complete\n\n### Phase 1: Audio Engine Bring-up ✅ (100%) - ✅ CoreAudio backend with lock-free callback - ✅ Graph arena for zero-allocation memory management - ✅ Deck players with command queues - ✅ Crossfader, EQ, limiter nodes - ✅ Engine controller API - ✅ Latency harness and telemetry - **Status:** Production-ready, all tests passing\n\n### Phase 2: Scheduler & Safety ✅ (100%) - ✅ BeatClock trait and LocalBeatClock implementation - ✅ Quantizer with multiple resolutions - ✅ Action queue (SPSC ring buffer) - ✅ Action executor with quantization and safety - ✅ Safety policy (locks, cooldowns, action masks) - ✅ MIDI input handler with learn mode - ✅ OSC server for external control - ✅ Scheduler worker thread - ✅ Property-based safety tests (proptest) - ✅ Link SDK FFI infrastructure (ready for SDK) - **Status:** Production-ready, 25+ tests passing\n\n### ✅ Week 13: Motion Stream Integration (100%) - ✅ Motion bridge crate created - ✅ DELL Motion Receiver (Episode 1 API integration) - ✅ Motion-to-Action Translator - ✅ Motion Calibration system - ✅ Event extraction (balance, coherence, energy spikes) - **Status:** Complete, ready for Episode 1 API connection\n\n### ✅ Week 14: Voice Control Integration (90%) - ✅ Voice control crate created - ✅ VoiceRecognizer structure (ready for whisper-rs) - ✅ VoiceCommandParser with intent recognition - ✅ Voice feedback system - ✅ Command vocabulary mapping - ⏳ **Pending:** Full whisper-rs integration (requires model files) - **Status:** Structure complete, needs whisper-rs model", "htmlHref": "/research/html/echelon-project-status-overview-1i0yrq3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1146 }, { "id": "echelon-project-to-do-list-13eajy9", "title": "Echelon Project To-Do List", "slug": "echelon-project-to-do-list", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/echelon/todo.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- ✅ Phase 1: Audio Engine (100%) - ✅ Phase 2: Scheduler & Safety (100%) - ✅ Phase 3 Week 13: Motion Stream Integration (100%) - ✅ Phase 3 Week 14: Voice Control Structure (90%) - ✅ Phase 3 Week 15: Phrase Intelligence Service (95%) - ✅ Phase 3 Week 16: UI Foundation (100%) - ✅ Phase 3 Week 17: Phrase Browser & Automation (100%) - ✅ Phase 3 Week 18: Initial Integration Structure (60%)", "excerpt": "**Last Updated:** December 2024 **Status:** Phase 3 Week 18 - Integration & Beta Review\n\n### 1. Scheduler Intent Processing - [ ] **Process intents_in in scheduler_thread** - **File:** `apps/studio/src/threads/scheduler_thread.rs` - **Current:** `intents_in` is received but not processed - **Action:** - Create a loop to process `intents_in` queue - Call `scheduler.submit_intent(intent)` for each intent - Handle errors gracefully - **Estimated Time:** 30 minutes - **Priority:** 🔴 Critical\n\n### 2. Motion → Phrase Intelligence Connection - [ ] **Connect motion thread to phrase intelligence service** - **File:** `apps/studio/src/threads/motion_thread.rs` (line 61) - **Current:** `RecommendationContext` is created but not used - **Action:** - Create a channel or shared state for recommendation requests - Send `RecommendationContext` to phrase intelligence service - Receive recommendations and display in UI - **Estimated Time:** 1-2 hours - **Priority:** 🔴 Critical\n\n### 3. Full Thread Integration - [ ] **Initialize and connect motion/voice/phrase intelligence in main.rs** - **File:** `apps/studio/src/main.rs` - **Current:** Components are stubbed, threads not fully connected - **Action:** - Initialize `DellMotionReceiver` and `MotionTranslator` - Initialize `VoiceRecognizer` and `VoiceCommandParser` - Initialize `PhraseDatabase`, `PhraseRecommender`, `RecommendationService` - Pass to respective threads - Create action queue producer for motion/voice threads - **Estimated Time:** 2-3 hours - **Priority:** 🔴 Critical\n\n### 4. Voice Recognition Integration - [ ] **Integrate whisper-rs for actual voice recognition** - **File:** `crates/voice-control/src/recognizer.rs` - **Current:** Stub implementation returns `None` - **Action:** - Add `whisper-rs` dependency (or alternative) - Load Whisper model - Convert f32 audio to i16 format - Run inference - Extract transcript and confidence - **Blocked On:** Whisper model files - **Estimated Time:** 4-6 hours (after model files) - **Priority:** 🟡 High", "htmlHref": "/research/html/echelon-project-to-do-list-13eajy9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 993 }, { "id": "ios-skills-system-implementation-1a3orzd", "title": "iOS Skills System Implementation", "slug": "ios-skills-system-implementation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/ios-app/SKILLS_SYSTEM_IMPLEMENTATION.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document describes the complete iOS implementation of the TrajectoryOS Skills System, achieving full parity with the Tauri desktop version while leveraging native Apple technologies.", "excerpt": "This document describes the complete iOS implementation of the TrajectoryOS Skills System, achieving full parity with the Tauri desktop version while leveraging native Apple technologies.\n\n**Features:** - Configurable half-life per skill (default: 90 days) - Decay floor (never drops below minimum) - Evergreen skills (no decay) - Recovery rate when practicing\n\n**Relationship Types:** - `prerequisite` - Skill A must be learned before B - `synergy` - Skills enhance each other - `variant` - Skills are variations - `enhances` - Skill A makes B more effective\n\n**Graph Operations:** - Build complete skill graph - Find prerequisites/dependents - Topological sort for learning order - Calculate skill transfer\n\n**Target Management:** - Define skill targets (e.g., \"Senior iOS Developer\") - Set required skills with levels - Track progress toward targets", "htmlHref": "/research/html/ios-skills-system-implementation-1a3orzd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 974 }, { "id": "development-runbook-rzorck", "title": "Development Runbook", "slug": "development-runbook", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "projects/Documentation/03-guides/development/dev_runbook.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "```bash python training/trainers/train_rps.py \\ --config training/experiments/exp_baseline.yaml \\ --epochs 50 \\ --checkpoint-dir training/checkpoints/rps ```", "excerpt": "**What it does**: 1. Replays synthetic session at 100 Hz 2. Encodes → RPS → GRU → controls 3. Emits MIDI CC to IAC Driver 4. Logs controls to `data/processed/sim_output.parquet`\n\n**What it does**: 1. Connects to mocopi suit (UDP) 2. Real-time encoding → controls 3. Emits MIDI CC to Strudel\n\n1. Open https://strudel.cc 2. Paste contents of `sound/strudel/patches/core_patch.strudel.md` 3. Enable Web MIDI → select \"IAC Driver Bus 1\" 4. Click \"Run\"\n\n**Flow**: 1. Starts Strudel embed (if configured) 2. Runs `realtime_loop.py` with test session 3. Monitors MIDI traffic 4. Generates evaluation report\n\n**Fix**: 1. Open Audio MIDI Setup 2. Enable IAC Driver 3. Restart Python interpreter", "htmlHref": "/research/html/development-runbook-rzorck.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 704 }, { "id": "generation-6-complete-k0bh62", "title": "Generation 6 Complete", "slug": "generation-6-complete", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "projects/hef-evolutions/nko-keyboard-ai-predictive-text-trained-on-manding/GENERATION-6-COMPLETE.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Task ID:** b6e09dc0-88d4-470a-992f-e7ef6529a786 **Instance:** inst_20260131082128_371 **Worker:** vm **Timestamp:** 2026-02-25T05:16:27.736274+00:00 **Exit Code:** 0 **Commit:** a6bd998b940e4ec4e3ba9c30d39fa414f4057a86", "excerpt": "**Task ID:** b6e09dc0-88d4-470a-992f-e7ef6529a786 **Instance:** inst_20260131082128_371 **Worker:** vm **Timestamp:** 2026-02-25T05:16:27.736274+00:00 **Exit Code:** 0 **Commit:** a6bd998b940e4ec4e3ba9c30d39fa414f4057a86", "htmlHref": "/research/html/generation-6-complete-k0bh62.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 738 }, { "id": "generation-6-complete-a93qp5", "title": "Generation 6 Complete", "slug": "generation-6-complete", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "projects/hef-evolutions/nko-x-agent-intelligence/GENERATION-6-COMPLETE.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Task ID:** 1b711922-7314-4a40-af75-db66501ca3ae **Instance:** inst_20260131075427_394+inst_20260131082143_740 **Worker:** vm **Timestamp:** 2026-02-25T12:35:16.924911+00:00 **Exit Code:** 0 **Commit:** ea6d84ba4191dc668f4a4ebe561147f4f40ae40e", "excerpt": "**Task ID:** 1b711922-7314-4a40-af75-db66501ca3ae **Instance:** inst_20260131075427_394+inst_20260131082143_740 **Worker:** vm **Timestamp:** 2026-02-25T12:35:16.924911+00:00 **Exit Code:** 0 **Commit:** ea6d84ba4191dc668f4a4ebe561147f4f40ae40e", "htmlHref": "/research/html/generation-6-complete-a93qp5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 506 }, { "id": "makeplayingcards-com-prototype-order-specification-galii8", "title": "MakePlayingCards.com — Prototype Order Specification", "slug": "makeplayingcards-com-prototype-order-specification", "kind": "proposal", "program": "Research Backlog", "sourceAnchor": "projects/Meaning-Full-Power/physical-cards/MPC_ORDER_SPEC.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2026-02-12 **Order Type:** Prototype — 15 unique cards × 2 copies (30 cards total) **Product:** Custom Tarot Cards (70×121mm)", "excerpt": "**Date:** 2026-02-12 **Order Type:** Prototype — 15 unique cards × 2 copies (30 cards total) **Product:** Custom Tarot Cards (70×121mm)\n\n| Setting | Value | |---------|-------| | **Product** | Custom Tarot Deck | | **Card Size** | 70mm × 121mm (2.75\" × 4.75\") — closest to our 70×120mm spec | | **Cards per Deck** | 15 front designs + 1 universal back | | **Quantity** | 2 decks | | **Packaging** | Custom tuck box with gold foil stamping |\n\n| Spec | Requirement | Our Source | |------|-------------|-----------| | **File Format** | PNG or JPEG (300+ DPI) | Export from SVG templates | | **Resolution** | Minimum 300 DPI, recommended 600 DPI | Target 600 DPI | | **Color Mode** | RGB (MPC converts internally) | Our SVGs are RGB ✅ | | **File Size** | Max 40MB per image | Well within limits |\n\n| Measurement | mm | inches | pixels @600DPI | |-------------|-----|--------|----------------| | **Final Card Size** | 70 × 121 | 2.75\" × 4.75\" | 1650 × 2850 | | **Bleed Zone** | +3mm each side | +0.12\" each side | +71px each side | | **Full Canvas (with bleed)** | 76 × 127 | 2.99\" × 4.99\" | 1792 × 2992 | | **Safe Zone (no trim risk)** | 64 × 115 | 2.52\" × 4.52\" | 1508 × 2708 |\n\n**Option A: Extend SVG backgrounds (Recommended)** 1. Update SVG viewBox from `0 0 70 120` to `-3 -3 76 127` 2. Extend background gradient/color 3mm past each edge 3. Export at 76×127mm", "htmlHref": "/research/html/makeplayingcards-com-prototype-order-specification-galii8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2147 }, { "id": "makeplayingcards-com-prototype-order-specification-hr76cl", "title": "MakePlayingCards.com — Prototype Order Specification", "slug": "makeplayingcards-com-prototype-order-specification", "kind": "research note", "program": "Research Backlog", "sourceAnchor": "projects/Meaning-Full-Power/physical-cards/prototype-upload/reference/MPC_ORDER_SPEC.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2026-02-12 **Order Type:** Prototype — 15 unique cards × 2 copies (30 cards total) **Product:** Custom Tarot Cards (70×121mm)", "excerpt": "**Date:** 2026-02-12 **Order Type:** Prototype — 15 unique cards × 2 copies (30 cards total) **Product:** Custom Tarot Cards (70×121mm)\n\n| Setting | Value | |---------|-------| | **Product** | Custom Tarot Deck | | **Card Size** | 70mm × 121mm (2.75\" × 4.75\") — closest to our 70×120mm spec | | **Cards per Deck** | 15 front designs + 1 universal back | | **Quantity** | 2 decks | | **Packaging** | Custom tuck box with gold foil stamping |\n\n| Spec | Requirement | Our Source | |------|-------------|-----------| | **File Format** | PNG or JPEG (300+ DPI) | Export from SVG templates | | **Resolution** | Minimum 300 DPI, recommended 600 DPI | Target 600 DPI | | **Color Mode** | RGB (MPC converts internally) | Our SVGs are RGB ✅ | | **File Size** | Max 40MB per image | Well within limits |\n\n| Measurement | mm | inches | pixels @600DPI | |-------------|-----|--------|----------------| | **Final Card Size** | 70 × 121 | 2.75\" × 4.75\" | 1650 × 2850 | | **Bleed Zone** | +3mm each side | +0.12\" each side | +71px each side | | **Full Canvas (with bleed)** | 76 × 127 | 2.99\" × 4.99\" | 1792 × 2992 | | **Safe Zone (no trim risk)** | 64 × 115 | 2.52\" × 4.52\" | 1508 × 2708 |\n\n**Option A: Extend SVG backgrounds (Recommended)** 1. Update SVG viewBox from `0 0 70 120` to `-3 -3 76 127` 2. Extend background gradient/color 3mm past each edge 3. Export at 76×127mm", "htmlHref": "/research/html/makeplayingcards-com-prototype-order-specification-hr76cl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1826 }, { "id": "sea-4-2-skill-mute-and-skill-unmute-1iirrpc", "title": "SEA-4.2 — /skill mute and /skill unmute", "slug": "sea-4-2-skill-mute-and-skill-unmute", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-4.2-COMPLETE.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Implemented skill mute/unmute controls for the SEA ecosystem. Users can now silence individual skills from autonomous activation via Tier 1 routing and Tier 2 scoring while preserving all skill state. Mute events are logged to activation-log.jsonl for audit trail.", "excerpt": "Implemented skill mute/unmute controls for the SEA ecosystem. Users can now silence individual skills from autonomous activation via Tier 1 routing and Tier 2 scoring while preserving all skill state. Mute events are logged to activation-log.jsonl for audit trail.\n\n- **File:** `[home-path]` — Created. Core controller with `mute`, `unmute`, `status`, `list-muted` subcommands. Manages `muted` boolean in state.json, tracks `muted_at` timestamp and `muted_reason`, increments `suppressed_count`, and logs mute/unmute events to activation-log.jsonl. Exposes `is_muted()` function for import by router/scorer.\n\n- **File:** `[home-path]` — Modified. Imports `is_muted` from skill_controller and filters muted skills from candidate list in `route_message()`.\n\n- **File:** `[home-path]` — Modified. Imports `is_muted` from skill_controller and short-circuits `score_skill()` to return `{score: 0.0, reason: \"skill is muted\", inject: false}` without making any API call when skill is muted.\n\n- [x] Structure: skill_controller.py created in correct location alongside tier1/tier2 - [x] Compilation: All 3 files import clean (`python3 -c \"import ...\"` passes) - [x] Integration: is_muted() imported by both router and scorer, no circular deps - [x] Content: mute → score returns 0 (verified), unmute restores, idempotent ops, invalid skill rejected - [x] User Journey: `mute art:snark` → `list-muted` shows it → scorer returns 0 → `unmute art:snark` → restored - [x] Deployment: committed with conventional commit", "htmlHref": "/research/html/sea-4-2-skill-mute-and-skill-unmute-1iirrpc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 256 }, { "id": "bwb-ui-system-3af5bm", "title": "BWB — UI System", "slug": "bwb-ui-system", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "spine/BWB/architecture/UI_SYSTEM.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "BWB uses a cohesive SwiftUI design system with a coffee-inspired color palette, consistent typography, and shared components across all three apps.", "excerpt": "BWB uses a cohesive SwiftUI design system with a coffee-inspired color palette, consistent typography, and shared components across all three apps.\n\nThe UI reflects this through: - Warm, inviting colors (coffee browns, cream whites) - Energetic accent colors (gold highlights, beat orange) - Smooth animations and transitions - Touch-friendly targets for all contexts\n\n| Token | Hex | Usage | |-------|-----|-------| | coffee_50 | #FDF8F6 | Lightest background | | coffee_100 | #F8EDE8 | Light surface | | coffee_200 | #EFDCD3 | Subtle accents | | coffee_300 | #E3C5B5 | Borders | | coffee_400 | #D4A68A | Disabled states | | coffee_500 | #C08A63 | Secondary text | | coffee_600 | #A46D46 | Primary actions | | coffee_700 | #7D5234 | Active states | | coffee_800 | #5C3A24 | Dark elements | | coffee_900 | #2A1B17 | Darkest (text) |\n\n| Token | Hex | Usage | |-------|-----|-------| | cream_50 | #FFFBF7 | Primary background | | cream_100 | #FFF5ED | Card backgrounds | | cream_200 | #FFEDE0 | Elevated surfaces | | cream_500 | #E6C9A8 | Muted elements | | cream_900 | #A87D4F | Deep contrast |\n\n| Token | Hex | Usage | |-------|-----|-------| | vinyl_50 | #F5F5F5 | Disabled text | | vinyl_100 | #E0E0E0 | Placeholder | | vinyl_400 | #9E9E9E | Secondary text | | vinyl_600 | #616161 | Body text | | vinyl_800 | #303030 | Primary text | | vinyl_900 | #0D0D0D | Headlines |", "htmlHref": "/research/html/bwb-ui-system-3af5bm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1166 }, { "id": "meaningful-power-theme-system-1wizq13", "title": "Meaningful Power — Theme System", "slug": "meaningful-power-theme-system", "kind": "architecture", "program": "Protocol and Compute", "sourceAnchor": "spine/Meaning Full Power/architecture/THEME_SYSTEM.md", "extension": "md", "score": 28, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Document ID:** MP-ARCH-002 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/Meaning Full Power/Meaning Full Power/Meaning Full Power/Models/Theme.swift`", "excerpt": "**Document ID:** MP-ARCH-002 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/Meaning Full Power/Meaning Full Power/Meaning Full Power/Models/Theme.swift`\n\nEach theme represents a core aspect of emotional intelligence from Mohamed's book.\n\n**Synergies:** Freedom, Confidence, Time, Hope **Counters:** Time **Cost Modifier:** 0\n\n**Synergies:** Transcendence, Accountability, Hope, Fulfillment, Passion, Confidence **Counters:** Passion **Cost Modifier:** -1 (cheaper)\n\n**Synergies:** Healing, Potential, Time, Passion, Fulfillment **Counters:** None **Cost Modifier:** -1 (cheaper)", "htmlHref": "/research/html/meaningful-power-theme-system-1wizq13.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1444 }, { "id": "trajectory-mobile-voice-capture-idea-vault-1fdcty3", "title": "Trajectory Mobile - Voice Capture + Idea Vault", "slug": "trajectory-mobile-voice-capture-idea-vault", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "trajectory-mobile/README.md", "extension": "md", "score": 28, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A React Native / Expo app for capturing ideas via voice and text, with full-text search, offline sync, priority management, and iOS widgets.", "excerpt": "A React Native / Expo app for capturing ideas via voice and text, with full-text search, offline sync, priority management, and iOS widgets.\n\n### 🎤 Voice Capture (CC-Speak Pattern) - **Low-latency recording** - Audio system pre-warmed on mount for 10ms response - **Visual feedback** - Pulse animation and duration display while recording - **Automatic file management** - Recordings saved with proper cleanup\n\n### 💡 Idea Vault - **Dual input modes** - Text or voice capture - **Auto-tagging** - Smart tag suggestions based on content - **Custom tags** - Add your own tags to organize ideas - **Priority levels** - Urgent/High/Medium/Low with color-coded indicators - **Categories** - Inbox, Project, Personal, Work, Creative, Research - **Swipe actions** - Swipe left to delete, right to edit - **Persistent storage** - Offline-first with sync queue\n\n### 🔍 Full-Text Search + Fuzzy Matching - **Ranked results** - Exact phrase matches score highest - **Fuzzy matching** - Levenshtein distance for typo-tolerant search - **Highlighted results** - Matched text highlighted in search results - **Tag + Category filtering** - Filter by tags, categories, and sync state - **Priority boost** - Urgent/high ideas rank higher\n\n### 📊 Statistics Dashboard - **Animated counters** - Total ideas, this week, urgent count - **Priority breakdown** - Visual bar chart by priority level - **Category distribution** - At-a-glance category counts - **Top tags** - Most used tags across all ideas - **Collapsible** - Compact by default, tap to expand", "htmlHref": "/research/html/trajectory-mobile-voice-capture-idea-vault-1fdcty3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 670 }, { "id": "main-v2-iylbbg", "title": "main v2", "slug": "main-v2", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/main_v2.pdf", "extension": "pdf", "score": 27, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/main-v2-iylbbg.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "main-archive-gpylrj", "title": "main — archive", "slug": "main-archive", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/main.pdf", "extension": "pdf", "score": 27, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/main-archive-gpylrj.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "nko-asr-paper-v2-1yznpdz", "title": "nko asr paper v2", "slug": "nko-asr-paper-v2", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/nko_asr_paper_v2.pdf", "extension": "pdf", "score": 27, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/nko-asr-paper-v2-1yznpdz.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "nko-monograph-ikeen4", "title": "nko monograph", "slug": "nko-monograph", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/nko_monograph.pdf", "extension": "pdf", "score": 27, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/nko-monograph-ikeen4.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "nko-paper-v3-1ao6h4f", "title": "nko paper v3", "slug": "nko-paper-v3", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/nko_paper_v3.pdf", "extension": "pdf", "score": 27, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/nko-paper-v3-1ao6h4f.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "nko-theorems-o9jnl6", "title": "nko theorems", "slug": "nko-theorems", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/nko_theorems.pdf", "extension": "pdf", "score": 27, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/nko-theorems-o9jnl6.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "nko-brain-scanner-kv5slw", "title": "nko brain scanner", "slug": "nko-brain-scanner", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/nko-brain-scanner.pdf", "extension": "pdf", "score": 27, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/nko-brain-scanner-kv5slw.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper1-dead-circuits-1gfcsfz", "title": "paper1 dead circuits", "slug": "paper1-dead-circuits", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/paper1_dead_circuits.pdf", "extension": "pdf", "score": 27, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper1-dead-circuits-1gfcsfz.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "paper2-living-speech-1rsk3o1", "title": "paper2 living speech", "slug": "paper2-living-speech", "kind": "pdf artifact", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/archive/paper2_living_speech.pdf", "extension": "pdf", "score": 27, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Rendered PDF artifact found in the workspace. Needs source/proof mapping before citation-ready release.", "excerpt": "Rendered PDF artifact found in the workspace. The corpus stores its public-safe metadata only; attach a public PDF link after release review.", "htmlHref": "/research/html/paper2-living-speech-1rsk3o1.html", "signals": { "hasPdf": true, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 0 }, { "id": "skill-1upqofm", "title": "SKILL", "slug": "skill", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anthropic-skills/skills/algorithmic-art/SKILL.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Algorithmic philosophies are computational aesthetic movements that are then expressed through code. Output .md files (philosophy), .html files (interactive viewer), and .js files (generative algorithms).", "excerpt": "--- name: algorithmic-art description: Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations. license: Complete terms in LICENSE.txt ---\n\nAlgorithmic philosophies are computational aesthetic movements that are then expressed through code. Output .md files (philosophy), .html files (interactive viewer), and .js files (generative algorithms).\n\nThis happens in two steps: 1. Algorithmic Philosophy Creation (.md file) 2. Express by creating p5.js generative art (.html + .js files)\n\nTo begin, create an ALGORITHMIC PHILOSOPHY (not static images or templates) that will be interpreted through: - Computational processes, emergent behavior, mathematical beauty - Seeded randomness, noise fields, organic systems - Particles, flows, fields, forces - Parametric variation and controlled chaos\n\n### THE CRITICAL UNDERSTANDING - What is received: Some subtle input or instructions by the user to take into account, but use as a foundation; it should not constrain creative freedom. - What is created: An algorithmic philosophy/generative aesthetic movement. - What happens next: The same version receives the philosophy and EXPRESSES IT IN CODE - creating p5.js sketches that are 90% algorithmic generation, 10% essential parameters.", "htmlHref": "/research/html/skill-1upqofm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2761 }, { "id": "skill-12j1byu", "title": "SKILL", "slug": "skill", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anthropic-skills/skills/canvas-design/SKILL.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "These are instructions for creating design philosophies - aesthetic movements that are then EXPRESSED VISUALLY. Output only .md files, .pdf files, and .png files.", "excerpt": "--- name: canvas-design description: Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations. license: Complete terms in LICENSE.txt ---\n\nThese are instructions for creating design philosophies - aesthetic movements that are then EXPRESSED VISUALLY. Output only .md files, .pdf files, and .png files.\n\nComplete this in two steps: 1. Design Philosophy Creation (.md file) 2. Express by creating it on a canvas (.pdf file or .png file)\n\nTo begin, create a VISUAL PHILOSOPHY (not layouts or templates) that will be interpreted through: - Form, space, color, composition - Images, graphics, shapes, patterns - Minimal text as visual accent\n\n### THE CRITICAL UNDERSTANDING - What is received: Some subtle input or instructions by the user that should be taken into account, but used as a foundation; it should not constrain creative freedom. - What is created: A design philosophy/aesthetic movement. - What happens next: Then, the same version receives the philosophy and EXPRESSES IT VISUALLY - creating artifacts that are 90% visual design, 10% essential text.", "htmlHref": "/research/html/skill-12j1byu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1749 }, { "id": "cc-anticipation-project-charter-xia5br", "title": "cc-anticipation: Project Charter", "slug": "cc-anticipation-project-charter", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anticipation-geometry/crates/anticipation/docs/PROJECT_CHARTER.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Status**: Phase Zero - Active **Canonical Input**: [Anchor.md](../../../../docs/Anchor.md)", "excerpt": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Status**: Phase Zero - Active **Canonical Input**: [Anchor.md](../../../../docs/Anchor.md)\n\ncc-anticipation converts stabilized motion state into actionable anticipatory signals. It answers one question: **\"What futures are cheap vs expensive given what's happening now?\"**\n\nIt does not generate motion. It does not generate sound. It does not decide policy. It **measures the geometry of possibility** around the present moment.\n\n| Responsibility | Description | |----------------|-------------| | **MotionWindow consumption** | Accept aligned, canonical motion windows from cc-window-aligner | | **Kinematic feature computation** | Compute velocity, acceleration, jerk, coordination from skeleton | | **Latent dynamics computation** | Compute dz/dt, d²z/dt² from LIM-RPS latent stream | | **Regime embedding** | Map motion window to regime embedding (64-256 dims) | | **Scalar signal emission** | Emit commitment, uncertainty, transition_pressure, recovery_margin, phase_stiffness, novelty, stability | | **Constraint proximity** | Compute balance margin, joint limit proximity, rotation commitment | | **AnticipationPacket emission** | Emit frozen-schema packets every frame, deterministically | | **Neighbor-based uncertainty** | Use continuation dispersion from MotionPhrase library | | **Deterministic replay** | Same input → same output, always |\n\n| Excluded | Rationale | |----------|-----------| | Raw sensor ingestion | Handled by cc-mcs-headless, mocopi-udp-ingest | | Time alignment | Handled by cc-window-aligner | | Policy decisions | Handled by Conductor | | Motion generation | Handled by cc-motiongen | | Audio generation | Handled by MotionStrudel, EchelonDiT | | Semantic labeling | No \"spin coming\" labels; only actionable scalars |", "htmlHref": "/research/html/cc-anticipation-project-charter-xia5br.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 971 }, { "id": "three-ais-one-terminal-how-i-built-cross-model-live-collaboration-29upl7", "title": "Three AIs, One Terminal: How I Built Cross-Model Live Collaboration", "slug": "three-ais-one-terminal-how-i-built-cross-model-live-collaboration", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "blog-cross-agent-collaboration.md", "extension": "md", "score": 26, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "I asked Claude Code about the pane orchestrator. Then I asked OpenAI Codex the same question, without giving it any context about pane awareness. Codex gave me a detailed technical breakdown: the 5-phase heartbeat cycle, the KL divergence invariants, the security patches from last week, the bridge file schema. Everything.", "excerpt": "I asked Claude Code about the pane orchestrator. Then I asked OpenAI Codex the same question, without giving it any context about pane awareness. Codex gave me a detailed technical breakdown: the 5-phase heartbeat cycle, the KL divergence invariants, the security patches from last week, the bridge file schema. Everything.\n\nThat moment made me stop and actually think about what I had built. Not a task dispatcher. Not a multi-model API wrapper. Something closer to a shared nervous system for three competing AI agents running simultaneously on the same machine.\n\n- **Claude Code** (Anthropic, Opus 4.6) across multiple panes, hooks into the OS - **OpenAI Codex CLI** (GPT-5.4) on `/dev/ttys001` in `--dangerously-full-access` mode - **Gemini CLI** (Google, Gemini 3 Pro) on `/dev/ttys009` in `--yolo` mode\n\nEach runs in its own terminal pane. Each has its own context window, its own company's model, its own personality. But they all read from the same underlying infrastructure: the same pane registry, the same task ledger, the same event bus, the same memory files.\n\nCodex has a bootstrap digest. It's a 37KB TypeScript script called `bootstrap-digest.ts` that runs at session start and reads everything:", "htmlHref": "/research/html/three-ais-one-terminal-how-i-built-cross-model-live-collaboration-29upl7.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2014 }, { "id": "bwb-deployment-infrastructure-handoff-18z5np6", "title": "BWB Deployment Infrastructure Handoff", "slug": "bwb-deployment-infrastructure-handoff", "kind": "technical note", "program": "Business Systems", "sourceAnchor": "BWB/docs/HANDOFF-2026-02-09.md", "extension": "md", "score": 26, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Built a complete 4-mode deployment infrastructure for the BWB (Brews With Beats) iOS app ecosystem. The system enables deploying Customer, POS, and Kiosk apps to iPhones and iPads via Discord commands, with intelligent automatic routing based on device availability and network conditions.", "excerpt": "**Date:** 2026-02-09 **Session:** #bwb-customer Discord channel **Author:** Claude (Clawdbot agent)\n\nBuilt a complete 4-mode deployment infrastructure for the BWB (Brews With Beats) iOS app ecosystem. The system enables deploying Customer, POS, and Kiosk apps to iPhones and iPads via Discord commands, with intelligent automatic routing based on device availability and network conditions.\n\n| Mode | Description | Use Case | |------|-------------|----------| | `device` | Direct deploy via devicectl | Same network as Mac | | `home` | Deploy to iPhone 14 (home device) | Remote deploys | | `hotspot` | Connect to car WiFi hotspot first | Field deploys | | `testflight` | Upload to App Store Connect | Works anywhere | | `smart` | Auto-select best mode | **Default behavior** |\n\n| Tool | Description | |------|-------------| | `bwb_status` | Check infrastructure status | | `bwb_deploy` | Deploy with smart routing | | `bwb_analyze` | Analyze and recommend mode |\n\nNatural language triggers: - `deploy customer` → smart deploy Customer app - `deploy pos` → smart deploy POS app - `deploy kiosk` → smart deploy Kiosk app - `deploy all` → deploy all apps to their devices - `testflight customer` → force TestFlight upload", "htmlHref": "/research/html/bwb-deployment-infrastructure-handoff-18z5np6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1382 }, { "id": "multimodal-guide-cpy1yc", "title": "multimodal guide", "slug": "multimodal-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/gesture_control/multimodal_guide.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Voice and gestures are NOT separate control methods** - they're **complementary modalities** that enhance each other for expressive, creative DJ performance.", "excerpt": "**Voice and gestures are NOT separate control methods** - they're **complementary modalities** that enhance each other for expressive, creative DJ performance.\n\nThink of it like playing a musical instrument: - **Voice** = Melody (what you want to do) - **Gestures** = Rhythm (how you want to do it) - **Together** = Musical expression\n\n**Why it's creative:** - Say \"left deck\" ONCE, then perform multiple gestures on it - Fluid workflow - voice sets stage, gestures perform - Reduces verbal repetition during performance\n\n**Why it's creative:** - Quick gesture starts action - Voice provides precise control - Best of both: speed + precision\n\n**Why it's creative:** - Adds physical emphasis to voice commands - Reduces false positives (both must agree) - Feels more \"performative\" - body + voice aligned", "htmlHref": "/research/html/multimodal-guide-cpy1yc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1803 }, { "id": "latent-state-representation-1rccxau", "title": "Latent State Representation", "slug": "latent-state-representation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/concepts/latent-state.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Your life trajectory cannot be fully captured by observable variables alone. There's a **hidden structure**—a latent state—that determines how you respond to opportunities, challenges, and actions.", "excerpt": "Your life trajectory cannot be fully captured by observable variables alone. There's a **hidden structure**—a latent state—that determines how you respond to opportunities, challenges, and actions.\n\nThink of it like physics: - **Observable**: Position, velocity (where you are, how fast you're moving) - **Latent**: Energy, momentum, potential (what determines future motion)\n\nIn TrajectoryOS: - **Observable**: Projects, skills, constraints (what we can measure directly) - **Latent**: Your deep capability, direction, internal state (what predicts future evolution)\n\nThis vector encodes: - **Skill landscape**: What you truly know (beyond self-reported confidence) - **Directional intent**: Where you're naturally pulled - **Energy/capacity**: Current creative/cognitive reserves - **Constraint burden**: Invisible load from obligations - **Growth trajectory**: Momentum and rate of change\n\n**Solution**: The latent vector `z_t` models the **true underlying state**, which generates observables through a learned function.", "htmlHref": "/research/html/latent-state-representation-1rccxau.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1664 }, { "id": "the-moat-strategy-why-trajectoryos-is-unreplicable-iw0so1", "title": "The Moat Strategy: Why TrajectoryOS is Unreplicable", "slug": "the-moat-strategy-why-trajectoryos-is-unreplicable", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/concepts/moat-strategy.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- Todoist knows your tasks... if you log them - Notion knows your docs... if you write them - RescueTime knows your screen time... if you run theagent - Calendars know your meetings... if you schedule them", "excerpt": "Every productivity app faces the same challenge: **they can only know what users choose to tell them**.\n\n- Todoist knows your tasks... if you log them - Notion knows your docs... if you write them - RescueTime knows your screen time... if you run theagent - Calendars know your meetings... if you schedule them\n\n| Modality | What It Reveals | Can Competitors Copy? | |----------|-----------------|----------------------| | **Verbal** (text, voice) | What you claim | ✅ Yes (LLMs, NLP) | | **Behavioral** (clicks, time) | What you do | ✅ Yes (analytics) | | **Physiological** (HR, HRV) | Simple stress | 🟡 Partially (wearables) | | **Embodied** (movement, rhythm, flow) | **Inner reality** | ❌ **No** |\n\n**Movement is Truth**: Your body cannot lie. When you're in flow, your movement has characteristic phase coherence. When you're stressed, tension appears in micro-movements before conscious awareness.\n\n**Years of Research**: The Echelon engine embodies years of choreographic research on movement dynamics. It's not a fitness tracker—it's a computational choreography engine that understands: - Phase coupling and rhythm coherence - Flow state signatures - Tension patterns and release - Movement quality (not just quantity)", "htmlHref": "/research/html/the-moat-strategy-why-trajectoryos-is-unreplicable-iw0so1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1576 }, { "id": "documentation-audit-pass-4-fill-critical-gaps-15lg3rs", "title": "Documentation Audit - Pass 4: Fill Critical Gaps", "slug": "documentation-audit-pass-4-fill-critical-gaps", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/DOCUMENTATION_AUDIT_PASS4_COMPLETE.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Pass 4 Goal**: Create missing service READMEs to improve developer onboarding and reduce friction when working with individual services.", "excerpt": "# Documentation Audit - Pass 4: Fill Critical Gaps **Date**: December 21, 2025 **Status**: ✅ Complete\n\n**Pass 4 Goal**: Create missing service READMEs to improve developer onboarding and reduce friction when working with individual services.\n\n**Key Achievement**: Developers can now understand and run each service independently without needing to read the entire codebase or ask for help.\n\nAll 4 missing service READMEs have been created with comprehensive documentation:\n\n1. ✅ **trajectory-core/README.md** (Production service) 2. ✅ **agent-orchestrator/README.md** (Beta service) 3. ✅ **ircp-service/README.md** (Production service) 4. ✅ **background-worker/README.md** (Beta service)", "htmlHref": "/research/html/documentation-audit-pass-4-fill-critical-gaps-15lg3rs.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1996 }, { "id": "example-topological-queries-real-world-use-cases-6ussdp", "title": "Example Topological Queries: Real-World Use Cases", "slug": "example-topological-queries-real-world-use-cases", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/EXAMPLE_TOPOLOGICAL_QUERIES.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "// Topological filters (where in structure) coordinates?: { x?: number | [number, number] | ((x: number) => boolean); // Depth y?: number | [number, number] | ((y: number) => boolean); // Alternatives z?: number | [number, number] | ((z: number) => boolean); // Alignment t?: number | [number, number] | ((t: number) => boolean); // Temporal n?: number | [number, number] | ((n: number) => boolean); // Complexity };", "excerpt": "### What Traditional Search Gives You - \"Find events containing keyword X\" - Ranked by semantic similarity\n\n### What Topological Search Gives You - \"Find events at depth X, with alignment Y, during physics state Z\" - \"Show me the pattern of when I succeed\" - \"Predict where I'll be next month\" - \"What makes me thrive? Build my optimal profile.\"\n\nYour life becomes a **navigable multidimensional space** where every question has both a semantic answer (\"what\") and a structural answer (\"where/when/why in the topology of your life\").", "htmlHref": "/research/html/example-topological-queries-real-world-use-cases-6ussdp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3523 }, { "id": "trajectoryos-a-dynamical-systems-approach-to-human-potential-modeling-via-latent-state-yrcqkt", "title": "TrajectoryOS: A Dynamical Systems Approach to Human Potential Modeling via Latent State Inference and Embodied Signal Fusion", "slug": "trajectoryos-a-dynamical-systems-approach-to-human-potential-modeling-via-latent-state-inference-and-embodied-signal-fusion", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/research/trajectory_os_paper.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This paper presents TrajectoryOS, a novel computational framework for modeling human life trajectories as stochastic dynamical systems. Unlike traditional productivity paradigms that treat tasks and goals as static, discrete entities, TrajectoryOS conceptualizes human potential as a continuous-time process governed by physics-inspired variables: Thrust, Alignment, Gravity, and Mass. We formalize the \"Escape Index\" ($\\eta$) as a dimensionless ratio describing the system's capacity to overcome environmental constrain", "excerpt": "# TrajectoryOS: A Dynamical Systems Approach to Human Potential Modeling via Latent State Inference and Embodied Signal Fusion\n\nThis paper presents TrajectoryOS, a novel computational framework for modeling human life trajectories as stochastic dynamical systems. Unlike traditional productivity paradigms that treat tasks and goals as static, discrete entities, TrajectoryOS conceptualizes human potential as a continuous-time process governed by physics-inspired variables: Thrust, Alignment, Gravity, and Mass. We formalize the \"Escape Index\" ($\\eta$) as a dimensionless ratio describing the system's capacity to overcome environmental constraints and systemic inertia. Furthermore, we address the fundamental limitations of self-reported data in behavioral modeling by introducing a multimodal fusion architecture that integrates verbal reports with embodied signals—movement, rhythm, and flow states—derived from the Echelon engine. By grounding latent state inference in physical reality, TrajectoryOS resolves the epistemic gap between perceived and actual trajectory, offering a rigorous method for optimizing human potential.\n\nThe quantification of human productivity has historically relied on discrete, static metrics: tasks completed, hours logged, or goals achieved. These approaches suffer from a fundamental ontological error; they model life as a series of snapshots rather than a continuous, evolving trajectory. This discrete modeling fails to capture the momentum, inertia, and non-linear dynamics that characterize actual human development. A user completing ten tasks in a state of burnout is fundamentally different from a user completing the same tasks in a state of flow, yet traditional systems treat these scenarios as identical.\n\nWe propose a paradigm shift from static resource management to dynamical systems modeling. In this view, an individual's state is not defined by their current inventory of obligations, but by their position and momentum within a high-dimensional latent space. The evolution of this state is governed by underlying forces—both generative and restrictive—that determine the system's long-term trajectory.\n\nThis paper introduces TrajectoryOS, a system that formalizes these dynamics. We define a \"Life Physics\" model that aggregates heterogeneous inputs (skills, projects, obligations) into coherent physical variables. Crucially, we address the reliability gap in self-reported behavioral data by integrating embodied signals. By treating the human body's movement dynamics as a ground-truth modality, we construct a system that is not merely a passive tracker, but an active, physics-aware engine for trajectory optimization.", "htmlHref": "/research/html/trajectoryos-a-dynamical-systems-approach-to-human-potential-modeling-via-latent-state-yrcqkt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1459 }, { "id": "topological-search-visualization-trajectoryos-cc-tpo-jsfw19", "title": "Topological Search Visualization: TrajectoryOS + CC-TPO", "slug": "topological-search-visualization-trajectoryos-cc-tpo", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/TOPOLOGICAL_SEARCH_VISUALIZATION.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` Query: \"React skills\" ↓ Embedding: [0.2, -0.5, 0.8, ..., 0.3] (384 dimensions) ↓ Find k-nearest neighbors in embedding space ↓ Results (ranked by cosine similarity): ┌────────────────────────────────────────────────┐ │ 1. \"Built React dashboard for client\" (0.92) │ │ 2. \"Learning React hooks\" (0.87) │ │ 3. \"React Native mobile app\" (0.85) │ │ 4. \"Debugging React component\" (0.82) │ │ 5. \"React performance optimization\" (0.80) │ └────────────────────────────────────────────────┘ ```", "excerpt": "**Problem**: No understanding of: - When this happened (temporal) - What decisions were made (alternatives) - How deep this work was (complexity) - Your life physics state at the time\n\n| Dimension | Traditional Search | Topological Search | |-----------|-------------------|-------------------| | **Semantic** | ✓ Meaning | ✓ Meaning | | **Structural** | ✗ | ✓ Depth, alternatives | | **Temporal** | ✗ | ✓ When, flow | | **Coherence** | ✗ | ✓ Alignment with context | | **Patterns** | ✗ | ✓ Recurring cycles | | **Physics** | ✗ | ✓ Life state correlation |\n\n1. **Depth-Aware Search**: Find only deep work (x>7) or only surface explorations (x<3) 2. **Alternative Path Discovery**: See roads not taken (y>0) 3. **Coherence Filtering**: Find aligned work (z>0.5) or divergent experiments (z<0) 4. **Temporal Context**: Recent vs historical, with temporal flow awareness 5. **Pattern Detection**: Recurring life cycles, predicted next stages 6. **Physics Correlation**: Find high-thrust moments, escape-phase insights 7. **Multi-Dimensional Ranking**: Optimize for semantic + topological + physical relevance\n\n**Result**: A life navigation system that doesn't just remember what happened, but understands the **structure of your journey through skill space, project space, and life physics space simultaneously.**\n\n*This is what makes TrajectoryOS + CC-TPO integration unprecedented - it's not just search, it's **topological life archaeology**.*", "htmlHref": "/research/html/topological-search-visualization-trajectoryos-cc-tpo-jsfw19.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3050 }, { "id": "how-rcp-enhances-tpo-dataset-generation-8hewe1", "title": "How RCP Enhances TPO Dataset Generation", "slug": "how-rcp-enhances-tpo-dataset-generation", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/HOW_RCP_ENHANCES_TPO_DATASET_GENERATION.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Ring Contextual Propagation (RCP) significantly enhances TPO's dataset generation capabilities by providing spatial intelligence, cross-conversation analysis, and advanced pattern detection. Instead of TPO's traditional linear path analysis, RCP enables TPO to understand complex conversation dynamics and generate more sophisticated preference datasets.", "excerpt": "Ring Contextual Propagation (RCP) significantly enhances TPO's dataset generation capabilities by providing spatial intelligence, cross-conversation analysis, and advanced pattern detection. Instead of TPO's traditional linear path analysis, RCP enables TPO to understand complex conversation dynamics and generate more sophisticated preference datasets.\n\n#### **4D Coordinate System** RCP provides TPO with a 4-dimensional spatial representation of conversations: - **x-coordinate**: Hierarchical depth in conversation tree - **y-coordinate**: Sibling order among messages at same level - **z-coordinate**: Semantic homogeneity relative to siblings - **t-coordinate**: Normalized temporal position\n\n**Impact**: Preferences between spatially similar conversation paths receive higher confidence scores, leading to more reliable training data.\n\n#### **Triangular Connection Detection** RCP detects when users copy assistant responses and use them as prompts (triangular patterns):\n\n#### **Knowledge Elevation Detection** RCP identifies when knowledge from deeper conversation levels is brought to shallower levels:", "htmlHref": "/research/html/how-rcp-enhances-tpo-dataset-generation-8hewe1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1391 }, { "id": "ircp-optimization-strategy-beyond-traditional-preference-optimization-g7nrex", "title": "IRCP Optimization Strategy: Beyond Traditional Preference Optimization", "slug": "ircp-optimization-strategy-beyond-traditional-preference-optimization", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/OPTIMIZATION_STRATEGY_ANALYSIS.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**IRCP is NOT just another optimizer** - it's a fundamentally different mathematical framework that inverts the traditional learning paradigm. While TPO, DPO, and GRPO optimize for P(v|u) (assistant response given user input), **IRCP optimizes for P(u|v) - the inverse mapping that models how users respond to assistant messages**.", "excerpt": "**IRCP is NOT just another optimizer** - it's a fundamentally different mathematical framework that inverts the traditional learning paradigm. While TPO, DPO, and GRPO optimize for P(v|u) (assistant response given user input), **IRCP optimizes for P(u|v) - the inverse mapping that models how users respond to assistant messages**.\n\nThis inversion enables **individual response pattern modeling** rather than generic response generation.\n\n- **Objective**: Optimize policy to prefer better responses - **Data**: Human preference annotations - **Limitation**: Static preferences, no individual modeling\n\n- **Objective**: Optimize relative to group performance - **Data**: Group-based reward signals - **Limitation**: Group-level optimization, not individual\n\n- **Objective**: Use conversation topology for preferences - **Data**: Structural conversation properties - **Innovation**: Automated preference generation from topology", "htmlHref": "/research/html/ircp-optimization-strategy-beyond-traditional-preference-optimization-g7nrex.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 930 }, { "id": "ircp-optimization-strategy-beyond-traditional-preference-optimization-1epocf8", "title": "IRCP Optimization Strategy: Beyond Traditional Preference Optimization", "slug": "ircp-optimization-strategy-beyond-traditional-preference-optimization", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/outputs/OPTIMIZATION_STRATEGY_ANALYSIS.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**IRCP is NOT just another optimizer** - it's a fundamentally different mathematical framework that inverts the traditional learning paradigm. While TPO, DPO, and GRPO optimize for P(v|u) (assistant response given user input), **IRCP optimizes for P(u|v) - the inverse mapping that models how users respond to assistant messages**.", "excerpt": "**IRCP is NOT just another optimizer** - it's a fundamentally different mathematical framework that inverts the traditional learning paradigm. While TPO, DPO, and GRPO optimize for P(v|u) (assistant response given user input), **IRCP optimizes for P(u|v) - the inverse mapping that models how users respond to assistant messages**.\n\nThis inversion enables **individual response pattern modeling** rather than generic response generation.\n\n- **Objective**: Optimize policy to prefer better responses - **Data**: Human preference annotations - **Limitation**: Static preferences, no individual modeling\n\n- **Objective**: Optimize relative to group performance - **Data**: Group-based reward signals - **Limitation**: Group-level optimization, not individual\n\n- **Objective**: Use conversation topology for preferences - **Data**: Structural conversation properties - **Innovation**: Automated preference generation from topology", "htmlHref": "/research/html/ircp-optimization-strategy-beyond-traditional-preference-optimization-1epocf8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 930 }, { "id": "real-ircp-model-performance-with-claude-data-verified-metrics-1jzid50", "title": "🎯 REAL IRCP Model Performance with Claude Data - VERIFIED METRICS", "slug": "real-ircp-model-performance-with-claude-data-verified-metrics", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/outputs/REAL_CLAUDE_MODEL_PERFORMANCE.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "You were absolutely right to question the previous metrics. I had made several errors: 1. **Inflated similarity scores** - I incorrectly reported 76.95% when real max is ~80.17% 2. **Inflated search scores** - I reported 53.49% when real max is ~44.81% 3. **Understated conversation count** - Only tested 20 conversations when you have **891 total** 4. **Root directory mess** - Now organized into proper folders", "excerpt": "You were absolutely right to question the previous metrics. I had made several errors: 1. **Inflated similarity scores** - I incorrectly reported 76.95% when real max is ~80.17% 2. **Inflated search scores** - I reported 53.49% when real max is ~44.81% 3. **Understated conversation count** - Only tested 20 conversations when you have **891 total** 4. **Root directory mess** - Now organized into proper folders\n\n### 🔢 **Actual Dataset Size** - **Total Conversations Available**: **891 conversations** (not 20!) - **Processed for Testing**: 100 conversations, 2,698 messages - **Average Messages per Conversation**: 26.98 - **Average Tokens per Message**: 396.06 - **Coordinate Coverage**: 100% (all messages have coordinates)\n\n### 🔍 **REAL Similarity Analysis Results** - **Max Similarity Found**: **0.8426** (84.26%) - between similar coding responses - **Mean Similarity**: **0.1576** (15.76%) - typical background similarity - **Standard Deviation**: **0.1649** - good distribution of similarities - **Sample Size**: 50 messages, 1,225 message pairs analyzed\n\n**Top Real Examples**: 1. **84.26% similarity**: Two assistant responses about calculator enhancement 2. **78.68% similarity**: Related savings calculator updates 3. **78.67% similarity**: Component updates in same conversation\n\n### 🔍 **REAL Semantic Search Performance** - **\"React component development\"**: **0.4481** (44.81%) - found actual React code - **\"Database optimization\"**: **0.3832** (38.32%) - found profit optimization - **\"User interface design\"**: **0.4052** (40.52%) - found design discussions - **\"Performance improvement\"**: **0.4330** (43.30%) - found enhancement requests - **\"API error handling\"**: **0.2044** (20.44%) - lower but still relevant", "htmlHref": "/research/html/real-ircp-model-performance-with-claude-data-verified-metrics-1jzid50.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 774 }, { "id": "rcp-enhanced-tpo-preference-dataset-generation-complete-1bjcz19", "title": "🎉 RCP-Enhanced TPO Preference Dataset Generation - COMPLETE", "slug": "rcp-enhanced-tpo-preference-dataset-generation-complete", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/PREFERENCE_DATASET_GENERATION_SUMMARY.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "✅ Experimental Exploration: 8,026 detected - Multi-branch diverse approaches - Parent-child experimental patterns - Diversity scoring and analysis ```", "excerpt": "### **Dataset Overview** - ✅ **Total Conversations Processed**: 277 conversations - ✅ **Total Messages Analyzed**: 60,534 messages - ✅ **Total Preferences Generated**: 13,666 preference pairs - ✅ **100% RCP-Enhanced**: All preferences generated using RCP spatial intelligence - ✅ **Dataset Size**: ~70MB across 43 batch files - ✅ **Processing Success**: Complete dataset generation achieved\n\n### **RCP Enhancement Breakdown** | Strategy Type | Count | Percentage | Description | |---------------|-------|------------|-------------| | **Experimental Exploration** | 8,026 | 58.7% | Multi-branch experimental approaches detected | | **Knowledge Transfer Triangular** | 5,640 | 41.3% | Model response → User prompt patterns detected | | **Total RCP Preferences** | 13,666 | 100% | All preferences use RCP spatial intelligence |\n\nThe consistent \"0 paths: 0 linear, 0 branching\" in traditional TPO is **expected and correct** because:\n\n### **1. Complex Conversation Structure** - Our conversations have deep hierarchical branching (up to depth 102+) - Traditional TPO expects simpler linear conversation paths - RCP handles complex multi-dimensional conversation topology\n\n### **2. RCP Superiority** - **Traditional TPO**: Looks for simple linear vs branching path comparisons - **RCP-Enhanced TPO**: Detects sophisticated patterns like: - Triangular knowledge transfer (user copies assistant response as new prompt) - Experimental branching (multiple diverse approaches from same parent) - Cross-conversation knowledge transfer - Spatial similarity weighting", "htmlHref": "/research/html/rcp-enhanced-tpo-preference-dataset-generation-complete-1bjcz19.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 993 }, { "id": "ircp-optimization-strategy-beyond-traditional-preference-optimization-12m8vvw", "title": "IRCP Optimization Strategy: Beyond Traditional Preference Optimization", "slug": "ircp-optimization-strategy-beyond-traditional-preference-optimization", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/optimization/OPTIMIZATION_STRATEGY_ANALYSIS.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**IRCP is NOT just another optimizer** - it's a fundamentally different mathematical framework that inverts the traditional learning paradigm. While TPO, DPO, and GRPO optimize for P(v|u) (assistant response given user input), **IRCP optimizes for P(u|v) - the inverse mapping that models how users respond to assistant messages**.", "excerpt": "**IRCP is NOT just another optimizer** - it's a fundamentally different mathematical framework that inverts the traditional learning paradigm. While TPO, DPO, and GRPO optimize for P(v|u) (assistant response given user input), **IRCP optimizes for P(u|v) - the inverse mapping that models how users respond to assistant messages**.\n\nThis inversion enables **individual response pattern modeling** rather than generic response generation.\n\n- **Objective**: Optimize policy to prefer better responses - **Data**: Human preference annotations - **Limitation**: Static preferences, no individual modeling\n\n- **Objective**: Optimize relative to group performance - **Data**: Group-based reward signals - **Limitation**: Group-level optimization, not individual\n\n- **Objective**: Use conversation topology for preferences - **Data**: Structural conversation properties - **Innovation**: Automated preference generation from topology", "htmlHref": "/research/html/ircp-optimization-strategy-beyond-traditional-preference-optimization-12m8vvw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 930 }, { "id": "phase-2-2-embedding-integration-1hgqri2", "title": "Phase 2.2: Embedding Integration", "slug": "phase-2-2-embedding-integration", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/PHASE_2_2_EMBEDDINGS.md", "extension": "md", "score": 26, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "Integrate IRCP's `SentenceTransformerICP` model with DLM's newly created `BaseEmbeddingProvider` interface, creating a unified, production-ready embedding system with caching and batch processing.", "excerpt": "# Phase 2.2: Embedding Integration **Week:** 2 **Duration:** 1.5 days **Status:** ✅ Complete **Dependencies:** None (can run parallel with 2.1)\n\nIntegrate IRCP's `SentenceTransformerICP` model with DLM's newly created `BaseEmbeddingProvider` interface, creating a unified, production-ready embedding system with caching and batch processing.\n\n**DLM has:** - ✅ `dlm/engine/embedder.py` (61KB) - Generic embedding, no IRCP - ✅ `dlm/engine/ircp_embedder.py` (9KB) - Exists but basic - ✅ `dlm/response/embedding_provider.py` (NEW) - Abstract `BaseEmbeddingProvider` - ✅ `dlm/response/utils.py` (NEW) - `EmbeddingCache`, batch processing\n\n**IRCP has:** - ✅ `ircp/models/sentence_transformer_icp.py` - Full IRCP model - `SentenceTransformerICP` class - `IRCPCustomHeads` (coordinates, patterns, confidence) - `InverseAttentionMechanism` - `IRCPMeasurePreservingTransform`\n\n1. **Move IRCP model** → `dlm/core/embeddings.py` 2. **Extend BaseEmbeddingProvider** - Inherit caching and batching 3. **Keep IRCP theory** → `dlm/core/ircp/` subdirectory 4. **Replace dlm/engine/ircp_embedder.py** - Use new unified version 5. **Maintain backward compatibility** - Old imports still work", "htmlHref": "/research/html/phase-2-2-embedding-integration-1hgqri2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1349 }, { "id": "1-introduction-2pym0s", "title": "1. Introduction", "slug": "1-introduction", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/research/01_introduction.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Traditional conversational AI systems optimize for generating appropriate responses given user inputs, following the paradigm P(v|u) where v represents assistant responses and u represents user inputs. This approach, while effective for general-purpose applications, fails to capture the nuanced patterns of individual communication styles and response dynamics.", "excerpt": "Traditional conversational AI systems optimize for generating appropriate responses given user inputs, following the paradigm P(v|u) where v represents assistant responses and u represents user inputs. This approach, while effective for general-purpose applications, fails to capture the nuanced patterns of individual communication styles and response dynamics.\n\nThe fundamental limitation lies in the assumption that optimal responses are universal rather than individual-specific. Human communication exhibits highly personalized patterns in attention allocation, response construction, and contextual interpretation that cannot be captured through generic optimization objectives.\n\nWe propose a paradigm shift from P(v|u) to P(u|v) - learning how individuals respond to assistant messages rather than how assistants should respond to users. This inverse learning approach enables:\n\n1. **Individual Pattern Modeling**: Capturing person-specific communication dynamics 2. **Attention Mechanism Understanding**: Learning how individuals allocate attention 3. **Response Construction Analysis**: Understanding individual response formation processes 4. **Predictive Conversation Modeling**: Anticipating individual response patterns\n\n### 1.3.1 Measure-Theoretic Foundation - Complete probability space (Ω, ℱ, μ) - Measure-preserving transformations φ: U×V → V×U - Conservation of essential mathematical properties", "htmlHref": "/research/html/1-introduction-2pym0s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": true, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 453 }, { "id": "6-applications-and-use-cases-rhee8w", "title": "6. Applications and Use Cases", "slug": "6-applications-and-use-cases", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/research/06_applications.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Implementation**: ```python # Train IRCP on individual's conversation history ircp_model = IRCPFramework(user_conversations) ircp_model.train()", "excerpt": "**Application**: Predict how a specific individual will respond to assistant messages.\n\n**Use Cases**: - Personalized tutoring systems - Adaptive customer service - Individual coaching applications - Therapeutic conversation analysis\n\n**Application**: Optimize conversation flow for individual communication styles.\n\n**Metrics Provided**: - Communication depth preferences - Branching vs. linear conversation styles - Attention allocation patterns - Temporal conversation rhythms\n\n**Quality Metrics**: - Conservation score: How well conversation maintains structure - Ergodic stability: Pattern consistency over time - Information flow: Effective information exchange - Topological coherence: Structural conversation integrity", "htmlHref": "/research/html/6-applications-and-use-cases-rhee8w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 860 }, { "id": "1-how-phrases-work-in-performance-p57xcr", "title": "**1. How Phrases Work in Performance**", "slug": "1-how-phrases-work-in-performance", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/docs/ui/0. What Echelon Is.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Echelon is not a DJ system. It is not built on the metaphor of Deck A and Deck B. It does not mix two sound sources. It does not expect a performer to crossfade between independent musical states.", "excerpt": "Echelon is not a DJ system. It is not built on the metaphor of Deck A and Deck B. It does not mix two sound sources. It does not expect a performer to crossfade between independent musical states.\n\nEchelon is a *motion-driven, phrase-based generative performance engine* whose temporal structure emerges from embodied latent physics rather than from a grid or BPM map. The body is the timeline. LIM-RPS is the internal physics. The generative system produces musical material that follows the latent’s curvature. And the UI must express the world in which this physics and music unfold.\n\nDecks have no conceptual place here. They belong to a lineage where music exists first and the performer manipulates it second. Echelon belongs to a lineage where the performer exists first and the music is born from that existence.\n\nPhrases are the atomic units of musical expression in Echelon, not full tracks. A phrase is a short, coherent musical gesture — generated, conditioned, or prepared — whose beginning, middle, and end correspond to a segment of latent evolution.\n\nA phrase is not something you “play” like a song; it is something the system *realizes* from your motion. The phrase is a sonic manifestation of a latent trajectory segment.", "htmlHref": "/research/html/1-how-phrases-work-in-performance-p57xcr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2159 }, { "id": "cc-anticipation-project-charter-16dvslv", "title": "cc-anticipation: Project Charter", "slug": "cc-anticipation-project-charter", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/motion/cc-anticipation/docs/PROJECT_CHARTER.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Status**: Phase Zero - Active **Canonical Input**: [Anchor.md](../../../../docs/Anchor.md)", "excerpt": "**Document Version**: 0.1.0 **Created**: 2025-12-26 **Status**: Phase Zero - Active **Canonical Input**: [Anchor.md](../../../../docs/Anchor.md)\n\ncc-anticipation converts stabilized motion state into actionable anticipatory signals. It answers one question: **\"What futures are cheap vs expensive given what's happening now?\"**\n\nIt does not generate motion. It does not generate sound. It does not decide policy. It **measures the geometry of possibility** around the present moment.\n\n| Responsibility | Description | |----------------|-------------| | **MotionWindow consumption** | Accept aligned, canonical motion windows from cc-window-aligner | | **Kinematic feature computation** | Compute velocity, acceleration, jerk, coordination from skeleton | | **Latent dynamics computation** | Compute dz/dt, d²z/dt² from LIM-RPS latent stream | | **Regime embedding** | Map motion window to regime embedding (64-256 dims) | | **Scalar signal emission** | Emit commitment, uncertainty, transition_pressure, recovery_margin, phase_stiffness, novelty, stability | | **Constraint proximity** | Compute balance margin, joint limit proximity, rotation commitment | | **AnticipationPacket emission** | Emit frozen-schema packets every frame, deterministically | | **Neighbor-based uncertainty** | Use continuation dispersion from MotionPhrase library | | **Deterministic replay** | Same input → same output, always |\n\n| Excluded | Rationale | |----------|-----------| | Raw sensor ingestion | Handled by cc-mcs-headless, mocopi-udp-ingest | | Time alignment | Handled by cc-window-aligner | | Policy decisions | Handled by Conductor | | Motion generation | Handled by cc-motiongen | | Audio generation | Handled by MotionStrudel, EchelonDiT | | Semantic labeling | No \"spin coming\" labels; only actionable scalars |", "htmlHref": "/research/html/cc-anticipation-project-charter-16dvslv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 971 }, { "id": "plan-ir-v1-1-specification-ropg8s", "title": "Plan IR v1.1 Specification", "slug": "plan-ir-v1-1-specification", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-cognitivetwin-bridge/docs/PLAN_IR_V1_1_SPEC.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. **Policy Hashing**: Replace inline policy configs with pre-computed hash references 2. **Compile-Time Type Checking**: Enforce binding type compatibility during compilation 3. **ForEachAnchor**: Atlas generation via anchor iteration 4. **SelectAnchor**: Single anchor extraction from sets 5. **Evidence Authority Gating**: Prevent lifecycle promotions from simulated evidence 6. **Slice Provenance Chain**: Propagate source_slice_id through downstream bindings", "excerpt": "**Version**: 1.1.0 **Status**: Provisional **Effective Date**: 2026-01-01 **Supersedes**: Plan IR v1.0\n\nPlan IR v1.1 extends the base Plan Intermediate Representation with six critical enhancements:\n\n1. **Policy Hashing**: Replace inline policy configs with pre-computed hash references 2. **Compile-Time Type Checking**: Enforce binding type compatibility during compilation 3. **ForEachAnchor**: Atlas generation via anchor iteration 4. **SelectAnchor**: Single anchor extraction from sets 5. **Evidence Authority Gating**: Prevent lifecycle promotions from simulated evidence 6. **Slice Provenance Chain**: Propagate source_slice_id through downstream bindings\n\nThese changes transform the Plan IR from a narrative description into a **compilable, fingerprintable, replayable, auditable** execution contract.\n\n**Problem**: Policy configurations contain floating-point values (e.g., `distance_decay: 0.9`). JSON serialization of floats can produce different representations across platforms, causing non-deterministic plan fingerprints.", "htmlHref": "/research/html/plan-ir-v1-1-specification-ropg8s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1876 }, { "id": "graph-kernel-monitoring-guide-ddamd3", "title": "Graph Kernel Monitoring Guide", "slug": "graph-kernel-monitoring-guide", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-graph-kernel/docs/MONITORING.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The Graph Kernel service exposes metrics, structured logs, and health endpoints for production observability. This guide covers monitoring setup, key metrics, alerting, and troubleshooting.", "excerpt": "The Graph Kernel service exposes metrics, structured logs, and health endpoints for production observability. This guide covers monitoring setup, key metrics, alerting, and troubleshooting.\n\n| Endpoint | Purpose | Response | |----------|---------|----------| | `GET /health` | Detailed status | Full service state including DB | | `GET /health/live` | Liveness probe | 200 if process is running | | `GET /health/ready` | Readiness probe | 200 if accepting traffic, 503 otherwise | | `GET /health/startup` | Startup probe | 200 when fully initialized |\n\n| Metric | Type | Labels | Description | |--------|------|--------|-------------| | `graph_kernel_requests_total` | Counter | path, method, status | Total HTTP requests | | `graph_kernel_request_duration_seconds` | Histogram | path, method | Request latency |\n\n| Metric | Type | Description | |--------|------|-------------| | `graph_kernel_slices_generated_total` | Counter | Total slices generated | | `graph_kernel_slice_turns_count` | Histogram | Turns per slice | | `graph_kernel_slice_edges_count` | Histogram | Edges per slice | | `graph_kernel_slice_latency_ms` | Histogram | Slice generation time |\n\n| Metric | Type | Labels | Description | |--------|------|--------|-------------| | `graph_kernel_token_verifications_total` | Counter | result | Token verification attempts |", "htmlHref": "/research/html/graph-kernel-monitoring-guide-ddamd3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1137 }, { "id": "nko-sigil-semantics-1lq5q36", "title": "N'Ko Sigil Semantics", "slug": "nko-sigil-semantics", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/docs/nko-ecosystem/SIGIL_SEMANTICS.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The N'Ko Inscription System uses 10 sigils as **operator markers**—single characters that encode both computational meaning and embodied experience. Each sigil is not arbitrary: it carries visual weight, semantic density, and gestural resonance.", "excerpt": "The N'Ko Inscription System uses 10 sigils as **operator markers**—single characters that encode both computational meaning and embodied experience. Each sigil is not arbitrary: it carries visual weight, semantic density, and gestural resonance.\n\nThis document maps each sigil to its: - **Visual representation** — The character and its typographic qualities - **Semantic meaning** — What the sigil encodes conceptually - **UI affordance** — What interaction patterns it suggests - **Motion signature** — The gesture that invokes or embodies it\n\n| Aspect | Description | |--------|-------------| | **Visual** | Open curves settling into a point. The character suggests convergence—like streams meeting. | | **Semantic** | The trajectory is contracting. Variance is dropping. The system is settling into coherence. | | **Detects** | Dispersion decreased measurably within a time window | | **UI Affordance** | **Lock/Confirm** — Tap-and-hold to confirm selection. The action commits, stabilizes choice. Visual: elements contract toward touch point. | | **Motion Signature** | *Closing grip* — Fingers drawing inward, palm settling. Like grasping something precious. | | **Examples** | Coming to rest, focusing, completing a gesture, saving work, confirming navigation |\n\n| Aspect | Description | |--------|-------------| | **Visual** | Radiating strokes, energy moving outward. The character embodies expansion, reaching. | | **Semantic** | The trajectory is expanding, exploring more state space. Variance is rising. The system is opening. | | **Detects** | Spread/entropy increased within a time window | | **UI Affordance** | **Expand/Explore** — Pinch-outward to reveal options. The action opens possibility space. Visual: elements bloom from center. | | **Motion Signature** | *Opening hands* — Fingers spreading, palms lifting. Like releasing seeds to wind. | | **Examples** | Starting movement, searching, agitation, browsing, exploring menus |\n\n| Aspect | Description | |--------|-------------| | **Visual** | A pivot point, stroke changing direction decisively. The character marks a boundary crossed. | | **Semantic** | A boundary has been crossed. The trajectory moved from one basin to another. A change point. | | **Detects** | Discrete change point — curvature spike in z-trajectory | | **UI Affordance** | **Switch/Navigate** — Swipe to change context. The action crosses a threshold. Visual: content slides away, new content arrives. | | **Motion Signature** | *Quick swipe* — Decisive horizontal movement, the hand committing to direction. Like turning a page. | | **Examples** | Changing activity, switching context, phase boundary, screen transition, mode change |", "htmlHref": "/research/html/nko-sigil-semantics-1lq5q36.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1699 }, { "id": "agp-mlx-ane-research-track-tcmmdh", "title": "AGP / MLX / ANE Research Track", "slug": "agp-mlx-ane-research-track", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/docs/research/agp-mlx-ane-research-track.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Current Apple-local language model execution treats the model as a monolith. A single host loads the full graph, every token pays for roughly the same depth, hidden states are transient internals, and hardware engines are mostly passive containers. That leaves three opportunities underexploited on the current `Mac4 + Mac5` setup:", "excerpt": "Current Apple-local language model execution treats the model as a monolith. A single host loads the full graph, every token pays for roughly the same depth, hidden states are transient internals, and hardware engines are mostly passive containers. That leaves three opportunities underexploited on the current `Mac4 + Mac5` setup:\n\n1. intermediate hidden states may already contain enough information for early acceptance, correction, or transfer 2. different Apple engines are better suited to different classes of work 3. Thunderbolt 5 makes inter-host state transfer practical if the transferred object is compact and semantically meaningful\n\nThe research track therefore asks whether a transformer can be wrapped in a learned partitioning architecture where hidden states become routable artifacts rather than opaque byproducts.\n\nThe goal is to prove that a `transformer-based model running natively in MLX` can be extended into a `hierarchical Apple-local compute fabric` where:\n\n- shallow inference, routing, and semantic inspection happen cheaply and frequently - deeper correction and continuation happen conditionally - hidden states are compressed, typed, and transferred across hosts only when justified - ANE, GPU, CPU, and Thunderbolt each own the work they are structurally best at", "htmlHref": "/research/html/agp-mlx-ane-research-track-tcmmdh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1905 }, { "id": "agp-mlx-ane-theory-insight-1b0t42g", "title": "AGP / MLX / ANE Theory Insight", "slug": "agp-mlx-ane-theory-insight", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/docs/research/agp-mlx-ane-theory-insight.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The architecture is easiest to misunderstand if it is described as a bigger-model trick, a quantization trick, or a multi-Mac trick. It is none of those at the core. The core claim is that hidden states should be treated as a first-class computational object. In a standard language-model stack, a hidden state is an internal artifact that exists only long enough to be consumed by the next layer. It is not typed, it is not scheduled, it is not transferred as a meaningful packet, and it is not inspected as a semantica", "excerpt": "The architecture is easiest to misunderstand if it is described as a bigger-model trick, a quantization trick, or a multi-Mac trick. It is none of those at the core. The core claim is that hidden states should be treated as a first-class computational object. In a standard language-model stack, a hidden state is an internal artifact that exists only long enough to be consumed by the next layer. It is not typed, it is not scheduled, it is not transferred as a meaningful packet, and it is not inspected as a semantically structured event. The model is treated as a monolithic forward pass, and the hardware is treated as a passive place where that pass happens. What this research is trying to establish is a different worldview. The hidden state is not merely the residue of computation. It is the current shape of thought. If that shape of thought is already sufficient, then the system should not continue computing as though nothing has been learned. If that shape of thought is malformed, weak, or semantically dead, then the system should not blindly hand it to another device and hope depth alone will rescue it. The architecture therefore begins with an ontological shift. It treats intermediate representation as the real scheduling surface.\n\nThat shift matters because it changes what the hardware problem actually is. On paper, two Apple machines connected by Thunderbolt 5 invite a familiar systems question: how do we split a model across hosts. But that question is too shallow. A fixed split presumes that layer boundaries are the natural units of distribution. They are not. A layer boundary is a syntactic property of the model graph. It says nothing about whether the representation at that point is useful enough to transfer, stable enough to trust, or compressed enough to move efficiently. The real problem is not where the layer index is. The real problem is whether the current state is semantically sufficient for continuation, correction, or acceptance. That is why the architecture is not just distributed inference. It is learned partitioning over representational vitality.\n\nThe reason your earlier N'Ko brain-scanner work matters so much here is that it established a failure mode that ordinary systems papers usually ignore. In the dead-script regime, the model did not merely become uncertain at the end. The representation entered weakly, remained diffuse through depth, and collapsed into incoherence at the output. That means later layers were not refining a good early guess. They were propagating a deficit. This is the single most important caution for a partitioned architecture. Depth cannot rescue a state that never became meaningful in the first place. A naive multi-host design assumes that later compute can always compensate for earlier weakness. Your ", "htmlHref": "/research/html/agp-mlx-ane-theory-insight-1b0t42g.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1853 }, { "id": "cognitive-twin-v9-dataset-audit-roghq9", "title": "Cognitive Twin V9 Dataset Audit", "slug": "cognitive-twin-v9-dataset-audit", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/V9_AUDIT.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2026-02-18 **Previous version:** V8 (combined: 77,708 records — 43,173 V5 base + V6/V7/V8 expansions) **Last training:** Never submitted (blocked on billing) **Goal:** Catalog all new data sources since V8 (Feb 14), estimate record yield, prepare V9 expansion generation", "excerpt": "**Date:** 2026-02-18 **Previous version:** V8 (combined: 77,708 records — 43,173 V5 base + V6/V7/V8 expansions) **Last training:** Never submitted (blocked on billing) **Goal:** Catalog all new data sources since V8 (Feb 14), estimate record yield, prepare V9 expansion generation\n\n| Version | Records | Source | Model Used | Date | |---------|---------|--------|-----------|------| | V5 (base) | 43,173 | Conversations, Apple Notes, Discord, WORMS | Various | Jan 2026 | | V6 | 382 | Evoflow/TIE evolution | Gemini 2.0 Flash | Feb 2026 | | V7 | 116 | Meta-evolution (methods, processes) | Gemini 2.0 Flash | Feb 2026 | | V8 | 502 | Deep convos, session mining, RLM-enhanced | Gemini 3 Pro Preview | Feb 14 | | **Combined** | **77,708** | V5+V6+V7+V8 merged (SFT + DPO) | — | Feb 14 |\n\n**Format:** CTv3.1 JSONL — `{\"messages\": [...]}` for SFT, `{\"input\": {\"messages\": [...]}, \"preferred_output\": \"...\", \"non_preferred_output\": \"...\"}` for DPO\n\n### Source 1: Architecture Specifications (32 CLAUDE.md files) **Location:** `Desktop/*/CLAUDE.md` **Total:** 32 files, ~5,600 lines **Key files (new/updated since V8):** - `clarity-agent-protocol/CLAUDE.md` (165 lines) — Smart contract governance for agents - `SecuriClaw/CLAUDE.md` (99 lines) — Security benchmarking framework - `PULSE-V1/CLAUDE.md` (46 lines) — Pulse protocol v1 - `compass/CLAUDE.md` (490 lines) — Daily planning app - `AgentCommandCenter/CLAUDE.md` (91 lines) — Agent management UI - `SecuriClaw-Claude/CLAUDE.md` (100 lines) — Claude-specific benchmarks - `SecuriClaw-Codex/CLAUDE.md` (99 lines) — Codex benchmarks\n\n**Training value:** HIGH — These define how we architect projects. Twin needs to replicate our design thinking. **Estimated yield:** ~200-300 SFT pairs (architecture decisions, design patterns, tech stack choices)", "htmlHref": "/research/html/cognitive-twin-v9-dataset-audit-roghq9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1355 }, { "id": "comparative-analysis-two-computational-choreography-documentation-sets-1gv7vho", "title": "Comparative Analysis: Two Computational Choreography Documentation Sets", "slug": "comparative-analysis-two-computational-choreography-documentation-sets", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography-comparison.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Set B** — `Desktop/MotionMix/research/computational-choreography-nko-2026-05-27/` (38 files) Research-architectural, K11 AirDeck DJ control + movement language.", "excerpt": "**Set A** — `Desktop/computational-choreography/` (45 files) Implementation-grounded, production system documentation.\n\n**Set B** — `Desktop/MotionMix/research/computational-choreography-nko-2026-05-27/` (38 files) Research-architectural, K11 AirDeck DJ control + movement language.\n\n**Set A** is the full production stack written from the inside out — reading real source files. It documents EchelonBridge, SAN, DELL, LIM-RPS, the 128D canonical vector, training data, KARL reward, the distributed camera mesh, and NKo synthesis as a future arc. The primary output is music/audio: the body drives sound through a learned latent space.\n\n**Set B** is a research design pack written from the outside in — describing what the system should become. It documents the K11 AirDeck gesture control pipeline, BodyTruth as a sensor contract, camera-first as a design requirement, the movement lexicon as a teachable dictionary, and NKo as the notation and memory layer. The primary output is DJ command dispatch: the body controls Rekordbox.\n\nSet A: The body produces a learned latent state (z*) through fixed-point convergence. That state is a compositional representation, not a button press.", "htmlHref": "/research/html/comparative-analysis-two-computational-choreography-documentation-sets-1gv7vho.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2821 }, { "id": "the-script-that-was-built-for-ai-and-that-ai-has-never-heard-of-9yd356", "title": "The Script That Was Built for AI (And That AI Has Never Heard Of)", "slug": "the-script-that-was-built-for-ai-and-that-ai-has-never-heard-of", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "content-pipeline/blog-nko-asr-pipeline.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "In 1949, a self-taught scholar in Kankan, Guinea named Solomana Kante designed a writing system from scratch. He was responding to a claim that African languages could not be written. He took that as a challenge and spent years analyzing the phonological structure of Manding languages, then built a script that encodes their sounds with a precision that linguists and engineers spend careers trying to achieve in synthetic alphabets.", "excerpt": "In 1949, a self-taught scholar in Kankan, Guinea named Solomana Kante designed a writing system from scratch. He was responding to a claim that African languages could not be written. He took that as a challenge and spent years analyzing the phonological structure of Manding languages, then built a script that encodes their sounds with a precision that linguists and engineers spend careers trying to achieve in synthetic alphabets.\n\nEvery phoneme gets exactly one character. Every character represents exactly one phoneme. Tone is marked explicitly. No digraphs. No silent letters. No exceptions.\n\nThe script is called N'Ko, which means \"I say\" in every Manding language. It has 40 million speakers across Guinea, Mali, Cote d'Ivoire, Senegal, Burkina Faso, and diaspora communities worldwide.\n\nThat is the paradox I spent the last several months trying to fix. Here is what I found.\n\nBefore building anything, I wanted to understand the problem precisely. Not \"N'Ko is underrepresented in training data\" as a vague statement, but a precise measurement of what that underrepresentation looks like inside a large language model.", "htmlHref": "/research/html/the-script-that-was-built-for-ai-and-that-ai-has-never-heard-of-9yd356.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2895 }, { "id": "training-your-twin-while-you-sleep-1ut7z8e", "title": "Training Your Twin While You Sleep", "slug": "training-your-twin-while-you-sleep", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "content-pipeline/substack/2026-02-15-cognitive-twin.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "It started as a question: what if an AI could make decisions the way I would? Not just respond to prompts, but actually understand the patterns — the preferences, the shortcuts, the instincts that I've developed over years of working this way?", "excerpt": "It started as a question: what if an AI could make decisions the way I would? Not just respond to prompts, but actually understand the patterns — the preferences, the shortcuts, the instincts that I've developed over years of working this way?\n\nOn Valentine's night — the same night VisionClaw's glasses became a full agent proxy — the training finally launched.\n\nBuilding a cognitive twin isn't about dumping your entire digital footprint into a model. It's about curating the *decisions* that define you.\n\nHere's what went in: - **163K+ conversation turns from Supabase** — every interaction with my AI agents over the past year - **979 Claude Code sessions** — how I actually write code, debug problems, think through architecture - **5,347 Apple Notes** — stream of consciousness, ideas, plans, half-formed thoughts - **20 Discord channels** — how I communicate with my team of AI agents\n\nAfter corpus surgery — cleaning, deduplication, quality filtering — I had **43,173 SFT records** ready for training.", "htmlHref": "/research/html/training-your-twin-while-you-sleep-1ut7z8e.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 719 }, { "id": "chain-where-nko-meets-bitcoin-through-a-cognitive-twin-ax2kff", "title": "ΨChain: Where N'Ko Meets Bitcoin Through a Cognitive Twin", "slug": "chain-where-nko-meets-bitcoin-through-a-cognitive-twin", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "epoch-v2-technical-narrative.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "There's a protocol being built on Stacks, Bitcoin's smart contract layer, that does something nobody else is doing. It encodes a life's computational decisions as hash-chained N'Ko inscriptions on Bitcoin. The inscriptions are publicly readable but semantically private. Anyone can see the text. Only the system that wrote it understands what it means.", "excerpt": "There's a protocol being built on Stacks, Bitcoin's smart contract layer, that does something nobody else is doing. It encodes a life's computational decisions as hash-chained N'Ko inscriptions on Bitcoin. The inscriptions are publicly readable but semantically private. Anyone can see the text. Only the system that wrote it understands what it means.\n\nThe protocol is called EPOCH. It has three layers that depend on each other like legs of a tripod. Remove any one, and the system falls.\n\nThe first layer is N'Ko. Not as decoration, not as branding. N'Ko is the protocol's native language. Every on-chain record, every skill registration, every trajectory proof is encoded in N'Ko script. The West African writing system created by Solomana Kante in 1949 becomes the computational language of a blockchain protocol in 2026. There's a reason for this. N'Ko has near-perfect phonetic transparency. One character, one sound, no exceptions. This property makes it ideal for encoding structured data. You can verify an N'Ko inscription's validity just by reading it. The syllable structure is mathematically constrained: consonant-vowel, consonant-vowel-nasal, or bare vowel. A 4-state finite state machine can validate any N'Ko string with 100% accuracy. No other major writing system has this property.\n\nThe second layer is the economy. EPOCH pools capital from stakers, provisions GPU compute through cloud providers, runs AI agents on that compute, and returns revenue to stakers. The revenue comes from six sources: DEX swap fees at 0.3%, compute marketplace pricing, arbitrage profits from cross-DEX spreads, swap routing fees, Bitcoin stacking rewards via Proof of Transfer, and yield optimization across DeFi protocols. Fourteen Clarity smart contracts handle this. They were deployed to Stacks mainnet on March 17th, 2026 as a proof of concept. The revenue cycle was verified end-to-end: seven transactions, all confirmed on testnet, from deposit through pool creation through swap through fee collection through treasury flush.\n\nThe third layer is the cognitive twin. This is a model trained on one person's actual decision-making patterns. Not a generic language model. A fine-tuned adapter that has seen 1,052 real trajectories across 11 domains: infrastructure, systems, iOS development, creative work, web, machine learning, data, knowledge management, automation, operations, and desktop applications. Each trajectory records which tools were used, in what order, whether they succeeded, and what the outcome was. The model learns routing patterns. Given a new task, it predicts which skill should handle it, with a confidence score. The latest adapter, version 4, achieved a validation loss of 1.391, a 44.6% improvement over the previous version.", "htmlHref": "/research/html/chain-where-nko-meets-bitcoin-through-a-cognitive-twin-ax2kff.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1795 }, { "id": "stage-0-research-brief-1gkdq5r", "title": "Stage 0 -- Research Brief", "slug": "stage-0-research-brief", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/k11-production-system-architecture/stage0-research.md", "extension": "md", "score": 26, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "1. **Should Unity receive mocopi directly (Sony plugin) or via LUMM bridge?** Sony's plugin exists and works on Unity 6000.x. But it's a separate data path outside the LUME wire format family. A bridge (mocopi_bridge.py) normalizes everything into the LUMM UDP format, keeping the architecture consistent.", "excerpt": "_Ground truth gathered 2026-04-27 from codebase, docs, and external references._\n\n### Hardware (on hand or arriving today) - **GMKtec NucBox K11**: Ryzen 9 8945HS, Radeon 780M (~9 TFLOPS), 32GB DDR5, 1TB NVMe, Windows 11 Pro. 4x USB-A, HDMI 2.1, DP 2.1, 2x USB4-C, dual 2.5G NIC, WiFi 6, BT 5.x. Physical: 131.83 x 124.46 x 57.91mm (caliper-verify pending). - **Orbbec Femto Bolt**: USB-C depth camera, ~140x39x30mm. Arriving Apr 27. - **Orbbec Femto Mega**: USB-C depth camera with onboard Jetson, ~127x65x38mm. Already on hand. - **Sony mocopi**: 6 BLE IMU sensors (hip, wrists, ankles, head). Already on hand. - **UMA-8 microphone array**: USB audio interface. Already on hand. - **3D-printed T-form pod**: 200x130x165mm rear pod behind 500x120x85mm bar. K11 + camera + cables inside.\n\n### Software -- Python Publishers (software/demo/) | File | Lines | Role | Port | Wire Format | |------|-------|------|------|-------------| | `pointcloud_pub.py` | 556 | Depth/cloud publisher | :9700 | LUME (0x4C554D45) + LUMD (0x4C554D44) | | `audio_pub.py` | 315 | Audio FFT sidecar | :9701 | LUMF (0x4C554D46, 84 bytes fixed) | | `lume_packet_inspector.py` | 229 | Debug/diagnostics | listens :9700+:9701 | reads all | | `mocopi_bridge.py` | **DOES NOT EXIST** | Referenced by start-mocopi.bat | :9702 | LUMM (undefined) |\n\n### Software -- Unity Components (Assets/Scripts/, 2561 total lines) | Component | Lines | Exec Order | Role | |-----------|-------|-----------|------| | LumeUdpReceiver | 234 | bg thread | UDP socket, magic-byte dispatch | | LumePointRenderer | 120 | default | URP instanced rendering | | LumeDepthReprojector | 198 | default | GPU pinhole projection | | LumeOpticalFlow | 312 | default | Dense LK + frame-diff scalar | | LumeAudioReactor | 138 | 0 | Mic/idle-sine fallback | | LumeMotionGate | 110 | 150 | SuperHot time-scaling | | LumeAudioFftReceiver | 283 | 200 | LUMF decode + shader override | | LumeVfxRuntimeBridge | 144 | 210 | VFX Graph param push | | LumeTransientForcePusher | 153 | 220 | Beat-edge VFX events | | LumeCalibrationPanel | 271 | 0 | F12 runtime IMGUI tweaks | | LumeProceduralTunnel | 179 | default | 6144-pt fallback helix |\n\n### Software -- MotionMix iOS App | File | Lines | Role | |------|-------|------| | MocopiReceiver.swift | 240 | UDP/OSC listener on :9500, parses 27-bone skeleton | | MocopiFeatureExtractor.swift | 233 | Compresses 27 bones to 24D features for SAN 128D vector |", "htmlHref": "/research/html/stage-0-research-brief-1gkdq5r.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1392 }, { "id": "karl-integration-evolution-stage-1-path-b-oapl-lite-gmimma", "title": "KARL Integration — Evolution³ / Stage 1, Path B: OAPL-Lite", "slug": "karl-integration-evolution-stage-1-path-b-oapl-lite", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/karl-trajectory-intelligence/stage1-path-b.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Path B implements a stripped-down version of KARL's OAPL algorithm that runs on Mac5's single M4 chip using offline advantage estimation instead of online rollouts. The core insight: we don't need live rollout infrastructure when we already have 3,249 logged trajectories in `verbose-all.jsonl`, 157 of which contain rich tool-use sequences with exit codes, file diffs, and success signals. The approach converts those trajectories into advantage-weighted training examples, computes rewards from build results, correcti", "excerpt": "# KARL Integration — Evolution³ / Stage 1, Path B: OAPL-Lite **Run:** karl-trajectory-intelligence **Generated:** 2026-03-10 **Method:** Evolution³ — divergent exploration\n\nPath B implements a stripped-down version of KARL's OAPL algorithm that runs on Mac5's single M4 chip using offline advantage estimation instead of online rollouts. The core insight: we don't need live rollout infrastructure when we already have 3,249 logged trajectories in `verbose-all.jsonl`, 157 of which contain rich tool-use sequences with exit codes, file diffs, and success signals. The approach converts those trajectories into advantage-weighted training examples, computes rewards from build results, correction signals, and user approval proxies, and trains a LoRA adapter on Mac5 that learns which tool-use sequences are associated with successful task completion.\n\nThe target is a LoRA adapter specialized for tool-use reasoning: given a prompt and a skill context, predict the high-advantage next action. This replaces the static `(prompt) -> inject SKILL.md content` pipeline with a `(prompt + trajectory context) -> learned action selection` model that improves as more trajectories accumulate.\n\nThe KARL OAPL loss is a regression objective derived from the KL-regularized RL problem:\n\nOAPL's key innovation over GRPO: V*(x) is the *soft optimal value*, not a simple baseline. It is computed in closed form from the rewards of all G rollouts, requiring no value network, no importance weight clipping, and no gradient through the value estimate. This makes it stable at policy lags up to 400+ gradient steps — the training data can be much older than in PPO/GRPO without degrading optimization.", "htmlHref": "/research/html/karl-integration-evolution-stage-1-path-b-oapl-lite-gmimma.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 7128 }, { "id": "stage-1-path-b-the-spoken-mesh-agents-that-talk-back-h473un", "title": "Stage 1 Path B: The Spoken Mesh — Agents That Talk Back", "slug": "stage-1-path-b-the-spoken-mesh-agents-that-talk-back", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/voice-first-agent-architecture/stage1-path-b.md", "extension": "md", "score": 26, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> Grounded in: Stage 0 finding that agents return results as text to Discord/terminal. No mesh-level TTS exists. The mesh is mute.", "excerpt": "> Grounded in: Stage 0 finding that agents return results as text to Discord/terminal. No mesh-level TTS exists. The mesh is mute.\n\nA voice-first architecture isn't just about listening — it's about speaking. When a Prefect flow completes, when a pane finishes a pulse task, when Evolution World triggers a mutation, when a security alert fires — these events should be spoken aloud. Not all of them. The critical ones. The mesh should have a voice.\n\n**2. Priority and Suppression:** - Critical events (security, build failure, absorbing panes) always spoken - Normal events spoken only when no active voice conversation - Suppress during \"focus mode\" (user says \"quiet\" or \"mute mesh\") - Rate limiting: max 1 spoken event per 30 seconds for non-critical - Queue events during suppression, summarize when un-muted: \"While you were focused, 3 builds completed and 1 flow failed\"\n\n**3. Voice Personality:** - ElevenLabs voice ID already configured: `TmSgyk1vGAD9YzdtJV3V` - Consistent voice across all mesh announcements - Tone varies by severity: neutral for status, urgent cadence for alerts - Optional: different voices for different subsystems (infra = deep voice, creative = lighter)\n\n**4. Spatial Audio (future):** - Mac speakers can do stereo positioning - Left speaker = build/deploy events, right speaker = creative/content events - Or: volume correlates with priority (whisper for info, full volume for critical)", "htmlHref": "/research/html/stage-1-path-b-the-spoken-mesh-agents-that-talk-back-h473un.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 472 }, { "id": "flow-walker-e2e-flow-testing-pipeline-13qkr4a", "title": "Flow Walker — E2E Flow Testing Pipeline", "slug": "flow-walker-e2e-flow-testing-pipeline", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Frameworks/omi/app/e2e/FLOW-WALKER-SKILL.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This skill teaches you how to use flow-walker to execute E2E flows on the Omi Flutter app, verify results, and publish shareable HTML reports. flow-walker is an agent-first testing CLI that works with agent-flutter (Marionette) for UI interaction.", "excerpt": "--- name: flow-walker-pipeline description: \"How to use flow-walker to run, verify, and publish E2E flow reports for the Omi Flutter app. Covers the full pipeline from YAML flow definition to published HTML report with screenshots and real timestamps.\" allowed-tools: Bash, Read, Glob, Grep ---\n\nThis skill teaches you how to use flow-walker to execute E2E flows on the Omi Flutter app, verify results, and publish shareable HTML reports. flow-walker is an agent-first testing CLI that works with agent-flutter (Marionette) for UI interaction.\n\nFlows live in `app/e2e/flows/.yaml`. Each flow defines a sequence of steps with expectations.\n\n| Kind | Fields | Meaning | |------|--------|---------| | `text_visible` | `values: [...]` | All listed strings must appear on screen | | `interactive_count` | `min: N` | At least N interactive widgets visible |\n\n**Replay mode:** If a `.snapshot.json` exists for the flow, `record init` returns a replay plan with cached coordinates. Check `replay.mode` — if `\"replay\"`, use `replay.steps[id].center` coordinates for cached steps.", "htmlHref": "/research/html/flow-walker-e2e-flow-testing-pipeline-13qkr4a.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1624 }, { "id": "miami-openings-radar-protocol-thkvpk", "title": "Miami Openings Radar Protocol", "slug": "miami-openings-radar-protocol", "kind": "research note", "program": "Protocol and Compute", "sourceAnchor": "koji-assistant/MIAMI-OPENINGS-RADAR-PROTOCOL.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Purpose: maintain an adaptive feed of newly opening Miami food, cafe, market, and hospitality businesses that are worth Koatji outreach.", "excerpt": "Purpose: maintain an adaptive feed of newly opening Miami food, cafe, market, and hospitality businesses that are worth Koatji outreach.\n\nThis is not a single-source scrape. New openings are noisy. One signal means \"maybe.\" Two independent signals means \"watch.\" Three aligned signals means \"work this lead.\"\n\n1. **Buildout** - permit, construction, certificate, plan review, or business registration activity. 2. **Pre-open** - \"coming soon,\" hiring, menu testing, buildout photos, soft-opening language. 3. **Soft open** - limited hours, first posts, Resy/OpenTable listings, local coverage. 4. **Newly open** - media coverage, first reviews, active menu, ready for outreach or visit.\n\nThe protocol should avoid chasing every restaurant. It should prioritize shops where Koatji has a realistic product fit: specialty coffee, matcha, bakery cafes, health-forward restaurants, upscale markets, juice/wellness, coworking cafes, hospitality groups, and design-forward neighborhood concepts.\n\n| Source | Use | Feed Behavior | |---|---|---| | Miami-Dade Local Business Tax GIS | Detect new or renewed business entities, business start dates, categories, NAICS, address, phone, email | Daily query, diff against prior snapshot | | City of Miami Data Explorer / Building Permits | Detect restaurant/cafe buildouts, improvements, tenant changes, commercial food-service work | Daily or 3x weekly query | | City of Miami Business Licensing / Certificate of Use | Confirm business legality and final opening readiness | Weekly/manual until API path is stable | | Miami Beach Civic Access | Permits, BTR, CU, fire inspection, planning/code compliance for Miami Beach | Weekly/manual or portal-monitor | | Miami-Dade Certificate of Occupancy / Certificate of Use | Detect change-of-use or occupancy readiness | Weekly/manual for high-score candidates |", "htmlHref": "/research/html/miami-openings-radar-protocol-thkvpk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2073 }, { "id": "track-3-research-state-of-the-art-for-operate-everything-from-the-phone-live-a-life-of-jfnmg4", "title": "Track 3 Research: State of the Art for \"Operate Everything From the Phone, Live a Life of Leisure\"", "slug": "track-3-research-state-of-the-art-for-operate-everything-from-the-phone-live-a-life-of-leisure", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "leisure-goal-synthesis/03-research.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Date: 2026-05-13 > Author: Research Engine (Claw subagent) > Goal: Inform the goal-prompt that conditions Claude Code's new goal-conditioning skill toward Mohamed's North Star of running his entire mesh and product surface from the iPhone with no laptop required.", "excerpt": "# Track 3 Research: State of the Art for \"Operate Everything From the Phone, Live a Life of Leisure\"\n\n> Date: 2026-05-13 > Author: Research Engine (Claw subagent) > Goal: Inform the goal-prompt that conditions Claude Code's new goal-conditioning skill toward Mohamed's North Star of running his entire mesh and product surface from the iPhone with no laptop required.\n\nThe \"phone as the operating console for everything\" thesis is no longer speculative in 2026. The infrastructure shipped. What separates the few people actually living it from the many who tried and failed is not technology, it is **surface area discipline**. Every successful operator runs a deliberately small product list, a deliberately small daily decision count, and a deliberately small set of agents that are trusted to act without supervision. Every failed ambient device (Humane, Rabbit, Friend) tried to invent a new substrate when the substrate that already won is \"the phone you already have, talking to compute you already own, over a tailnet you already trust.\" Mohamed's Pebble + aura-gateway + cross-machine inject stack is closer to the winning architecture than any consumer device shipped in the last two years.\n\n## 1. Prosumer Mesh Control Surfaces (the \"remote into my compute from my phone\" stack)\n\nThe defining shift this year is that Anthropic shipped **Claude Code Remote Control** (Feb 25, 2026, research preview) and brought Claude Code natively into the iOS app. The promise: keep the heavy session running on your laptop, attach from the phone in five seconds. Nothing moves to the cloud beyond a relay. The pattern is significant because it is the first major agent vendor to publicly admit that **the phone is the client, not the host**.", "htmlHref": "/research/html/track-3-research-state-of-the-art-for-operate-everything-from-the-phone-live-a-life-of-jfnmg4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3379 }, { "id": "lume-current-build-spec-k11-top-display-arducam-ecik7u", "title": "LUME Current Build Spec - K11 + Top Display + Arducam", "slug": "lume-current-build-spec-k11-top-display-arducam", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/LUME_CURRENT_BUILD_SPEC.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This is the current approval target for the LUME physical build. It replaces the earlier Jetson/SVPRO-oriented assumptions from the old print queue.", "excerpt": "This is the current approval target for the LUME physical build. It replaces the earlier Jetson/SVPRO-oriented assumptions from the old print queue.\n\n- Compute is the GMKtec K11 in the rear T-form pod. - The ZHAOCAILIN 11.3 inch 1920 x 440 mini monitor sits on top of the bar in a low cradle. It is not cut through the bar body. - The Arducam IMX586 USB 3.0 camera sits in the right-front auxiliary camera bay with its own printed mount and Type-C cable relief. - The Orbbec Femto Mega remains centered on the front face. - The K11 ports live in the rear pod. The bar rear now has a pod umbilical/feedthrough interface instead of visible Jetson-style ports.\n\n- `renders/approval/approval_bom_contact_sheet.png` - all current views in one image. - `renders/approval/femto_datasheet_fit_contact_sheet.png` - Femto Mega datasheet drawings plus current CAD fit check. - `renders/approval/approval_bom_hero.png` - 3/4 form-factor view. - `renders/approval/approval_bom_front.png` - front view showing Femto and Arducam placement. - `renders/approval/approval_bom_top.png` - top view showing the monitor and rear pod. - `renders/approval/approval_bom_ghost.png` - ghosted view showing mounts, cable path, K11 sled, and Arducam bracket.\n\n| Component | CAD assumption | Notes | |---|---:|---| | ZHAOCAILIN 11.3 inch monitor | 305 x 80 mm face footprint, 60 mm vendor-listed depth, 12 mm current render thickness | Public listing dimensions are inconsistent about case depth/orientation. Do not cut a structural pocket until top orientation is approved. | | Arducam IMX586 USB camera | 34 x 34 x 16.2 mm body, 28 x 28 mm mount pitch | Based on Arducam B0478 datasheet. Mount has a 20 mm lens aperture and Type-C cable notch. | | GMKtec K11 | 132 x 125 x 58 mm | Official GMKtec dimensions. Lives in rear pod. Sled includes intake slots and 12 mm standoff clearance for bottom fan airflow. | | Orbbec Femto Mega | 115 x 40 x 145 mm total body model | Centered front sensor module. Existing STL proxy is still used for visual fit. |\n\nThese are for validation only. The existing prearranged 3MF files are not updated yet.", "htmlHref": "/research/html/lume-current-build-spec-k11-top-display-arducam-ecik7u.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1312 }, { "id": "lume-hardware-cad-vpskvs", "title": "LUME Hardware — CAD", "slug": "lume-hardware-cad", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/README.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Current-doc warning, 2026-04-30: parts of this README still describe the earlier Jetson/SVPro in-bar architecture. The active build is documented in `LUME_CURRENT_BUILD_SPEC.md` and `PRINT_APPROVAL_QUEUE_CURRENT.md`: K11 rear pod, ZHAOCAILIN top display cradle, centered Femto Mega, and Arducam IMX586 auxiliary camera.", "excerpt": "> Current-doc warning, 2026-04-30: parts of this README still describe the earlier Jetson/SVPro in-bar architecture. The active build is documented in `LUME_CURRENT_BUILD_SPEC.md` and `PRINT_APPROVAL_QUEUE_CURRENT.md`: K11 rear pod, ZHAOCAILIN top display cradle, centered Femto Mega, and Arducam IMX586 auxiliary camera.\n\n| File | Purpose | |---|---| | `lume-config.scad` | Global dimensions, component footprints, toggles. **Edit here first.** | | `lume-primitives.scad` | Reusable helpers: `rbox`, `cchamfer`, `hex_grille`, `slot_grille`, `lens_cutout`, `insert_boss`, `insert_boss_gusseted`, `bolt_m3_counterbore`, `rib`, `cable_clip`, `strain_relief`, `lip_tongue`/`lip_groove`. | | `lume-components.scad` | Proxy volumes for Jetson, Femto Mega, UMA-8, Noctua fan, SVPRO, NeoPixel ring. Swap with vendor STEPs when available. | | `lume-shell.scad` | Exterior shell. Front/rear cutouts, interior ribs, gusseted corner bolt bosses, split halves (`lume_shell_front` / `lume_shell_rear`). | | `lume-internals.scad` | Jetson sled (96×96 pattern + heat-set bosses), Noctua fan shroud, thermal baffle, Femto bracket, SVPRO brackets (L+R), UMA-8 mic rail, cable backbone, port bracket anchor posts. | | `lume-bezel.scad` | Separate printable front bezel insert + blank camera plug (for v1 demo rigs using only 2 cameras). | | `lume-port-bracket.scad` | Rear port bracket with labeled cutouts: HDMI, USB-A ×2, Ethernet. Screws to interior-rear via 4 corner bolts. | | `lume-vesa.scad` | VESA 100×100 plate **or** French cleat (bar-side + wall-side). | | `lume-main.scad` | Top-level assembly. Shell + internals + proxies + bezel + diffuser + port bracket + VESA. Exploded view supported. | | `render.sh` | Headless render pipeline. |\n\n- `assembly` — shell ghosted, internals + components solid - `shell_only` — just the assembled shell - `print_front` / `print_rear` — isolate each half for slicer\n\nPass `-D EXPLODED=true` with `assembly` to offset parts along Y for exploded-view docs.\n\n1. Edit `lume-config.scad` (or any module) 2. `./render.sh preview` (fast, ~1 min total) 3. Check `exports/assembly.png` + `exports/exploded.png` 4. When fit looks right: `./render.sh stl` 5. Slice in Cura / PrusaSlicer → print", "htmlHref": "/research/html/lume-hardware-cad-vpskvs.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 899 }, { "id": "e483-duncan-fewkes-reel-analysis-digest-gchm8c", "title": "E483 — Duncan Fewkes reel analysis digest", "slug": "e483-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E483-noreel.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, D", "excerpt": "⚠ No video on disk for this reel — referenced by the playbook but not in the local ingest cache.\n\nThis file aggregates every playbook chunk section that cites E483. Sections are de-duplicated by heading.\n\n- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, DT6IlEfig-k, DTBUJiDCvPQ, DScEatyilnk). DSfZYMUChIi + DSZmIhOCrTv hit Gemini 429 quota exhaustion; captions on those are still detailed.\n\nMid-period work is dominated by **Audio Particle Clones** (E483→E491) — beat-snapshot human silhouette as particle clouds layered with live depth visuals. This is the direct ancestor of the recent \"Sunset Clone Plane\" (E605) and \"Motion Sparks 4\" (E579) work. Three things are clearer here than in the recent reels:\n\n1. **Snapshot timing is a published failure mode.** E491 (DSkpKC_iie8): \"needs a response time/curve adding so that snapshot pose/shape holds for a bit longer (maybe 250ms) and then slightly eases into the gravity fall, so you have time to read the shape better.\" → For LUME `LumeCloneSnapshot.cs`: `holdDuration = 0.25s`, then ease-in to gravity. Don't drop straight to physics. 2. **Audio reactivity is two-stage with a feedback loop**, not a single mapping. Beat trigger → snapshot AND audio FFT → reactive logo blend-shape inflation → blend-shape adds motion vectors to fluid sim → fluid sim moves OTHER particles → speed-to-brightness lights them up. (E489 + E490). This is a self-reinforcing cascade, not parallel channels. 3. **Speed→brightness is the \"twinkle\" parameter.** Every audio clones reel calls it out as the secret-sauce visual flourish that makes the system feel alive. Brightness boost is a power curve with a threshold — overshoot → blow-out, undershoot → no twinkle. Tune by ear.", "htmlHref": "/research/html/e483-duncan-fewkes-reel-analysis-digest-gchm8c.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2063 }, { "id": "e489-duncan-fewkes-reel-analysis-digest-1nzmqsy", "title": "E489 — Duncan Fewkes reel analysis digest", "slug": "e489-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E489-noreel.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, D", "excerpt": "⚠ No video on disk for this reel — referenced by the playbook but not in the local ingest cache.\n\nThis file aggregates every playbook chunk section that cites E489. Sections are de-duplicated by heading.\n\n- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, DT6IlEfig-k, DTBUJiDCvPQ, DScEatyilnk). DSfZYMUChIi + DSZmIhOCrTv hit Gemini 429 quota exhaustion; captions on those are still detailed.\n\nMid-period work is dominated by **Audio Particle Clones** (E483→E491) — beat-snapshot human silhouette as particle clouds layered with live depth visuals. This is the direct ancestor of the recent \"Sunset Clone Plane\" (E605) and \"Motion Sparks 4\" (E579) work. Three things are clearer here than in the recent reels:\n\n1. **Snapshot timing is a published failure mode.** E491 (DSkpKC_iie8): \"needs a response time/curve adding so that snapshot pose/shape holds for a bit longer (maybe 250ms) and then slightly eases into the gravity fall, so you have time to read the shape better.\" → For LUME `LumeCloneSnapshot.cs`: `holdDuration = 0.25s`, then ease-in to gravity. Don't drop straight to physics. 2. **Audio reactivity is two-stage with a feedback loop**, not a single mapping. Beat trigger → snapshot AND audio FFT → reactive logo blend-shape inflation → blend-shape adds motion vectors to fluid sim → fluid sim moves OTHER particles → speed-to-brightness lights them up. (E489 + E490). This is a self-reinforcing cascade, not parallel channels. 3. **Speed→brightness is the \"twinkle\" parameter.** Every audio clones reel calls it out as the secret-sauce visual flourish that makes the system feel alive. Brightness boost is a power curve with a threshold — overshoot → blow-out, undershoot → no twinkle. Tune by ear.", "htmlHref": "/research/html/e489-duncan-fewkes-reel-analysis-digest-1nzmqsy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2545 }, { "id": "e491-duncan-fewkes-reel-analysis-digest-ta2ujj", "title": "E491 — Duncan Fewkes reel analysis digest", "slug": "e491-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E491-noreel.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, D", "excerpt": "⚠ No video on disk for this reel — referenced by the playbook but not in the local ingest cache.\n\nThis file aggregates every playbook chunk section that cites E491. Sections are de-duplicated by heading.\n\n- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, DT6IlEfig-k, DTBUJiDCvPQ, DScEatyilnk). DSfZYMUChIi + DSZmIhOCrTv hit Gemini 429 quota exhaustion; captions on those are still detailed.\n\nMid-period work is dominated by **Audio Particle Clones** (E483→E491) — beat-snapshot human silhouette as particle clouds layered with live depth visuals. This is the direct ancestor of the recent \"Sunset Clone Plane\" (E605) and \"Motion Sparks 4\" (E579) work. Three things are clearer here than in the recent reels:\n\n1. **Snapshot timing is a published failure mode.** E491 (DSkpKC_iie8): \"needs a response time/curve adding so that snapshot pose/shape holds for a bit longer (maybe 250ms) and then slightly eases into the gravity fall, so you have time to read the shape better.\" → For LUME `LumeCloneSnapshot.cs`: `holdDuration = 0.25s`, then ease-in to gravity. Don't drop straight to physics. 2. **Audio reactivity is two-stage with a feedback loop**, not a single mapping. Beat trigger → snapshot AND audio FFT → reactive logo blend-shape inflation → blend-shape adds motion vectors to fluid sim → fluid sim moves OTHER particles → speed-to-brightness lights them up. (E489 + E490). This is a self-reinforcing cascade, not parallel channels. 3. **Speed→brightness is the \"twinkle\" parameter.** Every audio clones reel calls it out as the secret-sauce visual flourish that makes the system feel alive. Brightness boost is a power curve with a threshold — overshoot → blow-out, undershoot → no twinkle. Tune by ear.", "htmlHref": "/research/html/e491-duncan-fewkes-reel-analysis-digest-ta2ujj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2329 }, { "id": "e532-duncan-fewkes-reel-analysis-digest-1i0lllf", "title": "E532 — Duncan Fewkes reel analysis digest", "slug": "e532-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E532-DUgoDHlipPu.md", "extension": "md", "score": 26, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)", "excerpt": "Source video: `../reels/E532-DUgoDHlipPu.mp4` (symlink to `[home-path]`) Caption: `../reels/E532-DUgoDHlipPu.txt`\n\nThis file aggregates every playbook chunk section that cites E532. Sections are de-duplicated by heading.\n\n- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)\n\nE527, E544, E532, E544 (DUSui7PioUD, DU-52fcinww, DUgoDHlipPu) all confirm Duncan ships into a **branded \"Holovis®\" CAVE / wide LED installation venue**. This is not lab work, this is **a live commercial installation product**. Implications for LUME:\n\n- The visuals are tuned for a wide curved LED CAVE (multi-panel) — but he is now porting to a flat 17m × 3m screen (E567 caption). LUME's 1-3 vertical monitors is a smaller close-cousin of \"flat 17m × 3m\". - Each install gets per-site calibration — he literally calls out: *\"need to rebalance threshold etc values for the actual usage distance — probably easiest to expose in settings and debug menu to allow for tweak values for each install individually\"* (E568). **LUME action**: ship a per-install settings file (motion threshold, depth-camera distance, smoothing) loaded from disk, exposable via debug menu. - The Holovis logo is itself one of the VFX targets — a \"Logo:\" preset slot on the VFX editor (we already had this in the prior playbook). New twist below.", "htmlHref": "/research/html/e532-duncan-fewkes-reel-analysis-digest-1i0lllf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3215 }, { "id": "e534-duncan-fewkes-reel-analysis-digest-1ae9cdk", "title": "E534 — Duncan Fewkes reel analysis digest", "slug": "e534-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E534-DUleGWZisrH.md", "extension": "md", "score": 26, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)", "excerpt": "Source video: `../reels/E534-DUleGWZisrH.mp4` (symlink to `[home-path]`) Caption: `../reels/E534-DUleGWZisrH.txt`\n\nThis file aggregates every playbook chunk section that cites E534. Sections are de-duplicated by heading.\n\n- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)\n\nVerbatim from his caption (E534) — these are the actual preset names in his FluidSim slot:\n\n| Preset | Caption description | Best for | |--------|---------------------|----------| | **Default** | \"nice swishy pressure wave, but does sometimes look too large a motion\" | general use | | **Default_Smooth** | (named in E534 visual analysis UI panel) | smoothed Default | | **LongThrow** | \"lot of velocity propagation so it continues onwards, but tendency to thin down over distance, lacks the vorticity/swirls and pressure wave wobble\" | long arc throws | | **MidThrow** | \"puts more vorticity back in which helps it not drop downwards to ground level\" | balanced | | **ShortThrow** | \"very local, helps if you want to leave trails/particle clones lingering in space\" | trail residue, cymatic-on-logo | | **InvertedObstacle** | \"made for E522 Internal Swishy Stuff to keep fluid flow inside the offscreen reprojected depth render\" | fluid INSIDE the body silhouette only |", "htmlHref": "/research/html/e534-duncan-fewkes-reel-analysis-digest-1ae9cdk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1537 }, { "id": "e556-duncan-fewkes-reel-analysis-digest-roe7a5", "title": "E556 — Duncan Fewkes reel analysis digest", "slug": "e556-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E556-DVbENIFCocX.md", "extension": "md", "score": 26, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)", "excerpt": "Source video: `../reels/E556-DVbENIFCocX.mp4` (symlink to `[home-path]`) Caption: `../reels/E556-DVbENIFCocX.txt`\n\nThis file aggregates every playbook chunk section that cites E556. Sections are de-duplicated by heading.\n\n- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)\n\n- **VFX Graph Particle Strips** (= ribbon particles), used as kelp strands. Each strand has per-strip stiffness, propagating directionality down the chain. - **Per-particle physics constraints**: per-strip stiffness, motion/forces propagated parent→child along the strip. - **Lookdev gotcha** (E548): going from debug line renderer to even basic HDRP lit material with self-shadow = \"huge difference\". - **#normalizefailure** — he literally tags failures and shows them. Authenticity move worth borrowing for LUME devlog. - **Fish boids** (E557): Reynolds boids sim with audio params on cruising speed, separation. Tuned audio levels low so fish don't zip away. - **Spectrum-mapped vertical audio response** (E557, his next step): > *\"Planning another pass with spectrum levels mapping audio vertically, so leaves at the bottom react to the bass and frequencies increase up the stalk.\"* This is a concrete pattern: **map FFT bin index → vertical Y position on a strip particle**. Bass drives bottom leaves, treble drives top leaves. **LUME**: directly portable to anything tall/strip-shaped (curtain VFX, kelp, lightning). - **\"Wobbly Lads\" feedback gotcha** (E556): audio-reactive procedural creatures. *\"Making the motion of the Wobbly Lad input to fluid sim meant I had to disable the fluid sim force contribution to the motion, otherwise it would feedback and he'd go apeshit.\"* Lesson: bidirectional coupling between sim and creatures requires breaking the loop — pick one direction.\n\n**LUME relevance**: kelp/seagrass = niche, but the **strip-particle physics primitive** is broadly useful (tendrils, smoke ribbons, hair). Park the kelp aesthetic; bring forward the strip-physics capability for Wave 4-5.", "htmlHref": "/research/html/e556-duncan-fewkes-reel-analysis-digest-roe7a5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2207 }, { "id": "e568-duncan-fewkes-reel-analysis-digest-p3vgvb", "title": "E568 — Duncan Fewkes reel analysis digest", "slug": "e568-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E568-DV6A04wislr.md", "extension": "md", "score": 26, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)", "excerpt": "Source video: `../reels/E568-DV6A04wislr.mp4` (symlink to `[home-path]`) Caption: `../reels/E568-DV6A04wislr.txt`\n\nThis file aggregates every playbook chunk section that cites E568. Sections are de-duplicated by heading.\n\n- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)\n\nE527, E544, E532, E544 (DUSui7PioUD, DU-52fcinww, DUgoDHlipPu) all confirm Duncan ships into a **branded \"Holovis®\" CAVE / wide LED installation venue**. This is not lab work, this is **a live commercial installation product**. Implications for LUME:\n\n- The visuals are tuned for a wide curved LED CAVE (multi-panel) — but he is now porting to a flat 17m × 3m screen (E567 caption). LUME's 1-3 vertical monitors is a smaller close-cousin of \"flat 17m × 3m\". - Each install gets per-site calibration — he literally calls out: *\"need to rebalance threshold etc values for the actual usage distance — probably easiest to expose in settings and debug menu to allow for tweak values for each install individually\"* (E568). **LUME action**: ship a per-install settings file (motion threshold, depth-camera distance, smoothing) loaded from disk, exposable via debug menu. - The Holovis logo is itself one of the VFX targets — a \"Logo:\" preset slot on the VFX editor (we already had this in the prior playbook). New twist below.", "htmlHref": "/research/html/e568-duncan-fewkes-reel-analysis-digest-p3vgvb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4866 }, { "id": "e605-duncan-fewkes-reel-analysis-digest-1mjtddd", "title": "E605 — Duncan Fewkes reel analysis digest", "slug": "e605-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E605-DXhnYbCComC.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> *\"Reflective floor — which helps add depth cues back in, so I might try to keep it (although does have a significant perf hit for planar reflection render every frame).\"* (E532)", "excerpt": "Source video: `../reels/E605-DXhnYbCComC.mp4` (symlink to `[home-path]`) Caption: `../reels/E605-DXhnYbCComC.txt`\n\nThis file aggregates every playbook chunk section that cites E605. Sections are de-duplicated by heading.\n\n> *\"Reflective floor — which helps add depth cues back in, so I might try to keep it (although does have a significant perf hit for planar reflection render every frame).\"* (E532)\n\nAlready in prior playbook (planar reflection from E605). New info: **he flags it as expensive and makes it toggleable**. **LUME**: `LumeFloorReflection.cs` should be a togglable component, not always-on. On Mac5 M4 16GB it's likely cheaper than on his Windows HDRP, but still: budget it.\n\nMid-period work is dominated by **Audio Particle Clones** (E483→E491) — beat-snapshot human silhouette as particle clouds layered with live depth visuals. This is the direct ancestor of the recent \"Sunset Clone Plane\" (E605) and \"Motion Sparks 4\" (E579) work. Three things are clearer here than in the recent reels:", "htmlHref": "/research/html/e605-duncan-fewkes-reel-analysis-digest-1mjtddd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1699 }, { "id": "nouses-kou-study-for-lume-mohamed-s-content-1wwh1x", "title": "@nouses_kou — study for LUME + Mohamed's content", "slug": "nouses-kou-study-for-lume-mohamed-s-content", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-content/nouses-kou-study.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Account stats: Kyoto-based, ~305K followers, 500+ posts, contact `[email]`. Brother dancer `@nouses_motomi`. Tag self-description: \"physical sensations, technology and sound.\" Uses `#touchdesigner #aiart #newmedia #contemporaryart #glitchart`.", "excerpt": "Account stats: Kyoto-based, ~305K followers, 500+ posts, contact `[email]`. Brother dancer `@nouses_motomi`. Tag self-description: \"physical sensations, technology and sound.\" Uses `#touchdesigner #aiart #newmedia #contemporaryart #glitchart`.\n\n| Shortcode | Dur | Likes | Caption hook | |---|---|---|---| | DCmj5szSZcs | 18s | 377,210 | \"🌿◉\" (two glyphs) | | C-hxtqZyqJ8 | 25s | 149,406 | Noh quote: \"Truth is not emptiness but rather is as it is\" | | C6tF8K0Ssn_ | 89s | 44,965 | hand-glyph sequence + \"physical sensations, technology and sound\" | | C7WuPgry4Rn | 63s | 30,442 | \"🫧↗︎↩︎🫧\" + dancer credit | | C_2mhtyy7gx | 30s | 12,410 | Kanji Noh quote: void/substance | | DR-luD5EyVk | 17s | 10,934 | \"Forest, AI, liminal interface, signal.\" | | C-NkBZVytCm | 32s | 10,094 | Noh quote + deer-sound mention | | DVXF57Vk1_l | 21s | 9,025 | \"Human and city disappeared, AI and nature remained.\" | | DViZfY8kRmf | 27s | 2,962 | \"🌿🌱⇄↪︎↪︎ AI\" | | DUiLb6dEWXt | 24s | 1,073 | NFT drop announcement (the only \"ask\" — performs worst) |\n\nSkipped from this count: `DYCQRxNxfrr` (transcript too short, 7.5s motion-capture intro), `CODrUbYgb5u` (962s — not a reel, 2021 IGTV performance).\n\nA continuous, looped, 17–30 second AR-glitch tableau where a body (or two hands, or a finger on a leaf) is overlaid with white or green tracker IDs, bounding boxes, point clouds, and pseudo-code labels, scored to a distorted electronic ambient drone and captioned with a single classical Japanese Noh fragment plus a quiet \"Thank you very much, sincerely.\" It is not a tutorial and it is not a personality channel. There is no face, no voice, no CTA, no progress arc. Each reel is a self-contained loop of \"what would it look like if a machine were reverently observing the smallest gesture.\" The strategy is restraint scaled into spectacle: the same data-visualization vocabulary, the same forest or domestic frame, the same closing bow, repeated until the catalog itself becomes the brand.\n\n| Layer | Recurring device | Frequency in sample | |---|---|---| | Visual | White or neon-green bounding boxes labeled `ID: 7-digit` overlaid on subject | 7/9 reels | | Visual | Pseudo-code text floating in space (`Tensor.2.0`, `int main(){}`, `loop (format 1 \"^%1\")`) | 4/9 | | Visual | Point-cloud cutaway against pure black (subject reduced to dots) | 5/9 | | Visual | Glitch / data-mosh corruption over the live plate | 6/9 | | Visual | Greyscale or desaturated base footage with one chromatic accent (neon green or orange) | 8/9 | | Visual | Fixed-frame composition; camera does not move | 9/9 | | Visual | Subject = a body part interacting with nature (hand + fern, hand + branch, body + forest floor) | 6/9 | | Audio | Distorted whisper or processed voice (\"Thanks to the human heart by which we live\") looped as ma", "htmlHref": "/research/html/nouses-kou-study-for-lume-mohamed-s-content-1wwh1x.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1703 }, { "id": "algorithm-performance-specifications-c7sagf", "title": "Algorithm Performance Specifications", "slug": "algorithm-performance-specifications", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Milk Men/Documentation/Implementation/04-Algorithms/Performance-Specs.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Document ID:** ALGO-PERF-001 **Version:** 1.0.0-DRAFT **Created:** 2026-01-04 **Purpose:** Define performance requirements and benchmarks for all core algorithms **Parent Document:** [04-Algorithms/README.md](./README.md) **Related Documents:** - [Visit-Sequencing.md](./Visit-Sequencing.md) - [Route-Optimization.md](./Route-Optimization.md) - [Delivery-Optimization.md](./Delivery-Optimization.md) - [Decision-Logic.md](./Decision-Logic.md)", "excerpt": "**Document ID:** ALGO-PERF-001 **Version:** 1.0.0-DRAFT **Created:** 2026-01-04 **Purpose:** Define performance requirements and benchmarks for all core algorithms **Parent Document:** [04-Algorithms/README.md](./README.md) **Related Documents:** - [Visit-Sequencing.md](./Visit-Sequencing.md) - [Route-Optimization.md](./Route-Optimization.md) - [Delivery-Optimization.md](./Delivery-Optimization.md) - [Decision-Logic.md](./Decision-Logic.md)\n\n1. [Overview](#1-overview) 2. [Global Performance Requirements](#2-global-performance-requirements) 3. [Visit Sequencing Performance](#3-visit-sequencing-performance) 4. [Route Optimization Performance](#4-route-optimization-performance) 5. [Delivery Optimization Performance](#5-delivery-optimization-performance) 6. [Decision Logic Performance](#6-decision-logic-performance) 7. [Network Performance](#7-network-performance) 8. [UI Rendering Performance](#8-ui-rendering-performance) 9. [Memory Performance](#9-memory-performance) 10. [Battery Performance](#10-battery-performance) 11. [Offline Performance](#11-offline-performance) 12. [Swift App Parity Benchmarks](#12-swift-app-parity-benchmarks) 13. [Performance Testing Strategy](#13-performance-testing-strategy) 14. [Performance Degradation Triggers](#14-performance-degradation-triggers) 15. [Optimization Priorities](#15-optimization-priorities)\n\nThis document defines measurable, falsifiable performance requirements for all algorithms in the Milk Men Expo migration. Performance is a critical success criterion (EM-P-001 through EM-P-004) and must meet or exceed the Swift app baseline.\n\n**User-Centric Performance:** - Perceived performance > raw speed - Instant feedback (optimistic UI) > blocking operations - Progressive loading > all-or-nothing - Graceful degradation > hard failures\n\n**Asymmetric Performance Targets:** - Interactive operations (tap, scroll): <16ms (60 FPS) - User-initiated operations (button press): <100ms perceived response - Background operations (sync): No user-facing latency - Network-dependent operations: Optimistic UI + background fetch", "htmlHref": "/research/html/algorithm-performance-specifications-c7sagf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4820 }, { "id": "system-glossary-milk-men-1mj1xpc", "title": "System Glossary: Milk Men", "slug": "system-glossary-milk-men", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Milk Men/Documentation/Phase-0-Control/0.1.2-SYSTEM-GLOSSARY.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Document ID:** GLOSSARY-001 **Version:** 1.0.0-DRAFT **Created:** 2025-12-26 **Governing Document:** 0.1.1-PROJECT-CHARTER.md **Purpose:** Define all core terms to eliminate ambiguity in implementation", "excerpt": "**Document ID:** GLOSSARY-001 **Version:** 1.0.0-DRAFT **Created:** 2025-12-26 **Governing Document:** 0.1.1-PROJECT-CHARTER.md **Purpose:** Define all core terms to eliminate ambiguity in implementation\n\n1. **No term may be used in code, documentation, or discussion unless defined here** 2. **Terms are case-sensitive in code; case-insensitive in discussion** 3. **If a term appears ambiguous, this document is authoritative** 4. **New terms require glossary update before use**\n\n| Attribute | Value | |-----------|-------| | **Definition** | A distinct business entity that uses the platform; the top-level tenant boundary | | **What it is** | A company, team, or business unit with its own members, data, and configuration | | **What it is NOT** | A user account; a region; a team within an organization | | **Layer** | Domain / Conceptual | | **Database Table** | `organizations` | | **Swift Type** | `Organization` | | **Cardinality** | One user belongs to exactly one organization |\n\n| Attribute | Value | |-----------|-------| | **Definition** | An industry category that determines default terminology and feature configuration | | **What it is** | A preset configuration template (Coffee & Beverage, Food Service, Retail & Wholesale, Custom) | | **What it is NOT** | A separate product; a customizable workflow engine; a user-defined category | | **Layer** | Domain / Configuration | | **Database Column** | `organizations.vertical_id` | | **Swift Type** | `VerticalType` (enum) | | **Values** | `coffee_beverage`, `food_service`, `retail_wholesale`, `custom` |\n\n| Attribute | Value | |-----------|-------| | **Definition** | A user who belongs to an organization with an assigned role | | **What it is** | The association between a user account and an organization | | **What it is NOT** | The user account itself; an agent record; an invite | | **Layer** | Domain / Access Control | | **Database Table** | `organization_members` | | **Swift Type** | `OrganizationMember` |", "htmlHref": "/research/html/system-glossary-milk-men-1mj1xpc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2082 }, { "id": "autoencoders-1e2fh2b", "title": "Autoencoders", "slug": "autoencoders", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/live-music-diffusion-models/docs/autoencoders.md", "extension": "md", "score": 26, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "The *encoder* takes in an sequence (such as mono or stereo audio) and outputs a compressed representation of that sequence as a d-channel \"latent sequence\", usually heavily downsampled by a constant factor.", "excerpt": "# Autoencoders At a high level, autoencoders are models constructed of two parts: an *encoder*, and a *decoder*.\n\nThe *encoder* takes in an sequence (such as mono or stereo audio) and outputs a compressed representation of that sequence as a d-channel \"latent sequence\", usually heavily downsampled by a constant factor.\n\nThe *decoder* takes in a d-channel latent sequence and upsamples it back to the original input sequence length, reversing the compression of the encoder.\n\nAutoencoders are trained with a combination of reconstruction and adversarial losses in order to create a compact and invertible representation of raw audio data that allows downstream models to work in a data-compressed \"latent space\", with various desirable and controllable properties such as reduced sequence length, noise resistance, and discretization.\n\nThe autoencoder architectures defined in `stable-audio-tools` are largely fully-convolutional, which allows autoencoders trained on small lengths to be applied to arbitrary-length sequences. For example, an autoencoder trained on 1-second samples could be used to encode 45-second inputs to a latent diffusion model.", "htmlHref": "/research/html/autoencoders-1e2fh2b.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2044 }, { "id": "turbulence-lab-holosculpture-competitive-absorption-3soli7", "title": "Turbulence Lab / HoloSculpture Competitive Absorption", "slug": "turbulence-lab-holosculpture-competitive-absorption", "kind": "technical note", "program": "Research Practice", "sourceAnchor": "MotionMix/research/turbulencelab-holosculpture-competitive-absorption-2026-06-14.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "HoloSculpture is not a deep competitor to Lume as a production system. It is a strong product wrapper around a much simpler stack: a desktop art-speaker/display object, AI/avatar claims, music-reactive visuals, limited-edition art packaging, and a gallery-installation content pipeline.", "excerpt": "HoloSculpture is not a deep competitor to Lume as a production system. It is a strong product wrapper around a much simpler stack: a desktop art-speaker/display object, AI/avatar claims, music-reactive visuals, limited-edition art packaging, and a gallery-installation content pipeline.\n\nThe lesson is not \"copy the box.\" The lesson is that Lume needs a clearer physical/product myth. Turbulence Lab is selling a small object as a living art presence. Lume already has the harder substrate: multi-device capture spheres, BodyTruth/SAN, AirDeck gestures, real camera/audio lanes, K11 archival handoff, Studio timelines, Mac4 render/output paths, and Mac5 reconstruction gates. The move is to package those into a practical \"living room/world\" product.\n\nOfficial product framing: - HoloSculpture is a collectible \"living sculpture\" that fuses AI, 4D anamorphic imagery, and spatial/studio-grade sound. - Product modes: AI Assistant, Art, and Music. - AI mode: personalized avatar listens/responds as a companion. - Art mode: continuous 4D digital artwork, with \"Hey Holo\" voice trigger. - Music mode: real-time music analysis, avatar responds/dances to rhythm. - Characters are GLB embodied digital entities. - Voice/mic array plus physical controls. - Sound integrated into the body: speaker, acoustic chamber, manual EQ knobs. - Connectivity: Bluetooth 5.3, Wi-Fi 6E, USB-C for charging/data/future expansion. - Battery: up to 5 hours standalone. - Materials/design claims: carbon fiber enclosure, precision-milled knobs, minimalist architectural form. - Box contents: sculpture, wooden presentation box, carrying case, 3 exclusive 4D artworks, 3 embodied AI characters, archival gloves, certificates, power adapter, manual/support card.\n\nThe product/spec image adds: - \"Dynamic face & hand tracking\" - \"Real-time 3D character embodiment\" - \"Music-reactive AI art engine\" - \"Custom AI art uploads via USB\" - \"Full dual-control system: manual precision knobs + complete hands-free voice control\" - \"Hardware expansion capability\" - Approximate dimensions: - Device: 150 mm x 160 mm x 280 mm - Wooden box: 300 mm x 300 mm x 400 mm - Carrying case: 170 mm x 170 mm x 280 mm\n\nWeak signal: the product page still contains leftover XStore/Transparent Speaker/perfume template content in its REST output and footer/search scaffolding. That suggests the site is not deeply product-hardened.", "htmlHref": "/research/html/turbulence-lab-holosculpture-competitive-absorption-3soli7.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1726 }, { "id": "what-if-your-ai-twin-thought-in-your-mother-tongue-12qr0dd", "title": "What If Your AI Twin Thought in Your Mother Tongue?", "slug": "what-if-your-ai-twin-thought-in-your-mother-tongue", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/experiments/experiment-c-nko-cognitive-twin.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A cognitive twin is a language model fine-tuned on a specific person's conversation history. Not a general assistant. A specific, personalized model that has seen your questions, your reasoning patterns, your way of framing problems. It learns to respond the way you think, not the way a generic chatbot does.", "excerpt": "*A cognitive twin trained on English conversation gets retrained to operate in N'Ko. This is what we're looking for.*\n\nA cognitive twin is a language model fine-tuned on a specific person's conversation history. Not a general assistant. A specific, personalized model that has seen your questions, your reasoning patterns, your way of framing problems. It learns to respond the way you think, not the way a generic chatbot does.\n\nThe technical implementation involves collecting your conversation data as supervised fine-tuning (SFT) examples, message pairs where the user side is a question or prompt and the assistant side is the kind of response you'd actually want. You train a LoRA adapter on that data, a small set of weight updates that shift a base model's behavior toward your patterns without replacing everything the base model knows.\n\nThe result is something that feels distinctly familiar. It has your vocabulary preferences. It matches your register. It picks up on the framing you use for certain kinds of problems. It's not magic. It's pattern matching over your actual language use. But pattern matching done well, at scale, on a model that already understands language deeply, produces something that feels personal in a way generic models don't.\n\nAll of the existing cognitive twin work was done in English. Every training example was English. Every evaluation prompt was English. The model learned to reason in English because that's the language the training data was in.", "htmlHref": "/research/html/what-if-your-ai-twin-thought-in-your-mother-tongue-12qr0dd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1027 }, { "id": "dead-circuits-and-living-speech-building-the-first-nko-ai-pipeline-ws41ik", "title": "Dead Circuits and Living Speech: Building the First N'Ko AI Pipeline", "slug": "dead-circuits-and-living-speech-building-the-first-nko-ai-pipeline", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/posts/02-technical-deep-dive.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **What we found**: Qwen3-8B-Instruct processes N'Ko text with a 2.94x \"translation tax\" (L2 norm deficit) across all 36 transformer layers. Circuit duplication analysis (55 configurations, RYS methodology) finds 0/55 N'Ko-advantageous configurations. Three-zone failure analysis reveals structurally distinct collapse modes at embedding, middle, and output layers. Arabic, another RTL script, sits within 7% of English on the same metrics. The failure is entirely data-driven. - **What we built**: (1) A three-stage Lo", "excerpt": "*Two papers in preparation for ACL/EMNLP 2026. All code and models open-source.*\n\n- **What we found**: Qwen3-8B-Instruct processes N'Ko text with a 2.94x \"translation tax\" (L2 norm deficit) across all 36 transformer layers. Circuit duplication analysis (55 configurations, RYS methodology) finds 0/55 N'Ko-advantageous configurations. Three-zone failure analysis reveals structurally distinct collapse modes at embedding, middle, and output layers. Arabic, another RTL script, sits within 7% of English on the same metrics. The failure is entirely data-driven. - **What we built**: (1) A three-stage LoRA pipeline (CPT + SFT + BPE-aware, 185 minutes on Apple M4) that reduces the translation tax from 2.94x to 0.70x. (2) The first audio-to-N'Ko ASR system, with a four-version architecture progression from BiLSTM baseline (56% CER) to Whisper LoRA fine-tune (29.4% CER). A deterministic cross-script bridge, a 4-state FSM for phonotactic validation, and a downstream NLLB-200 translation pipeline complete the stack. - **The numbers**: Translation tax: 2.94x to 0.70x (76% reduction). ASR: V1 56% CER / 91.5% WER to V4 29.4% CER / 62.3% WER. Prediction confidence: 0.46 to 0.82 (79% improvement). Per-sample: worst case au30 drops from WER 15.8 to 1.0 (93.7% improvement). Total compute cost across all experiments: $14.\n\nN'Ko is the only writing system in history designed from the ground up with the computational properties that NLP engineers dream about when building synthetic alphabets.\n\nSolomana Kante designed it in 1949 in Kankan, Guinea, in response to a claim that African languages could not be written. The result is a right-to-left alphabetic script occupying Unicode block `U+07C0--U+07FF` (standardized 2006) with properties that no evolved script can match:\n\n- **Strict phoneme-grapheme bijection**: every phoneme in the Manding inventory maps to exactly one character. No digraphs, no silent letters, no context-dependent pronunciation rules. - **Explicit tonal diacritics**: Bambara is tonal; N'Ko marks tone with combining characters above vowels. Latin Bambara orthography does not mark tone. - **Zero spelling irregularities**: English has ~1,100 letter-to-sound rules for ~44 phonemes. N'Ko has 1-to-1 correspondence for 33 phonemes.", "htmlHref": "/research/html/dead-circuits-and-living-speech-building-the-first-nko-ai-pipeline-ws41ik.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3939 }, { "id": "the-script-that-was-built-for-ai-and-that-ai-has-never-heard-of-to10t1", "title": "The Script That Was Built for AI (And That AI Has Never Heard Of)", "slug": "the-script-that-was-built-for-ai-and-that-ai-has-never-heard-of", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/posts/03-asr-pipeline-story.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "In 1949, a self-taught scholar in Kankan, Guinea named Solomana Kante designed a writing system from scratch. He was responding to a claim that African languages could not be written. He took that as a challenge and spent years analyzing the phonological structure of Manding languages, then built a script that encodes their sounds with a precision that linguists and engineers spend careers trying to achieve in synthetic alphabets.", "excerpt": "In 1949, a self-taught scholar in Kankan, Guinea named Solomana Kante designed a writing system from scratch. He was responding to a claim that African languages could not be written. He took that as a challenge and spent years analyzing the phonological structure of Manding languages, then built a script that encodes their sounds with a precision that linguists and engineers spend careers trying to achieve in synthetic alphabets.\n\nEvery phoneme gets exactly one character. Every character represents exactly one phoneme. Tone is marked explicitly. No digraphs. No silent letters. No exceptions.\n\nThe script is called N'Ko, which means \"I say\" in every Manding language. It has 40 million speakers across Guinea, Mali, Cote d'Ivoire, Senegal, Burkina Faso, and diaspora communities worldwide.\n\nThat is the paradox I spent the last several months trying to fix. Here is what I found.\n\nBefore building anything, I wanted to understand the problem precisely. Not \"N'Ko is underrepresented in training data\" as a vague statement, but a precise measurement of what that underrepresentation looks like inside a large language model.", "htmlHref": "/research/html/the-script-that-was-built-for-ai-and-that-ai-has-never-heard-of-to10t1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2895 }, { "id": "living-speech-building-the-first-nko-asr-for-14-ors8cm", "title": "Living Speech: Building the First N'Ko ASR for 14", "slug": "living-speech-building-the-first-nko-asr-for-14", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/substack/02-living-speech.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Every speech recognition system for Bambara outputs Latin characters. French colonial characters designed for French colonial administrators. Not for the 40 million people who actually speak and read these languages.", "excerpt": "Every speech recognition system for Bambara outputs Latin characters. French colonial characters designed for French colonial administrators. Not for the 40 million people who actually speak and read these languages.\n\nThis is the story of how a $14 experiment on consumer hardware produced a speech recognition system that competes with models 38 times its size. And why Solomana Kante's 1949 design decisions turned out to be a machine learning advantage nobody predicted.\n\nThere is no N'Ko speech corpus. Every Bambara audio dataset has Latin transcriptions. The FarmRadio datasets, the MALIBA-AI models, the Bayelemabaga corpus. All Latin output.\n\nIf you want to build a system that listens to Bambara and writes N'Ko, you first need to solve a problem that nobody has needed to solve before: convert thousands of Latin Bambara transcriptions into valid N'Ko.\n\nLatin Bambara was designed by French colonial linguists in the 20th century. It reflects French phonological conventions, not Manding phonological reality.", "htmlHref": "/research/html/living-speech-building-the-first-nko-asr-for-14-ors8cm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1660 }, { "id": "acoustic-world-models-and-the-nko-speech-inscription-bridge-ocpxoq", "title": "Acoustic World Models and the N'Ko Speech Inscription Bridge", "slug": "acoustic-world-models-and-the-nko-speech-inscription-bridge", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/ACOUSTIC-WORLD-MODEL-ESSAY.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "An acoustic world model is the deeper architecture implied by the work so far. It is not merely a better recognizer, and it is not simply another decoder sitting after Whisper. It is a different way of deciding what speech is inside the system. A normal ASR pipeline treats speech as a signal whose purpose is to become text. The model receives audio, compresses it into features, predicts symbols, and then the rest of the system tries to clean up those symbols. An acoustic world model treats speech as a world of acou", "excerpt": "An acoustic world model is the deeper architecture implied by the work so far. It is not merely a better recognizer, and it is not simply another decoder sitting after Whisper. It is a different way of deciding what speech is inside the system. A normal ASR pipeline treats speech as a signal whose purpose is to become text. The model receives audio, compresses it into features, predicts symbols, and then the rest of the system tries to clean up those symbols. An acoustic world model treats speech as a world of acoustic events. Text becomes one possible explanation of that world, not the world itself.\n\nThis shift matters because the current N'Ko system has already shown the limit of the recognizer-only framing. The iPhone proof established that the acoustic serving stack can run on device. Audio can move through a Whisper-style mel frontend, a split CoreML encoder, an anchor CTC head, greedy decoding, bounded correction, and a Swift ranker. The live harness can record microphone input, route it into the same machinery, and produce files that can be copied back from the phone. That is a real serving milestone. But the visible live output also showed that a completed inference path can still produce repetitive garbage. The system can finish the computation and still fail to know what it is allowed to say.\n\nThat is the moment where an acoustic world model becomes necessary. The failure is not only a decoder failure. It is an ontology failure. If the system believes that the primary object is the transcript, then any decoded string looks like an answer. If the system believes that the primary object is acoustic evidence, then the decoded string is only a hypothesis. The hypothesis can be accepted, rejected, deferred, or archived. The Speech Inscription Bridge v0 is the first implementation of that second worldview.\n\nThe current bridge says that every live or recorded ASR run should compile into audio evidence, a typed transcript decision, an acoustic and FAC claim scaffold, and a controlled N'Ko proof rendering. That structure is important because it changes the meaning of a run. A run is no longer a black box that produces text. A run becomes an evidential event. The captured waveform, prepared waveform, logits, argmax path, hashes, manifest, and proof rendering all become parts of a durable record. The transcript is not allowed to float away from the evidence that produced it.\n\nThe acoustic world model is the future representation engine that belongs inside this evidential structure. It would learn the structure of acoustic reality before the system commits to symbols. In the current system, the Whisper-style encoder and CTC head are doing most of the representational work. They produce hidden states, logits, and candidate symbols. A future acoustic wor", "htmlHref": "/research/html/acoustic-world-models-and-the-nko-speech-inscription-bridge-ocpxoq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2684 }, { "id": "tiktok-series-plan-creative-ai-mandinka-and-nko-18slquo", "title": "TikTok Series Plan: Creative AI, Mandinka, and N'Ko", "slug": "tiktok-series-plan-creative-ai-mandinka-and-nko", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/social/tiktok-nko-series/README.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This series should not feel like a research paper cut into clips. It should feel like a creator showing people a completely different way to use AI.", "excerpt": "This series should not feel like a research paper cut into clips. It should feel like a creator showing people a completely different way to use AI.\n\n> I used AI to reconnect with my native language, Mandinka, and it turned into a research project about whether machines can hear and write the language in the script built for it.\n\nThat is the center. The audience does not meet the project through CER, CTC, TAR, TTT, AGP, or paper structure. They meet it through a surprising claim: AI is not only for making images, writing emails, or generating captions. It can become a microscope for culture, language, memory, and identity.\n\nThe technical work still matters. It gives the story seriousness. But on TikTok, the research is the receipt, not the opening line.\n\n> \"Here is a way I used AI to investigate my own language, my own script, and the infrastructure gap around it.\"", "htmlHref": "/research/html/tiktok-series-plan-creative-ai-mandinka-and-nko-18slquo.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1719 }, { "id": "nko-sigil-semantics-1ys3ao8", "title": "N'Ko Sigil Semantics", "slug": "nko-sigil-semantics", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/docs/essays/SIGIL_SEMANTICS.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The N'Ko Inscription System uses 10 sigils as **operator markers**—single characters that encode both computational meaning and embodied experience. Each sigil is not arbitrary: it carries visual weight, semantic density, and gestural resonance.", "excerpt": "The N'Ko Inscription System uses 10 sigils as **operator markers**—single characters that encode both computational meaning and embodied experience. Each sigil is not arbitrary: it carries visual weight, semantic density, and gestural resonance.\n\nThis document maps each sigil to its: - **Visual representation** — The character and its typographic qualities - **Semantic meaning** — What the sigil encodes conceptually - **UI affordance** — What interaction patterns it suggests - **Motion signature** — The gesture that invokes or embodies it\n\n| Aspect | Description | |--------|-------------| | **Visual** | Open curves settling into a point. The character suggests convergence—like streams meeting. | | **Semantic** | The trajectory is contracting. Variance is dropping. The system is settling into coherence. | | **Detects** | Dispersion decreased measurably within a time window | | **UI Affordance** | **Lock/Confirm** — Tap-and-hold to confirm selection. The action commits, stabilizes choice. Visual: elements contract toward touch point. | | **Motion Signature** | *Closing grip* — Fingers drawing inward, palm settling. Like grasping something precious. | | **Examples** | Coming to rest, focusing, completing a gesture, saving work, confirming navigation |\n\n| Aspect | Description | |--------|-------------| | **Visual** | Radiating strokes, energy moving outward. The character embodies expansion, reaching. | | **Semantic** | The trajectory is expanding, exploring more state space. Variance is rising. The system is opening. | | **Detects** | Spread/entropy increased within a time window | | **UI Affordance** | **Expand/Explore** — Pinch-outward to reveal options. The action opens possibility space. Visual: elements bloom from center. | | **Motion Signature** | *Opening hands* — Fingers spreading, palms lifting. Like releasing seeds to wind. | | **Examples** | Starting movement, searching, agitation, browsing, exploring menus |\n\n| Aspect | Description | |--------|-------------| | **Visual** | A pivot point, stroke changing direction decisively. The character marks a boundary crossed. | | **Semantic** | A boundary has been crossed. The trajectory moved from one basin to another. A change point. | | **Detects** | Discrete change point — curvature spike in z-trajectory | | **UI Affordance** | **Switch/Navigate** — Swipe to change context. The action crosses a threshold. Visual: content slides away, new content arrives. | | **Motion Signature** | *Quick swipe* — Decisive horizontal movement, the hand committing to direction. Like turning a page. | | **Examples** | Changing activity, switching context, phase boundary, screen transition, mode change |", "htmlHref": "/research/html/nko-sigil-semantics-1ys3ao8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1699 }, { "id": "computational-choreography-architecture-design-v1-1t25ywd", "title": "Computational Choreography — Architecture Design V1", "slug": "computational-choreography-architecture-design-v1", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "omega-output/cc-body-instrument-20260323/cc-architecture-v1.md", "extension": "md", "score": 26, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` ┌─────────────────────────┐ │ MotionMix 9:16 │ ← italic serif watermark │ │ │ ┌───────────────┐ │ │ │ │ │ │ │ YOUR CHEST │ │ │ │ (cropped) │ │ │ │ │ │ │ │ HOUSE │ │ ← genre + BPM overlay │ │ 134 BPM │ │ │ └───────────────┘ │ │ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │ ← thin divider │ ┌───────────────┐ │ │ │ │ │ │ │ ● ORB ● │ │ ← reactive to movement │ │ /|||||||||\\ │ │ spikes = energy │ │ │ │ color = genre │ └───────────────┘ │ │ │ │ ● REC 02:34 │ ← recording indicator └─────────────────────────┘ ```", "excerpt": "### Split Screen Ratios - **Single camera**: 55% body / 45% orb (current) - **Multi-camera with AutoDirector**: 60% body (switches angles) / 40% orb - **Flex mode**: Body fills 70%, orb compact at 30% (focus on the flex)\n\n### Camera Crop - Top 25% cut (head hidden) - Bottom 15% cut (below waist hidden) - Result: chest, shoulders, arms, belt line visible - Applied via SwiftUI `.mask()` on iOS, CSS `clip-path` on web\n\n### Orb Behavior The orb is NOT just a visualizer. It's a **biofeedback mirror**:\n\n| Body State | Orb Response | |-----------|-------------| | Still | Dim core, no spikes, breathing pulse | | Subtle movement | 4-6 small spikes, warm purple | | Active groove | Full radial spikes, pink/red gradient, 60Hz pulse | | Peak energy | Spikes explode past outer ring, white flash core | | Section transition | Color shift (purple→red→orange based on section) | | Flex detected | Single sharp spike in flex direction (L or R) |\n\n### Overlays During Recording - **Flex mode**: \"L PEC\" / \"R PEC\" / combo counter (fades after 800ms) - **Gesture detected**: Gesture name badge (top, fades after 1.5s) - **Section change**: Section name pulses once (GROOVE → BUILD → CLIMAX) - **Beat position**: 16-dot indicator (subtle, bottom of orb area) - **Recording**: Red dot + timer (top-right)", "htmlHref": "/research/html/computational-choreography-architecture-design-v1-1t25ywd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 2355 }, { "id": "auto-dj-system-7qph37", "title": "Auto DJ System", "slug": "auto-dj-system", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/AUTO_DJ_README.md", "extension": "md", "score": 26, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "An intelligent automatic DJ system that analyzes tracks, selects optimal transitions, applies effects, and creates seamless mixes with beat matching and harmonic mixing.", "excerpt": "An intelligent automatic DJ system that analyzes tracks, selects optimal transitions, applies effects, and creates seamless mixes with beat matching and harmonic mixing.\n\n- **Intelligent Track Selection**: Uses harmonic mixing, BPM matching, and energy analysis to select compatible tracks - **Automatic Transitions**: Detects optimal transition points based on track analysis (drops, breakdowns, builds) - **Effect Application**: Applies transition effects (censor, filter, echo, reverb) synchronized to beats - **Multiple Mixing Strategies**: Choose from harmonic, BPM, energy, composite, or random strategies - **Queue Management**: Add tracks to queue with automatic analysis - **Voice Control**: All Auto DJ features accessible via voice commands\n\n- **`queue_manager.py`**: Manages track queue with analysis metadata - **`mix_strategies.py`**: Provides mixing strategies (harmonic, BPM, energy, composite) - **`effect_controller.py`**: Handles effect application and timing - **`auto_dj.py`**: Main orchestrator that coordinates all components\n\nThe Auto DJ is integrated into the voice control system (`voice_controller.py`) and can be controlled via voice commands.\n\n2. **Add Tracks to Queue**: - Programmatically: Use `VoiceController.add_track_to_queue(track_path)` - Via Serato: Load tracks in Serato library (future integration)", "htmlHref": "/research/html/auto-dj-system-7qph37.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 855 }, { "id": "git-synchronization-strategy-kqv0k0", "title": "Git Synchronization Strategy", "slug": "git-synchronization-strategy", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/03-guides/GIT_SYNC_STRATEGY.md", "extension": "md", "score": 26, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "``` Main Repo (points to cc-studio.git) ❌ MISMATCHED │ ├── apps/ios/cc-handguard/.git # Separate repo ├── apps/web/cc-dashboard/.git # Separate repo (has remote) ├── apps/web/cc-studio/.git # Separate repo │ ├── core/cc-core/.git # Separate repo ├── core/cc-trajectory/.git # Separate repo (large, 4GB) │ └── [6 more nested repos inside trajectory] # Deep nesting │ └── backend/cc-mcs/.git # Likely exists ```", "excerpt": "### Main Repository - **Current remote**: `https://github.com/Diomandeee/cc-studio.git` - **Issue**: Points to cc-studio but contains entire Computational Choreography project - **Recent commits**: Show submodule updates for cc-dashboard\n\n**Git is confused** because: 1. Your main repo remote is `cc-studio.git` (just one component) 2. But the repo contains the entire 17GB Computational Choreography project 3. You have nested repos that are **not configured as submodules** 4. Git sees these nested repos as \"deleted files\" (the `D` in git status)\n\n**Yes, it's a good idea** to keep everything in one repository using **Git Submodules**.\n\n**Benefits**: - ✅ Work on entire project in one place - ✅ Each component has its own repo (independent versioning) - ✅ Main repo tracks specific commits of each submodule - ✅ Easy to update individual components - ✅ Can open in one IDE/workspace\n\n**Challenges**: - ⚠️ Requires explicit submodule commands (`git submodule update`) - ⚠️ Collaborators need to know about submodules - ⚠️ Slightly more complex workflow", "htmlHref": "/research/html/git-synchronization-strategy-kqv0k0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1674 }, { "id": "trajectoryos-desktop-rust-tauri-implementation-yp0fuu", "title": "TrajectoryOS Desktop: Rust + Tauri Implementation", "slug": "trajectoryos-desktop-rust-tauri-implementation", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/05-research/TRAJECTORYOS_TAURI_PROPOSAL.md", "extension": "md", "score": 26, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "**Status**: 🔮 **Planned** - Complete implementation proposal, ready to start **Last Updated**: December 21, 2025 **Alternative to**: Native macOS approach ([see comparison](TRAJECTORYOS_DESKTOP_PROPOSAL.md)) **Integration**: Works with existing [trajectory-core](core/cc-trajectory/services/trajectory-core/README.md) backend", "excerpt": "**Status**: 🔮 **Planned** - Complete implementation proposal, ready to start **Last Updated**: December 21, 2025 **Alternative to**: Native macOS approach ([see comparison](TRAJECTORYOS_DESKTOP_PROPOSAL.md)) **Integration**: Works with existing [trajectory-core](core/cc-trajectory/services/trajectory-core/README.md) backend\n\n**Quick Navigation**: - [Why Tauri?](#-why-tauri-over-native-macos) - Decision rationale - [15-Min Setup](#-getting-started-no-apple-id) - Get running fast - [Architecture](#-tauri-architecture) - System design - [Implementation](#-rust-backend-implementation) - Code examples - [vs Native](#tauri-vs-electron-vs-native) - Platform comparison\n\nThis document proposes implementing TrajectoryOS Desktop using **Rust + Tauri**, a modern framework that combines: - **Rust Backend**: High-performance native code - **Web Frontend**: React/TypeScript UI - **Native Webview**: OS-native rendering (not Chromium) - **Cross-Platform**: Windows, macOS, Linux from one codebase\n\n**Key Advantage**: **No Apple ID required for development** - can develop on any platform.\n\n**Problem**: Out of Apple IDs, need to wait for Xcode development **Solution**: Tauri development works on **any OS** (Windows, Linux, macOS)", "htmlHref": "/research/html/trajectoryos-desktop-rust-tauri-implementation-yp0fuu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3263 }, { "id": "lora-persona-override-research-and-recommendations-1o2ez3n", "title": "LoRA Persona Override: Research and Recommendations", "slug": "lora-persona-override-research-and-recommendations", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/karl/lora-persona-research.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Target: Make Qwen2.5-7B-Instruct-4bit fully adopt Mohamed's communication style. > Hardware: Mac5 (M4 16GB), MLX mlx_lm LoRA trainer. > Data: 3,126 training examples in ChatML format. > Date: 2026-03-22", "excerpt": "> Target: Make Qwen2.5-7B-Instruct-4bit fully adopt Mohamed's communication style. > Hardware: Mac5 (M4 16GB), MLX mlx_lm LoRA trainer. > Data: 3,126 training examples in ChatML format. > Date: 2026-03-22\n\nThe current configuration has **four compounding problems** that prevent persona override:\n\n| Parameter | Current | Problem | |-----------|---------|---------| | LoRA rank | 16 | Too low for style transfer. Only captures task patterns, not voice. | | Num layers | 8 / 28 | 71% of the model is frozen. MLP layers (where style lives) are mostly untouched. | | Learning rate | 1e-5 | Too conservative. The adapter barely nudges the base model's distribution. | | System prompt | ~456 chars avg, up to 2055 chars | Massive context window consumed by tool call history. Dilutes the persona signal with noise. |\n\nThe base Qwen2.5-7B-Instruct has deep instruct conditioning baked through all 28 transformer layers. With rank 16 on only 8 layers, you are trying to override a 7-billion-parameter personality with ~4M trainable parameters touching 28% of the network. The instruct persona dominates by default.\n\n- Sebastian Raschka's experiments (hundreds of LoRA runs): rank 256 \"significantly improved performance\" over rank 8. With r=256 and alpha=512, results matched full fine-tuning. Ranks above 256 (512, 1024) failed to converge. Source: https://magazine.sebastianraschka.com/p/practical-tips-for-finetuning-llms", "htmlHref": "/research/html/lora-persona-override-research-and-recommendations-1o2ez3n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2976 }, { "id": "modra-full-product-roadmap-g1g3yx", "title": "MODRA — Full Product Roadmap", "slug": "modra-full-product-roadmap", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "projects/Modra/ROADMAP.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Brand:** MODRA | \"STRENGTH REFINED\" **Founder/Model:** Mohamed Diomande **Positioning:** Utility fashion — functional garments for the dual-phone lifestyle **Category:** Compression wear + accessories", "excerpt": "**Brand:** MODRA | \"STRENGTH REFINED\" **Founder/Model:** Mohamed Diomande **Positioning:** Utility fashion — functional garments for the dual-phone lifestyle **Category:** Compression wear + accessories\n\n### SKU 1: The Compression Brief (working name: \"DUAL\") 5\" boxer brief with two integrated phone pouches — one per side.\n\n**Core Problem:** Carrying two iPhones daily without pockets, bags, or risk of drops.\n\n**Differentiator:** Every phone-pocket compression short on the market carries ONE phone. DUAL carries TWO. No competitor (WOLACO, All Citizens, FlipBelt) offers symmetric dual-phone carry in a boxer brief form factor.\n\n**Competitive Landscape:** - [WOLACO](https://wolaco.com) — single sweat-proof pocket, compression pants/shorts - [All Citizens Tactical II](https://allcitizens.com) — waterproof hip pockets, silicone grip legs, single phone - [FlipBelt](https://flipbelt.com) — 360° waistband storage, single primary pocket - None offer dual-phone carry in a boxer brief", "htmlHref": "/research/html/modra-full-product-roadmap-g1g3yx.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3350 }, { "id": "snap-to-make-strategy-brief-xht0kz", "title": "Snap-to-Make — Strategy Brief", "slug": "snap-to-make-strategy-brief", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "snap-to-make-strategy.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Both clips ride the same trending audio (\"Oh what are you doing? Quality, find out. I need a name…\") over the **Alibaba/1688 interior-design dupe** format:", "excerpt": "# Snap-to-Make — Strategy Brief > AI photo → 3D → CAD → manufactured object marketplace > Seeded from two TikToks (@ava.dupes, @sophiegregory__) | 2026-05-31\n\nBoth clips ride the same trending audio (\"Oh what are you doing? Quality, find out. I need a name…\") over the **Alibaba/1688 interior-design dupe** format:\n\n- **@sophiegregory__** — \"saving thousands 🫠 #interiordesignhacks #alibaba #fyp\" — **212.2K views, 20.7K likes, 281 comments, 4,988 reposts**. Sophie is an interior designer. - **@ava.dupes** — 39s, dedicated dupe-finding account.\n\nThe behavior shown: see an expensive designer piece → reverse-image-search it on Alibaba/1688 → find the actual factory that makes it → buy direct for a fraction of retail.\n\n**The number that matters: ~2.3% repost rate** (4,988 shares / 212K views). That's people DMing the clip to a friend saying \"we should do this.\" Extremely high commercial/save intent. This is not entertainment content — it's actionable, and the action is currently painful and manual.", "htmlHref": "/research/html/snap-to-make-strategy-brief-xht0kz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1721 }, { "id": "buf-barista-performance-protocols-eir384", "title": "Buf Barista — Performance Protocols", "slug": "buf-barista-performance-protocols", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "spine/Buf Barista/reference/PERFORMANCE_PROTOCOLS.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document defines the exact procedures for all Buff Barista performance modes. These protocols ensure consistency, safety, and quality across all public appearances.", "excerpt": "This document defines the exact procedures for all Buff Barista performance modes. These protocols ensure consistency, safety, and quality across all public appearances.\n\n| Mode | Description | Typical Duration | |------|-------------|------------------| | **DJ Set** | Music mixing with crowd engagement | 30 min - 2 hours | | **Handstand Performance** | Signature athletic demonstration | 30 sec - 2 min per attempt | | **Dancing with Weights** | Movement performance with dumbbells | 3-5 min per song | | **Buff Flow Session** | Full structured dance-fitness workout | 15-60 min | | **Comp-Core Integration** | Motion-reactive DJ performance | Variable |\n\n| Phase | Duration | BPM Range | Energy | Purpose | |-------|----------|-----------|--------|---------| | Opener | 5 min | 100-110 | 6/10 | Warm up crowd, establish presence | | Build | 10 min | 110-125 | 7-8/10 | Increase energy, test response | | Peak | 10 min | 125-135 | 9-10/10 | Maximum energy, signature moments | | Closer | 5 min | 120-110 | 7/10 | Controlled descent, memorable finish |\n\n| Phase | Duration | BPM Range | Energy | Notes | |-------|----------|-----------|--------|-------| | Opener | 8 min | 95-105 | 5/10 | Atmospheric, let crowd settle | | Warm-up | 12 min | 105-120 | 6-7/10 | Build recognition, familiar tracks | | Build 1 | 10 min | 120-128 | 8/10 | First energy push | | Peak 1 | 8 min | 128-135 | 10/10 | First climax | | Valley | 7 min | 115-120 | 6/10 | Recovery, regroup | | Build 2 | 7 min | 120-130 | 8-9/10 | Second push | | Peak 2 | 5 min | 130-140 | 10/10 | Maximum moment | | Closer | 3 min | 120-100 | 7/10 | Graceful exit |\n\nFollow standard structure with: - 3-4 peak moments - 2-3 valleys for recovery - More variety in genre/era - Planned handstand or weights moments", "htmlHref": "/research/html/buf-barista-performance-protocols-eir384.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3733 }, { "id": "buf-barista-development-roadmap-1m5bpau", "title": "Buf Barista — Development Roadmap", "slug": "buf-barista-development-roadmap", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "spine/Buf Barista/ROADMAP.md", "extension": "md", "score": 26, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Attribute | Value | |-----------|-------| | Current Phase | Phase 1: Content Foundation | | Overall Progress | 20% | | Target Completion | Ongoing (character, not project) | | Near-Term Focus | Random public DJ sets + fitness stunts | | Key Milestone | First viral content piece | | Blockers | Portable DJ setup TBD |", "excerpt": "| Attribute | Value | |-----------|-------| | Current Phase | Phase 1: Content Foundation | | Overall Progress | 20% | | Target Completion | Ongoing (character, not project) | | Near-Term Focus | Random public DJ sets + fitness stunts | | Key Milestone | First viral content piece | | Blockers | Portable DJ setup TBD |\n\n| Phase | Name | Status | Completion | |-------|------|--------|------------| | 0 | Character Definition | Complete | 100% | | 1 | Content Foundation | In Progress | 30% | | 1.5 | Buff Flow Development | Planned | 0% | | 1.7 | Buff Flow Crew | Planned | 0% | | 2 | Signature Moves | Planned | 0% | | 3 | Regular Content Cadence | Planned | 0% | | 4 | BWB Integration | Planned | 0% | | 5 | Expansion / Teaching | Future | 0% |\n\n### Phase 0: Character Definition **Status:** Complete **Completed:** 2026-01-16\n\n#### Objectives 1. Define Buff Barista as distinct character/persona 2. Clarify relationship to BWB (separate entities) 3. Establish the gimmick (apron + weights) 4. Document the dream (one-handed handstand latte art)\n\n#### Deliverables - [x] PROJECT.md documenting character identity - [x] Clear distinction: Buff Barista (character) vs BWB (business) - [x] Signature look defined: apron + weights - [x] Content pillars identified", "htmlHref": "/research/html/buf-barista-development-roadmap-1m5bpau.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2291 }, { "id": "agent-reputation-system-status-report-vew4du", "title": "Agent Reputation System - Status Report", "slug": "agent-reputation-system-status-report", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "agent-reputation/docs/SYSTEM_STATUS.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Generated:** 2025-02-02 **Version:** Gen 7 (HEF Evolution) **Project:** [home]/Desktop/agent-reputation", "excerpt": "**Generated:** 2025-02-02 **Version:** Gen 7 (HEF Evolution) **Project:** [home]/Desktop/agent-reputation\n\n| Component | File | Status | Description | |-----------|------|--------|-------------| | **Trust Bootstrap Engine** | `trust-bootstrap.ts` | ✅ Complete | Cold-start reputation via calibrated challenges | | **Prediction Markets** | `reputation_markets.py` | ✅ Complete | Stake reputation on task outcome predictions | | **Prediction Markets (TS)** | `src/prediction-market.ts` | ✅ Complete | TypeScript implementation with trading | | **Reputation Dynamics** | `reputation_dynamics.py` | ✅ Complete | Cascade propagation & trajectory tracking | | **Reputation Lineage** | `reputation_lineage.py` | ✅ Complete | Hereditary reputation, spawn stakes | | **Federated Trust** | `federated.py` | ✅ Complete | Cross-system trust federation | | **Trust Query Engine** | `trust_query_engine.py` | ✅ Complete | GraphQL-style reputation queries | | **Expertise Discovery** | `expertise_discovery.py` | ✅ Complete | Auto-discover agent skills | | **Democratic Governance** | `democratic_governance.py` | ✅ Complete | Agent voting & proposals | | **Emergent Specialization** | `emergent_specialization.py` | ✅ Complete | Self-organizing role assignment | | **Collective Deliberation** | `collective_deliberation.py` | ✅ Complete | Multi-agent consensus | | **Adversarial Validation** | `adversarial_validation.py` | ✅ Complete | Challenge-based trust verification |\n\n| Demo | Command | Status | |------|---------|--------| | TypeScript Demo | `npm run demo` | ✅ Works | | Markets Demo | `python3 reputation_markets.py` | ✅ Works | | Dynamics Demo | `python3 reputation_dynamics.py` | ✅ Works |\n\n### Prediction Market Performance - **Market implied probability:** 55.6% (pre-resolution) - **Stake utilization:** 45 rep across 3 agents - **Routing confidence:** 64% for recommended agent\n\n### Cascade Propagation - **Events per cascade:** ~13 propagation events - **Affected agents:** 4 from single origin - **Total delta distributed:** 0.321 rep points - **Max generation depth:** 2 hops", "htmlHref": "/research/html/agent-reputation-system-status-report-vew4du.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 760 }, { "id": "dispatching-parallel-agents-6tb05n", "title": "Dispatching Parallel Agents", "slug": "dispatching-parallel-agents", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anthropic-skills/claude-superpowers/skills/dispatching-parallel-agents/SKILL.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "When you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.", "excerpt": "--- name: dispatching-parallel-agents description: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies ---\n\nWhen you have multiple unrelated failures (different test files, different subsystems, different bugs), investigating them sequentially wastes time. Each investigation is independent and can happen in parallel.\n\n**Core principle:** Dispatch one agent per independent problem domain. Let them work concurrently.\n\n**Use when:** - 3+ test files failing with different root causes - Multiple subsystems broken independently - Each problem can be understood without context from others - No shared state between investigations\n\n**Don't use when:** - Failures are related (fix one might fix others) - Need to understand full system state - Agents would interfere with each other", "htmlHref": "/research/html/dispatching-parallel-agents-6tb05n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 872 }, { "id": "code-review-reception-1flajcf", "title": "Code Review Reception", "slug": "code-review-reception", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anthropic-skills/claude-superpowers/skills/receiving-code-review/SKILL.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. READ: Complete feedback without reacting 2. UNDERSTAND: Restate requirement in own words (or ask) 3. VERIFY: Check against codebase reality 4. EVALUATE: Technically sound for THIS codebase? 5. RESPOND: Technical acknowledgment or reasoned pushback 6. IMPLEMENT: One item at a time, test each ```", "excerpt": "--- name: receiving-code-review description: Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation ---\n\n**Core principle:** Verify before implementing. Ask before assuming. Technical correctness over social comfort.\n\n**NEVER:** - \"You're absolutely right!\" (explicit CLAUDE.md violation) - \"Great point!\" / \"Excellent feedback!\" (performative) - \"Let me implement that now\" (before verification)\n\n**INSTEAD:** - Restate the technical requirement - Ask clarifying questions - Push back with technical reasoning if wrong - Just start working (actions > words)\n\n### From your human partner - **Trusted** - implement after understanding - **Still ask** if scope unclear - **No performative agreement** - **Skip to action** or technical acknowledgment", "htmlHref": "/research/html/code-review-reception-1flajcf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 929 }, { "id": "mcp-server-development-guide-15jkqzr", "title": "MCP Server Development Guide", "slug": "mcp-server-development-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anthropic-skills/skills/mcp-builder/SKILL.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Create MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. The quality of an MCP server is measured by how well it enables LLMs to accomplish real-world tasks.", "excerpt": "--- name: mcp-builder description: Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK). license: Complete terms in LICENSE.txt ---\n\nCreate MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. The quality of an MCP server is measured by how well it enables LLMs to accomplish real-world tasks.\n\n**API Coverage vs. Workflow Tools:** Balance comprehensive API endpoint coverage with specialized workflow tools. Workflow tools can be more convenient for specific tasks, while comprehensive coverage gives agents flexibility to compose operations. Performance varies by client—some clients benefit from code execution that combines basic tools, while others work better with higher-level workflows. When uncertain, prioritize comprehensive API coverage.\n\n**Tool Naming and Discoverability:** Clear, descriptive tool names help agents find the right tools quickly. Use consistent prefixes (e.g., `github_create_issue`, `github_list_repos`) and action-oriented naming.\n\n**Context Management:** Agents benefit from concise tool descriptions and the ability to filter/paginate results. Design tools that return focused, relevant data. Some clients support code execution which can help agents filter and process data efficiently.", "htmlHref": "/research/html/mcp-server-development-guide-15jkqzr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1143 }, { "id": "clarity-agent-protocol-cap-16pn2ko", "title": "Clarity Agent Protocol (CAP)", "slug": "clarity-agent-protocol-cap", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "clarity-agent-protocol/CLAUDE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` ┌─────────────────────────┐ │ CONTRACT REGISTRY │ │ (schemas + traits) │ └───────────┬─────────────┘ │ ┌───────────────────┼───────────────────┐ ↓ ↓ ↓ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ Task Contract │ │ Task Contract │ │ Task Contract │ │ schema: X │ │ schema: Y │ │ schema: Z │ │ traits: [a,b] │ │ traits: [b,c] │ │ traits: [a,c] │ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ │ │ │ ↓ ↓ ↓ ┌───────────────────────────────────────────────────────┐ │ AGENT DISPATCHER │ │ Matches contra", "excerpt": "## What This Is An agent-agnostic governance protocol for AI agent task execution. Inspired by Stacks/Clarity smart contracts — tasks are structured as **contracts** with **traits**, **schemas**, and **validation rules**. Any agent, any model, any system can submit work. The protocol validates conformance and rejects non-compliant output with structured feedback.\n\n## Core Concept Just as Clarity smart contracts on Stacks enforce trait conformance at the chain level, CAP enforces task conformance at the agent orchestration level. Agents don't just \"do work\" — they fulfill contracts. Contracts define what success looks like. Non-conforming work gets rejected with specific feedback, not vague \"try again.\"\n\n### Contracts A contract defines a unit of work with: - **Schema**: Expected input/output structure - **Traits**: Capabilities required (`buildable`, `testable`, `deployable`) - **Validation rules**: How to check conformance - **Governance**: Who can approve, auto-merge thresholds\n\n### Traits (from Clarity) Composable interfaces agents declare they can fulfill: - `impl-buildable` — output compiles/builds without errors - `impl-testable` — includes tests that pass - `impl-deployable` — ready for production deployment - `impl-reviewable` — structured for code review - `impl-documented` — includes documentation - Custom traits per project\n\n### Governance - **Auto-accept threshold**: contracts that score above N% conformance auto-merge - **Review gate**: below threshold → human or senior agent review - **Escalation**: repeated failures bump to higher-tier agent - **Rejection feedback**: structured, actionable — not \"try again\" but \"trait X failed because Y, fix by doing Z\"", "htmlHref": "/research/html/clarity-agent-protocol-cap-16pn2ko.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 791 }, { "id": "echelon-web-visualization-cwy55g", "title": "Echelon Web Visualization", "slug": "echelon-web-visualization", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/apps/desktop/echelon/web-viz/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **3D Latent Orb**: GPU-accelerated sphere with custom shaders - Energy-based scaling - Residual glow effects - Fresnel rim lighting - Animated noise distortion", "excerpt": "- **3D Latent Orb**: GPU-accelerated sphere with custom shaders - Energy-based scaling - Residual glow effects - Fresnel rim lighting - Animated noise distortion\n\nThe dev server runs on http://localhost:3000 and proxies WebSocket connections to the Rust backend on port 8080.\n\n- **Mouse drag**: Rotate camera - **Mouse wheel**: Zoom in/out - **Right-click drag**: Pan camera\n\nEdit `src/shaders/orbVertex.glsl` and `orbFragment.glsl` to customize the orb appearance.\n\nModify the color schemes in: - `src/components/LatentOrb.jsx` - Main orb color - `src/components/TrailParticles.jsx` - Trail color - `src/components/TelemetryOverlay.css` - UI colors", "htmlHref": "/research/html/echelon-web-visualization-cwy55g.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 350 }, { "id": "websocket-protocol-cc-mcs-echeloncapture-jucdzg", "title": "WebSocket Protocol: cc-mcs ↔ EchelonCapture", "slug": "websocket-protocol-cc-mcs-echeloncapture", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/apps/ios/EchelonCapture/docs/legacy/WEBSOCKET_PROTOCOL.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Currently EchelonCapture **sends** sensor data to cc-mcs via HTTP POST. Now we need **bidirectional communication** so EchelonCapture can **receive** visualization data.", "excerpt": "Currently EchelonCapture **sends** sensor data to cc-mcs via HTTP POST. Now we need **bidirectional communication** so EchelonCapture can **receive** visualization data.\n\n**Query params:** - `device_id`: Which device this is (left, right, watch) - Optional: `subscribe`: Comma-separated list of channels (latent,trajectory,pattern,audio)\n\n### Authentication None required for now (same network assumption as existing HTTP)\n\n| Message Type | Frequency | Bandwidth | Priority | |--------------|-----------|-----------|----------| | `latent_state` | 50 Hz | ~2 KB/s | 🔴 Critical | | `trajectory` | 20 Hz | ~3 KB/s | 🟡 High | | `audio` | 30 Hz | ~1 KB/s | 🟡 High | | `pattern` | 1-4 Hz | ~0.5 KB/s | 🟢 Medium | | `section` | 0.01-0.05 Hz | ~0.01 KB/s | 🟢 Medium | | `ambient_aura` | 5 Hz | ~0.2 KB/s | ⚪ Low |\n\nEchelonCapture should: 1. Show connection lost indicator 2. Attempt reconnect every 2 seconds 3. Continue sensor streaming (HTTP still works) 4. Resume visualization when reconnected", "htmlHref": "/research/html/websocket-protocol-cc-mcs-echeloncapture-jucdzg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1065 }, { "id": "trajectory-apps-s7alpf", "title": "Trajectory Apps", "slug": "trajectory-apps", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/trajectory/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Decomposed from the original monolithic `trajectory-desktop` Tauri app (95K+ LOC) into focused, independently-buildable applications.", "excerpt": "Decomposed from the original monolithic `trajectory-desktop` Tauri app (95K+ LOC) into focused, independently-buildable applications.\n\n### trajectory-desktop (Reference) - **Status:** ✅ Complete (restored from main branch) - **Stack:** Tauri 1.5 + React 18 + Vite + Tailwind - **Description:** The original monolithic app with 80+ Tauri commands, full frontend with Dashboard, CalendarAI, GoalManager, InsightsDashboard, SkillGraph, Interview, PlanningDashboard, and more. - **Backend:** Rust with `commands.rs` (1324 lines), `database.rs` (4435 lines), `mcp.rs` (379 lines) - **Frontend:** React with comprehensive component library, hooks, and lib modules - **Build:** `npm install && npm run tauri dev`\n\n### trajectory-search - **Status:** 🚧 In Progress (stub backend, partial frontend) - **Stack:** Tauri + React + Vite - **Description:** Focused semantic search engine extracted from the desktop monolith. Has React components for real-time ledger feed and evolution timeline. Backend Rust modules are stubbed — need implementation extracted from trajectory-desktop's commands.rs. - **Frontend files:** LedgerFeed, EvolutionTimeline, useEvolutionBridge, useLedgerRealtime - **Build:** `npm install && cargo build` (stubs only, won't produce working app yet)\n\n### trajectory-orbit - **Status:** 🚧 In Progress (core Rust crates + deploy configs) - **Stack:** Rust workspace (orbit-core + orbit-server) - **Description:** Project orchestration service with graph kernel bridge and cognitive twin integration. Includes Prometheus metrics, Docker Compose deployment, Grafana dashboards, and Caddy reverse proxy configs. - **Crates:** - `orbit-core` — Graph kernel bridge (252 lines) + Cognitive twin bridge (173 lines) - `orbit-server` — Axum HTTP server with Prometheus metrics (67 lines) - **Build:** `cargo build` from the trajectory-orbit directory - **Deploy:** See `deploy/` for Docker Compose, Grafana, Prometheus, and Caddy configs\n\n### trajectory-mobile - **Status:** ✅ Complete (Swift iOS app) - **Stack:** Swift / SwiftUI / iOS - **Description:** iOS companion app with 54 source files. Features: Dashboard, Session management, Idea Vault, Dream Swarm, Skill tracking, Voice capture, Hand guard, Batch compose, Gateway settings, Account switcher. Includes App Intents (Siri), widgets, Bonjour discovery, WebSocket gateway. - **Build:** Open in Xcode, requires iOS development environment", "htmlHref": "/research/html/trajectory-apps-s7alpf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 742 }, { "id": "modular-voice-control-system-a1pu3o", "title": "Modular Voice Control System", "slug": "modular-voice-control-system", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/voice_control/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A comprehensive, extensible voice control system for DJ control using Gemini Live API with track analysis and intelligent transition recommendations.", "excerpt": "A comprehensive, extensible voice control system for DJ control using Gemini Live API with track analysis and intelligent transition recommendations.\n\n### Core Functionality - **Real-time Voice Recognition**: Uses Gemini Live API for high-accuracy speech recognition - **Command Matching**: Fuzzy matching with command buffering for multi-word commands - **Keyboard Execution**: Sends keyboard shortcuts to control Serato DJ - **Deck Management**: Tracks current deck and manages state\n\n### Advanced Features - **Track Analysis**: On-demand audio analysis using librosa - BPM detection - Beat grid extraction - Drop detection (energy spikes) - Build-up detection - Section detection (breakdowns, builds) - **Transition Recommendations**: AI-powered suggestions using Gemini - Harmonic mixing (key compatibility) - Energy matching - Beat alignment - Optimal timing suggestions\n\n### Higher-Order Commands - **Play Next**: Loads and plays next track - **Continuous Mode**: Auto-play with automatic track loading - **Transitions**: Smooth transitions between tracks - **Sync & Play**: Beat-matched transitions\n\nTrack analysis is automatically triggered when: - User navigates library (\"next track\", \"move down\") - User loads tracks (\"load left\", \"load right\")", "htmlHref": "/research/html/modular-voice-control-system-a1pu3o.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 764 }, { "id": "music-pipeline-consolidation-summary-1it21f4", "title": "Music Pipeline Consolidation Summary", "slug": "music-pipeline-consolidation-summary", "kind": "proposal", "program": "Research Backlog", "sourceAnchor": "Comp-Core/backend/cc-music-pipeline/python/CONSOLIDATION.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Old File | New Location | Status | |----------|--------------|--------| | `parse_soundcloud_likes.py` | `sources/soundcloud.py` | Merged | | `parse_soundcloud_v2.py` | `sources/soundcloud.py` | Merged | | `download_music.py` | `download/downloader.py` | Merged | | `download_music_to_gcs.py` | `storage/gcs.py` | Merged | | `process_all_tracks.py` | `pipeline.py` | Merged | | `process_music_list.py` | `pipeline.py` | Merged | | `process_soundcloud_likes.py` | `pipeline.py` | Merged | | `reprocess_soundcloud.py` | `", "excerpt": "This document tracks the consolidation of music pipeline code into `backend/cc-music-pipeline/python/`.\n\n| Old File | New Location | Status | |----------|--------------|--------| | `parse_soundcloud_likes.py` | `sources/soundcloud.py` | Merged | | `parse_soundcloud_v2.py` | `sources/soundcloud.py` | Merged | | `download_music.py` | `download/downloader.py` | Merged | | `download_music_to_gcs.py` | `storage/gcs.py` | Merged | | `process_all_tracks.py` | `pipeline.py` | Merged | | `process_music_list.py` | `pipeline.py` | Merged | | `process_soundcloud_likes.py` | `pipeline.py` | Merged | | `reprocess_soundcloud.py` | `cli.py research` | Merged | | `retry_failed_tracks.py` | `cli.py retry` | Merged | | `run_pipeline.py` | `cli.py ingest` | Merged | | `debug_search.py` | `search/youtube.py` | Merged | | `test_improved_search.py` | - | Test only, not needed | | `test_music_pipeline.py` | - | Test only, not needed | | `test_query_cleaning.py` | - | Test only, not needed | | `MUSIC_PIPELINE_ROADMAP.md` | Archived | Reference only | | `RESUME_DOWNLOADS.md` | - | Obsolete |\n\nAll output data files have been copied to `backend/cc-music-pipeline/python/data/`:\n\n- `all_liked.txt` - Original SoundCloud likes (478 tracks) - `soundcloud_likes_youtube_results.json` - YouTube search results (286 found) - `download_progress.json` - Download progress tracking - `all_music_search_results.json` / `.csv` - Additional search results - `soundcloud_youtube_urls.txt` - Found YouTube URLs\n\n| Feature | Old (`tools/`) | New (`cc_music_ingestion`) | |---------|----------------|----------------------------| | SoundCloud parsing | Multiple scripts | `SoundCloudParser` class | | YouTube search | In-line code | `YouTubeSearcher` with query variants | | Download | Basic | Exponential backoff, retry logic | | GCS upload | Script-only | `GCSStorage` class with database | | Rate limiting | Manual | Automatic detection and backoff | | Progress tracking | JSON files | Unified progress system | | CLI | Multiple scripts | Single `cli.py` with subcommands | | Paste mode | N/A | New feature | | Cloud Run | Dockerfile.cloud | Integrated Dockerfile |", "htmlHref": "/research/html/music-pipeline-consolidation-summary-1it21f4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 562 }, { "id": "trajectoryos-models-11fr0i0", "title": "TrajectoryOS Models", "slug": "trajectoryos-models", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/ai-models/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **skill_graph/**: Bayesian inference on skill competencies with graph-based message passing - **alignment/**: Embedding-based project coherence and alignment scoring - **gravity_mass/**: Constraint-based gravity estimation and structural mass computation - **life_state/**: Full latent dynamical system for life-state evolution and forecasting - **echelon_fusion/**: Embodied signal → life physics mapping (integrates movement data) - **generators/**: Scenario generation and plan evaluation", "excerpt": "This directory contains the Python-based modeling and inference stack for TrajectoryOS.\n\nThe models layer is the \"brain\" that the TypeScript Trajectory-Core service calls into for sophisticated inference:\n\n- **skill_graph/**: Bayesian inference on skill competencies with graph-based message passing - **alignment/**: Embedding-based project coherence and alignment scoring - **gravity_mass/**: Constraint-based gravity estimation and structural mass computation - **life_state/**: Full latent dynamical system for life-state evolution and forecasting - **echelon_fusion/**: Embodied signal → life physics mapping (integrates movement data) - **generators/**: Scenario generation and plan evaluation\n\n- **Thrust (T)**: Productive capacity from skills × time investment - **Alignment (A)**: How coherently projects and skills point in the same direction - **Gravity (G)**: Downward pull from constraints, obligations, stress - **Mass (M)**: Structural inertia from complexity and coupling - **Escape Index (η)**: η = T_eff / (G·M), where T_eff = T × A\n\nThese models are called by: - Background workers (periodic updates) - Real-time API endpoints (on-demand inference) - PlannerAgent (for scenario generation)", "htmlHref": "/research/html/trajectoryos-models-11fr0i0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 262 }, { "id": "trajectoryos-quick-start-guide-11tsqmn", "title": "TrajectoryOS Quick Start Guide", "slug": "trajectoryos-quick-start-guide", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/guides/QUICKSTART.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "TrajectoryOS is a life physics engine that models your career trajectory using computational physics. It treats your life as a dynamical system with:", "excerpt": "TrajectoryOS is a life physics engine that models your career trajectory using computational physics. It treats your life as a dynamical system with:\n\n- **T (Thrust)**: Your skill capacity × utilization × alignment - **A (Alignment)**: How well your projects match your skills - **G (Gravity)**: Constraints pulling you back - **M (Mass)**: Inertia from existing projects/dependencies - **η (Escape Index)**: T×A / G×M - your trajectory toward goals\n\n- **Python 3.9+** with pip - **Node.js 18+** with npm - **SQLite** (included with Python)\n\n**What happens:** 1. Evidence stored in SQLite 2. Python Bayesian model updates belief (posterior mean & std) 3. Belief propagates through skill graph 4. Updated beliefs returned with uncertainty estimates\n\n**What happens:** 1. Python scenario generator creates 10 different action plans 2. Each scenario is simulated using life state dynamics model 3. Scenarios are evaluated by final escape index (η) and escape probability 4. Results ranked by best outcome", "htmlHref": "/research/html/trajectoryos-quick-start-guide-11tsqmn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 912 }, { "id": "liquid-chat-ui-one-chat-to-rule-them-all-i32cvy", "title": "Liquid Chat UI - One Chat to Rule Them All", "slug": "liquid-chat-ui-one-chat-to-rule-them-all", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/apps/liquid-chat-ui/docs/PROJECT_README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A revolutionary liquid motion chat interface powered by IRCP (Inverse Ring Contextual Propagation) that visualizes conversations as dynamic, flowing systems where messages find their natural place in ring topology based on semantic coordinates.", "excerpt": "A revolutionary liquid motion chat interface powered by IRCP (Inverse Ring Contextual Propagation) that visualizes conversations as dynamic, flowing systems where messages find their natural place in ring topology based on semantic coordinates.\n\nThis interface represents a fundamental shift from sequential chat to **liquid, spatial conversation flow** where:\n\n- **Messages flow like liquid** and find their optimal position in the conversation ring - **IRCP coordinates** determine spatial relationships between messages - **Ring topology** maintains contextual connections in a circular structure - **Real-time positioning** as new messages are processed and placed - **One unified interface** for all AI interactions\n\n### **🔄 Liquid Ring Topology** - Messages visualized as nodes in a dynamic ring structure - Real-time coordinate calculation using IRCP DLM system - Liquid motion effects with viscosity, flow, and turbulence - Contextual connections between semantically related messages\n\n### **🧠 IRCP Integration** - **Semantic embeddings** for meaning-based positioning - **5D coordinate system** (x: depth, y: sibling order, z: homogeneity, t: temporal, n: complexity) - **Ring topology** for circular conversation flow - **Inverse attention** for contextual relationships", "htmlHref": "/research/html/liquid-chat-ui-one-chat-to-rule-them-all-i32cvy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 934 }, { "id": "cc-navigator-hierarchical-knowledge-interface-1e1kjz5", "title": "CC Navigator - Hierarchical Knowledge Interface", "slug": "cc-navigator-hierarchical-knowledge-interface", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/cc-navigator/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` ┌─────────────────────────────────────────────────────────────┐ │ CC Navigator (Next.js) │ │ ┌────────────────┐ ┌─────────────────────┐ │ │ │ Tree View │ │ Chat Interface │ │ │ │ - Folders │ │ - GPT-5.1 │ │ │ │ - Topics │◄────────────►│ - Context-aware │ │ │ │ - Breadcrumbs │ │ - Search mode │ │ │ └────────────────┘ └─────────────────────┘ │ │ │ │ │ │ └───────────────┬───────────────────┘ │ └──────────────────────────┼────────────────────────────────-─┘ │ HTTP API ┌──────────────────────────┼───────────────────", "excerpt": "**Interactive Next.js front-end for exploring your Computational Choreography knowledge base.**\n\n### 🌲 Hierarchical Tree View - File system-style organization of your 335 conversations - Auto-organized by topics (LIM-RPS, Echelon, Music Production, etc.) - Expandable/collapsible folders - Click to navigate and set context\n\n### 💬 Context-Aware Chat - Conversations powered by GPT-5.1 - Automatically scoped to your current location in the tree - Breadcrumb navigation shows your current context - Chat responses use knowledge from your selected topic\n\n### 📊 Graph Topology View - D3.js force-directed visualization - Interactive drag-and-drop nodes - Visual representation of knowledge connections - Switch between Tree and Graph views\n\n### 🔍 Intelligent Search - Toggle between Chat and Search modes - Search scoped to current context - Returns Q&A pairs with full context - Powered by your existing cc_ai system", "htmlHref": "/research/html/cc-navigator-hierarchical-knowledge-interface-1e1kjz5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1336 }, { "id": "complete-ircp-implementation-summary-14c2rsn", "title": "✅ Complete IRCP Implementation Summary", "slug": "complete-ircp-implementation-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/COMPLETE_IRCP_IMPLEMENTATION_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "All placeholders have been removed and the complete SentenceTransformer-based IRCP system is ready for local training using `all-MiniLM-L6-v2`.", "excerpt": "All placeholders have been removed and the complete SentenceTransformer-based IRCP system is ready for local training using `all-MiniLM-L6-v2`.\n\n### ✅ **Fixed All Placeholders** 1. **main.py**: Complete `generate_response` method with coordinate-guided response generation 2. **base_models.py**: Complete abstract methods with full implementations 3. **measure_theory.py**: Complete abstract methods with mathematical rigor 4. **All modules**: No remaining `TODO`, `FIXME`, or placeholder implementations\n\n### ✅ **Created Complete SentenceTransformer Model** - **File**: `ircp/models/sentence_transformer_icp.py` - **Features**: - Uses `sentence-transformers/all-MiniLM-L6-v2` as base encoder - Custom IRCP heads for coordinate prediction - Inverse attention mechanism - Ring topology integration - Measure-preserving transformations - Multi-component loss function - Complete response generation\n\n### ✅ **Model Registry Integration** - Automatically registered as `\"sentence_transformer_icp\"` - Accessible through `ModelRegistry.get_model()` - Full compatibility with existing IRCP framework\n\n### ✅ **Complete Training Pipeline** - **File**: `train_sentence_transformer_ircp.py` - **Features**: - Automatic dependency installation - Model validation and testing - Comprehensive configuration - Progress tracking and visualization - Checkpoint management - Evaluation integration", "htmlHref": "/research/html/complete-ircp-implementation-summary-14c2rsn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 752 }, { "id": "icp-implementation-complete-1eiezor", "title": "ICP Implementation Complete ✅", "slug": "icp-implementation-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/docs/IMPLEMENTATION_COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "I have successfully implemented the complete **Inverse Ring Contextual Propagation (ICP)** framework as specified in your theoretical documents. This is a comprehensive, production-ready implementation that transforms your 10,000+ message conversation dataset into a rigorous mathematical framework for learning individual response patterns.", "excerpt": "I have successfully implemented the complete **Inverse Ring Contextual Propagation (ICP)** framework as specified in your theoretical documents. This is a comprehensive, production-ready implementation that transforms your 10,000+ message conversation dataset into a rigorous mathematical framework for learning individual response patterns.\n\n**1. Divergent Language Matrix (DLM) Coordinate System** (`dlm_coordinates.py`) - Complete mathematical implementation from `DLM.md` - 4D coordinate calculation: (x, y, z, t) - **x**: Hierarchical depth in conversation tree - **y**: Sibling order among messages at same level - **z**: Homogeneity based on sibling count and similarity scores - **t**: Temporal coordinate with dynamic decay factors - Dynamic Message Ordering (DMO) system - Validation and error checking\n\n**2. Inverse Ring Contextual Propagation Architecture** (`icp_architecture.py`) - Complete neural architecture implementing `ICP.md` framework - **Measure-Preserving Transform**: φ: U×V → V×U with conservation guarantees - **Ring Topology**: Circular ordering preserving local/global structure - **Inverse Attention Mechanism**: A'(C') for capturing response patterns - **Differential Equation Solver**: Numerical integration of dC'/dt = A'(C')C' - **Conservation Constraints**: Ergodic stability, information preservation, homology\n\n**Comprehensive Data Extraction System** - Processes all 277 conversation folders in your dataset - Extracts conversation trees, coordinates, embeddings, relationships - Parallel processing for efficiency (configurable workers) - Creates training-ready tensors for ICP model - Handles different data formats and missing data gracefully - Generates comprehensive statistics and validation reports\n\n**Data Types Extracted:** - `conversation_tree.json` - Raw conversation structure - `coordinate_tree.json` - DLM coordinates - `main_df.csv` - Processed messages with embeddings - `similarity_df.csv` - Pairwise similarity matrices - `relationship.csv` - Message relationships and metrics - `global_embedding.npy` - High-dimensional embeddings - `combined_tensor.npy` - Combined feature tensors", "htmlHref": "/research/html/icp-implementation-complete-1eiezor.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1087 }, { "id": "enhanced-icp-framework-implementation-summary-h5g1x1", "title": "Enhanced ICP Framework - Implementation Summary", "slug": "enhanced-icp-framework-implementation-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/ENHANCED_ICP_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "All major components of the Enhanced Inverse Ring Contextual Propagation (ICP) Framework have been successfully implemented and tested.", "excerpt": "All major components of the Enhanced Inverse Ring Contextual Propagation (ICP) Framework have been successfully implemented and tested.\n\n✅ **Enhanced ICP Structure** - Restructured with better organization and database integration ✅ **Database Integration** - Integrated conversation database with ICP data extraction ✅ **Enhanced DLM Coordinates** - Improved coordinate calculation with database data ✅ **Upgraded ICP Architecture** - Enhanced neural architecture with latest insights ✅ **Training Pipeline** - Upgraded with database integration ✅ **Evaluation System** - Improved with comprehensive metrics\n\n### Core Components (`/core/`) - **`base_models.py`** - Fundamental data structures and base classes - **`coordinate_system.py`** - Enhanced DLM coordinate calculation system - **`inverse_attention.py`** - Inverse attention mechanisms for learning response patterns - **`measure_theory.py`** - Measure-preserving transformations and conservation constraints - **`ring_topology.py`** - Ring topology structures for conversation modeling\n\n### Data Management (`/data/`) - **`database_loader.py`** - Database integration with conversation data loading - **`conversation_processor.py`** - Conversation data processing utilities - **`data_validators.py`** - Data validation and quality assurance\n\n### Utilities (`/utils/`) - **`config.py`** - Configuration management system - **`logging_utils.py`** - Enhanced logging and monitoring - **`math_utils.py`** - Mathematical utility functions", "htmlHref": "/research/html/enhanced-icp-framework-implementation-summary-h5g1x1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 928 }, { "id": "complete-ircp-implementation-summary-1f32ce6", "title": "✅ Complete IRCP Implementation Summary", "slug": "complete-ircp-implementation-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/outputs/COMPLETE_IRCP_IMPLEMENTATION_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "All placeholders have been removed and the complete SentenceTransformer-based IRCP system is ready for local training using `all-MiniLM-L6-v2`.", "excerpt": "All placeholders have been removed and the complete SentenceTransformer-based IRCP system is ready for local training using `all-MiniLM-L6-v2`.\n\n### ✅ **Fixed All Placeholders** 1. **main.py**: Complete `generate_response` method with coordinate-guided response generation 2. **base_models.py**: Complete abstract methods with full implementations 3. **measure_theory.py**: Complete abstract methods with mathematical rigor 4. **All modules**: No remaining `TODO`, `FIXME`, or placeholder implementations\n\n### ✅ **Created Complete SentenceTransformer Model** - **File**: `ircp/models/sentence_transformer_icp.py` - **Features**: - Uses `sentence-transformers/all-MiniLM-L6-v2` as base encoder - Custom IRCP heads for coordinate prediction - Inverse attention mechanism - Ring topology integration - Measure-preserving transformations - Multi-component loss function - Complete response generation\n\n### ✅ **Model Registry Integration** - Automatically registered as `\"sentence_transformer_icp\"` - Accessible through `ModelRegistry.get_model()` - Full compatibility with existing IRCP framework\n\n### ✅ **Complete Training Pipeline** - **File**: `train_sentence_transformer_ircp.py` - **Features**: - Automatic dependency installation - Model validation and testing - Comprehensive configuration - Progress tracking and visualization - Checkpoint management - Evaluation integration", "htmlHref": "/research/html/complete-ircp-implementation-summary-1f32ce6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 752 }, { "id": "ircp-training-status-277-conversations-1qaau30", "title": "🚀 IRCP Training Status - 277 Conversations", "slug": "ircp-training-status-277-conversations", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/outputs/IRCP_TRAINING_STATUS_277_CONVERSATIONS.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Training Started**: Successfully running with all 277 conversations **Model**: SentenceTransformer + Custom IRCP Heads (`all-MiniLM-L6-v2`) **Status**: ✅ **ACTIVE** - Training in progress", "excerpt": "**Training Started**: Successfully running with all 277 conversations **Model**: SentenceTransformer + Custom IRCP Heads (`all-MiniLM-L6-v2`) **Status**: ✅ **ACTIVE** - Training in progress\n\n### **Loss Progress** - **Initial Train Loss**: 1432.27 - **Current Train Loss**: 1430.46 - **Train Improvement**: 1.80 points - **Validation Loss**: 1985.26 (stable)\n\n### **Learning Rate Schedule** - **Initial LR**: 4.97e-05 - **Current LR**: 0.0 (cosine schedule completed) - **Schedule**: Cosine annealing over 100 epochs\n\n### **Model Checkpoints** - **Checkpoints Saved**: 7 files - **Best Model**: 128.9 MB - **Auto-saving**: Every 10 epochs\n\n### **Base Model** - **Encoder**: `sentence-transformers/all-MiniLM-L6-v2` (FROZEN) - **Embedding Dim**: 384 - **Total Parameters**: ~22.7M - **Trainable Parameters**: ~2.5M (custom heads only)", "htmlHref": "/research/html/ircp-training-status-277-conversations-1qaau30.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 624 }, { "id": "ring-contextual-propagation-rcp-framework-complete-implementation-1v2luo0", "title": "Ring Contextual Propagation (RCP) Framework - Complete Implementation", "slug": "ring-contextual-propagation-rcp-framework-complete-implementation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/RCP_FRAMEWORK_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "All components of the Ring Contextual Propagation (RCP) Framework have been successfully implemented and thoroughly tested.", "excerpt": "All components of the Ring Contextual Propagation (RCP) Framework have been successfully implemented and thoroughly tested.\n\nThe RCP Framework implements a sophisticated system for modeling and propagating contextual information within hierarchical conversation structures:\n\n#### 1. **3D Coordinate System** (`coordinate_system.py`) - **Purpose**: Assigns spatial coordinates (x, y, z) to each message - **Coordinates**: - `x`: Depth level in conversation tree - `y`: Sibling order among messages at same level - `z`: Homogeneity relationships between sibling messages - **Features**: - Multiple homogeneity calculation methods (similarity-based, count-based, hybrid) - Coordinate normalization and validation - Confidence scoring for coordinate quality - Support for embeddings-based similarity computation\n\n#### 2. **Ring Structure** (`ring_structure.py`) - **Purpose**: Organizes messages in circular topology while preserving hierarchical relationships - **Construction Methods**: - Hierarchical preserving (maintains conversation tree structure) - Temporal-based (chronological ordering) - Similarity-based (content similarity clustering) - Hybrid (weighted combination of factors) - **Features**: - Ring connectivity validation - Neighbor traversal and path finding - Ring distance computation - Connection strength analysis\n\n#### 3. **Contextual Attention Mechanism** (`attention_mechanism.py`) - **Purpose**: Computes attention weights based on coordinate distances - **Formula**: `w(mᵢ, mⱼ) = softmax(ψ(cᵢ, cⱼ))` - **Distance Function**: `ψ(cᵢ, cⱼ) = α|xᵢ - xⱼ| + β|yᵢ - yⱼ| + γ|zᵢ - zⱼ|` - **Features**: - Learnable coordinate weights (α, β, γ) - Semantic similarity integration - Temporal decay factors - Multi-scale and adaptive attention variants - Comprehensive attention pattern analysis", "htmlHref": "/research/html/ring-contextual-propagation-rcp-framework-complete-implementation-1v2luo0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1443 }, { "id": "getting-started-build-your-personal-ai-1hxwrta", "title": "Getting Started: Build Your Personal AI", "slug": "getting-started-build-your-personal-ai", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/guides/GETTING_STARTED.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "You have **289 MB of personal data** across 5 files: - conversations.json (190 MB) - conversations_new.json (64 MB) - conversation_openai.json (8 MB) - notes.json (15 MB) - cc_conversations.json (13 MB)", "excerpt": "Quick guide to building your personalized AI inference system with full context memory.\n\nYou have **289 MB of personal data** across 5 files: - conversations.json (190 MB) - conversations_new.json (64 MB) - conversation_openai.json (8 MB) - notes.json (15 MB) - cc_conversations.json (13 MB)\n\nWe'll transform this into a **personal AI** that knows everything about you and your projects.\n\nThat's it! The `embeddinggemma-300m` model will download automatically on first run (~600 MB).\n\n**What it does**: - ✅ Loads all conversations from all sources - ✅ Extracts clean message threads - ✅ Deduplicates content - ✅ Auto-categorizes by topic (CC, music, business, etc.) - ✅ Creates `data/unified_knowledge.json`", "htmlHref": "/research/html/getting-started-build-your-personal-ai-1hxwrta.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1065 }, { "id": "ircp-dlm-integration-plan-1czxyxq", "title": "IRCP-DLM Integration Plan", "slug": "ircp-dlm-integration-plan", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/guides/INTEGRATION_PLAN.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This plan tracks the iterative integration of IRCP, TPO, and DLM packages into a unified, production-grade system. Each task is checkable, and progress is tracked across multiple detailed markdown files.", "excerpt": "**Started:** 2025-12-07 **Status:** 🔵 In Progress **Current Phase:** Week 3 - Training Pipeline Integration\n\nThis plan tracks the iterative integration of IRCP, TPO, and DLM packages into a unified, production-grade system. Each task is checkable, and progress is tracked across multiple detailed markdown files.\n\n**Key Principle:** DLM's coordinate system is the foundation - we enhance and unify, not replace.\n\n### Week 1: Planning & Architecture ✅ - [x] Complete DLM codebase audit - [x] Analyze IRCP package structure - [x] Analyze TPO package structure - [x] Document coordinate system differences - [x] Create integration strategy - [x] Design unified architecture - [x] Refactor dlm/response module with production utilities\n\n**Documents:** - [DLM_CODEBASE_AUDIT.md](DLM_CODEBASE_AUDIT.md) ✅ - [DLM_FUSION_STRATEGY.md](DLM_FUSION_STRATEGY.md) ✅ - [dlm/response/README.md](packages/dlm/response/README.md) ✅", "htmlHref": "/research/html/ircp-dlm-integration-plan-1czxyxq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1483 }, { "id": "ircp-dlmdataloader-integration-quick-reference-1edyrbn", "title": "IRCP & DLMDataLoader Integration - Quick Reference", "slug": "ircp-dlmdataloader-integration-quick-reference", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/guides/IRCP_INTEGRATION_QUICK_REFERENCE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Component | File Path | |-----------|-----------| | **IRCP Trainer** | `packages/ircp/training/icp_trainer.py` | | **IRCP Database Loader** | `packages/ircp/data/database_loader.py` | | **IRCP Base Models** | `packages/ircp/core/base_models.py` | | **DLM Data Loader** | `packages/dlm/core/data_loader.py` | | **TPO Trainer** | `packages/tpo/training/trainer.py` | | **Database Enhanced RCP** | `packages/tpo/consolidation/knowledge_base/database_enhanced_rcp.py` |", "excerpt": "| Component | File Path | |-----------|-----------| | **IRCP Trainer** | `packages/ircp/training/icp_trainer.py` | | **IRCP Database Loader** | `packages/ircp/data/database_loader.py` | | **IRCP Base Models** | `packages/ircp/core/base_models.py` | | **DLM Data Loader** | `packages/dlm/core/data_loader.py` | | **TPO Trainer** | `packages/tpo/training/trainer.py` | | **Database Enhanced RCP** | `packages/tpo/consolidation/knowledge_base/database_enhanced_rcp.py` |\n\n### Coordinates | IRCP DLMCoordinates | DLM DLMCoordinate | Status | |-------|-------|--------| | x | x | Direct | | y | y | Direct | | z | z | Direct | | t | t | Direct | | depth | depth_level | Direct | | sibling_count | n_parts | Semantic map | | is_linear | (missing) | Need default | | confidence | confidence | Direct |\n\n### ConversationNode Both have ConversationNode but: - IRCP uses: `DLMCoordinates` (from ircp/core/base_models.py) - DLM uses: `DLMCoordinate` (from dlm/core/coordinates.py)\n\n1. **Coordinate Prediction Loss** (weight: 1.0) - MSE 2. **Embedding Consistency Loss** (weight: 0.1) - Cosine similarity 3. **Conservation Constraint Loss** (weight: 0.05) - Measure preservation 4. **Topological Consistency Loss** (weight: 0.1) - k-NN preservation 5. **L2 Regularization** (weight: 1e-5) - Parameter regularization\n\n### IRCP Expected Schema - conversations: conversation_id, total_messages - messages: message_id, conversation_id, parent_id, content, author, create_time, token_count - **dlm_coordinates**: message_id, **x_coord, y_coord, z_coord, t_coord**, depth, sibling_order, sibling_count, is_linear - embeddings: message_id, embedding_vector", "htmlHref": "/research/html/ircp-dlmdataloader-integration-quick-reference-1edyrbn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1089 }, { "id": "complete-ircp-implementation-summary-21xb87", "title": "✅ Complete IRCP Implementation Summary", "slug": "complete-ircp-implementation-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/ircp/COMPLETE_IRCP_IMPLEMENTATION_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "All placeholders have been removed and the complete SentenceTransformer-based IRCP system is ready for local training using `all-MiniLM-L6-v2`.", "excerpt": "All placeholders have been removed and the complete SentenceTransformer-based IRCP system is ready for local training using `all-MiniLM-L6-v2`.\n\n### ✅ **Fixed All Placeholders** 1. **main.py**: Complete `generate_response` method with coordinate-guided response generation 2. **base_models.py**: Complete abstract methods with full implementations 3. **measure_theory.py**: Complete abstract methods with mathematical rigor 4. **All modules**: No remaining `TODO`, `FIXME`, or placeholder implementations\n\n### ✅ **Created Complete SentenceTransformer Model** - **File**: `ircp/models/sentence_transformer_icp.py` - **Features**: - Uses `sentence-transformers/all-MiniLM-L6-v2` as base encoder - Custom IRCP heads for coordinate prediction - Inverse attention mechanism - Ring topology integration - Measure-preserving transformations - Multi-component loss function - Complete response generation\n\n### ✅ **Model Registry Integration** - Automatically registered as `\"sentence_transformer_icp\"` - Accessible through `ModelRegistry.get_model()` - Full compatibility with existing IRCP framework\n\n### ✅ **Complete Training Pipeline** - **File**: `train_sentence_transformer_ircp.py` - **Features**: - Automatic dependency installation - Model validation and testing - Comprehensive configuration - Progress tracking and visualization - Checkpoint management - Evaluation integration", "htmlHref": "/research/html/complete-ircp-implementation-summary-21xb87.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 752 }, { "id": "ircp-training-status-277-conversations-1lnmoi1", "title": "🚀 IRCP Training Status - 277 Conversations", "slug": "ircp-training-status-277-conversations", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/ircp/IRCP_TRAINING_STATUS_277_CONVERSATIONS.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Training Started**: Successfully running with all 277 conversations **Model**: SentenceTransformer + Custom IRCP Heads (`all-MiniLM-L6-v2`) **Status**: ✅ **ACTIVE** - Training in progress", "excerpt": "**Training Started**: Successfully running with all 277 conversations **Model**: SentenceTransformer + Custom IRCP Heads (`all-MiniLM-L6-v2`) **Status**: ✅ **ACTIVE** - Training in progress\n\n### **Loss Progress** - **Initial Train Loss**: 1432.27 - **Current Train Loss**: 1430.46 - **Train Improvement**: 1.80 points - **Validation Loss**: 1985.26 (stable)\n\n### **Learning Rate Schedule** - **Initial LR**: 4.97e-05 - **Current LR**: 0.0 (cosine schedule completed) - **Schedule**: Cosine annealing over 100 epochs\n\n### **Model Checkpoints** - **Checkpoints Saved**: 7 files - **Best Model**: 128.9 MB - **Auto-saving**: Every 10 epochs\n\n### **Base Model** - **Encoder**: `sentence-transformers/all-MiniLM-L6-v2` (FROZEN) - **Embedding Dim**: 384 - **Total Parameters**: ~22.7M - **Trainable Parameters**: ~2.5M (custom heads only)", "htmlHref": "/research/html/ircp-training-status-277-conversations-1lnmoi1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 624 }, { "id": "claude-tpo-precomputation-system-complete-implementation-1r46cl8", "title": "Claude TPO Precomputation System - Complete Implementation", "slug": "claude-tpo-precomputation-system-complete-implementation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/outputs/CLAUDE_TPO_PRECOMPUTATION_COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Your Claude conversation data has been successfully precomputed with **IRCP embeddings** and **TPO DLM coordinates**! Here's what was accomplished:", "excerpt": "Your Claude conversation data has been successfully precomputed with **IRCP embeddings** and **TPO DLM coordinates**! Here's what was accomplished:\n\n### **Database Statistics** - **20 conversations** processed successfully - **1,395 messages** with complete data - **1,395 IRCP embeddings** (384-dimensional) - **1,395 DLM coordinates** (5-dimensional: x, y, z, t, n) - **0 errors** - 100% success rate - **Processing time**: 10.05 seconds\n\n### **Coordinate Analysis** - **X (Depth)**: 0.0 → 181.0 (avg: 42.1) - Conversation hierarchy depth - **Y (Sibling Order)**: All 0.0 - Linear conversation structure - **Z (Homogeneity)**: All 0.0 - No sibling semantic variation - **T (Temporal)**: 0.0 → 0.37 (avg: 0.17) - Normalized timestamps - **N (Structural)**: 1 → 195 (avg: 14.6) - Content complexity\n\n### **1. Claude TPO Precomputation System** (`claude_tpo_precomputation.py`) - **Full TPO integration** with spatial modules - **IRCP model loading** and embedding generation - **DLM coordinate computation** using TPO algorithms - **Relationship analysis** and spatial clustering - **Quality metrics** computation - **Comprehensive error handling**\n\n### **2. Simplified Embeddings Precomputer** (`claude_embeddings_precomputer.py`) - **Core functionality** focus - **IRCP embeddings** generation - **DLM coordinates** computation - **Batch processing** optimization - **Database storage** with proper schema", "htmlHref": "/research/html/claude-tpo-precomputation-system-complete-implementation-1r46cl8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 976 }, { "id": "ircp-search-engine-complete-implementation-48mdz5", "title": "IRCP Search Engine - Complete Implementation", "slug": "ircp-search-engine-complete-implementation", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/outputs/IRCP_SEARCH_ENGINE_COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "I've successfully created a comprehensive, robust command-line semantic and topological search engine that works with both your original trained data and Claude conversation data.", "excerpt": "I've successfully created a comprehensive, robust command-line semantic and topological search engine that works with both your original trained data and Claude conversation data.\n\n### **1. Full-Featured Search Engine** (`ircp_search_engine.py`) - **Multi-database support** - Works with multiple database formats - **Semantic search** using IRCP embeddings - **Topological search** using DLM coordinates - **Hybrid search** combining both approaches - **Robust error handling** and database validation - **Content fetching** from original data sources - **Interactive mode** for exploratory search\n\n### **2. Simple Demo Interface** (`ircp_search_demo.py`) - **Easy-to-use demonstration** of search capabilities - **Interactive mode** with simple commands - **Content integration** with original JSON data - **Demo searches** showing different search types\n\n**Features:** - Uses trained IRCP model embeddings - Cosine similarity matching - Configurable similarity thresholds - Cross-database search capability\n\n**Features:** - 3D coordinate-based search (x, y, z) - Euclidean distance calculation - Configurable distance thresholds - Reveals conversation structure patterns", "htmlHref": "/research/html/ircp-search-engine-complete-implementation-48mdz5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1094 }, { "id": "liquid-chat-interface-revolutionary-ai-communication-i04832", "title": "Liquid Chat Interface - Revolutionary AI Communication", "slug": "liquid-chat-interface-revolutionary-ai-communication", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/outputs/LIQUID_CHAT_INTERFACE_COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "I've created a revolutionary liquid motion chat interface that transforms AI communication from sequential text to **spatial, flowing conversation** where messages find their natural place in IRCP ring topology.", "excerpt": "I've created a revolutionary liquid motion chat interface that transforms AI communication from sequential text to **spatial, flowing conversation** where messages find their natural place in IRCP ring topology.\n\n### **🔄 Liquid Motion Paradigm** - **Messages flow like liquid** and self-organize based on IRCP coordinates - **Ring topology visualization** shows conversation structure in real-time - **Spatial relationships** replace linear chat sequences - **Dynamic positioning** as new messages find optimal placement - **Unified interface** for all AI interactions\n\n### **🧠 IRCP Integration** - **5D coordinate system** (depth, sibling order, homogeneity, temporal, complexity) - **Semantic embeddings** determine message positioning - **Ring topology** maintains contextual connections - **Real-time coordinate calculation** for new messages - **Inverse attention** for contextual relationships\n\n### **🌊 Visual Elements** - **Color-coded depth**: 🟢 Shallow (0-5) → 🟡 Medium (6-15) → 🔴 Deep (16+) - **Similarity bars**: Visual progress bars showing semantic strength - **Liquid particles**: Floating elements around active messages - **Ring connections**: Flowing lines between related messages - **Backdrop blur**: Depth and focus effects\n\n### **🎯 Interactive Features** - **Hover effects** with message previews - **Click to select** with detailed coordinate display - **Real-time positioning** as messages are processed - **Liquid input** with smart suggestions - **Voice input** preparation (UI ready)", "htmlHref": "/research/html/liquid-chat-interface-revolutionary-ai-communication-i04832.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1482 }, { "id": "project-cleanup-global-tool-installation-complete-120kv54", "title": "Project Cleanup & Global Tool Installation - Complete", "slug": "project-cleanup-global-tool-installation-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/outputs/PROJECT_CLEANUP_AND_GLOBAL_TOOL_COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "I've successfully cleaned up the root folder and created a globally accessible command-line tool for the IRCP hierarchical semantic search engine.", "excerpt": "I've successfully cleaned up the root folder and created a globally accessible command-line tool for the IRCP hierarchical semantic search engine.\n\n### **🗂️ Files Moved and Organized:** - **7 analysis tools** → `analysis_tools/` - **5 precomputation scripts** → `precomputation_scripts/` - **6 demo scripts** → `demo_scripts/` - **4 main tools** → `tools/` - **2 log files** → `logs/` - **Database files** → `databases/` - **Utility scripts** → `scripts/`\n\n### **🔧 Global Tool Features** - **Works from any directory** in the terminal - **Automatic environment activation** (uses tpo_env) - **Full argument support** with all search options - **Interactive mode** available globally - **Database auto-detection** from project location\n\n### **✅ Database Status** - **853 conversations processed** (96% of 891 total) - **16,858 messages with embeddings and coordinates** - **100% coordinate success rate** - **Two databases available** with full functionality\n\n### **✅ Clean Architecture** - **Organized file structure** with logical groupings - **No loose files** in root directory - **Clear separation** of tools, scripts, and data - **Professional project layout**", "htmlHref": "/research/html/project-cleanup-global-tool-installation-complete-120kv54.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 983 }, { "id": "dlm-performance-improvements-complete-1grndnx", "title": "DLM Performance Improvements - Complete", "slug": "dlm-performance-improvements-complete", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/plans/PERFORMANCE_IMPROVEMENTS_COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Successfully implemented embedding cache optimization with **demonstrated 5x speedup** and **80% reduction in API calls**!", "excerpt": "Successfully implemented embedding cache optimization with **demonstrated 5x speedup** and **80% reduction in API calls**!\n\n**Files Created:** - [packages/dlm/engine/cached_embedder.py](./packages/dlm/engine/cached_embedder.py) - Caching wrapper (275 lines) - [scripts/benchmark_embeddings.py](./scripts/benchmark_embeddings.py) - Performance benchmark (330 lines) - [PERFORMANCE_OPTIMIZATION_PLAN.md](./PERFORMANCE_OPTIMIZATION_PLAN.md) - Comprehensive optimization strategy\n\n**Features:** - LRU caching with configurable size - Thread-safe operations - Cache statistics and monitoring - Batch embedding support - MD5-based cache keys - Cache warming capability\n\n### Test Configuration - **Unique texts**: 100 - **Total texts**: 500 (with realistic repetition) - **Cache size**: 200 - **Simulated API latency**: 50ms\n\n| Metric | Without Cache | With Cache | Improvement | |--------|---------------|------------|-------------| | **Total Time** | 26.75s | 5.38s | **5.0x faster** ⚡ | | **API Calls** | 500 | 100 | **80% reduction** 💰 | | **Throughput** | 18.7 texts/sec | 92.9 texts/sec | **5.0x faster** | | **Cache Hit Rate** | N/A | 80.0% | **Excellent** ✅ |", "htmlHref": "/research/html/dlm-performance-improvements-complete-1grndnx.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1311 }, { "id": "dlm-performance-optimization-plan-1vwf0pp", "title": "DLM Performance Optimization Plan", "slug": "dlm-performance-optimization-plan", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/plans/PERFORMANCE_OPTIMIZATION_PLAN.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. Profile code to identify performance bottlenecks 2. Optimize embedding generation and caching 3. Improve training pipeline efficiency 4. Add intelligent caching mechanisms 5. Reduce memory footprint for large operations", "excerpt": "1. Profile code to identify performance bottlenecks 2. Optimize embedding generation and caching 3. Improve training pipeline efficiency 4. Add intelligent caching mechanisms 5. Reduce memory footprint for large operations\n\n| Component | Issue | Impact | Priority | |-----------|-------|--------|----------| | **Embedding Generation** | Repeated API calls | High latency | 🔴 HIGH | | **Training Pipeline** | No batch processing | Slow training | 🟡 MEDIUM | | **File I/O** | No caching | Repeated reads | 🟡 MEDIUM | | **Conversation Search** | Linear search | Slow with many convos | 🔴 HIGH | | **Model Loading** | Loaded each time | Startup delay | 🟢 LOW |\n\n**Current Issues:** - Multiple API calls for similar content - No caching mechanism - No batch processing support\n\n**Current Issues:** - Sequential epoch processing - No data prefetching - Checkpoint saving blocks training\n\n**Optimization Opportunities:** - Batch data loading - Parallel data processing - Async checkpoint saving - GPU utilization monitoring", "htmlHref": "/research/html/dlm-performance-optimization-plan-1vwf0pp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1496 }, { "id": "phase-2-3-configuration-consolidation-11vhx6h", "title": "Phase 2.3: Configuration Consolidation", "slug": "phase-2-3-configuration-consolidation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/PHASE_2_3_CONFIG.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Successfully consolidated configuration from DLM, IRCP, and TPO: 1. Created unified `DLMConfig` with 13 configuration sections: - TokenConfig, CoordinateConfig, IRCPConfig - EmbeddingConfig, ModelConfig, TrainingConfig - ContextArchivalConfig, ContextReorderingConfig, SynthesisTechniqueConfig - DatabaseConfig, EvaluationConfig, LoggingConfig, ResourceConfig", "excerpt": "# Phase 2.3: Configuration Consolidation **Week:** 2 | **Duration:** 0.5 days | **Status:** ✅ Complete\n\n## Objective Merge `dlm/response/config.py` and `ircp/utils/config.py` into unified `dlm/config.py`\n\n## Tasks - [x] Merge ResponseConfig + IRCP config into DLMConfig - [x] Add training configuration section - [x] Add embedding configuration - [x] Add coordinate calculation config - [x] Support environment variables - [x] Create config presets (dev/prod/performance/quality/coordinate-focus/conservation-focus) - [x] Add validation with dataclasses - [x] Add tests (20+ test cases) - [x] Document configuration options (comprehensive guide)\n\n## Files Created/Modified - Created: `packages/dlm/config.py` (500+ lines) - Created: `packages/dlm/tests/test_config.py` (comprehensive tests) - Created: `packages/dlm/CONFIG_GUIDE.md` (complete documentation) - Modified: `packages/dlm/response/config.py` (deprecation warning)\n\nSuccessfully consolidated configuration from DLM, IRCP, and TPO: 1. Created unified `DLMConfig` with 13 configuration sections: - TokenConfig, CoordinateConfig, IRCPConfig - EmbeddingConfig, ModelConfig, TrainingConfig - ContextArchivalConfig, ContextReorderingConfig, SynthesisTechniqueConfig - DatabaseConfig, EvaluationConfig, LoggingConfig, ResourceConfig", "htmlHref": "/research/html/phase-2-3-configuration-consolidation-11vhx6h.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 370 }, { "id": "phase-2-4-logging-unification-1jic713", "title": "Phase 2.4: Logging Unification", "slug": "phase-2-4-logging-unification", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/PHASE_2_4_LOGGING.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "2. **Performance Monitoring** - `timed_operation()` context manager - `@log_performance` decorator - `@log_context` decorator - `log_section()` helper", "excerpt": "# Phase 2.4: Logging Unification **Week:** 2 | **Duration:** 0.5 days | **Status:** ✅ Complete\n\n## Objective Create unified `dlm/utils/logger.py` from `dlm/response/logging_utils.py` and `ircp/utils/logging_utils.py`\n\n## Tasks - [x] Create `dlm/utils/` directory - [x] Merge logging utilities into `dlm/utils/logger.py` - [x] Enhance ResponseLogger for all DLM modules - [x] Add module-specific loggers - [x] Add performance logging decorators - [x] Add structured logging for training - [x] Add log levels configuration - [x] Replace print() statements throughout codebase - [x] Add tests - [x] Document logging patterns\n\n### Unified Logger Created Created comprehensive `DLMLogger` class consolidating: - **From DLM**: Structured logging with context management - **From IRCP**: File rotation, colored output, experiment tracking - **Enhanced**: Performance monitoring, decorators, global management\n\n### Key Features 1. **Structured Logging** - Context data support (`set_context()`, `context()` manager) - Automatic formatting with key-value pairs - Persistent and temporary context", "htmlHref": "/research/html/phase-2-4-logging-unification-1jic713.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 412 }, { "id": "phase-2-5-testing-validation-14dcpdl", "title": "Phase 2.5: Testing & Validation", "slug": "phase-2-5-testing-validation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/PHASE_2_5_TESTING.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Test Files (6 total, 2,000+ lines):** - `test_integration.py` - 430 lines of comprehensive integration tests - `test_week2_standalone.py` - 370 lines of standalone tests - `test_config.py` - 323 lines (Phase 2.3) - `test_logger.py` - 430 lines (Phase 2.4) - `test_coordinates.py` (Phase 2.1) - `test_embeddings.py` (Phase 2.2)", "excerpt": "# Phase 2.5: Testing & Validation **Week:** 2 | **Duration:** 1 day | **Status:** ✅ Complete (with notes) **Dependencies:** Phases 2.1-2.4 complete\n\n## Objective Comprehensive testing of all Week 2 components and backward compatibility verification\n\n### Unit Tests - [ ] Test DLMCoordinate (phase 2.1) - [ ] Test DLMCoordinateCalculator - [ ] Test DLMCoordinateValidator - [ ] Test IRCPEmbedder (phase 2.2) - [ ] Test IRCP theory modules - [ ] Test DLMConfig (phase 2.3) - [ ] Test unified logger (phase 2.4)\n\n### Integration Tests - [ ] Test coordinates + embeddings integration - [ ] Test config loading across modules - [ ] Test logging across modules - [ ] Test backward compatibility with ChainCoordinate - [ ] Test backward compatibility with old ircp_embedder\n\n### Performance Tests - [ ] Benchmark coordinate calculation speed - [ ] Benchmark embedding cache hit rates - [ ] Measure memory usage with caching - [ ] Profile batch embedding performance", "htmlHref": "/research/html/phase-2-5-testing-validation-14dcpdl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 631 }, { "id": "phase-3-2-ircp-trainer-integration-executive-summary-1cqywk3", "title": "Phase 3.2: IRCP Trainer Integration - Executive Summary", "slug": "phase-3-2-ircp-trainer-integration-executive-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/PHASE_3_2_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A complete **adapter layer** that enables seamless integration between DLM's new data loading system (Phase 3.1) and IRCP's existing training infrastructure.", "excerpt": "A complete **adapter layer** that enables seamless integration between DLM's new data loading system (Phase 3.1) and IRCP's existing training infrastructure.\n\n1. **`CoordinateAdapter`** - Bidirectional DLM ↔ IRCP coordinate conversion 2. **`ConversationGraphAdapter`** - Graph structure conversion 3. **`DataLoaderAdapter`** - IRCP-compatible wrapper for DLMDataLoader 4. **`create_ircp_compatible_loader()`** - Drop-in replacement factory function\n\n**Drop-in Replacement**: Existing IRCP training code works with zero changes using the new adapter.\n\n- Coordinate conversion (DLM → IRCP) - Coordinate conversion (IRCP → DLM) - Roundtrip preservation - Graph structure conversion - Full integration with database - Factory function - Precision < 1e-10 - Metadata preservation\n\n1. **Performance**: Leverages Phase 3.1 improvements (batch loading, caching) 2. **Compatibility**: Existing IRCP code works unchanged 3. **Precision**: < 1e-10 error in coordinate conversion 4. **Simplicity**: Single line of code to switch to new loader", "htmlHref": "/research/html/phase-3-2-ircp-trainer-integration-executive-summary-1cqywk3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 331 }, { "id": "phase-3-3-evaluation-metrics-completion-report-12m43b2", "title": "Phase 3.3: Evaluation & Metrics - Completion Report", "slug": "phase-3-3-evaluation-metrics-completion-report", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/PHASE_3_3_EVALUATION.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Phase 3.3 implements comprehensive evaluation metrics and validation tools for DLM coordinates. This phase provides the infrastructure to measure coordinate quality, validate predictions, and track training progress.", "excerpt": "**Status:** ✅ COMPLETE **Date:** 2025-12-08 **Integration Point:** Week 3, Phase 3.3\n\nPhase 3.3 implements comprehensive evaluation metrics and validation tools for DLM coordinates. This phase provides the infrastructure to measure coordinate quality, validate predictions, and track training progress.\n\n#### 1. **Metrics Module** ([packages/dlm/evaluation/metrics.py](packages/dlm/evaluation/metrics.py)) - 450+ lines\n\n##### `CoordinateMetrics` Comprehensive metrics container for coordinate quality.\n\n**Features:** - ✅ Accuracy metrics (MAE, RMSE, max error) - ✅ Per-dimension errors (x, y, z, t) - ✅ Consistency metrics (depth, sibling, temporal) - ✅ Coverage metrics (coordinates, embeddings) - ✅ Distribution statistics (ranges, means, std) - ✅ Export to dictionary", "htmlHref": "/research/html/phase-3-3-evaluation-metrics-completion-report-12m43b2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1136 }, { "id": "week-2-test-results-vhmq3f", "title": "Week 2 Test Results", "slug": "week-2-test-results", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/WEEK_2_TEST_RESULTS.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2025-12-07 **Status:** ✅ Week 2 Components Verified **Test Scope:** Phases 2.1-2.4 (Coordinates, Embeddings, Config, Logging)", "excerpt": "**Date:** 2025-12-07 **Status:** ✅ Week 2 Components Verified **Test Scope:** Phases 2.1-2.4 (Coordinates, Embeddings, Config, Logging)\n\nWeek 2 components have been successfully implemented and tested. **All Week 2 functionality works correctly.** The logging system (Phase 2.4) passed all tests with 100% success rate. Config, coordinates, and embeddings tests encountered pre-existing Pydantic v2 compatibility issues in the DLM codebase (unrelated to Week 2 work).\n\n| Component | Tests Run | Passed | Failed | Success Rate | Notes | |-----------|-----------|--------|--------|--------------|-------| | Logger System | 3 | 3 | 0 | **100%** | ✅ Perfect | | Config System | 2 | 0 | 2 | N/A | Blocked by Pydantic | | Coordinates | 1 | 0 | 1 | N/A | Blocked by Pydantic | | Embeddings | 2 | 0 | 2 | N/A | Blocked by Pydantic | | Integration | 4 | 0 | 4 | N/A | Blocked by Pydantic |\n\n**Key Finding:** Logger system (Phase 2.4) is production-ready. Other components are functionally complete but cannot be fully tested due to pre-existing Pydantic v2 compatibility issue in `dlm/models/generation.py` (line 54).\n\n**Test: Logger System** - ✅ DLMLogger creation - ✅ LogLevel enum functionality - ✅ Verbose mode toggling - ✅ get_logger() returns same instance - ✅ setup_logging() works correctly", "htmlHref": "/research/html/week-2-test-results-vhmq3f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1409 }, { "id": "week-3-training-pipeline-integration-progress-summary-10zu92f", "title": "Week 3: Training Pipeline Integration - Progress Summary", "slug": "week-3-training-pipeline-integration-progress-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/WEEK_3_PROGRESS_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Week 3 focuses on integrating the training pipeline components, building on Week 2's core modules (DLMConfig, DLMCoordinate, Logging). The goal is to create a complete training pipeline that uses unified data loading, IRCP training, evaluation metrics, and coordinate explainability.", "excerpt": "Week 3 focuses on integrating the training pipeline components, building on Week 2's core modules (DLMConfig, DLMCoordinate, Logging). The goal is to create a complete training pipeline that uses unified data loading, IRCP training, evaluation metrics, and coordinate explainability.\n\n**Key Deliverables:** - [packages/dlm/core/data_loader.py](packages/dlm/core/data_loader.py) - 560+ lines - `DLMDataLoader` - Main loader class - `ConversationNode` - Message representation with coordinates/embeddings - `ConversationGraph` - Tree structure with traversal methods\n\n**Features:** - ✅ Batch loading (coordinates and embeddings) - ✅ Caching system for performance - ✅ IRCP database schema compatibility - ✅ Integration with DLMConfig and DLMCoordinate - ✅ Context manager support - ✅ Tree traversal (get_children, get_ancestors, get_depth)\n\n**Testing:** - 10/10 tests passing - Comprehensive test coverage in [packages/dlm/tests/verify_week3_phase1.py](packages/dlm/tests/verify_week3_phase1.py)\n\n**Documentation:** - [PHASE_3_1_DATA_LOADING.md](PHASE_3_1_DATA_LOADING.md) - Complete tracking document", "htmlHref": "/research/html/week-3-training-pipeline-integration-progress-summary-10zu92f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1424 }, { "id": "pydantic-v2-migration-complete-1t2wgiu", "title": "Pydantic v2 Migration - COMPLETE ✅", "slug": "pydantic-v2-migration-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/refactoring/PYDANTIC_V2_COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "2. **[core/coordinates.py](core/coordinates.py:18)** - Updated: `@validator` → `@field_validator` (2 validators) - Added `@classmethod` decorators", "excerpt": "**Status**: ✅ **COMPLETE** - All modules successfully migrated to Pydantic v2.11.5\n\nThe DLM package now fully supports Pydantic v2 with all imports working correctly and all tests passing (16/16).\n\n### Migration Statistics - **Files Fixed**: 9 core files - **Validators Updated**: 7 instances - **Field Annotations Added**: 12 instances - **Import Errors Resolved**: 2 instances - **Test Success Rate**: 100% (16/16 tests passing)\n\n#### Core Pydantic v2 Fixes 1. **[models/generation.py](models/generation.py:3)** - Updated: `@root_validator` → `@model_validator(mode='after')` - Fixed: `text = \"\"` → `text: str = \"\"`\n\n2. **[core/coordinates.py](core/coordinates.py:18)** - Updated: `@validator` → `@field_validator` (2 validators) - Added `@classmethod` decorators", "htmlHref": "/research/html/pydantic-v2-migration-complete-1t2wgiu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 957 }, { "id": "dlm-refactoring-phase-1-complete-1buzltk", "title": "DLM Refactoring - Phase 1 Complete", "slug": "dlm-refactoring-phase-1-complete", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/refactoring/REFACTORING_PHASE1_COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Phase 1 of the DLM refactoring has been completed successfully. The critical Pydantic v2 compatibility issues have been resolved for all Week 2-3 modules, and a comprehensive audit has identified the remaining work.", "excerpt": "Phase 1 of the DLM refactoring has been completed successfully. The critical Pydantic v2 compatibility issues have been resolved for all Week 2-3 modules, and a comprehensive audit has identified the remaining work.\n\n### 1. Comprehensive Package Audit - **File Analysis**: Analyzed all 154 Python files (63,339 lines) - **Directory Structure**: Mapped 22 directories - **Size Analysis**: Identified 10 files exceeding 1000 lines - **Dependency Mapping**: Documented consolidation opportunities - **Output**: [DLM_REFACTORING_AUDIT.md](DLM_REFACTORING_AUDIT.md)\n\n### 2. Pydantic v2 Migration (Week 2-3 Modules) Successfully migrated core modules to Pydantic v2.11.5:\n\n#### Validator Updates - ✅ **models/generation.py**: 1 @root_validator → @model_validator - ✅ **core/coordinates.py**: 2 @validator → @field_validator - ✅ **base.py**: 1 @validator → @field_validator, 3 ClassVar annotations - ✅ **inference/artificial.py**: 3 @root_validator → @model_validator\n\n#### Field Annotation Fixes - ✅ Fixed unannotated field overrides - ✅ Added ClassVar annotations for class constants - ✅ Updated import statements", "htmlHref": "/research/html/dlm-refactoring-phase-1-complete-1buzltk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 826 }, { "id": "dlm-package-reorganization-complete-summary-1czg3fn", "title": "DLM Package Reorganization - Complete Summary", "slug": "dlm-package-reorganization-complete-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/refactoring/REORGANIZATION_COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Successfully reorganized the DLM package with improved structure, cleaner imports, and logical subfolder organization while maintaining 100% backward compatibility and all functionality intact.", "excerpt": "Successfully reorganized the DLM package with improved structure, cleaner imports, and logical subfolder organization while maintaining 100% backward compatibility and all functionality intact.\n\n**Before**: `from dlm.inference.file_manager import Element` **After**: `from dlm.inference.utils import Element`\n\n**Exports**: `PromptManager`, `SYSTEM_PROMPT`, `SYSTEM_PROMPT_00`-`SYSTEM_PROMPT_17`\n\n**Before**: `from dlm.inference.prompt_manager import PromptManager` **After**: `from dlm.inference.prompts import PromptManager`\n\n**Before**: `from dlm.inference.conversation_manager import ChainManager` **After**: `from dlm.inference.management import ChainManager`", "htmlHref": "/research/html/dlm-package-reorganization-complete-summary-1czg3fn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1178 }, { "id": "dlm-package-reorganization-plan-1qa3h4f", "title": "DLM Package Reorganization Plan", "slug": "dlm-package-reorganization-plan", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/refactoring/REORGANIZATION_PLAN.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Split Plan:** 1. **base.py** (~200 lines) - Base classes and utilities 2. **chat_model.py** (~800 lines) - BaseChatModel, ChatArtificial 3. **ai_interface.py** (~1,200 lines) - AI class with main interface 4. **completion.py** (~600 lines) - Completion logic 5. **streaming.py** (~400 lines) - Streaming functionality 6. **embeddings.py** (~400 lines) - Embedding cache and utilities", "excerpt": "**Goal**: Improve code organization while maintaining all functionality for the conversation/chatbot system.\n\n**Approach**: Create logical subfolders, split mega files, consolidate duplicates.\n\n### Large Files Requiring Split 1. **inference/artificial.py** - 3,692 lines (AI chatbot core) 2. **inference/prompt.py** - 2,153 lines (prompt templates) 3. **response/links.py** - 2,084 lines (link handling) 4. **response/motion.py** - 1,783 lines (motion techniques) 5. **response/system.py** - 1,521 lines (response system) 6. **engine/embedder.py** - 1,543 lines (duplicate - to deprecate)\n\n### Module Count - **inference/**: 12 files (10,620 lines total) - **response/**: 71 files (organized but needs subfolder cleanup) - **engine/**: 20 files (some duplicates)\n\n### Migration Steps 1. Create new subfolder structure 2. Split artificial.py (3,692 lines) into 6 focused modules 3. Split generator.py (1,433 lines) into 3 modules 4. Split prompt.py (2,153 lines) into 3 modules 5. Move files to appropriate subfolders 6. Update all imports 7. Test thoroughly", "htmlHref": "/research/html/dlm-package-reorganization-plan-1qa3h4f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1165 }, { "id": "dlm-reorganization-progress-status-poubxs", "title": "DLM Reorganization - Progress Status", "slug": "dlm-reorganization-progress-status", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/refactoring/REORGANIZATION_STATUS.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` packages/dlm/ ├── response/ │ ├── techniques/ ✅ RENAMED (was vangaurd/) │ │ ├── fitness/ │ │ ├── synth/ │ │ └── word_weaver/ │ ├── system.py │ ├── links.py │ ├── cohort.py │ └── ... (other files) │ ├── inference/ │ ├── utils/ ✅ NEW SUBFOLDER │ │ ├── __init__.py │ │ └── file.py (Element, SimpleDirectoryReader, generate_id) │ ├── prompts/ ✅ NEW SUBFOLDER │ │ ├── __init__.py │ │ ├── manager.py (PromptManager) │ │ └── templates.py (SYSTEM_PROMPT_* constants) │ ├── management/ ✅ NEW SUBFOLDER │ │ ├── __init__.py │ │", "excerpt": "### Phase 1: Response Module - Step 1.1 ✅ **Date**: 2025-12-08 **Action**: Renamed `vangaurd/` → `techniques/`\n\n#### Changes Made: 1. ✅ Renamed directory: `response/vangaurd/` → `response/techniques/` 2. ✅ Updated `response/__init__.py`: Changed import from `.vangaurd` to `.techniques` 3. ✅ Updated `response/cohort.py`: Changed all references from `vangaurd` to `techniques`\n\n#### Files Modified: - `packages/dlm/response/` - directory renamed - `packages/dlm/response/__init__.py` - import updated - `packages/dlm/response/cohort.py` - all references updated\n\n### Phase 2: Inference Module - Step 2.1 ✅ **Date**: 2025-12-08 **Action**: Created `inference/utils/` subfolder for file operations\n\n#### Changes Made: 1. ✅ Created directory: `inference/utils/` 2. ✅ Moved `file_manager.py` → `utils/file.py` 3. ✅ Created `utils/__init__.py` with exports for Element, SimpleDirectoryReader, generate_id 4. ✅ Kept `cloud_manager.py` at root level (depends on PromptManager, not a true util) 5. ✅ Updated all imports across 6 files: - `inference/__init__.py` - `inference/generator.py` - `inference/manager.py` - `inference/conversation_manager.py` - `inference/prompt_manager.py` - `engine/builder.py`", "htmlHref": "/research/html/dlm-reorganization-progress-status-poubxs.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1239 }, { "id": "root-folder-reorganization-plan-94znri", "title": "Root Folder Reorganization Plan", "slug": "root-folder-reorganization-plan", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/refactoring/ROOT_REORGANIZATION_PLAN.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` cc-tpo/ ├── README.md # Main README (keep) ├── START_HERE.md # Getting started guide (keep) ├── .env # Environment config (keep) ├── package.json # Node config (keep) ├── requirements-ircp.txt # Python deps (keep) │ ├── docs/ # All documentation │ ├── guides/ # User guides │ │ ├── GETTING_STARTED.md │ │ ├── INTEGRATION_PLAN.md │ │ └── ... │ ├── architecture/ # Architecture docs │ │ ├── DLM_INTEGRATION_PIPELINE.md │ │ ├── DLM_FUSION_STRATEGY.md │ │ └── ... │ ├── progress/ # Progress summaries │ │ ├── WEEK_2_PROG", "excerpt": "## Current Issues - 40+ markdown files in root directory - Loose Python scripts (cc_ai.py, man.py, verify_imports.py) - Notebook file (main.ipynb) in root - Documentation scattered across root\n\n### Keep in Root: - README.md - START_HERE.md - .env - package.json, package-lock.json - requirements-ircp.txt\n\n### Move to docs/guides/: - GETTING_STARTED.md - INTEGRATION_PLAN.md - IRCP_INTEGRATION_QUICK_REFERENCE.md - DLM_INTEGRATION_QUICK_REFERENCE.md\n\n### Move to docs/architecture/: - DLM_INTEGRATION_PIPELINE.md - DLM_FUSION_STRATEGY.md - DLM_CODEBASE_AUDIT.md - PERSONALIZED_AI_SYSTEM_ARCHITECTURE.md - CC_AI_PIPELINE_COMPLETE.md\n\n### Move to docs/progress/: - WEEK_2_PROGRESS_SUMMARY.md - WEEK_2_TEST_RESULTS.md - WEEK_3_PROGRESS_SUMMARY.md - PHASE_2_1_COORDINATES.md - PHASE_2_2_EMBEDDINGS.md - PHASE_2_3_CONFIG.md - PHASE_2_4_LOGGING.md - PHASE_2_5_TESTING.md - PHASE_3_1_DATA_LOADING.md - PHASE_3_2_IRCP_INTEGRATION.md - PHASE_3_2_SUMMARY.md - PHASE_3_3_EVALUATION.md - PHASE_3_4_PIPELINE.md - PHASE_3_4_SUMMARY.md", "htmlHref": "/research/html/root-folder-reorganization-plan-94znri.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 406 }, { "id": "7-conclusion-and-future-work-1lxyrzr", "title": "7. Conclusion and Future Work", "slug": "7-conclusion-and-future-work", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/research/07_conclusion.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This paper presents Inverse Ring Contextual Propagation (IRCP), a novel mathematical framework that fundamentally shifts the paradigm of conversational AI from generic response generation to individual pattern learning. Our key contributions include:", "excerpt": "This paper presents Inverse Ring Contextual Propagation (IRCP), a novel mathematical framework that fundamentally shifts the paradigm of conversational AI from generic response generation to individual pattern learning. Our key contributions include:\n\n1. **Inverse Learning Paradigm**: First rigorous mathematical framework for P(u|v) learning in conversational systems 2. **Measure-Theoretic Foundation**: Complete mathematical foundation with conservation guarantees and convergence proofs 3. **Ring Topology Integration**: Novel topological approach to conversation structure preservation 4. **Conservation Law Framework**: Four fundamental conservation laws ensuring mathematical rigor\n\n1. **Individual Pattern Recognition**: Demonstrated ability to learn person-specific conversation patterns 2. **4D Coordinate System**: Interpretable mapping of conversations to mathematical space 3. **Real-Time Implementation**: Efficient neural architecture suitable for production deployment 4. **Experimental Validation**: Comprehensive validation on 277 conversations with 60,534 messages\n\n**Convergence Theorem**: Proved that IRCP converges to unique individual patterns under conservation constraints **Measure Preservation**: Demonstrated that conversation transformations can maintain mathematical properties **Ergodic Stability**: Showed that learned patterns remain stable over time **Topological Invariance**: Proved that conversation structure is preserved through transformations\n\nThe inverse learning approach represents a fundamental shift from: - **Generic → Individual**: Learning person-specific rather than universal patterns - **Response Generation → Pattern Understanding**: Understanding rather than mimicking - **Heuristic → Mathematical**: Rigorous mathematical foundation rather than empirical approaches - **Static → Dynamic**: Continuous adaptation through differential equations", "htmlHref": "/research/html/7-conclusion-and-future-work-1lxyrzr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1032 }, { "id": "ircp-research-paper-cxzh6s", "title": "IRCP Research Paper", "slug": "ircp-research-paper", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/research/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. **[Title Page](00_title_page.md)** - Title, authors, abstract, keywords 2. **[Introduction](01_introduction.md)** - Motivation, paradigm shift, contributions 3. **[Mathematical Framework](02_mathematical_framework.md)** - Theoretical foundation, proofs 4. **[Algorithm Implementation](03_algorithm_implementation.md)** - Neural architecture, training 5. **[Experimental Setup](04_experimental_setup.md)** - Dataset, configuration, methodology 6. **[Results and Analysis](05_results_analysis.md)** - Performance metric", "excerpt": "## Inverse Ring Contextual Propagation: A Mathematical Framework for Learning Individual Response Patterns in Conversational Dynamics\n\n1. **[Title Page](00_title_page.md)** - Title, authors, abstract, keywords 2. **[Introduction](01_introduction.md)** - Motivation, paradigm shift, contributions 3. **[Mathematical Framework](02_mathematical_framework.md)** - Theoretical foundation, proofs 4. **[Algorithm Implementation](03_algorithm_implementation.md)** - Neural architecture, training 5. **[Experimental Setup](04_experimental_setup.md)** - Dataset, configuration, methodology 6. **[Results and Analysis](05_results_analysis.md)** - Performance metrics, validation 7. **[Applications](06_applications.md)** - Use cases, practical implementations 8. **[Conclusion](07_conclusion.md)** - Summary, future work, implications\n\n- **Inverse Learning Paradigm**: P(u|v) instead of P(v|u) - **Measure-Theoretic Foundation**: Mathematical rigor with conservation laws - **Individual Pattern Modeling**: Person-specific conversation dynamics - **Ring Topology Integration**: Structural conversation preservation - **Experimental Validation**: Real data with 277 conversations, 60,534 messages\n\n- **Conservation Laws**: Measure, information, energy, ergodic stability - **Ring Topology**: Circular conversation ordering with homology preservation - **Inverse Attention**: A'(C') mechanism with differential equation dynamics - **Coordinate System**: 4D mapping (x,y,z,t) of conversation space\n\n- **Individual Pattern Recognition**: 82.3% consistency - **Coordinate Prediction**: R² = 0.889 - **Conservation Satisfaction**: > 0.87 across all measures - **Training Convergence**: Stable learning on 46,025 samples", "htmlHref": "/research/html/ircp-research-paper-cxzh6s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 237 }, { "id": "dlm-refactoring-complete-success-q3hmgk", "title": "DLM Refactoring - Complete Success ✅", "slug": "dlm-refactoring-complete-success", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/summaries/FINAL_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Successfully completed comprehensive Pydantic v2 migration and prepared detailed reorganization plan for the DLM package. All critical systems (AI chatbot, response system, inference, engine) are now fully functional with Pydantic v2.11.5.", "excerpt": "Successfully completed comprehensive Pydantic v2 migration and prepared detailed reorganization plan for the DLM package. All critical systems (AI chatbot, response system, inference, engine) are now fully functional with Pydantic v2.11.5.\n\n**Objective**: Migrate entire DLM package from Pydantic v1 to v2 **Result**: 100% SUCCESS\n\n#### Statistics - **Files Fixed**: 9 core files - **Validators Updated**: 7 instances (`@root_validator` → `@model_validator`) - **Field Annotations Added**: 12 instances - **Import Errors Resolved**: 2 instances - **Test Success Rate**: 100% (16/16 tests passing)\n\n#### Key Achievements ✅ **Full Package Imports** - `import dlm` works flawlessly ✅ **AI Chatbot System** - inference/artificial.py fully functional ✅ **Response System** - All conversation/response features working ✅ **Engine Modules** - Embedding, filtering, matching all operational ✅ **Training Pipeline** - 6/6 tests passing ✅ **Explainability** - 10/10 tests passing\n\n**Objective**: Analyze entire codebase and create reorganization plan **Result**: COMPLETE", "htmlHref": "/research/html/dlm-refactoring-complete-success-q3hmgk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1492 }, { "id": "dlm-package-improvements-summary-1srfyxv", "title": "DLM Package Improvements - Summary", "slug": "dlm-package-improvements-summary", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/summaries/IMPROVEMENTS_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Metric | Before | After | Improvement | |--------|--------|-------|-------------| | **Module Organization** | Flat | Hierarchical | +100% | | **Test Pass Rate** | 100% | 100% | Maintained | | **Documentation Coverage** | ~10% | ~30% | +200% | | **Import Clarity** | Mixed | Clean | +100% | | **Circular Imports** | 0 | 0 | Maintained |", "excerpt": "### 1. Code Reorganization (COMPLETE) - ✅ Renamed `response/vangaurd/` → `response/techniques/` - ✅ Created `inference/utils/` for file operations - ✅ Created `inference/prompts/` for prompt management - ✅ Created `inference/management/` for conversation management - ✅ Created `inference/generation/` for content generation - ✅ Updated 25+ import statements across codebase - ✅ All tests passing (16/16 = 100%)\n\n### 2. Documentation Improvements (IN PROGRESS) - ✅ Created [DOCUMENTATION_PLAN.md](./DOCUMENTATION_PLAN.md) with comprehensive strategy - ✅ Added 70-line module docstring to [inference/artificial.py](./packages/dlm/inference/artificial.py:1) - ✅ Created [inference/README.md](./packages/dlm/inference/README.md) with usage examples - ✅ Created [REORGANIZATION_COMPLETE.md](./REORGANIZATION_COMPLETE.md) summary - ✅ Created [REORGANIZATION_STATUS.md](./REORGANIZATION_STATUS.md) detailed progress\n\n### Structure Quality | Aspect | Status | Notes | |--------|--------|-------| | **Organization** | ✅ Excellent | Logical subfolder structure | | **Test Coverage** | ✅ 100% | 16/16 tests passing | | **Documentation** | 🟡 Good | Module docs added, more needed | | **Type Hints** | 🟡 Partial | ~40% coverage | | **Code Quality** | ✅ Good | No linting tools ran yet |\n\n### Documentation Status | Component | Module Docstring | README | Status | |-----------|------------------|--------|--------| | `inference/` | ✅ Added | ✅ Created | Complete | | `response/` | ⏳ Pending | ✅ Exists | Partial | | `pipeline/` | ⏳ Pending | ⏳ Needed | Pending | | `explainability/` | ⏳ Pending | ⏳ Needed | Pending | | `core/` | ⏳ Pending | ⏳ Needed | Pending |\n\n#### 1. Complete Documentation (2-3 hours) - Add module docstrings to remaining large files: - `response/system.py` (1,520 lines) - `response/links.py` (2,083 lines) - `pipeline/training_pipeline.py` - `explainability/analyzer.py`", "htmlHref": "/research/html/dlm-package-improvements-summary-1srfyxv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 961 }, { "id": "cc-ai-intelligent-search-improvements-summary-1szwgo2", "title": "CC AI Intelligent Search - Improvements Summary", "slug": "cc-ai-intelligent-search-improvements-summary", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/IMPROVEMENTS_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Issue**: User questions were being returned instead of assistant answers. When you ask a question, you want **answers**, not more questions.", "excerpt": "**Issue**: User questions were being returned instead of assistant answers. When you ask a question, you want **answers**, not more questions.\n\n**Result**: Assistant responses get 20% boost, user questions get 30% reduction. This ensures answers appear first.\n\n**Result**: Each result includes both question and answer for complete understanding.\n\n**Purpose**: Primary search method combining intelligent scoring + context retrieval\n\n**Result**: Returns 5 results with full Q&A context, prioritizing actual answers.", "htmlHref": "/research/html/cc-ai-intelligent-search-improvements-summary-1szwgo2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1300 }, { "id": "cc-navigator-quick-start-guide-146ovy1", "title": "CC Navigator - Quick Start Guide", "slug": "cc-navigator-quick-start-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/NAVIGATOR_QUICKSTART.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A dual-pane interface where: - **Left**: File system-style tree of your 335 conversations - **Right**: Context-aware chat powered by GPT-5.1", "excerpt": "A dual-pane interface where: - **Left**: File system-style tree of your 335 conversations - **Right**: Context-aware chat powered by GPT-5.1\n\nYour CC AI system is already set up with: - ✅ 335 conversations unified - ✅ 11,230 embeddings generated - ✅ cc_ai.py and cc_chat.py working\n\nIf disk space is still an issue, you can: - Free up space first - Or run on a different machine with the code\n\n1. Left sidebar shows your knowledge organized by topics 2. Click folders to expand (computational_choreography, music_production, etc.) 3. Click a conversation to set context 4. Watch breadcrumbs update: `Root > LIM-RPS > Core Architecture`\n\n1. Navigate to: `Computational Choreography > LIM-RPS` 2. In chat: \"How does this work?\" 3. GPT-5.1 knows you're asking about LIM-RPS specifically 4. Get answers from YOUR 335 conversations + GPT-5.1 reasoning", "htmlHref": "/research/html/cc-navigator-quick-start-guide-146ovy1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1189 }, { "id": "dlm-configuration-guide-17s5p9f", "title": "DLM Configuration Guide", "slug": "dlm-configuration-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/dlm/CONFIG_GUIDE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "```python config.tokens.total_max_tokens = 16000 # Total token budget config.tokens.max_tokens_per_text = 8192 # Per-text limit config.tokens.truncation_buffer = 100 # Safety buffer ```", "excerpt": "# Or use a preset config = DLMConfig.create_production() config = DLMConfig.create_development() config = DLMConfig.create_performance_optimized() config = DLMConfig.create_quality_optimized() python config.tokens.total_max_tokens = 16000 # Total token budget config.tokens.max_tokens_per_text = 8192 # Per-text limit config.tokens.truncation_buffer = 100 # Safety buffer python # Normalization config.coordinates.normalize_coordinates = True config.coordinates.x_bounds = (0.0, 1.0) config.coordinates.y_bounds = (0.0, 1.0) config.coordinates.z_bounds = (0.0, 1.0)\n\n# Homogeneity calculation config.coordinates.homogeneity_method = \"similarity_based\" # or \"variance_based\" config.coordinates.homogeneity_threshold = 0.5\n\n# Weighting factors config.coordinates.embedding_weight = 0.3 config.coordinates.temporal_weight = 0.2 config.coordinates.structural_weight = 0.5\n\n# Performance config.coordinates.use_cache = True config.coordinates.batch_size = 32 python # Forward ring config.ircp.alpha = 1.0 config.ircp.beta = 1.0 config.ircp.gamma = 1.0\n\n# Inverse ring config.ircp.alpha_prime = 1.0 config.ircp.beta_prime = 1.0 config.ircp.gamma_prime = 1.0", "htmlHref": "/research/html/dlm-configuration-guide-17s5p9f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1206 }, { "id": "engine-module-refactoring-summary-1kau0b0", "title": "Engine Module Refactoring Summary", "slug": "engine-module-refactoring-summary", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/dlm/engine/REFACTORING_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**New Structure**: ``` core/ ├── __init__.py # Exports ├── similarity.py # Unified similarity calculations ├── validators.py # Unified validation logic ├── dataframe_ops.py # Unified DataFrame operations ├── embedding_utils.py # Unified embedding utilities └── filters.py # Unified filter system ```", "excerpt": "## Overview Comprehensive refactoring of the `dlm/engine` module to eliminate redundancy, improve modularity, and enhance maintainability. Created unified core components that all engine implementations can use.\n\n**Benefits**: - Single source of truth for common operations - Reduced code duplication by ~50% - Consistent behavior across all engine components - Easier to optimize and maintain\n\n**Before**: Similarity calculation code duplicated in: - `engine.py` - `calculate_similarity()`, `calculate_cross_entropy_loss()` - `embedder.py` - `calculate_scores()` - `retriever.py` - Similar patterns\n\n**After**: Single `SimilarityUtils` class with: - `calculate_similarity()` - Unified cosine similarity - `cosine_similarity_batch()` - Vectorized batch operations - `calculate_scores()` - Query-corpus similarity - `compute_cross_entropy_loss()` - Cross-entropy loss\n\n**Before**: Validation code scattered across: - `retriever.py` - `_validate_data()`, `_validate_columns()`, `_validate_pair_type()` - `loader.py` - Data source validation - Multiple files - Index range validation", "htmlHref": "/research/html/engine-module-refactoring-summary-1kau0b0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 934 }, { "id": "dlm-rcp-integration-194t013", "title": "DLM-RCP Integration", "slug": "dlm-rcp-integration", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/dlm/integration/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Cross-Conversation Understanding**: Query across all 277 conversations simultaneously - **Unified Knowledge Base**: Treat all conversations as one interconnected system - **Dynamic Context Assembly**: Automatically find and assemble relevant messages - **Knowledge Evolution**: Track knowledge building without regression - **High Performance**: Built-in caching and optimization", "excerpt": "This module provides integration between the Dynamic Language Model (DLM) and Ring Contextual Propagation (RCP) systems.\n\nThe RCP Bridge enables DLM to leverage RCP's cross-conversation understanding capabilities:\n\n- **Cross-Conversation Understanding**: Query across all 277 conversations simultaneously - **Unified Knowledge Base**: Treat all conversations as one interconnected system - **Dynamic Context Assembly**: Automatically find and assemble relevant messages - **Knowledge Evolution**: Track knowledge building without regression - **High Performance**: Built-in caching and optimization\n\n- `initialize(verbose=True)` - Initialize RCP system (loads all conversations) - `query_with_rcp(query, max_context_messages=50, use_cache=True)` - Query with cross-conversation understanding - `expand_context(response_id, additional_messages=20)` - Expand previous response with more messages - `get_conversation_context(conversation_id, include_cross_conversation=True)` - Get conversation context - `find_similar_messages(message_id, max_similar=20)` - Find similar messages across conversations - `get_system_status()` - Get system status and statistics - `clear_cache()` - Clear query cache - `export_knowledge_state(output_path)` - Export knowledge state for backup\n\n- `query` (str) - Original query - `response_id` (str) - Unique response identifier - `assembled_context` (str) - Assembled text context from relevant messages - `raw_context` (DynamicContext) - Full RCP context object - `confidence` (float) - Response confidence score [0, 1] - `source_conversations` (List[str]) - IDs of source conversations - `knowledge_clusters` (List[int]) - Knowledge clusters used - `message_count` (int) - Number of messages in context - `temporal_span` (Tuple[float, float]) - Time range of messages - `knowledge_state_id` (str) - Current knowledge state ID - `knowledge_gain` (Optional[float]) - Knowledge gain from query - `is_expandable` (bool) - Whether context can be expanded - `processing_time` (float) - Query processing time in seconds - `timestamp` (float) - Result timestamp", "htmlHref": "/research/html/dlm-rcp-integration-194t013.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 929 }, { "id": "response-module-refactoring-summary-1nca3jb", "title": "Response Module Refactoring Summary", "slug": "response-module-refactoring-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/dlm/response/REFACTORING_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The `@packages/dlm/response/` module has been enhanced and refactored to improve performance, maintainability, type safety, and developer experience while maintaining full backward compatibility.", "excerpt": "The `@packages/dlm/response/` module has been enhanced and refactored to improve performance, maintainability, type safety, and developer experience while maintaining full backward compatibility.\n\n#### 1. **config.py** - Centralized Configuration Management - `ResponseConfig`: Main configuration container - `TokenConfig`: Token limit settings - `IRCPConfig`: I-RCP propagation parameters - `ContextArchivalConfig`: Context archival settings - `ContextReorderingConfig`: Context reordering options - `SynthesisTechniqueConfig`: Synthesis technique parameters - **Presets**: `create_default()`, `create_performance_optimized()`, `create_quality_optimized()`\n\n#### 2. **validators.py** - Comprehensive Input Validation - `ValidationError`: Custom exception with detailed messages - `ContentValidator`: Validates Content objects and text - `CoordinateValidator`: Validates ChainCoordinate objects - `ChainTypeValidator`: Validates chain types (system/assistant/user) - `ConversationDataValidator`: Validates conversation data structures - `ParameterValidator`: Validates numeric and enum parameters - `EmbeddingValidator`: Validates embeddings and similarity scores\n\n#### 3. **utils.py** - Performance Utilities - `LRUCache[K, V]`: Generic LRU cache with TTL support - `EmbeddingCache`: Specialized cache for text embeddings with MD5 hashing - `BatchProcessor`: Batch processing utility for operations - `AttentionWeightCache`: Specialized cache for I-RCP attention weights - `cosine_similarity_batch()`: Vectorized similarity computation - `normalize_coordinates()`: Coordinate normalization - `compute_coordinate_distance()`: Distance computation - `memoize_with_ttl()`: Function memoization decorator\n\n#### 4. **embedding_provider.py** - Enhanced Embedding Interface - `EmbeddingProviderProtocol`: Protocol for embedding providers - `BaseEmbeddingProvider`: Abstract base with caching and batching - `SimpleEmbeddingProvider`: Wrapper for existing embedding functions - Features: - Automatic caching with configurable capacity and TTL - Batch processing for efficiency - Advanced similarity computation with I-RCP support - Cache statistics tracking", "htmlHref": "/research/html/response-module-refactoring-summary-1nca3jb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1375 }, { "id": "enhanced-inverse-ring-contextual-propagation-icp-framework-cpurfv", "title": "Enhanced Inverse Ring Contextual Propagation (ICP) Framework", "slug": "enhanced-inverse-ring-contextual-propagation-icp-framework", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/ircp/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This enhanced ICP implementation integrates the comprehensive conversation database with advanced mathematical frameworks for learning individual response patterns in conversational dynamics. The system now supports both the original ICP architecture and TPO integration for comprehensive conversational AI training.", "excerpt": "This enhanced ICP implementation integrates the comprehensive conversation database with advanced mathematical frameworks for learning individual response patterns in conversational dynamics. The system now supports both the original ICP architecture and TPO integration for comprehensive conversational AI training.\n\n### 1. Database Integration - Direct integration with the conversation database - Efficient data loading and preprocessing - Support for both ICP and TPO data formats\n\n### 2. Enhanced Mathematical Framework - Improved measure-preserving transformations - Advanced differential equation solvers - Conservation constraint enforcement\n\n### 3. Modular Architecture - Clean separation of concerns - Extensible component system - Easy integration with other frameworks\n\n### 4. Advanced Training - Multi-objective optimization - Conservation-aware training - Adaptive learning strategies", "htmlHref": "/research/html/enhanced-inverse-ring-contextual-propagation-icp-framework-cpurfv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 619 }, { "id": "ircp-sentence-transformer-training-1q71hwk", "title": "IRCP Sentence Transformer Training", "slug": "ircp-sentence-transformer-training", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/ircp/training/README_SENTENCE_TRANSFORMER.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This directory contains the training pipeline for fine-tuning sentence transformers with IRCP coordinate-based supervision.", "excerpt": "This directory contains the training pipeline for fine-tuning sentence transformers with IRCP coordinate-based supervision.\n\nWe fine-tune sentence transformers (like `all-MiniLM-L6-v2`) to be **IRCP-aware** by using IRCP coordinate proximity as the similarity signal. This creates embeddings that understand conversation structure, intent depth, and temporal flow.\n\nThe default IRCP model **freezes** the sentence transformer encoder and only trains custom heads. This means:\n\n❌ Embeddings are generic (not IRCP-aware) ❌ Can't learn conversation-specific patterns ❌ Limited by pre-trained semantic similarity\n\n✅ End-to-end training of embeddings ✅ Learn IRCP-specific patterns ✅ Better coordinate prediction ✅ Improved conversation understanding", "htmlHref": "/research/html/ircp-sentence-transformer-training-1q71hwk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1048 }, { "id": "cc-tpo-computational-choreography-temporal-positional-optimization-1bn0ve2", "title": "CC-TPO - Computational Choreography Temporal Positional Optimization", "slug": "cc-tpo-computational-choreography-temporal-positional-optimization", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A comprehensive framework for semantic search and conversation analysis using Inverse Ring Contextual Propagation (IRCP) and Dynamic Liquid Motion (DLM) coordinates.", "excerpt": "A comprehensive framework for semantic search and conversation analysis using Inverse Ring Contextual Propagation (IRCP) and Dynamic Liquid Motion (DLM) coordinates.\n\n> **📚 Documentation**: All documentation has been organized in [`docs/`](docs/). See [`docs/README.md`](docs/README.md) for the full index.\n\n- **Getting Started**: [`docs/guides/GETTING_STARTED.md`](docs/guides/GETTING_STARTED.md) or [`START_HERE.md`](START_HERE.md) - **Architecture**: [`docs/architecture/`](docs/architecture/) - **Main CLI**: `python scripts/cc_ai.py --help` - **Latest Progress**: [`docs/progress/WEEK_3_PROGRESS_SUMMARY.md`](docs/progress/WEEK_3_PROGRESS_SUMMARY.md)\n\nSee [project_structure_final.md](.gemini/antigravity/brain/2cabc4fb-d307-4040-a5fa-bf170f888e05/project_structure_final.md) for complete structure.\n\n### IRCP (Inverse Ring Contextual Propagation) - **Location**: `packages/ircp/` - **Purpose**: Semantic embedding and ring topology-based conversation analysis - **Model**: Custom SentenceTransformer (384-dim embeddings) - **Training Data**: 277 conversations", "htmlHref": "/research/html/cc-tpo-computational-choreography-temporal-positional-optimization-1bn0ve2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 658 }, { "id": "root-folder-reorganization-plan-1oxrjk1", "title": "Root Folder Reorganization Plan", "slug": "root-folder-reorganization-plan", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/ROOT_REORGANIZATION_PLAN.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` cc-tpo/ ├── README.md # Main README (keep) ├── START_HERE.md # Getting started guide (keep) ├── .env # Environment config (keep) ├── package.json # Node config (keep) ├── requirements-ircp.txt # Python deps (keep) │ ├── docs/ # All documentation │ ├── guides/ # User guides │ │ ├── GETTING_STARTED.md │ │ ├── INTEGRATION_PLAN.md │ │ └── ... │ ├── architecture/ # Architecture docs │ │ ├── DLM_INTEGRATION_PIPELINE.md │ │ ├── DLM_FUSION_STRATEGY.md │ │ └── ... │ ├── progress/ # Progress summaries │ │ ├── WEEK_2_PROG", "excerpt": "## Current Issues - 40+ markdown files in root directory - Loose Python scripts (cc_ai.py, man.py, verify_imports.py) - Notebook file (main.ipynb) in root - Documentation scattered across root\n\n### Keep in Root: - README.md - START_HERE.md - .env - package.json, package-lock.json - requirements-ircp.txt\n\n### Move to docs/guides/: - GETTING_STARTED.md - INTEGRATION_PLAN.md - IRCP_INTEGRATION_QUICK_REFERENCE.md - DLM_INTEGRATION_QUICK_REFERENCE.md\n\n### Move to docs/architecture/: - DLM_INTEGRATION_PIPELINE.md - DLM_FUSION_STRATEGY.md - DLM_CODEBASE_AUDIT.md - PERSONALIZED_AI_SYSTEM_ARCHITECTURE.md - CC_AI_PIPELINE_COMPLETE.md\n\n### Move to docs/progress/: - WEEK_2_PROGRESS_SUMMARY.md - WEEK_2_TEST_RESULTS.md - WEEK_3_PROGRESS_SUMMARY.md - PHASE_2_1_COORDINATES.md - PHASE_2_2_EMBEDDINGS.md - PHASE_2_3_CONFIG.md - PHASE_2_4_LOGGING.md - PHASE_2_5_TESTING.md - PHASE_3_1_DATA_LOADING.md - PHASE_3_2_IRCP_INTEGRATION.md - PHASE_3_2_SUMMARY.md - PHASE_3_3_EVALUATION.md - PHASE_3_4_PIPELINE.md - PHASE_3_4_SUMMARY.md", "htmlHref": "/research/html/root-folder-reorganization-plan-1oxrjk1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 406 }, { "id": "search-api-quick-start-guide-1ju2amj", "title": "Search API Quick Start Guide", "slug": "search-api-quick-start-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/services/search-api/QUICK_START.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "```python { \"results\": [ { \"message_id\": \"...\", \"conversation_id\": \"...\", \"content\": \"...\", \"author\": \"user\", \"similarity\": 0.85, \"coordinates\": {\"x\": 5, \"y\": 2, \"z\": 1, \"t\": 0.5}, \"ring_position\": 180.0, \"depth_category\": \"shallow\", \"timestamp\": 1234567890, \"content_length\": 150, \"source\": \"conversations_fixed\" } ], \"analysis\": { \"similarity_stats\": {...}, \"depth_stats\": {...}, \"ring_stats\": {...}, \"author_distribution\": {...}, \"depth_distribution\": {...} }, \"query\": \"machine learning\", \"total_found\": 25, \"sources", "excerpt": "1. **Use semantic mode** for best accuracy 2. **Use fast mode** for good balance of speed/accuracy 3. **Use instant mode** for fastest results (lower accuracy) 4. **Model is cached** - first load is slow, subsequent searches are fast 5. **Batch operations** - use `cosine_similarity_batch` for multiple comparisons", "htmlHref": "/research/html/search-api-quick-start-guide-1ju2amj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 568 }, { "id": "search-api-services-l5iwg1", "title": "Search API Services", "slug": "search-api-services", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/services/search-api/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Features:** - IRCP embedding-based semantic search - SQLite database integration - Conversation history search - Similarity scoring", "excerpt": "This directory contains all search-related backend services and APIs for the CC-TPO project.\n\n**Features:** - IRCP embedding-based semantic search - SQLite database integration - Conversation history search - Similarity scoring\n\n### ⚡ search_api_optimized.py Optimized version of the search API with performance improvements.\n\n**Features:** - Faster query processing - Reduced memory footprint - Batch processing support\n\n**Features:** - Minimal overhead - Quick response times - Suitable for real-time applications", "htmlHref": "/research/html/search-api-services-l5iwg1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 326 }, { "id": "search-api-refactoring-summary-hxlyuk", "title": "Search API Refactoring Summary", "slug": "search-api-refactoring-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/services/search-api/REFACTORING_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**New Structure**: ``` core/ ├── __init__.py # Exports ├── model_manager.py # Unified model loading & caching ├── database.py # Unified database queries & operations ├── similarity.py # Unified similarity calculations └── formatters.py # Unified result formatting & analysis ```", "excerpt": "## Overview Comprehensive consolidation of the search-api module to eliminate redundancy and improve maintainability. Created unified core components that all search implementations can use.\n\n**Benefits**: - Single source of truth for common operations - Reduced code duplication by ~60% - Consistent behavior across all search implementations - Easier to optimize and maintain\n\n**After**: Single `ModelManager` class with: - Thread-safe singleton pattern - Automatic caching - Consistent configuration - Error handling\n\n**Files Consolidated**: - `search_api.py` - `load_model()` - `search_api_optimized.py` - `load_model_cached()` - `search_server.py` - `load_model()` - `ircp_gui_search.py` - `load_model()` - `ircp_web_search.py` - `load_model()` - `claude_semantic_search_system.py` - `load_model()`\n\n**After**: `DatabaseSearcher` and `DatabaseQueryBuilder` classes with: - Standardized query building - Consistent database paths - Unified result parsing - Claude conversation loading with caching", "htmlHref": "/research/html/search-api-refactoring-summary-hxlyuk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 989 }, { "id": "training-directory-qkuaz9", "title": "Training Directory", "slug": "training-directory", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/training/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` training/ └── ircp/ ├── full_dataset/ # Full dataset training │ ├── best_model.pt # Trained model checkpoint │ ├── inferred_config.json # Model configuration │ └── [other training files] │ ├── complete_training/ # Complete training run │ ├── outputs/ # Training outputs and logs │ ├── evaluation/ # Evaluation results │ └── backups/ # Training backups └── ircp_training_backup_20250815_173556/ ```", "excerpt": "This directory contains all machine learning training artifacts, models, and evaluation results for the IRCP project.\n\n### full_dataset/ Contains the production IRCP model trained on the full dataset.\n\n**Key Files:** - `best_model.pt` - PyTorch model checkpoint - `inferred_config.json` - Model configuration - Training hyperparameters and metrics\n\n**Used by:** - `apps/liquid-chat-backend/main.py` - Loads this model for embeddings\n\n**Architecture:** Custom SentenceTransformer with IRCP (Inverse Ring Contextual Propagation)", "htmlHref": "/research/html/training-directory-qkuaz9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 327 }, { "id": "ircp-service-1n9ec0w", "title": "IRCP Service", "slug": "ircp-service", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/services/ircp-service/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Python-based service providing **Inverse Ring Contextual Propagation (IRCP)** embeddings for topological search in TrajectoryOS. Enables 5D coordinate-based retrieval beyond traditional semantic search.", "excerpt": "Python-based service providing **Inverse Ring Contextual Propagation (IRCP)** embeddings for topological search in TrajectoryOS. Enables 5D coordinate-based retrieval beyond traditional semantic search.\n\nIRCP Service generates topological embeddings for life events, enabling multi-dimensional search that combines: - **Semantic similarity** (what events mean) - **Topological distance** (where events sit in 5D space) - **Physics-based filtering** (life regime awareness)\n\n**5D Coordinate Space**: - **x**: Depth (exploration vs exploitation) - **y**: Alternatives (breadth of options considered) - **z**: Coherence (alignment of actions) - **t**: Time (temporal position) - **n**: Complexity (system noise/uncertainty)\n\n### Prerequisites - Python 3.11+ - pip or poetry - (Optional) GPU for faster embeddings\n\nTraditional embeddings (like Word2Vec, BERT) capture semantic meaning but ignore **structural position** in a life trajectory. IRCP adds topological awareness.", "htmlHref": "/research/html/ircp-service-1n9ec0w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1366 }, { "id": "rag-evaluation-framework-fo5efb", "title": "RAG++ Evaluation Framework", "slug": "rag-evaluation-framework", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/services/trajectory-core/src/evaluation/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Runs all three evaluation components: - Action Classification (30-100 labeled events) - Recommendation Quality (5-15 states) - State-Awareness (regime consistency, flag sensitivity)", "excerpt": "Complete evaluation suite for RAG++ v0 with action classification, recommendation quality, and state-awareness testing.\n\nThis creates 3 evaluation users with 60-90 days of realistic trajectory data each.\n\nRuns all three evaluation components: - Action Classification (30-100 labeled events) - Recommendation Quality (5-15 states) - State-Awareness (regime consistency, flag sensitivity)\n\n**Measures**: Precision, Recall, F1 for each action type - ReduceGravity - ReduceMass - IncreaseAlignment - IncreaseThrust\n\n**Methods Tested**: - Heuristic (keyword patterns) - LLM (Anthropic API) - Hybrid (heuristic + LLM fallback)", "htmlHref": "/research/html/rag-evaluation-framework-fo5efb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1051 }, { "id": "agp-turboquant-ane-benchmarks-1rge6nh", "title": "AGP TurboQuant + ANE Benchmarks", "slug": "agp-turboquant-ane-benchmarks", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/benchmarks/agp-turboquant-ane/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This benchmark package makes the local `cog-rlm` TurboQuant and Apple Neural Engine research measurable inside the AGP research track.", "excerpt": "This benchmark package makes the local `cog-rlm` TurboQuant and Apple Neural Engine research measurable inside the AGP research track.\n\n- `Desktop/cog-rlm/scripts/turboquant.py` - `Desktop/cog-rlm/scripts/ane_bridge.py` - `Desktop/cog-rlm/scripts/ane_whisper_spike.py` - `Desktop/cog-rlm/scripts/ane_mlx_train.py` - `Desktop/cog-rlm/scripts/ane_trainer.py` - `Desktop/Comp-Core/core/retrieval/cc-turboquant-index`\n\nThe JSONL importer accepts raw vector arrays or object rows with `embedding`, `vector`, `values`, or `embedding_vector` fields.\n\n- TurboQuant embedding search quality and memory footprint. - Rust packed-code TurboQuant candidate generation over bit-packed corpus rows. - Rust packed snapshot persistence and metadata inspection. - JSONL ingestion for exported Orbit/RAG++ embedding slices. - TurboQuant activation packet compression for AGP-PTP transport. - Local ANE private MIL bridge availability. - Minimal ANE route-head compile/eval status through `ane_route_head_bench.py`.\n\n- It does not prove final retrieval latency; the current Python path pre-dequantizes rotated vectors to fp16. - The Rust sidecar v0 is packed-code scalar scan, not the final hand-tuned Apple Silicon SIMD kernel. - It does not claim ANE trains the full transformer. - It does not claim ANE route-head execution is currently stable; the current local bridge compiles but eval fails with Apple ANE status `0x2/statusType=0x9`. - It does not replace MLX/GPU as the stable training path.", "htmlHref": "/research/html/agp-turboquant-ane-benchmarks-1rge6nh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 399 }, { "id": "anticipatory-transformer-phase-0-validation-1fzoya6", "title": "Anticipatory Transformer - Phase 0 Validation", "slug": "anticipatory-transformer-phase-0-validation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/_recovered/cc-anticipatory-transformer/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Empirical validation of core architectural components for the Anticipatory Transformer as defined in [docs/architecture/23-ANTICIPATORY_TRANSFORMER.md](../../docs/architecture/23-ANTICIPATORY_TRANSFORMER.md).", "excerpt": "Empirical validation of core architectural components for the Anticipatory Transformer as defined in [docs/architecture/23-ANTICIPATORY_TRANSFORMER.md](../../docs/architecture/23-ANTICIPATORY_TRANSFORMER.md).\n\n1. **Frequency Separation**: Dual pathways naturally specialize (fast: syntax 5-50 Hz, slow: semantics 0.5-5 Hz) 2. **Orthogonality**: Cross-covariance penalty prevents mode collapse while maintaining specialization 3. **Trajectory Attention**: Additive bias mechanism is numerically stable and improves context efficiency 4. **Commitment Targets**: Counterfactual stability correlates with generation quality (r > 0.6) 5. **Slice-Based Context**: Priority-queue selection achieves 30% token reduction vs fixed-window baseline\n\n- Python 3.10+ - PyTorch 2.1+ with CUDA 12.1 - 1x A100 (40GB) or equivalent GPU - ~100GB disk space for checkpoints and data\n\nEach experiment must meet specific success criteria as defined in [23-ANTICIPATORY_TRANSFORMER_PHASE0_CHARTER.md](../../docs/architecture/23-ANTICIPATORY_TRANSFORMER_PHASE0_CHARTER.md):\n\n| Experiment | Success Criterion | Measurement | |------------|------------------|-------------| | Frequency Separation | Fast: 5-50 Hz, Slow: 0.5-5 Hz, <10% overlap | FFT on hidden states | | Orthogonality | L_ortho ↓ during training, perplexity stable | Training curves | | Trajectory Attention | No NaN/Inf gradients over 10K steps | Gradient monitoring | | Commitment Correlation | r > 0.6 with quality ratings (n=100) | Pearson correlation | | Context Efficiency | 30% fewer tokens for equivalent perplexity | Token budget sweep |", "htmlHref": "/research/html/anticipatory-transformer-phase-0-validation-1fzoya6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 385 }, { "id": "phase-2-complete-rust-javascript-bridge-2bbbdu", "title": "🎉 Phase 2 Complete: Rust → JavaScript Bridge", "slug": "phase-2-complete-rust-javascript-bridge", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/PHASE_2_COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The Rust → JavaScript communication layer is now **fully functional**. PatternEdit commands can flow from the Tauri backend to the React frontend and into StrudelEngine.", "excerpt": "The Rust → JavaScript communication layer is now **fully functional**. PatternEdit commands can flow from the Tauri backend to the React frontend and into StrudelEngine.\n\n1. **PatternEdit Type System** - Defined `PatternEdit` enum matching cc-brain/conductor.rs - Four variants: SetParam, ScheduleEvent, Transform, SectionChange - Full serialization support (Serde)\n\n2. **Tauri Commands** - `emit_pattern_edit()` - Send PatternEdit to frontend - `test_pattern_edit()` - Manual testing command - `get_conductor_status()` - Placeholder for Phase 3\n\n3. **Command Registration** - All commands registered in main.rs invoke_handler - Ready for frontend to call\n\n4. **useStrudelEngine Hook** - Manages StrudelEngine lifecycle - Listens for `pattern_edit` Tauri events - Provides start/stop/toggle controls - Tracks state (isPlaying, currentSection, editsReceived)", "htmlHref": "/research/html/phase-2-complete-rust-javascript-bridge-2bbbdu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1069 }, { "id": "gap-g4-features-json-schema-verification-1jmtqv1", "title": "Gap G4 — `features.json` Schema Verification", "slug": "gap-g4-features-json-schema-verification", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/tools/lume-music/FEATURES_VERIFY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Verifies the `features.json` files in the 115-track LUME stem library against > both the producer (`process_library.py`) and the consumer > (`StemFeatureSet::parse` in `audio-engine`). The consumer is the binding > contract: it is the code that actually loads the files at runtime. > > Date: 2026-05-21. Task: LUME Gap G4.", "excerpt": "> Verifies the `features.json` files in the 115-track LUME stem library against > both the producer (`process_library.py`) and the consumer > (`StemFeatureSet::parse` in `audio-engine`). The consumer is the binding > contract: it is the code that actually loads the files at runtime. > > Date: 2026-05-21. Task: LUME Gap G4.\n\n`process_library.py` emits a superset of every field `StemFeatureSet::parse` reads, with matching names, matching types, and matching array lengths. The parser is built to be permissive (`#[serde(default)]` on every field) and only hard-fails on transport-critical conditions that a correctly-run `process_library.py` cannot produce. No schema mismatch, no name drift, no type drift, no unit drift was found. No code change was required.\n\nOne environmental caveat is recorded in §6: this run could not pull the live `features.json` files off K11 (`ssh k11`) because the local machine's disk is 100% full, which blocks the Bash tool's command-output path. The verification is therefore a complete static reconciliation of producer code vs. consumer code plus the in-tree Rust test fixture, which is itself a `features.json` instance. A live-sample spot check remains as a recommended follow-up once disk is freed.\n\nLocation: `core/audio-media/stem-pipeline/process_library.py` (single canonical copy; a workspace-wide search found no other `process_library.py`).\n\nIt runs Demucs `htdemucs` 4-stem separation, then `extract_features()` (lines 93-161) runs librosa per stem and writes `features.json` via `process_track()` (lines 197-202) to `/separated///features.json`.", "htmlHref": "/research/html/gap-g4-features-json-schema-verification-1jmtqv1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2259 }, { "id": "stemdeck-stage-1-quality-gate-10fcz9m", "title": "StemDeck Stage 1 — Quality Gate", "slug": "stemdeck-stage-1-quality-gate", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/tools/lume-music/STEMDECK_QUALITY_GATE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Target**: `crates/audio-engine/src/stem_deck.rs` (1643 lines) + the `fx.rs` SVF coefficient-caching change. - **HEAD**: `749408de` on `feat/femto-only-bar` (21 prior meta-review findings already fixed). - **Baseline**: `cargo test -p audio-engine` — 67 pass, 0 fail, 3 ignored. - **Method**: Layer 1 meta-review (6 parallel domain passes + contrarian) → Layer 2 meta:amr (6-domain adversarial debate) → Layer 3 meta:adversarial (Codex gpt-5.3-codex, read-only).", "excerpt": "- **Target**: `crates/audio-engine/src/stem_deck.rs` (1643 lines) + the `fx.rs` SVF coefficient-caching change. - **HEAD**: `749408de` on `feat/femto-only-bar` (21 prior meta-review findings already fixed). - **Baseline**: `cargo test -p audio-engine` — 67 pass, 0 fail, 3 ignored. - **Method**: Layer 1 meta-review (6 parallel domain passes + contrarian) → Layer 2 meta:amr (6-domain adversarial debate) → Layer 3 meta:adversarial (Codex gpt-5.3-codex, read-only).\n\nThe Hydra quality gate (0 critical AND 0 high) does **not** pass as-is — the 2 High findings block. Both are small, well-localized fixes. Codex's structural finding: the sample-locked playhead model and the `render()` path are sound; Stage 2 (`StemConductor`) can be built on `StemDeck` once the 2 Highs (and ideally the 4 Mediums) are fixed.\n\nThe chain earned its cost: it found **QG-A** — a reachable panic in the audio worker — and **QG-FX1** — reverb default-state incoherence. Both were missed by the original 21-finding meta-review. It also killed 8 false or overstated findings under adversarial pressure.\n\n| ID | File:Line | Finding | Fix | |----|-----------|---------|-----| | QG-A | fx.rs:170, 184, 210, 214 / fx.rs:515, 564, 570 / stem_deck.rs:319 | No sample-rate validation at the construction boundary. `DelayFx::new`/`FlangerFx::new` size their ring buffers as `(sample_rate * N) as usize`, which is `0` for a zero/tiny `sample_rate` → empty `Vec`. Then `DelayFx::set_delay_ms` does `buffer.len() - 1` (usize underflow) and `process_sample` does `% buffer.len()` (divide-by-zero) → **panic aborts the audio worker**. Zero/non-finite `sample_rate` also yields NaN SVF coefficients. `StemDeck::new` passes `sample_rate` through unchecked. | Validate `sample_rate` once in `StemDeck::new` (finite, `> 0`, `== 48_000.0` per the 48kHz-only contract — return `Result`/`bail!`). Add `.max(1)` to the `DelayFx`/`FlangerFx` buffer sizing as defense-in-depth — mirrors `CombFilter::new(size.max(1))` already in the same file; Delay/Flanger are an inconsistent omission. | | QG-2 | stem_deck.rs:1599 | `loop_seam_is_click_free` tolerance is `filtered_jump <= raw_jump * 1.25 + 1e-4` — it *permits the filter to amplify the seam discontinuity by 25%*. The test guarding the headline click-free guarantee cannot fail for the right reason. | `filtered_jump <= raw_jump + 1e-4` — the filter must dampen the seam, never amplify it. |\n\n| ID | File:Line | Finding | Fix | |----|-----------|---------|-----| | QG-1 | stem_deck.rs:179 | `StemFeatureSet::parse` accepts non-finite/negative `bpm` — the `bpm <= 0.0` guard does not catch `NaN` (NaN comparisons are false). Downstream is mostly protected (`bpm()` returns `None` for non-positive), so impact is contained, but a malformed `features.json` should be rejected at parse, not absor", "htmlHref": "/research/html/stemdeck-stage-1-quality-gate-10fcz9m.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1004 }, { "id": "phrase-database-enhancement-guide-1ubejpg", "title": "Phrase Database Enhancement Guide", "slug": "phrase-database-enhancement-guide", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/ml/cc-ml/diffusion/ENHANCEMENT_GUIDE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. **Sub-segment** existing phrases into shorter, more expressive sub-phrases 2. **Analyze** your database to understand what you have 3. **Enhance** structure while staying CPU-efficient", "excerpt": "You currently have **68 phrases** from **7 files** using **fixed segmentation**. This guide shows how to:\n\n1. **Sub-segment** existing phrases into shorter, more expressive sub-phrases 2. **Analyze** your database to understand what you have 3. **Enhance** structure while staying CPU-efficient\n\n- **Method**: Fixed segmentation (uniform chunks) - **Phrases**: 68 - **Source files**: 7 - **Average phrase length**: ~12-16 bars (estimated)\n\nApply a **second layer** of segmentation on top of your fixed segments to get more granular structure:\n\n**What this does:** - Takes each existing 12-16 bar phrase - Further segments it into 2-8 bar sub-phrases - Uses lightweight, CPU-efficient methods - Preserves all original phrases - Creates new sub-phrases with `_sub1`, `_sub2` labels", "htmlHref": "/research/html/phrase-database-enhancement-guide-1ubejpg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 660 }, { "id": "beat-tracking-cache-optimization-6qdx4v", "title": "Beat Tracking Cache Optimization", "slug": "beat-tracking-cache-optimization", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/ml/cc-ml/diffusion/scripts/BEAT_CACHE_OPTIMIZATION.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The `build_phrase_database_incremental.py` script includes a **beat tracking cache** that significantly speeds up reprocessing of audio files.", "excerpt": "The `build_phrase_database_incremental.py` script includes a **beat tracking cache** that significantly speeds up reprocessing of audio files.\n\nBeat tracking is the most computationally expensive step in the phrase database building pipeline (~270s per file). The cache stores: - Beat times - Downbeat locations - BPM information\n\n- The cache automatically invalidates when a file is modified - Gracefully handles corrupted cache files by recomputing - Cache persists across script runs\n\n| Stage | Without Cache | With Cache | Speedup | |-------|--------------|------------|---------| | **Beat Tracking** | ~270s | <0.5s | **~500x faster** ⚡ | | **Total per file** | ~280-310s | ~10-20s | **~15-30x faster** ⚡ | | **10 files** | ~50 min | ~2-4 min | **~15-25x faster** ⚡ | | **200 files** | ~16-17 hours | ~30-60 min | **~15-30x faster** ⚡ |\n\nUse `--no-cache` when: - Beat tracking algorithm has changed - You suspect cached results are incorrect - Debugging beat tracking issues - First-time processing (no cache exists yet anyway)", "htmlHref": "/research/html/beat-tracking-cache-optimization-6qdx4v.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 450 }, { "id": "diffusion-system-setup-guide-1kjxiy5", "title": "Diffusion System Setup Guide", "slug": "diffusion-system-setup-guide", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/ml/cc-ml/diffusion/SETUP_GUIDE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. **Project Structure** - Created `diffusion/` module with proper package structure - Set up configuration system (`configs/`) - Organized into logical subdirectories (data, models, training, inference)", "excerpt": "**Status**: Phase 0 Complete ✅ **Next**: Ready to install dependencies and build Phase 1\n\n1. **Project Structure** - Created `diffusion/` module with proper package structure - Set up configuration system (`configs/`) - Organized into logical subdirectories (data, models, training, inference)\n\n2. **Documentation** - Main README with full architecture overview - Configuration files with extensive comments - This setup guide\n\n3. **Dependencies** - Updated `requirements.txt` with all necessary packages: - Audio processing (librosa, soundfile, madmom, aubio) - Vector search (FAISS, hnswlib) - Diffusion models (diffusers, k-diffusion) - Training utilities (accelerate, wandb)\n\n4. **Configuration Files** - `phrase_database.yaml`: Full configuration for building phrase DB - `vqvae.yaml`: Complete VQ-VAE tokenizer setup", "htmlHref": "/research/html/diffusion-system-setup-guide-1kjxiy5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1202 }, { "id": "cc-core-cc-collection-integration-benchmark-report-omnnn0", "title": "CC-Core / CC-Collection Integration Benchmark Report", "slug": "cc-core-cc-collection-integration-benchmark-report", "kind": "experiment", "program": "Research Practice", "sourceAnchor": "Comp-Core/core/runtime/cc-core/docs/integration/BENCHMARK.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document compares the performance characteristics of the legacy `SensorDataset`/`SensorDataLoader` pipeline against the new `MotionDataset`/`MotionDataLoader` pipeline integrated with `cc_collection`.", "excerpt": "This document compares the performance characteristics of the legacy `SensorDataset`/`SensorDataLoader` pipeline against the new `MotionDataset`/`MotionDataLoader` pipeline integrated with `cc_collection`.\n\n| Metric | Legacy Pipeline | New Pipeline | Improvement | |--------|-----------------|--------------|-------------| | Data Loading (NPZ) | Baseline | ~1.05x | +5% overhead (type validation) | | Batch Collation | Baseline | ~0.95x | 5% faster (optimized numpy ops) | | Memory per Sample | 100 bytes (25D) | 100 bytes (25D) | No change | | Type Safety | Runtime checks | Compile-time + Runtime | Stronger guarantees | | Session Handling | Manual | Automatic boundaries | Reduced data leakage |\n\n- **Small Dataset**: 10,000 frames, 1 session - **Medium Dataset**: 100,000 frames, 10 sessions - **Large Dataset**: 1,000,000 frames, 50 sessions\n\n1. **Data Loading**: Time to load dataset from NPZ file 2. **Iteration**: Time to iterate through entire dataset 3. **Batch Collation**: Time to collate batches 4. **Memory Usage**: Peak memory during operations 5. **Type Validation**: Overhead of validation checks\n\n**Characteristics**: - Fast loading (no validation) - No dtype enforcement - No shape validation - Silent failures on malformed data", "htmlHref": "/research/html/cc-core-cc-collection-integration-benchmark-report-omnnn0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1067 }, { "id": "lim-rps-and-dell-evaluation-guide-100ypoc", "title": "LIM-RPS and DELL Evaluation Guide", "slug": "lim-rps-and-dell-evaluation-guide", "kind": "experiment", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/runtime/cc-core/evals/LIMRPS_EVALUATION.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The `evaluate_with_limrps.py` script: 1. Loads sensor data from CSV files 2. Processes data through LIM-RPS (Lipschitz-constrained Implicit-Map for Recursive Proximal Synthesis) 3. Optionally processes through DELL (Dual-Equilibrium Latent Learning) 4. Generates comprehensive visualizations", "excerpt": "This guide explains how to evaluate sensor data using the LIM-RPS and DELL algorithms with visualizations.\n\nThe `evaluate_with_limrps.py` script: 1. Loads sensor data from CSV files 2. Processes data through LIM-RPS (Lipschitz-constrained Implicit-Map for Recursive Proximal Synthesis) 3. Optionally processes through DELL (Dual-Equilibrium Latent Learning) 4. Generates comprehensive visualizations\n\nThe script generates plots in the specified `--plots-dir` directory (default: `evals/plots/`):\n\n1. **Accelerometer X, Y, Z over time** - Raw accelerometer data 2. **Accelerometer Magnitude** - L2 norm of acceleration vector 3. **Motion Energy** - Computed motion energy over time 4. **Gyroscope Data** - Angular velocity (if available) 5. **LIM-RPS Convergence** - Residual convergence plot (if LIM-RPS is used) 6. **3D Accelerometer Trajectory** - 3D visualization of acceleration space\n\n1. **Encoding**: Converts raw sensor data (accelerometer, gyroscope, energy) into latent representations 2. **Fusion**: Solves a fixed-point equation to find the equilibrium state:", "htmlHref": "/research/html/lim-rps-and-dell-evaluation-guide-100ypoc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 665 }, { "id": "graph-kernel-security-hardening-implementation-summary-al05jy", "title": "Graph Kernel Security Hardening — Implementation Summary", "slug": "graph-kernel-security-hardening-implementation-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-graph-kernel/docs/IMPLEMENTATION_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. **[00-PROJECT_CHARTER.md](00-PROJECT_CHARTER.md)** — Locked charter defining: - Purpose: Make security guarantees impossible to bypass, cheap to verify, easy to debug - Non-goals: No algorithm changes, no UI, no API breaking changes - Success criteria: 7 measurable conditions - Direction constraints: 5 compatibility requirements", "excerpt": "Created complete documentation-driven implementation foundation following CLAUDE.md constitution:\n\n1. **[00-PROJECT_CHARTER.md](00-PROJECT_CHARTER.md)** — Locked charter defining: - Purpose: Make security guarantees impossible to bypass, cheap to verify, easy to debug - Non-goals: No algorithm changes, no UI, no API breaking changes - Success criteria: 7 measurable conditions - Direction constraints: 5 compatibility requirements\n\n2. **[01-GLOSSARY.md](01-GLOSSARY.md)** — Comprehensive term definitions: - 15 core security/verification terms defined - Overloaded terms flagged and split - Layer assignments (Conceptual/Architectural/Runtime/Interface) - Stability levels for each definition\n\n3. **[02-INVARIANTS_LEDGER.md](02-INVARIANTS_LEDGER.md)** — Production invariants: - 6 assumptions with falsification detection - 8 invariants with canary implementations - Incident response triggers with severity levels - Canary implementation status tracking\n\n4. **[03-IMPLEMENTATION_GUIDE.md](03-IMPLEMENTATION_GUIDE.md)** — Execution rules: - Signal requirements (micro/meso/macro decisions) - Decomposition rules (atomic unit definition) - Validation stages and artifacts - Priority ordering: Type safety → Canonicalization → Verification → Sufficiency → ...", "htmlHref": "/research/html/graph-kernel-security-hardening-implementation-summary-al05jy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 737 }, { "id": "implementation-guide-dojbao", "title": "Implementation Guide", "slug": "implementation-guide", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/core/semantic/cc-inscription/docs/03-IMPLEMENTATION_GUIDE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Decision Type | Signals Required | Example | |--------------|------------------|---------| | **Micro** (naming, formatting) | 1 signal | Variable names, comment style | | **Meso** (module API, struct fields) | 2 signals | Claim struct design, method signatures | | **Macro** (claim types, sigil assignments) | 3+ signals | Adding claim type 11, changing sigil |", "excerpt": "| Decision Type | Signals Required | Example | |--------------|------------------|---------| | **Micro** (naming, formatting) | 1 signal | Variable names, comment style | | **Meso** (module API, struct fields) | 2 signals | Claim struct design, method signatures | | **Macro** (claim types, sigil assignments) | 3+ signals | Adding claim type 11, changing sigil |\n\n1. **Charter wins**: If conflicting with implementation detail, charter governs 2. **Invariants win**: If violating invariant, implementation must change 3. **Glossary wins**: If term is ambiguous, glossary definition governs 4. **IR wins**: If N'Ko surface conflicts with IR structure, adjust surface\n\nA task is complete when: - [ ] Code compiles without warnings - [ ] Tests pass (`cargo test`) - [ ] Documentation matches implementation - [ ] Checklist item is marked complete with artifact reference\n\nA task is blocked when: - Missing dependency (another task must complete first) - Ambiguous requirement (needs clarification) - External service unavailable (Graph Kernel, DELL) - Resource constraint (memory, compute)\n\nThe smallest unit of work: - Has a single, verifiable output (one file, one struct, one test) - Can be validated independently - Does not require context from unfinished sibling tasks - Can be rolled back without affecting other units", "htmlHref": "/research/html/implementation-guide-dojbao.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1167 }, { "id": "experiment-index-cc-semantic-language-phase-9-nnl0yi", "title": "Experiment Index: cc-semantic-language Phase 9", "slug": "experiment-index-cc-semantic-language-phase-9", "kind": "experiment", "program": "Research Backlog", "sourceAnchor": "Comp-Core/core/semantic/cc-semantic-language/docs/research/EXPERIMENT_INDEX.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Version**: 1.0.0 **Status**: Active **Schema Version**: 1.0.0 **Last Modified**: 2024-12-31 **Mode**: Simulated (BATCH-001) — See RUN_MANIFEST.md", "excerpt": "**Version**: 1.0.0 **Status**: Active **Schema Version**: 1.0.0 **Last Modified**: 2024-12-31 **Mode**: Simulated (BATCH-001) — See RUN_MANIFEST.md\n\nThis document is the table of contents for reproducibility. It enumerates every experiment run and maps to file paths for inputs, results, and logs. If someone else runs this repository, this index makes it impossible to get lost.\n\n| Field | Description | |-------|-------------| | **Experiment ID** | Unique identifier (EXP-XXX) | | **Stress Profile** | Name of stress profile used | | **Seed** | Random seed for PRNG | | **Replay Count** | Number of rehearsal iterations | | **Target Stage** | Starting lifecycle stage filter | | **Dataset Slice** | Manifest reference | | **Input Path** | JSONL input file relative to `repro/phase9_bundle_v1/` | | **Result Path** | JSONL result file relative to `repro/phase9_bundle_v1/` | | **Event Log** | Event log snapshot hash or path | | **Status** | Pending / Complete / Failed |\n\n| Field | Value | |-------|-------| | Experiment ID | EXP-001 | | Stress Profile | baseline_v1 | | Seed | 42 | | Replay Count | 100 | | Target Stage | proto | | Dataset Slice | publication_slice_v1 | | Input Path | runs/baseline_42_input.jsonl | | Result Path | runs/baseline_42_result.jsonl | | Event Log | logs/baseline_42_events.hash | | Status | Pending |\n\n| Field | Value | |-------|-------| | Experiment ID | EXP-002 | | Stress Profile | baseline_v1 | | Seed | 100 | | Replay Count | 100 | | Target Stage | proto | | Dataset Slice | publication_slice_v1 | | Input Path | runs/baseline_100_input.jsonl | | Result Path | runs/baseline_100_result.jsonl | | Event Log | logs/baseline_100_events.hash | | Status | Pending |", "htmlHref": "/research/html/experiment-index-cc-semantic-language-phase-9-nnl0yi.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1667 }, { "id": "agp-thunder-train-stage-1-plan-ahnspw", "title": "AGP Thunder-Train Stage 1 Plan", "slug": "agp-thunder-train-stage-1-plan", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/research/agp-thunder-train-stage1-plan.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This is the stage-1 backbone plan for running AGP domain adaptation across `Mac4 + Mac5` over `Thunderbolt 5` using the existing `thunder-train` stack. The purpose of this stage is not to train the full AGP architecture end to end. The purpose is to make both Macs compute immediately on the first useful backbone problem: `Gemma 4 E2B` domain adaptation on the AGP high-signal corpus.", "excerpt": "This is the stage-1 backbone plan for running AGP domain adaptation across `Mac4 + Mac5` over `Thunderbolt 5` using the existing `thunder-train` stack. The purpose of this stage is not to train the full AGP architecture end to end. The purpose is to make both Macs compute immediately on the first useful backbone problem: `Gemma 4 E2B` domain adaptation on the AGP high-signal corpus.\n\nThe core decision is now explicit. `Mac4 + Mac5 should both compute.` The prior single-host MLX path remains important, but only as the baseline and fallback control. The primary execution path for stage 1 is dual-host Thunder-Train over the `10.0.5.x` Thunderbolt link.\n\nFirst, the real Thunder entrypoint is `launch.sh`, not `distributed_launch.sh`. The repo marks `distributed_launch.sh` as legacy and the current launcher path is `launch.sh` + `mlx_launch.py`.\n\nSecond, Thunder-Train expects ChatML-style `{\"messages\": [...]}` records. The current AGP MLX lane already proved out on plain `text` exports for `mlx_lm lora`, so the AGP data must be re-exported into Thunder format instead of pretending the same files can be reused unchanged.\n\nThird, the remote runtime assumption is currently broken. The Thunder launcher expects a consistent Python interpreter path on both Macs with `mlx` and `mlx_lm` installed. At status check time, neither host satisfied that assumption cleanly. Until that parity is fixed, no distributed launch should be called “live.”", "htmlHref": "/research/html/agp-thunder-train-stage-1-plan-ahnspw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 737 }, { "id": "anticipation-geometry-1fkbtu7", "title": "anticipation-geometry", "slug": "anticipation-geometry", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/anticipation-geometry/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Bridges Princeton's KG-path reward function (arXiv:2603.14147) with Comp-Core's anticipation geometry. Provides domain-general anticipation scalars that work on any trajectory: motion vectors, conversation embeddings, knowledge graph paths, or task planning traces.", "excerpt": "Bridges Princeton's KG-path reward function (arXiv:2603.14147) with Comp-Core's anticipation geometry. Provides domain-general anticipation scalars that work on any trajectory: motion vectors, conversation embeddings, knowledge graph paths, or task planning traces.\n\n| Question | Princeton (KG Reward) | Comp-Core (Anticipation Geometry) | |----------|----------------------|-----------------------------------| | What it evaluates | Path validity (retrospective) | Path dynamics (prospective) | | Core question | \"Was this path correct?\" | \"Where is this path going?\" | | Input | Completed KG path | Ongoing state trajectory | | Output | Composite reward score | 4 scalar fields per timestep | | Strength | Hard correctness signal | Early warning / steering signal |\n\nCombined, they enable: early detection of invalid reasoning, identification of exploration opportunities, and optimal steering at decision points.\n\n**Uncertainty** u(t) = H(angular distribution of KNN displacement vectors) / H_max\n\n- `numpy` (required) - `requests` (required, for GK + Supabase queries) - `sentence-transformers` (optional, for conversation embeddings; falls back to hash embedding)", "htmlHref": "/research/html/anticipation-geometry-1fkbtu7.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 713 }, { "id": "crp-1-2-expanded-evaluation-suite-174-questions-1x20wpf", "title": "CRP-1.2: Expanded Evaluation Suite (174 Questions)", "slug": "crp-1-2-expanded-evaluation-suite-174-questions", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/CRP-1.2-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Dimension | ID Prefix | Count | Source | |-----------|-----------|-------|--------| | Question Policy | `qp` | 7 | original | | Format Compliance | `fc` | 5 | original | | Omission | `om` | 3 | original | | Historical Annoyance | `ha` | 5 | original | | Edge Case | `ec` | 4 | original | | **Recall** | `rc` | 15 | expanded | | **Reasoning** | `rs` | 15 | expanded | | **Temporal** | `tp` | 12 | expanded | | **Counterfactual** | `cf` | 12 | expanded | | **Adversarial** | `av` | 12 | expanded | | **Generalization** |", "excerpt": "Expanded the CognitiveTwin V3 evaluation suite from **24 to 174 test cases** across **18 dimensions**.\n\n### Files Modified - `cognitive_twin/v3/eval/test_cases_expanded.py` — **NEW** (2309 lines, 150 tests across 13 classes) - `cognitive_twin/v3/eval/suite.py` — Registered all 13 new generators - `cognitive_twin/v3/eval/__init__.py` — Added exports for expanded test classes - `scripts/eval_dry_run.py` — **NEW** dry-run + live eval script\n\n### Files Generated - `data/eval_results/eval_dryrun_*.json` — Mock results with full structure\n\n| Dimension | ID Prefix | Count | Source | |-----------|-----------|-------|--------| | Question Policy | `qp` | 7 | original | | Format Compliance | `fc` | 5 | original | | Omission | `om` | 3 | original | | Historical Annoyance | `ha` | 5 | original | | Edge Case | `ec` | 4 | original | | **Recall** | `rc` | 15 | expanded | | **Reasoning** | `rs` | 15 | expanded | | **Temporal** | `tp` | 12 | expanded | | **Counterfactual** | `cf` | 12 | expanded | | **Adversarial** | `av` | 12 | expanded | | **Generalization** | `gz` | 10 | expanded | | **Consistency** | `cs` | 10 | expanded | | **Precision** | `pr` | 10 | expanded | | **Negation** | `ng` | 10 | expanded | | **Inference** | `if` | 10 | expanded | | **Multi-Turn Coherence** | `mt` | 12 | expanded | | **Ambiguity Handling** | `ah` | 10 | expanded | | **Edge Case Extended** | `ex` | 12 | expanded | | **Total** | | **174** | |\n\n| Priority | Count | |----------|-------| | Critical | 11 | | High | 59 | | Medium | 93 | | Low | 11 |", "htmlHref": "/research/html/crp-1-2-expanded-evaluation-suite-174-questions-1x20wpf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 548 }, { "id": "t1-complete-auto-extract-knowledge-graph-juzh17", "title": "T1 Complete — Auto-Extract Knowledge Graph", "slug": "t1-complete-auto-extract-knowledge-graph", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/T1-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Status:** ✅ COMPLETE **Completed:** 2026-02-19T18:47 EST **Duration:** ~5 minutes extraction time (196K messages × 150+ regex patterns)", "excerpt": "**Status:** ✅ COMPLETE **Completed:** 2026-02-19T18:47 EST **Duration:** ~5 minutes extraction time (196K messages × 150+ regex patterns)\n\n| Metric | Before (v1) | After (v2) | Growth | |--------|------------|------------|--------| | **Nodes** | 70 | **270** | 3.9× | | **Edges** | 75 | **689** | 9.2× | | **Node types** | 9 | **13** | +4 new types | | **Relationship types** | ~15 | **30+** | 2× |\n\n| Type | Count | |------|-------| | technology | 121 | | project | 62 | | concept | 28 | | decision | 14 | | service | 12 | | channel | 10 | | machine | 6 | | location | 6 | | app | 4 | | person | 3 | | storefront | 2 | | agent | 1 | | architecture | 1 |\n\n| Relationship | Count | |-------------|-------| | uses | 273 | | co_used_with | 102 | | created | 63 | | related_to | 48 | | relates_to | 21 | | part_of | 15 | | decided | 14 | | built_with | 12 | | evolved_from | 12 | | contains | 11 |\n\n1. **Existing graph** (`data/expanded_graph.json`) — 70 seed nodes, ground truth 2. **Ledger DB** (`[home-path]`) — 196,917 messages across 5,934 sessions 3. **Knowledge Graph DB** (`[home-path]`) — 7,595 entities cross-referenced (37 high-quality ones added) 4. **Curated dictionaries** — 150+ regex patterns for technologies, projects, concepts, locations, machines", "htmlHref": "/research/html/t1-complete-auto-extract-knowledge-graph-juzh17.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 497 }, { "id": "t4-temporal-reasoning-layer-complete-14795yc", "title": "T4 — Temporal Reasoning Layer: COMPLETE ✅", "slug": "t4-temporal-reasoning-layer-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/T4-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Core capabilities: - **Natural language date parsing** — \"yesterday\", \"last week\", \"3 days ago\", \"February 2026\", \"Q1\", \"recently\", ISO dates - **Query classification** — 6 query types: activity, timeline, recency, duration, sequence, search - **Recency scoring** — Exponential decay with configurable half-life (default 30 days) - **Temporal ordering** — Results ranked by combined relevance × recency score - **Timeline generation** — Chronological event listing for any topic - **Temporal edge traversal** — preceded_", "excerpt": "**Completed:** 2026-02-19 **Status:** All deliverables shipped, 54/54 tests passing\n\n## Problem Eval showed 80% on temporal reasoning — weakest dimension. The knowledge graph and RAG had zero temporal metadata. No way to answer \"what were we working on last week?\" or \"when did we switch from X to Y?\"\n\n### 1. Temporal Retrieval Module **File:** `cognitive_twin/v3/tools/temporal_retrieval.py` (43KB, ~1100 lines)\n\nCore capabilities: - **Natural language date parsing** — \"yesterday\", \"last week\", \"3 days ago\", \"February 2026\", \"Q1\", \"recently\", ISO dates - **Query classification** — 6 query types: activity, timeline, recency, duration, sequence, search - **Recency scoring** — Exponential decay with configurable half-life (default 30 days) - **Temporal ordering** — Results ranked by combined relevance × recency score - **Timeline generation** — Chronological event listing for any topic - **Temporal edge traversal** — preceded_by, followed_by, concurrent_with, superseded_by\n\nKey classes: - `TemporalRetriever` — Main retrieval engine over graph + RAG - `TemporalRange` — Time range with start/end/granularity - `TemporalResult` / `TemporalQueryResult` — Structured result types - `parse_temporal_reference()` — NL date → TemporalRange - `classify_temporal_query()` — Query → type + params - `compute_recency_score()` — Exponential decay scoring", "htmlHref": "/research/html/t4-temporal-reasoning-layer-complete-14795yc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 738 }, { "id": "cognitive-twin-training-runbook-lxthx1", "title": "🧠 Cognitive Twin — Training Runbook", "slug": "cognitive-twin-training-runbook", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/TRAINING_RUNBOOK.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Platform | Model | Cost | Time | Quality | |----------|-------|------|------|---------| | **Mac4 Local** | gemma-3-1b-it (4-bit) | $0 | 5 min | ⭐⭐ (proof of concept) | | **Google Colab Pro** | gemma-3-12b-it (4-bit) | $0 (subscription) | 1-2h | ⭐⭐⭐⭐ | | **Together AI** | Qwen3-Next-80B-A3B | ~$16-20 | 2-4h | ⭐⭐⭐⭐⭐ | | **Together AI** | Qwen3-235B-A22B | ~$100-200 | 8-12h | ⭐⭐⭐⭐⭐⭐ (future) |", "excerpt": "> Repeatable pipeline for fine-tuning the Cognitive Twin on any platform. > Last updated: 2026-02-18\n\n| Platform | Model | Cost | Time | Quality | |----------|-------|------|------|---------| | **Mac4 Local** | gemma-3-1b-it (4-bit) | $0 | 5 min | ⭐⭐ (proof of concept) | | **Google Colab Pro** | gemma-3-12b-it (4-bit) | $0 (subscription) | 1-2h | ⭐⭐⭐⭐ | | **Together AI** | Qwen3-Next-80B-A3B | ~$16-20 | 2-4h | ⭐⭐⭐⭐⭐ | | **Together AI** | Qwen3-235B-A22B | ~$100-200 | 8-12h | ⭐⭐⭐⭐⭐⭐ (future) |\n\n### Data Location - **Train:** `Desktop/Comp-Core/packages/cognitive-twin/local_finetune/data/train.jsonl` (192MB, 16,360 records) - **Val:** `Desktop/Comp-Core/packages/cognitive-twin/local_finetune/data/valid.jsonl` (10MB, 909 records) - **Test:** `Desktop/Comp-Core/packages/cognitive-twin/local_finetune/data/test.jsonl` (10MB, 909 records)\n\n**⚠️ Gemma models require strict alternation:** `system? (user assistant)+` The merge script handles this automatically.\n\n### When to use - Quick iteration, testing data quality - Zero cost, ~5 minutes - Limited to 1B model (16GB RAM constraint)", "htmlHref": "/research/html/cognitive-twin-training-runbook-lxthx1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1179 }, { "id": "comp-core-source-of-truth-13p0qjo", "title": "Comp-Core Source Of Truth", "slug": "comp-core-source-of-truth", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/00-COMPCORE-SOURCE-OF-TRUTH.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This is the current grounding document for computational choreography. It follows the code and separates implemented runtime from research vocabulary.", "excerpt": "This is the current grounding document for computational choreography. It follows the code and separates implemented runtime from research vocabulary.\n\nThe implemented stack is not a single monolithic \"model.\" It is a set of runtime bridges and crates:\n\n> MotionMixApp gathers body and device signals, feeds them through the Rust > EchelonCore, reads latent/dynamics output, runs SAN and ClaimBridge, and uses > those outputs for audio, camera, training capture, and N'Ko motion inscriptions.\n\n- `EchelonBridge` is `@MainActor`. - Brain access is single-threaded by design. - Audio uses a separate `AudioHandle`. - `isEnabled` must be true or `step(dt)` returns immediately. - `SANService` is owned by `EchelonBridge`. - `ClaimBridgeService` runs after `echelon_get_dynamics_128`.\n\n- a pluggable `LatentUpdater`; - `SectionStateMachine`; - `LexiconController`; - sensor frame buffer; - current `LatentState`; - current `SectionState`; - current `Lexicon`; - current `UIState`; - `WindowAligner`; - `AnticipationAdapter`; - pose/gesture caches; - temporal integrator; - pocket FFT tempo source; - Femto skeleton encoder.", "htmlHref": "/research/html/comp-core-source-of-truth-13p0qjo.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1303 }, { "id": "128d-dynamics-vector-verified-contract-and-caveats-v17oeg", "title": "128D Dynamics Vector - Verified Contract And Caveats", "slug": "128d-dynamics-vector-verified-contract-and-caveats", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/03-latent-representation/128d-canonical-vector.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The old page described one universal \"canonical vector.\" The source is more complicated. There are several 128D-adjacent paths that overlap but are not identical.", "excerpt": "The old page described one universal \"canonical vector.\" The source is more complicated. There are several 128D-adjacent paths that overlap but are not identical.\n\n- `Desktop/Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/lib.rs` - `Desktop/Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/ffi.rs` - `Desktop/Comp-Core/core/audio-media/cc-echelon/crates/cc-brain/src/san/mod.rs` - `Desktop/MotionMixApp/MotionMixApp/Services/EchelonBridge.swift` - `Desktop/MotionMixApp/MotionMixApp/Services/MocopiFeatureExtractor.swift` - `Desktop/MotionMixApp/MotionMixApp/Services/SANTrajectoryLogger.swift` - `Desktop/MotionMixApp/MotionMixApp/Services/DiffusionService.swift`\n\nThis is the Rust-side dynamics vector. It is the base source for several Swift consumers.\n\n`EchelonBridge.getDynamics128()` calls `echelon_get_dynamics_128(...)`, then overlays Swift-side state:\n\n`flatten_latent(...)` writes a 128D vector from the Rust `LatentState` fields. Its comments reserve `[76:104]` for Swift-filled sensor fusion, but that function itself does not call `EchelonBridge.getDynamics128()`.", "htmlHref": "/research/html/128d-dynamics-vector-verified-contract-and-caveats-v17oeg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 642 }, { "id": "data-capture-current-verified-paths-1y3bcmm", "title": "Data Capture - Current Verified Paths", "slug": "data-capture-current-verified-paths", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/05-training-and-learning/data-capture.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This page documents what the current code can record. It does not claim that a specific training run has already consumed the data unless a run artifact is identified.", "excerpt": "This page documents what the current code can record. It does not claim that a specific training run has already consumed the data unless a run artifact is identified.\n\n- schema version; - dimensionality; - timestamp; - frame number; - optional bar number; - optional track name; - optional track time; - 128D input; - four audio parameter groups; - seven camera scores; - cut timing; - pattern intensity and variation; - phrase lifecycle; - gesture probabilities; - phase; - regime; - calibration confidence; - latency.\n\nThe logger captures SAN's flat input and SAN output at runtime. It is useful for:\n\n- replay analysis; - checking whether SAN output is flat or moving; - future supervised training; - comparing heuristic vs SAN-blended outputs; - correlating track metadata with body state.\n\n- the current SAN weights were trained from this session; - the session was accepted into a training set; - a train/validation split exists; - the model improved; - Rekordbox gestures worked; - mocopi, watch, and camera were all active.", "htmlHref": "/research/html/data-capture-current-verified-paths-1y3bcmm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3466 }, { "id": "san-training-status-verified-vs-unverified-ybq6s6", "title": "SAN Training Status - Verified vs Unverified", "slug": "san-training-status-verified-vs-unverified", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/05-training-and-learning/san-training-v5.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This page replaces the old \"SAN Training V5\" narrative. The old page stated dataset counts and validation loss as facts without pointing to local artifacts. The current rule is simple: training claims need files.", "excerpt": "This page replaces the old \"SAN Training V5\" narrative. The old page stated dataset counts and validation loss as facts without pointing to local artifacts. The current rule is simple: training claims need files.\n\nThis proves there is a local SAN weight artifact compatible with the binary manifest loader. It does not prove the training dataset, validation loss, or model quality by itself.\n\n- \"V5 is 135,000 parameters.\" - \"V5 trained on 5,408 real performance pairs.\" - \"Validation loss was 0.028.\" - \"Training ran from `/Volumes/HD1/training-phrases/train_san_v5.py`.\" - \"The current deployed weights are from that exact run.\"\n\nThey may be historically true, but this documentation set is now source-grounded. Historical claims need a training log, run directory, manifest, or checkpoint note.\n\n`Desktop/MotionMixApp/MASTER-TASKS.md` is more cautious than the old docs. At that checkpoint it says:", "htmlHref": "/research/html/san-training-status-verified-vs-unverified-ybq6s6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 559 }, { "id": "comp-core-lume-cc-nko-unification-1tn46tn", "title": "Comp-Core / LUME CC / N'Ko Unification", "slug": "comp-core-lume-cc-nko-unification", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "computational-choreography/07-nko-synthesis/comp-core-lumecc-nko-unification.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document is the correction layer for the computational choreography package. It aligns the choreography docs with the actual implementation in Comp-Core, MotionMixApp, and the N'Ko audio/ASR work.", "excerpt": "This document is the correction layer for the computational choreography package. It aligns the choreography docs with the actual implementation in Comp-Core, MotionMixApp, and the N'Ko audio/ASR work.\n\nThese are connected lanes. They are not the same model, and the docs should not pretend they are.\n\n- MotionMixApp `EchelonBridge.swift` - Comp-Core `core/audio-media/cc-echelon/` - Rust `cc-brain` - SAN / Echelon dynamics - `echelon_get_dynamics_128` - audio bridge and real-time synth controls - `SANTrajectoryLogger` for training capture\n\nIts job is to turn body state into a stable real-time latent representation that can drive music, visual state, camera behavior, training capture, and inscription.\n\n- MotionMixApp `ClaimBridgeService.swift` - Rust `cc-brain/src/san/claim_bridge.rs` - Rust FFI in `cc-brain/src/ffi.rs` - `cc-inscription` - Convex `inscriptions.ts` - Comp-Core `docs/nko-ecosystem/` - Comp-Core `docs/motion-language/`", "htmlHref": "/research/html/comp-core-lume-cc-nko-unification-1tn46tn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 925 }, { "id": "implementation-confirmation-maoe-vs-trajectory-bias-17pjms9", "title": "Implementation Confirmation - MAOE vs Trajectory Bias", "slug": "implementation-confirmation-maoe-vs-trajectory-bias", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "computational-choreography/07-nko-synthesis/implementation-confirmation.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "You were right: the verified N'Ko ASR number comes from the anticipatory / trajectory-biased Transformer CTC model, not from MAOE routing.", "excerpt": "You were right: the verified N'Ko ASR number comes from the anticipatory / trajectory-biased Transformer CTC model, not from MAOE routing.\n\n- `Desktop/nko-brain-scanner/HANDOFF.md` - `Desktop/nko-brain-scanner/asr/trajectory_asr.py` - `Desktop/nko-brain-scanner/constrained/trajectory_bias.py` - `Desktop/MAOE-NKo-Technical-Architecture.md`\n\n- model: N'Ko Trajectory CTC - checkpoint family: Paper 4 reproduction - reported held-out result: 20.57% CER - architecture: `UnifiedCTCHead` - decoder: 6-layer Transformer - key mechanism: trajectory-bias injection - trajectory components: - `AudioTrajectoryScalars` - `TrajectoryBiasNetwork` - `TrajectoryTransformerLayer`\n\nMAOE is not the acoustic model that produced the verified ASR checkpoint. In the current local architecture, MAOE is the routed correction and admissibility layer around the ASR anchor.\n\n- `partition_policy.py`: classifies ASR telemetry into `stable`, `boundary`, `uncertain`, `recovery`, or `novelty`. - `expert_router.py`: maps each partition to an expert lane and safety contract. - Rust/admissibility layer: decides whether a proposed correction is allowed.", "htmlHref": "/research/html/implementation-confirmation-maoe-vs-trajectory-bias-17pjms9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 437 }, { "id": "maoe-routing-1wcmn4i", "title": "MAOE Routing", "slug": "maoe-routing", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "computational-choreography/07-nko-synthesis/maoe-routing.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "MAOE means Mixture of Anticipatory Orthogonal Experts. In this project it should be documented as a routing/correction pattern, not as the verified ASR acoustic anchor.", "excerpt": "MAOE means Mixture of Anticipatory Orthogonal Experts. In this project it should be documented as a routing/correction pattern, not as the verified ASR acoustic anchor.\n\n- `Desktop/nko-brain-scanner/asr/trajectory_asr.py` - `Desktop/nko-brain-scanner/constrained/trajectory_bias.py`\n\n- `Desktop/Comp-Core/experiments/agp_mlx/asr_bridge/partition_policy.py` - `Desktop/Comp-Core/experiments/agp_mlx/asr_bridge/expert_router.py`\n\nMAOE is important because N'Ko and embodied motion both need authority control. When evidence is stable, preserve it. When evidence is uncertain, limit repairs. When evidence is novel, prevent a generic model from normalizing it away.\n\n- EchelonCore; - LatentUpdater; - SANPipeline; - BodyTruth; - AirDeck safety; - ClaimBridge.", "htmlHref": "/research/html/maoe-routing-1wcmn4i.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 311 }, { "id": "claim-audit-2026-05-27-1qyaexg", "title": "Claim Audit - 2026-05-27", "slug": "claim-audit-2026-05-27", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/09-reference/claim-audit-2026-05-27.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This audit records the corrections made after reviewing the computational choreography docs against MotionMixApp and Comp-Core source.", "excerpt": "This audit records the corrections made after reviewing the computational choreography docs against MotionMixApp and Comp-Core source.\n\nThe old docs over-presented research vocabulary as deployed architecture. The rewritten docs now separate:\n\n- verified runtime code; - local artifacts; - research terms; - future training plans; - philosophical framing.\n\nUser memory was correct: the current MotionMixApp generation path is better described as a conditioning encoder plus one-step flow path.\n\n- `MotionMixApp/Services/DiffusionService.swift` - `MotionMixApp/MLModels/ConditioningEncoder.mlpackage` - `MotionMixApp/MLModels/FlowGenerator1Step.mlpackage` - `MotionMixApp/MASTER-TASKS.md` - `MotionMixApp/CLAUDE.md`", "htmlHref": "/research/html/claim-audit-2026-05-27-1qyaexg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 663 }, { "id": "critical-files-d8fdas", "title": "Critical Files", "slug": "critical-files", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/09-reference/critical-files.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This page lists files that are critical because source inspection shows they own runtime contracts. It avoids stale claims about parameter counts or training runs.", "excerpt": "This page lists files that are critical because source inspection shows they own runtime contracts. It avoids stale claims about parameter counts or training runs.\n\n| File | Why it matters | | --- | --- | | `MotionMixApp/Services/EchelonBridge.swift` | Main Swift coordinator. Owns Rust brain/audio handles, SANService, ClaimBridgeService, sensor queues, and dynamics overlays. | | `MotionMixApp/Services/SANService.swift` | Swift wrapper for Rust SAN FFI. Loads `san_weights.bin` and `san_manifest.json`; owns `SANTrajectoryLogger`. | | `MotionMixApp/Services/SANTrajectoryLogger.swift` | Schema-v2 body/SAN capture logger. Writes `Documents/san-training/.jsonl`; can push NDJSON to K11. | | `MotionMixApp/Services/DiffusionService.swift` | CoreML/phone-hub/fallback generation service. Uses `ConditioningEncoder` and `FlowGenerator1Step` when available. | | `MotionMixApp/Services/ClaimBridgeService.swift` | Swift wrapper for Rust ClaimBridge. Converts Echelon dynamics into controlled motion inscription claims. | | `MotionMixApp/Services/MocopiFeatureExtractor.swift` | Compresses mocopi skeletons into the app's 24D feature slice and pose stats. | | `MotionMixApp/Services/LiveStreamServer.swift` | Camera-node HTTP surface. | | `MotionMixApp/Services/NodeAdvertiser.swift` | Bonjour camera-node advertisement. | | `MotionMixApp/Services/CameraService.swift` | AVCapture session and capture pipeline. | | `MotionMixApp/Frameworks/libechelon_ios.a` | Rust static library consumed by iOS. | | `MotionMixApp/Resources/san_weights.bin` | Current SAN weight binary. Training provenance must be documented separately. | | `MotionMixApp/Resources/san_manifest.json` | SAN weight manifest. Current local audit: 76 tensors, 164,248 parameters. | | `MotionMixApp/MotionMixApp.swift` | App entry and service wiring. |\n\n| File | Why it matters | | --- | --- | | `MotionMixApp/MLModels/ConditioningEncoder.mlpackage` | CoreML encoder used by `DiffusionService`; current Swift shim feeds a 104D input prefix. | | `MotionMixApp/MLModels/FlowGenerator1Step.mlpackage` | CoreML one-step flow/token generator used after the conditioning embedding. | | `MotionMixApp/Models/MotionToMusic.mlpackage` | Separate model artifact; do not confuse it with SAN or the one-step flow lane without checking call sites. |\n\n| File | Why it matters | | --- | --- | | `core/audio-media/cc-echelon/crates/cc-brain/src/lib.rs` | Root of the Rust brain crate and public exports. | | `core/audio-media/cc-echelon/crates/cc-brain/src/ffi.rs` | C FFI contract used by Swift. | | `core/audio-media/cc-echelon/crates/cc-brain/src/latent/mod.rs` | `LatentUpdater` trait and backend exports. | | `core/audio-media/cc-echelon/crates/cc-brain/src/latent/simple.rs` | Simple latent updater path. | | `core/audio-media/cc-echelon/", "htmlHref": "/research/html/critical-files-d8fdas.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 734 }, { "id": "mega-serials-start-cl85x-1g2k4o2", "title": "Mega serials start CL85x...", "slug": "mega-serials-start-cl85x", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "FEMTO-MEGA-VS-BOLT-RUNBOOK-2026-05-12.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "And also give me a script for both of them on how I should go about doing that for both of the reels on how I'm explaining the process, since we didn't have a live director, we'll just say# Femto Mega vs Femto Bolt — Differentiation + MediaPipe Setup Runbook", "excerpt": "And also give me a script for both of them on how I should go about doing that for both of the reels on how I'm explaining the process, since we didn't have a live director, we'll just say# Femto Mega vs Femto Bolt — Differentiation + MediaPipe Setup Runbook\n\n**Last verified state:** 2026-05-10 21:00Z (pairing plan), tasks #234-#247 closed.\n\nMac4 carries the dev rig with **Femto Mega**. K11 carries the bar product install with **Femto Bolt**. Both run the same pipeline: RGB feed in → MediaPipe BlazePose → 33 landmarks → echelon-bar Rust → LUMA UDP :9703 → Unity visuals. The cameras differ in physical form factor and lens characteristics, not in software path. This doc nails down what makes each one its own thing and how MediaPipe gets wired on K11.\n\n| Spec | Femto Mega | Femto Bolt | |---|---|---| | Form factor | Larger, dev-friendly mount | Smaller, install-friendly | | Onboard compute | Jetson NX (does depth + Ethernet stream + multi-device sync) | No onboard compute (host does everything) | | Connection | USB-C **OR** PoE Gigabit Ethernet | USB-C only | | Depth tech | iToF (indirect time of flight) | iToF | | Depth range | 0.25–5.46 m | 0.25–2.88 m (NFOV) / 0.25–5.46 m (WFOV) | | Depth resolution | up to 1024×1024 @ 30fps | up to 1024×1024 @ 30fps | | RGB resolution | 4K (3840×2160) @ 30fps | 4K (3840×2160) @ 30fps | | Field of view (RGB) | 80° H × 51° V | 80° H × 51° V | | Field of view (depth) | 120° × 120° (WFOV NFOV unbinned) | 120° × 120° (WFOV) | | IMU | Yes (BMI2x0) | Yes (BMI2x0) | | Audio mic array | 6-mic array | 7-mic array | | Power | PoE 802.3af or USB-C | USB-C | | Use case | Mac4 dev rig: tethered, big surface area, multi-device sync ready | K11 bar install: mounted in the room, minimal cabling |\n\n**One-line difference:** Mega has a brain on board and can talk Ethernet. Bolt is dumber and smaller. For our pipeline neither matters — we only use the RGB feed and run MediaPipe on the host.", "htmlHref": "/research/html/mega-serials-start-cl85x-1g2k4o2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1727 }, { "id": "pulse-local-skill-1sil1ij", "title": "Pulse Local Skill", "slug": "pulse-local-skill", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/bot:pulse/SKILL.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Pulse runs autonomous development loops that iterate toward a goal without constant human intervention. This skill executes iterations locally via Claude Code subprocess, with iMessage notifications through Clawdbot.", "excerpt": "--- name: bot:pulse description: Manages Pulse autonomous development sessions with local execution via Claude Code homepage: https://github.com/diomandeee/comp-core user-invocable: true command-dispatch: pulse metadata.clawdbot: {\"local_execution\": true} manifest: inputs: [project_path, development_goal, max_iterations] outputs: [session_id, iteration_results, commit_hashes, completion_status] chains_with: [bot:dream-weaver, sys:plan, evo:evolve, tie:dist] triggers: [pulse, autonomous, develop, iterate, implement, execute] can_spawn_pulse: true ---\n\nPulse runs autonomous development loops that iterate toward a goal without constant human intervention. This skill executes iterations locally via Claude Code subprocess, with iMessage notifications through Clawdbot.\n\n| Command | Description | |---------|-------------| | `/pulse @project \"goal\"` | Start an autonomous Pulse session | | `/pulse:status [id]` | Check session progress | | `/pulse:pause ` | Pause a running session | | `/pulse:resume ` | Resume a paused session | | `/pulse:abort ` | Stop a session | | `/pulse:list` | List recent sessions | | `/pulse:context ` | View full session context |\n\n1. User defines a development goal 2. Pulse runs iterations autonomously (up to 10 by default) 3. Each iteration: analyze -> implement -> test -> commit -> signal 4. Signals determine flow: - `CONTINUE` - keep iterating toward goal - `COMPLETE` - goal achieved, session ends - `BLOCKED` - needs human input 5. User notified via iMessage after each iteration\n\nThis will: 1. Resolve project path (Desktop/my-project or similar) 2. Create session in [home-path] 3. Start background loop runner 4. Execute iterations via `claude --print` subprocess 5. Send iMessage notifications on progress", "htmlHref": "/research/html/pulse-local-skill-1sil1ij.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 720 }, { "id": "failure-museum-g8sq2q", "title": "🏛️ Failure Museum", "slug": "failure-museum", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/failure-museum/SKILL.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The Failure Museum operates on a radical premise: **failed ideas are assets, not liabilities**. They contain: - **Timing errors** — right idea, wrong moment - **Hidden gems** — valuable fragments buried in flawed wholes - **Learning signals** — what the environment wasn't ready for - **Resurrection candidates** — waiting for context to change", "excerpt": "The Failure Museum operates on a radical premise: **failed ideas are assets, not liabilities**. They contain: - **Timing errors** — right idea, wrong moment - **Hidden gems** — valuable fragments buried in flawed wholes - **Learning signals** — what the environment wasn't ready for - **Resurrection candidates** — waiting for context to change\n\n### 💎 Gem Tracker (NEW) Track when museum lessons are actually used and measure their impact.\n\n**Impact Levels:** | Status | Meaning | |--------|---------| | 💤 Dormant | Never applied | | 🌱 Seeding | 1-2 applications | | ⭐ Low | Applied but poor outcomes | | ⭐⭐ Medium | Applied with mixed results | | ⭐⭐⭐ HIGH | Applied successfully 3+ times |\n\n### 🔍 Closure Detector (NEW) Catches overconfident statements before they become museum exhibits.\n\n**Closure Types Detected:** | Type | Example | Risk | |------|---------|------| | `absolute_negative` | \"It doesn't exist\" | 9/10 | | `comprehensive_claim` | \"Here's everything\" | 8/10 | | `identity_assertion` | \"You are X\" | 5-8/10 | | `capability_denial` | \"I can't do that\" | 4-8/10 | | `temporal_closure` | \"That will never work\" | 9/10 | | `certainty_marker` | \"Absolutely certain\" | 5-8/10 |", "htmlHref": "/research/html/failure-museum-g8sq2q.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1153 }, { "id": "memory-defrag-1f8131e", "title": "Memory Defrag 🧠🔧", "slug": "memory-defrag", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/memory-defrag/SKILL.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Memory Defrag is your AI-powered note janitor. It scans your memory files, finds duplicates and related content, suggests consolidations, and helps reorganize your second brain.", "excerpt": "--- name: memory-defrag description: AI that reorganizes your notes, finds duplicates, suggests consolidation - keep your second brain clean homepage: https://github.com/clawdbot user-invocable: true command-dispatch: defrag metadata.clawdbot: {\"version\": \"2.0.0\", \"hef_generation\": 6} ---\n\nMemory Defrag is your AI-powered note janitor. It scans your memory files, finds duplicates and related content, suggests consolidations, and helps reorganize your second brain.\n\n### 🔗 Reference Graph - Detects `[[wiki-links]]`, `@mentions`, and file paths - Maps connections between notes - Identifies truly isolated content\n\n### 📈 Growth Trends - Tracks memory growth over time - Visualizes word count and health trends - Helps identify documentation patterns\n\n### 🌱 Freshness Decay - Exponential decay model for content freshness - Highlights stale areas needing attention - Smarter orphan detection", "htmlHref": "/research/html/memory-defrag-1f8131e.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1146 }, { "id": "posture-compiler-skill-m38vr", "title": "Posture Compiler Skill", "slug": "posture-compiler-skill", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/posture-compiler/SKILL.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Your body position shapes your mind. This skill compiles posture + environment + biofeedback + history into a rich AI interaction mode.", "excerpt": "Your body position shapes your mind. This skill compiles posture + environment + biofeedback + history into a rich AI interaction mode.\n\n> **Embodiment is computation.** Your body is an input device, your environment is a context flag, and your history is a learning signal.\n\n| Feature | Description | |---------|-------------| | **Cognitive Weather** | Single metaphor for your full mental state (☀️ Sunny, ⛈️ Storming, ⚡ Electric...) | | **Anti-Pattern Detection** | Warns about harmful habits (marathon sitting, stress spirals, dehydration) | | **Posture Playlists** | Composable, shareable posture sequences with goals and music moods | | **Body Budget** | Holistic physical wellness: hydration, breaks, eye rest, posture variety | | **Mode Blending** | Smooth interpolation between modes during transitions (no jarring switches) |\n\n| Weather | Emoji | When | |---------|-------|------| | **Electric** | ⚡ | Peak energy + deep flow — on fire | | **Sunny** | ☀️ | High energy, good focus, productive | | **Breezy** | 🌤️ | Light, creative, ideas flowing | | **Clear** | 🌥️ | Focused and steady, not peak but good | | **Cloudy** | ☁️ | Energy dipping, needs a change | | **Foggy** | 🌫️ | Depleted, unclear — rest needed | | **Storming** | ⛈️ | Stressed, overwhelmed | | **Twilight** | 🌙 | Winding down, reflective |\n\nIncludes cognitive temperature (0-100°), wind (rate of change), and a near-term forecast.", "htmlHref": "/research/html/posture-compiler-skill-m38vr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1685 }, { "id": "claude-md-3buglx", "title": "CLAUDE.md", "slug": "claude-md", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "karl/CLAUDE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "KARL (Knowledge Agents via Reinforcement Learning) records what AI coding agents do during real work sessions as trajectories, scores them with a multi-signal reward engine, and uses the best trajectories for LoRA fine-tuning via MLX. It also provides vector-based skill routing that shadows and can replace regex routing.", "excerpt": "This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\nKARL (Knowledge Agents via Reinforcement Learning) records what AI coding agents do during real work sessions as trajectories, scores them with a multi-signal reward engine, and uses the best trajectories for LoRA fine-tuning via MLX. It also provides vector-based skill routing that shadows and can replace regex routing.\n\nThe extended CLI lives in `karl/karl_cli.py` (67 commands). The simpler `karl/cli.py` is the pip-installed entry point (`karl` command) with 10 core subcommands.\n\nThe system records agent sessions through 4 tap points in `trajectory_tap.py`: 1. **Tap A** - `init_session_buffer()`: Start recording, run shadow skill routing 2. **Tap B** - `append_tool_event()`: Log each tool call (name, params, success) 3. **Tap C** - `flush_session()`: End recording, compute reward, write to `trajectories.jsonl` 4. **Tap D** - `annotate_previous()`: Detect corrections on next prompt, update prior trajectory\n\n`reward_engine.py` computes composite scores. Note: the README documents 3 signals with weights 0.40/0.35/0.25, but the actual code uses 5 signals: - Outcome (0.30), Process (0.25), Efficiency (0.15), Verification (0.15), Consistency (0.15)", "htmlHref": "/research/html/claude-md-3buglx.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 499 }, { "id": "karl-trajectory-memory-ledger-1p6zgat", "title": "KARL - Trajectory Memory Ledger", "slug": "karl-trajectory-memory-ledger", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "karl/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "KARL is the reference implementation of the Trajectory Memory Ledger: a schema-normalized experience replay layer for AI coding agents. It records what an agent does during real work sessions, normalizes those recordings into a schema-v2 trajectory store, scores them with a six-signal reward engine, and uses the highest-scoring trajectories to improve future performance through LoRA fine-tuning and learned skill routing.", "excerpt": "KARL is the reference implementation of the Trajectory Memory Ledger: a schema-normalized experience replay layer for AI coding agents. It records what an agent does during real work sessions, normalizes those recordings into a schema-v2 trajectory store, scores them with a six-signal reward engine, and uses the highest-scoring trajectories to improve future performance through LoRA fine-tuning and learned skill routing.\n\nBased on the Trajectory Memory Ledger paper ([arXiv 2603.05218](https://arxiv.org/abs/2603.05218)).\n\nThe trajectory store grows over time. The current normalized store contains 7,468 scored trajectories, 67,409 observed tool events, and 73,470 recovered tool steps. The best trajectories are exported as advantage-weighted SFT data and used to train a LoRA adapter via MLX; the current export contains 3,678 ChatML examples split into 3,310 train and 368 validation rows.\n\n| Signal | Weight | Measures | |--------|--------|----------| | **Outcome** | 25% | Was the user satisfied? No correction, no redo, build passed, session continued | | **Process** | 22% | Did tools work? Success rate, bash exit codes, error density | | **Efficiency** | 13% | Was it efficient? Tool diversity, duration efficiency, file touch rate | | **Verification** | 13% | Did the agent check its own work? Tests, builds, read-after-write | | **Consistency** | 13% | Was the tool order coherent? Low thrash, enough context before mutation | | **Wasted motion** | 14% | Did the trajectory avoid repeated loops and unnecessary retries? |\n\nComposite reward is `[0, 1]`. Advantage = reward - domain baseline, used for OAPL-Lite oversampling. On the normalized corpus, mean reward is 0.6632 and the reward range is 0.4666-0.8165.", "htmlHref": "/research/html/karl-trajectory-memory-ledger-1p6zgat.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1409 }, { "id": "lim-rps-as-constraint-y3v4n1", "title": "LIM-RPS as Constraint", "slug": "lim-rps-as-constraint", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "LUME-CC/01-foundation/lim-rps-constraint.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The name is technical but the principle is artistic: LUME's visual and musical responses must be bounded, memoryful, multimodal, and synthesizing. This is the difference between a sensor spike and a choreographic response.", "excerpt": "The name is technical but the principle is artistic: LUME's visual and musical responses must be bounded, memoryful, multimodal, and synthesizing. This is the difference between a sensor spike and a choreographic response.\n\nOutputs cannot change arbitrarily fast. Every primitive, template, and effect has an attack and release rate. If the wave target jumps from 0.0 to 1.0, the actual value moves toward it at a controlled rate. If burst falls, it decays rather than disappearing in one frame.\n\nThis prevents sensor jitter from becoming visual violence. It gives the visuals the musical quality of attack, sustain, and release. A hand moving fast produces an increase in wave that builds and then settles. A sensor dropout does not immediately blank the visual. The body is heard as a continuous voice, not a series of disconnected shouts.\n\nThe system does not use one rigid table that maps a single gesture to a single effect. Instead, it evaluates a continuous field. BodyTruth, primitives, templates, memory, and confidence become effect weights. Color shift, pressure glow, wall bend, ribbon impulse, calm field, contour focus, fluid impulse, and spark damping emerge from that map.\n\nThe result is more like a mixer than a switchboard. Multiple body qualities contribute simultaneously. A moment that is 0.6 wave and 0.4 lean produces a different visual than 0.9 wave and 0.0 lean. The aesthetic richness comes from this continuous composition, not from a discrete command system.", "htmlHref": "/research/html/lim-rps-as-constraint-y3v4n1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 632 }, { "id": "lume-chain-1-echelon-layer-4-128d-temporal-closure-irnpgw", "title": "LUME Chain 1 — Echelon Layer 4 + 128D Temporal Closure", "slug": "lume-chain-1-echelon-layer-4-128d-temporal-closure", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/chains/RELEASE-CHAIN-1.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Status:** RELEASED (plan + patches ready to apply, live verification pending) **Subject:** Close the body-time loop in MotionMix Echelon **Started:** 2026-05-08 **Released:** 2026-05-08 **Chain owner:** Mohamed **Execution model:** META:OMEGA + META:HYDRA collapsed (single pass), 8-lens reviewed", "excerpt": "**Status:** RELEASED (plan + patches ready to apply, live verification pending) **Subject:** Close the body-time loop in MotionMix Echelon **Started:** 2026-05-08 **Released:** 2026-05-08 **Chain owner:** Mohamed **Execution model:** META:OMEGA + META:HYDRA collapsed (single pass), 8-lens reviewed\n\nThis release bundles a VALIDATED PLAN + READY-TO-APPLY PATCHES for closing the body-time loop in the MotionMix Echelon engine. It does NOT contain a fully shipped + verified live system. Live verification is gated on Codex / Mohamed applying the patches on Mac4 + running the live test on iPhone 16.\n\n1. `state.phase` is never written by `SimpleLatentUpdater`. Source: `cc-brain/src/latent/simple.rs:166-178`. Slot [70] of the 128D vector is dead-zero. 2. Backend enum dispatch is INVERTED between Swift and Rust. Source: `EchelonBridge.swift:62-65` (Swift declares `simple=0, learned=1, dell=2`) vs `cc-brain/src/ffi.rs:348-351` (Rust dispatches `1 => DELL, _ => Simple`). `Backend.learned` makes a DELL core. `LearnedLatentUpdater` is unreachable from iOS. 3. EchelonBridge slot index mismatch. Source: `EchelonBridge.swift:397-404` (`getTemporalState` reads `[69, 70, 71]` as `(tempo, confidence, phase)` but Rust writes `(tempo, phase, periodicity)` per `san/mod.rs:85-87`).\n\nPlus one architectural module (`TemporalIntegrator`) and one supporting module (`PocketFFT`) are needed to give the system a single source of truth for body-time.\n\n| # | Criterion | Verification status | |---|-----------|---------------------| | 1 | 128D[70] state.phase non-zero during body motion | **PATCH READY** (`patches/phase-2/01-state-phase-population.patch` writes phase from autocorrelation + dt-aware advancement). Live verification BLOCKED on patch application + on-device run. | | 2 | iOS default path uses LearnedLatentUpdater (with safe fallback) | **PATCH READY** (`patches/phase-3/01-rust-backend-enum-fix.patch` + `patches/phase-3/03-default-path-swap.patch`). Backend enum fix is independent and ships first; default-path swap gated behind `simple-default` cargo feature for instant rollback. Live verification BLOCKED on patch application + iOS rebuild. | | 3 | Body-driven audio output verified live | **BLOCKED on live capture** (Mac4 + iPhone 16 + ShootView rig). Patches do not address this gate; this is a human-in-loop verification per Lens 6 E-3. | | 4 | No DELL 150 BPM imposition | **DEFERRED to Phase 5** (intentionally not in this collapsed run; bar-event queue from Phase 2 is the prerequisite, and the Phase 5 patch consumes it). | | 5 (added by Excavation) | EchelonBridge `getTemporalState` reads slots in correct order | **PATCH READY** (`patches/phase-2/05-swift-bridge-temporal-state.patch` switches Swift to the explicit `echelon_get_temporal_state` FFI which returns `(tempo, con", "htmlHref": "/research/html/lume-chain-1-echelon-layer-4-128d-temporal-closure-irnpgw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1115 }, { "id": "lume-chain-3-closed-loop-integration-body-iphone-echelon-audio-bridge-mac4-lumf-sky-ga-igeiq2", "title": "LUME Chain 3 — Closed-Loop Integration: Body → iPhone (Echelon) → Audio Bridge → Mac4 LUMF → Sky Garden Visuals", "slug": "lume-chain-3-closed-loop-integration-body-iphone-echelon-audio-bridge-mac4-lumf-sky-garden-visuals", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/chains/RELEASE-CHAIN-3.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Status:** RELEASED (plan + scripts ready, live verification pending) **Subject:** Performer body conducts BOTH the audio AND the visuals simultaneously. Chain 3 closes the loop between Chain 1 (released, body→audio) and Chain 2 (released, body-aware visuals) by routing iPhone-generated Echelon audio onto Mac4's LUMF publisher so the existing visual-side `LumeAudioFftReceiver` consumes it. **Started:** 2026-05-08 **Released:** 2026-05-08 **Chain owner:** Mohamed **Execution model:** META:OMEGA + META:HYDRA collaps", "excerpt": "# LUME Chain 3 — Closed-Loop Integration: Body → iPhone (Echelon) → Audio Bridge → Mac4 LUMF → Sky Garden Visuals\n\n**Status:** RELEASED (plan + scripts ready, live verification pending) **Subject:** Performer body conducts BOTH the audio AND the visuals simultaneously. Chain 3 closes the loop between Chain 1 (released, body→audio) and Chain 2 (released, body-aware visuals) by routing iPhone-generated Echelon audio onto Mac4's LUMF publisher so the existing visual-side `LumeAudioFftReceiver` consumes it. **Started:** 2026-05-08 **Released:** 2026-05-08 **Chain owner:** Mohamed **Execution model:** META:OMEGA + META:HYDRA collapsed (single pass), 8-lens reviewed **Prerequisites:** - Chain 1 (Echelon Layer 4 + 128D Temporal Closure) released same day, see `docs/chains/RELEASE-CHAIN-1.md`. **Live verification of Chain 1 is REQUIRED before Chain 3 setup scripts are run.** - Chain 2 (Sky Garden Duncan-parity push) released same day, see `docs/chains/RELEASE-CHAIN-2.md`. **Live verification of Chain 2 is REQUIRED before Chain 3 setup scripts are run.**\n\nA VALIDATED PLAN + READY-TO-RUN SETUP SCRIPTS for closing the body→music→visuals loop on the LUME rig. It does NOT contain a live-verified integrated system. Live verification is gated on: 1. Chain 1 patches APPLIED + verified (iPhone audio measurably tracks body skeleton) 2. Chain 2 patches APPLIED + verified (Sky Garden reads as Duncan-family at 1080p60) 3. Chain 3 setup scripts run on Mac4 (audio bridge installed + routed + verified) 4. 60-second demo cut MP4 captured per the runbook\n\nThis chain is **mostly plumbing** — config, setup scripts, and a small handful of integration patches. The novelty is at the SYSTEM level (body conducting both audio and visuals) rather than at the bridge level.\n\nAfter 8-lens review (`Desktop/omega-output/closed-loop-integration-20260508/03-review.md`):", "htmlHref": "/research/html/lume-chain-3-closed-loop-integration-body-iphone-echelon-audio-bridge-mac4-lumf-sky-ga-igeiq2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1548 }, { "id": "lume-chain-4-music-v6-retrain-pipeline-mode-emotion-conditioning-850apd", "title": "LUME Chain 4 — Music V6 Retrain Pipeline (mode + emotion conditioning)", "slug": "lume-chain-4-music-v6-retrain-pipeline-mode-emotion-conditioning", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/chains/RELEASE-CHAIN-4.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Status:** RELEASED (validated plan + capture protocol + retrain scripts; live training NOT executed) **Subject:** Replace V5 (2-track) ConditioningEncoder + FlowGenerator1Step with V6 trained on 30-track diverse capture data, conditioned on (LUME mode, emotion) so each Sky Garden / Turquoise Alcove / Radiant Underground / Iridescent Beauty / Aurora Veil produces its own music character. V6 also consumes full 128D dynamics (closes the V5 truncation shim at DiffusionService.swift line ~258). **Started:** 2026-05-08", "excerpt": "**Status:** RELEASED (validated plan + capture protocol + retrain scripts; live training NOT executed) **Subject:** Replace V5 (2-track) ConditioningEncoder + FlowGenerator1Step with V6 trained on 30-track diverse capture data, conditioned on (LUME mode, emotion) so each Sky Garden / Turquoise Alcove / Radiant Underground / Iridescent Beauty / Aurora Veil produces its own music character. V6 also consumes full 128D dynamics (closes the V5 truncation shim at DiffusionService.swift line ~258). **Started:** 2026-05-08 **Released:** 2026-05-08 **Chain owner:** Mohamed **Execution model:** META:OMEGA + META:HYDRA collapsed (single pass), 8-lens reviewed **Prerequisites:** - Chain 1 (Echelon Layer 4 + 128D Temporal Closure) — released, see `RELEASE-CHAIN-1.md`. **Live verification of Chain 1 is REQUIRED before V6 .mlpackages get deployed (the dispatch fixes are upstream of any model swap)** - HD1 mounted on Mac4 with `/Volumes/HD1/training-phrases/v6/` writable - iPhone 16 Pro Max + iPhone 16 Plus available for capture sessions - Mac5 (Tailscale `[ip]`) accessible for training jobs\n\nA VALIDATED PLAN + CAPTURE PROTOCOL + READY-TO-RUN RETRAIN SCRIPTS. It does NOT contain trained V6 weights or deployed V6 models. Live execution is gated on:\n\n1. 30 capture sessions × 15 min run by a human dancer (~7.5 hours over 1 week) 2. Mac5 GPU running ConditioningEncoder + FlowGenerator retrain (~30 min + 4-8 hours overnight) 3. CoreML export to .mlpackage (15 min) 4. iOS smoke test + deploy + on-device verification (1 hour)\n\nWhen all 4 are green and V6-ACCEPTANCE.md hard gates pass, Chain 4 transitions from RELEASED to FULLY SHIPPED.\n\nThis chain is **training-data + ML** — the novelty is in DATASET DIVERSITY + CONDITIONING SCHEMA, not architecture. FlowGenerator1Step architecture is unchanged from V5; only its inputs are.", "htmlHref": "/research/html/lume-chain-4-music-v6-retrain-pipeline-mode-emotion-conditioning-850apd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 862 }, { "id": "lume-multi-sensor-motion-fusion-phased-plan-seu5xt", "title": "LUME Multi-Sensor Motion Fusion — Phased Plan", "slug": "lume-multi-sensor-motion-fusion-phased-plan", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/LUME_MULTI_SENSOR_FUSION_PLAN.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The plan to go from **one camera** (today) to **four fused pose sources**: K11 Femto Bolt + Mac4 Femto Mega + 2 iPhones running MotionMix.", "excerpt": "The plan to go from **one camera** (today) to **four fused pose sources**: K11 Femto Bolt + Mac4 Femto Mega + 2 iPhones running MotionMix.\n\nThe bar opens **single performer, single Bolt**. One camera = one timeline, no fusion, no clock sync required. This entire plan is the post-launch \"smarter track.\" The trigger to begin Phase 1 is: **the bar has launched on the single Bolt and is stable.** Starting earlier is the scope-creep we explicitly cut.\n\n| Source | State | |---|---| | K11 Femto Bolt | ✅ Live — pyorbbecsdk COLOR_SENSOR → MediaPipe BlazePose → emits canonical pose JSON on UDP 9705, LUMM 27-bone on 9702, MJPG recording. Verified 2026-05-19. | | Mac4 Femto Mega | ❌ No pose. Orbbec RGB is not a UVC webcam; needs the pyorbbecsdk-color path (same fix already proven on the Bolt). | | iPhone ×2 (MotionMix) | ❌ Not wired. MotionMix does on-device pose but keeps it for its own synth. |\n\n**Canonical capture-node contract** (frozen — the Bolt publisher already emits it): `{\"frame\":int,\"t\":float,\"w\":int,\"h\":int,\"landmarks\":[{\"x\",\"y\",\"z\",\"vis\"}×33]}` as UDP datagrams. Every capture node emits this, tagged with a `source` id.\n\n**Architecture decisions already locked** (from the 2026-05-19 redundancy audit): - `cc-collection` is the canonical fusion path (1,027-line Kalman engine, parses 33-landmark frames). - `cc-window-aligner` is parked for LUME — real code (20,215 LOC) but mocopi-shaped, its `PacketPayload` has no MediaPipe variant. - `femto-bridge`'s 128D `skeleton_128d::Encoder` is kept — the only 128D code in the stack.", "htmlHref": "/research/html/lume-multi-sensor-motion-fusion-phased-plan-seu5xt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 971 }, { "id": "lume-duncan-fewkes-playbook-gap-analysis-1h9b9xh", "title": "LUME ↔ Duncan Fewkes playbook gap analysis", "slug": "lume-duncan-fewkes-playbook-gap-analysis", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/research/DUNCAN-GAP-ANALYSIS.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> **STATUS WARNING — stale status table.** This document remains useful as a > Duncan/Fewkes feature checklist, but its \"LUME status\" column predates later > Unity work. For current shipped/not-shipped state, use > `unity/lume_pcloud/ARCHITECTURE.md` first. As of 2026-05-01, the newer project > includes impulse, runtime calibration panel, motion gate, fluid sim, LUMM > mocopi receiver/animator, display controller, skeleton-fluid injector, and VFX > editor files that are not reflected accurately below. Treat rows 4,", "excerpt": "> **STATUS WARNING — stale status table.** This document remains useful as a > Duncan/Fewkes feature checklist, but its \"LUME status\" column predates later > Unity work. For current shipped/not-shipped state, use > `unity/lume_pcloud/ARCHITECTURE.md` first. As of 2026-05-01, the newer project > includes impulse, runtime calibration panel, motion gate, fluid sim, LUMM > mocopi receiver/animator, display controller, skeleton-fluid injector, and VFX > editor files that are not reflected accurately below. Treat rows 4, 5, 8, 10, > 11, and 15 as old-plan notes until this table is regenerated.\n\n_2026-04-26 — generated to anchor the Wave 5 priority list. Sources: the 4 Duncan playbook memory files (master + DV-DU + DT-DS + DR-DQ chunks) and the 16 Wave 1-4 commits on `main`._\n\nThe reels are the source of truth for \"what Duncan ships.\" The commits are the source of truth for \"what we ship.\" This file is the diff.\n\n| # | Layer | Duncan's stack | LUME status | Commit | Gap | |---|-------|----------------|-------------|--------|-----| | 1 | **Depth reprojection** | Femto/Kinect → CPU/GPU pinhole | ✅ Wave 2 GPU compute | `7387abb2` | — | | 2 | **Optical flow** | LK pyramid on linearised depth | ✅ Wave 4 dense single-scale LK | `ca975000` | Pyramid (multi-scale) deferred — fast motion above ~8 px/frame may alias | | 3 | **Audio FFT** | 4 EQ bands + RMS + spectral centroid + transient | ✅ Wave 4-B LUMF sidecar | `976e594a`, `e36956f7` | — | | 4 | **Audio reactivity (3-channel)** | outline=form, inner=action, **impulse=transient kick via VFX AddForce** | 🟡 outline + inner shipped; **impulse not wired** | Track C set transient bit on `_OutlineFlash`, but no per-particle force kick | **Wire AddForce into VFX Graph from `_OutlineFlash` transient bit** | | 5 | **2D Eulerian fluid sim** | Keijiro StableFluids fork, **6 named presets**, reflective boundaries | ❌ NOT STARTED | — | Vendor `keijiro/StableFluids`, port advection kernel into URP, expose 6 presets (Default / Default_Smooth / LongThrow / MidThrow / ShortThrow / InvertedObstacle) | | 6 | **VFX Graph particles** | `Multiparticle_Spine_FX` + `ParticleSystem_Spine_Trail` layered on depth particles | 🟡 Bootstrap shipped, **node graph empty** | `6d312a95`, `cf9becc4` | User wires the .vfx node graph per `Reference/Duncan/analyses/E460-noreel.md` recipe; runtime bridge already pushes globals | | 7 | **Marching cubes** | Keijiro `ComputeMarchingCubes`, **twin-mesh nested with `_InnerThreshold` / `_OuterThreshold` for glass-over-gold** | ❌ NOT STARTED | — | Vendor Keijiro MC, write twin-mesh shader pass | | 8 | **Calibration** | Per-install runtime tweak grid + circular degree-marked spatial UI; persisted to disk | 🟡 `LumeCalibration` ScriptableObject (intrinsics only) | `2f63709e` | No runtime debug UI yet, no per-i", "htmlHref": "/research/html/lume-duncan-fewkes-playbook-gap-analysis-1h9b9xh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1199 }, { "id": "lume-wood-v2-print-queue-mb0673", "title": "LUME Wood V2 Print Queue", "slug": "lume-wood-v2-print-queue", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/print/usb-staging/wood-v2-first-set/00_READ_ME_PRINT_ORDER.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The wood enclosure replaces the large 3D-printed outer bar shell and rear pod. Do not print the old shell halves or pod halves for this version. The printer is now used for the precision support pieces that make the wood body usable: camera mounts, sensor shelves, K11 tray, cable clamps, fan parts, and service plates.", "excerpt": "The wood enclosure replaces the large 3D-printed outer bar shell and rear pod. Do not print the old shell halves or pod halves for this version. The printer is now used for the precision support pieces that make the wood body usable: camera mounts, sensor shelves, K11 tray, cable clamps, fan parts, and service plates.\n\n- Printable CAD source: `../lume-wood-v2-printables.scad` - STL exports: `../exports/wood-v2/` - OrcaSlicer projects: `3mf-current/wood-v2/` - Preview renders: `../renders/wood-v2-printables/` - Wood fabrication spec: `../wood/LUME_WOOD_ENCLOSURE_SPEC.md`\n\nOpen these in OrcaSlicer, inspect the plate, then slice/export G-code from the GUI.\n\n| Plate | Orca project | Parts | Purpose | |---|---|---|---| | 01 | `3mf-current/wood-v2/01_wood_v2_small_fit.3mf` | 2x Arducam mounts, NF-A8 grille, NF-A8 spacer, USB service plate, display cable clamps, zip-tie anchors, feedthrough radius template | First validation plate. Confirms printer settings, fan hardware fit, Arducam mounting, cable routing hardware. | | 02 | `3mf-current/wood-v2/02_wood_v2_sensor_stack.3mf` | Mega shelf, Bolt shelf, sensor side-rail pair | Builds the stacked Mega/Bolt shelf tower for the wood front bar. | | 03 | `3mf-current/wood-v2/03_wood_v2_k11_sled.3mf` | Universal sled base, K11 adapter plate | Holds the K11 in the rear wood pod with bottom-fan clearance. |\n\n1. Print Plate 01 first. This replaces the old shell-joinery coupon gate for the wood version. 2. Test-fit the NF-A8 FLX fan against the grille/spacer and verify the 71.5 mm hole pattern. 3. Test-fit both Arducams against the two printed mounts before drilling the final front panel holes. 4. Print Plate 02 only after confirming the wood front-face window layout is still the stacked Mega-lower/Bolt-upper design. 5. Print Plate 03 after confirming the K11 will sit in the rear pod with ports facing the rear service window.", "htmlHref": "/research/html/lume-wood-v2-print-queue-mb0673.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 793 }, { "id": "lume-wood-v2-print-queue-1j98ku6", "title": "LUME Wood V2 Print Queue", "slug": "lume-wood-v2-print-queue", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/print/WOOD_V2_PRINT_QUEUE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The wood enclosure replaces the large 3D-printed outer bar shell and rear pod. Do not print the old shell halves or pod halves for this version. The printer is now used for the precision support pieces that make the wood body usable: camera mounts, sensor shelves, K11 tray, cable clamps, fan parts, and service plates.", "excerpt": "The wood enclosure replaces the large 3D-printed outer bar shell and rear pod. Do not print the old shell halves or pod halves for this version. The printer is now used for the precision support pieces that make the wood body usable: camera mounts, sensor shelves, K11 tray, cable clamps, fan parts, and service plates.\n\n- Printable CAD source: `../lume-wood-v2-printables.scad` - STL exports: `../exports/wood-v2/` - OrcaSlicer projects: `3mf-current/wood-v2/` - Preview renders: `../renders/wood-v2-printables/` - Wood fabrication spec: `../wood/LUME_WOOD_ENCLOSURE_SPEC.md`\n\nOpen these in OrcaSlicer, inspect the plate, then slice/export G-code from the GUI.\n\n| Plate | Orca project | Parts | Purpose | |---|---|---|---| | 01 | `3mf-current/wood-v2/01_wood_v2_small_fit.3mf` | 2x Arducam mounts, NF-A8 grille, NF-A8 spacer, USB service plate, display cable clamps, zip-tie anchors, feedthrough radius template | First validation plate. Confirms printer settings, fan hardware fit, Arducam mounting, cable routing hardware. | | 02 | `3mf-current/wood-v2/02_wood_v2_sensor_stack.3mf` | Mega shelf, Bolt shelf, sensor side-rail pair | Builds the stacked Mega/Bolt shelf tower for the wood front bar. | | 03 | `3mf-current/wood-v2/03_wood_v2_k11_sled.3mf` | Universal sled base, K11 adapter plate | Holds the K11 in the rear wood pod with bottom-fan clearance. |\n\n1. Print Plate 01 first. This replaces the old shell-joinery coupon gate for the wood version. 2. Test-fit the NF-A8 FLX fan against the grille/spacer and verify the 71.5 mm hole pattern. 3. Test-fit both Arducams against the two printed mounts before drilling the final front panel holes. 4. Print Plate 02 only after confirming the wood front-face window layout is still the stacked Mega-lower/Bolt-upper design. 5. Print Plate 03 after confirming the K11 will sit in the rear pod with ports facing the rear service window.", "htmlHref": "/research/html/lume-wood-v2-print-queue-1j98ku6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 793 }, { "id": "e460-duncan-fewkes-reel-analysis-digest-nos5nv", "title": "E460 — Duncan Fewkes reel analysis digest", "slug": "e460-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E460-noreel.md", "extension": "md", "score": 24, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "The prior chunk caught his recent product surface (VFX Editor, two-channel audio+motion reactivity, sunset preset, bullet-time/clones). This chunk catches the **rendering tech** under the surface:", "excerpt": "⚠ No video on disk for this reel — referenced by the playbook but not in the local ingest cache.\n\nThis file aggregates every playbook chunk section that cites E460. Sections are de-duplicated by heading.\n\nThe prior chunk caught his recent product surface (VFX Editor, two-channel audio+motion reactivity, sunset preset, bullet-time/clones). This chunk catches the **rendering tech** under the surface:\n\n1. **The product is called \"HOLOVIS\"** — that's the brand text rendered as 3D letters in nearly every install demo. It's not a placeholder. The letters are the **payload object** of his rendering: blendshape inflated by audio, reflection probe hit-target, particle attractor, light source. Treat HOLOVIS_LETTERS as a first-class object in his architecture, not chrome. 2. **Target hardware = Quadro A6000 @ 60fps** (E470 caption verbatim: *\"Target hardware is Quadro A6000 at 60 fps\"*). His laptop dev box is a 3070. This sets the LUME perf target ceiling — A6000 ≈ RTX 4080. Anything we plan that wouldn't run on a single 4080 at 60fps is over-budget for parity. 3. **The calibration grid IS the LED stage UI** — the gridded floor + walls + circular degree-marked \"calibration markers\" you see in every recent reel are actually his runtime spatial reference, used for depth-camera reprojection and multi-screen LED alignment. Not just decoration. He runs an \"LED-backed XR / CAVE-like volume\" (Gemini on E460/E466/E472). 4. **Two render-mode profiles ship together** (E473 visual analysis): `tint Lights, No Shadows` (160-170 fps, ambient/emissive only) and `Spot Lights, Shadows` (70-110 fps, cast shadows from 7x point/spot lights). Operator can A/B at runtime. **Add to LumeVfxEditor: a `LightingProfile` dropdown** with at least these two modes — fast/cheap and full/cinematic. 5. **Reflection-probe budget**: realtime reflection probe render every frame across 6 faces is a known toggle (E460 caption) — adds depth/colour but he calls it \"as an option toggled in settings.\" Same toggle slot in LUME. 6. **Depth-camera kaleidoscope** is a discrete VFX preset he calls out explicitly (E469 first introduces it, E471 adds metallic vs non-metallic, E472 stretches to full body). **Net new mode for LUME** not in the prior playbook. 7. **Marching Cubes is Keijiro's**, confirmed (E427 caption verbatim: `https://github.com/keijiro/ComputeMarchingCubes`). Source particles → MC compute shader → mesh. He runs **2 surface thresholds simultaneously** to get nested skins (inner gold, outer glass).\n\nCaption progression: - E469: *\"shoulda done it sooner — Amazing the daft poses that some rotational symmetry prompts you to hit\"* - E471: tests metallic vs non-metallic surface, adds \"test box environment so the metallic surface has something to reflect\" - E472: extends from upper-body-only to full ", "htmlHref": "/research/html/e460-duncan-fewkes-reel-analysis-digest-nos5nv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 4359 }, { "id": "duncan-fewkes-reel-reference-library-e2pn93", "title": "Duncan Fewkes reel reference library", "slug": "duncan-fewkes-reel-reference-library", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/INDEX.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Source: `[home-path]`. Local MP4s in `reels/` are symlinks (~zero disk cost). Captions are in `.txt` (grep-friendly) and `.json` (cleaned metadata). Per-reel Gemini visual analyses (where available) live in `analyses/`.", "excerpt": "Source: `[home-path]`. Local MP4s in `reels/` are symlinks (~zero disk cost). Captions are in `.txt` (grep-friendly) and `.json` (cleaned metadata). Per-reel Gemini visual analyses (where available) live in `analyses/`.\n\nCross-reference for the playbook synthesis: `[home-path]` and the 3 chunk files (DV-DU, DT-DS, DR-DQ).\n\n| E# | Date | Dur | Likes | Src | Analysis | Caption (head) | |---:|:-----|----:|------:|:----|:---------|:----------------| | E606 | 2026-04-25 | 1:51 | 25 | caption | [📄](analyses/E606-DXkF_PAigoP.md) | E606: \"Wide FoV vs Narrow FoV\" 🎵 Nikka Costa - Like A Feather Testing 3D depth … | | E605 | 2026-04-24 | 54 | 66 | caption | [📄](analyses/E605-DXhnYbCComC.md) | E605: \"Sunset Clone Plane\" 🎵 Pleasurekraft - Tarantula (Original Mix) Testing o… | | E604 | 2026-04-23 | 1:25 | 76 | caption | [📄](analyses/E604-DXeyhlRCpDN.md) | E604: \"Still Bouncing (Full)\" 🎵 ittibitti, Anna Graceman - Made You Look Testin… | | E599 | 2026-04-18 | 11 | 244 | caption | [📄](analyses/E599-DXRk-43inXa.md) | E599: \"Maximalism\" 🎵 Hall & Oates - You Make My Dreams (Come True) Testing how … | | E598 | 2026-04-17 | 38 | 4,081 | caption | [📄](analyses/E598-DXPfZg2ChnY.md) | E598: \"Dissolving Clones\" 🎵 Sammy Virji - Sinking Sailor Bopping about with my … | | E595 | 2026-04-14 | 7 | 70 | caption | [📄](analyses/E595-DXG-7e2CqSS.md) | E595: \"Slime Freeze\" 🎵 Dope Ammo, Phibes - Kill Bill (Phibes Remix) Testing the… | | E593 | 2026-04-12 | 32 | 55 | caption | [📄](analyses/E593-DXB2oG5Cq1u.md) | E593: \"Blobby Guys\" Some different surface materials on the metaball blobby guy… | | E589 | 2026-04-08 | 7 | 105 | caption | [📄](analyses/E589-DW3wCoVir-x.md) | E589: \"Dat Funk\" 🎵 Leo NXT - Dope On Plastic Just a short clip from test sessio… | | E588 | 2026-04-07 | 33 | 45 | caption | [📄](analyses/E588-DW1CrgUipKJ.md) | E588: \"Combo Test\" 🎵 Leo NXT - Hands Up Quick clip testing a few of the VFX. Wo… | | E587 | 2026-04-06 | 11 | 34 | caption | [📄](analyses/E587-DWy1RgUCpFk.md) | E587: \"Music On/Off\" 🎵 The Sponges, Father Funk - All I Hear (is a funky bassli… | | E584 | 2026-04-03 | 21 | 48 | caption | — | E584: \"In And Out\" 🎵 Leo NXT - Step Up | | E584 | 2026-04-03 | 21 | 149 | caption | — | E584: \"In And Out\" 🎵 Leo NXT - Step Up | | E579 | 2026-03-29 | 59 | 124 | caption | [📄](analyses/E579-DWd8U8Sig9F.md) | E579: \"Motion Sparks 4 (Getting Somewhere...)\" 🎵 Jaz-O - The Originators First … | | E579 | 2026-03-29 | 59 | 101 | caption | — | E579: \"Motion Sparks 4 (Getting Somewhere...)\" 🎵 Jaz-O - The Originators First … | | E578 | 2026-03-28 | 2:36 | 40 | caption | — | E578: \"Motion Sparks 3 (Audio-Reactive)\" 🎵 Nadia Rose - Skwod First pass audio-… | | E577 | 2026-03-27 | 28 | 72 | caption | — | E577: \"Motion Sparks 2\" Pushing extra variety in the", "htmlHref": "/research/html/duncan-fewkes-reel-reference-library-e2pn93.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2178 }, { "id": "2026-04-30-6te83r", "title": "2026-04-30", "slug": "2026-04-30", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/memory/2026-04-30.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- LUME CAD validation pass: corrected the active build direction to K11 rear pod + ZHAOCAILIN top display + Arducam IMX586 front-right camera. - Generated approval mockups in `hardware/cad/renders/approval/` and non-destructive validation STLs in `hardware/cad/exports/approval-v2/`. - Legacy Jetson/SVPRO/port-bracket parts are no longer mandatory for the current build. - Added a reversible symmetric Arducam variant: `ARDUCAM_LAYOUT=\"dual\"`, renders under `approval_symmetric_*`, exports under `hardware/cad/exports/a", "excerpt": "- LUME CAD validation pass: corrected the active build direction to K11 rear pod + ZHAOCAILIN top display + Arducam IMX586 front-right camera. - Generated approval mockups in `hardware/cad/renders/approval/` and non-destructive validation STLs in `hardware/cad/exports/approval-v2/`. - Legacy Jetson/SVPRO/port-bracket parts are no longer mandatory for the current build. - Added a reversible symmetric Arducam variant: `ARDUCAM_LAYOUT=\"dual\"`, renders under `approval_symmetric_*`, exports under `hardware/cad/exports/approval-symmetric/`, and notes in `LUME_SYMMETRIC_CAMERA_VARIANT.md`. - Reviewed `ORBBEC_Datasheet_Femto-Mega1.pdf`: front window is acceptable, rear feedthrough was enlarged to 87 x 38mm, and legacy Femto mount was replaced with a bottom/side cradle that does not cover sensors. - Added `hardware/cad/PRINT_APPROVAL_QUEUE_CURRENT.md` as the active queue: single-right Arducam is 15 final physical pieces / 19 with coupons; symmetric dual Arducam is 16 final physical pieces / 20 with coupons. Older print queue docs are stale and existing prearranged 3MFs need rebuilding before final print. - Stamped old CAD print/planning docs as legacy or stale (`PRINT_PLAN.md`, `DIMENSIONAL_AUDIT.md`, old slicing checklists, old queue files, and `CAD_APPROVAL_PACK.md`) and added missing finalization items to the active spec: display retention, USB/power architecture, service access, hardware BOM, and thermal validation. - Added pod service-access CAD: rear K11 port window, matching VESA-plate window, and right-side USB/service slot for Bluetooth/Sony adapter extension. Wrote `hardware/cad/LUME_WIRING_SERVICE_PLAN.md` and regenerated affected pod STLs in both approval export folders. - Verified internet dimensions and updated K11 CAD to official GMKtec 132 x 125 x 58mm. Generated Blender approval renders and current OrcaSlicer 3MF approval plates for both single-right and symmetric Arducam variants. Added `LUME_DIMENSION_SOURCE_AUDIT.md`. - Completed unattended 4K/128-sample Blender render run for single-right and symmetric Arducam variants. Output folders: `hardware/cad/renders/blender-approval-single-4k/`, `hardware/cad/renders/blender-approval-symmetric-4k/`; combined contact sheet: `hardware/cad/renders/blender-approval-4k-contact-sheet.png`. Computer Use access had worked earlier for OrcaSlicer, but later generic app-listing timed out, so file-based Orca/Blender automation remains the reliable route for now. - Patched all current OrcaSlicer approval 3MFs to fix slicer warnings: added `G92 E0` to `before_layer_change_gcode`, lowered embedded inner/travel accelerations to 500, and set embedded travel acceleration limit to 1000. Backups live under `hardware/cad/print/3mf-current/.backup-before-g92/` and `.backup-before-accel-patch/`. - Rebuilt the symmetric ", "htmlHref": "/research/html/2026-04-30-6te83r.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 736 }, { "id": "lume-mocopi-synth-a4l6gm", "title": "lume-mocopi-synth", "slug": "lume-mocopi-synth", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/services/mocopi-synth/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Procedural skeleton publisher — emits LUMM frames without any sensor hardware. Drives the visual stack for development, demos, and CI.", "excerpt": "Procedural skeleton publisher — emits LUMM frames without any sensor hardware. Drives the visual stack for development, demos, and CI.\n\nSame 772-byte LUMM datagram as `services/mocopi-bridge/`. Bone count, byte layout, and magic are pinned by `tests/services/test_wire_format_golden.py` — `mocopi-synth` is a reference implementation of the format.\n\n`--sync-to-lumf` listens to LUMF transients on `:9701` so the synthetic skeleton dances to whatever audio-pub is producing.\n\nCovers: golden wire bytes, motion-mode determinism (seeded RNG), BPM accuracy, beat-wrap stability.\n\nWave 8 ship. 21 components total in the visual stack (per `viz/lume-pcloud/ARCHITECTURE.md`). Production-tested on K11 NSSM.", "htmlHref": "/research/html/lume-mocopi-synth-a4l6gm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 149 }, { "id": "lume-internal-brief-for-vc-pitch-generation-cvebah", "title": "LUME — Internal Brief (for VC pitch generation)", "slug": "lume-internal-brief-for-vc-pitch-generation", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-content/vc-pitch/lume-internal-brief.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This brief is the source-of-truth the deck generator reads. It is INTERNAL. Architecture detail is fair game here. The public-content secret-sauce rule does NOT apply to this file or any deck generated from it.", "excerpt": "This brief is the source-of-truth the deck generator reads. It is INTERNAL. Architecture detail is fair game here. The public-content secret-sauce rule does NOT apply to this file or any deck generated from it.\n\nLUME is a real-time body-driven audio + visual install engine. A song plays. A body moves. The room watches both. When the rhythm catches the body and the body locks in, the wall remembers it. The room becomes a partner.\n\nIt runs as a self-contained piece of hardware that goes in venues: bars, lounges, galleries, retail spaces, brand-experience rooms. The body becomes the instrument. The visuals reward the alignment. People stop scrolling. They start watching themselves.\n\n- Multi-modal real-time engine: 21 Unity components, audio FFT + body tracking + depth reproject + optical flow + GPU compute pipeline, all running together at 60Hz on a small mini-PC. - Original wire-format suite (LUME / LUMD / LUMF / LUMM) over UDP. Each surface (audio, depth, mocopi motion, point clouds) has its own protocol, version-stable, reusable across publishers. - Computational choreography score: a real-time metric of body-music alignment that drives visuals back into the loop. Patentable territory; nobody else has shipped a scored body-music install engine. - Editor-grade tooling: F2 choreography panel, F12 calibration panel, one-click scene auto-wire. Operators can install + tune in a venue in <2 hours. - Hardware-software co-design: K11 mini-PC + Orbbec Femto Mega depth camera + dual Arducam IMX586 RGB cameras + 1920x440 IPS bar display + custom 3D-printed shell (31 parts, 7 plates, ASA filament, Elegoo Max). - 73-test pytest suite + Wave 1-9 architecture lineage. Production-grade, not demo-grade.\n\n- Wave 1-8 complete: audio reactor, depth reproject, optical flow, VFX bridge, fluid sim hooks, F2 choreography panel, motion-OSC bridge, computational choreography scorer - 21 Unity components live and integrated - K11 mini-PC online, three packet streams green - 73 fast pytest tests passing, byte-level wire-format regression - Hardware: K11 + Orbbec Femto Mega + dual Arducam IMX586 + 1920x440 IPS bar display defined for the current shell - Software: full Wave 8 stack on Mac1 main, ready for first reel record - 3D print queue: 31 parts, 7 plates, ~50 hours total, ASA matte white + signal orange palettes", "htmlHref": "/research/html/lume-internal-brief-for-vc-pitch-generation-cvebah.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 856 }, { "id": "motionmix-convergence-directive-ryzkd3", "title": "MotionMix Convergence Directive", "slug": "motionmix-convergence-directive", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "MotionMix/agent-handoffs/00-CONVERGENCE-DIRECTIVE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "MotionMix is no longer at the \"invent the architecture\" stage. The major runtime pieces already exist: the iPhone/iPad capture app, `multicam-server`, the Live Director macOS app, the Convex production ledger, the still-upload path, and the low-latency hero-feed/WebRTC seam. The current job is convergence. That means turning multiple partially completed coding sessions into one coordinated push with strict lane ownership, shared situational awareness, and no duplicate implementation. The product goal for this conve", "excerpt": "MotionMix is no longer at the \"invent the architecture\" stage. The major runtime pieces already exist: the iPhone/iPad capture app, `multicam-server`, the Live Director macOS app, the Convex production ledger, the still-upload path, and the low-latency hero-feed/WebRTC seam. The current job is convergence. That means turning multiple partially completed coding sessions into one coordinated push with strict lane ownership, shared situational awareness, and no duplicate implementation. The product goal for this convergence pass is not \"train the whole music brain today.\" The goal is to make the **AI photoshoot lane** trustworthy, operable, and logged well enough that it can be used as a real creative workflow.\n\n1. Stabilize the AI photoshoot runtime. 2. Add operator supervision for Ghost mode. 3. Complete Convex production-session/event writes from the live photoshoot path. 4. Start the offline training pipeline as a separate branch, without touching the live runtime.\n\n- Photoshoot Mode shell exists in Live Director. - Coverage map exists in Live Director. - Convex production ledger exists. - WebRTC hero-feed signaling/publisher/consumer seam exists. - Per-device flip controls already exist. - Smarter iPhone lens switching has already been patched. - Real still-upload path exists. - Optional Mac webcam feeds are already hidden by default in the photoshoot workflow.\n\n- `MotionMixApp` on iPhone/iPad: - `[home]/Desktop/MotionMixApp/MotionMixApp` - `multicam-server`: - `[home]/Desktop/MotionMix/multicam-server/src/main.rs` - `MotionMixLiveDirector`: - `[home]/Desktop/MotionMixLiveDirector` - Convex production backend: - `[home]/Desktop/Comp-Core/apps/convex-memory/convex`\n\n- `[home]/Desktop/MotionMix/AI-PHOTOSHOOT-TODAY-RUNBOOK.md` - `[home]/Desktop/MotionMix/AI-PHOTOSHOOT-MOTION-MUSIC-PLAN.md` - `[home]/Desktop/MotionMix/CONVEX-PRODUCTION-IMPLEMENTATION-HANDOFF.md` - `[home]/Desktop/MotionMix/CANONICAL-STATE-CONTRACT.md` - `[home]/Desktop/MotionMix/HANDOFF-AUDIO-PREP.md`", "htmlHref": "/research/html/motionmix-convergence-directive-ryzkd3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 534 }, { "id": "claude-agent-2-production-logging-lane-1lthadq", "title": "Claude Agent 2 - Production Logging Lane", "slug": "claude-agent-2-production-logging-lane", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "MotionMix/agent-handoffs/CLAUDE-AGENT-2-PRODUCTION-LOGGING.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The AI photoshoot lane already has a real runtime: phones/iPads capture, `multicam-server` coordinates, Live Director runs Photoshoot Mode, stills can be uploaded, and a Convex production ledger already exists. The missing piece is not architecture. The missing piece is making the live shoot write its own history. Your job is to wire the live photoshoot path into the already-built Convex production backend so a session produces durable production memory: sessions, cameras, cuts, holds, still markers, and other crea", "excerpt": "The AI photoshoot lane already has a real runtime: phones/iPads capture, `multicam-server` coordinates, Live Director runs Photoshoot Mode, stills can be uploaded, and a Convex production ledger already exists. The missing piece is not architecture. The missing piece is making the live shoot write its own history. Your job is to wire the live photoshoot path into the already-built Convex production backend so a session produces durable production memory: sessions, cameras, cuts, holds, still markers, and other creative events. You are not here to redesign the schema, build the training model, or rework transport. You are here to make the live shoot leave behind a coherent ledger.\n\nOwns runtime convergence, device registration truth, placement metadata, and final rebuild/redeploy validation.\n\n- hero-feed transport - mobile registry repair - placement metadata debugging - deployment reporting as the final source of truth\n\nUse the **existing Convex production ledger** as the source of truth for the photoshoot session.\n\n- `Start Shoot` creates or updates a `photoshoot_performance` production session - participating cameras are written into `productionCameras` - live direction writes meaningful events into `productionDirectorEvents` - still capture creates at least one production still record or event linkage - session completion closes out the production session", "htmlHref": "/research/html/claude-agent-2-production-logging-lane-1lthadq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 802 }, { "id": "codex-orchestrator-lane-1tfwyvi", "title": "Codex Orchestrator Lane", "slug": "codex-orchestrator-lane", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "MotionMix/agent-handoffs/CODEX-ORCHESTRATOR-LANE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "You are the runtime integrator and final truth source for the MotionMix convergence pass. The other agents are each being assigned a narrowly scoped implementation lane so they can work in parallel. Your job is not to duplicate their work. Your job is to keep the system honest, merge their outcomes safely, recover runtime truth when the live environment drifts, and validate that the full AI photoshoot stack works as one product. The current system already has the major building blocks. What is still fragile is the ", "excerpt": "You are the runtime integrator and final truth source for the MotionMix convergence pass. The other agents are each being assigned a narrowly scoped implementation lane so they can work in parallel. Your job is not to duplicate their work. Your job is to keep the system honest, merge their outcomes safely, recover runtime truth when the live environment drifts, and validate that the full AI photoshoot stack works as one product. The current system already has the major building blocks. What is still fragile is the seam between them: placement metadata, live device registration consistency, rebuild/redeploy correctness, and end-to-end integration verification after multiple agents land changes.\n\n- `MotionMixApp` - `multicam-server` - `MotionMixLiveDirector` - the live deployment/relaunch path - the final integration pass after the other agent lanes are complete\n\nYou are the only lane that should make authoritative claims about the actual runtime state after all changes land.\n\n- pending-cut UI - accept/veto behavior - Ghost-mode proposal countdown/rationale display\n\nThat agent does **not** own runtime placement metadata, live device registry recovery, or deployment truth.", "htmlHref": "/research/html/codex-orchestrator-lane-1tfwyvi.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 924 }, { "id": "sa3-mlx-stable-audio-3-in-pure-mlx-18r6o02", "title": "sa3_mlx — Stable Audio 3 in pure MLX", "slug": "sa3-mlx-stable-audio-3-in-pure-mlx", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/stable-audio-3/optimized/mlx/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "One line on a fresh Apple Silicon Mac — installs everything and plays back ~2 minutes of \"Impending tribal, epic orchestral buildup\":", "excerpt": "Apple-Silicon-native inference for **Stable Audio 3**, with no PyTorch, transformers, or stable-audio-tools at runtime.\n\nOne line on a fresh Apple Silicon Mac — installs everything and plays back ~2 minutes of \"Impending tribal, epic orchestral buildup\":\n\n| `--dit` | model | best for | |------------|--------------------|--------------------------------| | `sm-music` | sa3-sm-music (50 M block) | fast music generation | | `sm-sfx` | sa3-sm-sfx (50 M block) | sound effects | | `medium` | sa3-medium-ARC (1.4 B) | higher-quality music, slower |\n\n| mode | flags | example | |------------------|-----------------------------------------------|----------------------------------| | text-to-audio | `--prompt P` | new clip from a description | | audio-to-audio | `--prompt P --init-audio IN.wav --init-noise-level σ` | variation of an existing clip | | inpainting | `--prompt P --init-audio IN.wav --inpaint-range \"S,E\"` | regenerate one section, keep rest | | CFG + negative | `--cfg 3.0 --negative-prompt P_NEG` | steer toward / away from prompts |\n\n1. Install [uv](https://github.com/astral-sh/uv) via the official curl installer if it's missing (prompts y/N; `-y` skips the prompt). 2. Create a project-local `.venv/` with managed Python 3.11. 3. `uv pip install` the runtime deps into the venv (much faster than pip). 4. Ask which DiT bundles to download from HuggingFace (`stabilityai/stable-audio-3-optimized`). Each pick pulls its matching audio codec; T5Gemma (the shared text encoder) is downloaded once. Already-present weights are skipped.", "htmlHref": "/research/html/sa3-mlx-stable-audio-3-in-pure-mlx-18r6o02.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1653 }, { "id": "hf-paper-batch-lume-evaluation-2026-05-24-n709lu", "title": "HF Paper Batch -> LUME Evaluation - 2026-05-24", "slug": "hf-paper-batch-lume-evaluation-2026-05-24", "kind": "experiment", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/hf-paper-batch-lume-eval-2026-05-24.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- `https://huggingface.co/papers/2605.22809` - `https://huggingface.co/papers/2605.22717` - `https://huggingface.co/papers/2605.17991` - `https://huggingface.co/papers/2605.18714`", "excerpt": "- `https://huggingface.co/papers/2605.22809` - `https://huggingface.co/papers/2605.22717` - `https://huggingface.co/papers/2605.17991` - `https://huggingface.co/papers/2605.18714`\n\n- `Desktop/MotionMix/research/external/audio-ai/live-music-diffusion-models` - Git: `ab74346` (`2026-05-22 fix readme`) - `Desktop/MotionMix/research/external/audio-ai/stable-audio-3` - Git: `fa5ee84` (`2026-05-21 Merge pull request #36 from Stability-AI/apg-float64-mps`) - `Desktop/MotionMix/research/external/audio-ai/sgt-project-page` - Git: `dfb0941` (`2026-05-19 add links`)\n\nNo heavy installs or model-weight downloads were run. Stable Audio 3 weights are gated on Hugging Face and require accepting Stability/Gemma terms. LMDM needs a pretrained audio checkpoint before useful inference.\n\nTitle: `Sensor2Sensor: Cross-Embodiment Sensor Conversion for Autonomous Driving`\n\n- Convert unstructured monocular dashcam video into a structured multi-sensor suite using 4D Gaussian Splatting plus diffusion. - The important abstraction for LUME is not autonomous driving; it is cross-embodiment sensor conversion.", "htmlHref": "/research/html/hf-paper-batch-lume-evaluation-2026-05-24-n709lu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 744 }, { "id": "fac-implementation-scorecard-1x92ty7", "title": "FAC Implementation Scorecard", "slug": "fac-implementation-scorecard", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-acoustic-coding/experiments/artifacts/fac_implementation_scorecard.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- Entries: 105 - Unique videos: 20 - N'Ko chars: 12541 - Tone marks: 3316 - Parsed syllables: 4139 - Marked register H+L: 65.8% - Non-contour H+L+M: 99.1% - Contour rising+falling: 0.9%", "excerpt": "- Entries: 105 - Unique videos: 20 - N'Ko chars: 12541 - Tone marks: 3316 - Parsed syllables: 4139 - Marked register H+L: 65.8% - Non-contour H+L+M: 99.1% - Contour rising+falling: 0.9%\n\n- PASS: unicode_inventory_verified - PASS: tone_prior_current_corpus - PASS: text_baseline_recomputed - PASS: scripts_pass - PASS: contract_tests_pass - PASS: no_stale_claims - BLOCKED: read_speech_available - BLOCKED: checkpoint_inference_verified\n\n- PASS: `/opt/homebrew/opt/python@3.14/bin/python3.14 -W ignore tone_lm_baseline.py` - corpus: 105 lessons, 4139 syllables - text-only tone-resolution TDER (avg of 5 splits, lower=better): - majority-class floor : 58.7% - PASS: `/opt/homebrew/opt/python@3.14/bin/python3.14 -W ignore tone_seam_v0.py` - ================================================================ - TONE-SEAM v0 — acoustic tone resolution for N'Ko - ================================================================ - PASS: `/opt/homebrew/opt/python@3.14/bin/python3.14 -W ignore tone_fusion_eval.py --selftest` - [selftest] controlled F0 matching gold tones (acoustic should be near-perfect): - syllables=60 - TEXT-only TDER : 60.0% - PASS: `/opt/homebrew/opt/python@3.14/bin/python3.14 -W ignore h2_pitch_fidelity.py` - H2 pitch-fidelity | RMSE in cents (lower=better) | rate-distortion - corpus: synthetic tonal, 500x6x16, F0 100-250 Hz, contour depth 360 cents - - PASS: `/opt/homebrew/opt/python@3.14/bin/python3.14 -m pytest -q tests` - ...... [100%] - 6 passed in 0.03s\n\n- A real read-speech WAV aligned to known toned N'Ko text. - One checkpoint inference pass to measure end-to-end toned CER.", "htmlHref": "/research/html/fac-implementation-scorecard-1x92ty7.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 238 }, { "id": "fac-nko-tone-experiments-httwy3", "title": "FAC / N'Ko Tone Experiments", "slug": "fac-nko-tone-experiments", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-acoustic-coding/experiments/RESULTS.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This file is the human-readable summary of the runnable experiment scripts. The canonical machine-readable status is generated by:", "excerpt": "This file is the human-readable summary of the runnable experiment scripts. The canonical machine-readable status is generated by:\n\n- `artifacts/fac_implementation_scorecard.json` - `artifacts/fac_implementation_scorecard.md` - `corpus/tone_prior.json`\n\n- `U+07EB` short high - `U+07EC` short low - `U+07ED` short rising - `U+07EE` long descending - `U+07EF` long high - `U+07F0` long low - `U+07F1` long rising\n\nFolding length into class yields high, low, rising, falling, and unmarked mid. The important correction is that falling is native: `U+07EE` is long descending. The old extension interpretation is deprecated.\n\nThe current lesson corpus contains 105 entries from 20 videos, 12,541 N'Ko characters, 3,316 tone marks, and 4,139 parsed syllables.", "htmlHref": "/research/html/fac-nko-tone-experiments-httwy3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 491 }, { "id": "656-000-lines-of-code-for-a-script-most-ai-has-never-seen-wxupci", "title": "656,000 Lines of Code for a Script Most AI Has Never Seen", "slug": "656-000-lines-of-code-for-a-script-most-ai-has-never-seen", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/archive/infrastructure.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Here's a number that hit me when I ran `wc -l` across the project: 656,000 lines. Python, Swift, TypeScript. All of it for a single writing system that most language models handle worse than random noise.", "excerpt": "Here's a number that hit me when I ran `wc -l` across the project: 656,000 lines. Python, Swift, TypeScript. All of it for a single writing system that most language models handle worse than random noise.\n\nThe script is N'Ko (ߒߞߏ). You've probably never heard of it. That's the whole problem.\n\nIn 1949, a self-taught linguist named Solomana Kante designed N'Ko from scratch. He spoke Manding, a language family with 40 million speakers across West Africa. Bambara in Mali, Dioula in Cote d'Ivoire, Mandinka in The Gambia, Maninka in Guinea. Arabic script and Latin script both existed for these languages. Neither fit.\n\nArabic doesn't capture Manding's vowel distinctions. Latin doesn't encode its tonal system. The word \"ba\" means mother, goat, or river depending on tone. In Latin script, all three look identical. In N'Ko, each has a different mark.\n\nKante built something precise. 27 base characters, each mapping to exactly one sound. No silent letters. No irregular spellings. Explicit diacritical marks for all three tonal levels. It reads right-to-left. The name means \"I say\" in every Manding language.", "htmlHref": "/research/html/656-000-lines-of-code-for-a-script-most-ai-has-never-seen-wxupci.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1742 }, { "id": "does-every-ai-have-the-same-blind-spot-vhdhye", "title": "Does Every AI Have the Same Blind Spot?", "slug": "does-every-ai-have-the-same-blind-spot", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/experiments/experiment-a-cross-model-brain-scan.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Qwen3-8B, an 8-billion-parameter model trained on trillions of tokens, processed N'Ko text with measurably less activation than English at every single layer. More dead neurons. Less information being distributed. Flatter circuits. The model wasn't failing because N'Ko is difficult. It was failing because it had barely seen the script in training.", "excerpt": "*Testing whether N'Ko invisibility is a universal property of language models, or a quirk of one.*\n\nQwen3-8B, an 8-billion-parameter model trained on trillions of tokens, processed N'Ko text with measurably less activation than English at every single layer. More dead neurons. Less information being distributed. Flatter circuits. The model wasn't failing because N'Ko is difficult. It was failing because it had barely seen the script in training.\n\nThe technical name for this is an activation deficit. When a layer processes unfamiliar input, fewer neurons fire. The ones that do fire produce weaker signals. The result is a flatter, sparser activation profile across all 4,096 hidden dimensions. You can measure this with four numbers: L2 norm (how loudly is the layer speaking?), Shannon entropy (how spread out is the information?), sparsity (what fraction of neurons are essentially turned off?), and kurtosis (how specialized are the active circuits?).\n\nFor N'Ko, all four metrics pointed the same direction. The model was running on reduced capacity. It was processing N'Ko text with the cognitive equivalent of one hand behind its back.\n\nExperiment A asks a direct question: is N'Ko's invisibility specific to Qwen, or is it a structural property of models trained on data where N'Ko barely exists?", "htmlHref": "/research/html/does-every-ai-have-the-same-blind-spot-vhdhye.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1477 }, { "id": "adr-001-on-device-serving-feature-extractor-consistency-the-ane-and-turboquant-1s6rd38", "title": "ADR-001: On-Device Serving — Feature-Extractor Consistency, the ANE, and TurboQuant", "slug": "adr-001-on-device-serving-feature-extractor-consistency-the-ane-and-turboquant", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/adr/ADR-001-on-device-serving-and-quantization.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Status:** Accepted (2026-06-02) - **Scope:** How N'Ko ASR is served on-device, and the discipline that keeps a model decodable end to end. Does **not** change the training/research path. - **Authors:** Mohamed + Claude", "excerpt": "# ADR-001: On-Device Serving — Feature-Extractor Consistency, the ANE, and TurboQuant\n\n- **Status:** Accepted (2026-06-02) - **Scope:** How N'Ko ASR is served on-device, and the discipline that keeps a model decodable end to end. Does **not** change the training/research path. - **Authors:** Mohamed + Claude\n\n1. **Research / training path** — features extracted with standard **PyTorch-GPU Whisper-large-v3**, giving `(1500, 1280)` encoder output (1500 frames / 30 s). The validated 20.57 %-CER anchor (`paper4_reproduction_35205256`, `UnifiedCTCHead(use_trajectory=True, use_tar=False, use_ttt=False)`) trains and decodes on this path. Its model contains an internal `temporal_ds` (Conv1d, stride 4) that downsamples 1500 → 375 frames *inside* the network.\n\n2. **On-device path** — features extracted with a **CoreML Whisper encoder on the Apple Neural Engine (ANE)** (`Desktop/ane-training/ane_ctc_train.py`: \"Frozen Whisper encoder on ANE, CTC head on MLX GPU\"), giving **pre-downsampled `(375, 1280)`** features. The 297k pilot model is compatible with this 375-frame layout.\n\nFeeding the GPU-trained anchor the ANE's 375-frame features produced **all-blank output** (`blank_mass = 1.000` on every frame). Root cause: a **train/serve feature mismatch** — the anchor expects raw 1500 frames and downsamples internally; the ANE features are already downsampled, so the model double-downsampled (375 → ~94) into garbage. The cleanly-loaded state dict (0 missing / 0 unexpected) was a red herring; the features were out of distribution.", "htmlHref": "/research/html/adr-001-on-device-serving-feature-extractor-consistency-the-ane-and-turboquant-1s6rd38.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 814 }, { "id": "nko-uncertainty-packet-execution-plan-1wi0p3d", "title": "N'Ko Uncertainty Packet Execution Plan", "slug": "nko-uncertainty-packet-execution-plan", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/handoffs/nko_uncertainty_packet_execution_plan_2026-04-28.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- a loose chain of scripts passing text around - a real speech system with explicit uncertainty, provenance, and partition-aware routing", "excerpt": "- a loose chain of scripts passing text around - a real speech system with explicit uncertainty, provenance, and partition-aware routing\n\n- trajectory ASR on Vast - AGP/Gemma correction on Mac4/Mac5 - ASR partitioning (`stable|boundary|uncertain|novelty`) - a canonical segment corpus at `artifacts/corpus/segments.{jsonl,parquet}`\n\nWhat is still missing is the formal interface. Right now the stack is too text-centric. The next step is to make uncertainty and routing first-class.\n\n1. **Audio evidence stays upstream** - Gemma does not replace the acoustic model. 2. **Correction stays bounded** - AGP proposes; the gate decides. 3. **Every row is attributable** - raw ASR, corrected text, and decisions remain inspectable. 4. **Partitions are policy, not decoration** - `stable`, `boundary`, `uncertain`, and `novelty` drive downstream behavior. 5. **Search and TTS consume different slices** - not every corrected utterance is valid TTS training data.\n\n- `feat_id` - `audio_id` - `audio_path` - `episode_id` - `segment_id` - `split` - `script` - `mode`", "htmlHref": "/research/html/nko-uncertainty-packet-execution-plan-1wi0p3d.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1198 }, { "id": "nko-task-list-2026-04-25-1h7te5a", "title": "N'Ko Task List — 2026-04-25", "slug": "nko-task-list-2026-04-25", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/handoffs/nko-task-list-2026-04-25.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- [ ] Monitor `nko_trajectory_ttt_290596` to completion - [ ] Run one-command refresh immediately after TTT completion: - [ ] `python3 Desktop/nko-brain-scanner/scripts/paper4_post_ttt_refresh.py --wait` - [ ] Verify TTT artifacts exist locally: - [ ] `results.json` - [ ] `test_predictions.jsonl` - [ ] `test_references.jsonl` - [ ] Verify refreshed five-run outputs exist: - [ ] `Desktop/Comp-Core/experiments/agp_mlx/asr_bridge/reports/paper4_same_snapshot_batch_replay_final/batch_summary.json` - [ ] `Desktop/Comp-C", "excerpt": "- [ ] Monitor `nko_trajectory_ttt_290596` to completion - [ ] Run one-command refresh immediately after TTT completion: - [ ] `python3 Desktop/nko-brain-scanner/scripts/paper4_post_ttt_refresh.py --wait` - [ ] Verify TTT artifacts exist locally: - [ ] `results.json` - [ ] `test_predictions.jsonl` - [ ] `test_references.jsonl` - [ ] Verify refreshed five-run outputs exist: - [ ] `Desktop/Comp-Core/experiments/agp_mlx/asr_bridge/reports/paper4_same_snapshot_batch_replay_final/batch_summary.json` - [ ] `Desktop/Comp-Core/experiments/agp_mlx/asr_bridge/reports/paper4_same_snapshot_batch_replay_final/batch_summary.md` - [ ] `Desktop/Comp-Core/experiments/agp_mlx/asr_bridge/reports/paper4_same_snapshot_final_correction/combined_bridge.jsonl` - [ ] `Desktop/Comp-Core/experiments/agp_mlx/asr_bridge/reports/paper4_same_snapshot_final_correction/gemma_correction_sft/manifest.json`\n\n- [ ] Mark `gemma4_e2b_nko_correction_partial_real_stage1_stable` step 80 as invalid for quality use - [ ] Preserve the step-80 reports as failure evidence, not as deployment artifacts - [x] Inspect the clean recovery anchor: - [x] `[home-path]` - [x] Create a new recovery adapter path that does not overwrite the poisoned stable path - [x] `[home-path]` - [x] Add recovery tooling: - [x] `prepare_partial_real_recovery.sh` - [x] `partial_real_recovery_stage1_stable` launcher/chunk modes - [ ] Decide recovery mode: - [ ] restart from clean probe step 10 - [ ] or restart fresh from the same partial-real dataset - [ ] Add an early 10-row validation gate before any long continuation - [ ] Abort immediately on any resumed `loss=nan`\n\n- [ ] Keep corrected evaluator behavior: - [ ] `eval_agp_nko_adapter.py` must parse `ASR candidate:` - [ ] Preserve the decisive fixed reports: - [ ] `eval-valid-10-base-fixed.json` - [ ] `eval-valid-10-fixed.json` - [ ] After recovery, rerun bounded base-vs-adapter validation before any broader replay claim\n\n- [ ] Let the Mac5 `babamamadidiane` mirror continue in background - [ ] After matrix closeout, verify full channel mirror completeness on `HD1` - [ ] Start frame extraction - [ ] Start scene segmentation - [ ] Run OCR on extracted frames - [ ] Align OCR text with audio segments - [ ] Generate new training/evaluation pairs from OCR+audio alignment\n\n- [ ] Keep LearnNKo live inscriptions path stable: - [ ] `https://www.learnnko.com/nko?tab=inscriptions` - [ ] Keep Mac4 proxy healthy under launchd - [ ] Keep Mac5 speech endpoint reachable: - [ ] `http://[ip]:8899/transcribe` - [ ] Run a better speech sample audit after matrix closeout", "htmlHref": "/research/html/nko-task-list-2026-04-25-1h7te5a.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 395 }, { "id": "nko-unified-plan-2026-04-25-1feo2vi", "title": "N'Ko Unified Plan — 2026-04-25", "slug": "nko-unified-plan-2026-04-25", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/handoffs/nko-unified-plan-2026-04-25.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This is the current operating plan for the N'Ko lane after consolidating the website work, the same-snapshot Paper 4 matrix, the MAOE replay layer, the partial-real Gemma correction lane, the live ASR service, and the OCR expansion queue.", "excerpt": "This is the current operating plan for the N'Ko lane after consolidating the website work, the same-snapshot Paper 4 matrix, the MAOE replay layer, the partial-real Gemma correction lane, the live ASR service, and the OCR expansion queue.\n\nThe key correction is simple. The local partial-real Gemma correction adapter reached step 80 mechanically, but it failed behaviorally. The corrected validation check shows the base model outperforming the adapter by a wide margin, and the adapter emits repeated pad tokens on a one-sample probe. That means the step-80 adapter is a dead branch. It is not a checkpoint to continue from, and it is not a candidate for proposal evaluation.\n\nThe highest-priority scientific dependency is still the final same-snapshot run:\n\n- do not interfere while the run is healthy - once it completes, immediately run closeout - collect: - `results.json` - `test_predictions.jsonl` - `test_references.jsonl` - final checkpoint metadata\n\n- the same-snapshot five-run matrix becomes complete - the paper claims can stop speaking in provisional language about TTT", "htmlHref": "/research/html/nko-unified-plan-2026-04-25-1feo2vi.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 747 }, { "id": "ankatta-capture-v0-1dz4224", "title": "Ankatta Capture V0", "slug": "ankatta-capture-v0", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/ANKATTA-CAPTURE-V0.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Ankatta fits the N'Ko/Malinke speech stack as a lexicon-assisted intent capture surface. It is not the recognizer and it is not the translator. Its job is to make human evidence collection easy when the speaker does not know exact N'Ko spelling.", "excerpt": "Ankatta fits the N'Ko/Malinke speech stack as a lexicon-assisted intent capture surface. It is not the recognizer and it is not the translator. Its job is to make human evidence collection easy when the speaker does not know exact N'Ko spelling.\n\nThe page records short audio, lets the speaker enter what they meant in English or rough Malinke/Bambara/Jula, and uses the scraped Ankataa dictionary as a quiet vocabulary aid. Dictionary matches appear automatically from the meaning or rough phrase field. Checked matches are saved only as candidate lexicon context. They do not prove that the audio contained those words.\n\nThe original simple capture flow is still preserved in code as `html_app_simple_capture()`, but the served app is the family trainer.\n\nAdvanced fields such as phrase identity, optional N'Ko, notes, local export, and raw status remain available behind the advanced drawer. They are useful for review, but they are not the main user journey.\n\nPrompted kid and baby captures do not require typed meaning. The prompt itself becomes the expected meaning and rough Latin/Malinke phrase. This is stronger than open-ended capture because the intended label is known before recording, but it is still not training truth until governed review admits it.", "htmlHref": "/research/html/ankatta-capture-v0-1dz4224.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 435 }, { "id": "edit-candidate-oracle-report-1oxa5pw", "title": "Edit-Candidate Oracle Report", "slug": "edit-candidate-oracle-report", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/overnight/edit_candidate_oracle_v1/ORACLE-REPORT.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| condition | CER | delta pp | changed | better/same/worse | |---|---:|---:|---:|---:| | baseline | 0.3514 | +0.00 | 0 | 0/0/0 | | oracle_any | 0.2951 | -5.63 | 1367 | 1367/0/0 | | oracle_preserve | 0.3234 | -2.80 | 669 | 669/0/0 | | acoustic_gate | 0.3497 | -0.18 | 213 | 119/52/42 | | acoustic_preserve_gate | 0.3496 | -0.18 | 194 | 113/47/34 | | acoustic_featural_preserve_gate | 0.3496 | -0.18 | 194 | 113/47/34 |", "excerpt": "Rows: 1381 Baseline CER: 0.3514 Rows with any bounded local-edit improvement: 1367/1381 (99.0%)\n\n| condition | CER | delta pp | changed | better/same/worse | |---|---:|---:|---:|---:| | baseline | 0.3514 | +0.00 | 0 | 0/0/0 | | oracle_any | 0.2951 | -5.63 | 1367 | 1367/0/0 | | oracle_preserve | 0.3234 | -2.80 | 669 | 669/0/0 | | acoustic_gate | 0.3497 | -0.18 | 213 | 119/52/42 | | acoustic_preserve_gate | 0.3496 | -0.18 | 194 | 113/47/34 | | acoustic_featural_preserve_gate | 0.3496 | -0.18 | 194 | 113/47/34 |\n\nAcoustic-selected improvements: 119/1381 (8.6%). Hit rate on rows where the candidate set had a true improvement: 8.7%.\n\nThe oracle rows are not deployable because they use clean references to choose the best candidate. They measure ceiling only. The acoustic rows are the deployable selection test.\n\nArtifacts: `experiments/acoustic_gate/overnight/edit_candidate_oracle_v1/oracle_report.json`, `experiments/acoustic_gate/overnight/edit_candidate_oracle_v1/oracle_cases.jsonl`.", "htmlHref": "/research/html/edit-candidate-oracle-report-1oxa5pw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 153 }, { "id": "stage-3-report-bounded-edit-op-corrector-q9b87d", "title": "Stage 3 Report — Bounded Edit-Op Corrector", "slug": "stage-3-report-bounded-edit-op-corrector", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/overnight/STAGE3-REPORT.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Status:** done. The edit-op interface is valid and much faster than full-string correction, but the trained proposer collapsed to COPY and does **not** improve clean-anchor CER.", "excerpt": "**Status:** done. The edit-op interface is valid and much faster than full-string correction, but the trained proposer collapsed to COPY and does **not** improve clean-anchor CER.\n\nFull-string correction was the wrong serving shape: Codex's clean LoRA trained, but 1,381-row generation was stopped after 39+ minutes with no completed output. Stage 3 replaced that with bounded edit operations (`COPY`, `SUB`, `INS`, `DEL`) scored by `featural_edit.py` and applied deterministically by `edit_ops.py`.\n\nThe interface itself works only with a constrained opening-bracket decode prompt:\n\nThe generated tail is parsed as `[` + tail. Without this prefix, Gemma drifts into N'Ko phrase loops instead of JSON. With the prefix, the full 1,381-row generation is valid and bounded, but every output is `COPY`.\n\n| metric | value | |---|---:| | rows in | 86,990 | | rows kept | 86,043 | | rows dropped, over 3 ops | 947 | | median edit ops | 0 | | max edit ops observed | 3 | | median target chars | 10 | | max target chars | 50 |", "htmlHref": "/research/html/stage-3-report-bounded-edit-op-corrector-q9b87d.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 739 }, { "id": "ranker-generalization-report-1pu76eh", "title": "Ranker Generalization Report", "slug": "ranker-generalization-report", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/RANKER-GENERALIZATION-REPORT.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- Pilot train/tune source: `[home]/Desktop/nko-brain-scanner/experiments/acoustic_gate/decoded_anchor_native.jsonl` (1381 rows) - External test source: `[home]/Desktop/nko-brain-scanner/experiments/acoustic_gate/decoded_anchor_generalization_500.jsonl` (500 rows) - External rows are true anchor seed-42 TEST split rows, disjoint from `bam_train_000000..001380`. - Ranker threshold tuned on pilot validation only: `0.6500`.", "excerpt": "- Pilot train/tune source: `[home]/Desktop/nko-brain-scanner/experiments/acoustic_gate/decoded_anchor_native.jsonl` (1381 rows) - External test source: `[home]/Desktop/nko-brain-scanner/experiments/acoustic_gate/decoded_anchor_generalization_500.jsonl` (500 rows) - External rows are true anchor seed-42 TEST split rows, disjoint from `bam_train_000000..001380`. - Ranker threshold tuned on pilot validation only: `0.6500`.\n\n| condition | CER | delta pp | changed | better/same/worse | |---|---:|---:|---:|---:| | baseline | 0.4352 | +0.00 | 0 | 0/0/0 | | oracle_any | 0.3843 | -5.09 | 492 | 492/0/0 | | oracle_preserve | 0.4121 | -2.31 | 225 | 225/0/0 | | ranker | 0.3987 | -3.65 | 489 | 441/42/6 | | ranker_preserve | 0.4170 | -1.82 | 263 | 223/35/5 |\n\nThe first table above is the pure pilot-threshold generalization result. After that pass, the frozen config was calibrated on this broader held-out slice to produce audited operating modes:\n\n| mode | tuned threshold | preserve gate | external CER | delta pp | changed | better/same/worse | |---|---:|---:|---:|---:|---:|---:| | aggressive | 0.8000 | False | 0.3986 | -3.66 | 482 | 439/41/2 | | balanced | 0.8000 | False | 0.3986 | -3.66 | 482 | 439/41/2 | | conservative | 0.9432 | False | 0.4026 | -3.26 | 396 | 381/15/0 | | preservation | 0.9432 | True | 0.4188 | -1.64 | 210 | 196/14/0 |\n\n- External candidate AUC: `0.9134446030936896` - External candidate AP: `0.8660712285419349` - Weights/config: `[home]/Desktop/nko-brain-scanner/experiments/acoustic_gate/models/candidate_ranker_v1.json` - Packaged apply verification: `apply_ranked_correction.py --mode conservative` reproduced the audited held-out result exactly: CER `0.4352 -> 0.4026` (`-3.26pp`), 396 changed, 381 better / 15 same / 0 worse. - Final module verification after refactor: the deployable modules no longer import the overnight oracle/ranker scripts. `candidate_generator.py` owns alignment/confusion/candidate/CTC-scoring logic, `candidate_ranker.py` owns feature extraction + frozen logistic inference, and `apply_ranked_correction.py` loads the frozen config directly. Full 500-row conservative apply still reproduces `0.4352 -> 0.4026`, 381 better / 15 same / 0 worse. - Frozen deployable artifact: `models/candidate_ranker_v1.json` now includes feature means/stds, logistic weights/bias, calibrated modes, candidate-generator config, and the serialized ASR->clean confusion maps. It no longer needs training rows at inference time.", "htmlHref": "/research/html/ranker-generalization-report-1pu76eh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 465 }, { "id": "runbook-phase-1-regenerate-proposals-on-the-clean-anchor-base-mac5-1c9q3m0", "title": "Runbook — Phase 1: regenerate proposals on the CLEAN anchor base (mac5)", "slug": "runbook-phase-1-regenerate-proposals-on-the-clean-anchor-base-mac5", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/RUNBOOK-anchor-clean-regen.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Why:** the acoustic-gate pilot's reference-dependent numbers (proposer hit rate 1.9%, flywheel harvest precision) were measured on the 297k model against **contaminated** ane references. To make them trustworthy, regenerate Gemma correction proposals against the **anchor's clean hypotheses + clean HF references**, then re-run the gate.", "excerpt": "**Why:** the acoustic-gate pilot's reference-dependent numbers (proposer hit rate 1.9%, flywheel harvest precision) were measured on the 297k model against **contaminated** ane references. To make them trustworthy, regenerate Gemma correction proposals against the **anchor's clean hypotheses + clean HF references**, then re-run the gate.\n\n- `proposer_input_anchor.jsonl` (1,381 rows) — anchor clean hyps as `asr_candidate`, clean HF refs as `reference`. Already compatible with `ASRBridgePacket.from_mapping` (accepts `asr_candidate`/`reference`/`n_best`; trajectory scalars default to neutral 0.0 — acceptable, or recompute the anchor's `scalar_computer` outputs first for a fully self-consistent packet). - Proposer: `Desktop/Comp-Core/experiments/agp_mlx/asr_bridge/agp_text_proposal.py` (+ sibling `schema.py`). Lives on **mac1** — must be copied to mac5 with its package dir.\n\n1. **Base vs LoRA.** Task #10 trained a minimal-edit LoRA adapter (SFT from rejected pairs). Decide: run base Gemma-3n-E2B-4bit (clean baseline) **or** the #10 adapter (the intended corrector). Recommend running **both** to isolate the adapter's effect. 2. **Gemma model path on mac5.** Resolve the exact `--model` (Gemma-3n-E2B-4bit) + optional `--adapter-path`. Use `[home-path]` (mlx_lm 0.31.2 — the only venv that loads gemma-3n E2B; system py3.9/mlx 0.29.3 does NOT).\n\n1. `scp mac5:[home-path] .` 2. `reextract.py` → `proposals_anchor_clean_extracted.jsonl` (harness fix, clean N'Ko). 3. Re-run the gate against **clean** refs: adapt `robust_eval.py` to point at `decoded_anchor_native.jsonl` + the clean proposals → the trustworthy 4-condition table (baseline / raw+gate / clean+gate / clean+preserve+gate) with bootstrap CIs. 4. Compare to the contaminated-substrate numbers in `TECHNICAL-REPORT.md §8`. The honest question this answers: **does the corrector help at all once the references are clean and the base is the 20.57% anchor?**\n\n- Anchor = `UnifiedCTCHead(num_classes=66, use_trajectory=True, use_tar=False, use_ttt=False)`; native features at `/Volumes/HD1/anchor_bam_feats` (1500-frame). - Clean refs: HF `Diomande/bambara-whisper-features/corrected_pairs_290k.jsonl` (== `pairs.jsonl` for bam). - Split is seed-42 deterministic; reconstruction verified (232476/29060/29060). The 1,381 pilot utts are NOT all train — they scatter ~80/10/10. No memorization (held-out CER 0.3112 vs train 0.3081).", "htmlHref": "/research/html/runbook-phase-1-regenerate-proposals-on-the-clean-anchor-base-mac5-1c9q3m0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 400 }, { "id": "nko-speech-inscription-bridge-v0-1a89owo", "title": "N'Ko Speech Inscription Bridge v0", "slug": "nko-speech-inscription-bridge-v0", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/experiments/acoustic_gate/SPEECH-INSCRIPTION-BRIDGE-V0.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The live mic harness must not display unstable CTC output as if it were language. A live or recorded run now has to compile into a governed speech inscription packet:", "excerpt": "The live mic harness must not display unstable CTC output as if it were language. A live or recorded run now has to compile into a governed speech inscription packet:\n\nThe N'Ko surface is not the source of truth. The typed decision and archived evidence are.\n\n- IR primacy: the transcript decision is authoritative; the rendered N'Ko line is a surface. - Controlled register: this is not natural-language N'Ko prose and not translation. - Determinism: same archived audio/logits/argmax/config must reproduce the same decision. - Provenance: each decision points back to captured audio, prepared audio, logits, argmax, file hashes, and manifest sidecar hash. - Non-retroactivity: once saved, calibration packets are not rewritten. Later models may reinterpret them as derived views.\n\nThe public Learn N'Ko technical docs describe the same chain as evidence, IR, surface, and proof scaffold. The NIP docs frame evidence admissibility, deterministic commitment, limits of translation, and human feedback as constitutional concerns. Speech v0 is an application of those laws to audio.\n\n- `live_mic`: microphone capture with optional copied `recording.caf`. - `recorded_fixture`: bundled real-audio fixture proof.", "htmlHref": "/research/html/nko-speech-inscription-bridge-v0-1a89owo.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 791 }, { "id": "nko-phonemic-substrate-validation-report-m84whu", "title": "N'Ko Phonemic Substrate Validation Report", "slug": "nko-phonemic-substrate-validation-report", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/NKO-VALIDATION-REPORT.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This report freezes the evidence state before turning the current work into a paper. It separates what is mechanically validated, what is empirically supported, what failed, and what remains a hypothesis.", "excerpt": "This report freezes the evidence state before turning the current work into a paper. It separates what is mechanically validated, what is empirically supported, what failed, and what remains a hypothesis.\n\nThe correct term in this package is **N'Ko**. \"NKL\" was only a conversational typo; it is not used as a technical term here.\n\nUnicode uses the formal block/script spelling **NKo** because apostrophes are not allowed in Unicode character and block names. The research text uses **N'Ko** for the script/language tradition and **NKo** only when referring to Unicode identifiers.\n\n- Unicode Core Specification, Chapter 19, section 19.4.1, documents N'Ko as a right-to-left, phonetic script with seven vowels, tone marks, nasalization, and diacritics used for foreign sounds. Source: https://www.unicode.org/versions/latest/core-spec/chapter-19/ - Unicode Table 19-3 documents concrete foreign-sound combinations, including mappings involving U+07ED and U+07F3 for sounds such as [v], [theta], [esh], [ezh], [schwa], and French [y]. Source: https://www.unicode.org/versions/latest/core-spec/chapter-19/ - ScriptSource independently summarizes N'Ko as a phonemic alphabet with 19 consonants, 7 vowels, 8 diacritics, and later combining marks for foreign sounds. Source: https://scriptsource.org/scr/Nkoo - Library of Congress romanization notes list foreign-sound and diacritic handling for N'Ko cataloging practice. Source: https://www.loc.gov/catdir/cpso/romanization/N%27ko.pdf\n\nThese sources validate the key standards claim: extending N'Ko with diacritics for foreign sounds is not an invented premise. The paper's internal full-compositional layer is still a computational encoding, not an official orthographic reform.", "htmlHref": "/research/html/nko-phonemic-substrate-validation-report-m84whu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1087 }, { "id": "project-state-snapshot-1038pbf", "title": "Project State Snapshot", "slug": "project-state-snapshot", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/pipeline/scripts/PROJECT_STATE_SNAPSHOT.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. Snapshot Metadata 1.1 Snapshot ID: 2026-01-03-01 1.2 Date: 2026-01-03 1.3 Scope: [home]/Desktop/learnnko/training/scripts", "excerpt": "1. Snapshot Metadata 1.1 Snapshot ID: 2026-01-03-01 1.2 Date: 2026-01-03 1.3 Scope: [home]/Desktop/learnnko/training/scripts\n\n2. Canonical Artifacts 2.1 README.md 2.2 INTAKE_REPORT.md 2.3 PROJECT_CHARTER.md 2.4 SYSTEM_GLOSSARY.md 2.5 ASSUMPTIONS_INVARIANTS.md 2.6 IMPLEMENTATION_GUIDE.md 2.7 IMPLEMENTATION_CHECKLIST.md 2.8 CONTINUATION_PROTOCOL.md 2.9 PROJECT_STATE_SNAPSHOT.md\n\n3. Current Phase and Progress 3.1 Phase: 0 - Project Control Layer 3.2 Last Completed: Create State Snapshot (IMPLEMENTATION_CHECKLIST.md [ip]) 3.3 Next Active: Validate Phase Zero Documents (IMPLEMENTATION_CHECKLIST.md [ip]) 3.4 Confidence: Medium 3.5 Open Uncertainties: Intended scope beyond README.md; preferred location or naming for governance documents; meaning of \"synergetic\" request. 3.6 Blocked By: None\n\n4. Change History 4.1 2026-01-03 v0.1 Initial snapshot after intake and Phase Zero document creation. 4.2 2026-01-03 v0.2 Added self-reference to canonical artifacts list.", "htmlHref": "/research/html/project-state-snapshot-1038pbf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 116 }, { "id": "speakflow-9gsw9i", "title": "SpeakFlow 🎙️", "slug": "speakflow", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/macos/SpeakFlow/README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Hold **⌥Space** anywhere on macOS → speak → text appears in whatever app is focused. No cloud, no subscription, no latency.", "excerpt": "Hold **⌥Space** anywhere on macOS → speak → text appears in whatever app is focused. No cloud, no subscription, no latency.\n\n| Wave | Tasks | Status | |------|-------|--------| | **Wave 0: Foundation** | SF-0.1 → SF-0.4 | ✅ Done — builds, pipeline wired | | **Wave 1: Mac Injection** | SF-1.1 → SF-1.4 | ⬜ Queued | | **Wave 2: AI Cleanup** | SF-2.1 → SF-2.3 | ⬜ Queued | | **Wave 3: iOS Keyboard** | SF-3.1 → SF-3.5 | ⬜ Queued | | **Wave 4: Ship** | SF-4.1 → SF-4.4 | ⬜ Queued |\n\n- `Desktop/Speak/SpeakReader/` — HotKeyManager, PermissionsManager ported - `Desktop/Speak/services/macos_speech_service.py` — API design reference - `Desktop/cross-script-bridge/ios-keyboard/` — KeyboardViewController (Wave 3 source) - `Desktop/voice-corpus/` — 382 voice notes (Wave 2 training data)\n\nTrack progress: [#speakflow-ops](https://discord.com/channels/1470100197941051623/1473426349849972739)", "htmlHref": "/research/html/speakflow-9gsw9i.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 310 }, { "id": "nko-1-2-complete-nko-phonetics-module-12nizkl", "title": "NKO-1.2 Complete — `nko.phonetics` Module", "slug": "nko-1-2-complete-nko-phonetics-module", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-1.2-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Replaced the 4-line stub at `nko/phonetics.py` with a comprehensive **820-line** unified phonetics module that consolidates IPA mappings, tone handling, character classification, and Unicode utilities from 13+ scattered implementations across the codebase.", "excerpt": "Replaced the 4-line stub at `nko/phonetics.py` with a comprehensive **820-line** unified phonetics module that consolidates IPA mappings, tone handling, character classification, and Unicode utilities from 13+ scattered implementations across the codebase.\n\n### Source Files Analyzed | File | What it contributed | |------|-------------------| | `core/audio/phoneme.py` | PhonemeMapper, NKO_CONSONANTS, NKO_VOWELS, NKO_TONES, IPA mappings | | `core/transliteration/nko.py` | NkoHandler — full NKO_TO_IPA map, IPA_TO_NKO reverse, LATIN_TO_NKO, validation | | `core/transliteration/bridge.py` | Script detection logic (Unicode ranges) | | `core/audio/pronunciation.py` | PronunciationEngine — syllabification, difficulty estimation | | `core/prediction/prosody_engine.py` | NKO_VOWELS/NKO_CONSONANTS sets, ToneType enum, NKO_HIGH_TONE/LOW_TONE constants | | `core/prediction/tts_engine.py` | PhonemeMapping dataclass, TonePattern enum, dialect awareness | | `tools/sound-sigils/definitions.py` | SigilDefinition data (N'Ko char → semantic/audio mappings) | | `data/nko-unified.json` | 232 canonical records — characters (vowels/consonants/digits/tone_marks/punctuation), vocabulary, morphology, cognates, proverbs |\n\n### Unicode Range Utilities | Method | Returns | Example | |--------|---------|---------| | `is_nko_char(ch)` | `bool` | `is_nko_char('ߞ') → True` | | `is_nko_text(text)` | `bool` | `is_nko_text('ߒߞߏ') → True` | | `nko_purity(text)` | `float` | `nko_purity('ߒabc') → 0.25` |\n\n### Character Classification | Method | Returns | Example | |--------|---------|---------| | `classify(ch)` | `CharCategory` | `classify('ߞ') → CONSONANT` | | `is_vowel(ch)` | `bool` | `is_vowel('ߊ') → True` | | `is_consonant(ch)` | `bool` | `is_consonant('ߞ') → True` | | `is_letter(ch)` | `bool` | `is_letter('ߊ') → True` | | `is_tone_mark(ch)` | `bool` | `is_tone_mark('߫') → True` | | `is_combining(ch)` | `bool` | `is_combining('߲') → True` | | `is_digit(ch)` | `bool` | `is_digit('߁') → True` | | `is_punctuation(ch)` | `bool` | `is_punctuation('߹') → True` |\n\n### IPA Conversion | Method | Returns | Example | |--------|---------|---------| | `to_ipa(text)` | `str` | `to_ipa('ߒߞߏ') → 'nkɔ'` | | `to_ipa(text, include_tones=True)` | `str` | Includes IPA diacritics for tones | | `char_to_ipa(ch)` | `str` | `char_to_ipa('ߞ') → 'k'` | | `to_phonemes(text)` | `List[Phoneme]` | List with symbol, source_char, tone, duration | | `ipa_to_nko(ipa)` | `str` | `ipa_to_nko('nkɔ') → 'ߣߞߏ'` |", "htmlHref": "/research/html/nko-1-2-complete-nko-phonetics-module-12nizkl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1023 }, { "id": "nko-1-3-complete-nko-transliterate-canonical-engine-1djqwuy", "title": "NKO-1.3 Complete — `nko.transliterate` Canonical Engine", "slug": "nko-1-3-complete-nko-transliterate-canonical-engine", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-1.3-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "`nko/transliterate.py` — the canonical, unified transliteration engine for the N'Ko Unified Platform. Consolidates **6 scattered implementations** into one authoritative module.", "excerpt": "`nko/transliterate.py` — the canonical, unified transliteration engine for the N'Ko Unified Platform. Consolidates **6 scattered implementations** into one authoritative module.\n\n| # | Source | Type | Status | |---|--------|------|--------| | 1 | `core/transliteration/` (Bridge + NkoHandler + ArabicHandler + LatinHandler) | Python — IPA intermediary arch | **Primary source** — most structured | | 2 | `core/prediction/translation_bridge.py` | Python — keyboard-ai with dictionary + SQLite | Superseded (duplicate transliteration logic) | | 3 | `tools/telegram-bot/bridge_core.py` | Python — standalone fallback bridge | Superseded | | 4 | `tools/pwa/js/bridge-core.js` | JavaScript — client-side bridge | Reference only (JS, different runtime) | | 5 | `core/audio/phoneme.py` | Python — PhonemeMapper with char maps | Phoneme maps referenced | | 6 | `core/pipeline/stages.py` | Python — TransliterationStage wrapping Bridge | Pipeline consumer, not source |\n\n**Canonical source chosen:** `core/transliteration/` — best architecture (IPA intermediary), most complete character maps, cleanest separation of concerns. Enhanced with corrections from other implementations.\n\n| Direction | Status | |-----------|--------| | N'Ko → Latin | ✅ Full (7 vowels, 19+ consonants, digits, tone marks, punctuation) | | Latin → N'Ko | ✅ Full (single chars + digraphs: ny, ng, gb, ch, sh, dj, rr) | | N'Ko → Arabic | ✅ Via IPA intermediary | | Arabic → N'Ko | ✅ Via IPA intermediary | | Arabic → Latin | ✅ Full Arabic consonants + vowel diacritics | | Latin → Arabic | ✅ Via IPA intermediary | | Script detection | ✅ Unicode-range voting (NKO: U+07C0-07FF, Arabic: U+0600-06FF+) |\n\n- **7 vowels:** ߊ(a) ߋ(o) ߌ(i) ߍ(e) ߎ(u) ߏ(ɔ) ߐ(ɛ) - **19 consonants:** ߒ(n) ߓ(b) ߔ(p) ߕ(t) ߖ(dʒ) ߗ(tʃ) ߘ(d) ߙ(r) ߚ(rr) ߛ(s) ߜ(gb) ߝ(f) ߞ(k) ߟ(l) ߡ(m) ߢ(ɲ) ߣ(n) ߤ(h) ߥ(w) ߦ(j) ߧ(ŋ) - **3 alternates:** ߠ(na) ߨ(p) ߩ(r) ߪ(s) - **10 digits:** ߀-߉ - **5 tone marks:** ߫(high) ߬(low) ߭(falling) ߮(rising) ߯(long) - **4 punctuation:** ߸(,) ߹(.) ߷(!) ߺ(-) - **2 combining:** ߲(nasalization) ߳(tilde)", "htmlHref": "/research/html/nko-1-3-complete-nko-transliterate-canonical-engine-1djqwuy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 854 }, { "id": "nko-1-5-complete-merge-morphology-1v10vks", "title": "NKO-1.5 Complete — Merge Morphology ✅", "slug": "nko-1-5-complete-merge-morphology", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-1.5-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Task:** Merge morphology — combine cross-script-bridge/morphology + keyboard-ai/morphological_engine **Status:** DONE **Date:** 2025-07-19", "excerpt": "**Task:** Merge morphology — combine cross-script-bridge/morphology + keyboard-ai/morphological_engine **Status:** DONE **Date:** 2025-07-19\n\n### Source 1: `core/morphology/morphology/` (cross-script-bridge) | File | What It Does | Lines | Merged | |------|-------------|-------|--------| | `analyzer.py` | MorphologicalAnalyzer — word decomposition, verb/noun matching, cross-script normalization, sentence analysis, interlinear glossing | ~350 | ✅ Full | | `conjugator.py` | VerbConjugator — 9 TAM particles × 6 person-numbers, tri-script output, full paradigm generation | ~250 | ✅ Full | | `compound_splitter.py` | CompoundSplitter — 14 known compounds, greedy longest-match decomposition, compound type classification | ~300 | ✅ Full | | `tone_engine.py` | ToneEngine — tone extraction, minimal pairs, cross-script tone preservation | ~300 | Referenced (TonePattern enum exposed) | | `cli.py` | CLI interface for all morphology commands | ~200 | N/A (CLI stays in core) |\n\n### Source 2: `core/prediction/morphological_engine.py` (keyboard-ai) | Component | What It Does | Merged | |-----------|-------------|--------| | `MandingMorphologyAnalyzer` | Prefix/suffix/root tables (VERBAL_SUFFIXES, NOMINAL_SUFFIXES, PREFIXES, ROOT_DICTIONARY), morpheme prediction | ✅ Affix tables merged into AffixInventory; root dictionary merged into analyzer | | `CodeSwitchingDetector` | French/English/N'Ko detection | Not merged (prediction-layer concern, not morphology) | | `CulturalCalendarEngine` | Islamic calendar + agricultural seasons | Not merged (belongs in nko.culture) | | `Gen63MorphologicalEngine` | Unified wrapper | Superseded by nko.morphology API |\n\n### Classes | Class | Purpose | |-------|---------| | `MorphologicalAnalyzer` | Word/sentence analysis, script detection, root extraction, noun class detection | | `VerbConjugator` | Manding verb phrase generation (9 tenses × 6 persons × 3 scripts) | | `CompoundDetector` | Compound word recognition, splitting, hypothetical generation | | `AffixInventory` | Static catalogue of all known Manding prefixes, suffixes, postpositions |\n\n### Enums `MorphemeType` · `NounClass` (11 classes) · `TenseAspect` (9 values) · `PersonNumber` (6 values) · `CompoundType` (8 types) · `TonePattern`", "htmlHref": "/research/html/nko-1-5-complete-merge-morphology-1v10vks.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 645 }, { "id": "nko-2-1-complete-swift-phonetics-port-1a2zvk9", "title": "NKO-2.1 Complete — Swift Phonetics Port", "slug": "nko-2-1-complete-swift-phonetics-port", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-2.1-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Task:** Port NKoPhonetics — IPA mappings, tone marks, N'Ko Unicode ranges to Swift **Status:** ✅ COMPLETE **Date:** 2026-02-19 **Build:** `swift build` ✅ | `swift test` ✅ (106 tests, 0 failures)", "excerpt": "**Task:** Port NKoPhonetics — IPA mappings, tone marks, N'Ko Unicode ranges to Swift **Status:** ✅ COMPLETE **Date:** 2026-02-19 **Build:** `swift build` ✅ | `swift test` ✅ (106 tests, 0 failures)\n\nNative Swift port of `nko/phonetics.py` (820 lines Python → 1,995 lines Swift across 9 source files + 1 test file). Every class, method, constant, and enum from the Python module has a Swift-idiomatic equivalent.\n\n| File | Lines | Purpose | |------|-------|---------| | `NKoPhonetics.swift` | 386 | Main public API — unified phonetics engine | | `CharacterTables.swift` | 344 | Canonical character data (singleton, O(1) lookup) | | `IPAMapper.swift` | 272 | IPA conversion, reverse mapping, syllabification | | `NKoDataset.swift` | 180 | Codable model for nko-unified.json | | `UnicodeRange.swift` | 137 | Unicode block constants, range checks, script detection | | `CharInfo.swift` | 100 | Immutable character info struct (frozen dataclass equivalent) | | `ToneType.swift` | 76 | Tone type enum with IPA diacritics | | `Phoneme.swift` | 53 | Phoneme struct for TTS pipeline | | `CharCategory.swift` | 38 | Character classification enum | | `PhoneticTests.swift` | 409 | 71 unit tests covering all public API |\n\n**Location:** `shared/SwiftCore/Sources/NKoPhonetics/` **Tests:** `shared/SwiftCore/Tests/PhoneticTests.swift` **Resource:** `shared/SwiftCore/Sources/NKoPhonetics/Resources/nko-unified.json`\n\n- **`CharInfo`** — Immutable struct: `char`, `codepoint`, `code`, `name`, `category`, `ipa`, `latin`, `toneType?`, `digitValue?`, `punctuationEquivalent?` - **`Phoneme`** — Struct: `symbol`, `sourceChar`, `audioHint`, `durationMs`, `tone?` - **`ToneType`** — Enum: `.high`, `.low`, `.rising`, `.long`, `.veryLong`, `.nasal`, `.nasalAlt`, `.mid`, `.unknown` - **`CharCategory`** — Enum: `.vowel`, `.consonant`, `.digit`, `.toneMark`, `.combining`, `.punctuation`, `.other` - **`NKoUnicode`** — Static utilities: `blockStart/End`, `isNKo(_:)`, `detectScript(_:)`, etc. - **`IPAMapper`** — Static methods: `toIPA(_:)`, `toPhonemes(_:)`, `ipaToNKo(_:)`, `syllabifyIPA(_:)` - **`NKoDataset`** — Codable model for nko-unified.json (vocabulary, proverbs, characters, meta)", "htmlHref": "/research/html/nko-2-1-complete-swift-phonetics-port-1a2zvk9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 882 }, { "id": "nko-2-4-complete-nkoprediction-predictive-text-engine-uvuwtm", "title": "NKO-2.4 COMPLETE — NKoPrediction: Predictive Text Engine", "slug": "nko-2-4-complete-nkoprediction-predictive-text-engine", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-2.4-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Task:** NKO-2.4 — Build NKoPrediction — predictive text engine in Swift with CoreML stub **Status:** ✅ COMPLETE **Date:** 2026-02-19 **Wave:** 2 (FINAL TASK)", "excerpt": "**Task:** NKO-2.4 — Build NKoPrediction — predictive text engine in Swift with CoreML stub **Status:** ✅ COMPLETE **Date:** 2026-02-19 **Wave:** 2 (FINAL TASK)\n\nNKoPrediction is the unified predictive text engine that powers the N'Ko keyboard. It orchestrates 6 sub-engines into a single latency-budgeted pipeline that produces context-aware, morphology-informed, culturally-sensitive word and phrase predictions for Manding languages in N'Ko script.\n\n1. **FrequencyPredictor** — Prefix match against 40+ lexicon entries + n-gram continuation 2. **ContextEngine** — Topic detection (8 categories) + Manding SOV grammar analysis → boost scores 3. **MorphologyExpander** — Root extraction via NKoMorphology → suffix expansion candidates 4. **PhoneticFallback** — IPA Levenshtein similarity via NKoPhonetics (when <3 candidates) 5. **CoreML** — Neural inference (when model loaded; stub no-ops for now) 6. **Merge & Rank** — Deduplicate, apply context boosts, filter by minScore, return top-K\n\n| File | Lines | Role | |------|-------|------| | `NKoPrediction.swift` | 415 | Main engine orchestrator, pipeline, merge/rank | | `FrequencyPredictor.swift` | 312 | Lexicon (40+ entries), n-gram seeding, prefix/next-word prediction | | `ContextEngine.swift` | 289 | Topic detection (8 categories), grammar analysis (SOV), contextual boosts | | `SmartCompose.swift` | 317 | Full-phrase completions: greetings, blessings, proverbs, welfare chains, responses | | `CoreMLSlot.swift` | 159 | `NKoLanguageModelProvider` protocol + `CoreMLStub` no-op + `CoreMLStatus` | | `PredictionResult.swift` | 301 | `PredictionCandidate`, `PredictionRequest/Response`, enums (TopicCategory, GrammarExpectation, ComposeIntent, ComposeSuggestion) | | `NGramModel.swift` | 246 | Thread-safe n-gram model (bi/trigram), backoff, prefix search, vocabulary tracking | | **Total source** | **2,039** | | | `PredictionTests.swift` | 358 | 43 tests across 7 test classes |\n\n| Dependency | How Used | |-----------|----------| | **NKoMorphology** | `analyzeWord()` → root extraction; `listSuffixes()` → morpheme expansion candidates | | **NKoPhonetics** | `toIPA()` → phonetic representation; Levenshtein similarity for phonetic fallback |", "htmlHref": "/research/html/nko-2-4-complete-nkoprediction-predictive-text-engine-uvuwtm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1080 }, { "id": "nko-2-5-complete-nkoculture-swift-module-y5q99h", "title": "NKO-2.5 Complete — NKoCulture Swift Module", "slug": "nko-2-5-complete-nkoculture-swift-module", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-2.5-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Task:** Build NKoCulture — proverbs, blessings, cultural calendar in Swift **Status:** ✅ COMPLETE **Date:** 2026-02-19 **Build:** `swift build` ✅ | `swift test` ✅ (35/35 pass, 0 failures)", "excerpt": "**Task:** Build NKoCulture — proverbs, blessings, cultural calendar in Swift **Status:** ✅ COMPLETE **Date:** 2026-02-19 **Build:** `swift build` ✅ | `swift test` ✅ (35/35 pass, 0 failures)\n\nThe `NKoCulture` Swift module — a complete, production-quality Swift Package providing programmatic access to all N'Ko cultural heritage data. Every proverb, blessing, greeting, clan, calendar event, and cultural concept loads correctly from bundled JSON resources.\n\n| Dataset | Expected | Loaded | Status | |---------|----------|--------|--------| | Proverbs | 62 | 62 | ✅ | | Blessings | 29 | 29 | ✅ | | Greetings | 23 | 23 | ✅ | | Clans | 9 | 9 | ✅ | | Calendar Events | 7 | 7 | ✅ | | Cultural Concepts | 12 | 12 | ✅ | | **Total** | **142** | **142** | ✅ |\n\n| Enum | Values | |------|--------| | `BlessingCategory` | `.blessing`, `.condolence`, `.congratulation`, `.apology`, `.farewell`, `.response` | | `LifeEvent` | `.general`, `.birth`, `.namingCeremony`, `.wedding`, `.death`, `.illness`, `.journey`, `.eid`, `.ramadan`, `.achievement`, `.reunion` | | `GreetingPhase` | `.opening`, `.response`, `.welfare`, `.family`, `.work`, `.closing`, `.blessing` | | `SpeakerRole` | `.initiator`, `.responder` | | `TimeContext` | `.morning`, `.afternoon`, `.evening`, `.night`, `.general` | | `ConceptType` | `.concept`, `.title`, `.kinship`, `.lifeEventsReference` |\n\n- **Thread-safe:** `NSLock` protects all lazy-loaded caches - **Sendable:** All models are `Sendable` for Swift concurrency - **Lazy loading:** Data only loads on first access per dataset - **Zero copy:** JSON resources bundled via SPM `.process(\"Resources\")` - **Faithful to Python:** API mirrors `nko/culture.py` (230 lines) but adds Swift-idiomatic features (enums, Codable, computed properties) - **Life event detection:** `detectLifeEventBlessings(from:)` scans text for life events in English and N'Ko, returns culturally appropriate blessings - **Greeting protocol:** Preserves Manding multi-turn greeting structure (OPENING → RESPONSE → WELFARE → FAMILY → CLOSING → BLESSING)", "htmlHref": "/research/html/nko-2-5-complete-nkoculture-swift-module-y5q99h.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 923 }, { "id": "nko-3-2-complete-nko-keyboard-extension-kd2ucj", "title": "NKO-3.2 Complete — N'Ko Keyboard Extension", "slug": "nko-3-2-complete-nko-keyboard-extension", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-3.2-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Task:** Build keyboard extension — N'Ko input with predictive text **Status:** ✅ Complete **Date:** 2025-02-19 **Tests:** 372/372 passing (0 failures)", "excerpt": "**Task:** Build keyboard extension — N'Ko input with predictive text **Status:** ✅ Complete **Date:** 2025-02-19 **Tests:** 372/372 passing (0 failures)\n\nA production-quality iOS Custom Keyboard Extension for N'Ko script input, powered by the NKoKeyboardEngine prediction pipeline.\n\n| File | Lines | Description | |------|-------|-------------| | `ios/NKoKeyboardExtension/KeyboardViewController.swift` | 948 | Main UIInputViewController — all keyboard logic | | `ios/NKoKeyboardExtension/KeyboardLayout.swift` | 399 | Layout models, key definitions, long-press alternates | | `ios/NKoKeyboardExtension/KeyboardTheme.swift` | 231 | Light/dark adaptive theme with N'Ko cultural palette | | `ios/NKoKeyboardExtension/HapticsManager.swift` | 94 | Pre-warmed haptic feedback with adaptive intensity | | `ios/NKoKeyboardExtension/Info.plist` | 44 | Extension config (PrimaryLanguage: nqo, RTL, OpenAccess) | | `ios/NKoKeyboard/NKoKeyboardApp.swift` | 761 | Companion app (setup, test area, prediction demo, reference) | | **Total keyboard UI** | **2,433** | |\n\nStandard QWERTY layout. Latin keystrokes are transliterated to N'Ko in real-time through the IPA intermediary pipeline:\n\n- Digraphs detected automatically: `ny`→ߢ, `gb`→ߜ, `ch`→ߗ, `dj`→ߖ, `ng`→ߧ, `rr`→ߚ - Shift key with double-tap caps lock - Long-press for accented Latin characters (à, é, ñ, ŋ, ɛ, ɔ)", "htmlHref": "/research/html/nko-3-2-complete-nko-keyboard-extension-kd2ucj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1232 }, { "id": "nko-4-2-complete-coreml-prediction-model-from-corpus-2jcblm", "title": "NKO-4.2 COMPLETE — CoreML Prediction Model from Corpus", "slug": "nko-4-2-complete-coreml-prediction-model-from-corpus", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-4.2-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Trained an interpolated n-gram language model from the N'Ko corpus, exported it to CoreML format, created Swift integration code, and evaluated prediction quality. The model provides real-time next-word prediction for the N'Ko keyboard.", "excerpt": "Trained an interpolated n-gram language model from the N'Ko corpus, exported it to CoreML format, created Swift integration code, and evaluated prediction quality. The model provides real-time next-word prediction for the N'Ko keyboard.\n\n### Interpolated Trigram Model (Primary) - **Type:** Interpolated trigram/bigram/unigram with add-k smoothing - **Formula:** `P(w|w₋₂, w₋₁) = λ₃·P_tri + λ₂·P_bi + λ₁·P_uni` - **Weights:** λ₃=0.55, λ₂=0.30, λ₁=0.15, add_k=0.01 - **Rationale:** With ~4.7K sentences / ~34K tokens, a well-tuned n-gram model outperforms any neural approach. The interpolation provides graceful backoff from trigram → bigram → unigram for unseen contexts.\n\n### CoreML Neural Model (Secondary) - **Type:** Embedding + Dense + Softmax - **Input:** Two word indices (bigram context) - **Architecture:** 2×Embedding(3001→32) → Concat(64) → Dense(64→3000) → Softmax - **Training:** 20 epochs SGD distillation from n-gram statistics - **Size:** 1.5 MB (.mlmodel)\n\n| Metric | Value | |--------|-------| | Total sentences | 4,650 | | Sentences ≥2 words | 3,377 | | Total tokens | 33,932 | | Vocabulary size | 7,364 | | Unique bigram contexts | 7,363 | | Unique trigram contexts | 20,869 | | Train/test split | 90%/10% (3,039/338) |\n\n| Metric | Value | |--------|-------| | **Top-1 Accuracy** | **13.4%** | | **Top-3 Accuracy** | **22.9%** | | Top-5 Accuracy | 27.8% | | Top-10 Accuracy | 35.6% | | Mean Reciprocal Rank (MRR) | 0.1965 | | Perplexity (test) | 673.59 | | Perplexity (train sample) | 73.87 |", "htmlHref": "/research/html/nko-4-2-complete-coreml-prediction-model-from-corpus-2jcblm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 844 }, { "id": "nko-4-3-speakflow-voice-engine-integration-ita5f9", "title": "NKO-4.3 — SpeakFlow Voice Engine Integration", "slug": "nko-4-3-speakflow-voice-engine-integration", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-4.3-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Status:** ✅ COMPLETE **Build:** ✅ BUILD SUCCEEDED (zero errors, iPhone 17 Pro Simulator, iOS 26.2) **Date:** 2025-07-19", "excerpt": "**Status:** ✅ COMPLETE **Build:** ✅ BUILD SUCCEEDED (zero errors, iPhone 17 Pro Simulator, iOS 26.2) **Date:** 2025-07-19\n\nVoice-to-N'Ko transliteration module for the ߒߞߏ Bridge iOS app. Speak Manding, see N'Ko script in real-time.\n\n| File | Change | |------|--------| | `ios/NKoBridge/BridgeView.swift` | Added mic button to input field + voice sheet | | `ios/NKoBridge/Info.plist` | Added NSMicrophoneUsageDescription, NSSpeechRecognitionUsageDescription | | `ios/NKoBridge/NKoBridge.xcodeproj/project.pbxproj` | Added Voice group + 3 source files + fixed missing files |\n\n| Locale | Language | Status | Notes | |--------|----------|--------|-------| | `bm-ML` | Bambara (Mali) | ❌ Not available (as of iOS 18) | Apple has not added Bambara | | `bm` | Bambara (generic) | ❌ Not available | No Bambara support at all | | `fr-ML` | French (Mali) | ⚠️ May not be available on all devices | Regional French variant | | `fr-FR` | French (France) | ✅ Available + offline model | **Primary fallback** | | `en-US` | English (US) | ✅ Available + offline model | Ultimate fallback |\n\n1. **French (fr-FR) as primary recognizer** — All Manding speakers in West Africa speak French as L2. The recognizer handles Manding words reasonably well since many are loan words or phonetically close.", "htmlHref": "/research/html/nko-4-3-speakflow-voice-engine-integration-ita5f9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 790 }, { "id": "nko-5-1-testflight-build-bridge-1t5x0t0", "title": "NKO-5.1: TestFlight Build — ߒߞߏ Bridge", "slug": "nko-5-1-testflight-build-bridge", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-5.1-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Item | Value | |------|-------| | **App Name** | N'Ko Bridge | | **Bundle ID** | `com.openclaw.nko-bridge` | | **Extension Bundle ID** | `com.openclaw.nko-bridge.keyboard` | | **Version** | 1.0.0 (Build 1) | | **Deployment Target** | iOS 17.0 | | **Architecture** | arm64 | | **Xcode** | 26.2 (Build 17C52) | | **Swift** | 5.9 | | **Team ID** | 8643C988C4 (Mohamed Diomande) | | **Signing Identity** | Apple Development: [email] (5HUVWWUKW3) | | **Distribution Cert** | Apple Distribution: Mohamed Diomande (8643C988C4", "excerpt": "**Status:** ✅ ARCHIVE SUCCEEDED — Ready for TestFlight upload **Completed:** 2026-02-19T18:44:00-05:00\n\n| Item | Value | |------|-------| | **App Name** | N'Ko Bridge | | **Bundle ID** | `com.openclaw.nko-bridge` | | **Extension Bundle ID** | `com.openclaw.nko-bridge.keyboard` | | **Version** | 1.0.0 (Build 1) | | **Deployment Target** | iOS 17.0 | | **Architecture** | arm64 | | **Xcode** | 26.2 (Build 17C52) | | **Swift** | 5.9 | | **Team ID** | 8643C988C4 (Mohamed Diomande) | | **Signing Identity** | Apple Development: [email] (5HUVWWUKW3) | | **Distribution Cert** | Apple Distribution: Mohamed Diomande (8643C988C4) ✅ Available | | **Archive Size** | 22MB | | **IPA Size** | ~1.2MB | | **Build Errors** | 0 | | **Build Warnings** | 8 (all deprecation, non-blocking) |\n\n### 1. Xcode Project Verification & Repair - Found existing `NKoBridge.xcodeproj` at `Desktop/NKo/ios/` with only the app target - Keyboard extension (`NKoKeyboardExtension/`) existed as source but was NOT wired into the project - **Regenerated** project using XcodeGen with updated `project.yml` containing both targets: - `NKoBridge` (application) — depends on NKoTransliteration, NKoPhonetics, NKoCulture packages - `NKoKeyboardExtension` (app-extension) — depends on NKoKeyboardEngine package - All SPM packages resolve from root `Desktop/NKo/Package.swift` (NKoCore monorepo)\n\n### 2. Build Fixes Applied - **Fixed compilation error** in `KeyboardViewController.swift:588` — replaced convoluted `allSatisfy` closure with clean tone mark range check `(0x07EB...0x07F3)` - **Fixed version mismatch** — keyboard extension `CFBundleShortVersionString` changed from `1.0` to `1.0.0` to match containing app\n\n### 4. Archive Contents Verified - ✅ `NKoBridge` binary (1.8MB arm64) - ✅ `NKoKeyboardExtension.appex` embedded in `PlugIns/` - ✅ App icon (1024x1024 universal + device-specific variants) - ✅ Cultural resources bundled: proverbs, blessings, calendar, clans, greetings, concepts (6 JSON files) - ✅ Phonetics data (`nko-unified.json`) in both app and extension - ✅ dSYMs for both targets (crash symbolication ready) - ✅ Code signed (development profile) - ✅ Provisioning profiles embedded", "htmlHref": "/research/html/nko-5-1-testflight-build-bridge-1t5x0t0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1202 }, { "id": "nko-5-3-complete-pwa-chrome-extension-telegram-bot-16j3hhy", "title": "NKO-5.3 COMPLETE — PWA + Chrome Extension + Telegram Bot", "slug": "nko-5-3-complete-pwa-chrome-extension-telegram-bot", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-5.3-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Pure client-side transliteration** — works fully offline via a JavaScript port of the Python `nko.transliterate` engine.", "excerpt": "**Status:** ✅ COMPLETE **Date:** 2025-02-19 **Task:** Launch web/platform tools using the `nko` Python backend\n\n**Pure client-side transliteration** — works fully offline via a JavaScript port of the Python `nko.transliterate` engine.\n\n| File | Purpose | |------|---------| | `index.html` | Single-page app — dark theme, mobile-responsive | | `nko-engine.js` | **Pure JS transliteration engine** — complete port of Python maps (N'Ko↔IPA↔Latin↔Arabic), longest-match algorithm, script detection | | `app.js` | App controller — real-time input handling, copy-to-clipboard, install prompt | | `sw.js` | Service worker — offline caching, cache-first strategy | | `manifest.json` | PWA manifest — installable on mobile/desktop | | `server.py` | **Optional** FastAPI backend with REST API (transliterate, analyze, proverbs) | | `icons/` | SVG + PNG icons (16, 48, 128, 192, 512px) |\n\n**Features:** - Type in any script → see all 3 (N'Ko, Latin, Arabic) + IPA instantly - Auto script detection (badge updates live) - One-click copy per output - Offline-capable after first load - Installable as a standalone app - Optional FastAPI server with 7 API endpoints\n\n**Verified:** JS engine tested — `salam` → `ߛߊߟߊߡ`, `ߒߞߏ` → `nkɔ`, `hello` → `ߤߍߟߟߋ` ✅", "htmlHref": "/research/html/nko-5-3-complete-pwa-chrome-extension-telegram-bot-16j3hhy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 864 }, { "id": "app-evolution-protocol-standardized-dispatch-pipeline-1pus7km", "title": "App Evolution Protocol — Standardized Dispatch Pipeline", "slug": "app-evolution-protocol-standardized-dispatch-pipeline", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/agent-swarm/APP-EVOLUTION-PROTOCOL.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Level | Requirements | Dispatch? | |-------|-------------|-----------| | L0 | Git repo exists | No | | L1 | CLAUDE.md (50+ lines) | No | | L2 | EVOLUTION.md (15+ tasks) | Manual only | | L3 | GitHub webhook wired to swarm | Auto-dispatch | | L4 | CI/CD pipeline (TestFlight) | Full automation |", "excerpt": "Every app in the portfolio follows this protocol to become dispatch-ready for Agent Swarm.\n\n| Level | Requirements | Dispatch? | |-------|-------------|-----------| | L0 | Git repo exists | No | | L1 | CLAUDE.md (50+ lines) | No | | L2 | EVOLUTION.md (15+ tasks) | Manual only | | L3 | GitHub webhook wired to swarm | Auto-dispatch | | L4 | CI/CD pipeline (TestFlight) | Full automation |\n\nThe swarm daemon picks up `issues.opened` events with `swarm` label and auto-dispatches.\n\nTier 1 (revenue + users): Spore, SpeakFlow, CreativeDirector Tier 2 (platform): OpenClawHub, SecuriClaw, Aura Tier 3 (ecosystem): agent-swarm, agent-intelligence, creator-shield Tier 4 (Trajectory Bloom): 14 Wave 3 apps Tier 5 (experimental): remaining apps", "htmlHref": "/research/html/app-evolution-protocol-standardized-dispatch-pipeline-1pus7km.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 379 }, { "id": "agent-router-convergence-broker-1nad666", "title": "Agent Router -- Convergence Broker", "slug": "agent-router-convergence-broker", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/convergence-broker/agent-router.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The agent router decides which AI agent handles a given task. It scores complexity, checks rate limits, and falls back through a priority chain when the preferred agent is unavailable.", "excerpt": "The agent router decides which AI agent handles a given task. It scores complexity, checks rate limits, and falls back through a priority chain when the preferred agent is unavailable.\n\nEach agent has a domain where it performs best. The router matches task characteristics to agent strengths.\n\n### Claude Opus - Complex architecture decisions spanning multiple systems - iOS SwiftUI development (TCA, navigation, async patterns) - Multi-file refactors that require full codebase context - System design, protocol definitions, cross-service integration - Creative writing, naming, brand voice work - Tasks requiring 100K+ context windows\n\n### Claude Sonnet - Standard feature implementation (single module, 2-5 files) - Code review and quality analysis - Bug investigation with moderate context needs - Documentation generation from code - Test suite creation for existing modules - Prompt engineering and template refinement\n\n### Codex (OpenAI) - Focused single-file code changes with clear specs - Test writing from function signatures - Linting fixes, formatting, mechanical refactors - Dependency version bumps with migration - Regex construction, data transformation scripts - Tasks with well-defined input/output contracts", "htmlHref": "/research/html/agent-router-convergence-broker-1nad666.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1079 }, { "id": "echeloncapture-restructuring-plan-birgdw", "title": "📱 EchelonCapture Restructuring Plan", "slug": "echeloncapture-restructuring-plan", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/_archive/2024-12/ECHELON_CAPTURE_RESTRUCTURING.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date**: December 21, 2025 **Status**: 🔄 Planning Phase **Context**: Multi-sensor ecosystem with Mocopi + Strudel music generation", "excerpt": "**Date**: December 21, 2025 **Status**: 🔄 Planning Phase **Context**: Multi-sensor ecosystem with Mocopi + Strudel music generation\n\nWith the addition of Sony Mocopi sensors (6 body-mounted IMUs) and the existing **Strudel music generation engine**, we need to restructure **EchelonCapture** to fit into a coherent multi-sensor, multi-app ecosystem.\n\n### Current Situation - **3 iOS Apps**: EchelonCapture, cc-handguard, TrajectoryOS - **Sensors**: iPhone (2x), Apple Watch, AirPods, **Mocopi (6x new)** - **Music Generation**: Strudel (JavaScript/Web Audio) + optional Neural Audio Server - **Backend**: cc-mcs Cloud Run (Rust) for latent physics + Computational Rehearsal\n\n### Key Question from User > \"what's also to be considered from the iOS perspectives how many iPhone applications are to we to be creating as you know we have Strudel and the music generation just wondering if that should be all together\"\n\n### Answer **Strudel music generation runs in JavaScript (browser or WKWebView).** We have 3 distinct iOS apps with different purposes:", "htmlHref": "/research/html/echeloncapture-restructuring-plan-birgdw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3584 }, { "id": "mapping-system-update-quick-summary-1qla7v5", "title": "Mapping System Update - Quick Summary", "slug": "mapping-system-update-quick-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/MAPPING_UPDATE_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Aspect | Before | After | Change | |--------|--------|-------|--------| | **Total Commands** | ~60 | 450 | +650% | | **Deck 1 Commands** | ~30 | 227 | +657% | | **Deck 2 Commands** | ~30 | 223 | +643% | | **Categories** | 8 | 10 | +2 | | **Voice Synonyms** | ~150 | ~600 | +300% |", "excerpt": "### 1. Converted JSON Mappings to YAML - **Source:** `Mapping/json/decks12_full_mappings.json` - **Output:** `Mapping/commands_full.yaml` - **Result:** 450 commands with full metadata\n\n### 2. Replaced Commands Catalog - **Backed up:** `commands.yaml` → `commands.yaml.backup` - **Updated:** `commands.yaml` with 450 comprehensive commands - **Coverage:** 227 Deck 1 + 223 Deck 2 commands\n\n### 3. Updated Gemini System Instructions - **File 1:** `gemini_listener.py` (original) - **File 2:** `gemini_listener_enhanced.py` (Tier 1 optimizations) - **Added:** Comprehensive command examples across 10+ categories\n\n### 4. Created Tools & Documentation - **Converter:** `Mapping/convert_json_to_yaml.py` - **Guide:** `MAPPING_UPDATE_GUIDE.md` (full documentation) - **Summary:** This file\n\n| Aspect | Before | After | Change | |--------|--------|-------|--------| | **Total Commands** | ~60 | 450 | +650% | | **Deck 1 Commands** | ~30 | 227 | +657% | | **Deck 2 Commands** | ~30 | 223 | +643% | | **Categories** | 8 | 10 | +2 | | **Voice Synonyms** | ~150 | ~600 | +300% |", "htmlHref": "/research/html/mapping-system-update-quick-summary-1qla7v5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1070 }, { "id": "quick-start-voice-control-for-rekordbox-dtrr99", "title": "Quick Start - Voice Control for Rekordbox", "slug": "quick-start-voice-control-for-rekordbox", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/QUICK_START_VOICE_CONTROL.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Enhanced (Recommended):** ```bash cd [home]/Desktop/Computational\\ Choreography/computational-studio/studio ./START_REKORDBOX_VOICE_GEMINI_ENHANCED.sh ```", "excerpt": "Your voice control system has been updated with **450 commands** covering all Rekordbox operations.\n\n- Open Rekordbox - Switch to **Performance Mode** (DJ mode) - Load tracks on both decks\n\n### Coverage - **450 total commands** (was ~60) - **227 Deck 1 commands** (left) - **223 Deck 2 commands** (right) - **10 categories** fully supported\n\n### Categories Available 1. ✅ **Transport** (170 commands) - Play, pause, cue, reverse, navigation 2. ✅ **Loop** (72 commands) - Manual loops, beat loops, halve/double 3. ✅ **Sync/Tempo** (38 commands) - Beat sync, tempo adjust, pitch bend 4. ✅ **Navigation** (120 commands) - Jump, scroll, beat navigation 5. ✅ **Grid** (22 commands) - Memory cues, beatgrid editing 6. ✅ **Library** (10 commands) - Load tracks, search, playlists 7. ✅ **Layout** (6 commands) - Zoom, panels, views 8. ✅ **Sampler** (4 commands) - Sample playback and control 9. ✅ **Mixer** (4 commands) - Crossfader, EQ, filters 10. ✅ **Effects** (4 commands) - FX slots and controls\n\n### Transport | Voice Command | Action | Deck | |---------------|--------|------| | \"play left\" | Play/Pause | Left | | \"play right\" | Play/Pause | Right | | \"cue left deck\" | Set cue point | Left | | \"next track right\" | Load next | Right | | \"slip reverse left\" | Slip reverse | Left |", "htmlHref": "/research/html/quick-start-voice-control-for-rekordbox-dtrr99.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1010 }, { "id": "quick-test-guide-wav2vec2-rekordbox-11jwc1", "title": "Quick Test Guide - Wav2Vec2 + Rekordbox", "slug": "quick-test-guide-wav2vec2-rekordbox", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/TEST_WAV2VEC_QUICK.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**What to expect**: ``` Loading Wav2Vec2 ASR model: facebook/wav2vec2-base-960h ✅ Rekordbox orbiter initialized 🎤 Wav2Vec2 listener started. Speak now...", "excerpt": "### Rekordbox Setup 1. **Launch Rekordbox** in Performance mode (not Export mode) 2. **Load tracks** to Deck 1 and Deck 2 3. **Verify keyboard shortcuts**: - Manually press `Z` → Deck 1 should play/pause - Manually press `N` → Deck 2 should play/pause - Manually press `7` → 4-beat loop on Deck 1\n\n**Verify**: - ✅ ASR transcribes your speech correctly - ✅ Commands map to correct IDs (3006 = Play Left, 3114 = Loop Right) - ✅ Shortcuts match Rekordbox (Z, 7+Shift, etc.) - ✅ Latency < 100ms for mapping\n\n1. **Play Left** - Say: \"play left\" - Expected: Deck 1 plays/pauses - Verify: Audio output changes, waveform moves\n\n2. **Play Right** - Say: \"play right\" - Expected: Deck 2 plays/pauses - Verify: Deck 2 starts playing\n\n3. **Sync Left** - Say: \"sync left\" or \"beat sync left\" - Expected: Deck 1 syncs to Deck 2 - Verify: BPMs match, beatgrids align", "htmlHref": "/research/html/quick-test-guide-wav2vec2-rekordbox-11jwc1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1168 }, { "id": "tier-2-command-macro-system-implementation-summary-1aclvqq", "title": "Tier 2: Command Macro System - Implementation Summary", "slug": "tier-2-command-macro-system-implementation-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/docs/TIER2_MACRO_SYSTEM_SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The **Command Macro System** has been successfully implemented as the first Tier 2 enhancement for the Rekordbox voice control system.", "excerpt": "The **Command Macro System** has been successfully implemented as the first Tier 2 enhancement for the Rekordbox voice control system.\n\n#### Macro Catalog (`rekordbox_macro_catalog.py`) - **MacroSafety**: Dataclass for safety constraints - `confirm_before_execute` (bool) - `cooldown_ms` (int)\n\n- **Macro**: Dataclass for macro definition - `name`: Unique identifier - `description`: Human-readable description - `commands`: List of voice commands - `delays_ms`: Timing control - `safety`: Safety constraints - Auto-validation in `__post_init__()` - Properties: `total_duration_ms`, `command_count`\n\n- **MacroCatalog**: Macro management system - `_load_macros()`: Load from YAML - `get_macro(name)`: Retrieve with name normalization - `list_macros()`: Get all macros - `describe_macro(name)`: Detailed info - `reload()`: Reload from file - `validate_all()`: Comprehensive validation\n\n#### Macro YAML Schema (`Mapping/macros.yaml`) - 8 pre-defined example macros: 1. `drop_sequence` - DJ drop preparation 2. `transition_left_to_right` - Smooth deck transition 3. `save_phrase_markers` - Hot cue phrase marking 4. `emergency_stop` - Immediate stop (with confirmation) 5. `loop_stack` - Nested loop breakdown 6. `sample_cascade` - Sequential sampler triggering 7. `setup_left_deck` - Full deck preparation 8. `quick_mix_in` - Fast transition prep", "htmlHref": "/research/html/tier-2-command-macro-system-implementation-summary-1aclvqq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1462 }, { "id": "improving-wav2vec2-asr-accuracy-for-dj-commands-19nn8th", "title": "Improving Wav2Vec2 ASR Accuracy for DJ Commands", "slug": "improving-wav2vec2-asr-accuracy-for-dj-commands", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/IMPROVE_WAV2VEC_ACCURACY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Wav2Vec2 is misrecognizing DJ commands: - \"play left\" → \"hey laughed\", \"they left\", \"lay left\" - Short, specific phrases are hard for general ASR models", "excerpt": "Wav2Vec2 is misrecognizing DJ commands: - \"play left\" → \"hey laughed\", \"they left\", \"lay left\" - Short, specific phrases are hard for general ASR models\n\n**Pros**: Much better accuracy, still fast **Cons**: Requires additional library\n\n**Pros**: Best accuracy, learns your voice **Cons**: Takes time to record and train\n\n**Pros**: Best balance of accuracy and speed **Cons**: Requires phonetic mapping for each language\n\n**Pros**: Much better accuracy out-of-box **Cons**: Slower (100-300ms vs 60ms), larger model", "htmlHref": "/research/html/improving-wav2vec2-asr-accuracy-for-dj-commands-19nn8th.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1127 }, { "id": "tier-3-whisper-fallback-offline-voice-control-guide-hfn5vw", "title": "Tier 3: Whisper Fallback - Offline Voice Control Guide", "slug": "tier-3-whisper-fallback-offline-voice-control-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/TIER3_WHISPER_FALLBACK_GUIDE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Whisper Fallback** enables the voice control system to work **offline** by automatically switching to a local speech recognition engine (OpenAI Whisper) when the Gemini API is unavailable.", "excerpt": "**Whisper Fallback** enables the voice control system to work **offline** by automatically switching to a local speech recognition engine (OpenAI Whisper) when the Gemini API is unavailable.\n\n**Benefits:** - ✅ Works offline (no internet required) - ✅ Automatic failover (<100ms switch time) - ✅ 99.9% uptime guarantee - ✅ Zero configuration (auto-downloads model) - ✅ Seamless user experience\n\n**What Happens:** 1. System connects to Gemini Live API (primary) 2. Whisper engine loads in background (fallback) 3. Health monitor checks Gemini every 30s 4. If Gemini fails → auto-switch to Whisper 5. If Gemini recovers → auto-switch back\n\n**Failure Detection:** 1. Health monitor pings Gemini every 30s 2. 2 consecutive failures → mark as UNAVAILABLE 3. Trigger switch to Whisper\n\n**Recovery Detection:** 1. Health monitor continues checking 2. 2 consecutive successes → mark as HEALTHY 3. Trigger switch back to Gemini", "htmlHref": "/research/html/tier-3-whisper-fallback-offline-voice-control-guide-hfn5vw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1074 }, { "id": "real-time-voice-control-for-dj-1eott", "title": "Real-Time Voice Control for DJ", "slug": "real-time-voice-control-for-dj", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/VOICE_CONTROL_README.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This will: 1. Calibrate your microphone 2. Start listening continuously 3. Execute keyboard shortcuts when you speak commands 4. Press Ctrl+C to stop", "excerpt": "Then just speak commands like: - \"play left deck\" - \"censor right\" - \"cue 1\" - \"load next track left\"\n\nThis will: 1. Calibrate your microphone 2. Start listening continuously 3. Execute keyboard shortcuts when you speak commands 4. Press Ctrl+C to stop\n\n### Left Deck (Deck A) - **\"play left\"** / \"pause left\" / \"stop left\" → Press W - **\"censor left\"** → Press U - **\"load next left\"** → Alt+W - **\"load previous left\"** → Alt+Q - **\"tempo up left\"** / \"speed up left\" → Press R - **\"tempo down left\"** / \"slow down left\" → Press E - **\"rewind left\"** → Alt+E - **\"fast forward left\"** → Alt+R - **\"cue 1\"** to **\"cue 5\"** → Press 1-5\n\n### Right Deck (Deck B) - **\"play right\"** / \"pause right\" / \"stop right\" → Press S - **\"censor right\"** → Press J - **\"load next right\"** → Alt+S - **\"load previous right\"** → Alt+A - **\"tempo up right\"** / \"speed up right\" → Press F - **\"tempo down right\"** / \"slow down right\" → Press D - **\"rewind right\"** → Alt+D - **\"fast forward right\"** → Alt+F - **\"cue 6\"** to **\"cue 0\"** → Press 6-0\n\n1. **Microphone Input** - Listens to your voice continuously 2. **Speech Recognition** - Uses Google Speech Recognition (free, no API key needed) 3. **Command Matching** - Matches what you said to a command 4. **Keyboard Execution** - Presses the corresponding keyboard shortcut 5. **Serato Responds** - Serato receives the keyboard shortcut and executes the action", "htmlHref": "/research/html/real-time-voice-control-for-dj-1eott.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 649 }, { "id": "echelon-project-plan-1c0jn7h", "title": "Echelon Project Plan", "slug": "echelon-project-plan", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/echelon/echelon_project_plan.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Workspace document requiring curation.", "excerpt": "## 1. Overview - **Goal:** Ship Echelon, a standalone Rust-based motion- and voice-driven performance instrument that can also bridge Serato/Ableton and feed cloud rehearsal services. - **Timeline Baseline:** 24-week program across four releases (Prototype → Alpha → Beta → 1.0) aligned with `Echelon.md` roadmap expectations. - **Success Metrics:** <10 ms audio latency, beat-safe automation, gesture/voice control parity with Episode 1 demos, phrase recommendation latency <5 ms, rehearsal loop turnaround <24 h, NPS ≥40 among pilot DJs.\n\n## 2. Phase Breakdown & Milestones | Phase | Duration | Exit Criteria | Milestone Links | | --- | --- | --- | --- | | Prototype (Weeks 1–6) | Rust audio engine running two decks with limiter; Link clock stubbed | Milestone 1 – Engine Bring-up (`Echelon.md` 133-135) | | Alpha (Weeks 7–12) | Scheduler with Link sync, safety policies, MIDI learn for core actions | Milestone 2 – Scheduler + Link (`Echelon.md` 136-141) | | Beta (Weeks 13–18) | Motion/voice integrations, phrase intelligence online, UI deck lanes | Milestones 3 & 4 (`Echelon.md` 149-150, 142-147) | | Release (Weeks 19–24) | Computational rehearsal loop operational, installer & telemetry ready | Milestone 5 + product polish (`Echelon.md` 151-154, 236-239) |\n\n## 3. Workstreams & Leads - **Audio Engine (Lead: Rust Audio Lead)** - Tasks: cpal/cubeb drivers, node graph, resampling/time-stretch, mixer/mastering (`Echelon.md` 25-31, 45-48). - Dependencies: access to sample libraries, Rubber Band licensing, performance profiling. - **Scheduler & Safety (Lead: Control Systems Lead)** - Tasks: Link integration, quantized intents, deck locks, cooldowns (`COMPLETE_IMPLEMENTATION_SUMMARY.txt` 144-148). - Dependencies: action taxonomy from DJ Agent, Link SDK approval. - **AI Services & Phrase Brain (Lead: AI Services Lead)** - Tasks: wrap Episode 1 embeddings (`EPISODE1_OVERVIEW.py` 27-35), ANN service (<5 ms), whisper-rs intents, DELL bridge. - Dependencies: GPU sidecar infrastructure, model conversion budget. - **Human Interface (Lead: UX Lead + Frontend Engineer)** - Tasks: egui/iced UI (deck lanes, phrase browser, automation curves), MIDI learn UX, telemetry (`Echelon.md` 8-12, 243-254). - Dependencies: scheduler IPC spec, design system, usability testing participants. - **Computational Rehearsal & Cloud (Lead: Data Ops Lead)** - Tasks: reuse logging/replay (`EPISODE1_OVERVIEW.py` 59-62), nightly training pipelines, dashboard updates. - Dependencies: cloud infra budget, data retention policy. - **DevOps & QA (Lead: Platform Lead)** - Tasks: CI/CD, automated latency tests (`COMPLETE_IMPLEMENTATION_SUMMARY.txt` 71-74), crash telemetry, installer packaging. - Dependencies: hardware lab, signing certificates, QA staffing.\n\n## 4. Detailed Schedule (Gantt Outline) - **Weeks 1", "htmlHref": "/research/html/echelon-project-plan-1c0jn7h.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 784 }, { "id": "phase-3-implementation-plan-motion-voice-phrase-intelligence-beta-xruax1", "title": "Phase 3 Implementation Plan – Motion, Voice & Phrase Intelligence (Beta)", "slug": "phase-3-implementation-plan-motion-voice-phrase-intelligence-beta", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/echelon/phases/phase-3-plan.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Timeline:** Weeks 13-18 (6 weeks) **Status:** ~85% Complete - Integration phase in progress **Goal:** Beta release with motion/voice control, phrase recommendations, and UI deck lanes", "excerpt": "## Overview Phase 3 focuses on integrating motion and voice control, implementing phrase intelligence with online recommendations, and building the user interface. This phase transforms Echelon from a core audio engine into a complete performance instrument with AI-powered phrase suggestions and gesture/voice control.\n\n**Timeline:** Weeks 13-18 (6 weeks) **Status:** ~85% Complete - Integration phase in progress **Goal:** Beta release with motion/voice control, phrase recommendations, and UI deck lanes\n\n- [x] **13.1 DELL Motion Stream Bridge** - [x] Create `motion-bridge` crate in `echelon/crates/` - [x] Implement `DellMotionReceiver` struct - [x] Connect to Episode 1 motion pipeline (ready, needs API endpoint) - [x] Add `MotionEvent` enum - [x] Map motion events to scheduler actions - **Dependencies:** Episode 1 motion pipeline running - **Deliverable:** ✅ Motion bridge receives Episode 1 data and converts to Echelon events\n\n- [x] **13.2 Motion-to-Action Translator** - [x] Create `MotionTranslator` struct - [x] Implement threshold-based triggers - [x] Map motion gestures to quantized actions - [x] Integrate with `ActionExecutor` - **Dependencies:** Motion bridge (13.1) - **Deliverable:** ✅ Motion gestures trigger deck operations\n\n- [x] **13.3 Motion Calibration** - [x] Implement `MotionCalibrator` for device-specific tuning - [x] Add calibration UI/config - [x] Store calibration data per device - **Deliverable:** ✅ Calibration system allows per-device tuning", "htmlHref": "/research/html/phase-3-implementation-plan-motion-voice-phrase-intelligence-beta-xruax1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1308 }, { "id": "trajectoryos-ios-production-roadmap-13n774i", "title": "TrajectoryOS iOS - Production Roadmap", "slug": "trajectoryos-ios-production-roadmap", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/02-projects/ios-app/PRODUCTION_ROADMAP.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Add new entities to schema: ```swift let schema = Schema([ // Existing LifeStateEntity.self, SkillEntity.self, SkillEvidenceEntity.self, TransitionEntity.self, ProjectEntity.self, ConstraintEntity.self, // NEW - Skills System SkillDecayConfigEntity.self, SkillRelationshipEntity.self, SkillTargetEntity.self, SkillTargetRequirementEntity.self, LearningPathEntity.self, SkillPracticeLogEntity.self, SkillAssessmentEntity.self, SkillDecayAlertEntity.self, ]) ```", "excerpt": "### ✅ Completed - **SwiftData Entities** (7): SkillDecayConfig, SkillRelationship, SkillTarget, LearningPath, SkillPracticeLog, SkillAssessment, SkillDecayAlert - **Services** (6): SkillDecay, SkillRelationship, LearningPath, SkillPractice, SkillAssessment, SkillGraph (facade) - **ViewModel**: SkillsViewModel with @Observable pattern\n\n### 🔴 Critical Gaps for Production 1. No UI views for Skills System 2. New entities not registered in app schema 3. SkillsViewModel uses sample data (not connected to SkillEntity) 4. No navigation to Skills from main app 5. No notifications for decay alerts 6. No backend sync\n\n| View | Purpose | Complexity | |------|---------|------------| | **SkillsDashboardView** | Overview with health score, at-risk skills, recommendations | Medium | | **SkillDetailView** | Single skill detail with decay, practice, relationships | High | | **PracticeLogSheet** | Log practice modal | Low | | **SkillGraphView** | Visual skill relationship graph | High | | **LearningPathsView** | Active paths, gap analysis | Medium | | **AssessmentView** | Take self-assessments | Medium |\n\nTrigger points: - Daily decay check finds critical skill - Skill becomes \"at risk\" status - Streak about to break (no practice yesterday)\n\n### 2.2 Haptics & Animations - Practice logged → Success haptic + confetti animation - Streak milestone reached → Celebration animation - Skill level up → Level-up sound + animation", "htmlHref": "/research/html/trajectoryos-ios-production-roadmap-13n774i.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1338 }, { "id": "directory-organization-summary-y9sfjj", "title": "Directory Organization Summary", "slug": "directory-organization-summary", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/05-research/DIRECTORY_CONSOLIDATION_STATUS.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Moved**: All UI components to Episode 1 - `dashboard.py` - Episode 1-specific dashboard (two-device balance, coherence, trajectories) - `audio_viz.py` - Audio visualization utilities - `gps_viz.py` - GPS visualization utilities", "excerpt": "**Moved**: All UI components to Episode 1 - `dashboard.py` - Episode 1-specific dashboard (two-device balance, coherence, trajectories) - `audio_viz.py` - Audio visualization utilities - `gps_viz.py` - GPS visualization utilities\n\n**`fusion/` directory contains**: - `phase_lock.py` - Has both `PhaseLock` (general) and `DualPhaseLock` (Episode 1-specific) - `transformer.py` - ✅ Duplicate of `cc-core/cc_core/fusion/transformer.py` - `ekf.py` - ✅ Duplicate of `cc-core/cc_core/fusion/ekf.py`\n\n**`cc-core/cc_core/fusion/` already contains**: - `phase_lock.py` - Has `PhaseLock` (general-purpose) ✅ - `transformer.py` - ✅ - `ekf.py` - ✅\n\n**`episode1/control/` already contains**: - `dual_phase_lock.py` - Episode 1-specific `DualPhaseLock` ✅ - `balance.py` - Episode 1-specific `BalanceFuser` ✅\n\n**Files importing from `fusion/`**: - `tests/test_fusion.py` - `from fusion.balance import BalanceFuser` - `tests/test_performance.py` - `from fusion.balance import BalanceFuser` - `tests/test_ep1_pll.py` - `from fusion.phase_lock import PhaseLock` - `tests/test_ep1_balance.py` - `from fusion.balance import BalanceFuser` - `scripts/replay_episode1_session.py` - `from fusion.balance import BalanceFuser` - `scripts/run_episode1.py` - `from fusion.balance import BalanceFuser`, `from fusion.phase_lock import PhaseLock` - `inference/controller/episode1_controller.py` - `from fusion.balance import BalanceFuser`, `from fusion.phase_lock import PhaseLock, DualPhaseLock` - `inference/run_episode1_offline.py` - `from fusion.balance import BalanceFuser`", "htmlHref": "/research/html/directory-organization-summary-y9sfjj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 452 }, { "id": "metamorphosis-unified-agent-os-summary-report-1f8jn81", "title": "METAMORPHOSIS: Unified Agent OS — Summary Report", "slug": "metamorphosis-unified-agent-os-summary-report", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/dream-metamorphosis/unified-agent-os/SUMMARY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| System | Current State | UAOS Role | |---|---|---| | **Pulse v3** | `dual_runner.py` + MCP server + session JSONs | Development engine — executes autonomous dev sessions | | **Heartbeat v2** | `HEARTBEAT.md` + state JSON + main agent polling | Monitoring layer — periodic checks, alerts, proactive work | | **Dream Weaver / Noosphere** | `incubator.py` + `noosphere.py` + daemon + MCP + GitHub Actions engine | Incubation engine — idea exploration, evolution, emergence | | **Cadence** | `cadence_bridge.py` + governan", "excerpt": "> **Dream ID:** dream_202601291857_a242e7 > **Status:** ✅ Design Complete > **Date:** 2025-02-09\n\nA **Unified Agent OS (UAOS)** that merges four currently separate systems into one cohesive platform:\n\n| System | Current State | UAOS Role | |---|---|---| | **Pulse v3** | `dual_runner.py` + MCP server + session JSONs | Development engine — executes autonomous dev sessions | | **Heartbeat v2** | `HEARTBEAT.md` + state JSON + main agent polling | Monitoring layer — periodic checks, alerts, proactive work | | **Dream Weaver / Noosphere** | `incubator.py` + `noosphere.py` + daemon + MCP + GitHub Actions engine | Incubation engine — idea exploration, evolution, emergence | | **Cadence** | `cadence_bridge.py` + governance markdown + Supabase sync | Orchestration layer — multi-agent coordination, priority routing |\n\n### 1. SQLite as the Unified State Store Instead of scattered JSON files (`sessions/*.json`, `dreams.json`, `heartbeat-state.json`) and ad-hoc bridges (`noosphere_bridge.py`), a single SQLite database (`[home-path]`) holds all state. JSON blobs are used for subsystem-specific fields to maintain flexibility.\n\n### 2. Event Bus Over File Watching Systems currently discover each other's state by reading files. UAOS introduces an event bus with defined topics (`pulse.iteration.completed`, `dream.emerged`, `heartbeat.alert`, etc.). Cross-system reactions are registered as event listeners, not embedded in each system's code.", "htmlHref": "/research/html/metamorphosis-unified-agent-os-summary-report-1f8jn81.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 761 }, { "id": "graph-kernel-kimi-k2-memory-integration-11v7f28", "title": "Graph Kernel + Kimi-K2 Memory Integration", "slug": "graph-kernel-kimi-k2-memory-integration", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/dream-weaver-engine/docs/GRAPH_KERNEL_INTEGRATION.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Connect Comp-Core's Graph Kernel and RAG++ to the Kimi-K2 memory layer, enabling: - **Slice-conditioned synthesis** — Context slicing for focused responses - **Knowledge graph integration** — Semantic relationships from Graph Kernel - **Dual-plane retrieval** — Raw messages + semantic atoms", "excerpt": "Connect Comp-Core's Graph Kernel and RAG++ to the Kimi-K2 memory layer, enabling: - **Slice-conditioned synthesis** — Context slicing for focused responses - **Knowledge graph integration** — Semantic relationships from Graph Kernel - **Dual-plane retrieval** — Raw messages + semantic atoms\n\n### 1. Knowledge Graph Sync Kimi-K2 extracts knowledge triples → Graph Kernel stores relationships\n\n### 2. Slice-Conditioned Synthesis Before synthesis, get admissible context slice from Graph Kernel\n\n### 3. RAG++ Retrieval Augmentation Use RAG++ for semantic search when building context\n\n### Phase 1: Local Integration (Current) - [x] SQLite memory store - [x] Knowledge graph table - [ ] Graph Kernel client in Python - [ ] Slice-aware context building", "htmlHref": "/research/html/graph-kernel-kimi-k2-memory-integration-11v7f28.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 526 }, { "id": "generation-5-complete-ini1zn", "title": "Generation 5 Complete", "slug": "generation-5-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/hef-evolutions/agent-reputation-ais-rate-each-others-work-build-t/GENERATION-5-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Task ID:** db728993-7f7e-443f-a4ac-108d91aa78b8 **Instance:** inst_20260131082143_740 **Worker:** vm **Timestamp:** 2026-02-25T11:50:56.983568+00:00 **Exit Code:** 0 **Commit:** 0b083e67baed3bf263afbc749f86705bcfa8ac3b", "excerpt": "**Task ID:** db728993-7f7e-443f-a4ac-108d91aa78b8 **Instance:** inst_20260131082143_740 **Worker:** vm **Timestamp:** 2026-02-25T11:50:56.983568+00:00 **Exit Code:** 0 **Commit:** 0b083e67baed3bf263afbc749f86705bcfa8ac3b", "htmlHref": "/research/html/generation-5-complete-ini1zn.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 416 }, { "id": "generation-6-complete-1b3x363", "title": "Generation 6 Complete", "slug": "generation-6-complete", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/hef-evolutions/motion-autocomplete-ai-predicts-your-next-physical/GENERATION-6-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Task ID:** a62282cd-c475-4f07-ab53-dc0ea43b8360 **Instance:** inst_20260131082128_333 **Worker:** vm **Model:** codex-full-auto **Timestamp:** 2026-02-26T17:07:14.919177+00:00 **Exit Code:** 0 **Commit:** 534e6e54acfdeee8d1fa4fc2717ed4f699e272b8", "excerpt": "**Task ID:** a62282cd-c475-4f07-ab53-dc0ea43b8360 **Instance:** inst_20260131082128_333 **Worker:** vm **Model:** codex-full-auto **Timestamp:** 2026-02-26T17:07:14.919177+00:00 **Exit Code:** 0 **Commit:** 534e6e54acfdeee8d1fa4fc2717ed4f699e272b8", "htmlHref": "/research/html/generation-6-complete-1b3x363.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 136 }, { "id": "generation-6-complete-vpfydk", "title": "Generation 6 Complete", "slug": "generation-6-complete", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/hef-evolutions/weighted-dance-style-train-motion-model-variant-th/GENERATION-6-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Task ID:** 40a133cf-5bc3-4f75-b13f-079c81145694 **Instance:** inst_20260131093817_471 **Worker:** vm **Model:** gemini-sandbox **Timestamp:** 2026-02-26T17:53:49.395255+00:00 **Exit Code:** 0 **Commit:** f8067cbc7cdbbfce4df101c7f63d5c31dabd7a12", "excerpt": "**Task ID:** 40a133cf-5bc3-4f75-b13f-079c81145694 **Instance:** inst_20260131093817_471 **Worker:** vm **Model:** gemini-sandbox **Timestamp:** 2026-02-26T17:53:49.395255+00:00 **Exit Code:** 0 **Commit:** f8067cbc7cdbbfce4df101c7f63d5c31dabd7a12\n\n## Agent Output json { \"status\": \"complete\", \"files_changed\": [ \"EVOLUTION.md\", \"README.md\", \"src/buff_barista/main.py\", \"src/buff_barista/mocap_data.py\", \"src/buff_barista/motion_physics.py\", \"src/buff_barista/neural_network.py\", \"src/buff_barista/train_motion_model.py\" ], \"commits\": [ \"feat(hef): integrate neural network and mocap data for buff barista weighted dance style Gen 7.1\" ], \"quality_score\": 0.96, \"artifacts\": [ \"src/buff_barista/neural_network.py\", \"src/buff_barista/mocap_data.py\", \"src/buff_barista/train_motion_model.py\", \"src/buff_barista/main.py\" ], \"summary\": \"Evolved the Buff Barista weighted dance style to Generation 7.1 by integrating a mock PyTorch-style neural network architecture and synthetic motion capture data generator, enabling a dynamic training and evaluation pipeline.\", \"next_suggestion\": \"Explore 3D visualization of the generated trajectories to visually confirm the 'Buff Barista' style aesthetics, potentially outputting a mock BVH or JSON format animation file.\" }", "htmlHref": "/research/html/generation-6-complete-vpfydk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 126 }, { "id": "nko-lesson-master-plan-implementation-46lux1", "title": "🎓 **N'KO LESSON MASTER PLAN & IMPLEMENTATION**", "slug": "nko-lesson-master-plan-implementation", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "projects/LearnNKo/docs/archive/NKO-LESSON-MASTER-PLAN.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "3. **N'Ko Consonants (Part 1)** 🔄 (25min) - *40% Complete* - First 10 consonants: ߓ ߔ ߕ ߖ ߗ ߘ ߙ ߚ ߛ ߜ - Sound associations - Character recognition", "excerpt": "#### **📚 Module 1: Introduction & History** 1. **Introduction to N'Ko** ✅ (15min) - *100% Complete* - History of Solomana Kanté - Cultural significance - Modern usage\n\n#### **📝 Module 2: Alphabet Mastery** 2. **N'Ko Vowels** 🔄 (20min) - *75% Complete* - 7 vowel characters: ߊ ߍ ߎ ߏ ߐ ߑ ߒ - Pronunciation practice - Recognition exercises\n\n3. **N'Ko Consonants (Part 1)** 🔄 (25min) - *40% Complete* - First 10 consonants: ߓ ߔ ߕ ߖ ߗ ߘ ߙ ߚ ߛ ߜ - Sound associations - Character recognition\n\n4. **N'Ko Consonants (Part 2)** 🔒 (25min) - *Locked* - Remaining 10 consonants: ߝ ߞ ߟ ߠ ߡ ߢ ߣ ߤ ߥ ߦ - Complete alphabet mastery - Character combinations\n\n#### **🎵 Module 3: Advanced Writing** 5. **Tone Marks and Diacritics** 🔒 (30min) - *Locked* - Tone indicators: ߭ ߮ ߯ - Diacritical marks - Pronunciation refinement", "htmlHref": "/research/html/nko-lesson-master-plan-implementation-46lux1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1012 }, { "id": "agp-nko-thunder-train-status-1mwwz5n", "title": "AGP/N'Ko Thunder Train Status", "slug": "agp-nko-thunder-train-status", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "projects/thunder-train/docs/agp-nko-thunder-train-status.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Thunder Train is active again for MLX-based distributed adapter training across Mac4 and Mac5. It applies directly to the Gemma/AGP corrective language layer, including LoRA adapter training and tensor/data parallel experiments.", "excerpt": "Thunder Train is active again for MLX-based distributed adapter training across Mac4 and Mac5. It applies directly to the Gemma/AGP corrective language layer, including LoRA adapter training and tensor/data parallel experiments.\n\nIt does not automatically apply to the current Paper 4 N'Ko ASR checkpoint because that checkpoint is a PyTorch Whisper-large-v3 trajectory model. To use Thunder Train for that layer, the ASR model would need an MLX training/inference port or a separate MLX-compatible acoustic adapter design.\n\n- Mac4: `[ip]`, MLX `0.31.1`, MLX-LM `0.31.2` - Mac5: `[ip]`, MLX `0.31.1`, MLX-LM `0.31.2` - Thunderbolt bridge: - Mac4 -> Mac5: about `0.52ms` - Mac5 -> Mac4: about `0.56ms` - MLX distributed ring smoke: - rank 0 reported `size=2` - rank 1 reported `size=2` - all-sum check passed on both ranks\n\n- Builder: `scripts/build_agp_nko_correction_chatml.py` - Manifest: `data/agp-nko-corrections/manifest.json` - Train rows: `16` - Validation rows: `4` - Source reports: - `policy_smoke_http_fewshot_rust_gate` - `synthetic_http_fewshot_rust_gate` - `eval_results_base_lowcer_http_rust_gate`\n\n- world size: `2` - strategy: `data` - LoRA: rank `8`, last `4` layers - trainable params: `15,877,411` - validation loss: - step 2: `3.7663` - step 4/final: `3.7460` - adapter artifact: - Mac4 rank-0 path: `[home-path]` - mirrored local path: `[home-path]` - size: about `61M`", "htmlHref": "/research/html/agp-nko-thunder-train-status-1mwwz5n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 404 }, { "id": "v5-training-session-handoff-p81bj1", "title": "V5 Training Session Handoff", "slug": "v5-training-session-handoff", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "SESSION-HANDOFF-V5.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Instance | What | Cost | SSH | |----------|------|------|-----| | Vast.ai 33195812 | Cognitive twin SFT/DPO training | $0.97/hr | `[ssh command redacted]` | | Vast.ai 33248108 | V5 mel extraction (tmux \"v5\") | $0.93/hr | `[ssh command redacted]` | | Mac4 monitor | V5 watch (LaunchAgent com.nko.v5-monitor) | free | `ssh -o IdentitiesOnly=yes -i [home-path] mac4` |", "excerpt": "# V5 Training Session Handoff > Updated: 2026-03-21 00:11 EDT > Purpose: Fresh session picks this up with full context, nothing lost\n\n| Instance | What | Cost | SSH | |----------|------|------|-----| | Vast.ai 33195812 | Cognitive twin SFT/DPO training | $0.97/hr | `[ssh command redacted]` | | Vast.ai 33248108 | V5 mel extraction (tmux \"v5\") | $0.93/hr | `[ssh command redacted]` | | Mac4 monitor | V5 watch (LaunchAgent com.nko.v5-monitor) | free | `ssh -o IdentitiesOnly=yes -i [home-path] mac4` |\n\n1. `prepare_v5_data.py` only loads HuggingFace datasets (afvoices + bam-asr-early = 259K samples) 2. It does NOT load any of the local JSONL data files (20K+ pairs on disk) 3. It does NOT run the YouTube OCR pipeline (490+ unprocessed videos) 4. Training script had `total_mem` instead of `total_memory` (fixed 3 times, kept reverting from stale SCPs) 5. Training launched with `--skip-features` but the script requires mel spectrograms to exist 6. Context compaction dropped details between tool calls, causing repeated mistakes\n\n### Audio-paired data (for ASR training): | Source | Samples | Quality | Location | Used in V5? | |--------|---------|---------|----------|-------------| | afvoices (HF) | 253,290 | Whisper-inferred | HuggingFace | YES | | bam-asr-early (HF) | 37,306 | Whisper-inferred | HuggingFace | YES | | Babamamadidiane OCR | 2,577 | **Ground truth** (Gemini vision) | `results/dynamic_ocr/dynamic_pairs.jsonl` | NO | | Babamamadidiane features | 941 | Whisper-inferred | `results/feature_pairs_babamamadidiane.jsonl` | NO | | Djoko pairs | 926 | Whisper-inferred | `results/quebec_djoko_pairs.jsonl` | NO | | Texas pairs | 6,633 | Whisper-inferred | `results/vastai/texas_nko_pairs.jsonl` | NO | | Texas transcriptions | 8,981 | Whisper-inferred | `results/vastai/texas_transcriptions.jsonl` | NO | | Common Voice Bambara | 500 files | Human-verified | `data/common_voice_bm/audio/` | NO | | **Total available** | **~311,000** | | | **259K used** |\n\n### UNPROCESSED YouTube (highest value, ground-truth labels): | Channel | Total videos | Processed | Remaining | |---------|-------------|-----------|-----------| | @babamamadidiane | 532 | ~40 | **490** | | @mamadibabadiane1 | 58 | 0 | **58** | | Djoko | partial | partial | unknown |", "htmlHref": "/research/html/v5-training-session-handoff-p81bj1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1282 }, { "id": "computational-choreography-integration-plan-1nm5l08", "title": "🕺 Computational Choreography Integration Plan", "slug": "computational-choreography-integration-plan", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "spine/Buf Barista/COMPUTATIONAL-CHOREOGRAPHY.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` ┌────────────────────────────────────────────────────────────────────┐ │ THE BUFF BARISTA LOOP │ ├────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────┐ ┌──────────────┐ ┌─────────────┐ │ │ │ MUSIC │ ───> │ CC-MOTIONGEN │ ───> │ CHOREOGRAPHY │ │ │ │ (Input) │ │ (Diffusion) │ │ (Generated) │ │ │ └─────────┘ └──────────────┘ └──────┬──────┘ │ │ │ │ │ ▼ │ │ ┌──────────────┐ │ │ │ PRACTICE │ │ │ │ (iPhone App) │ │ │ └──────┬───────┘ │ │ │ │ │ ┌───────────────────────────────────────", "excerpt": "**Vision:** Auto-generate Zumba choreography using AI + body motion → real-time music generation\n\n### Motion Layer (Rust) | Component | Purpose | Status | |-----------|---------|--------| | `cc-types` | Core motion types (MotionWindow, SkeletonFrame) | ✅ FROZEN | | `cc-anticipation` | Anticipation kernel for choreo | ✅ Complete | | `cc-collection` | Sensor fusion via EKF | ✅ Complete | | `cc-gesture` | Gesture recognition | 🔄 Partial | | `cc-window-aligner` | Motion alignment (5-stage) | ✅ 99.5% |\n\n### ML Layer (Python) | Component | Purpose | Status | |-----------|---------|--------| | `cc-ml/cc_motiongen` | Diffusion-based motion generation | ✅ Substantial | | `diffusion/` | UNet1D (116M params) | ✅ Trained | | `motionphrase/` | Semantic phrase library | 🔄 Building | | `pattern_coder/` | Motion pattern encoding | ✅ Complete |\n\n### Audio Layer | Component | Purpose | Status | |-----------|---------|--------| | `echelon_adapter.py` | Motion → Music control mapping | ✅ Complete | | `choreo_server.py` | Real-time choreo via ZMQ | ✅ Complete | | `LIM-RPS` | 3-timescale latent state solver | ✅ Complete | | Strudel IR | Music generation DSL | ✅ Integrated |\n\n### Supported Genres (for generation) - Reggaeton (BPM: 90-110) - Salsa (BPM: 160-220) - Cumbia (BPM: 80-100) - Merengue (BPM: 120-160) - Bachata (BPM: 120-140) - Afrobeats (BPM: 100-120)", "htmlHref": "/research/html/computational-choreography-integration-plan-1nm5l08.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1063 }, { "id": "buff-flow-motion-capture-setup-guide-1nt8mfw", "title": "Buff Flow — Motion Capture Setup Guide", "slug": "buff-flow-motion-capture-setup-guide", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "spine/Buf Barista/program/MOTION_CAPTURE_SETUP.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This guide covers setting up Sony Mocopi motion capture for Buff Flow sessions. Motion data enables gesture recognition, form feedback, and the computational choreography features in later phases.", "excerpt": "**Document ID:** BUFF-FLOW-MOCAP-001 **Version:** 1.0.0 **Last Updated:** 2026-01-18\n\nThis guide covers setting up Sony Mocopi motion capture for Buff Flow sessions. Motion data enables gesture recognition, form feedback, and the computational choreography features in later phases.\n\n| Item | Model | Purpose | Status | |------|-------|---------|--------| | Motion Sensors | Sony Mocopi (6 IMU) | Full-body tracking | To acquire | | Recording Device | Laptop with cc-mcs | Motion capture server | Available | | Backup Camera | iPhone/iPad | MediaPipe fallback | Available |\n\n| Item | Purpose | Priority | |------|---------|----------| | External SSD (500GB+) | Motion data storage | P1 | | USB-C hub | Charging + data | P2 | | Sensor straps (backup) | Replace worn straps | P3 |\n\nSony Mocopi is a 6-sensor IMU (Inertial Measurement Unit) system that captures full-body motion without cameras. Each sensor tracks rotation and acceleration, and the system reconstructs a 27-bone skeleton.", "htmlHref": "/research/html/buff-flow-motion-capture-setup-guide-1nt8mfw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1542 }, { "id": "meaningful-power-roadmap-k4kl0e", "title": "Meaningful Power — Roadmap", "slug": "meaningful-power-roadmap", "kind": "proposal", "program": "Research Backlog", "sourceAnchor": "spine/Meaning Full Power/ROADMAP.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Document ID:** MFP-ROAD-001 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Reference:** `.project_control/checklists/IMPLEMENTATION_CHECKLIST.md`", "excerpt": "**Document ID:** MFP-ROAD-001 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Reference:** `.project_control/checklists/IMPLEMENTATION_CHECKLIST.md`\n\n| Metric | Value | |--------|-------| | Overall Completion | ~45% | | Status | PAUSED (migration) | | Primary Blocker | Platform decision | | Active Development | Expo scaffold |\n\n- [x] Project Charter (PC-001) - [x] System Glossary (GL-001) - [x] Assumptions & Invariants (AI-001) - [x] Implementation Guide (IG-001) - [x] Implementation Checklist (CL-001) - [x] Source of Truth Directory (ST-001)\n\n- [x] cards.json schema design - [x] CardDataLoader implementation - [x] CardAssetBridge implementation - [x] CardAssets model - [x] Asset preparation script\n\n- [x] Card model - [x] Card view component - [x] Card flip animation - [ ] Card zoom/detail view - [ ] GIF playback optimization", "htmlHref": "/research/html/meaningful-power-roadmap-k4kl0e.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 842 }, { "id": "supabase-edge-functions-nr9yct", "title": "Supabase Edge Functions", "slug": "supabase-edge-functions", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "supabase-skills/skills/supabase-edge-functions/SKILL.md", "extension": "md", "score": 24, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "This skill provides operations for working with Supabase Edge Functions - serverless TypeScript/JavaScript functions that run on Deno Deploy. Use for invoking functions, deploying code, and managing function lifecycles.", "excerpt": "--- name: supabase-edge-functions description: Deploy and manage Supabase Edge Functions. Use for invoking serverless functions, deploying new functions, and managing function deployments. ---\n\nThis skill provides operations for working with Supabase Edge Functions - serverless TypeScript/JavaScript functions that run on Deno Deploy. Use for invoking functions, deploying code, and managing function lifecycles.\n\n**Required tools:** - Supabase CLI (`supabase` command) - Deno (for local development)\n\n**Helper script:** This skill uses the shared Supabase API helper for invoking functions:\n\n| Status | Meaning | |--------|---------| | 200 | Success | | 400 | Bad request (invalid input) | | 401 | Unauthorized (invalid/missing auth) | | 403 | Forbidden (insufficient permissions) | | 500 | Internal server error (function crashed) | | 504 | Gateway timeout (function took too long) |", "htmlHref": "/research/html/supabase-edge-functions-nr9yct.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": true, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1532 }, { "id": "harness-skills-layer-c1h1p3", "title": "Harness Skills Layer", "slug": "harness-skills-layer", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "trajectory-memory-ledger/docs/harness-skills.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The harness skills layer turns executable benchmark deltas into evidence-bound skill packages. It is the local implementation of the useful parts of SkillDAG, SkillOpt, and MUSE-style memory packaging without making an unsafe claim that a failed adapter should be routed automatically.", "excerpt": "The harness skills layer turns executable benchmark deltas into evidence-bound skill packages. It is the local implementation of the useful parts of SkillDAG, SkillOpt, and MUSE-style memory packaging without making an unsafe claim that a failed adapter should be routed automatically.\n\n- public task prompts - canonical task specs - one baseline `executable-task-bench` report - one comparison `executable-task-bench` report\n\n- `trajectory-skills.jsonl`: one structured row per extracted skill family - `skill-graph.json`: typed graph nodes and edges - `router-index.json`: regression-gated routing index - `skillgraph-evolution-report.json`: aggregate comparison report - `packages//SKILL.md`: human-readable activation boundary - `packages//MEMORY.md`: compact task evidence memory - `packages//tests.jsonl`: task-level evidence rows - `packages//failure_modes.json`: quarantine and diagnostic metadata - `packages//skill.json`: full structured package\n\n| Edge | Meaning | |---|---| | `depends_on` | Skill evidence belongs to a specific task set | | `specializes` | Skill applies to a task family such as `path`, `date`, or `parse` | | `repairs` | Comparison passed a task that the baseline failed | | `conflicts_with` | Comparison failed a task that the baseline passed |\n\nThis is deliberately a harness-side graph, not a model-side promise. The graph records where a trajectory delta helped, where it hurt, and which families need repair before routing.", "htmlHref": "/research/html/harness-skills-layer-c1h1p3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1415 }, { "id": "hef-gen-6-evolution-complete-trajectory-mobile-4n3guj", "title": "HEF Gen 6 Evolution Complete — Trajectory Mobile", "slug": "hef-gen-6-evolution-complete-trajectory-mobile", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "trajectory-mobile/HEF-GEN6-COMPLETE.md", "extension": "md", "score": 24, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Instance:** inst_20260131075427_227 **Task:** task_20260225114539_7c72cf **Generation:** 5 → 6 **Completed:** 2026-02-25", "excerpt": "**Instance:** inst_20260131075427_227 **Task:** task_20260225114539_7c72cf **Generation:** 5 → 6 **Completed:** 2026-02-25\n\n### 1. Priority System - **Types:** Added `IdeaPriority` type (`low` | `medium` | `high` | `urgent`) with color-coded config - **IdeaCard:** Colored left border strip indicates priority (gray/blue/orange/red) - **NewIdeaSheet:** 4-button priority picker with color highlights and icons - **Search:** Priority boost in scoring — urgent/high ideas rank higher - **Sort:** Ideas sorted by priority first, then by date - **Widget:** Priority dots shown next to recent ideas (colored circles)\n\n### 2. Categories System - **Types:** Added `IdeaCategory` type with 6 categories: inbox, project, personal, work, creative, research - **HomeScreen:** Horizontal scrolling category tabs above sync filter chips - **NewIdeaSheet:** Grid-style category selector with icons - **IdeaCard:** Category badge shown below text (except 'inbox' which is default) - **Search:** Category filter parameter integrated into `searchIdeas()` - **Widget:** Category icons displayed next to recent ideas\n\n### 3. Swipe Actions on IdeaCard - **PanResponder** for native gesture handling (no external libs) - Swipe left → red \"Delete\" background revealed → delete confirmation - Swipe right → blue \"Edit\" background → enters edit mode - `SWIPE_THRESHOLD` = 80px, with spring animation snap-back - Background action indicators visible during swipe\n\n### 4. Fuzzy Search - **New file:** `src/utils/fuzzySearch.ts` - Levenshtein distance algorithm for fuzzy matching - `fuzzyScore()` returns 0-1 score (exact → contains → prefix → distance) - `findMatchRanges()` returns highlight ranges for UI - `debounce()` utility for search input (300ms) - Search results now show highlighted matched text", "htmlHref": "/research/html/hef-gen-6-evolution-complete-trajectory-mobile-4n3guj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 589 }, { "id": "phase-3-native-desktop-features-wlo27i", "title": "Phase 3: Native Desktop Features ✅", "slug": "phase-3-native-desktop-features", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/trajectory/trajectory-desktop/docs/legacy/PHASE3_COMPLETE.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Phase 3 successfully delivers **native desktop integration** with system tray, notifications, and keyboard shortcuts for TrajectoryOS Desktop.", "excerpt": "**Status**: Complete **Duration**: Phase 3 **Completion Date**: December 21, 2025\n\nPhase 3 successfully delivers **native desktop integration** with system tray, notifications, and keyboard shortcuts for TrajectoryOS Desktop.\n\n1. ✅ **System Tray** - Native tray icon with context menu 2. ✅ **Notifications** - System-level notifications for events 3. ✅ **Keyboard Shortcuts** - Global and in-app shortcuts 4. ✅ **Window Management** - Show/hide/minimize controls 5. ✅ **Tray Integration** - Real-time status indicators\n\n### Notification Types 1. **State Updates**: Escape index changes, regime transitions 2. **Skill Events**: New skills added, level ups 3. **Project Events**: Milestones, completions 4. **Interview Events**: Session completion, skills extracted 5. **Insights**: New insights from AI analysis\n\n**Features:** - Platform-native tray icon (Windows, macOS, Linux) - Context menu with quick actions - Show/hide window controls - Quit application option", "htmlHref": "/research/html/phase-3-native-desktop-features-wlo27i.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1726 }, { "id": "ui-specification-data-pipeline-integration-11yvxo", "title": "UI Specification: Data Pipeline Integration", "slug": "ui-specification-data-pipeline-integration", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/apps/web/cc-dashboard/UI_SPECIFICATION.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "> **For Frontend AI**: This document specifies UI components to implement. **DO NOT modify any files in `/lib/`** - the backend data layer is complete. Your job is strictly UI components and visual presentation.", "excerpt": "> **For Frontend AI**: This document specifies UI components to implement. **DO NOT modify any files in `/lib/`** - the backend data layer is complete. Your job is strictly UI components and visual presentation.\n\n### 1. Play Event Tracking (`/lib/audio/PhrasePlayer.ts`) Every user interaction is automatically tracked to Supabase: - `play_start` - When a phrase begins playing - `play_complete` - When a phrase finishes naturally - `skip` - When user stops before 90% completion - `pause` - When user stops after 90% completion - `crossfade_start` - When transition to next phrase begins - `crossfade_complete` - When transition finishes\n\nEach event includes: - `session_id` - Groups events by browser session - `position_seconds` / `position_pct` - Where in the phrase - `playback_duration_seconds` - How long they listened - `tempo_sync_method` - `'exact'` | `'half_time'` | `'double_time'` | `'none'` - `device_type` - `'mobile'` | `'tablet'` | `'desktop'` - `is_auto` - Whether auto-advance triggered the event\n\n### 2. MediaPipe Capture Storage (`/lib/mediapipe/CaptureStorageService.ts`) Motion capture sessions are stored with: - `mediapipe_sessions` - Session metadata, performer name, tracking quality - `mediapipe_captures` - Frame-by-frame landmark data - `mediapipe_feature_sequences` - Aggregated motion features (body_energy, arm_spread, etc.)\n\n**Location**: Phrase card in list view (both `/phrases/page.tsx` list and any phrase cards)", "htmlHref": "/research/html/ui-specification-data-pipeline-integration-11yvxo.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2095 }, { "id": "command-processor-enhancements-1t4m457", "title": "Command Processor Enhancements", "slug": "command-processor-enhancements", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/core/command_processor.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "All enhancements are backward compatible: - Existing code continues to work - `process_text()` still returns `bool` - Default parameters match original behavior - Optional features can be disabled", "excerpt": "The `CommandProcessor` has been significantly enhanced with a full-featured implementation.\n\n### 1. **Advanced Matching System** - **Confidence Scoring**: Every match includes a confidence score (0.0-1.0) - **Match Types**: EXACT, WORD_BOUNDARY, FUZZY, ALIAS, PARTIAL - **Multi-strategy Matching**: Tries multiple matching strategies in order of preference - **SequenceMatcher**: Uses advanced similarity algorithms for fuzzy matching\n\n### 2. **Command Aliases & Synonyms** - **Built-in Aliases**: Common shortcuts like \"go\" → \"play\", \"cut\" → \"censor\" - **Custom Aliases**: Add your own with `add_alias()` - **Synonyms**: Automatic synonym generation for deck-specific commands - **Alias Expansion**: Automatically expands aliases before matching\n\n### 3. **Command History** - **Execution History**: Tracks last 100 commands with full details - **History Entry**: Includes phrase, key combo, execution time, success status, match type, confidence - **History Access**: `get_history(limit=10)` to retrieve recent commands - **History Clearing**: `clear_history()` to reset\n\n### 4. **Statistics & Metrics** - **Comprehensive Stats**: Total commands, success rate, match type distribution - **Performance Metrics**: Average match time, execution time, min/max times - **Confidence Tracking**: Average confidence across all matches - **Statistics Access**: `get_statistics()` returns full stats dictionary - **Statistics Reset**: `reset_statistics()` to clear all stats", "htmlHref": "/research/html/command-processor-enhancements-1t4m457.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 829 }, { "id": "project-restructuring-december-17-2025-1a7et87", "title": "Project Restructuring - December 17, 2025", "slug": "project-restructuring-december-17-2025", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/docs/guides/MIGRATION_2025-12-17.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Completed comprehensive directory restructuring to create a clean, unified folder structure for TrajectoryOS. This migration consolidates scattered components, archives legacy code, and establishes clear organizational boundaries.", "excerpt": "Completed comprehensive directory restructuring to create a clean, unified folder structure for TrajectoryOS. This migration consolidates scattered components, archives legacy code, and establishes clear organizational boundaries.\n\n#### 1. Apps Consolidation **MERGED**: `apps/web-dashboard` + `services/cc-tpo/cc-navigator` → `apps/web/` - Combined modern Next.js 16 setup from web-dashboard - Integrated navigation components from cc-navigator - Updated package.json with unified dependencies (d3, lucide-react, etc.) - Removed: `apps/api-gateway/` (functionality moved to trajectory-core)\n\n#### 2. Services Cleanup **ARCHIVED**: - `services/cc-tpo/` → `legacy/cc-tpo-original/` - `services/cc-tpo.backup.20251215/` → `legacy/`\n\n**EXTRACTED** from CC-TPO before archiving: - Python packages (ircp, tpo, rcp, dlm) → `packages/` - Database files → `data/databases/`\n\n**KEPT**: Clean, active services only - trajectory-core - ircp-service - agent-orchestrator - background-worker - echelon-bridge", "htmlHref": "/research/html/project-restructuring-december-17-2025-1a7et87.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 942 }, { "id": "cc-chat-conversational-ai-guide-1glhmeg", "title": "CC Chat - Conversational AI Guide", "slug": "cc-chat-conversational-ai-guide", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/CC_CHAT_GUIDE.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "1. **Semantic Search** - Finds 3 most relevant conversations from your knowledge base 2. **Context Injection** - Adds relevant Q&A pairs to your message 3. **OpenAI API** - GPT-4 generates response using your personal context 4. **State Persistence** - Conversation history saved automatically", "excerpt": "**Full conversational AI powered by OpenAI with your personal CC knowledge as context.**\n\n1. **Semantic Search** - Finds 3 most relevant conversations from your knowledge base 2. **Context Injection** - Adds relevant Q&A pairs to your message 3. **OpenAI API** - GPT-4 generates response using your personal context 4. **State Persistence** - Conversation history saved automatically\n\n**System retrieves**: - [Context 1] LIM-RPS architecture explanation from \"Computational choreography audio\" - [Context 2] LIM-RPS vs neural networks from \"Echelon DAW comparison\" - [Context 3] LIM-RPS definition from \"Recursive polymodal synthesis analysis\"\n\n**GPT-4 responds** with an answer synthesized from your personal knowledge + its general understanding.\n\n**Result**: Personalized, accurate response that references YOUR specific work and conversations.", "htmlHref": "/research/html/cc-chat-conversational-ai-guide-1glhmeg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1274 }, { "id": "dlm-integration-quick-reference-zs87bw", "title": "DLM Integration Quick Reference", "slug": "dlm-integration-quick-reference", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/guides/DLM_INTEGRATION_QUICK_REFERENCE.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "| Component | Status | Location | Completion | |-----------|--------|----------|------------| | **IRCP Embedder** | ✅ Complete | `dlm/core/embeddings.py` | 100% | | **IRCP Coordinate Prediction** | ✅ Complete | `dlm/core/embeddings.py` | 100% | | **IRCP Weighting** | ⚠️ Placeholder | `dlm/response/embedding_provider.py` | 20% | | **RCP Integration** | ❌ Missing | N/A | 0% | | **TPO Integration** | ⚠️ Partial | `dlm/core/coordinates.py` | 30% | | **Unified Config** | ✅ Complete | `dlm/config.py` | 100% |", "excerpt": "| Component | Status | Location | Completion | |-----------|--------|----------|------------| | **IRCP Embedder** | ✅ Complete | `dlm/core/embeddings.py` | 100% | | **IRCP Coordinate Prediction** | ✅ Complete | `dlm/core/embeddings.py` | 100% | | **IRCP Weighting** | ⚠️ Placeholder | `dlm/response/embedding_provider.py` | 20% | | **RCP Integration** | ❌ Missing | N/A | 0% | | **TPO Integration** | ⚠️ Partial | `dlm/core/coordinates.py` | 30% | | **Unified Config** | ✅ Complete | `dlm/config.py` | 100% |\n\n### ✅ Already Done - [x] IRCPEmbedder class with coordinate prediction - [x] DLMCoordinate system with IRCP enhancement hooks - [x] Unified configuration system - [x] Base embedding provider interface - [x] IRCP module re-exports\n\n### ⚠️ Needs Implementation - [ ] `_apply_ircp_weighting()` - Use actual IRCP coordinates - [ ] `_apply_temporal_weighting()` - Implement temporal decay - [ ] `_apply_context_awareness()` - Use RCP context flow - [ ] RCP context propagator class - [ ] RCP ring topology builder - [ ] RCP attention mechanism - [ ] RCP flow dynamics solver - [ ] TPO path analyzer - [ ] TPO quality calculator - [ ] TPO preference generator\n\n1. **IRCP → DLM**: Coordinate enhancement in `DLMCoordinateCalculator` 2. **DLM → RCP**: Coordinate usage in `RCPContextPropagator` 3. **RCP → DLM**: Context flow in similarity calculations 4. **TPO → DLM**: Path quality in response generation 5. **All → Similarity**: Multi-dimensional similarity calculation\n\n- [ ] Test IRCP coordinate prediction - [ ] Test IRCP weighting in similarity - [ ] Test temporal weighting - [ ] Test RCP ring topology construction - [ ] Test RCP attention computation - [ ] Test RCP context propagation - [ ] Test TPO path extraction - [ ] Test TPO quality calculation - [ ] Test integrated pipeline", "htmlHref": "/research/html/dlm-integration-quick-reference-zs87bw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1622 }, { "id": "phase-2-1-coordinate-system-unification-1jvx8lw", "title": "Phase 2.1: Coordinate System Unification", "slug": "phase-2-1-coordinate-system-unification", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/PHASE_2_1_COORDINATES.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "Create a unified DLM coordinate system that **enhances and extends** the existing DLM `ChainCoordinate` foundation with the best calculation methods from TPO's `RCPCoordinateSystem`.", "excerpt": "# Phase 2.1: Coordinate System Unification **Week:** 2 **Duration:** 2 days **Status:** ✅ Complete **Dependencies:** None\n\nCreate a unified DLM coordinate system that **enhances and extends** the existing DLM `ChainCoordinate` foundation with the best calculation methods from TPO's `RCPCoordinateSystem`.\n\n**Key Principle:** DLM coordinates are the foundation - we're unifying the calculation logic, not replacing the core concept.\n\n- ✅ Pydantic model with validation - ✅ Has 5 dimensions (x, y, z, t, n_parts) - ✅ Tree structure (parent/children) - ❌ No calculation methods - ❌ No validation logic beyond Pydantic\n\n- ✅ Rich metadata - ✅ Distance calculations - ✅ Comprehensive calculation in `RCPCoordinateSystem` - ✅ Validation with `CoordinateValidator` - ❌ Only 3 dimensions (missing t, n_parts) - ❌ Not a Pydantic model", "htmlHref": "/research/html/phase-2-1-coordinate-system-unification-1jvx8lw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1594 }, { "id": "lume-agent-contracts-v1-im0h9p", "title": "LUME Agent Contracts — v1", "slug": "lume-agent-contracts-v1", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/docs/LUME_AGENT_CONTRACTS.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "**Status:** authoritative as of 2026-05-24. Lock these contracts before parallel agent work continues. If anything below changes, **update this doc first**, then the agents.", "excerpt": "**Status:** authoritative as of 2026-05-24. Lock these contracts before parallel agent work continues. If anything below changes, **update this doc first**, then the agents.\n\nThis document exists because the bar's runtime is forked across three agents (K11 audio, Mac4 visuals/cameras, Mac1 dev) and they will silently drift unless they all code against the same packet schema, IPs, ports, and conventions.\n\n**Mac1** is dev only — not in the live runtime. Its job is the repo, this doc, and ensuring the bridge code is committed.\n\n**Twitch / OBS / NDI / hotspot are explicitly out of scope for v1.** The bar runs local. Stream comes back later.\n\n- **Mac4 cannot run Bolt depth.** `pyorbbecsdk` on macOS reports \"Femto Bolt is unavailable on macOS due to Depth Engine.\" Mega depth works (~30 fps), Bolt is RGB-only on Mac4. Dual-depth on Mac4 is **not pursued**. - **K11 is where Bolt depth lives** if/when needed (the original Bolt depth pipeline was proven on K11/Windows). - **K11 Pose Coach Viewer is the current Bolt owner.** While `C:\\temp\\lume_pose_viewer.py` is open it owns the Bolt color stream, emits `source=orbbec_bolt`, `role=bolt-rgb` pose JSON to local UDP `:9705`, and overlays body plus hand landmarks for live debugging. - **Mac4 keeps the Mega depth → Unity baseline** at `[ip]:9700`. Don't touch it. - **Mac4 RGB publisher uses the Mega**, not the Bolt, for v1. Bolt RGB + MediaPipe is a future path; permissions need to be granted to the runtime process before it can capture.", "htmlHref": "/research/html/lume-agent-contracts-v1-im0h9p.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2853 }, { "id": "cc-gesture-3i6gpm", "title": "cc-gesture", "slug": "cc-gesture", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/motion/cc-gesture/README.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "`cc-gesture` provides gesture recognition that integrates with `cc-anticipation`'s commitment/uncertainty signals and MotionPhraseIndex for neighbor-based classification.", "excerpt": "`cc-gesture` provides gesture recognition that integrates with `cc-anticipation`'s commitment/uncertainty signals and MotionPhraseIndex for neighbor-based classification.\n\n1. **Full-Body Pipeline** (Mokopi): Uses `AnticipationPacket` from `cc-anticipation` 2. **Hand Pipeline** (iPhone/Watch): Lightweight kernel for 6DOF IMU data\n\n- **Commitment = Gesture Lock-in**: High commitment means motion is deterministic - **Uncertainty = Ambiguity**: Low uncertainty + high commitment = confident classification - **Transition Pressure = Completion**: Spike signals gesture boundary - **Neighbor Voting = Label Propagation**: Similar past motions vote for current label", "htmlHref": "/research/html/cc-gesture-3i6gpm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 282 }, { "id": "graph-kernel-service-j11u90", "title": "Graph Kernel Service", "slug": "graph-kernel-service", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-graph-kernel/docs/SERVICE.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The Graph Kernel runs as a REST API service for slice-conditioned retrieval. It's the **admissibility authority** for the semantic system.", "excerpt": "The Graph Kernel runs as a REST API service for slice-conditioned retrieval. It's the **admissibility authority** for the semantic system.\n\n| Variable | Required | Default | Description | |----------|----------|---------|-------------| | `DATABASE_URL` | Yes | - | PostgreSQL connection string | | `KERNEL_HMAC_SECRET` | Yes (prod) | dev secret | HMAC secret for admissibility tokens | | `PORT` | No | 8001 | Service port | | `HOST` | No | [ip] | Bind address | | `RUST_LOG` | No | info | Log level (debug, info, warn, error) | | `LOG_FORMAT` | No | json | Log format (json, pretty) |\n\nResponse includes: - `slice_id`: Unique fingerprint - `turn_ids`: Admissible turns - `admissibility_token`: HMAC-signed proof\n\n#### `POST /api/verify_token` Verify an admissibility token without HMAC secret.\n\n| Endpoint | Purpose | |----------|---------| | `GET /health` | Detailed health (database, policies) | | `GET /health/live` | Liveness probe (process alive) | | `GET /health/ready` | Readiness probe (database connected) | | `GET /health/startup` | Startup probe for Cloud Run |", "htmlHref": "/research/html/graph-kernel-service-j11u90.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 494 }, { "id": "tri-agent-coordination-protocol-aao-wave-5-b9ix2o", "title": "Tri-Agent Coordination Protocol — AAO Wave 5", "slug": "tri-agent-coordination-protocol-aao-wave-5", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/AGENT_COORDINATION_PROTOCOL.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "**Status:** LIVE as of 2026-02-26 **Authority:** Graph Kernel (GK) at `:8001` **Replaces:** `[home-path]` (file-based, one-sided, deprecated)", "excerpt": "**Status:** LIVE as of 2026-02-26 **Authority:** Graph Kernel (GK) at `:8001` **Replaces:** `[home-path]` (file-based, one-sided, deprecated)\n\n| Agent | Model | Strengths | Spawner | |-------|-------|-----------|---------| | **Claude Code** | Opus 4.6 | Agentic dev, architecture, multi-file refactors | `clawdbot agent` | | **Gemini CLI** | Gemini 3 Pro Preview | Research, creative, long-context (>50K tokens) | `gemini` CLI | | **Codex CLI** | GPT-5.3 Codex | Structured output, data analysis, low hallucination | `codex` binary |\n\n**Problem:** The file-based `cross_agent_handshake.json` was one-sided — Gemini wrote 3 messages, Codex acknowledged once, Claude Code never participated. The event bus (`event_bus.sock`) died after 1 test message. Two agents could grab the same task simultaneously with no conflict detection.\n\n**Solution:** All coordination now flows through the **Graph Kernel HTTP API**. The GK is already the authority layer for task tickets, dedup, attestations, and reputation. Adding agent presence + claims makes it the **single source of truth** for the entire multi-agent system. No file watching, no Unix sockets, no race conditions.\n\n| Context | URL | When to use | |---------|-----|-------------| | Local (Mac2, where GK runs) | `http://localhost:8001` | Agent running on Mac2 | | Tailscale mesh (any Mac) | `http://[ip]:8001` | Agent running on Mac1/Mac3/Mac4 | | Cloud Run (remote) | `https://graph-kernel-274020562532.us-central1.run.app` | Cloud VM or external |", "htmlHref": "/research/html/tri-agent-coordination-protocol-aao-wave-5-b9ix2o.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2514 }, { "id": "admissibility-kernel-ygimwo", "title": "admissibility-kernel", "slug": "admissibility-kernel", "kind": "research note", "program": "Research Backlog", "sourceAnchor": "Comp-Core/packages/admissibility-kernel-py/README.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Python bindings for the Admissibility Kernel - deterministic context slicing with cryptographic verification for conversation DAGs.", "excerpt": "Python bindings for the Admissibility Kernel - deterministic context slicing with cryptographic verification for conversation DAGs.\n\n- **Deterministic slicing**: Same input always produces identical output - **HMAC-signed tokens**: Cryptographic verification of slice integrity - **Priority-queue BFS**: Novel algorithm for context boundary expansion - **Phase-aware scoring**: Synthesis > Consolidation > Exploration weighting - **High performance**: Rust core with Python bindings", "htmlHref": "/research/html/admissibility-kernel-ygimwo.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 246 }, { "id": "body-as-input-overview-aobz9e", "title": "Body As Input Overview", "slug": "body-as-input-overview", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/02-body-as-input/overview.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "The body-input layer gathers evidence about what the performer is doing. It must work when only a camera is available, and it should improve when mocopi, watch, phone, or depth sensors are available.", "excerpt": "The body-input layer gathers evidence about what the performer is doing. It must work when only a camera is available, and it should improve when mocopi, watch, phone, or depth sensors are available.\n\n| Source | Role | Hard dependency? | | --- | --- | --- | | Camera pose | Primary baseline for hand/torso/head gestures | Yes, for camera gestures | | iPhone CoreMotion | Phone motion/body energy when phone is carried | No | | Sony mocopi | Higher-quality skeleton/body source | No | | Apple Watch / SensorLogger | Wrist motion, HR, compass/barometer/location where enabled | No | | Femto/Bolt/Mega cameras | RGB/depth/pose assist depending on host support | No | | MotionMix BodyTruth | Intended fused body-state authority | Only after stability checks |\n\nThe architectural rule is camera-first: basic gestures must not stop working because mocopi is off, charging, or disconnected.\n\nFor DJ/AirDeck, this matters more than model sophistication. The user must be able to raise a hand and get a predictable command even without wearing sensors.\n\n- `CMDeviceMotion` into `SensorFrameFFI`; - camera pose/statistics where enabled; - mocopi features through `MocopiFeatureExtractor`; - watch/pocket features; - SAN capture frames through `SANTrajectoryLogger`.", "htmlHref": "/research/html/body-as-input-overview-aobz9e.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 428 }, { "id": "substack-the-ghost-agent-exorcism-1xyoved", "title": "Substack — The Ghost Agent Exorcism", "slug": "substack-the-ghost-agent-exorcism", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "content-pipeline/substack/2026-02-17-ghost-agent-exorcism.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "I woke up this morning and ran my usual audit of the overnight AI pipeline. Everything looked fine. The dashboard was calm. No error alerts. The system hummed along exactly as designed.", "excerpt": "I woke up this morning and ran my usual audit of the overnight AI pipeline. Everything looked fine. The dashboard was calm. No error alerts. The system hummed along exactly as designed.\n\nEvery five minutes, like clockwork, my chain engine would wake up, select a task, spin up an agent, and dispatch it. The agent would fail. The system would note the failure, wait five minutes, and try again. No escalation. No alert. No log entry worth reading.\n\nHere's the thing about automation bugs: the dangerous ones don't crash. They *persist*. They wrap their failures in retry logic and backoff algorithms. They consume resources quietly. They maintain the appearance of progress.\n\nWhen I finally dug into the logs, I found not one bug, but five—each one masking the others, each one contributing to a system that looked healthy but was quietly burning API calls and compute cycles on nothing.\n\nThe chain dispatch engine was designed to orchestrate multiple parallel build chains. Four different feature branches, each with its own CI pipeline, each ready to dispatch.", "htmlHref": "/research/html/substack-the-ghost-agent-exorcism-1xyoved.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 753 }, { "id": "tiktok-rhythm-is-parallel-processing-451jvw", "title": "TikTok: Rhythm Is Parallel Processing", "slug": "tiktok-rhythm-is-parallel-processing", "kind": "architecture", "program": "Research Backlog", "sourceAnchor": "content-pipeline/tiktok/series/the-bridge/17-rhythm-is-architecture.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Workspace document requiring curation.", "excerpt": "# TikTok: Rhythm Is Parallel Processing **Series:** The Bridge | Episode 17 **Date:** 2026-02-24 **Duration:** ~60 seconds\n\n## HOOK (0-3 sec) **[Direct to camera]** \"West African drumming is parallel processing. And computer science still hasn't caught up.\"\n\n## SETUP (3-15 sec) \"In a drum circle, every drummer holds a different pattern. Different time signatures. Different rhythmic phrases. And they interlock — perfectly — into one unified groove. No conductor. No score. Each person listening and adjusting in real time.\"\n\n## THE PARALLEL (15-30 sec) **[Building]** \"Multiple independent processes, running simultaneously, producing one coherent output through real-time synchronization. No central clock. No master node. Each node self-correcting based on what it hears from the others.\"\n\n## THE DEPTH (30-45 sec) **[Grounded]** \"Polyrhythm is the ability to hold multiple time streams simultaneously. Not alternating — simultaneously. Your left hand is in three. Your right is in four. Your foot is in two. Your mind holds all of them.\"", "htmlHref": "/research/html/tiktok-rhythm-is-parallel-processing-451jvw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 242 }, { "id": "everlasting-loop-protocol-elp-1-mesh-backed-autonomous-convergence-1u6g0uf", "title": "Everlasting Loop Protocol (ELP-1) — Mesh-Backed Autonomous Convergence", "slug": "everlasting-loop-protocol-elp-1-mesh-backed-autonomous-convergence", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "crucible-output/soop-2/05-everlasting-loop-protocol.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> **Status:** v1 draft (2026-05-13). Born from honest accounting of the SOOP-2 single-Claude loop's caveats. > **Goal:** Drive multi-day acceptance-criteria convergence without any single point of failure. No daemon, no machine, no session, no model dependency that can kill the loop.", "excerpt": "> **Status:** v1 draft (2026-05-13). Born from honest accounting of the SOOP-2 single-Claude loop's caveats. > **Goal:** Drive multi-day acceptance-criteria convergence without any single point of failure. No daemon, no machine, no session, no model dependency that can kill the loop.\n\n| Caveat | Root cause | ELP solution | |---|---|---| | C1: No visibility into the harness wake queue | ScheduleWakeup is a black-box claim | Supervisor maintains its own queue in Supabase + filesystem; wake claims are independently verifiable | | C2: Wake dies if Claude Code closes | Wake is intra-session | Supervisor runs as launchd plist outside Claude; dispatches work into any available session/pane | | C3: Loop is mine alone to drive | Single-driver pattern | Multi-worker pattern: any of mac1-5 + cloud-vm can pull from the queue; worker failure does not kill the loop | | C4: No external supervisor for stall | Silent failures don't escalate | Stagnation detector pages Mohamed via telegram/SMS after configurable thresholds; failed workers get quarantined via cortex:rules |\n\n| Failure | Frequency | Recovery cost | |---|---|---| | Claude Code app closed | hourly | zero (supervisor outside Claude) | | Single machine offline | daily | zero (mesh redistributes to other nodes) | | Specific pane rate-limited | hourly | zero (cortex:rules quarantines pane, work redistributes) | | Worker session hangs mid-batch | per-cycle | <5 min (claim TTL releases; another worker reclaims) | | Supabase unreachable | rare | falls back to filesystem-mirror state | | Tailscale partition | rare | mesh nodes work from local state; reconcile on heal | | Power loss on Mac1 | weeks | mac2/cloud-vm take over supervisor role | | Mohamed unreachable | known | protocol continues; queues escalations for resume | | Bad batch corrupts state | rare | state writes are atomic + journaled; rollback to last good |\n\nThe protocol has no single component whose failure stalls the loop indefinitely. Every component has a recovery path.\n\nEvery node has a local copy at `[home-path]`: - `scoreboard.json` — mirror of `soop2_state` row - `queue/pending/.json` — atomic per-batch files - `queue/claimed/.json` — moved here on claim - `queue/completed/.json` — moved on completion - `log/YYYY-MM-DD.jsonl` — daily log files, append-only - `supervisor.heartbeat` — touched every cycle by supervisor", "htmlHref": "/research/html/everlasting-loop-protocol-elp-1-mesh-backed-autonomous-convergence-1u6g0uf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 3180 }, { "id": "stage-3-expand-master-plan-agentos-cognitive-synchronization-1w3w4lj", "title": "Stage 3: Expand + Master Plan -- AgentOS Cognitive Synchronization", "slug": "stage-3-expand-master-plan-agentos-cognitive-synchronization", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/agentos-cognitive-sync/stage3-expand-master-plan.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Probability**: Medium (hooks fire frequently, timing overlap is plausible) **Impact**: High (missed SIG_SESSION_END means the orchestrator thinks the pane is still working for up to 5 minutes)", "excerpt": "#### R1: Interrupt File Race Condition **Failure scenario**: PostToolUse hook and SessionEnd hook fire within milliseconds of each other for the same pane. Both try to write `/tmp/pane_interrupts/ttys007.json`. One overwrites the other. The SessionEnd signal (high priority) is lost because PostToolUse (low priority) clobbered it.\n\n**Probability**: Medium (hooks fire frequently, timing overlap is plausible) **Impact**: High (missed SIG_SESSION_END means the orchestrator thinks the pane is still working for up to 5 minutes)\n\nEach interrupt is a separate file. The orchestrator reads ALL files in the directory, sorts by timestamp, takes the highest-priority one, and deletes consumed files.\n\n**Validation**: Write a test that fires 100 concurrent interrupts to the same TTY directory and verifies zero data loss.\n\n#### R2: Drift Meter Threshold Produces False Positives at High Pane Count **Failure scenario**: With 40 panes, each emitting SIG_TOOL_ACTIVE (drift += 0.02), the aggregate drift noise triggers sync pulses continuously. The system enters a \"sync storm\" where every cycle fires a pulse, defeating the purpose of event-driven sync.", "htmlHref": "/research/html/stage-3-expand-master-plan-agentos-cognitive-synchronization-1w3w4lj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 3750 }, { "id": "evo3-stage-0-research-app-fleet-lifecycle-deep-exploration-f300fh", "title": "Evo3 Stage 0: RESEARCH — App Fleet Lifecycle Deep Exploration", "slug": "evo3-stage-0-research-app-fleet-lifecycle-deep-exploration", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/app-fleet-lifecycle-qwen35-cloud/stage0-research.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Target:** Mega-Cube #13 — \"App Fleet Lifecycle\" **Date:** 2026-03-10 **Model:** qwen35-cloud (405B) **Exploration Depth:** 3 (recursive) **File Budget:** 30 files max", "excerpt": "**Target:** Mega-Cube #13 — \"App Fleet Lifecycle\" **Date:** 2026-03-10 **Model:** qwen35-cloud (405B) **Exploration Depth:** 3 (recursive) **File Budget:** 30 files max\n\n### Candidate 1: M-2 EW Graduation | File | Lines | Key Classes/Functions | Cross-References | |------|-------|----------------------|------------------| | `engine.py` | 400 | `EvolutionWorld.evolve_step()`, `EvolutionWorld.evolve_all()` | graduation.py:28, feedback.py:30 | | `graduation.py` | 234 | `evaluate_graduation()`, `speciate()`, `enter_optimization()`, `enter_dormancy()`, `apply_graduation()` | genome.py:18, feedback.py:31 | | `genome.py` | 241 | `AppGenome`, `Milestone`, `MutationOperator`, `DEFAULT_MILESTONES` | — | | `feedback.py` | 334 | `FeedbackState`, `FeedbackCollector`, `compute_grounded_fitness()`, `compute_metabolism()` | — |\n\n**Key Facts:** - Graduation triggers at `fitness >= 0.85` (graduation.py:23) - 3 outcomes: SPECIATION (momentum >0.01/day), OPTIMIZATION (stable), DORMANCY (metabolism <0.15) - Speciation forks genome: stable (RELEASED) + variant (ACTIVE with new milestones) - Optimization locks out G-techniques, keeps R/D only (graduation.py:142-149) - Dormancy preserves capabilities in gene pool for crossover (graduation.py:160) - Feedback has 5 weighted channels with temporal decay (feedback.py:30-36)\n\n### Candidate 2: A-8 Wave 3 | File | Lines | Key Classes/Functions | Cross-References | |------|-------|----------------------|------------------| | `fleet.py` | 329 | `FLEET_3_APPS`, `create_fleet3_genome()`, `initialize_fleet3()`, `run_fleet3_evolution()` | genome.py:18, engine.py:21 | | `population.py` | 453 | `PopulationManager`, `crossover_capabilities()`, `bootstrap_fleet()` | genome.py:24 |\n\n**Key Facts:** - 16 Wave 3 apps defined (fleet.py:28-173) - All apps start with `testflight_live=1.0` (already on TestFlight) - Category-specific mutation operator boosts (fleet.py:176-185) - Spore is most mature: `core_feature=0.7`, others at 0.2-0.3 - Categories: language (5), movement (3), builder (4), voice (2), coffee (1), garden (1)", "htmlHref": "/research/html/evo3-stage-0-research-app-fleet-lifecycle-deep-exploration-f300fh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 2311 }, { "id": "stage-0-research-brief-comp-core-production-map-2kqsl6", "title": "Stage 0: Research Brief -- Comp-Core Production Map", "slug": "stage-0-research-brief-comp-core-production-map", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "evo-cube-output/comp-core-production-map/stage0-research.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Comp-Core is a monorepo at `Desktop/Comp-Core/` containing 73 components across 8 domain layers, 13 packages, ~30 applications, and 4 backend services. It started as a motion-intelligence system for computational choreography and has grown into Mohamed's full infrastructure backbone: retrieval (RAG++), semantic graph (Graph Kernel), agent orchestration, audio synthesis (Echelon), gateway connectors, and ML pipelines.", "excerpt": "Comp-Core is a monorepo at `Desktop/Comp-Core/` containing 73 components across 8 domain layers, 13 packages, ~30 applications, and 4 backend services. It started as a motion-intelligence system for computational choreography and has grown into Mohamed's full infrastructure backbone: retrieval (RAG++), semantic graph (Graph Kernel), agent orchestration, audio synthesis (Echelon), gateway connectors, and ML pipelines.\n\nVersion: 0.1.0. Last INDEX.md update: 2025-02-02. Actual development has continued aggressively through Q1 2026.\n\n| Project | Lang | Claimed Status | Real State | |---------|------|---------------|------------| | cc-core | Python | Complete | Python LIM-RPS algorithms. Has pyproject.toml + requirements.txt. Foundational. Works. | | cc-core-rs | Rust/Py | Complete | DSP kernels, lock-free buffers. Has Cargo.toml + pyproject.toml (PyO3). | | cc-kernel | Rust | Substantial | SMART execution kernel. Has Cargo.toml. No release binary found. | | cc-protocol | Rust | Complete | Unified protocol definitions. Has Cargo.toml. | | cc-migration-architect | TS | Present | Has package.json. Schema migration tooling. |\n\n**Honest assessment**: Runtime layer is the most stable. cc-core and cc-core-rs are genuinely complete. cc-kernel has code but \"substantial\" means it compiles, not that it's battle-tested under load.\n\n| Project | Lang | Claimed Status | Real State | |---------|------|---------------|------------| | cc-types | Rust | FROZEN | Core motion types. Intentionally locked. | | cc-anticipation | Rust/Py | Complete | Anticipation kernel with 7 scalars. Has target/ dir (was compiled). | | cc-collection | Rust/Py | Complete | Extended Kalman Filter fusion. Has target/ dir. | | cc-gesture | Rust | Partial | Has target/ dir but gesture recognition is incomplete. | | cc-window-aligner | Rust | 99% | Has target/ dir. Known integration gap at lib.rs:411-414. | | cc-motion-utils | TS | Planned | Does not exist as real code. | | sensor-pipeline | -- | Present | Listed in directory, not in INDEX.md. |", "htmlHref": "/research/html/stage-0-research-brief-comp-core-production-map-2kqsl6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 2252 }, { "id": "stage-3-expand-master-plan-f4xb82", "title": "Stage 3: EXPAND + MASTER PLAN", "slug": "stage-3-expand-master-plan", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/computational-choreography-device/stage3-expand-master-plan.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Component | Part | Unit Cost (500 qty) | Unit Cost (3000 qty) | |-----------|------|--------------------:|---------------------:| | Depth camera | Orbbec Femto Bolt | $380 | $340 | | Compute module | Jetson Orin Nano Super | $225 | $200 | | Storage | Samsung PM9A3 512GB NVMe | $42 | $35 | | Wide camera | Sony IMX577 4K module | $18 | $14 | | Tight camera | Sony IMX577 4K module | $18 | $14 | | Mic array | 3x MEMS mic + ADC board | $12 | $9 | | Speakers | 2x 3W full-range drivers | $8 | $6 | | WiFi/BT module | Int", "excerpt": "### R1: Unity on Jetson Orin Nano Performance [CRITICAL] - **Failure scenario:** Unity URP + compute shaders + VFX Graph + video recording exceeds Jetson's 25W GPU budget. Frame rate drops below 30fps, making the experience unusable. - **Probability:** MEDIUM-HIGH (40%) - **Impact:** CRITICAL. The entire product is the visual experience. If it stutters, there is no product. - **Mitigation:** (a) Build a performance benchmark on actual Jetson hardware in Week 2. Target: 60fps with 256x256 fluid sim, 30K particles, 1080p output. (b) If Unity fails: port the 3 compute shaders to native CUDA/Vulkan. The shaders are standard HLSL and translate directly to CUDA. Lose VFX Graph but gain 3-5x performance. (c) Fallback: drop to 720p output and 128x128 fluid sim. Still looks good on a projector from 6ft. - **Validation criteria:** Measured frame time < 16.6ms (60fps) with full pipeline running on Jetson dev kit. - **Owner:** Mohamed - **Timeline:** Must be resolved by end of Month 1.\n\n### R2: Real-Time Video Compositing + Recording Simultaneously [CRITICAL] - **Failure scenario:** Recording composited video (camera feed + visual overlay) to NVMe while rendering the visual pipeline causes frame drops or recording corruption. - **Probability:** MEDIUM (30%) - **Impact:** HIGH. Content creation is the primary value proposition. If recording degrades the experience, users choose between \"good visuals\" and \"record content,\" which breaks the product promise. - **Mitigation:** (a) Use Jetson's dedicated hardware video encoder (NVENC) which runs independently of the GPU compute pipeline. H.265 encoding at 1080p30 consumes ~2W and does not steal GPU cycles. (b) Record at 1080p30 even if display is at 1080p60 (30fps is standard for social content). (c) Compositing happens in GPU memory. The final render target is both displayed AND piped to NVENC. No CPU-side copy needed. - **Validation criteria:** 5-minute continuous recording at 1080p30 with zero dropped frames while maintaining 60fps display output.\n\n### R3: Femto Bolt Depth Quality at Room-Scale Distances [MEDIUM] - **Failure scenario:** At 3-5 meter distance (typical studio), the Femto Bolt's depth accuracy degrades. Silhouette edges become noisy. The fluid sim looks jittery instead of smooth. - **Probability:** LOW-MEDIUM (25%) - **Impact:** MEDIUM. Noisy depth can be filtered, but aggressive filtering adds latency. - **Mitigation:** (a) Use NFOV mode (640x576 @30fps, 75x65 deg) for tighter, more accurate depth at distance. (b) Apply temporal filtering (exponential moving average across 3-5 frames) to smooth depth edges. (c) The Sobel edge detection in DepthReprojection.compute already provides clean edges from noisy depth. (d) Femto Bolt is rated to 5.5m with <11mm accuracy. At 4m, accuracy is ~15mm. This is acce", "htmlHref": "/research/html/stage-3-expand-master-plan-f4xb82.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 5942 }, { "id": "karl-integration-evolution3-stage-0-research-1edkxyy", "title": "KARL Integration -- Evolution3 / Stage 0: RESEARCH", "slug": "karl-integration-evolution3-stage-0-research", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/karl-trajectory-intelligence/stage0-research.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**This is exactly the trajectory data KARL needs.** The data exists but flows into storage (unified.jsonl, verbose-all.jsonl) without any feedback loop to skill improvement. The unified store has 3,909 entries with tool_calls arrays -- this is a goldmine of trajectory data that currently goes unused for learning.", "excerpt": "# KARL Integration -- Evolution3 / Stage 0: RESEARCH **Run:** karl-trajectory-intelligence **Generated:** 2026-03-10 **Method:** Evolution3 -- four-stage recursive evoflow (research-grounded) **Run Directory:** Desktop/evo-cube-output/karl-trajectory-intelligence/\n\n## Noosphere Context No prior dreams or patterns found on this topic. Fresh ground.\n\n### Architecture Overview The Cortex is a self-improving behavioral intelligence system at `[home-path]` with 7 phases, 17 Python files, 29 tests, and 3 hooks. Its data store is `[home-path]` (currently 399 entries: 324 invocation_records + 75 decay_flags).\n\n#### 1a. Extractor (`[home-path]`, 287 lines) - **Pipeline**: 4-pass -- Load+Filter, Tokenize+N-gram, Cluster (Jaccard >0.6), Enrich - **Input**: `[home-path]` (currently 903 entries) - **Output**: `CortexEntry(type=\"skill_candidate\")` objects - **Filtering**: Lines 41-67 define SKIP_PATTERNS (automated prompts, trivial inputs like \"yes\", \"ok\", \"continue\") - **Tokenization**: Line 96-98 -- lowercase, strip punctuation, remove stop words, 2-4 word n-grams - **Clustering**: Line 157 -- requires `min_count=15` for meaningful clusters. Jaccard threshold 0.6 at line 192 - **Domain detection**: Lines 70-81 -- 10 operational domains (ios, deploy, supabase, docker, git, prefect, monitoring, mesh, debug, asc) - **Cap**: 30 candidates maximum (line 224) - **Critical gap**: Only extracts intent *labels* from prompts. Does NOT capture tool-use sequences, file paths touched, success/failure signals, or the full trajectory of how a task was accomplished.\n\n#### 1b. Generator (`[home-path]`, 178 lines) - **Input**: `CortexEntry` skill candidate - **Output**: Static SKILL.md file with frontmatter (YAML) + markdown body - **Template variables**: Lines 19-59 define DOMAIN_TOOLS, DOMAIN_MACHINES, DOMAIN_TRIGGERS per domain - **Content**: Generic 4-step workflow (check state, execute, verify, report) at lines 112-127 - **Critical gap**: Generated skills are *static templates*, not learned procedures. The \"Workflow\" section is the same 4 generic steps for every skill. No tool sequences, no gotcha accumulation from actual failures, no reward signal integration.", "htmlHref": "/research/html/karl-integration-evolution3-stage-0-research-1edkxyy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 3671 }, { "id": "karl-integration-evolution-stage-1-path-e-hwmei1", "title": "KARL Integration — Evolution³ / Stage 1: PATH E", "slug": "karl-integration-evolution-stage-1-path-e", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/karl-trajectory-intelligence/stage1-path-e.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Path E adapts KARL's synthetic self-play pipeline to our living codebase. Instead of mining static enterprise documents, our question generator reads our own code, memory files, hooks, flows, and configs to produce domain-specific questions. A solver agent then attempts to answer each question using our actual tool stack (Read, Grep, Bash, RAG++, GK). Every attempt is recorded as a trajectory. Trajectories are quality-filtered, then used to either improve SKILL.md content (near-term, zero training cost) or train a ", "excerpt": "# KARL Integration — Evolution³ / Stage 1: PATH E **Run:** karl-trajectory-intelligence **Path:** E — Synthetic Self-Play: Generate Our Own Training Data from the Codebase **Stage:** 1 of 4 (Explore + Design) **Generated:** 2026-03-10 **Method:** Evolution³ — four-stage recursive evoflow (research-grounded) **Run Directory:** Desktop/evo-cube-output/karl-trajectory-intelligence/\n\nPath E adapts KARL's synthetic self-play pipeline to our living codebase. Instead of mining static enterprise documents, our question generator reads our own code, memory files, hooks, flows, and configs to produce domain-specific questions. A solver agent then attempts to answer each question using our actual tool stack (Read, Grep, Bash, RAG++, GK). Every attempt is recorded as a trajectory. Trajectories are quality-filtered, then used to either improve SKILL.md content (near-term, zero training cost) or train a LoRA adapter on Mac5 (medium-term, higher yield). The net result is a self-improving knowledge base that gets better the more it is used, without requiring any manual documentation work.\n\n**Why this is the right path over alternatives:** - Path A (add OAPL directly) requires distributed GPU training we do not have. - Path B (plug in KARL's external model weights) gives us someone else's knowledge, not ours. - Path C (add reward signals to existing Cortex) improves routing but not knowledge depth. - Path D (use RAG++ as the KARL search tool) improves retrieval but not the agent's procedures. - **Path E** generates our own proprietary training signal from our own codebase — a moat no external model can replicate.\n\nThe question generator mines five tiers of source material, ordered by information density:\n\n| Tier | Source | Volume | Why | |------|--------|--------|-----| | T1 | `[home-path]` topic files | 29 files, ~3,500 lines | Curated operational knowledge with hard-won gotchas | | T2 | `[home-path]` SKILL.md files (Gen 2 only) | 12 active, ~800 lines | Procedure documents with trigger patterns and workflows | | T3 | `flows/feed-hub/*.py` — Prefect flow source | 106 files | Actual implementation truth for flow/task questions | | T4 | `[home-path]` — all hook source files | 34 hooks, 29 scripts | Ground truth for hook behavior questions | | T5 | `[home-path]` (filtered) | ~400 real human prompts after SKIP_PATTERNS | Reveals what humans actually need to know |", "htmlHref": "/research/html/karl-integration-evolution-stage-1-path-e-hwmei1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 6132 }, { "id": "stage-3-5-creative-forge-architectural-synthesis-l4p2lh", "title": "Stage 3.5 — Creative:Forge architectural synthesis", "slug": "stage-3-5-creative-forge-architectural-synthesis", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-creative-engine-2026-05-02/creative-forge-output.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Output of Wave 9 forge pass on the master plan (stage3-expand-master-plan.md). > Scope: deepen the 3 architectural questions the master plan defers or under-specifies. > Treat as **PRODUCTION SYSTEM**. Don't break what ships. > Six forge phases per question: Prime → Explode → Forge → Synthesize → Create → Evolve.", "excerpt": "> Output of Wave 9 forge pass on the master plan (stage3-expand-master-plan.md). > Scope: deepen the 3 architectural questions the master plan defers or under-specifies. > Treat as **PRODUCTION SYSTEM**. Don't break what ships. > Six forge phases per question: Prime → Explode → Forge → Synthesize → Create → Evolve.\n\nThe master plan picks the right 5 panes and the right reel-ship cadence, but under-specifies three load-bearing decisions that will bite during Wave A-B execution if not nailed down:\n\n- **Q1 — where exactly does the audio tap live, and does LUMF carry SAN's pattern decisions?** Master plan §7.1 hand-waves \"AudioEngine pre-allocated buffers\" without picking the AVAudioEngine node, the cadence, or the threading model. Get this wrong and either the engine drops audio (catastrophic) or LumfPublisher silently allocates per-buffer (audible glitches every ~5s as ARC stalls the audio thread).\n\n- **Q2 — three directors, no shared state schema.** Master plan §6 R6 names the risk (\"coordination collapse across 5 panes\") but only mitigates code collisions, not director state collisions. Stage 0 found three live directors actively maintained. Without a written contract, the next pane to touch any director re-derives the schema and they diverge harder.\n\n- **Q3 — universal sled has two physical constraints (USB topology vs thermal) and four-way mounting variance.** Master plan §7.5 lists `MAC_MINI_W/D/H/FOOT_PITCH` constants but doesn't pick the dominant constraint that drives the CAD geometry. Pick wrong and the sled prints but the cables don't reach, or the thermals are fine but the user fights connectors every load-in.", "htmlHref": "/research/html/stage-3-5-creative-forge-architectural-synthesis-l4p2lh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 8759 }, { "id": "plan-review-lume-creative-engine-maturation-1hzak3c", "title": "Plan Review: LUME Creative Engine Maturation", "slug": "plan-review-lume-creative-engine-maturation", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-creative-engine-2026-05-02/meta-review.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Findings**: 15 (2 Critical / 4 High / 6 Medium / 3 Low) - **Cross-cutting patterns**: 3 (advisory protocol treated as atomic, missing dep declaration vs assumed-present, packet format arithmetic slippage) - **Plan health**: GO-with-fixes", "excerpt": "# Plan Review: LUME Creative Engine Maturation > Stage 5 of `/chain:genesis` — 6-pass meta-review of the plan, not shipped code. > Reviewed: `divergent-rail.md` (Stage 4), `creative-forge-output.md` (Stage 3), > `stage3-expand-master-plan.md` (Stage 2), `stage0-research.md` (Stage 1). > Verified claims against repo state via Bash tooling as of 2026-05-02.\n\n- **Findings**: 15 (2 Critical / 4 High / 6 Medium / 3 Low) - **Cross-cutting patterns**: 3 (advisory protocol treated as atomic, missing dep declaration vs assumed-present, packet format arithmetic slippage) - **Plan health**: GO-with-fixes\n\n| ID | Description | Location | Fix | |----|-------------|----------|-----| | C-01 | **FirstDate PAT is live in the remote URL right now.** `git -C Desktop/FirstDate remote -v` confirms `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` is in the fetch and push remote. The plan treats PAT rotation as Phase 0 Track A with a 20-min estimate and an explicit \"rotated OR sentinel\" escape hatch. The escape hatch means Mohamed can paste pane prompts while the token remains live. Any pane prompt that is logged, synced, or echoed to disk will carry context that references this credential path. The token itself has been in the remote URL since at least `d823a3a` (verified via `git remote -v`). | `stage0-research.md:A.11`, `divergent-rail.md:Phase 0 Track A` | Rotate the PAT *before* Phase 0 completes. Remove the escape hatch. The sentinel `WAVE8_PUSH_BLOCKED_PAT_ROTATION` is the right safety signal, but the plan must require rotation, not just documentation of the blocker. Rotate now: `git -C Desktop/FirstDate remote set-url origin https://github.com/Diomandeee/FirstDate.git` then revoke the old token via GitHub Settings → Tokens. | | C-02 | **Phase 0 coordination state is entirely absent — zero of 5 prerequisites exist.** Verified: `[home-path]` = MISSING, `[home-path]` = MISSING, `.WAVE8_NOT_PUSHED` sentinel = MISSING, `[home-path]` = MISSING, `pane-prompt-P{1..5}.md` = MISSING. The rail plan's Phase 0 Gate reads \"5 Codex pane prompts in evo-cube-output/, K11 health-check green, Mac4 reachable via Tailscale, FirstDate PAT rotation **status confirmed**, `[home-path]` directory created.\" None of these conditions are met. Mohamed cannot paste pane prompts because the prompts do not exist yet. The plan defines what Phase 0 must produce but no pane or task in Phase 0 generates the prompts themselves — there is a circular dependency: pane prompts are Phase 0 outputs, but Phase 0 requires pane prompts to already be open. | `divergent-rail.md:Phase 0 deliverables`, verified via Bash | The prompts must be written in this session (Stage 5) or in a dedicated pre-Phase-0 step, before any pane is opened. Stage 5 (this review) should close by writing `pane-prompt-P1.md` through `pane-promp", "htmlHref": "/research/html/plan-review-lume-creative-engine-maturation-1hzak3c.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 3659 }, { "id": "stage-2-compound-synthesis-sequential-linear-1kjn1s6", "title": "Stage 2 — Compound Synthesis (Sequential, Linear)", "slug": "stage-2-compound-synthesis-sequential-linear", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-creative-engine-2026-05-02/stage2-compound.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Output of Evo3 Stage 2 for LUME creative engine maturation. > 6 paths from Stage 1 (A bridge-first, B director-first, C pod-first, D reel-first, E maximalist, F minimalist) compounded into one ranked plan. > Sequential rule: Step 1 starts from ground truth; Steps 2-8 each inherit ALL prior steps and resolve conflicts explicitly.", "excerpt": "> Output of Evo3 Stage 2 for LUME creative engine maturation. > 6 paths from Stage 1 (A bridge-first, B director-first, C pod-first, D reel-first, E maximalist, F minimalist) compounded into one ranked plan. > Sequential rule: Step 1 starts from ground truth; Steps 2-8 each inherit ALL prior steps and resolve conflicts explicitly.\n\n**Anchor in stage0-research.md, not in any path.** Five claims from Stage 0 are load-bearing for Stage 2:\n\n1. **The music engine is deployed, not undefined.** (stage0 §C.6, §C.8.) Echelon-Rust → SAN-MLX (135K params, V5 weights, 5,408 real pairs, val loss 0.028) → AudioEngine.swift (2110 lines, AVF + Rust-FFI hybrid). Zero MusicGen/AudioCraft/Riffusion installs anywhere. The *gap* is **integration bridges**, not training. This invalidates memory §2's Phase A/B/C framing. 2. **Three competing AI directors exist with no canonical owner.** (stage0 §A.4/A.5/A.9, Top-3-facts #1.) `MotionMixDirector` (macOS multicam hub), `MotionMixLiveDirector` (iOS show-runner overlay), `StageView/Services/{GeminiLiveService,PhotoshootDirector}` (iPad performer-facing). All three are actively maintained. 3. **Universal sled does not exist; pod is K11-locked.** (stage0 §E, Top-3-facts #3.) `lume-pod.scad` and `pod_compute_sled` only have K11_VESA_PITCH=75 holes, K11-bottom-fan-intake/K11-top-fan-exhaust grid, K11-USB-A cable channels. Mac mini M4 has zero mounting points. Memory's \"3hr port\" estimate is wrong; it's a 1-2 day rewrite due to fan topology differences. 4. **Wave 8 is shipped (6 commits) but not pushed.** Mac1 main has `da8d1478`/`c5194f92`/`2a6e6b25`/`95387a02`/`8139a931`/`8fb6fe75`. K11 NSSM services live and reboot-survival proven. Mocopi-pro in mail; iPad LUMM fallback is the demo skeleton. (stage0 §A.1, §B.1.) 5. **Production-system constraint applies.** Memory §7b clarification: \"Codex briefings going forward must label this as a production system so future agents don't treat it as throwaway scaffolding.\" This shapes the don't-touch list and forbids \"good enough\" handwavy work.\n\n**Don't-touch list (verified, must propagate to every Codex briefing):** - Wave 8 wire format magics: `LUME` (0x4C554D45), `LUMD` (0x4C554D44), `LUMF` (0x4C554D46), `LUMM` (0x4C554D4D), `LUMC`. Byte-for-byte pinned via `tests/test_wire_format_golden.py`. - 21 Unity component public APIs — additive only, no field renames or signature changes. - K11 NSSM service definitions (`install-services.ps1`) — runtime args may be flagged but service registration stays untouched. - Wave 8 commits not-pushed — Mohamed pushes manually after Mac4 verification. - LUMF wire format `audio_pub.py:send_lumf` byte order (golden-bytes test on Mac1).\n\n## Step 2 — Music-gen pipeline decision (resolves Path A vs F vs the chain prompt's framing)", "htmlHref": "/research/html/stage-2-compound-synthesis-sequential-linear-1kjn1s6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 2277 }, { "id": "stage-3-expand-master-plan-l6eer", "title": "Stage 3 — Expand + Master Plan", "slug": "stage-3-expand-master-plan", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-creative-engine-2026-05-02/stage3-expand-master-plan.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Final ranked, dependency-ordered execution plan for LUME creative engine maturation. > Treat as **PRODUCTION SYSTEM**. Don't break what ships. > Output of Evo3 Stage 3, Wave 9 of the LUME chain. 5 panes, 3 reel-critical + 2 parallel. > Deadline: reel posted by **2026-05-09 EOD**.", "excerpt": "> Final ranked, dependency-ordered execution plan for LUME creative engine maturation. > Treat as **PRODUCTION SYSTEM**. Don't break what ships. > Output of Evo3 Stage 3, Wave 9 of the LUME chain. 5 panes, 3 reel-critical + 2 parallel. > Deadline: reel posted by **2026-05-09 EOD**.\n\nThis list is **enforced at the git pre-commit layer** (P3 ships the hook). Treat any apparent need to violate it as an escalation signal, not a refactor opportunity.\n\n- **Wire format magic bytes**: `LUME` (0x4C554D45), `LUMD` (0x4C554D44), `LUMF` (0x4C554D46), `LUMM` (0x4C554D4D), `LUMC`. Pinned byte-for-byte by `tests/test_wire_format_golden.py` (memory: Wave 4 Track I). - **21 Unity component public APIs** — additive only, no field renames or signature changes. Surface enumerated in `software/demo/unity/lume_pcloud/ARCHITECTURE.md` (memory: 2026-04-26 commit `e2089c56`). - **K11 NSSM service definitions** in `software/demo/launchagents/k11/install-services.ps1`. Runtime Args may be parameter-flagged; service registration block stays as-is. - **Wave 8 commits not-pushed**: `da8d1478`, `c5194f92`, `2a6e6b25`, `95387a02`, `8139a931`, `8fb6fe75`. Only Mohamed pushes after Mac4 verification. - **LUMF byte order in `audio_pub.py:send_lumf`** — pinned by golden-bytes test. - **MotionMix repo proof-token model** (commit `1ea8da7 feat(director): Phase 5a proof token model`) — read it before defining any director event payload; do not redefine its schema. - **Production system constraint** — Mohamed runs all destructive operations manually. No Codex pane may `git push`, `launchctl unload && load`, `nssm remove`, or post to social media on Mohamed's behalf.\n\n**Wire format edges (verified from stage0):** - `MotionMix iPhone → Unity` via **LUMM** (772B, 27 bones, magic 0x4C554D4D, port 9702 — direct fleet path; or via mocopi when activated). - `MotionMixApp iPhone → Unity` via **LUMF** (84B, magic 0x4C554D46, port 9701) — NEW PATH from P1. - `K11 LUME-Depth (Femto Bolt) → Unity` via **LUMD** (716px raw depth, magic 0x4C554D44, port 9700). - `Unity → MotionMixApp` via **OSC** (7 channels, port 9050) — NEW CONSUMER from P4. - `MotionMixApp → StrudelWebEngine` via **WKWebView JS bridge** (window.sanUpdate at 10Hz, /san HTTP POST at 2Hz). - `MotionMix iPhone → MotionMixDirector` via **MJPEG** (port 8081, existing).\n\n| Phase | Timing | What | Why | |-------|--------|------|-----| | **A — ship-bridge-now** | This week (P1) | LumfPublisher.swift NEW. MotionMixApp's deployed AudioEngine output becomes Unity's audio source. | Stage0 §C.6 verified the engine is deployed; the gap is publishing PCM as LUMF. | | **B — condition-on-OSC-channels** | Weeks 2-4 (P4) | OSC :9050 → ParamMapper.Extras → StrudelWebEngine.sanUpdate. SAN→Strudel realtime via debounced setSANPattern. | Closes the visual→au", "htmlHref": "/research/html/stage-3-expand-master-plan-l6eer.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 5837 }, { "id": "lume-reconciliation-execution-playbook-mac1-canonical-mac4-patch-source-1n71ti", "title": "LUME Reconciliation + Execution Playbook — Mac1 Canonical, Mac4 Patch Source", "slug": "lume-reconciliation-execution-playbook-mac1-canonical-mac4-patch-source", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-creative-engine-2026-05-02/STATE-OF-THE-PANES-2026-05-02-EVENING.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This file replaces all prior playbooks. It supersedes the earlier Mac4-as-author plan after verified state showed (a) Mac4 `lume-commerce` is not a clean standalone Git repo, (b) Mac1 has 13 staged files + 134 passed/6 skipped Python tests, (c) `LumeSonyMotionBridge.cs` does NOT decode Sony or emit LUMM — it only reacts to skeletons already received by `LumeMocopiReceiver` on :9702. The real missing bridge is upstream.", "excerpt": "# LUME Reconciliation + Execution Playbook — Mac1 Canonical, Mac4 Patch Source **Written: 2026-05-02 evening. Mohamed offline. Single source of truth for every active pane.** **Source session: 3a30cf44-adb2-4160-a40d-2258245acd0d (compacted at 191%)**\n\nThis file replaces all prior playbooks. It supersedes the earlier Mac4-as-author plan after verified state showed (a) Mac4 `lume-commerce` is not a clean standalone Git repo, (b) Mac1 has 13 staged files + 134 passed/6 skipped Python tests, (c) `LumeSonyMotionBridge.cs` does NOT decode Sony or emit LUMM — it only reacts to skeletons already received by `LumeMocopiReceiver` on :9702. The real missing bridge is upstream.\n\n1. **Mac1 is the only committable LUME source of truth.** Mac1's `Assets/Scripts/` is canonical and has 13 staged files awaiting commit. Mac4 `lume-commerce` is not a clean Git repo — do NOT commit or `git mv` from Mac4. Mac4 is a **patch source**, not a Git author.\n\n2. **The real Sony bridge is upstream, not in Unity.** Add `software/demo/sony_to_lumm_bridge.py` (or extend Mac1's `sensor-relay.js`) that consumes parsed Sony frames and emits actual LUMM datagrams to `:9702`. `LumeSonyMotionBridge` stays as the visual motion reactor only — it does not pack, decode, or emit anything.\n\n3. **Mac4 visual/perf work is valuable but must be ported into Mac1 by hand.** Pull Mac4's `Assets/Lume/` into a temporary import folder on Mac1, port selected files into canonical paths, preserve Mac1 `.meta` for existing components, bring Mac4 `.meta` only for genuinely new assets.", "htmlHref": "/research/html/lume-reconciliation-execution-playbook-mac1-canonical-mac4-patch-source-1n71ti.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 4304 }, { "id": "path-b-distributed-orchestra-each-machine-specializes-echelon-coordinates-5j81ur", "title": "Path B: Distributed Orchestra -- Each Machine Specializes, Echelon Coordinates", "slug": "path-b-distributed-orchestra-each-machine-specializes-echelon-coordinates", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-full-system-architecture/stage1-path-b.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Every machine in the Tailscale mesh has exactly one job. K11 = sensors + visuals. Mac5 = audio synthesis (Strudel.js). MotionMix iOS = motion intelligence + camera + SAN. Mac1 = multicam server (coordination + director). Cloud-vm = ML inference. Echelon's link-clock provides the shared beat clock that synchronizes everything. The multicam server :9404 becomes the message bus. All data flows through well-defined API endpoints.", "excerpt": "# Path B: Distributed Orchestra -- Each Machine Specializes, Echelon Coordinates\n\nEvery machine in the Tailscale mesh has exactly one job. K11 = sensors + visuals. Mac5 = audio synthesis (Strudel.js). MotionMix iOS = motion intelligence + camera + SAN. Mac1 = multicam server (coordination + director). Cloud-vm = ML inference. Echelon's link-clock provides the shared beat clock that synchronizes everything. The multicam server :9404 becomes the message bus. All data flows through well-defined API endpoints.\n\n- **Uses existing code as-is.** Every piece of existing software runs in its native environment. Zero ports, zero rewrites. - **Echelon beat clock is real.** The link-clock crate wraps Ableton Link, which is explicitly designed for multi-device synchronized performance. It handles network jitter, clock drift, and joins/leaves. - **Clean separation of concerns.** Each machine does what it's best at. K11 has the GPU for visuals. iOS has CoreMotion/Vision for body intelligence. Mac5 has the Strudel runtime. - **Redundancy through specialization.** If Mac5 goes down, visuals still work. If K11 goes down, music still plays.\n\n- **Latency accumulation.** Mocopi sensor -> iOS parse -> LUMM -> K11 Unity. That's 2 Tailscale hops for skeletal data to reach visuals. Estimated 20-60ms added. - **Echelon link-clock has never been tested cross-platform.** The Rust crate exists but iOS-only compilation history means Windows Ableton Link FFI is unverified. - **Coordination complexity.** 5 machines, 4 different languages (Python, Rust, Swift, JS), 3 operating systems (Windows, macOS, iOS). Debugging distributed state is hard. - **Single operator.** Mohamed can't monitor 5 machines during a live performance. - **Mac1 as coordinator is fragile.** The multicam server is already 10K+ lines. Adding LUME orchestration on top risks scope creep. - **Music param latency.** iOS -> Mac5 for Strudel control adds Tailscale hop. iOS -> K11 for visual param sync adds another.\n\nCONCEPTUALLY CORRECT but OPERATIONALLY DANGEROUS for a single operator. The separation of concerns is right. The beat clock idea is right. But 5-machine coordination is too many failure surfaces. Need to reduce to 2-3 machines max for reliability.", "htmlHref": "/research/html/path-b-distributed-orchestra-each-machine-specializes-echelon-coordinates-5j81ur.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 555 }, { "id": "path-c-motionmix-as-brain-ios-app-is-the-conductor-k11-is-just-sensors-1mor5oe", "title": "Path C: MotionMix-as-Brain -- iOS App is the Conductor, K11 is Just Sensors", "slug": "path-c-motionmix-as-brain-ios-app-is-the-conductor-k11-is-just-sensors", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-full-system-architecture/stage1-path-c.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "MotionMix iOS is the master. It already has EchelonBridge (128D canonical vector), ParamMapper, SAN, ChestFlexDetector, MocopiFeatureExtractor, AudioEngine, StrudelWebEngine, and LiveStreamServer. K11 becomes a dumb sensor bridge: it runs publishers and Unity for visual rendering, but all intelligence decisions flow from the iPhone. The phone tells K11 what to render and Mac5 what to play.", "excerpt": "MotionMix iOS is the master. It already has EchelonBridge (128D canonical vector), ParamMapper, SAN, ChestFlexDetector, MocopiFeatureExtractor, AudioEngine, StrudelWebEngine, and LiveStreamServer. K11 becomes a dumb sensor bridge: it runs publishers and Unity for visual rendering, but all intelligence decisions flow from the iPhone. The phone tells K11 what to render and Mac5 what to play.\n\n- **Leverages the most mature code.** EchelonBridge + SAN + ParamMapper is the most tested, most iterated intelligence stack. It's been trained on real data (5,408 pairs). - **iPhone sensor fusion is unmatched.** CoreMotion + Vision BodyPose + LiDAR + face detection. No equivalent on K11. - **Already works.** The iOS app already drives Strudel.js audio and already consumes mocopi data. This is the smallest delta from current state. - **Single control surface.** Mohamed holds the phone. One device to rule them all.\n\n- **CRITICAL: Adds latency to visual path.** Depth camera data would need to flow K11 -> iOS -> K11 for any motion-reactive visual decisions. That's a round trip through Tailscale. Unacceptable for 60fps visuals. - **Phone battery.** Running EchelonBridge at 60Hz + SAN at 30Hz + network I/O + camera is a battery drain. iPhone 16 Plus has ~4-5 hours of heavy use. - **Phone thermal throttle.** Sustained 60Hz compute + camera + networking causes iOS thermal management to kick in after 30-45 minutes. - **Phone is also the camera.** If MotionMix is the brain AND a camera node, it's doing too much. The model (Mohamed) holds the phone during performance. - **New protocol needed.** \"VISUAL_CMD\" from iOS to K11 Unity doesn't exist. This is a new wire format, new consumer, new complexity. - **K11 Unity already reacts locally.** LumeOpticalFlow, LumeMotionGate, LumeAudioFftReceiver all react to sensor data locally on K11. Making them follow remote commands breaks the local reactivity that makes the visuals feel alive.\n\nREJECT as primary architecture. The phone should remain a brain for MUSIC (it already drives Strudel.js) but should NOT be the brain for VISUALS. Visual reactivity must remain K11-local. The phone's correct role is: (1) provide the 128D canonical vector for music synthesis, (2) consume LUMM for MocopiFeatureExtractor, (3) drive Strudel.js audio. It should NOT try to control K11's visual pipeline remotely.", "htmlHref": "/research/html/path-c-motionmix-as-brain-ios-app-is-the-conductor-k11-is-just-sensors-1mor5oe.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 547 }, { "id": "path-d-unity-as-middleware-unity-on-k11-becomes-the-central-bus-1dkw58d", "title": "Path D: Unity-as-Middleware -- Unity on K11 Becomes the Central Bus", "slug": "path-d-unity-as-middleware-unity-on-k11-becomes-the-central-bus", "kind": "architecture", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-full-system-architecture/stage1-path-d.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Unity is not just a renderer. It becomes the system's central message bus. All sensor data flows into Unity. Unity extracts features (motion, audio, depth), makes all reactive decisions locally, and ALSO publishes derived features outward to other consumers via UDP. Unity becomes both consumer AND producer. A new \"LumeSystemBus\" C# component aggregates all signals and publishes a unified state packet at 30Hz that any mesh node can subscribe to.", "excerpt": "Unity is not just a renderer. It becomes the system's central message bus. All sensor data flows into Unity. Unity extracts features (motion, audio, depth), makes all reactive decisions locally, and ALSO publishes derived features outward to other consumers via UDP. Unity becomes both consumer AND producer. A new \"LumeSystemBus\" C# component aggregates all signals and publishes a unified state packet at 30Hz that any mesh node can subscribe to.\n\n- **Zero latency for visual path.** All sensor -> visual processing is local loopback. - **Unity already does feature extraction.** LumeOpticalFlow computes motion. LumeAudioFftReceiver computes audio features. LumeMotionGate computes time scale. Unity is ALREADY the bus; this path just makes it explicit. - **New LUMS wire format is cheap.** 84 bytes at 30Hz is trivial network load. Derived features are more useful than raw sensor data for remote consumers. - **Simplifies MotionMix's job.** Instead of consuming 3 raw streams (LUMD, LUMF, LUMM), MotionMix consumes 1 derived stream (LUMS). Feature extraction happens once on K11, not redundantly on every consumer. - **Consistent with LUME wire format family.** LUMS (0x4C554D53) extends the existing protocol.\n\n- **Unity main thread bottleneck.** All C# components run on Unity's main thread (Update/LateUpdate). Adding more processing risks frame drops below 60fps on Radeon 780M. - **C# is the wrong language for motion intelligence.** ParamMapper's velocity detection, cadence detection, and rhythm stability algorithms are elegant in Swift. Porting to C# loses the tight integration with Vision/CoreMotion and the SAN pipeline. - **Mocopi feature extraction in Unity is weak.** MocopiFeatureExtractor in Swift uses specific joint velocity/limb ratio algorithms tuned for the 128D canonical vector. A C# version would be a parallel implementation with no shared test suite. - **Unity is not a message broker.** It doesn't handle subscriptions, backpressure, or reliable delivery. Bolting pub-sub onto Unity's update loop is architecturally wrong. - **Loses the 128D canonical vector.** The canonical vector is computed by Echelon (Rust via iOS FFI). Unity has no access to the latent state, SAN outputs, lexicon, or section state.\n\nPARTIAL ADOPT. The insight that Unity should PUBLISH derived features (not just consume raw ones) is correct. LUMS as a derived state packet is a good idea. But Unity should not try to be a general-purpose intelligence layer or replace MotionMix's motion-to-music mapping. Unity's job: consume sensor data, render visuals, publish derived visual-scene state.", "htmlHref": "/research/html/path-d-unity-as-middleware-unity-on-k11-becomes-the-central-bus-1dkw58d.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 633 }, { "id": "graph-vector-intelligence-mega-cube-17-stage-1-path-a-the-edge-table-15imdgk", "title": "Graph + Vector Intelligence (Mega-Cube 17) -- Stage 1, Path A: The Edge Table", "slug": "graph-vector-intelligence-mega-cube-17-stage-1-path-a-the-edge-table", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/mega-cube-17-graph-vector-intel/stage1-path-a.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Add a single `memory_edges` table to the existing Postgres schema. Edges connect `memory_turns` rows by relationship type: temporal (same session), referential (shared file), causal (correction/follow-up), and categorical (shared inscription). Vector search stays exactly as-is. Graph queries are standard SQL joins. No new services, no new databases, no new dependencies. The graph is a Postgres table.", "excerpt": "# Graph + Vector Intelligence (Mega-Cube 17) -- Stage 1, Path A: The Edge Table **Run:** mega-cube-17-graph-vector-intel **Generated:** 2026-04-04 **Method:** Evolution-Cube Stage 1 -- Divergent exploration (relational graph in Postgres) **Run Directory:** Desktop/evo-cube-output/mega-cube-17-graph-vector-intel/\n\nAdd a single `memory_edges` table to the existing Postgres schema. Edges connect `memory_turns` rows by relationship type: temporal (same session), referential (shared file), causal (correction/follow-up), and categorical (shared inscription). Vector search stays exactly as-is. Graph queries are standard SQL joins. No new services, no new databases, no new dependencies. The graph is a Postgres table.\n\n| Type | Source | Target | Weight | Metadata | |------|--------|--------|--------|----------| | `temporal` | Turn N in session | Turn N+1 in session | 1.0 (decays with gap) | `{session_id, gap_seconds}` | | `referential` | Turn that reads file X | Turn that wrote file X | cosine(embed_A, embed_B) | `{file_path, operation}` | | `causal` | Correction turn | Original turn | KARL correction score | `{correction_type, overlap}` | | `categorical` | Turn with inscription A | Turn with same inscription | inscription similarity | `{inscription, category}` | | `trajectory` | Trajectory start | Trajectory end | KARL composite reward | `{skill, domain, reward}` |\n\n- 332K turns, avg 5 turns/session = ~66K sessions - Temporal edges: ~266K (N-1 per session of N turns) - Referential edges: ~50K (file path overlap across sessions) - Causal edges: ~5K (KARL corrections + redo detections) - Categorical edges: ~20K (inscription-matched pairs, sampled) - Trajectory edges: ~121 (KARL trajectory start-to-end) - **Total: ~341K edges.** Fits in ~50MB with indexes.\n\nWeight decays with temporal gap: 1.0 for consecutive turns, ~0.5 for 1-hour gap, ~0.1 for 10-hour gap.", "htmlHref": "/research/html/graph-vector-intelligence-mega-cube-17-stage-1-path-a-the-edge-table-15imdgk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1657 }, { "id": "stage-0-research-multi-agent-survival-algorithms-nash-equilibrium-escape-1blx6cf", "title": "Stage 0: RESEARCH -- Multi-Agent Survival Algorithms: Nash Equilibrium Escape", "slug": "stage-0-research-multi-agent-survival-algorithms-nash-equilibrium-escape", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/multi-agent-survival-algorithms/stage0-research.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date**: 2026-03-10 **Source**: code4AI video rTwrFdyRmww (score: 8.0/10) **Target Systems**: Evolution World (primary), Multi-Agent Mesh (primary), KARL (secondary)", "excerpt": "**Date**: 2026-03-10 **Source**: code4AI video rTwrFdyRmww (score: 8.0/10) **Target Systems**: Evolution World (primary), Multi-Agent Mesh (primary), KARL (secondary)\n\n**Architecture**: - **L1 (App Evolution)**: Individual app genomes mutate via TIE techniques toward milestones - **L2 (Meta-Evolution)**: The evolution process itself adapts (technique weights, selection strategy, decomposition method, risk tolerance, exploration rate) - **L3 (Meta-Meta-Evolution)**: Evolves L2's constants every 30 L1 steps - **4 Non-Halting Invariants**: 1. **Minimum Entropy Production**: Every step must produce >= epsilon (0.01) bits of novelty (KL divergence). Prevents stalling. 2. **Bounded Divergence**: Divergence rate capped at M (2.0) over sliding window. Prevents chaos. 3. **Cross-Layer Forcing**: L1 stall (3 steps) forces L2 mutation. L2 stall (5 steps) forces L1 phase transition. Neither layer can stall independently. 4. **No Absorbing States**: Every configuration must have >= 2 viable transitions. Prevents dead ends.\n\n**Immune System**: 4-tier escalation (Innate -> Soft Quarantine -> Hard Quarantine + Exploration Burst -> Threshold Recalibration). Sliding window of 10 heartbeats. Detects dead-ends via co-violation patterns (min_entropy + no_absorbing_states).\n\n**Population Genetics**: Crossover operators (capability graft, architecture allele, operator transfer), species distance matrix (L2-evolved), within-species and between-species crossover with convergence gates.\n\n**Selection Strategies**: tournament, roulette, rank_based, elitist, diversity_driven -- L2 mutates between these.", "htmlHref": "/research/html/stage-0-research-multi-agent-survival-algorithms-nash-equilibrium-escape-1blx6cf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1931 }, { "id": "stage-2-compound-architecture-twin-swarm-cognitive-routing-ewao1f", "title": "Stage 2: Compound Architecture — Twin Swarm + Cognitive Routing", "slug": "stage-2-compound-architecture-twin-swarm-cognitive-routing", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/twin-swarm-cognitive-routing/stage2-compound.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Decision:** Path D's \"twin-first, escalate on failure\" is the right default because it eliminates routing latency for 80% of tasks and leverages the key finding that RAG achieves 87.2% accuracy alone. But Path D's blind escalation is wasteful. Path B's cascade adds intelligence without replacing the fast path.", "excerpt": "## Step 1: Twin-First Default + Cascade Escalation (inherits Stage 0 + Path D + Path B)\n\n**Decision:** Path D's \"twin-first, escalate on failure\" is the right default because it eliminates routing latency for 80% of tasks and leverages the key finding that RAG achieves 87.2% accuracy alone. But Path D's blind escalation is wasteful. Path B's cascade adds intelligence without replacing the fast path.\n\n**Default flow (80% of tasks):** Task → Twin Alpha (Qwen3-235B via Together AI, RAG-augmented) → Output. No classification. No routing. ~1500ms latency (RAG retrieval + generation).\n\n**Smart escalation (replaces Path D's blind retry):** When Twin Alpha fails (build error, test failure, user rejection), don't just retry or blindly escalate. Run Path B's Layer 1 feature classifier on the failed task to determine WHY it failed: - Complexity > 0.7 → escalate to Claude (task was too hard for twin) - Domain mismatch detected → route to domain specialist (Swift→Claude on Mac1, analysis→Codex) - The failure reason itself becomes a classification signal\n\n**Result:** Twin handles everything by default. Failures get intelligent triage. No upfront routing cost.", "htmlHref": "/research/html/stage-2-compound-architecture-twin-swarm-cognitive-routing-ewao1f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1235 }, { "id": "evolution-stage-0-research-brief-v4-5hm56w", "title": "Evolution³ — Stage 0: Research Brief (V4)", "slug": "evolution-stage-0-research-brief-v4", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/v4-rust-threads/stage0-research-brief.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**V2 (Technical Substrate)** decided: - Centralized TypeScript daemon with hot standby on Mac4 - TOML declarative manifests for service/flow/skill definitions - WebSocket pub/sub event bus for inter-service messaging - 43-task master plan, 264 hours, 10-16 weeks", "excerpt": "# Evolution³ — Stage 0: Research Brief (V4) ## NUMU FARE — Rust Core + Native Thread Intelligence + openclaw Library Integration ### Generated: 2026-03-05 | Method: 3 parallel research agents + 2 prior evo-cube runs (V2 substrate, V3 personal OS)\n\n**V2 (Technical Substrate)** decided: - Centralized TypeScript daemon with hot standby on Mac4 - TOML declarative manifests for service/flow/skill definitions - WebSocket pub/sub event bus for inter-service messaging - 43-task master plan, 264 hours, 10-16 weeks\n\n**V3 (Personal Integration)** decided: - Name: **NUMU FARE** (ߒߎߡߎ ߝߊ߬) — \"The Forge That Crosses\" - CLI: `numu`, Fleet: `numu fleet`, Intelligence: \"The Weave\" - 147 skills with heat tracking + memory spines (40 active, 107 cold storage) - Adaptive enrichment curriculum (MASTER/CRAFTSMAN/JOURNEYMAN depth) - ADI personas as forge temperatures - 7-wave implementation plan (~7 weeks, score target 7.6→9.2)\n\n**V4 introduces three new dimensions that reshape the architecture:** 1. The openclaw/openclaw library patterns — proven at scale, directly adoptable 2. Rust as the daemon language — performance, safety, deployment characteristics 3. Native Discord thread management — threads as first-class workspaces, not afterthoughts\n\n### What It Is A TypeScript/Node.js personal AI assistant platform (263K+ GitHub stars). It solves many of the same problems NUMU FARE faces: multi-model orchestration, skill/tool management, context enrichment, memory search, session management.", "htmlHref": "/research/html/evolution-stage-0-research-brief-v4-5hm56w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 2585 }, { "id": "stage-1-path-f-the-voice-mesh-protocol-every-node-gets-a-mouth-and-an-ear-1b5ej4z", "title": "Stage 1 Path F: The Voice Mesh Protocol — Every Node Gets a Mouth and an Ear", "slug": "stage-1-path-f-the-voice-mesh-protocol-every-node-gets-a-mouth-and-an-ear", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/voice-first-agent-architecture/stage1-path-f.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> Grounded in: Stage 0 finding that 4 Mac machines exist in the mesh but only phones have voice I/O. The mesh nodes are deaf and mute.", "excerpt": "> Grounded in: Stage 0 finding that 4 Mac machines exist in the mesh but only phones have voice I/O. The mesh nodes are deaf and mute.\n\nDon't centralize voice. Distribute it. Every node in the mesh (Mac1, Mac4, Mac5, cloud-vm) gets a microphone daemon (ear) and a TTS daemon (mouth). Inter-node voice happens over the existing NUMU/Mesh Event Bus. The mesh doesn't need a voice server — it needs voice as a native capability of every node, like networking.\n\n**4. Spatial Voice (multi-room):** If machines are in different rooms/locations: - Mac1 (office desk) = primary interaction point - Mac4 (server rack area) = status announcements only - Mac5 (beside Mac4) = paired with Mac4 for compute status - Each machine's TTS volume and frequency tuned to its physical context\n\n- Every machine becomes voice-interactive, not just the phone - Cross-machine voice relay enables \"talk to Mac4 through Mac1\" - Distributed voice means no single point of failure - Each node's voice daemon is independent — works offline for local commands - Builds on existing NUMU event bus and mesh architecture - Physical presence at any machine = voice access to entire mesh\n\n- Mac4 and Mac5 may not have microphones (headless compute nodes) - Audio hardware management across 4+ machines is complex - Echo/feedback loops if two machines are near each other (Mac4+Mac5 side by side) - Whisper model on every node = memory overhead per machine - NUMU event bus latency for voice relay (~50-200ms) adds to response time - No authentication for voice commands — anyone near a mic can issue commands (mitigate: speaker ID)", "htmlHref": "/research/html/stage-1-path-f-the-voice-mesh-protocol-every-node-gets-a-mouth-and-an-ear-1b5ej4z.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 583 }, { "id": "handoff-mesh-v1-1-event-sourced-rail-karl-reward-engine-1w40bx8", "title": "Handoff: Mesh / V1.1 Event-Sourced Rail / KARL Reward Engine", "slug": "handoff-mesh-v1-1-event-sourced-rail-karl-reward-engine", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "Leisure/HANDOFF-mesh-karl-to-sea-2026-05-14.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "**From:** the agent running the \"Life of Leisure, mesh from phone\" goal (mac1, main session) **To:** the SEA (skill-entity-architecture) agent **Date:** 2026-05-14 **Why you're getting this:** you've been working on SEA / the mac3-worker-config track. This session drifted from a phone-app build into a corpus-wide KARL reward-engine repair. The work is real and committed, but one piece (`karl train`) is blocked on a rate-limited machine, and you may be able to unblock it. Full context below so you can pick up cleanl", "excerpt": "**From:** the agent running the \"Life of Leisure, mesh from phone\" goal (mac1, main session) **To:** the SEA (skill-entity-architecture) agent **Date:** 2026-05-14 **Why you're getting this:** you've been working on SEA / the mac3-worker-config track. This session drifted from a phone-app build into a corpus-wide KARL reward-engine repair. The work is real and committed, but one piece (`karl train`) is blocked on a rate-limited machine, and you may be able to unblock it. Full context below so you can pick up cleanly.\n\nThe active `/goal` is the **\"Life of Leisure, mesh from phone\"** build: run all 5 Macs (mac1-5) + K11 from an iPhone, hands-off, via two pieces:\n\n- **aura-gateway** — FastAPI service on `mac1:8095`, launchd label `com.openclaw.aura-gateway`, file at `[home-path]`. The control plane: inject prompts cross-machine over SSH+tmux, spawn sessions, autopilot loops, wake-on-LAN, and a **flow runtime**. - **Pebble** — iOS app at `Desktop/Pebble/`, bundle `com.diomande.pebble`. The phone surface. Conversations list + chat + a FlowsSection driving the gateway's flow runtime.\n\nThe leisure metric: \"Tier-C taps per active hour, under 5 = leisure.\" The point is to walk away from the laptop.\n\n**The honest summary:** KARL was never a deliberate destination. The V1.1 architecture verdict (Path C + Path F from the divergent doc) said completed flows become KARL trajectory cards. Phase 2 wired that. \"Backfill the scores\" was a natural next-step — and once inside KARL, the backfill kept hitting pre-existing bugs that had nothing to do with flows. Every record in the corpus was scoring a flat 0.5. Fixing that was the right call (root-cause over symptom) but it drifted us well off the leisure/mesh goal.", "htmlHref": "/research/html/handoff-mesh-v1-1-event-sourced-rail-karl-reward-engine-1w40bx8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1633 }, { "id": "lume-chain-2-sky-garden-duncan-parity-push-jzh6jz", "title": "LUME Chain 2 — Sky Garden Duncan-parity push", "slug": "lume-chain-2-sky-garden-duncan-parity-push", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/chains/RELEASE-CHAIN-2.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "**Status:** RELEASED (plan + patches ready to apply, live verification pending) **Subject:** Drive LUME Sky Garden mode on Mac4 to Duncan Fewkes parity in visual feel. **Started:** 2026-05-08 **Released:** 2026-05-08 **Chain owner:** Mohamed **Execution model:** META:OMEGA + META:HYDRA collapsed (single pass), 8-lens reviewed **Prerequisite:** Chain 1 (Echelon Layer 4 + 128D Temporal Closure) released same day, see `docs/chains/RELEASE-CHAIN-1.md`.", "excerpt": "**Status:** RELEASED (plan + patches ready to apply, live verification pending) **Subject:** Drive LUME Sky Garden mode on Mac4 to Duncan Fewkes parity in visual feel. **Started:** 2026-05-08 **Released:** 2026-05-08 **Chain owner:** Mohamed **Execution model:** META:OMEGA + META:HYDRA collapsed (single pass), 8-lens reviewed **Prerequisite:** Chain 1 (Echelon Layer 4 + 128D Temporal Closure) released same day, see `docs/chains/RELEASE-CHAIN-1.md`.\n\nThis release bundles a VALIDATED PLAN + READY-TO-APPLY PATCHES for closing the visual gap between LUME Sky Garden mode and Duncan Fewkes-grade visuals on Mac4. It does NOT contain a fully shipped + verified live system. Live verification is gated on Codex / Mohamed applying the patches on Mac4 and recording side-by-side OBS comparison footage.\n\nThe release covers W13.0 (sky parallax + god rays + breath modulation), W13.1 (pond reflection + DOF), and W13.2 (body subsurface + heat shimmer). W13.3 (operator camera overlay), W13.4 (cinematic framing), and W13.5 (show director) are deferred to a follow-up chain per the 8-lens review (W13.5 was identified as over-architecture risk; W13.3 + W13.4 require partial GUI authoring outside Codex's autonomous range).\n\n| # | Criterion | Verification status | |---|-----------|---------------------| | 1 | Side-by-side OBS comparison: Mac4 Sky Garden vs Duncan reel reference, must read as \"same family\" | **BLOCKED on Codex applying patches + recording on Mac4.** Patches READY (12 artifacts in `Desktop/omega-output/skygarden-duncan-parity-20260508/patches/`). Reference corpus AVAILABLE (`[home-path]` — 82 reels × 12 frames). | | 2 | No FPS regression on Mac4 (60fps min at 1080p) | **PATCHES BUDGETED FOR THIS GATE.** Review Lens 1 (Feasibility) sized each patch against Radeon 780M's 9 TFLOPS budget. Total predicted W13.0+W13.1+W13.2 GPU cost: ~6.5ms within remaining 7ms budget after baseline ~9ms. Live verification BLOCKED on capture. | | 3 | No new external runtime cost (no jump in K11↔Mac4 traffic, no new endpoints) | **DESIGN COMPLIANT.** All W13.0/W13.1/W13.2 changes are local Mac4 GPU passes. No new K11↔Mac4 wire format. No new UDP ports. | | 4 | Sky Garden remains compatible with Wave 9 visual presets (LumeFrozenFlow, LumeKaleidoscope) | **DESIGN COMPLIANT.** Review Lens 3 (Risk) audited shared globals; new W13 globals are gated by `*Active` floats matching W11.4 BodyGlow pattern. Injection points ordered (god rays + heat shimmer at `BeforeRenderingPostProcessing`, kaleido at `AfterRenderingPostProcessing`) so the kaleido mirror catches W13 effects correctly. Live verification BLOCKED on running both modes after patch application. |\n\n**Honest summary:** All 4 criteria are GATED on live capture. The patches are ready, the budget math works out, the architecture is compa", "htmlHref": "/research/html/lume-chain-2-sky-garden-duncan-parity-push-jzh6jz.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1802 }, { "id": "codex-plan-what-to-do-next-ranked-jtmh23", "title": "Codex plan — what to do next, ranked", "slug": "codex-plan-what-to-do-next-ranked", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/handoffs/CODEX-PLAN.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "> **Topology correction, 2026-04-26:** Mac4 is the current Unity Editor / GUI smoke-test host and real-Femto capture host. Mac5 is still the synthpub LaunchAgent / synthetic fallback host. Do not blindly replace all Mac5 references; see `software/demo/TOPOLOGY-CORRECTION-2026-04-26.md`.", "excerpt": "> **Topology correction, 2026-04-26:** Mac4 is the current Unity Editor / GUI smoke-test host and real-Femto capture host. Mac5 is still the synthpub LaunchAgent / synthetic fallback host. Do not blindly replace all Mac5 references; see `software/demo/TOPOLOGY-CORRECTION-2026-04-26.md`.\n\n_Read `CODEX-CONTEXT.md` + `ARCHITECTURE.md` first. This file is the priority-ordered action list. Each item has: scope, success criteria, files to touch, things to avoid, and when to escalate to Mohamed._\n\n1. `CODEX-CONTEXT.md` — origin, evolution, decision log. 2. `unity/lume_pcloud/ARCHITECTURE.md` — current state mental model. 3. **This file (`CODEX-PLAN.md`)** — next actions. 4. `MAC5-CODEX-HANDOFF-2026-04-26.md` — bootstrap prompt with commit ledger + smoke-test commands. 5. `DUNCAN-GAP-ANALYSIS.md` — what's left to match Duncan's stack. 6. `Reference/Duncan/INDEX.md` — 83 reels + 69 analyses.\n\n- **22 commits** on `main`, no push, Mac1 source-of-truth. - **Mac5 sync deferred** — Tailscale 100% loss across multiple checks. - **10 Unity components** (5 base + 5 Wave 4-5 additions). - **37 pytest tests** passing (33 fast + 4 slow). - **Wave 5 score: 4 of 5 priorities shipped** (impulse, calibration, motion-gate, ARCHITECTURE.md). Remaining: fluid sim, marching cubes.\n\nIf both fail: - Mac5 is physically off (cable / power) - Tailscale on Mac5 is dead — needs manual restart - Tailscale on Mac1 is dead — `tailscale status` will reveal", "htmlHref": "/research/html/codex-plan-what-to-do-next-ranked-jtmh23.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1278 }, { "id": "mac5-codex-handoff-2026-04-26-14-30-local-last-revised-16-15-post-wave-5-y03l0c", "title": "Mac5 Codex handoff — 2026-04-26 ~14:30 local (last revised ~16:15 post-Wave-5)", "slug": "mac5-codex-handoff-2026-04-26-14-30-local-last-revised-16-15-post-wave-5", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/handoffs/MAC5-CODEX-HANDOFF-2026-04-26.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "> **Topology correction, 2026-04-26:** Mac4 is the current Unity Editor / GUI smoke-test host and real-Femto capture host. Mac5 is still the synthpub LaunchAgent / synthetic fallback host. Do not blindly replace all Mac5 references; see `software/demo/TOPOLOGY-CORRECTION-2026-04-26.md`.", "excerpt": "# Mac5 Codex handoff — 2026-04-26 ~14:30 local (last revised ~16:15 post-Wave-5)\n\n> **Topology correction, 2026-04-26:** Mac4 is the current Unity Editor / GUI smoke-test host and real-Femto capture host. Mac5 is still the synthpub LaunchAgent / synthetic fallback host. Do not blindly replace all Mac5 references; see `software/demo/TOPOLOGY-CORRECTION-2026-04-26.md`.\n\n**This file supersedes the 2026-04-25 handoff** (`MAC5-CODEX-HANDOFF.md`, which anchored on Wave 1 only). This one covers Waves 1-5 (22 commits) plus the Duncan reference library + gap analysis.\n\n1. **`CODEX-CONTEXT.md`** — origin, evolution, decision log. *Why* the pipeline looks the way it does. Read this FIRST. 2. **`unity/lume_pcloud/ARCHITECTURE.md`** — current state mental model. The 10-component graph + 13 global uniforms + wire formats. 3. **`CODEX-PLAN.md`** — priority-ranked next-action list with success criteria + escalation triggers. 4. **This file** — operational bootstrap prompt (below). Paste into Codex on Mac5 once you've read 1-3. 5. `DUNCAN-GAP-ANALYSIS.md` — what's left to match Duncan's stack. 6. `Reference/Duncan/INDEX.md` — 83 reels + 69 analyses, indexed by Duncan's own E-numbering.\n\nPaste from `## ↓↓↓ paste this to Codex ↓↓↓` to the end of this file as the bootstrap prompt.", "htmlHref": "/research/html/mac5-codex-handoff-2026-04-26-14-30-local-last-revised-16-15-post-wave-5-y03l0c.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1437 }, { "id": "lume-cad-approval-pack-k11-t-form-audit-1565bh2", "title": "LUME CAD Approval Pack - K11 T-Form Audit", "slug": "lume-cad-approval-pack-k11-t-form-audit", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/CAD_APPROVAL_PACK.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Superseded for the current hardware pass by `LUME_CURRENT_BUILD_SPEC.md`, which adds the ZHAOCAILIN top display, Arducam IMX586 mount, K11-era rear pod interface, and approval-v2 STL exports.", "excerpt": "Superseded for the current hardware pass by `LUME_CURRENT_BUILD_SPEC.md`, which adds the ZHAOCAILIN top display, Arducam IMX586 mount, K11-era rear pod interface, and approval-v2 STL exports.\n\n> Do not use this as the active print plan. It is retained only as an audit trail for the earlier K11 T-form review.\n\nThis is a repo-grounded audit of the current CAD, STL exports, and prearranged 3MF print plates. It corrects the earlier \"31 parts\" claim.\n\n- Front bar: 500 x 120 x 85 mm rounded enclosure, printed as four shell halves. - Rear pod: centered pod behind the bar for the GMKtec K11, K11 sled, cable bend, airflow, and VESA mount. - Compute: K11 lives in the pod. Do not use the old Jetson AGX Orin sled path. - Sensors: Orbbec Femto Mega/front camera window, two SVPRO brackets, UMA-8 mic rail, LED diffuser, cable backbone. - Top display: 1920 x 440 strip display is represented, but dimensions are still placeholder and not approved.\n\n- `renders/approval/approval_form_factor.png` - fresh T-form overview, top view, side/front views, pod exploded, and current top display cutout. - `renders/approval/approval_shell_halves.png` - all four printed shell halves, exterior and interior. - `renders/approval/approval_print_plates.png` - the seven prearranged 3MF plate thumbnails. - `renders/approval/approval_small_parts.png` - active small parts plus flagged legacy/optional pieces.", "htmlHref": "/research/html/lume-cad-approval-pack-k11-t-form-audit-1565bh2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1210 }, { "id": "lume-v1-printer-pre-flight-1ytwn1s", "title": "LUME v1 — Printer Pre-Flight", "slug": "lume-v1-printer-pre-flight", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/pre-flight.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Printer setup notes only, 2026-04-30: the machine setup and ASA calibration notes are still useful, but the referenced print queue/plates are old. Use `PRINT_APPROVAL_QUEUE_CURRENT.md` for current LUME part order.", "excerpt": "> Printer setup notes only, 2026-04-30: the machine setup and ASA calibration notes are still useful, but the referenced print queue/plates are old. Use `PRINT_APPROVAL_QUEUE_CURRENT.md` for current LUME part order.\n\nChecklist from unboxing the Neptune 4 Max to starting the first LUME plate. Target: printer arrives Wed AM → first ASA part printing Wed +4h.\n\n- [ ] Unbox, remove all foam + zip ties (check gantry, bed, hotend, belts — N4M has 6 transit ties). - [ ] Mount spool holder + filament runout sensor. Plug in both. - [ ] Power cord to 120V. Ensure switch on rear is OFF before plugging. - [ ] Boot. Touchscreen should light — firmware version visible. - [ ] Connect to 2.4GHz WiFi via touchscreen. Note IP for Orca LAN upload.\n\n- [ ] Run auto-level from touchscreen (Prepare → Level → Auto). 49-point mesh. ~8 min. - [ ] Set Z-offset by live-feedback method: 1. Heat bed to 100°C, nozzle to 260°C (ASA conditions — we level hot because ASA warps on cold bed). 2. Home all. Disable steppers. 3. Slide a sheet of standard A4 paper under nozzle. Lower Z until paper drags with light friction. 4. Save Z-offset to profile. - [ ] Accept auto Z-offset or nudge −0.03mm if paper tears (too close) or glides freely (too far).\n\n- [ ] Pre-heat hotend to **260°C** (wait for stable). - [ ] Snip filament end at 45° angle. - [ ] Feed through runout sensor → extruder → into hotend. Push gently until extruder motor grips. - [ ] Extrude 50mm via touchscreen. Purge should come out grey, smooth, no bubbling or popping. - [ ] If popping (moisture in ASA): dry spool 6h in food dehydrator at 70°C before using. If ASA came from a sealed Polymaker bag, skip drying.", "htmlHref": "/research/html/lume-v1-printer-pre-flight-1ytwn1s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1021 }, { "id": "e415-duncan-fewkes-reel-analysis-digest-19jcgqj", "title": "E415 — Duncan Fewkes reel analysis digest", "slug": "e415-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E415-noreel.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Caption progression: - E469: *\"shoulda done it sooner — Amazing the daft poses that some rotational symmetry prompts you to hit\"* - E471: tests metallic vs non-metallic surface, adds \"test box environment so the metallic surface has something to reflect\" - E472: extends from upper-body-only to full body so legs participate", "excerpt": "⚠ No video on disk for this reel — referenced by the playbook but not in the local ingest cache.\n\nThis file aggregates every playbook chunk section that cites E415. Sections are de-duplicated by heading.\n\nCaption progression: - E469: *\"shoulda done it sooner — Amazing the daft poses that some rotational symmetry prompts you to hit\"* - E471: tests metallic vs non-metallic surface, adds \"test box environment so the metallic surface has something to reflect\" - E472: extends from upper-body-only to full body so legs participate\n\nMechanism (inferred from visuals): - Take live depth-camera silhouette - Rotate + mirror N times around screen-center axis (kaleidoscope = rotational symmetry, typically 6 or 8 fold) - Composite the rotated copies on top of each other - Apply chrome / matte material toggle for surface change - Reflection probe in the middle of the symmetry gives the metallic copies something to reflect\n\n**LUME mapping:** add `LumeKaleidoscope.cs` as a Wave 4 VFX preset. Cheap to ship — single render texture + N copies rotated by `60°*i`. Plays well with our Femto depth stream (silhouette already segmented). Useful as a \"performance mode\" where one user generates an N-fold pattern. Net new mode for the playbook.", "htmlHref": "/research/html/e415-duncan-fewkes-reel-analysis-digest-19jcgqj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1636 }, { "id": "e475-duncan-fewkes-reel-analysis-digest-109s4cl", "title": "E475 — Duncan Fewkes reel analysis digest", "slug": "e475-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E475-noreel.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, D", "excerpt": "⚠ No video on disk for this reel — referenced by the playbook but not in the local ingest cache.\n\nThis file aggregates every playbook chunk section that cites E475. Sections are de-duplicated by heading.\n\n- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, DT6IlEfig-k, DTBUJiDCvPQ, DScEatyilnk). DSfZYMUChIi + DSZmIhOCrTv hit Gemini 429 quota exhaustion; captions on those are still detailed.\n\n- 16-clone radial ring around centre — N=16 is his settled number. Tested 20/24/32, \"makes it even harder to read the human form.\" - Each clone is a rotational copy of the live depth silhouette - Slow top-level rotation of the entire ring - LOD mesh switching to push more clones (tunnel formation in E476) - E479 stacks a SECOND ring of new-colour clones snapshot every second, falling inwards into turbulence — he's doing temporal stacking on top of spatial mirroring - He explicitly rejected per-clone twist: \"additional twists ... too much variance and makes the shape much harder to read.\"\n\n**LUME design rule from this**: when stacking visual transforms, ONE rotational symmetry is enough. Don't compound symmetries; pick one and let temporal evolution do the rest.", "htmlHref": "/research/html/e475-duncan-fewkes-reel-analysis-digest-109s4cl.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2521 }, { "id": "e527-duncan-fewkes-reel-analysis-digest-1pfyjj2", "title": "E527 — Duncan Fewkes reel analysis digest", "slug": "e527-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E527-DUSui7PioUD.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)", "excerpt": "Source video: `../reels/E527-DUSui7PioUD.mp4` (symlink to `[home-path]`) Caption: `../reels/E527-DUSui7PioUD.txt`\n\nThis file aggregates every playbook chunk section that cites E527. Sections are de-duplicated by heading.\n\n- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)\n\nE527, E544, E532, E544 (DUSui7PioUD, DU-52fcinww, DUgoDHlipPu) all confirm Duncan ships into a **branded \"Holovis®\" CAVE / wide LED installation venue**. This is not lab work, this is **a live commercial installation product**. Implications for LUME:\n\n- The visuals are tuned for a wide curved LED CAVE (multi-panel) — but he is now porting to a flat 17m × 3m screen (E567 caption). LUME's 1-3 vertical monitors is a smaller close-cousin of \"flat 17m × 3m\". - Each install gets per-site calibration — he literally calls out: *\"need to rebalance threshold etc values for the actual usage distance — probably easiest to expose in settings and debug menu to allow for tweak values for each install individually\"* (E568). **LUME action**: ship a per-install settings file (motion threshold, depth-camera distance, smoothing) loaded from disk, exposable via debug menu. - The Holovis logo is itself one of the VFX targets — a \"Logo:\" preset slot on the VFX editor (we already had this in the prior playbook). New twist below.", "htmlHref": "/research/html/e527-duncan-fewkes-reel-analysis-digest-1pfyjj2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2485 }, { "id": "e536-duncan-fewkes-reel-analysis-digest-mwynv7", "title": "E536 — Duncan Fewkes reel analysis digest", "slug": "e536-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E536-DUqHj-BCgP4.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)", "excerpt": "Source video: `../reels/E536-DUqHj-BCgP4.mp4` (symlink to `[home-path]`) Caption: `../reels/E536-DUqHj-BCgP4.txt`\n\nThis file aggregates every playbook chunk section that cites E536. Sections are de-duplicated by heading.\n\n- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)\n\nThis is a concept the prior playbook missed. Logos / wordmarks are not just static overlays — they are **3D volumes that become particle obstacles, spawn surfaces, or \"punch through\" reveals**:\n\n- **E530 \"Punch Through\"**: invisible logo + inverted-obstacle fluid sim → particles get thrown out of letter shapes, leaving you visible through the gaps between letters. *\"Works because high fluid influence throws particles out of the logo letters, and no particle kill for zero velocity, so particles get stuck in non-fluid-flow area.\"* - **E528 cymatics**: ShortThrow fluid sim + logo letters → particles \"stuck\" on letters bouncing internally → almost cymatic (Chladni-plate) pattern. - **E536 self-critique**: *\"Need to rewrite spawning buffers to use entire screen (not just depth camera point cloud) so can easily spawn particles on/in eg logos, metaballs or other geometry.\"* — this is a major architectural TODO he hasn't done yet. **LUME can leapfrog**: build the spawn buffer to accept any signed-distance source (depth, logo SDF, metaball SDF) from day 1. - **E544 \"Blocky PinScreen Revisit\"**: Holovis text reacts volumetrically — *\"interactive text displayed and reacts volumetrically to the user's movements, allowing the user to walk through or displace the letters.\"*", "htmlHref": "/research/html/e536-duncan-fewkes-reel-analysis-digest-mwynv7.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2507 }, { "id": "e544-duncan-fewkes-reel-analysis-digest-ap471u", "title": "E544 — Duncan Fewkes reel analysis digest", "slug": "e544-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E544-DU-52fcinww.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)", "excerpt": "Source video: `../reels/E544-DU-52fcinww.mp4` (symlink to `[home-path]`) Caption: `../reels/E544-DU-52fcinww.txt`\n\nThis file aggregates every playbook chunk section that cites E544. Sections are de-duplicated by heading.\n\n- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)\n\nE527, E544, E532, E544 (DUSui7PioUD, DU-52fcinww, DUgoDHlipPu) all confirm Duncan ships into a **branded \"Holovis®\" CAVE / wide LED installation venue**. This is not lab work, this is **a live commercial installation product**. Implications for LUME:\n\n- The visuals are tuned for a wide curved LED CAVE (multi-panel) — but he is now porting to a flat 17m × 3m screen (E567 caption). LUME's 1-3 vertical monitors is a smaller close-cousin of \"flat 17m × 3m\". - Each install gets per-site calibration — he literally calls out: *\"need to rebalance threshold etc values for the actual usage distance — probably easiest to expose in settings and debug menu to allow for tweak values for each install individually\"* (E568). **LUME action**: ship a per-install settings file (motion threshold, depth-camera distance, smoothing) loaded from disk, exposable via debug menu. - The Holovis logo is itself one of the VFX targets — a \"Logo:\" preset slot on the VFX editor (we already had this in the prior playbook). New twist below.", "htmlHref": "/research/html/e544-duncan-fewkes-reel-analysis-digest-ap471u.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3063 }, { "id": "e549-duncan-fewkes-reel-analysis-digest-1enm555", "title": "E549 — Duncan Fewkes reel analysis digest", "slug": "e549-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E549-DVLnDW0Cq0b.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)", "excerpt": "Source video: `../reels/E549-DVLnDW0Cq0b.mp4` (symlink to `[home-path]`) Caption: `../reels/E549-DVLnDW0Cq0b.txt`\n\nThis file aggregates every playbook chunk section that cites E549. Sections are de-duplicated by heading.\n\n- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)\n\n- **VFX Graph Particle Strips** (= ribbon particles), used as kelp strands. Each strand has per-strip stiffness, propagating directionality down the chain. - **Per-particle physics constraints**: per-strip stiffness, motion/forces propagated parent→child along the strip. - **Lookdev gotcha** (E548): going from debug line renderer to even basic HDRP lit material with self-shadow = \"huge difference\". - **#normalizefailure** — he literally tags failures and shows them. Authenticity move worth borrowing for LUME devlog. - **Fish boids** (E557): Reynolds boids sim with audio params on cruising speed, separation. Tuned audio levels low so fish don't zip away. - **Spectrum-mapped vertical audio response** (E557, his next step): > *\"Planning another pass with spectrum levels mapping audio vertically, so leaves at the bottom react to the bass and frequencies increase up the stalk.\"* This is a concrete pattern: **map FFT bin index → vertical Y position on a strip particle**. Bass drives bottom leaves, treble drives top leaves. **LUME**: directly portable to anything tall/strip-shaped (curtain VFX, kelp, lightning). - **\"Wobbly Lads\" feedback gotcha** (E556): audio-reactive procedural creatures. *\"Making the motion of the Wobbly Lad input to fluid sim meant I had to disable the fluid sim force contribution to the motion, otherwise it would feedback and he'd go apeshit.\"* Lesson: bidirectional coupling between sim and creatures requires breaking the loop — pick one direction.\n\n**LUME relevance**: kelp/seagrass = niche, but the **strip-particle physics primitive** is broadly useful (tendrils, smoke ribbons, hair). Park the kelp aesthetic; bring forward the strip-physics capability for Wave 4-5.", "htmlHref": "/research/html/e549-duncan-fewkes-reel-analysis-digest-1enm555.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1779 }, { "id": "e557-duncan-fewkes-reel-analysis-digest-1my8lkh", "title": "E557 — Duncan Fewkes reel analysis digest", "slug": "e557-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E557-DVdnQeiCjXN.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)", "excerpt": "Source video: `../reels/E557-DVdnQeiCjXN.mp4` (symlink to `[home-path]`) Caption: `../reels/E557-DVdnQeiCjXN.txt`\n\nThis file aggregates every playbook chunk section that cites E557. Sections are de-duplicated by heading.\n\n- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)\n\n- **VFX Graph Particle Strips** (= ribbon particles), used as kelp strands. Each strand has per-strip stiffness, propagating directionality down the chain. - **Per-particle physics constraints**: per-strip stiffness, motion/forces propagated parent→child along the strip. - **Lookdev gotcha** (E548): going from debug line renderer to even basic HDRP lit material with self-shadow = \"huge difference\". - **#normalizefailure** — he literally tags failures and shows them. Authenticity move worth borrowing for LUME devlog. - **Fish boids** (E557): Reynolds boids sim with audio params on cruising speed, separation. Tuned audio levels low so fish don't zip away. - **Spectrum-mapped vertical audio response** (E557, his next step): > *\"Planning another pass with spectrum levels mapping audio vertically, so leaves at the bottom react to the bass and frequencies increase up the stalk.\"* This is a concrete pattern: **map FFT bin index → vertical Y position on a strip particle**. Bass drives bottom leaves, treble drives top leaves. **LUME**: directly portable to anything tall/strip-shaped (curtain VFX, kelp, lightning). - **\"Wobbly Lads\" feedback gotcha** (E556): audio-reactive procedural creatures. *\"Making the motion of the Wobbly Lad input to fluid sim meant I had to disable the fluid sim force contribution to the motion, otherwise it would feedback and he'd go apeshit.\"* Lesson: bidirectional coupling between sim and creatures requires breaking the loop — pick one direction.\n\n**LUME relevance**: kelp/seagrass = niche, but the **strip-particle physics primitive** is broadly useful (tendrils, smoke ribbons, hair). Park the kelp aesthetic; bring forward the strip-physics capability for Wave 4-5.", "htmlHref": "/research/html/e557-duncan-fewkes-reel-analysis-digest-1my8lkh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1779 }, { "id": "e560-duncan-fewkes-reel-analysis-digest-162v4wi", "title": "E560 — Duncan Fewkes reel analysis digest", "slug": "e560-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E560-DVlh0gSCiZ9.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)", "excerpt": "Source video: `../reels/E560-DVlh0gSCiZ9.mp4` (symlink to `[home-path]`) Caption: `../reels/E560-DVlh0gSCiZ9.txt`\n\nThis file aggregates every playbook chunk section that cites E560. Sections are de-duplicated by heading.\n\n- 20 reels ingested at `[home]/.openclaw/browser/reels-ingest/{DU,DV}*/` - Episodes covered: **E485 (Pt2 Jason Derulo World Tour), E525-E536, E543-E549, E556-E557, E560, E567-E568, E570** - 5 Gemini visual analyses: DU-52fcinww (E544 Blocky Pinscreen), DUleGWZisrH (E534 Fluid Presets), DV6A04wislr (E568 SuperHot Cubes), DUSui7PioUD (E527 Holovis branded), DUgoDHlipPu (E532 Depth Cubes vs Fluid Presets) — rest rate-limited - All on **HDRP + VFX Graph + Shader Graph** (confirmed every caption)\n\nE560 caption — found by accident, kept: > *\"Stopped Unity editor playback and the fluid sim stops updating but the buffers don't get cleared (as they exist in asset database), so the particle VFX continue to update and the particles follow the frozen sim velocity buffer paths. This creates frozen forms in the motion paths that you don't get while the sim is updating.\"*\n\nThis is **distinct from SuperHot mode**: SuperHot pauses sim time when user is still; this is **freezing the velocity field while the particles keep flowing through it**. The result is laminar streams flowing along etched-in paths. Implement as another mode on the LumeMotionGatedFluidSim controller: `FreezeVelocityField` toggle.", "htmlHref": "/research/html/e560-duncan-fewkes-reel-analysis-digest-162v4wi.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1630 }, { "id": "2026-05-03-10ny1pu", "title": "2026-05-03", "slug": "2026-05-03", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/memory/2026-05-03.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- Used the open Claude Design project for LUME hardware approval mockups: `https://claude.ai/design/p/019debf9-ec40-70ca-8d8b-eb94509e887d`. - Active visual prototype: `LUME Approval Board.html`; print/PDF version: `LUME Approval Board-print.html`. - Prototype is the symmetric dual-Arducam version: centered Orbbec Femto Mega, left/right Arducam IMX586 modules, top ZHAOCAILIN 11.3 inch 1920x440 display cradle, rear K11/GMKtec pod, cable backbone, service USB path, and open physical gates. - Corrected cloud prototype", "excerpt": "- Used the open Claude Design project for LUME hardware approval mockups: `https://claude.ai/design/p/019debf9-ec40-70ca-8d8b-eb94509e887d`. - Active visual prototype: `LUME Approval Board.html`; print/PDF version: `LUME Approval Board-print.html`. - Prototype is the symmetric dual-Arducam version: centered Orbbec Femto Mega, left/right Arducam IMX586 modules, top ZHAOCAILIN 11.3 inch 1920x440 display cradle, rear K11/GMKtec pod, cable backbone, service USB path, and open physical gates. - Corrected cloud prototype status to match real state: printer connected/not powered on, no print jobs completed. Header and footer now show `0 of 5 physical gates passed`, Print Timeline shows `Stages Done 0/11`, Queue Totals shows `Done 0 of 11`, and primary action is `Approve Next Gate`. - Important framing: the cloud board is for visual/design approval only. Physical next step remains powering the Elegoo, ASA calibration cube, then fit coupons before internals, shells, or pod prints. - VC pitch follow-up completed in `[home]/Desktop/lume-content/vc-pitch`: removed stale Femto Bolt references from `lume-internal-brief.md`, regenerated Claude-design local `v1-hardware-first.html` and `v4-traction.html` around Orbbec Femto Mega + dual Arducam IMX586 + 1920x440 bar display, re-captured `screenshots/v1.png` and `screenshots/v4.png`, appended `REPORT.md`, and committed exact scoped files as `c1630fc9`. - Instagram reference `DXyxaiXiMRt` is Duncan Fewkes `E612: \"Fluid Sim Presets Test\"`. Created original LUME-direction mockup at `[home]/Desktop/lume-commerce/viz/mockups/e612-fluid-sim-lume-mockup.html` plus screenshot `.png` and build note `[home]/Desktop/lume-commerce/docs/research/duncan-v3/E612-fluid-sim-mimic-plan.md`. Direction: dark realtime stage, readable body silhouette, fluid particles, debug HUD, preset switching. Unity already has the relevant FluidSim preset family and F1 picker plumbing. - Wrote detailed Unity runbook for the E612 direction at `[home]/Desktop/lume-commerce/viz/lume-pcloud/E612-FLUID-SIM-UNITY-IMPLEMENTATION-GUIDE.md`. It documents Mac4 setup, exact Unity menus, synthetic publishers, overlay tuning, FluidSim presets, 1920x440 crop rules, VFX Graph follow-up, recording protocol, K11 performance gates, and final approval checklist. Key approach: use existing `LumeFlowParticleOverlay` + `LumeFluidSim` first, then author `LumeFlowParticles.vfx` after visual approval.", "htmlHref": "/research/html/2026-05-03-10ny1pu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 287 }, { "id": "lume-rehearsal-bundle-hub-implementation-v49e2b", "title": "LUME Rehearsal Bundle Hub Implementation", "slug": "lume-rehearsal-bundle-hub-implementation", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/viz/lume-pcloud/Docs/LUME_REHEARSAL_BUNDLE_HUB_IMPLEMENTATION_2026-05-28.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "```text C:\\lume\\dance-sessions\\_incoming C:\\lume\\dance-sessions\\_manifests C:\\lume\\recordings\\pose-coach\\sessions C:\\lume\\data\\bodytruth_motionmix_mocopi_k11.jsonl C:\\lume\\data\\bodytruth_k11.jsonl C:\\lume\\data\\sensorlogger_k11.jsonl ```", "excerpt": "The hub is storage/indexing only. It does not send Rekordbox keys, does not send MIDI, does not restart the AirDeck bridge, and does not modify MotionMix live services.\n\nArchives are extracted from `_incoming` into `_processed/` only after SHA-256 verification against the transport manifest.\n\nNKo here means motion-language semantics first. Actual NKo-script inscriptions can be added after labels and meanings stabilize.\n\nThe request points Mac5 to the Mac4 session root, video, and labels. Recommended worker command:\n\nDEMON is treated as a future audio-generation output lane, not a body tracker and not a Rekordbox controller. The request maps reviewed motion labels such as `wave_color`, `burst_high_energy`, `weighted_slow_power_hold`, and `airdeck_platter_spin` into candidate time-varying audio-generation controls.", "htmlHref": "/research/html/lume-rehearsal-bundle-hub-implementation-v49e2b.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 655 }, { "id": "e612-fluid-sim-unity-implementation-guide-19lymfp", "title": "E612 Fluid Sim Unity Implementation Guide", "slug": "e612-fluid-sim-unity-implementation-guide", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/viz/lume-pcloud/E612-FLUID-SIM-UNITY-IMPLEMENTATION-GUIDE.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "Goal: make the LUME Unity build visually match the direction of the Duncan Fewkes `E612: \"Fluid Sim Presets Test\"` reference while staying original to LUME.", "excerpt": "Goal: make the LUME Unity build visually match the direction of the Duncan Fewkes `E612: \"Fluid Sim Presets Test\"` reference while staying original to LUME.\n\n- dark realtime room - readable body silhouette - dense but controlled particle/fluid motion - visible preset switching - small debug/test-bench HUD for build-in-public clips - clean venue mode with the HUD hidden - 1920x440 bar-display-safe composition\n\n`[home]/Desktop/lume-commerce/docs/research/duncan-v3/E612-fluid-sim-mimic-plan.md`\n\n| Piece | File | Status | |---|---|---| | Fluid sim | `Assets/Scripts/LumeFluidSim.cs` | built | | Fluid preset ScriptableObject | `Assets/Scripts/Vfx/LumeFluidSimPreset.cs` | built | | Flow particle overlay | `Assets/Scripts/LumeFlowParticleOverlay.cs` | built | | VFX runtime bridge | `Assets/Scripts/LumeVfxRuntimeBridge.cs` | built | | Runtime picker | `Assets/Scripts/Vfx/LumeVfxEditor.cs` | built | | Preset generator | `Assets/Editor/LumePresetGenerator.cs` | built | | Auto-wire menu | `Assets/Editor/LumeWaveAutoWire.cs` | built | | VFX Graph recipe | `Assets/VFX/README-LumeFlowParticles.md` | written | | Overlay material | `Assets/Materials/LumeFlowParticleOverlay.mat` | present | | Fluid compute | `Assets/Shaders/LumeFluidSim.compute` | present |\n\n- `Default` - `Default_Smooth` - `LongThrow` - `MidThrow` - `ShortThrow` - `InvertedObstacle` - `FrozenVelocityField` - `None`", "htmlHref": "/research/html/e612-fluid-sim-unity-implementation-guide-19lymfp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2273 }, { "id": "mac4-codex-handoff-2026-04-26-night-1qlj97i", "title": "Mac4 Codex Handoff — 2026-04-26 night", "slug": "mac4-codex-handoff-2026-04-26-night", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/viz/lume-pcloud/MAC4-CODEX-HANDOFF-2026-04-26-night.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "You're picking up LUME on Mac4 in steady-state product-build mode. The Saturday demo is past. The current live state is a Duncan-lite proof: real Femto raw depth + audio sidecar + shader dissolve + 26K-particle code-driven overlay + purple grid tunnel, all running together in Unity right now. See `lume-mac4-live-demo-state.md` in `[home-path]` for that snapshot.", "excerpt": "# Mac4 Codex Handoff — 2026-04-26 night ## Goal: turn the live demo into a Duncan-modes picker app\n\nYou're picking up LUME on Mac4 in steady-state product-build mode. The Saturday demo is past. The current live state is a Duncan-lite proof: real Femto raw depth + audio sidecar + shader dissolve + 26K-particle code-driven overlay + purple grid tunnel, all running together in Unity right now. See `lume-mac4-live-demo-state.md` in `[home-path]` for that snapshot.\n\nThis handoff is about the next jump: making the running application feel like the **operator console** Duncan teases in his E588 / E588+ reels — where a hidden backtick-toggled panel lets you flip through named visual modes (\"Maximalism\", \"Dissolving Clones\", \"Frozen Sim Buffers\", \"Kelp Audio Reaction\", \"Pinscreen\", \"Logo Testing\", etc.) without touching the Unity Editor. We have everything we need on disk to do this. Most of the foundation is already shipped. The work is fill-in-the-blanks plus a real UI pass.\n\nA runtime **picker** UX inside the running LUME app. Not a Unity Editor inspector list. A real polished panel that:\n\n- Lists Duncan's named visual modes by name (Maximalism, Kelp, Frozen Forms 1–9, Logo Testing 1–5, Motion Sparks 1–4, Pinscreen, Depth Spawn, Wobbly Lads, Blobby Guys, etc.). - Shows the audio-coupling family for each (4-band EQ rules, position-not-force, EQ before auto-gain — see playbook). - Lets the operator switch instantly during a live session. - Optionally auto-cycles on a BPM divisor (already wired in `LumeVfxEditor`). - Persists last selection per install (use the `LumeCalibrationPanel` JSON pattern at `Application.persistentDataPath/lume-calibration.json` — extend it or add a sibling `lume-picker.json`).", "htmlHref": "/research/html/mac4-codex-handoff-2026-04-26-night-1qlj97i.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2087 }, { "id": "opencode-training-pairing-lane-1phgd8y", "title": "OpenCode - Training Pairing Lane", "slug": "opencode-training-pairing-lane", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "MotionMix/agent-handoffs/OPENCODE-TRAINING-PAIRING.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "MotionMix now has enough runtime infrastructure that the next deep branch can start without blocking today’s AI photoshoot work. This branch is the offline training/data lane. The live system already has capture, live direction, motion-derived state, and audio-prep artifacts. What it does not yet have is a reproducible paired dataset builder that aligns real audio features with real pose/session data. Your job is to start that branch cleanly. You are not here to touch the live runtime, Live Director UI, device cont", "excerpt": "MotionMix now has enough runtime infrastructure that the next deep branch can start without blocking today’s AI photoshoot work. This branch is the offline training/data lane. The live system already has capture, live direction, motion-derived state, and audio-prep artifacts. What it does not yet have is a reproducible paired dataset builder that aligns real audio features with real pose/session data. Your job is to start that branch cleanly. You are not here to touch the live runtime, Live Director UI, device controls, Convex session logging, or transport. You are here to prepare the data substrate for later model training by building the pairing engine and dataset builder on top of real local artifacts.\n\n- `multicam-server` live behavior - Live Director UI - phone deployment - runtime device control\n\n- audio/pose pairing engine - dataset creation path - reproducible manifest builder\n\nThis should output a dataset that later model-training work can consume. Stop before invasive model training unless the dataset build is complete and clearly working.\n\n- `[home]/Desktop/MotionMix/HANDOFF-AUDIO-PREP.md` - `[home]/Desktop/MotionMix/CANONICAL-STATE-CONTRACT.md` - `[home]/Desktop/MotionMix/ARCHITECTURE.md` - `[home]/Desktop/MotionMix/AI-PHOTOSHOOT-MOTION-MUSIC-PLAN.md`", "htmlHref": "/research/html/opencode-training-pairing-lane-1phgd8y.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1077 }, { "id": "convex-production-backend-handoff-qedss", "title": "Convex Production Backend Handoff", "slug": "convex-production-backend-handoff", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/CONVEX-PRODUCTION-IMPLEMENTATION-HANDOFF.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "The goal is to add a **production memory/control plane** for the MotionMix AI photoshoot + motion-music lane on top of the existing Convex memory app.", "excerpt": "The goal is to add a **production memory/control plane** for the MotionMix AI photoshoot + motion-music lane on top of the existing Convex memory app.\n\nDo not build frontend UI in this pass. Do not re-architect MotionMix. Do not move anything back to Supabase.\n\n- AI-directed multicam photo/video shoot - pose-aware still extraction - motion-derived music/session structure\n\n- reconstruct the cut log - find hero pose windows - extract still candidates - align motion and music events - track final assets\n\n- `feedTapSessions` - `feedTapSessionItems` - `contentItems` - `contentEmbeddings` - `reactabilityScores` - `streamQueue` - `contentProjectMap` - `algorithmHealth`", "htmlHref": "/research/html/convex-production-backend-handoff-qedss.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1794 }, { "id": "equilibrium-diffusion-lim-rps-x-discrete-token-diffusion-10b1l2z", "title": "Equilibrium Diffusion: LIM-RPS x Discrete Token Diffusion", "slug": "equilibrium-diffusion-lim-rps-x-discrete-token-diffusion", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/EQUILIBRIUM-DIFFUSION-THEORY.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "**Banach Fixed-Point Theorem**: If f is a contraction mapping (Lipschitz constant L < 1), then: 1. A unique fixed point z* exists 2. The iteration z_{k+1} = f(z_k, x) converges to z* for any initial z_0 3. Convergence is exponential: ||z_k - z*|| <= L^k ||z_0 - z*||", "excerpt": "> A unified framework for motion-conditioned music generation via coupled equilibrium systems.\n\nA DEQ replaces L explicit layers with a single implicit layer defined by its fixed point:\n\n**Banach Fixed-Point Theorem**: If f is a contraction mapping (Lipschitz constant L < 1), then: 1. A unique fixed point z* exists 2. The iteration z_{k+1} = f(z_k, x) converges to z* for any initial z_0 3. Convergence is exponential: ||z_k - z*|| <= L^k ||z_0 - z*||\n\n| | LIM-RPS Fixed-Point | Diffusion Denoising | |---|---|---| | Iteration | z_{k+1} = z_k - gamma * B(z_k) + prox_pull | x_{t-1} = x_t + epsilon * s(x_t, t) + noise | | Vector field | B: CrossModalOperator (96 -> 96) | s_theta: score network | | Contraction | Spectral norm(B) <= 1 (1-Lipschitz) | Bounded Jacobian of s_theta | | Attractor | Unique z* (deterministic) | Data manifold (statistical) | | Convergence proof | Banach theorem (spectral norm < 1) | Score matching loss -> true score | | Without noise | Deterministic equilibrium | Probability flow ODE |\n\nThe operator B in LIM-RPS plays the same mathematical role as -s_theta in diffusion. Both are vector fields pushing the state toward an attractor. The spectral normalization of B is equivalent to requiring the score function to have bounded Jacobian, which is exactly the condition needed for diffusion convergence.", "htmlHref": "/research/html/equilibrium-diffusion-lim-rps-x-discrete-token-diffusion-10b1l2z.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2438 }, { "id": "lume-post-mac4-master-goal-17u10p0", "title": "LUME Post-Mac4 Master Goal", "slug": "lume-post-mac4-master-goal", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/lume-wiring/lume-post-mac4-master-goal-20260610T143753Z.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Build the full post-Mac4 LUME system as a multi-device capture, control, reconstruction, learning, and performance loop without breaking the command boundary. K11 remains the only Rekordbox/AirDeck command gate. Mac4 remains read-only for BodyTruth, ENTHEA, Unity visuals, MRT2-style audio mapping, DEMON control curves, and template output. Mac5 reconstructs and learns offline only after real synchronized evidence passes strict preflight, operator review, and explicit heavy-reconstruction allow.", "excerpt": "Build the full post-Mac4 LUME system as a multi-device capture, control, reconstruction, learning, and performance loop without breaking the command boundary. K11 remains the only Rekordbox/AirDeck command gate. Mac4 remains read-only for BodyTruth, ENTHEA, Unity visuals, MRT2-style audio mapping, DEMON control curves, and template output. Mac5 reconstructs and learns offline only after real synchronized evidence passes strict preflight, operator review, and explicit heavy-reconstruction allow.\n\nCloud VM is out of scope for this phase. The active mesh is local devices plus Tailscale.\n\nCode and contract surfaces are ready. The Mac4-first unlock is green, the post-Mac4 contract coverage audit passes, Mac5 tooling is verified, and the current refresh surface now carries Mac5 sync, strict real-bundle preflight, full-goal audit, and the operator action packet together.\n\nThe system is not complete. Current status is `waiting_for_physical_lanes`. Strict real-bundle preflight is `blocked_real_bundle_preflight`, with `heavy_reconstruction_preflight_ready=false`, because the existing bundle still contains fixture/smoke-origin evidence. No heavy reconstruction has started.\n\n| Device | Role | Required For First Real Run | Command Authority | | --- | --- | --- | --- | | K11 | Pose Coach, AirDeck/Rekordbox safety gate, command execution | Yes | Yes, only gate | | iPhone 16 Plus | MotionMix pose/camera angle | Yes | No | | iPhone 14 Pro Max | MotionMix pose/camera angle | Yes | No | | iPhone 16 Pro Max | Optional MotionMix third angle and dominance lane | Optional | No | | iPad StageView | Optional stage/memory/shot surface | Optional | No | | iPad ShootView | Optional shoot/camera direction surface | Optional | No | | Mac2 | Insta360 room-wide capture lane | Yes | No | | Mac4 | BodyTruth depth/wide, ENTHEA/Unity/MRT2/DEMON read-only output lane | Yes | No | | Mac5 | SAM3D/reconstruction/learning worker | After verified bundle | No live commands | | N'Ko/MnKO/SAN | Phrase, semantic, audio, gesture annotation and learning policy | Supporting lane | No |", "htmlHref": "/research/html/lume-post-mac4-master-goal-17u10p0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1755 }, { "id": "dataflow-3xe369", "title": "Dataflow", "slug": "dataflow", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "MotionMix/research/computational-choreography-nko-2026-05-27/02-architecture/dataflow.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "```text K11 camera -> pose landmarks / body boxes / segmentation -> AirDeck zones -> gesture candidate -> K11 command gate -> Rekordbox key ```", "excerpt": "This path can improve trust but should not become a required dependency for camera-visible gestures.\n\nThe recording path is as important as the live path. It is how the coach learns and how commands become safe.\n\nUnity can later visualize AirDeck zones and body intent, but Rekordbox command dispatch stays on K11.", "htmlHref": "/research/html/dataflow-3xe369.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 167 }, { "id": "event-taxonomy-eu8yid", "title": "Event Taxonomy", "slug": "event-taxonomy", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "MotionMix/research/computational-choreography-nko-2026-05-27/02-architecture/event-taxonomy.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "- landmark position; - wrist velocity; - body box; - segmentation coverage; - hand visibility; - frame timestamp; - source id.", "excerpt": "- landmark position; - wrist velocity; - body box; - segmentation coverage; - hand visibility; - frame timestamp; - source id.\n\n- `left_hand_raise_candidate`; - `airdeck_scratch_candidate`; - `next_track_swipe_candidate`; - `loop_pinch_candidate`; - `safe_stop_candidate`.\n\n- `left_hand_raise`; - `right_hand_raise`; - `airdeck_platter_spin`; - `airdeck_sync_hold`; - `airdeck_next_swipe`.\n\n- `d1_play_pause`; - `d2_play_pause`; - `d1_sync`; - `d2_sync`; - `d1_next_track`; - `d2_next_track`; - `safe_stop_all`.\n\n- label start; - label stop; - capture session id; - frame included; - keyframe saved; - promotion result.", "htmlHref": "/research/html/event-taxonomy-eu8yid.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 120 }, { "id": "machine-roles-1kntppy", "title": "Machine Roles", "slug": "machine-roles", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "MotionMix/research/computational-choreography-nko-2026-05-27/02-architecture/machine-roles.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "- Rekordbox foreground/focus handling. - Keyboard/MIDI command dispatch. - Pose Coach camera view. - AirDeck gesture detection. - Recording raw camera, overlay, keyframes, and training JSONL. - Storing `body_motion.sqlite3`. - Running self-play and promotion audits.", "excerpt": "- Rekordbox foreground/focus handling. - Keyboard/MIDI command dispatch. - Pose Coach camera view. - AirDeck gesture detection. - Recording raw camera, overlay, keyframes, and training JSONL. - Storing `body_motion.sqlite3`. - Running self-play and promotion audits.\n\n- Unity DYK. - Femto Mega depth/RGB. - Sony mocopi intake when sensors are on. - Local mocopi-to-Unity feed. - Optional MotionMix relay.\n\n- Session manifests. - Multi-camera data. - SensorLogger intake. - BodyTruth endpoint. - Dataset organization. - Future sensor fusion.\n\n- SensorLogger watch data. - MotionMix iPhone camera/SAN data. - Optional wrist motion and heart-rate alignment. - Additional training perspectives.\n\nThey should not directly trigger DJ commands until their data is validated through the same promotion gates.", "htmlHref": "/research/html/machine-roles-1kntppy.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 186 }, { "id": "safety-boundaries-5i5bv4", "title": "Safety Boundaries", "slug": "safety-boundaries", "kind": "architecture", "program": "Language as Infrastructure", "sourceAnchor": "MotionMix/research/computational-choreography-nko-2026-05-27/02-architecture/safety-boundaries.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "- Camera pose can trigger baseline hand raise play/pause. - Full AirDeck gestures can be observed and recorded. - Self-play can test gesture chains offline. - MotionMix can store and expose body state. - Mac4 can visualize the body and optional sensor state.", "excerpt": "- Camera pose can trigger baseline hand raise play/pause. - Full AirDeck gestures can be observed and recorded. - Self-play can test gesture chains offline. - MotionMix can store and expose body state. - Mac4 can visualize the body and optional sensor state.\n\n- Unity directly pressing Rekordbox keys. - Mocopi directly pressing Rekordbox keys. - SensorLogger directly pressing Rekordbox keys. - A newly detected gesture becoming live without proof. - Scratch/rewind/next/loop commands being live before promotion.\n\n1. physical capture exists; 2. capture gate passes; 3. self-play passes; 4. chain rehearsal passes; 5. motion matrix passes; 6. label-command pairs are canonical; 7. the promotion manifest is loaded by K11.\n\n- left hand raise -> deck 1 play/pause; - right hand raise -> deck 2 play/pause.\n\nThese can remain live because they are already proven and simple, but they should still be recorded.", "htmlHref": "/research/html/safety-boundaries-5i5bv4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 169 }, { "id": "how-seven-numbers-changed-everything-we-know-about-speech-recognition-xvrg0k", "title": "How Seven Numbers Changed Everything We Know About Speech Recognition", "slug": "how-seven-numbers-changed-everything-we-know-about-speech-recognition", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/posts/06-trajectory-bias.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "We had a working Bambara ASR system. A 46.9M-parameter Transformer CTC decoder sitting on top of frozen Whisper features. It took raw audio, ran it through Whisper's encoder to get acoustic features, then decoded those features into N'Ko characters.", "excerpt": "We had a working Bambara ASR system. A 46.9M-parameter Transformer CTC decoder sitting on top of frozen Whisper features. It took raw audio, ran it through Whisper's encoder to get acoustic features, then decoded those features into N'Ko characters.\n\nBut there was a pattern we kept noticing in the errors. The model would get the middle of words right and the beginnings wrong. It would handle sustained vowels perfectly but stumble on consonant clusters at phrase boundaries. It would decode long stretches of speech with no errors, then suddenly produce a burst of garbage at exactly the moments where a human listener would say \"oh, something changed there.\"\n\nThe model had no sense of where it was in the utterance. It processed each frame independently, using only local attention to the surrounding frames. It had no concept of \"we are at the beginning of a new phrase\" or \"the speaker is about to transition to a different topic.\" It was reading the audio like a very fast typewriter, one frame at a time, with no awareness of the larger structure.\n\nIn our motion capture work (a separate project involving dance, music, and real-time audio generation), we had developed something called anticipation geometry. The idea: you can predict what a dancer is about to do by tracking seven scalar values derived from their movement trajectory.\n\nThose seven values are: 1. **Commitment** (0-1): how locked-in the current motion path is 2. **Uncertainty** (0-1): how many possible next-states exist 3. **Transition pressure** (0-1): how close we are to a regime change 4. **Rhythmic phase** (0-2pi): where we are in the current periodic cycle 5. **Energy** (0-1): overall intensity of the signal 6. **Curvature** (0-1): how rapidly the trajectory is bending 7. **Jerk** (0-1): rate of change of curvature, the \"snap\" in the motion", "htmlHref": "/research/html/how-seven-numbers-changed-everything-we-know-about-speech-recognition-xvrg0k.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1338 }, { "id": "the-nko-paper-strategy-angle-and-outline-dqk2lt", "title": "The N'Ko Paper — Strategy, Angle, and Outline", "slug": "the-nko-paper-strategy-angle-and-outline", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/PAPER-STRATEGY.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Written 2026-06-01, after the session that ran the AGP oracle/real benchmark, the > budget two-regime proof, and launched the minimal-edit retrain. This is the paper > the evidence actually supports — not the four-paper measurement split, and not a > tone paper. It is the one that closes the loop.", "excerpt": "> Written 2026-06-01, after the session that ran the AGP oracle/real benchmark, the > budget two-regime proof, and launched the minimal-edit retrain. This is the paper > the evidence actually supports — not the four-paper measurement split, and not a > tone paper. It is the one that closes the loop.\n\n## The angle (Mohamed's own framing) \"It went beyond ASR because we're limited with data and we need to figure out how we can make more.\" That is the thesis. The paper is NOT \"we built an N'Ko ASR.\" It is:\n\n**A self-improving speech system that manufactures its own training data, governed by a single trajectory-uncertainty geometry, for a language that has no corpus to train on.**\n\nASR is the entry point. The contribution is the LOOP: decode → govern → correct → recycle-as-data → retrain. The whole point is data generation under governance.\n\n## Why this is the right paper (3 reasons) 1. **It subsumes everything we built.** ASR anchor, z_t trajectory state, AGP gate, FAC/tone, SFT recycler — they stop being 5 contributions and become 5 STAGES of one machine. The four-paper measurement split presents N'Ko as a measuring stick; this presents it as the substrate of a self-improving model. Bigger, truer, one story. 2. **The low-resource constraint is the engine, not a caveat.** High-resource: train a big LM on a giant corpus, done. N'Ko CAN'T (the data desert is real — ~500h public audio, no large toned text). So the system is FORCED to grow its own prior from its own ASR output + a small reference set + acceptance rules. The constraint is what makes the architecture necessary and novel. 3. **We have the experiments, and they're honest.** Most ran THIS session on artifacts already on disk. The killer result is a true one (below).", "htmlHref": "/research/html/the-nko-paper-strategy-angle-and-outline-dqk2lt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1267 }, { "id": "when-unicode-is-not-understanding-1hirly1", "title": "When Unicode Is Not Understanding", "slug": "when-unicode-is-not-understanding", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/blog-series/01-when-unicode-is-not-understanding.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The characters render. The cursor moves right to left. The prompt accepts the input. The model returns something confident. From the outside, the system looks as if it can read.", "excerpt": "Most people think the machine has crossed the line once the script appears on the screen.\n\nThe characters render. The cursor moves right to left. The prompt accepts the input. The model returns something confident. From the outside, the system looks as if it can read.\n\nN'Ko makes the difference visible because it is not a broken script, not an informal spelling habit, and not a niche encoding trick. It is a real writing system designed for Manding languages, standardized in Unicode from U+07C0 through U+07FF, used in books, education, religious texts, newspapers, keyboards, and online writing. If the machine fails on N'Ko, the failure is not that N'Ko is ill-formed. The failure is that the machine's world is incomplete.\n\nThat was the first experiment: look inside the model and ask whether N'Ko has a real internal life there.\n\nThe method was simple in spirit. Take a large language model. Feed it matched text in scripts the model should process. Then extract the hidden states layer by layer, the internal vectors the model builds before it ever speaks.", "htmlHref": "/research/html/when-unicode-is-not-understanding-1hirly1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1038 }, { "id": "cultural-code-comments-1ji548a", "title": "ߛߓߍ ߞߏ ߢߊ (Cultural Code Comments)", "slug": "cultural-code-comments", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-code-comments/README.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Traditional code comments explain **what** or **how**. Cultural Code Comments explain **why** — through the lens of ancestral wisdom.", "excerpt": "Traditional code comments explain **what** or **how**. Cultural Code Comments explain **why** — through the lens of ancestral wisdom.\n\nEvery programming concept has a parallel in human experience. N'Ko proverbs, distilled over generations, capture these patterns. This system bridges code and culture.\n\n| Programming Concept | N'Ko Wisdom | Proverb | |---------------------|-------------|---------| | Error handling | Rivers don't reverse | ߓߊ ߕߍ ߥߊ߫ ߞߐ ߝߍ߬ | | Collaboration | One hand can't grab flour | ߓߟߏ ߞߋߟߋ߲ ߕߍ ߓߎ߬ߙߎ ߕߊ | | Modularity | No one comes from one direction | ߡߐ߱ ߛߌ߬ ߕߍ ߓߐ߫ ߝߊ߲߬ ߞߋߟߋ߲ ߠߊ߫ | | Patience/async | Patience is wisdom | ߢߍߥߟߊ ߦߋ ߣߡߊ | | Documentation | Truth persists | ߕߌ߲ ߦߋ ߟߊ ߥߟߊ ߛߎ | | Learning/iteration | The hand of learning is response | ߖߐ ߓߟߏ ߦߋ ߖߊ߬ߓߌ | | Team architecture | One head doesn't carry the roof | ߞߎ߲ ߞߋߟߋ߲ ߕߍ ߜߊ߬ߙߊ ߕߊ |\n\n### ߛߓߍߞߏ (Foundations) Core programming principles — variables, functions, types\n\nThis adds: - **pre-commit**: Suggests wisdom for staged files - **prepare-commit-msg**: Adds wisdom template to commit messages - **commit-msg**: Optionally appends proverbs", "htmlHref": "/research/html/cultural-code-comments-1ji548a.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1959 }, { "id": "nko-unified-platform-master-integration-plan-1d91dp1", "title": "ߒߞߏ N'Ko Unified Platform — Master Integration Plan", "slug": "nko-unified-platform-master-integration-plan", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/MASTER-PLAN.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "``` ┌─────────────────────────────────────────────────────────────────┐ │ N'KO UNIFIED PLATFORM │ │ ═══════════════════ │ │ │ │ ┌──────────────────────── APPS ────────────────────────────┐ │ │ │ │ │ │ │ 📱 iOS App 🖥 macOS MenuBar 🌐 PWA/Web │ │ │ │ (Keyboard + (SpeakFlow + (Bridge + │ │ │ │ Voice + Quick Translate) Demo) │ │ │ │ Bridge) │ │ │ │ │ │ │ │ 🤖 Telegram Bot 🔌 Chrome Ext ⌨️ Raycast │ │ │ │ (Translate + (Inline Bridge) (Quick Convert) │ │ │ │ Cultural) │ │ │ └───────────────────────────┬─────────────────", "excerpt": "# ߒߞߏ N'Ko Unified Platform — Master Integration Plan ## From 13 Scattered Projects → 1 Unified System\n\n### R1: Transliteration (3 implementations → 1) | Current | Location | Lines | Action | |---------|----------|-------|--------| | Python Bridge | cross-script-bridge/core/ | ~400 | **KEEP as canonical** | | Python Translation Bridge | nko-keyboard-ai/lib/translation_bridge.py | ~200 | **DELETE** — redirect imports to core bridge | | Swift Transliterator | ios-keyboard/Sources/NKoCore/ | ~150 | **REWRITE** — port canonical Python to Swift natively |\n\n### R2: Phonetics/IPA (scattered across 13 files → 1 module) | Current | Action | |---------|--------| | Inline IPA maps in bridge.py, nko.py, arabic.py | **EXTRACT** into `core/phonetics/ipa.py` | | IPA references in 10 keyboard engines | **IMPORT** from shared phonetics module | | Tone handling in prosody_engine.py | **MERGE** into phonetics module |\n\n**Result:** `nko.phonetics` — single source of truth for IPA mappings, tone marks, diacritics.\n\n### R3: Cultural Data (3 sources → 1) | Current | Location | Action | |---------|----------|--------| | cultural_engine.py | nko-keyboard-ai | **KEEP** — richest implementation | | proverbs.json | nko-code-comments | **MERGE** into unified `data/proverbs/` | | Manding Proverbs API | 28-days-of-code | **ABSORB** — data into proverbs/, API logic into core |", "htmlHref": "/research/html/nko-unified-platform-master-integration-plan-1d91dp1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1491 }, { "id": "nko-3-3-complete-cultural-tools-tab-4nlxl4", "title": "NKO-3.3 Complete — Cultural Tools Tab", "slug": "nko-3-3-complete-cultural-tools-tab", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/NKO-3.3-COMPLETE.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "**Task:** Build cultural tools tab — proverbs browser, sound sigils player, cultural calendar, blessings, greetings, clan explorer, concepts browser **Status:** ✅ COMPLETE **Date:** 2025-07-19 **Lines of SwiftUI:** 3,874 across 9 culture-specific files", "excerpt": "**Task:** Build cultural tools tab — proverbs browser, sound sigils player, cultural calendar, blessings, greetings, clan explorer, concepts browser **Status:** ✅ COMPLETE **Date:** 2025-07-19 **Lines of SwiftUI:** 3,874 across 9 culture-specific files\n\n| File | Lines | Description | |------|-------|-------------| | **Theme.swift** | 303 | Design system — 6 script colors, 6 feature accent colors, typography tokens (nkoTitle/nkoBody/nkoCaption/serifBody/serifItalic), spacing constants, `NKoHaptics`, `MetaTag`, `CopyButton`, `nkoCard`/`nkoFeaturedCard` view modifiers | | **CultureTabView.swift** | 516 | Main hub — hero header with N'Ko calligraphy, Daily Proverb card (deterministic by day-of-year, widget-ready), 7-tool grid (3 rows × 2 + full-width sigils banner), stats sheet with dataset breakdown | | **ProverbsBrowserView.swift** | 464 | Proverbs browser — featured proverb card with copy, language filter chips, category filter chips, expandable rows showing N'Ko/Latin/Arabic/literal/meaning/context/code-patterns, search across all scripts | | **BlessingsView.swift** | 428 | Blessings & prayers — filter by BlessingCategory (6 types with icons) and LifeEvent (11 events with icons), expandable detail cards, one-tap copy on every blessing | | **GreetingsView.swift** | 499 | Manding greeting protocol — interactive protocol overview card explaining the 7-phase sequence (OPENING→RESPONSE→WELFARE→FAMILY→WORK→CLOSING→BLESSING), morning protocol demo with timeline visualization, time-of-day filter, phase filter, expandable rows with expected responses | | **ClanExplorerView.swift** | 411 | Clan/jamu explorer — hero section explaining the jamu system, filter by All/Noble/Griot, rich clan cards with N'Ko name, Latin name, praise name (jamu), totem animal, lineage badge (crown/music note), region, expanded detail with appropriate greetings (each copyable) and historical notes | | **ConceptsView.swift** | 348 | Cultural concepts — hero card with quick stats, type filter (Concept/Title/Kinship/Life Events), grouped sections when unfiltered, expandable rows with Arabic script, usage notes, semantic tags | | **CulturalCalendarView.swift** | 400 | Cultural calendar — hero card, 5-way filter (All/Fixed/Lunar/Islamic/Regional), date badge visualization (fixed dates show day/month, lunar shows moon icon), expandable detail with date notes, themed tags, associated greetings (copyable), associated proverbs | | **SigilsPlayerView.swift** | 505 | Sound sigils player — hero card with character strip, 10 sigils with N'Ko names, deterministic waveform visualization, AVFoundation tone synthesizer (plays sine wave at character's frequency for character's duration), play/stop button, frequency/duration badges, legend section |\n\n**Colors (18 named):** - Brand: `primary`, `primaryDa", "htmlHref": "/research/html/nko-3-3-complete-cultural-tools-tab-4nlxl4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 921 }, { "id": "cultural-code-comments-13z7zwh", "title": "ߛߓߍ ߞߏ ߢߊ (Cultural Code Comments)", "slug": "cultural-code-comments", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/tools/code-wisdom/README.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Traditional code comments explain **what** or **how**. Cultural Code Comments explain **why** — through the lens of ancestral wisdom.", "excerpt": "Traditional code comments explain **what** or **how**. Cultural Code Comments explain **why** — through the lens of ancestral wisdom.\n\nEvery programming concept has a parallel in human experience. N'Ko proverbs, distilled over generations, capture these patterns. This system bridges code and culture.\n\n| Programming Concept | N'Ko Wisdom | Proverb | |---------------------|-------------|---------| | Error handling | Rivers don't reverse | ߓߊ ߕߍ ߥߊ߫ ߞߐ ߝߍ߬ | | Collaboration | One hand can't grab flour | ߓߟߏ ߞߋߟߋ߲ ߕߍ ߓߎ߬ߙߎ ߕߊ | | Modularity | No one comes from one direction | ߡߐ߱ ߛߌ߬ ߕߍ ߓߐ߫ ߝߊ߲߬ ߞߋߟߋ߲ ߠߊ߫ | | Patience/async | Patience is wisdom | ߢߍߥߟߊ ߦߋ ߣߡߊ | | Documentation | Truth persists | ߕߌ߲ ߦߋ ߟߊ ߥߟߊ ߛߎ | | Learning/iteration | The hand of learning is response | ߖߐ ߓߟߏ ߦߋ ߖߊ߬ߓߌ | | Team architecture | One head doesn't carry the roof | ߞߎ߲ ߞߋߟߋ߲ ߕߍ ߜߊ߬ߙߊ ߕߊ |\n\n### ߛߓߍߞߏ (Foundations) Core programming principles — variables, functions, types\n\nThis adds: - **pre-commit**: Suggests wisdom for staged files - **prepare-commit-msg**: Adds wisdom template to commit messages - **commit-msg**: Optionally appends proverbs", "htmlHref": "/research/html/cultural-code-comments-13z7zwh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1959 }, { "id": "stage-5-rail-execution-plan-yhovc8", "title": "Stage 5: RAIL — Execution Plan", "slug": "stage-5-rail-execution-plan", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "omega-output/cc-motion-gen-20260321/05-execution-plan.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Step | Task | Machine | Est. | |------|------|---------|------| | 0.1 | Create `model/dit.py` with MotionDiT architecture (Tiny: 4 blocks/128dim, Full: 8 blocks/256dim) | Mac1 | 4h | | 0.2 | Create `model/flow_matching.py` with OT-CFM (training + Euler/midpoint sampling + CFG) | Mac1 | 4h | | 0.3 | Create `training/flow_losses.py` (flow matching loss + existing structure regularizers) | Mac1 | 2h | | 0.4 | Modify `config.py` to add FlowMatchingConfig and DiTConfig blocks | Mac1 | 1h | | 0.5 | Modify `training/tra", "excerpt": "### Phase 0: Foundation (Week 1) **Priority**: P0 | **Machine**: Mac1 (controller) **Parallel tracks**: None (setup)\n\n| Step | Task | Machine | Est. | |------|------|---------|------| | 0.1 | Create `model/dit.py` with MotionDiT architecture (Tiny: 4 blocks/128dim, Full: 8 blocks/256dim) | Mac1 | 4h | | 0.2 | Create `model/flow_matching.py` with OT-CFM (training + Euler/midpoint sampling + CFG) | Mac1 | 4h | | 0.3 | Create `training/flow_losses.py` (flow matching loss + existing structure regularizers) | Mac1 | 2h | | 0.4 | Modify `config.py` to add FlowMatchingConfig and DiTConfig blocks | Mac1 | 1h | | 0.5 | Modify `training/trainer.py` to support flow matching training loop | Mac1 | 2h | | 0.6 | Modify `inference/sampler.py` to add ODE solvers alongside DDIM | Mac1 | 2h | | 0.7 | Create `scripts/train_flow.py` entry point | Mac1 | 1h | | 0.8 | Unit tests for DiT forward pass and flow matching loss | Mac1 | 2h |\n\n**Review checkpoint (end of Week 1)**: DiT builds, flow matching loss computes, sampling produces shaped output.\n\n### Phase 1: Flow Matching Training (Weeks 2-4) **Priority**: P0 | **Machine**: Cloud GPU (training), Mac4/Mac5 (prototyping)\n\n| Step | Task | Machine | Est. | |------|------|---------|------| | 1.1 | Prepare training data: validate existing phrase bundles, compute statistics | Mac1 | 2h | | 1.2 | Train MotionDiT-Full (8 blocks) on phrase data with flow matching — initial run (10 epochs) | Cloud GPU | 8h | | 1.3 | **WEEK 2 CHECKPOINT**: Evaluate convergence. If loss not decreasing → pivot to DDIM consistency distillation | Mac1 | 1h | | 1.4 | Full training run (100 epochs) with WandB logging | Cloud GPU | 24h | | 1.5 | Compare quality: Flow 1-step vs Flow 4-step vs Flow 10-step vs DDIM-50 baseline | Mac1 | 4h | | 1.6 | Run SanityChecker + MusalityScorer on flow matching outputs vs DDIM outputs | Mac1 | 2h | | 1.7 | Select best step count for quality/speed tradeoff | Mac1 | 1h |", "htmlHref": "/research/html/stage-5-rail-execution-plan-yhovc8.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1554 }, { "id": "epoch-appchain-stacks-fork-native-rust-services-5tq0qt", "title": "EPOCH Appchain: Stacks Fork + Native Rust Services", "slug": "epoch-appchain-stacks-fork-native-rust-services", "kind": "architecture", "program": "Protocol and Compute", "sourceAnchor": "omega-output/epoch-v2-upgrade-20260320/06-appchain-architecture.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Instead of 5 external services talking to the chain via HTTP, they become native chain modules. Graph Kernel queries happen at chain speed, not network speed. N'Ko inscriptions render inside the block validator. RAG++ vector search is part of consensus.", "excerpt": "Instead of 5 external services talking to the chain via HTTP, they become native chain modules. Graph Kernel queries happen at chain speed, not network speed. N'Ko inscriptions render inside the block validator. RAG++ vector search is part of consensus.\n\n| Crate | Lines | Appchain Role | |-------|-------|--------------| | cc-rag-plus-plus | 33,274 | Native vector similarity precompile | | cc-inscription | 22,881 | Native inscription validator (the killer feature) | | cc-graph-kernel | 14,953 | Native context slicing with admissibility tokens | | cc-protocol | 7,429 | Smart contract type definitions | | cc-kernel | 4,357 | Ledger/storage layer | | cc-semantic-language | 4,000 | N'Ko text processing primitives |\n\n**Appchain spec**: 764 lines at `docs/appchain-mining-spec.md` covering mining rules, bridge contracts, economic model, security analysis.\n\n**Fork base**: Stacks `feat/app-chain-mvp` branch. Alpha quality, predates Nakamoto upgrade. Needs rebase against v3.[ip].\n\nThese run inside the block validator at Rust speed, not Clarity interpreter speed.", "htmlHref": "/research/html/epoch-appchain-stacks-fork-native-rust-services-5tq0qt.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 628 }, { "id": "code-review-agent-swarm-gnkg0w", "title": "Code Review: Agent Swarm", "slug": "code-review-agent-swarm", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/agent-swarm/CODE_REVIEW.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "- **Findings**: 66 total (4 critical, 18 high, 23 medium, 21 low) - **Cross-Cutting Patterns**: 6 identified - **Overall Health**: Functional but needs hardening before production use. Core architecture is sound. Security and input validation are the most urgent gaps.", "excerpt": "- **Findings**: 66 total (4 critical, 18 high, 23 medium, 21 low) - **Cross-Cutting Patterns**: 6 identified - **Overall Health**: Functional but needs hardening before production use. Core architecture is sound. Security and input validation are the most urgent gaps.\n\n| Pass | Critical | High | Medium | Low | Total | |------|----------|------|--------|-----|-------| | Security & Input Validation | 1 | 4 | 4 | 2 | 11 | | Concurrency & Resource Safety | 1 | 4 | 5 | 2 | 12 | | API Design & Type Safety | 1 | 6 | 4 | 2 | 13 | | Dependency Health | 0 | 2 | 5 | 8 | 15 | | Performance & Scalability | 0 | 5 | 6 | 4 | 15 | | Developer Experience | 3 | 6 | 5 | 4 | 18 |\n\n| ID | Pass | Description | File | Fix | |----|------|-------------|------|-----| | S1 | Security | `.env` committed with real Supabase service key, GitHub token, webhook secret | `.env` | Rotate all credentials immediately. Remove from git history with `git filter-repo`. | | C1 | Concurrency | Linear polling `setInterval` never stored or cleared on shutdown. Leaks timer. | `orchestrator.ts:344` | Store handle in `linearPollingHandle`, clear in `shutdown()`. | | A1 | API | `as any` cast on user-supplied status string bypasses type safety entirely. | `api-server.ts:64` | Validate against `VALID_STATUSES` set before casting. | | X2 | DX | No CI/CD workflow. No `.github/workflows/` directory. | project root | Create `ci.yml` with `bun install && bun lint && bun test`. |\n\n| ID | Pass | Description | File | |----|------|-------------|------| | S2 | Security | HMAC verification has timing side-channel via early return on missing signature. | `github.ts:74` | | S3 | Security | `runHook()` passes untrusted string to `sh -c`, enabling command injection. | `workspace-manager.ts:150` | | S4 | Security | `parseExternalId()` does not validate owner/repo, allowing path traversal in GitHub API URLs. | `github.ts:394` | | S5 | Security | YAML parser prototype pollution guards use blocklist only. | `prompt-renderer.ts:149` | | C3 | Concurrency | Background session runner has no cancellation tracking or promise handle storage. | `orchestrator.ts:266` | | C4 | Concurrency | `activeSessions` Map accessed concurrently from dispatch loop and session runner without mutex. | `orchestrator.ts:254,454` | | C5 | Concurrency | Timer in `runHook()` not cleared on all abort code paths. | `workspace-manager.ts:146` | | A3 | API | Silent `JSON.parse` failure on Claude stream output hides malformed events. | `claude.ts:403` | | A4 | API | `AgentErrorCode` enum exists but `AgentEvent.error.code` is `string?`. Enum never used. | `interface.ts:102` | | A6 | API | `Record` metadata bags everywhere. No discriminated types. | Multiple files | | A7 | API | Inconsistent null-vs-throw error contracts across source prov", "htmlHref": "/research/html/code-review-agent-swarm-gnkg0w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1787 }, { "id": "mobile-client-specification-episode-1-paqa4u", "title": "Mobile Client Specification - Episode 1", "slug": "mobile-client-specification-episode-1", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/03-guides/MOBILE_CLIENT_SPEC.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document specifies requirements for mobile sensor clients (iOS/Android) that stream data to the Episode 1 host system via WebSocket.", "excerpt": "This document specifies requirements for mobile sensor clients (iOS/Android) that stream data to the Episode 1 host system via WebSocket.\n\n| Sensor | Rate (Hz) | Priority | Notes | |--------|-----------|----------|-------| | Accelerometer | 100 | **Required** | Device acceleration (m/s²) | | Gyroscope | 100 | **Required** | Angular velocity (rad/s) | | Gravity | 100 | Recommended | Gravity vector (m/s²) | | Barometer | 10 | Optional | Atmospheric pressure (hPa) | | GPS/Location | 1 | Optional | Lat/lon/alt/speed/bearing | | Microphone RMS | 50 | Optional | Audio envelope (unitless) |\n\n**Accelerometer/Gyro:** - Use device coordinate system - X: Right - Y: Up - Z: Forward (out of screen)\n\n**Gravity:** - If available from device, send as-is - Otherwise, host will estimate via low-pass filter\n\n**Connection Flow:** 1. Client connects to WebSocket 2. Send first packet with `device_id` 3. Host acknowledges and begins logging 4. Stream packets continuously", "htmlHref": "/research/html/mobile-client-specification-episode-1-paqa4u.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1303 }, { "id": "cognitive-twin-the-reversal-1nvoaz0", "title": "Cognitive Twin — The Reversal", "slug": "cognitive-twin-the-reversal", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/dream-weaver-engine/dreams/cognitive-twin-reversal.md", "extension": "md", "score": 22, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Workspace document requiring curation.", "excerpt": "## Essence Instead of injecting context into generic models, fine-tune models that already know our patterns. Twin Alpha (Qwen3-235B MoE) trained on 38K conversation turns learns Mo's voice, decision patterns, and technical preferences. The reversal: from context-first to model-first architecture. Frontier models become escalation-only.\n\n## Context SFT training submitted to Together AI on Qwen3-235B-A22B-Instruct. 34K train + 3.8K val conversations. DPO data ready for Phase 2 (793 pairs). MiniMax M2.5 running on Vast.ai H100 as interim inference. The twin swarm concept: Alpha (coding), Beta (review), Gamma (tests/docs).\n\n## Tags fine-tuning, cognitive-twin, qwen, together-ai, sft, dpo, model-first, reversal", "htmlHref": "/research/html/cognitive-twin-the-reversal-1nvoaz0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 103 }, { "id": "system-architecture-evolution-qfd9a", "title": "System Architecture Evolution", "slug": "system-architecture-evolution", "kind": "architecture", "program": "Business Systems", "sourceAnchor": "projects/hef-evolutions/voice-to-code-speak-architecture-get-scaffold-natu/gen8_scaffold/ARCHITECTURE.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "Workspace document requiring curation.", "excerpt": "## 🎙️ Voice Interaction > \"Affirmative. I've mapped your request to a 2-tier architecture. Configuring python_api and react_frontend. Scaffold initialized. Ready for deployment.\"\n\n## Components & Rationale - **python_api**: Provides a robust, scalable entry point for business logic. - **react_frontend**: Ensures a modern, reactive user interface with component reuse.", "htmlHref": "/research/html/system-architecture-evolution-qfd9a.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 69 }, { "id": "system-architecture-1vohjxg", "title": "System Architecture", "slug": "system-architecture", "kind": "architecture", "program": "Research Backlog", "sourceAnchor": "projects/hef-evolutions/voice-to-code-speak-architecture-get-scaffold-natu/test_scaffold/ARCHITECTURE.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "```mermaid graph TD User -->|API calls| API[Python Flask API] API -->|query| DB[(PostgreSQL Database)] API -->|cache| Redis{{Redis Cache}}", "excerpt": "No public-safe excerpt was extracted yet. This item needs curation before it becomes a readable paper.", "htmlHref": "/research/html/system-architecture-1vohjxg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 31 }, { "id": "mac3-worker-config-1g17e7j", "title": "Mac3 Worker Config", "slug": "mac3-worker-config", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/mac3-worker-config/README.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "- `sea-worker.plist` — launchd plist for the main SEA scorer/worker process - `install.sh` — Deploy script to install the plist on mac3", "excerpt": "- `sea-worker.plist` — launchd plist for the main SEA scorer/worker process - `install.sh` — Deploy script to install the plist on mac3\n\n| Key | Default | Description | |-----|---------|-------------| | `SEA_NODE_ID` | `mac3` | Node identifier in SEA cluster | | `SEA_ROLE` | `scorer` | Worker role (scorer, router, health) | | `SEA_PORT` | `18080` | HTTP port for worker API |\n\n- Python 3.8.2 (system) — adequate for scoring/routing workers - 8 GB RAM — keep ML models on Mac4 (16 GB) instead - launchd auto-restarts on crash (`KeepAlive.SuccessfulExit = false`) - Logs at `[home-path]`", "htmlHref": "/research/html/mac3-worker-config-1g17e7j.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 140 }, { "id": "sea-0-5-complete-xjcv5p", "title": "SEA-0.5-COMPLETE", "slug": "sea-0-5-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-0.5-COMPLETE.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "| Skill | Channel ID | |-------|-----------| | phi:veritas | 1473385676102828246 | | phi:paradox | 1473385870815133940 | | phi:metaphysical | 1473385883767013559 | | art:creative | 1473385889223671880 | | art:convergent | 1473385894579798207 | | art:divergent | 1473385943909269708 | | art:synthesis | 1473385948376072275 | | art:snark | 1473385953157447701 | | art:movement | 1473385957255549001 | | art:dj | 1473386000645624034 | | nav:nonlinear | 1473386004864831622 | | nav:organic | 1473386009524703385 | | nav:pers", "excerpt": "## Summary Created a Discord category \"SEA Skills\" with 13 text channels in guild 1470100197941051623, one per skill entity. Wrote `[home-path]` mapping each skill (phi:veritas, phi:paradox, phi:metaphysical, art:creative, art:convergent, art:divergent, art:synthesis, art:snark, art:movement, art:dj, nav:nonlinear, nav:organic, nav:perspective) to its Discord channel ID.\n\n## Changes - File: `[home-path]` — created. Contains meta (guild, category, version) and channels map with all 13 skill->channel_id entries. - Discord: Created category `1473385615629226173` (\"SEA Skills\") and 13 text channels underneath.\n\n| Skill | Channel ID | |-------|-----------| | phi:veritas | 1473385676102828246 | | phi:paradox | 1473385870815133940 | | phi:metaphysical | 1473385883767013559 | | art:creative | 1473385889223671880 | | art:convergent | 1473385894579798207 | | art:divergent | 1473385943909269708 | | art:synthesis | 1473385948376072275 | | art:snark | 1473385953157447701 | | art:movement | 1473385957255549001 | | art:dj | 1473386000645624034 | | nav:nonlinear | 1473386004864831622 | | nav:organic | 1473386009524703385 | | nav:perspective | 1473386015048863865 |\n\n## RTD Verification - [x] Structure: `[home-path]` created, directory structure established - [x] Compilation: valid JSON, parseable - [x] Integration: channel IDs verified against Discord API, category parent_id correct - [x] Content: all 13 skills mapped, meta includes guild/category/version - [x] User Journey: channels visible in Discord under \"SEA Skills\" category, channel-map.json consumable by sea-router - [x] Deployment: committed with conventional commit", "htmlHref": "/research/html/sea-0-5-complete-xjcv5p.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 296 }, { "id": "sea-1-1-complete-12gzwiq", "title": "SEA-1.1-COMPLETE", "slug": "sea-1-1-complete", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "skill-entity-architecture/SEA-1.1-COMPLETE.md", "extension": "md", "score": 22, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "``` Chunk: Directory Creation | Status: ✅ | Evil findings: 0 | Fixes: 0 | Gate: pass Chunk: State JSON Generation | Status: ✅ | Evil findings: 0 | Fixes: 0 | Gate: pass Chunk: Activation Log Creation | Status: ✅ | Evil findings: 0 | Fixes: 0 | Gate: pass Chunk: Validation & Verification | Status: ✅ | Evil findings: 0 | Fixes: 0 | Gate: pass ```", "excerpt": "## Summary Created the skill-memory directory structure at `[home-path]` for all 13 SEA Phase 1 skill entities. Each skill has a `state.json` with seeded hot/cold topics (extracted from SKILL.md files) and an empty `activation-log.jsonl`.\n\n## Changes - Directory: `[home-path]` — created 13 skill directories - File: `[home-path]` — 13 files with schema: skill, total_activations, useful_activations, suppressed_count, hot_topics, cold_topics, context_window, confidence_calibration, last_activated - File: `[home-path]` — 13 empty log files\n\n### Skills Created | Cluster | Skills | |---------|--------| | phi (Philosophy) | phi:veritas, phi:paradox, phi:metaphysical | | art (Creative) | art:creative, art:convergent, art:divergent, art:synthesis, art:snark, art:movement, art:dj | | nav (Navigation) | nav:nonlinear, nav:organic, nav:perspective |\n\n### Topic Seeding Hot/cold topics were extracted from each skill's SKILL.md definition file: - **Hot topics** (3-5 per skill): Core concepts most likely to trigger activation - **Cold topics** (2-3 per skill): Secondary concepts for companion skill suggestions\n\n## RTD Verification - [x] Structure: all 13 directories, 13 state.json, 13 activation-log.jsonl present - [x] Compilation: all JSON validates with python3 json.load() - [x] Integration: lives in existing [home-path] alongside channel-map.json - [x] Content: all 9 required schema fields present, topics seeded from source SKILL.md files - [x] User Journey: skill-router can now read state.json to make activation decisions - [x] Deployment: committed", "htmlHref": "/research/html/sea-1-1-complete-12gzwiq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 343 }, { "id": "brews-with-beats-roadmap-er5dom", "title": "Brews With Beats — Roadmap", "slug": "brews-with-beats-roadmap", "kind": "proposal", "program": "Business Systems", "sourceAnchor": "spine/BWB/ROADMAP.md", "extension": "md", "score": 22, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Document ID:** BWB-ROAD-001 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/BWB/docs/PROJECT_PLAN.md`", "excerpt": "**Document ID:** BWB-ROAD-001 **Version:** 1.0.0 **Last Updated:** 2026-01-15 **Source:** `Desktop/BWB/docs/PROJECT_PLAN.md`\n\n| Metric | Value | |--------|-------| | Overall Completion | ~80% | | Status | DORMANT | | Blocking Dependency | Buf Barista readiness | | Last Active Development | 2025 |\n\n- [x] Project architecture design - [x] BWBCore Swift Package creation - [x] Supabase project setup - [x] Basic authentication flow - [x] Theme system (colors, typography, spacing)\n\n- [x] User model and authentication - [x] Menu item data models - [x] Order and OrderItem models - [x] Cart service implementation - [x] Supabase integration layer - [x] Logger and utilities\n\n- [x] Home view - [x] Menu browsing - [x] Cart management - [x] Checkout flow - [x] Order status tracking - [ ] HealthKit integration (dance tracking) - [ ] Push notifications", "htmlHref": "/research/html/brews-with-beats-roadmap-er5dom.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 641 }, { "id": "web-artifacts-builder-1yxuoxr", "title": "Web Artifacts Builder", "slug": "web-artifacts-builder", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anthropic-skills/skills/web-artifacts-builder/SKILL.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "To build powerful frontend claude.ai artifacts, follow these steps: 1. Initialize the frontend repo using `scripts/init-artifact.sh` 2. Develop your artifact by editing the generated code 3. Bundle all code into a single HTML file using `scripts/bundle-artifact.sh` 4. Display artifact to user 5. (Optional) Test the artifact", "excerpt": "--- name: web-artifacts-builder description: Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Use for complex artifacts requiring state management, routing, or shadcn/ui components - not for simple single-file HTML/JSX artifacts. license: Complete terms in LICENSE.txt ---\n\nTo build powerful frontend claude.ai artifacts, follow these steps: 1. Initialize the frontend repo using `scripts/init-artifact.sh` 2. Develop your artifact by editing the generated code 3. Bundle all code into a single HTML file using `scripts/bundle-artifact.sh` 4. Display artifact to user 5. (Optional) Test the artifact\n\n**Stack**: React 18 + TypeScript + Vite + Parcel (bundling) + Tailwind CSS + shadcn/ui\n\nVERY IMPORTANT: To avoid what is often referred to as \"AI slop\", avoid using excessive centered layouts, purple gradients, uniform rounded corners, and Inter font.\n\nThis creates a fully configured project with: - ✅ React + TypeScript (via Vite) - ✅ Tailwind CSS 3.4.1 with shadcn/ui theming system - ✅ Path aliases (`@/`) configured - ✅ 40+ shadcn/ui components pre-installed - ✅ All Radix UI dependencies included - ✅ Parcel configured for bundling (via .parcelrc) - ✅ Node 18+ compatibility (auto-detects and pins Vite version)", "htmlHref": "/research/html/web-artifacts-builder-1yxuoxr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 446 }, { "id": "anticipation-geometry-1vrkrg5", "title": "Anticipation Geometry", "slug": "anticipation-geometry", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anticipation-geometry/README.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "[![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE) [![Rust](https://img.shields.io/badge/Rust-1.75+-orange.svg)](https://www.rust-lang.org/) [![Python](https://img.shields.io/badge/Python-3.9+-green.svg)](https://www.python.org/)", "excerpt": "[![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE) [![Rust](https://img.shields.io/badge/Rust-1.75+-orange.svg)](https://www.rust-lang.org/) [![Python](https://img.shields.io/badge/Python-3.9+-green.svg)](https://www.python.org/)\n\nGive it a sequence of vectors, any kind, and it returns 7 scalars that tell you what the trajectory is doing: committing, wandering, about to change direction, stuck, etc. Works on motion capture data, conversation embeddings, knowledge graph paths, whatever.\n\nThe key number is **transition pressure** (`d(commitment)/dt - d(uncertainty)/dt`). When it spikes, the trajectory is about to shift. It predicts conversation convergence at 71.8% accuracy and picks valid knowledge graph paths at 81.0%, with no training at all.\n\n| Name | What it tells you | |------|------------------| | **commitment** | How locked-in the trajectory is. High = deep into a sustained phase. | | **uncertainty** | How many directions it could still go. High = lots of options open. | | **transition_pressure** | Speed of futures collapsing. Positive spike = about to change. | | **recovery_margin** | How easy to reverse course. Low = past the point of no return. | | **phase_stiffness** | How rhythmic/consistent the motion is. | | **novelty** | How different this is from recent history. | | **stability** | How predictable the local dynamics are. |\n\nThe library classifies each conversation turn into one of 10 patterns (stabilization, transition, oscillation, correction, exploration, convergence, expansion, regression, stagnation, completion) based on the scalar values. We call these \"inscriptions.\"", "htmlHref": "/research/html/anticipation-geometry-1vrkrg5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 808 }, { "id": "quick-start-guide-3829i0", "title": "Quick Start Guide", "slug": "quick-start-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/gesture_control/QUICKSTART.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**What This Tests:** - ✅ Database creation and loading - ✅ Sample recording (15 samples with variations) - ✅ Template training with cross-validation - ✅ Gesture recognition with caching - ✅ Template export/import - ✅ Automatic backups - ✅ Data integrity (checksums)", "excerpt": "**What This Tests:** - ✅ Database creation and loading - ✅ Sample recording (15 samples with variations) - ✅ Template training with cross-validation - ✅ Gesture recognition with caching - ✅ Template export/import - ✅ Automatic backups - ✅ Data integrity (checksums)\n\nInstall **Sensor Logger** app: - iOS: https://apps.apple.com/app/sensor-logger/id1531582925 - Android: https://play.google.com/store/apps/details?id=com.kelvin.sensorapp\n\nThe script will display your computer's IP address. Configure phone app with: - Protocol: WebSocket - Host: `` - Port: 8765\n\nNavigate through the menu: 1. **Recording Mode** - Capture training samples 2. **Practice Mode** - Test your gestures 3. **Review Mode** - View statistics 4. **Manage Templates** - Configure shortcuts 5. **Performance Dashboard** - Monitor metrics\n\n1. Check phone and computer on same WiFi 2. Verify IP address in phone app 3. Check firewall allows port 8765 4. Try: `telnet 8765`", "htmlHref": "/research/html/quick-start-guide-3829i0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 728 }, { "id": "phase-3-4-end-to-end-pipeline-executive-summary-pic1o1", "title": "Phase 3.4: End-to-End Pipeline - Executive Summary", "slug": "phase-3-4-end-to-end-pipeline-executive-summary", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/progress/PHASE_3_4_SUMMARY.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Status:** ✅ COMPLETE **Date:** 2025-12-08 **Duration:** ~3-4 hours **Lines of Code:** 1,882+ lines (core + tests + examples)", "excerpt": "**Status:** ✅ COMPLETE **Date:** 2025-12-08 **Duration:** ~3-4 hours **Lines of Code:** 1,882+ lines (core + tests + examples)\n\nA complete, production-ready training pipeline orchestration system for DLM coordinates, consisting of three main components:\n\n### 1. Checkpoint Manager **File:** [packages/dlm/pipeline/checkpoint_manager.py](packages/dlm/pipeline/checkpoint_manager.py) (370+ lines)\n\n- Save/load training state with full metadata - Track best checkpoints by configurable metrics - Automatic cleanup (max_checkpoints limit) - Resume training from any checkpoint - PyTorch artifact persistence\n\n### 2. Data Pipeline **File:** [packages/dlm/pipeline/data_pipeline.py](packages/dlm/pipeline/data_pipeline.py) (330+ lines)", "htmlHref": "/research/html/phase-3-4-end-to-end-pipeline-executive-summary-pic1o1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 584 }, { "id": "research-depth-reactive-interactive-visual-system-in-unity-6-on-macos-apple-silicon-1t7x4wi", "title": "Research: Depth-Reactive Interactive Visual System in Unity 6 on macOS Apple Silicon", "slug": "research-depth-reactive-interactive-visual-system-in-unity-6-on-macos-apple-silicon", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/depth-reactive-visuals-research.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date**: 2026-04-03 **Scope**: Hardware selection, SDK viability, rendering pipeline, fluid simulation, and reference implementations for building a depth-camera-driven interactive particle/fluid installation using Unity 6 on M-series Macs.", "excerpt": "# Research: Depth-Reactive Interactive Visual System in Unity 6 on macOS Apple Silicon\n\n**Date**: 2026-04-03 **Scope**: Hardware selection, SDK viability, rendering pipeline, fluid simulation, and reference implementations for building a depth-camera-driven interactive particle/fluid installation using Unity 6 on M-series Macs.\n\nBuilding a depth-reactive visual system in Unity 6 on macOS Apple Silicon is feasible but requires navigating a fragmented SDK landscape. The Orbbec Femto Bolt is the strongest hardware choice (identical ToF sensor to the discontinued Azure Kinect, macOS supported via SDK v2, $299). However, the official Unity wrapper is stale (v1.1.9, Nov 2023) and does not yet wrap SDK v2. The recommended workaround is the K4A Wrapper path or the LightBuzz third-party SDK. Unity VFX Graph works on Metal and supports millions of particles on M-series GPUs, though the Unity 6 editor still requires Rosetta. For fluid simulation, Keijiro Takahashi's StableFluids (updated for Unity 6) is the canonical starting point, and his Rsvfx project is the exact reference architecture for depth-camera-to-VFX-Graph point cloud rendering. Apple LiDAR via Record3D is a viable alternative/supplementary depth source with a proven Unity VFX Graph pipeline.\n\n### Hardware Specs - **Depth sensor**: Microsoft 1MP iToF (identical to Azure Kinect DK) - **Depth modes**: NFOV 640x576 @ 30fps (75x65 deg), WFOV 1024x1024 @ 15fps (120x120 deg), WFOV binned 512x512 @ 30fps - **RGB**: 3840x2160 @ 30fps, HDR capable (81.1dB dynamic range, vs Azure Kinect's 45.6dB) - **IMU**: 6-axis (accelerometer + gyroscope) - **Size**: 115.3 x 40.3 x 65.0mm, 348g (smaller/lighter than Azure Kinect) - **Price**: ~$299 USD - **Connection**: USB-C (power + data)\n\n**Orbbec SDK v2 (recommended)** - Open-source, actively maintained (2,513 commits on main branch) - macOS support: confirmed for \"M2 chip, OS version 13.2\" (ARM64 native) - Supports Femto Bolt with full maintenance - C/C++ API, Python wrapper, ROS1/2, K4A Wrapper - **NO Unity wrapper for SDK v2 yet** -- this is the critical gap", "htmlHref": "/research/html/research-depth-reactive-interactive-visual-system-in-unity-6-on-macos-apple-silicon-1t7x4wi.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 3387 }, { "id": "stage-3-expand-master-plan-karl-v6-session-driver-hwtbim", "title": "Stage 3: EXPAND + MASTER PLAN -- KARL V6 Session Driver", "slug": "stage-3-expand-master-plan-karl-v6-session-driver", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/karl-v6-session-driver/stage3-expand-master-plan.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**R1: Terminal Diff Fragility** - **Failure scenario:** ANSI escape codes, cursor repositioning, wrapped lines, and partial terminal renders cause the diff algorithm to produce garbage. The pane hash changes on every read (due to timestamp updates or animated spinners), defeating the \"skip unchanged\" optimization. - **Probability:** HIGH (70%). Terminal output is inherently messy. tmux capture-pane includes invisible characters. - **Impact:** HIGH. Without reliable diff, every turn fires the model with junk context", "excerpt": "**R1: Terminal Diff Fragility** - **Failure scenario:** ANSI escape codes, cursor repositioning, wrapped lines, and partial terminal renders cause the diff algorithm to produce garbage. The pane hash changes on every read (due to timestamp updates or animated spinners), defeating the \"skip unchanged\" optimization. - **Probability:** HIGH (70%). Terminal output is inherently messy. tmux capture-pane includes invisible characters. - **Impact:** HIGH. Without reliable diff, every turn fires the model with junk context, recreating V5's problems. - **Mitigation:** Multi-layer stripping: (1) `strip_ansi()` removes escape sequences via regex `\\x1b\\[[0-9;]*[a-zA-Z]`, (2) normalize whitespace, (3) hash only alpha-numeric content (ignore formatting), (4) use a \"stable hash\" that ignores timestamps matching `\\d{2}:\\d{2}:\\d{2}` pattern. - **Validation:** Test against 100 real tmux captures (save from current sessions). Hash stability rate must be >90% on unchanged content.\n\n**R2: Phase Detection False Positives** - **Failure scenario:** Phase detector sees \"running\" in a file path (`/app/running-config.ts`) and classifies as WAITING. Or sees \"error\" in a variable name and classifies as ERROR. The session stalls or takes wrong actions. - **Probability:** MEDIUM (40%). Keyword matching on raw terminal output is inherently noisy. - **Impact:** HIGH. Wrong phase = wrong action. WAITING when BUILDING means the driver waits forever. - **Mitigation:** (1) Only match keywords in the LAST 3 lines (not all 80), (2) require keyword to be the dominant signal (not embedded in longer text), (3) add a \"confidence\" score -- if multiple conflicting signals, default to BUILDING (safest), (4) timeout: any phase held for >120s without change auto-transitions to STUCK. - **Validation:** Annotate 50 real pane snapshots with correct phase. Phase detector accuracy must be >85%.\n\n**R3: Model Generates Harmful Prompts** - **Failure scenario:** The 4B model generates a prompt that causes Claude to delete files, push to wrong branches, deploy broken code, or modify production data. The validation gate (Step 5) only checks for repetition and status, not destructive commands. - **Probability:** LOW (15%). The model is trained on Mohamed's patterns, which are rarely destructive. But a confused model could generate `git push --force` or `rm -rf`. - **Impact:** CRITICAL. Data loss, broken deployments. - **Mitigation:** Add a DESTRUCTIVE_PATTERNS blocklist to the validation gate: `['rm -rf', 'git push --force', 'drop table', 'git reset --hard', 'DELETE FROM', 'kill -9']`. Any generated prompt matching these patterns is rejected outright. - **Validation:** Test with 200 generated prompts. Zero destructive prompts must pass validation.\n\n**R4: Plan Generation Quality** - **Failure scenario:** The 4", "htmlHref": "/research/html/stage-3-expand-master-plan-karl-v6-session-driver-hwtbim.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": true, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 3929 }, { "id": "stage-1-path-c-the-unified-voice-router-one-intent-classifier-for-all-devices-gzwq3e", "title": "Stage 1 Path C: The Unified Voice Router — One Intent Classifier for All Devices", "slug": "stage-1-path-c-the-unified-voice-router-one-intent-classifier-for-all-devices", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/voice-first-agent-architecture/stage1-path-c.md", "extension": "md", "score": 20, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "> Grounded in: Stage 0 finding that VoiceRouter (35 intents, iOS), FleetVoiceRouter (fleet intents, iOS), and SpeakFlow VoiceCommandService (15 commands, macOS) are three separate intent classifiers with incompatible taxonomies. Voice commands work differently depending on which device you're on.", "excerpt": "# Stage 1 Path C: The Unified Voice Router — One Intent Classifier for All Devices\n\n> Grounded in: Stage 0 finding that VoiceRouter (35 intents, iOS), FleetVoiceRouter (fleet intents, iOS), and SpeakFlow VoiceCommandService (15 commands, macOS) are three separate intent classifiers with incompatible taxonomies. Voice commands work differently depending on which device you're on.\n\nPort intent classification to the server. One classifier, shared across all clients. The iPhone, Mac, glasses, and any future device all send audio/text to the same endpoint. The server classifies the intent, resolves the target, and dispatches. Device-specific logic is limited to audio capture and playback.\n\n**3. Client Updates:** - iOS OpenClawHub: Replace VoiceRouter.classify() + FleetVoiceRouter.classify() with POST to /voice/command - SpeakFlow macOS: Replace VoiceCommandService local classification with POST - Mac Ear Daemon (Path A): Use /voice/command directly - Benefit: fix a classification bug once, all devices get the update\n\n- One intent classifier for all devices — consistent behavior everywhere - Pronoun resolution and context tracking work across device switches - New intents added once, available everywhere - Server-side classification can use more powerful models (embedding similarity, LLM fallback) - Device-agnostic: any device that can capture audio and play TTS can be a voice client", "htmlHref": "/research/html/stage-1-path-c-the-unified-voice-router-one-intent-classifier-for-all-devices-gzwq3e.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 533 }, { "id": "handguard-skill-gerrhr", "title": "HandGuard Skill", "slug": "handguard-skill", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/handguard/SKILL.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Port**: 8766 (8765 is used by Clawdbot) - **Status URL**: http://localhost:8766/status - **State**: [home-path]", "excerpt": "--- name: handguard description: Nail-biting prevention system - check status, confirm events, manage alerts homepage: https://github.com/diomandeee/comp-core user-invocable: true ---\n\n- **Port**: 8766 (8765 is used by Clawdbot) - **Status URL**: http://localhost:8766/status - **State**: [home-path]\n\nUser phrases: \"I'm biting my nails\", \"caught myself biting\", \"confirm nail bite\", \"nailbite\"\n\nThe model needs 10+ confirmed events to learn your pattern: 1. When you catch yourself biting, say \"nailbite\" or run `nailbite` 2. System records the current sensor state 3. After 10+ samples, manifold_trained becomes True 4. Then it can detect and alert before you bite!\n\n1. **Untrained** (0 samples): Uses only tension/velocity signals 2. **Training** (1-9 samples): Collecting data 3. **Trained** (10+ samples): Contact manifold active, high accuracy", "htmlHref": "/research/html/handguard-skill-gerrhr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 328 }, { "id": "sky-garden-body-first-stabilization-2026-05-05-rhbmpo", "title": "Sky Garden Body-First Stabilization - 2026-05-05", "slug": "sky-garden-body-first-stabilization-2026-05-05", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/runbooks/sky-garden-body-first-stabilization-2026-05-05.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Keep `Serenity Ethereal Sky Garden` centered on the live human body before adding more spectacle. The performer is the conductor; sky, water, glow, petals, and post effects are supporting layers only.", "excerpt": "Keep `Serenity Ethereal Sky Garden` centered on the live human body before adding more spectacle. The performer is the conductor; sky, water, glow, petals, and post effects are supporting layers only.\n\nDuring Mac4 Unity Play Mode validation, the W11 procedural sky rendered as a full-frame white oval. Disabling body glow and mirror water did not remove it; disabling `LumeSkySunsetRenderer` did. The Femto/depth feed was still live, and the performer returned once the sky layer was gated off.\n\nSecond validation showed the performer could still be buried by floating-island geometry even after sky/water/glow/post were disabled. The first safe-mode patch had not gated W11.2 scenic geometry or W11.5 decorative emitters, so a huge island layer could sit in the foreground and defeat the body-first rule.\n\n- `skyGardenBodyFirstSafeMode`: default `true` - `skyGardenEnableProceduralSky`: default `false` - `skyGardenEnableScenicGeometry`: default `false` - `skyGardenEnableNarrativeTrack`: default `false` - `skyGardenEnableMirrorWater`: default `false` - `skyGardenEnableAmbientParticles`: default `false` - `skyGardenEnableBodyGlow`: default `false` - `skyGardenEnablePainterlyPost`: default `false`\n\nWhen safe mode is on, Sky Garden uses the live depth body plus the stable dark atmospheric backdrop. The experimental W11 sky, scenic geometry, timed narrative cameras, mirror water, lotus/firefly decoration, body glow, and painterly pass stay disabled.", "htmlHref": "/research/html/sky-garden-body-first-stabilization-2026-05-05-rhbmpo.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 540 }, { "id": "e473-duncan-fewkes-reel-analysis-digest-a8wc4b", "title": "E473 — Duncan Fewkes reel analysis digest", "slug": "e473-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E473-noreel.md", "extension": "md", "score": 20, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "The prior chunk caught his recent product surface (VFX Editor, two-channel audio+motion reactivity, sunset preset, bullet-time/clones). This chunk catches the **rendering tech** under the surface:", "excerpt": "⚠ No video on disk for this reel — referenced by the playbook but not in the local ingest cache.\n\nThis file aggregates every playbook chunk section that cites E473. Sections are de-duplicated by heading.\n\nThe prior chunk caught his recent product surface (VFX Editor, two-channel audio+motion reactivity, sunset preset, bullet-time/clones). This chunk catches the **rendering tech** under the surface:\n\n1. **The product is called \"HOLOVIS\"** — that's the brand text rendered as 3D letters in nearly every install demo. It's not a placeholder. The letters are the **payload object** of his rendering: blendshape inflated by audio, reflection probe hit-target, particle attractor, light source. Treat HOLOVIS_LETTERS as a first-class object in his architecture, not chrome. 2. **Target hardware = Quadro A6000 @ 60fps** (E470 caption verbatim: *\"Target hardware is Quadro A6000 at 60 fps\"*). His laptop dev box is a 3070. This sets the LUME perf target ceiling — A6000 ≈ RTX 4080. Anything we plan that wouldn't run on a single 4080 at 60fps is over-budget for parity. 3. **The calibration grid IS the LED stage UI** — the gridded floor + walls + circular degree-marked \"calibration markers\" you see in every recent reel are actually his runtime spatial reference, used for depth-camera reprojection and multi-screen LED alignment. Not just decoration. He runs an \"LED-backed XR / CAVE-like volume\" (Gemini on E460/E466/E472). 4. **Two render-mode profiles ship together** (E473 visual analysis): `tint Lights, No Shadows` (160-170 fps, ambient/emissive only) and `Spot Lights, Shadows` (70-110 fps, cast shadows from 7x point/spot lights). Operator can A/B at runtime. **Add to LumeVfxEditor: a `LightingProfile` dropdown** with at least these two modes — fast/cheap and full/cinematic. 5. **Reflection-probe budget**: realtime reflection probe render every frame across 6 faces is a known toggle (E460 caption) — adds depth/colour but he calls it \"as an option toggled in settings.\" Same toggle slot in LUME. 6. **Depth-camera kaleidoscope** is a discrete VFX preset he calls out explicitly (E469 first introduces it, E471 adds metallic vs non-metallic, E472 stretches to full body). **Net new mode for LUME** not in the prior playbook. 7. **Marching Cubes is Keijiro's**, confirmed (E427 caption verbatim: `https://github.com/keijiro/ComputeMarchingCubes`). Source particles → MC compute shader → mesh. He runs **2 surface thresholds simultaneously** to get nested skins (inner gold, outer glass).\n\nThis is the highest-value extract from this chunk. The recent reels never showed his Inspector. Here it is:", "htmlHref": "/research/html/e473-duncan-fewkes-reel-analysis-digest-a8wc4b.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2474 }, { "id": "e479-duncan-fewkes-reel-analysis-digest-8nz9g1", "title": "E479 — Duncan Fewkes reel analysis digest", "slug": "e479-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E479-noreel.md", "extension": "md", "score": 20, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, D", "excerpt": "⚠ No video on disk for this reel — referenced by the playbook but not in the local ingest cache.\n\nThis file aggregates every playbook chunk section that cites E479. Sections are de-duplicated by heading.\n\n- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, DT6IlEfig-k, DTBUJiDCvPQ, DScEatyilnk). DSfZYMUChIi + DSZmIhOCrTv hit Gemini 429 quota exhaustion; captions on those are still detailed.\n\nThe recent playbook only exposed `Multiparticle_Spine_FX` and `slime/water/chrome` material names. E521's screen recording shows the actual UI panel cycling through every preset. Update the LUME `LumeVfxEditor.cs` slot enums to match:\n\n### `Depth:` slot (the surface visual on the human silhouette) - `GhostChromatic2` — translucent particle-filled ghost, chromatic aberration on edges - `GlassThin` — thin refractive glass sculpture - `GlassThick` — solid heavy glass form - `GlassScan1` / `GlassScan2` / `GlassScan3` — three styles of scan-line / fragmented glass - (E520 reveals) `DepthCubes` with a runtime LOD randomizer — VFX Graph mesh particles fed by live depth buffer, audio-reactive trigger script flips LOD level on beat", "htmlHref": "/research/html/e479-duncan-fewkes-reel-analysis-digest-8nz9g1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 3404 }, { "id": "e488-duncan-fewkes-reel-analysis-digest-1jubqp", "title": "E488 — Duncan Fewkes reel analysis digest", "slug": "e488-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E488-noreel.md", "extension": "md", "score": 20, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, D", "excerpt": "⚠ No video on disk for this reel — referenced by the playbook but not in the local ingest cache.\n\nThis file aggregates every playbook chunk section that cites E488. Sections are de-duplicated by heading.\n\n- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, DT6IlEfig-k, DTBUJiDCvPQ, DScEatyilnk). DSfZYMUChIi + DSZmIhOCrTv hit Gemini 429 quota exhaustion; captions on those are still detailed.\n\nDSZmIhOCrTv adds gravity + room collision to the audio-clones particles. Caption is a complete failure→fix log:\n\n> Initial test with depth buffer collision didn't work as particles cast shadows so write depth, and were self-colliding into a mess. Then test with just room collision was boring as they just dropped straight. But as soon as added some kick from the fluid sim and turbulence, was instantly fun!", "htmlHref": "/research/html/e488-duncan-fewkes-reel-analysis-digest-1jubqp.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2757 }, { "id": "e512-duncan-fewkes-reel-analysis-digest-1h4n3er", "title": "E512 — Duncan Fewkes reel analysis digest", "slug": "e512-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E512-DThrF5Miq0-.md", "extension": "md", "score": 20, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, D", "excerpt": "Source video: `../reels/E512-DThrF5Miq0-.mp4` (symlink to `[home-path]`) Caption: `../reels/E512-DThrF5Miq0-.txt`\n\nThis file aggregates every playbook chunk section that cites E512. Sections are de-duplicated by heading.\n\n- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, DT6IlEfig-k, DTBUJiDCvPQ, DScEatyilnk). DSfZYMUChIi + DSZmIhOCrTv hit Gemini 429 quota exhaustion; captions on those are still detailed.\n\nThe recent playbook only exposed `Multiparticle_Spine_FX` and `slime/water/chrome` material names. E521's screen recording shows the actual UI panel cycling through every preset. Update the LUME `LumeVfxEditor.cs` slot enums to match:\n\n### `Depth:` slot (the surface visual on the human silhouette) - `GhostChromatic2` — translucent particle-filled ghost, chromatic aberration on edges - `GlassThin` — thin refractive glass sculpture - `GlassThick` — solid heavy glass form - `GlassScan1` / `GlassScan2` / `GlassScan3` — three styles of scan-line / fragmented glass - (E520 reveals) `DepthCubes` with a runtime LOD randomizer — VFX Graph mesh particles fed by live depth buffer, audio-reactive trigger script flips LOD level on beat", "htmlHref": "/research/html/e512-duncan-fewkes-reel-analysis-digest-1h4n3er.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1529 }, { "id": "e516-duncan-fewkes-reel-analysis-digest-q5kqeq", "title": "E516 — Duncan Fewkes reel analysis digest", "slug": "e516-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E516-DTr5TQfCpG4.md", "extension": "md", "score": 20, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, D", "excerpt": "Source video: `../reels/E516-DTr5TQfCpG4.mp4` (symlink to `[home-path]`) Caption: `../reels/E516-DTr5TQfCpG4.txt`\n\nThis file aggregates every playbook chunk section that cites E516. Sections are de-duplicated by heading.\n\n- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, DT6IlEfig-k, DTBUJiDCvPQ, DScEatyilnk). DSfZYMUChIi + DSZmIhOCrTv hit Gemini 429 quota exhaustion; captions on those are still detailed.\n\nThe recent playbook only exposed `Multiparticle_Spine_FX` and `slime/water/chrome` material names. E521's screen recording shows the actual UI panel cycling through every preset. Update the LUME `LumeVfxEditor.cs` slot enums to match:\n\n### `Depth:` slot (the surface visual on the human silhouette) - `GhostChromatic2` — translucent particle-filled ghost, chromatic aberration on edges - `GlassThin` — thin refractive glass sculpture - `GlassThick` — solid heavy glass form - `GlassScan1` / `GlassScan2` / `GlassScan3` — three styles of scan-line / fragmented glass - (E520 reveals) `DepthCubes` with a runtime LOD randomizer — VFX Graph mesh particles fed by live depth buffer, audio-reactive trigger script flips LOD level on beat", "htmlHref": "/research/html/e516-duncan-fewkes-reel-analysis-digest-q5kqeq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1912 }, { "id": "orbbec-femto-mega-jetson-agx-orin-64gb-build-rehearsal-1f4qtdh", "title": "Orbbec Femto Mega — Jetson AGX Orin 64GB Build Rehearsal", "slug": "orbbec-femto-mega-jetson-agx-orin-64gb-build-rehearsal", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/scripts/bringup/ORBBEC_BUILD_NOTES.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "No container runtime on Mac1: `docker`, `colima`, `podman`, `lima` all absent, and `/Applications` has no Docker/OrbStack. Per the operating contract, no host install attempted. A cross-arch rehearsal is not possible on this machine without first installing Docker Desktop or Colima + qemu-user-static.", "excerpt": "Target: Ubuntu 22.04 aarch64, JetPack 6, native build on device. Rehearsal host: Mac1 (Apple Silicon). Date: 2026-04-21.\n\nNo container runtime on Mac1: `docker`, `colima`, `podman`, `lima` all absent, and `/Applications` has no Docker/OrbStack. Per the operating contract, no host install attempted. A cross-arch rehearsal is not possible on this machine without first installing Docker Desktop or Colima + qemu-user-static.\n\nMitigation: sources audited directly from the Orbbec GitHub repos. The authoritative dependency list below is lifted verbatim from Orbbec's own `scripts/docker/aarch64.dockerfile` at tag `v2.7.6`, so the Jetson bootstrap is not guesswork.\n\nCMake: JetPack 6 apt cmake is 3.22 which meets the >=3.15 floor, but Orbbec's own image installs Kitware 3.30 to be safe. If `cmake --version` < 3.25, pull the aarch64 tarball: `https://github.com/Kitware/CMake/releases/download/v3.30.0/cmake-3.30.0-linux-aarch64.tar.gz`.\n\nNote: `libudev-dev` is not in the upstream Dockerfile (it's pulled in transitively by `libusb-1.0-0-dev`) but keep it explicit per spec.", "htmlHref": "/research/html/orbbec-femto-mega-jetson-agx-orin-64gb-build-rehearsal-1f4qtdh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 578 }, { "id": "nko-research-blog-6dsirs", "title": "N'Ko Research Blog", "slug": "nko-research-blog", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/README.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| # | Title | File | Words | |---|-------|------|-------| | 1 | The Script That Machines Can't Read | `posts/01-the-script-machines-cant-read.md` | ~7,000 | | 2 | Technical Deep-Dive | `posts/02-technical-deep-dive.md` | ~3,500 | | 3 | Building the First N'Ko ASR Pipeline | `posts/03-asr-pipeline-story.md` | ~2,900 | | 4 | When AI Can't See Your Language | `posts/04-when-ai-cant-see-your-language.md` | ~1,800 |", "excerpt": "| # | Title | File | Words | |---|-------|------|-------| | 1 | The Script That Machines Can't Read | `posts/01-the-script-machines-cant-read.md` | ~7,000 | | 2 | Technical Deep-Dive | `posts/02-technical-deep-dive.md` | ~3,500 | | 3 | Building the First N'Ko ASR Pipeline | `posts/03-asr-pipeline-story.md` | ~2,900 | | 4 | When AI Can't See Your Language | `posts/04-when-ai-cant-see-your-language.md` | ~1,800 |\n\n| Experiment | Title | File | |-----------|-------|------| | A | Does Every AI Have the Same Blind Spot? | `experiments/experiment-a-*.md` | | B | Does Script Design Affect How Machines Hear? | `experiments/experiment-b-*.md` | | C | What If Your AI Twin Thought in Your Mother Tongue? | `experiments/experiment-c-*.md` | | D | Can 10 Characters Encode a Lifetime of Conversation? | `experiments/experiment-d-*.md` | | E | Putting Knowledge On-Chain | `experiments/experiment-e-*.md` |", "htmlHref": "/research/html/nko-research-blog-6dsirs.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 190 }, { "id": "paper-4-research-closeout-2026-05-03-1503kf3", "title": "Paper 4 Research Closeout - 2026-05-03", "slug": "paper-4-research-closeout-2026-05-03", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/handoffs/paper4-research-closeout-2026-05-03.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Paid Vast training is paused indefinitely. The remaining Vast instance was destroyed on 2026-05-03 to stop storage billing. `vastai show instances` was empty immediately after destroying instance `35911134`.", "excerpt": "Paid Vast training is paused indefinitely. The remaining Vast instance was destroyed on 2026-05-03 to stop storage billing. `vastai show instances` was empty immediately after destroying instance `35911134`.\n\nThe recurring heartbeat monitor `monitor-nko-anchor-audit` was also deleted because the active remote audit no longer exists.\n\n- Path: `[home]/Desktop/nko-brain-scanner/local_results_cache/paper4_reproduction_35205256/results.json` - Script: `nko` - Mode: `trajectory` - TAR: `false` - TTT: `false` - LR: `0.0003` - Batch size: `32` - Dropout: `0.1` - Seed: `42` - Split: `232476 / 29060 / 29060` - Best validation loss: `0.6358872798606507` - Epochs trained: `47` - Test CER: `0.2057`\n\nThis is the only locally retained result that directly supports the archived `20.57%` N'Ko trajectory anchor.\n\nThe April 22 safe matrix is preserved locally, but it is not a strict validation of the 20.57 anchor because it used `lr=0.0001`, not `lr=0.0003`.", "htmlHref": "/research/html/paper-4-research-closeout-2026-05-03-1503kf3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 573 }, { "id": "project-charter-1pnsxgo", "title": "Project Charter", "slug": "project-charter", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/pipeline/scripts/PROJECT_CHARTER.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. Purpose 1.1 Statement 1.1.1 Must provide a local, script-driven pipeline that, given one or more YouTube video URLs, downloads video data, extracts frames, applies Gemini OCR to detect N'Ko text, optionally generates up to five world variants per detection, and writes a structured JSON report; when Supabase credentials are provided and `--store-supabase` is used, the same results are written to Supabase. 1.1.2 Falsifiability: If a run with valid inputs does not produce the JSON report or expected Supabase writes", "excerpt": "1. Purpose 1.1 Statement 1.1.1 Must provide a local, script-driven pipeline that, given one or more YouTube video URLs, downloads video data, extracts frames, applies Gemini OCR to detect N'Ko text, optionally generates up to five world variants per detection, and writes a structured JSON report; when Supabase credentials are provided and `--store-supabase` is used, the same results are written to Supabase. 1.1.2 Falsifiability: If a run with valid inputs does not produce the JSON report or expected Supabase writes, the purpose is not met.\n\n2. Non-goals 2.1 Must not provide a hosted web service or end-user UI. 2.1.1 Trace: README.md describes a local, script-driven pipeline. 2.2 Must not train or fine-tune ML models. 2.2.1 Trace: README.md describes using the Gemini API for OCR and generation. 2.3 Must not guarantee availability of YouTube content or bypass access restrictions. 2.3.1 Trace: README.md troubleshooting notes on 403 and IP blocking.\n\n3. Success Criteria 3.1 A run of `nko_analyzer.py --limit 1` with valid `GEMINI_API_KEY` writes a JSON file containing top-level keys `summary` and `results`. 3.1.1 Validation: Inspect output file at the configured path. 3.2 A run with `--store-supabase` and a valid service role key inserts records without RLS policy errors. 3.2.1 Validation: Supabase insert logs show success and no RLS errors. 3.3 A run with `--skip-worlds` writes results that omit world variants. 3.3.1 Validation: Output lacks world variant entries.\n\n4. Direction Constraints 4.1 Must remain compatible with Gemini-based OCR usage as described in README.md. 4.2 Must preserve the JSON output schema described in README.md unless a new schema version is documented. 4.3 Should keep local, script-driven execution without requiring a persistent server. 4.4 Should preserve HLS/m3u8 download preference in download scripts to mitigate 403 errors.\n\n6. Traceability 6.1 Source signals: README.md, existing scripts in this directory.", "htmlHref": "/research/html/project-charter-1pnsxgo.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 312 }, { "id": "bridge-telegram-bot-aw7py6", "title": "ߒߞߏ Bridge — Telegram Bot", "slug": "bridge-telegram-bot", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/bots/telegram/README.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Auto-transliterate** — Send any text, get all 3 scripts instantly - **Script-specific commands** — `/nko`, `/latin`, `/arabic` for targeted conversion - **IPA pronunciation** — `/ipa` with per-character guide for N'Ko input - **Cultural proverbs** — `/proverb` returns a random N'Ko proverb with translation - **Morphological analysis** — `/analyze` decomposes words into roots + affixes - **Inline mode** — Type `@nko_bridge_bot text` in any chat to get transliterations", "excerpt": "A Telegram bot for real-time N'Ko ↔ Latin ↔ Arabic transliteration, powered by the `nko` Python package.\n\n- **Auto-transliterate** — Send any text, get all 3 scripts instantly - **Script-specific commands** — `/nko`, `/latin`, `/arabic` for targeted conversion - **IPA pronunciation** — `/ipa` with per-character guide for N'Ko input - **Cultural proverbs** — `/proverb` returns a random N'Ko proverb with translation - **Morphological analysis** — `/analyze` decomposes words into roots + affixes - **Inline mode** — Type `@nko_bridge_bot text` in any chat to get transliterations\n\n1. Message [@BotFather](https://t.me/BotFather) on Telegram 2. Send `/newbot` 3. Choose a name (e.g., \"ߒߞߏ Bridge\") 4. Choose a username (e.g., `nko_bridge_bot`) 5. Copy the **bot token**\n\n| Command | Description | Example | |---------|-------------|---------| | `/start` | Welcome message | `/start` | | `/help` | List all commands | `/help` | | `/transliterate ` | All 3 scripts + IPA | `/transliterate salam` | | `/nko ` | Convert to N'Ko | `/nko hello` | | `/latin ` | Convert to Latin | `/latin ߒߞߏ` | | `/arabic ` | Convert to Arabic | `/arabic salam` | | `/ipa ` | IPA pronunciation | `/ipa ߒߞߏ` | | `/proverb` | Random proverb | `/proverb` | | `/analyze ` | Morphological analysis | `/analyze mogolu` |\n\nJust send any text directly to the bot — it auto-detects the script and transliterates to all three.", "htmlHref": "/research/html/bridge-telegram-bot-aw7py6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 443 }, { "id": "motion-controlled-dj-system-implementation-complete-1f991dd", "title": "Motion-Controlled DJ System - Implementation Complete", "slug": "motion-controlled-dj-system-implementation-complete", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "projects/Documentation/_archive/2024-12/historical-plans/MOTION_DJ_CONTROL_IMPLEMENTATION.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "I've successfully implemented a complete motion-controlled DJ system that allows you to control Serato DJ using Apple Watch gestures detected from the Motion web app.", "excerpt": "I've successfully implemented a complete motion-controlled DJ system that allows you to control Serato DJ using Apple Watch gestures detected from the Motion web app.\n\n**`gesture_library.py`** - Gesture pattern definitions - 12+ gesture types (flick, scratch, shake, circular, etc.) - Pattern matching algorithms - Configurable thresholds - Confidence scoring (0.0-1.0)\n\n**`gesture_detector.py`** - Real-time gesture detection engine - Sliding window analysis (100ms windows with 50ms overlap) - Feature extraction from IMU data: - Acceleration: magnitude, direction, velocity - Rotation: rate, total rotation, direction changes - Patterns: circularity, spike ratio, tilt angle - Debouncing (300ms cooldown between gestures) - <50ms target latency\n\n**`motion_dj_bridge.py`** - WebSocket client & bridge service - Connects to Motion app WebSocket - Filters data by device role (left/right) - Sends commands to SeratoBridge - Async/await architecture - Auto-reconnect on disconnect - Metrics tracking\n\n**`config.yaml`** - Complete configuration - 12 gesture definitions with tunable thresholds - Motion app connection settings - SeratoBridge integration settings - Logging and performance options", "htmlHref": "/research/html/motion-controlled-dj-system-implementation-complete-1f991dd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1475 }, { "id": "session-summary-dj-agent-dell-training-implementation-12qhw5n", "title": "Session Summary: DJ Agent + DELL Training Implementation", "slug": "session-summary-dj-agent-dell-training-implementation", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/_archive/2024-12/old-status-files/MERGED_SESSION_SUMMARY_DJ_AGENT.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Files Created**: - `training/trainers/train_dell.py` - `training/trainers/train_dell_production.py` - `training/dataloaders/sessions.py` - `training/dataloaders/sensor_processor.py` - `training/dataloaders/dell_dataset.py` - `training/losses/dell_losses.py` - `training/evaluation/dell_metrics.py` - `training/evaluation/evaluate_dell.py` - `training/evaluation/training_monitor.py` - `training/evaluation/dell_benchmark.py` - `configs/dell_training.yaml`", "excerpt": "# Session Summary: DJ Agent + DELL Training Implementation **Date**: November 4, 2025\n\n### 1. DELL Training Pipeline (Complete) ✅ Implemented full DELL training infrastructure ✅ Created production-grade training script with curriculum ✅ Added comprehensive evaluation metrics (phase cRMSE, residuals, benchmarks) ✅ Fixed critical spectral normalization bug ✅ Achieved 651.8 fps inference speed ✅ Trained for 30 epochs with 5x learning rate improvement\n\n**Files Created**: - `training/trainers/train_dell.py` - `training/trainers/train_dell_production.py` - `training/dataloaders/sessions.py` - `training/dataloaders/sensor_processor.py` - `training/dataloaders/dell_dataset.py` - `training/losses/dell_losses.py` - `training/evaluation/dell_metrics.py` - `training/evaluation/evaluate_dell.py` - `training/evaluation/training_monitor.py` - `training/evaluation/dell_benchmark.py` - `configs/dell_training.yaml`\n\n### 2. DJ Agent System (Complete) ✅ Implemented complete motion-driven auto-DJ system ✅ Created tiered action space (6 tiers, 50+ actions) ✅ Built beat-quantized scheduler with safety masks ✅ Integrated MIDI/keyboard bridge for Serato ✅ Added reflex + planner policies ✅ Wired into Studio runtime engine ✅ Created training and evaluation pipeline ✅ Documented setup and usage\n\n**Files Created**: - `computational-studio/studio/dj_agent/__init__.py` - `computational-studio/studio/dj_agent/action_space.py` - `computational-studio/studio/dj_agent/scheduler.py` - `computational-studio/studio/dj_agent/state_shadow.py` - `computational-studio/studio/dj_agent/serato_bridge.py` - `computational-studio/studio/dj_agent/policy_reflex.py` - `computational-studio/studio/dj_agent/policy_planner.py` - `computational-studio/studio/dj_agent/rewards.py` - `computational-studio/studio/dj_agent/README.md` - `computational-studio/studio/configs/dj.yaml` - `training/dataloaders/dj_actions.py` - `training/trainers/train_dj_planner.py` - `training/evaluation/eval_dj_agent.py` - `docs/guides/SERATO_SETUP.md`", "htmlHref": "/research/html/session-summary-dj-agent-dell-training-implementation-12qhw5n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 750 }, { "id": "how-to-run-the-voice-control-system-1cdir8o", "title": "How to Run the Voice Control System", "slug": "how-to-run-the-voice-control-system", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "projects/Documentation/02-projects/dj-agent/studio/HOW_TO_RUN.md", "extension": "md", "score": 20, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "```bash # Make sure you're in the project root (studio/) cd \"[home]/Desktop/Computational Choreography/computational-studio/studio\"", "excerpt": "### Basic Commands - `\"play left\"` - Play left deck - `\"pause right\"` - Pause right deck - `\"cue 1\"` - Jump to cue point 1 - `\"censor left\"` - Apply censor effect\n\n### Higher-Order Commands - `\"play next\"` - Load and play next track - `\"continuous mode\"` - Enable auto-play mode - `\"transition left\"` - Smooth transition to next track\n\n### New Expressive Commands (with Intent Processor) - `\"loop the vocal and fade it out slowly\"` - Complex loop with fade - `\"give me a long buildup\"` - Transition with buildup - `\"play something funky\"` - Semantic search\n\n### Semantic Search (with Library Indexer) - `\"play some 90s hip hop\"` - Find and play matching tracks - `\"find something chill\"` - Search by vibe - `\"search for house music\"` - Genre-based search\n\n**Microphone Access:** - System Settings → Privacy & Security → Microphone - Enable access for Terminal (or your Python interpreter)", "htmlHref": "/research/html/how-to-run-the-voice-control-system-1cdir8o.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 683 }, { "id": "reputation-market-mechanics-74sr52", "title": "Reputation Market Mechanics", "slug": "reputation-market-mechanics", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "agent-reputation/docs/REPUTATION_MARKET_MECHANICS.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Unlike traditional reputation systems where scores are assigned by a central authority, this system treats **reputation as a market-priced asset**.", "excerpt": "Unlike traditional reputation systems where scores are assigned by a central authority, this system treats **reputation as a market-priced asset**.\n\n**Key insight:** Market prices aggregate information from all participants, making them more accurate than any single rater.\n\n| Field | Type | Description | |-------|------|-------------| | `domainScores` | Map | Per-domain competence (0-1) | | `portfolio` | Portfolio | Balance, positions, staked credits | | `predictionAccuracy` | float | How well they predict others | | `tradingHistory` | Trade[] | Historical transactions |\n\n**Matching rules:** 1. Buy order matches if `buyPrice >= lowestAsk` 2. Execution price = existing order's price (price-time priority) 3. Partial fills allowed\n\n**Example:** - Total pool: 120 credits - Success pool: 90 credits - Your bet: 50 on SUCCESS - Outcome: SUCCESS - **Payout:** (50/90) × 120 = 66.67 credits - **Profit:** 66.67 - 50 = +16.67 credits", "htmlHref": "/research/html/reputation-market-mechanics-74sr52.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1402 }, { "id": "test-scenarios-for-agent-reputation-system-1qyhi9w", "title": "Test Scenarios for Agent Reputation System", "slug": "test-scenarios-for-agent-reputation-system", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "agent-reputation/docs/TEST_SCENARIOS.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "```python # Scenario 1.1: Register new agent def test_register_agent(): marketplace = ReputationMarketplace() agent = marketplace.get_or_create_manager(\"agent_001\", initial_rep=100.0)", "excerpt": "| Category | Scenarios | Priority | |----------|-----------|----------| | **Registration** | 1.1, 1.2 | High | | **Market Creation** | 2.1, 2.2 | High | | **Staking** | 3.1, 3.2, 3.3 | High | | **Resolution** | 4.1, 4.2, 4.3 | High | | **Cascades** | 5.1, 5.2, 5.3 | Medium | | **Trajectories** | 6.1, 6.2, 6.3 | Medium | | **Routing** | 7.1, 7.2, 7.3 | Medium | | **Security** | 8.1, 8.2, 8.3 | High | | **Lineage** | 9.1, 9.2, 9.3 | Medium | | **Performance** | 10.1, 10.2, 10.3 | Low |", "htmlHref": "/research/html/test-scenarios-for-agent-reputation-system-1qyhi9w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1458 }, { "id": "executing-plans-nqakwh", "title": "Executing Plans", "slug": "executing-plans", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "anthropic-skills/claude-superpowers/skills/executing-plans/SKILL.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "For each task: 1. Mark as in_progress 2. Follow each step exactly (plan has bite-sized steps) 3. Run verifications as specified 4. Mark as completed", "excerpt": "--- name: executing-plans description: Use when you have a written implementation plan to execute in a separate session with review checkpoints ---\n\nLoad plan, review critically, execute tasks in batches, report for review between batches.\n\n**Announce at start:** \"I'm using the executing-plans skill to implement this plan.\"\n\n### Step 1: Load and Review Plan 1. Read plan file 2. Review critically - identify any questions or concerns about the plan 3. If concerns: Raise them with your human partner before starting 4. If no concerns: Create TodoWrite and proceed\n\nFor each task: 1. Mark as in_progress 2. Follow each step exactly (plan has bite-sized steps) 3. Run verifications as specified 4. Mark as completed", "htmlHref": "/research/html/executing-plans-nqakwh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 335 }, { "id": "requirements-for-outputs-50xsqw", "title": "Requirements for Outputs", "slug": "requirements-for-outputs", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "anthropic-skills/skills/xlsx/SKILL.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "A user may ask you to create, edit, or analyze the contents of an .xlsx file. You have different tools and workflows available for different tasks.", "excerpt": "--- name: xlsx description: \"Comprehensive spreadsheet creation, editing, and analysis with support for formulas, formatting, data analysis, and visualization. When Claude needs to work with spreadsheets (.xlsx, .xlsm, .csv, .tsv, etc) for: (1) Creating new spreadsheets with formulas and formatting, (2) Reading or analyzing data, (3) Modify existing spreadsheets while preserving formulas, (4) Data analysis and visualization in spreadsheets, or (5) Recalculating formulas\" license: Proprietary. LICENSE.txt has complete terms ---\n\n### Zero Formula Errors - Every Excel model MUST be delivered with ZERO formula errors (#REF!, #DIV/0!, #VALUE!, #N/A, #NAME?)\n\n### Preserve Existing Templates (when updating templates) - Study and EXACTLY match existing format, style, and conventions when modifying files - Never impose standardized formatting on files with established patterns - Existing template conventions ALWAYS override these guidelines\n\n### Color Coding Standards Unless otherwise stated by the user or existing template\n\n#### Industry-Standard Color Conventions - **Blue text (RGB: 0,0,255)**: Hardcoded inputs, and numbers users will change for scenarios - **Black text (RGB: 0,0,0)**: ALL formulas and calculations - **Green text (RGB: 0,128,0)**: Links pulling from other worksheets within same workbook - **Red text (RGB: 255,0,0)**: External links to other files - **Yellow background (RGB: 255,255,0)**: Key assumptions needing attention or cells that need to be updated", "htmlHref": "/research/html/requirements-for-outputs-50xsqw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1481 }, { "id": "cognitive-metrics-specification-1dxdcaj", "title": "Cognitive Metrics Specification", "slug": "cognitive-metrics-specification", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "cognitive-hire/docs/metrics-spec.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "```python def divergence_rate(embeddings: list[np.ndarray], window: int = 5) -> float: \"\"\" Compute average cosine distance between consecutive prompt embeddings over a sliding window.", "excerpt": "Technical definitions for extracting cognitive analytics from AI interaction data.\n\n### Primary (Mohamed - North Star) - `claude_prompts` table in Supabase (112K+ turns) - `memory_turns` table (332K rows, 768-dim embeddings via text-embedding-3-small) - prompt-logger JSONL archives - RAG++ vector search for semantic clustering\n\n### Secondary (Future Users) - ChatGPT export (JSON: `conversations[].mapping[].message`) - Claude.ai export (when available) - Gemini export (JSON format TBD) - Any OpenAI-compatible API logs\n\n**Definition**: Semantic distance between consecutive prompts within and across sessions.\n\n**Visualization**: Line chart over time. Color gradient from blue (focused) to red (divergent). Overlay session boundaries.", "htmlHref": "/research/html/cognitive-metrics-specification-1dxdcaj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1061 }, { "id": "echeloncapture-integration-with-handguard-1kmk8k4", "title": "EchelonCapture Integration with HandGuard", "slug": "echeloncapture-integration-with-handguard", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/apps/ios/cc-handguard/ECHELON_INTEGRATION.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "HandGuard and EchelonCapture can now **share the same latent stream** without redundant sensor uploads. Both apps receive the same `z(t)` latent state from CC-MCS and apply different policies.", "excerpt": "HandGuard and EchelonCapture can now **share the same latent stream** without redundant sensor uploads. Both apps receive the same `z(t)` latent state from CC-MCS and apply different policies.\n\n**Already configured** in [CCConfig.swift](cc-handguard/Services/CloudBridge/CCConfig.swift):\n\nBoth `CCBridgeManager` (upload) and `CCLatentSubscriber` (receive) use this shared device_id.\n\nTo enable EchelonCapture to receive the same latent stream as HandGuard, configure it to subscribe to the same device_id.\n\n#### Location Find the latent stream subscription code in EchelonCapture. This is likely in: - `latent_subscriber.py` (Python) - `LatentStreamManager.swift` (Swift) - Or equivalent WebSocket connection code", "htmlHref": "/research/html/echeloncapture-integration-with-handguard-1kmk8k4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1014 }, { "id": "orb-2-3-grafana-dashboard-74pvsv", "title": "ORB-2.3: Grafana Dashboard", "slug": "orb-2-3-grafana-dashboard", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/trajectory/trajectory-orbit/ORB-2.3-COMPLETE.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| # | Panel | Type | Metrics used | |---|-------|------|-------------| | 1 | Project Count by Status | Pie chart | `orbit_project_count` | | 2 | Active Sessions Over Time | Time series | `orbit_active_sessions`, `orbit_websocket_connections` | | 3 | API Request Rate | Stacked bar | `rate(orbit_api_requests_total[5m])` by method | | 4 | API Requests by Path (Top 10) | Bar gauge | `topk(10, increase(orbit_api_requests_total[1h]))` by path | | 5 | Query Latency (p50/p95/p99) | Time series | `histogram_quantile` on `or", "excerpt": "| # | Panel | Type | Metrics used | |---|-------|------|-------------| | 1 | Project Count by Status | Pie chart | `orbit_project_count` | | 2 | Active Sessions Over Time | Time series | `orbit_active_sessions`, `orbit_websocket_connections` | | 3 | API Request Rate | Stacked bar | `rate(orbit_api_requests_total[5m])` by method | | 4 | API Requests by Path (Top 10) | Bar gauge | `topk(10, increase(orbit_api_requests_total[1h]))` by path | | 5 | Query Latency (p50/p95/p99) | Time series | `histogram_quantile` on `orbit_query_latency_seconds_bucket` | | 6 | Orbit Overview | Stat panel | All four core metrics at a glance |\n\n### Dashboard metadata - UID: `orbit-server-dashboard` - Tags: `orbit`, `trajectory`, `observability` - Schema version: 39 - Datasource variable: `${DS_PROMETHEUS}` (auto-selects Prometheus) - Default time range: last 6 hours\n\n### Validation - Valid JSON (verified with `json.load`) - 6 panels, all referencing `orbit_*` metrics - Datasource templated for portability", "htmlHref": "/research/html/orb-2-3-grafana-dashboard-74pvsv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 193 }, { "id": "analysis-module-enhancements-1ovlcb", "title": "Analysis Module Enhancements", "slug": "analysis-module-enhancements", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/cc-studio/docs/dj_agent/voice_control/enhancements.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. **Cache Invalidation**: Only re-analyzes if file modified 2. **Memory + Disk Cache**: Two-tier caching system 3. **Progress Reporting**: Better user feedback during analysis 4. **Batch Processing**: Efficient batch analysis support", "excerpt": "### 1. **Key Detection** - **Implemented**: Full key detection using Krumhansl-Schmuckler algorithm - **Output**: Camelot notation (e.g., \"8A\", \"5B\") with confidence score - **Method**: Uses chroma features from librosa to match against key profiles - **Benefits**: Enables harmonic mixing recommendations\n\n### 2. **Advanced Section Detection** - **Verse/Chorus Detection**: Identifies verse and chorus sections using energy and harmonic similarity - **Improved Breakdown Detection**: Better detection of low-energy breakdown sections - **Section Merging**: Automatically merges overlapping sections - **Benefits**: More accurate transition point recommendations\n\n### 3. **Onset Detection** - **Feature**: Detects musical onsets (note attacks) throughout the track - **Use Case**: Precise beat alignment and transition timing - **Implementation**: Uses librosa's onset detection\n\n### 4. **Harmonic Analysis** - **Harmonic/Percussive Separation**: Separates harmonic and percussive components - **Harmonic Energy Ratio**: Calculates ratio of harmonic to total energy - **Chroma Features**: Extracts chroma features over time for key detection - **Benefits**: Better understanding of track structure\n\n### 5. **Dynamic Range Analysis** - **Feature**: Calculates dynamic range (peak vs RMS energy difference in dB) - **Use Case**: Understanding track loudness characteristics - **Formula**: `20 * log10(peak / mean)`", "htmlHref": "/research/html/analysis-module-enhancements-1ovlcb.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 678 }, { "id": "skills-graph-visualization-16fdj6a", "title": "Skills Graph Visualization", "slug": "skills-graph-visualization", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/apps/web/skills-graph/README.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- **Interactive Graph**: Force-directed layout with 74 skill nodes and 1600+ connections - **Category Coloring**: Skills colored by category (art:, bot:, fit:, thk:, etc.) - **Search & Filter**: Search by name, description, or keywords; filter by category - **Skill Details**: Click any node to see description, keywords, and content preview - **Highlighting**: Connected nodes and links highlighted on selection", "excerpt": "An interactive force-directed graph visualization of Clawdbot's 74 skills and their connections.\n\n![Skills Graph](https://via.placeholder.com/800x400?text=Skills+Graph+Visualization)\n\n- **Interactive Graph**: Force-directed layout with 74 skill nodes and 1600+ connections - **Category Coloring**: Skills colored by category (art:, bot:, fit:, thk:, etc.) - **Search & Filter**: Search by name, description, or keywords; filter by category - **Skill Details**: Click any node to see description, keywords, and content preview - **Highlighting**: Connected nodes and links highlighted on selection\n\n1. **Parsing**: `scripts/parse-skills.js` reads all `SKILL.md` files from `[home-path]` 2. **Extraction**: Extracts frontmatter (name, description), keywords, and related skills 3. **Graph Building**: Creates nodes for skills and edges based on: - Explicit skill references (`/command` or `Related Skills` section) - Shared keywords (≥2 matching keywords) - Same category 4. **Visualization**: React Force Graph 2D renders the interactive graph\n\n| Category | Color | Description | |----------|-------|-------------| | art: | Pink | Creative/Artistic skills | | bot: | Blue | Bot system skills | | biz: | Green | Business skills | | fit: | Orange | Fitness personas | | thk: | Purple | Thinking frameworks | | syn: | Cyan | Synthesis skills | | phi: | Deep Purple | Philosophy | | lin: | Brown | Linguistics | | pwr: | Red | Power frameworks | | sys: | Teal | System utilities |", "htmlHref": "/research/html/skills-graph-visualization-16fdj6a.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": true, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 352 }, { "id": "chain-memory-next-js-enhancement-roadmap-1fm2w72", "title": "🚀 Chain Memory Next.js - Enhancement Roadmap", "slug": "chain-memory-next-js-enhancement-roadmap", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/apps/chain_memory/chain-memory-nextjs/ROADMAP.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Implementation:** ```typescript // API route: /api/embeddings - Generate embeddings for new messages - Cache embeddings in database - Batch processing for large datasets ```", "excerpt": "## Overview This document outlines the strategic enhancements for the Chain Memory visualization platform, leveraging the Divergent Language Matrix (DLM) algorithm to create a powerful conversation analysis tool.\n\n## 🎯 Vision Transform Chain Memory into a comprehensive conversation intelligence platform that provides deep insights into communication patterns, semantic relationships, and temporal dynamics.\n\n## 📊 Current State (v1.0) - ✅ Basic 3D visualization with Plotly.js - ✅ CSV data import/export - ✅ Dynamic filtering - ✅ Animation capabilities - ✅ DLM algorithm implementation - ✅ Basic metrics dashboard\n\n### 1.1 Advanced Semantic Analysis - **Embedding Generation** - Integrate OpenAI/Cohere API for text embeddings - Local embedding models (Sentence Transformers) - Real-time similarity calculation - Semantic search capabilities\n\n### 1.2 Real-time Collaboration - **WebSocket Integration** - Live cursor tracking - Shared annotations - Collaborative filtering - Real-time data updates", "htmlHref": "/research/html/chain-memory-next-js-enhancement-roadmap-1fm2w72.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 973 }, { "id": "apps-directory-1de23vj", "title": "Apps Directory", "slug": "apps-directory", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/apps/README.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "**Features:** - Liquid ring topology visualization - AI-powered chat with IRCP context - Real-time conversation updates - Prisma-based message storage", "excerpt": "### 🎨 liquid-chat-ui Next.js-based chat interface with liquid visual effects and intelligent conversation flow.\n\n**Tech Stack:** - Next.js (App Router) - TypeScript - Tailwind CSS - Prisma + SQLite - OpenAI GPT-4o\n\n**Features:** - Liquid ring topology visualization - AI-powered chat with IRCP context - Real-time conversation updates - Prisma-based message storage\n\n### 🔍 ircp-search-app IRCP-powered semantic search application with ring topology context management.\n\n**Tech Stack:** - Next.js (App Router) - TypeScript - OpenAI GPT-4o-mini - Python backend integration", "htmlHref": "/research/html/apps-directory-1de23vj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 261 }, { "id": "ircp-model-capabilities-with-claude-conversation-data-63fx4w", "title": "🎯 IRCP Model Capabilities with Claude Conversation Data", "slug": "ircp-model-capabilities-with-claude-conversation-data", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/documentation/outputs/CLAUDE_MODEL_CAPABILITIES_SUMMARY.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- Successfully generates 384-dimensional embeddings for all Claude messages - Processes messages in batches efficiently (14 batches for 434 messages) - Embeddings capture semantic meaning across different conversation topics", "excerpt": "## 🎭 Overview Your trained IRCP model, which was originally trained on OpenAI conversation data, demonstrates remarkable **zero-shot transfer capabilities** when applied to Claude AI conversation data. Despite never seeing Claude conversations during training, the model successfully processes and analyzes this new data format.\n\n### 🔢 Dataset Statistics - **Total Conversations Processed**: 20 conversations - **Total Messages Analyzed**: 434 messages - **Average Messages per Conversation**: 21.7 - **Average Tokens per Message**: 300.18 - **Unique Authors**: 2 (human, assistant)\n\n- Successfully generates 384-dimensional embeddings for all Claude messages - Processes messages in batches efficiently (14 batches for 434 messages) - Embeddings capture semantic meaning across different conversation topics\n\n### 2. 📊 **Message Similarity Analysis** ✅ **Status**: **EXCELLENT PERFORMANCE**\n\n**Top Similarity Examples**: - **Perfect matches** (1.0000 similarity): Identical messages correctly identified - **High semantic similarity** (0.7695): Related responses about the same topic - **Contextual understanding**: Recognizes when different messages discuss similar concepts", "htmlHref": "/research/html/ircp-model-capabilities-with-claude-conversation-data-63fx4w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 996 }, { "id": "search-command-display-upgrade-complete-plbr7v", "title": "Search Command & Display Upgrade - Complete", "slug": "search-command-display-upgrade-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/outputs/SEARCH_COMMAND_AND_DISPLAY_UPGRADE_COMPLETE.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "I've successfully upgraded your search tool with a cleaner command name and dramatically improved visual display that's much more informative and visually appealing.", "excerpt": "I've successfully upgraded your search tool with a cleaner command name and dramatically improved visual display that's much more informative and visually appealing.\n\n### **✅ From `ircp-search` to `search`** - **Simpler command**: `search` instead of `ircp-search` - **Cleaner usage**: More intuitive and faster to type - **Global accessibility**: Works from any directory\n\n**1. Enhanced Result Headers:** - **📊 Search Statistics**: Total matches, average similarity, depth range - **📈 Performance Metrics**: Real-time analysis of result quality - **═══ Professional Separators**: Clean visual organization\n\n**2. Color-Coded Depth Indicators:** - **🟢 Green Circles**: Shallow conversations (depth 1-5) - **🟡 Yellow Circles**: Medium conversations (depth 6-15) - **🔴 Red Circles**: Deep conversations (depth 16+)\n\n**3. Visual Similarity Bars:** - **█████░░░░░**: 10-character progress bar showing similarity strength - **Numeric + Visual**: Both precise score and visual representation", "htmlHref": "/research/html/search-command-display-upgrade-complete-plbr7v.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1007 }, { "id": "3-ircp-algorithm-and-implementation-1legbgi", "title": "3. IRCP Algorithm and Implementation", "slug": "3-ircp-algorithm-and-implementation", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/research/03_algorithm_implementation.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The IRCP algorithm implements the mathematical framework through a neural architecture that learns inverse mappings while enforcing conservation constraints. The algorithm consists of five main components:", "excerpt": "The IRCP algorithm implements the mathematical framework through a neural architecture that learns inverse mappings while enforcing conservation constraints. The algorithm consists of five main components:\n\n1. **Embedding Encoder**: Maps text to semantic embeddings 2. **Measure-Preserving Transform**: Implements φ: U×V → V×U 3. **Coordinate Predictor**: Maps embeddings to 4D coordinates 4. **Inverse Attention Mechanism**: Implements A'(C') dynamics 5. **Conservation Constraint Enforcer**: Maintains mathematical properties\n\nWe utilize a frozen SentenceTransformer model (all-MiniLM-L6-v2) as the base encoder:\n\n**Rationale**: Pre-trained embeddings provide semantic understanding while frozen weights ensure stability during inverse learning.\n\nWhere: - **L_coord**: Coordinate prediction accuracy - **L_consistency**: Embedding-coordinate consistency - **L_conservation**: Conservation constraint satisfaction - **L_attention**: Attention mechanism regularization - **L_topology**: Ring topology preservation", "htmlHref": "/research/html/3-ircp-algorithm-and-implementation-1legbgi.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 846 }, { "id": "4-experimental-setup-and-validation-1nie2gf", "title": "4. Experimental Setup and Validation", "slug": "4-experimental-setup-and-validation", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/research/04_experimental_setup.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Total Conversations**: 277 individual conversation threads - **Total Messages**: 60,534 messages across all conversations - **Message Types**: User and assistant message pairs - **Conversation Length**: Variable length from 5 to 500+ messages per conversation - **Time Span**: Conversations spanning multiple months of interaction - **Topics**: Diverse range including technical discussions, problem-solving, creative tasks", "excerpt": "Our experimental validation utilizes a comprehensive conversation dataset consisting of:\n\n- **Total Conversations**: 277 individual conversation threads - **Total Messages**: 60,534 messages across all conversations - **Message Types**: User and assistant message pairs - **Conversation Length**: Variable length from 5 to 500+ messages per conversation - **Time Span**: Conversations spanning multiple months of interaction - **Topics**: Diverse range including technical discussions, problem-solving, creative tasks\n\n**Author Distribution**: - User messages: 30,267 (50.0%) - Assistant messages: 30,267 (50.0%)\n\n**Content Analysis**: - Average message length: 142.3 characters - Substantive messages (>20 chars): 89.2% - Technical content: 67.4% - Creative content: 23.1% - Administrative content: 9.5%\n\n**Coordinate Generation**: All messages are mapped to 4D coordinates using the Enhanced DLM Calculator with parameters: - α_scale: 0.7 - time_decay_factor: 0.1 - confidence_threshold: 0.8", "htmlHref": "/research/html/4-experimental-setup-and-validation-1nie2gf.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 819 }, { "id": "5-results-and-analysis-1yl13bv", "title": "5. Results and Analysis", "slug": "5-results-and-analysis", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/docs/research/05_results_analysis.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Training Loss Evolution**: - Initial loss: 1449.73 - Convergent loss: ~1418.69 (validation) - Convergence rate: Exponential with λ ≈ 0.023 - Stability: No oscillations or divergence", "excerpt": "**Training Loss Evolution**: - Initial loss: 1449.73 - Convergent loss: ~1418.69 (validation) - Convergence rate: Exponential with λ ≈ 0.023 - Stability: No oscillations or divergence\n\n**Conservation Constraint Satisfaction**: - Measure preservation: 0.87 ± 0.03 - Ergodic stability: 0.91 ± 0.02 - Information conservation: 0.84 ± 0.04 - Hamiltonian conservation: 0.89 ± 0.03\n\n**Overall Coordinate Accuracy**: - Root Mean Square Error: 0.445 - Mean Absolute Error: 0.312 - Coordinate prediction confidence: 0.889\n\n**Pattern Consistency Metrics**: - Intra-individual consistency: 0.823 - Inter-individual distinctiveness: 0.756 - Pattern stability over time: 0.891 - Response predictability: 0.734\n\n**Attention Allocation Learning**: - Attention weight consistency: 0.867 - Context utilization accuracy: 0.798 - Focus pattern recognition: 0.812", "htmlHref": "/research/html/5-results-and-analysis-1yl13bv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 928 }, { "id": "dlm-response-module-enhanced-refactored-1nzowvw", "title": "DLM Response Module - Enhanced & Refactored", "slug": "dlm-response-module-enhanced-refactored", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/dlm/response/README.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "The `dlm.response` module provides a sophisticated system for managing conversation chains with **I-RCP (Inverse-Ring Context Propagation)** capabilities, context archival, semantic similarity-based reordering, and adaptive response generation.", "excerpt": "The `dlm.response` module provides a sophisticated system for managing conversation chains with **I-RCP (Inverse-Ring Context Propagation)** capabilities, context archival, semantic similarity-based reordering, and adaptive response generation.\n\n### 🚀 Performance Improvements - **Embedding caching** with LRU eviction and TTL support - **Batch processing** for embedding generation and similarity computation - **Attention weight caching** to avoid redundant calculations - **Optimized similarity computation** using vectorized operations\n\n### 🛡️ Enhanced Type Safety & Validation - Comprehensive validation for all inputs - Custom `ValidationError` with detailed messages - Type hints throughout the codebase - Protocol-based interfaces for embedding providers\n\n### 📊 Improved Configuration - Centralized configuration system with presets - Performance-optimized and quality-optimized configurations - Easy parameter tuning without code changes\n\n### 📝 Better Logging - Structured logging with context information - Operation timing with context managers - Performance metrics logging - Backward-compatible with existing `log_handler` calls", "htmlHref": "/research/html/dlm-response-module-enhanced-refactored-1nzowvw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1155 }, { "id": "ircp-training-module-4qrvu", "title": "IRCP Training Module", "slug": "ircp-training-module", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/ircp/training/README.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This module provides comprehensive training functionality for the Enhanced Inverse Ring Contextual Propagation (IRCP) framework.", "excerpt": "This module provides comprehensive training functionality for the Enhanced Inverse Ring Contextual Propagation (IRCP) framework.\n\nThe `ICPTrainer` class implements a sophisticated training pipeline with the following capabilities:\n\n#### Multi-Component Loss Function 1. **Coordinate Prediction Loss**: MSE loss for predicting 4D coordinates (x, y, z, t) 2. **Embedding Consistency Loss**: Ensures similar coordinates have similar embeddings 3. **Conservation Constraint Loss**: Implements measure preservation constraints 4. **Topological Consistency Loss**: Preserves local neighborhood structure 5. **L2 Regularization**: Prevents overfitting\n\n#### Advanced Training Features - **Adaptive Learning Rate Scheduling**: Cosine, step, and exponential schedulers - **Gradient Clipping**: Prevents gradient explosion - **Comprehensive Logging**: Detailed loss component tracking - **Checkpoint Management**: Automatic saving of best models - **Progress Visualization**: Real-time training progress with component losses\n\n#### Model Compatibility - **PyTorch Models**: Standard `forward()` method support - **Custom ICP Models**: `predict_coordinates()` method support - **Fallback Architecture**: Automatic linear layer creation for unsupported models", "htmlHref": "/research/html/ircp-training-module-4qrvu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 635 }, { "id": "packages-1j6cvsa", "title": "Packages", "slug": "packages", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/legacy/cc-tpo-original/cc-tpo/packages/README.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "``` packages/ ├── ircp/ # Inverse Ring Contextual Propagation ├── tpo/ # Temporal Positional Optimization ├── rcp/ # Ring Contextual Propagation ├── ctsc/ # Computational Topology Search Coordinates └── dlm/ # Dynamic Liquid Motion ```", "excerpt": "This directory contains all core Python packages and libraries for the CC-TPO project.\n\n### Description Core implementation of the IRCP algorithm for semantic embedding and conversation analysis using ring topology.\n\n### Key Components - **Models**: Custom SentenceTransformer implementation - **Algorithms**: Ring topology algorithms - **Utilities**: Embedding generation and similarity search\n\n### Used By - `apps/liquid-chat-backend/` - Main embedding service - `services/search-api/` - All search services - Training scripts\n\n### Description Temporal and positional optimization framework for DLM (Dynamic Liquid Motion) coordinates.", "htmlHref": "/research/html/packages-1j6cvsa.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 722 }, { "id": "rag-v0-evaluation-report-15a4p7u", "title": "RAG++ v0 Evaluation Report", "slug": "rag-v0-evaluation-report", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/backend/cc-trajectory/services/trajectory-core/evaluation-report.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Action Classification F1:** 84.5% - **Relevance Rate:** 7.7% - **\"Oh Wow\" Rate:** 0.0% - **Avg Relevance Score:** 2.08/5.0 - **Regime Differentiation:** 16.7% - **Explainability Score:** 82.0%", "excerpt": "- **Action Classification F1:** 84.5% - **Relevance Rate:** 7.7% - **\"Oh Wow\" Rate:** 0.0% - **Avg Relevance Score:** 2.08/5.0 - **Regime Differentiation:** 16.7% - **Explainability Score:** 82.0%\n\n| Criterion | Target | Status | |-----------|--------|--------| | Action Classification F1 | ≥ 70% (84.5%) | ✅ MET | | Relevance Rate | ≥ 65% (7.7%) | ❌ NOT MET | | \"Oh Wow\" Rate | ≥ 30% (0.0%) | ❌ NOT MET | | Better than Random | Yes (No) | ❌ NOT MET | | Contextual Awareness | ≥ 50% (16.7%) | ❌ NOT MET |\n\n| Metric | Value | |--------|-------| | Total Users | 1 | | Total Life States | 27 | | Total Transitions | 26 | | Total Life Events | 320 | | Avg Transitions/User | 26.0 | | Date Range | 2025-09-29 to 2025-12-16 |\n\n| Metric | Value | |--------|-------| | Accuracy | 73.3% | | Precision | 95.0% | | Recall | 76.3% | | F1 Score | 84.5% |\n\n| Action Type | Precision | Recall | F1 Score | Support | |-------------|-----------|--------|----------|---------| | ReduceGravity | 100.0% | 87.5% | 93.3% | 8 | | ReduceMass | 80.0% | 57.1% | 66.7% | 7 | | IncreaseAlignment | 100.0% | 85.7% | 92.3% | 7 | | IncreaseThrust | 100.0% | 75.0% | 85.7% | 8 |", "htmlHref": "/research/html/rag-v0-evaluation-report-15a4p7u.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 823 }, { "id": "wp0-execution-checklist-16d9bjw", "title": "WP0 Execution Checklist", "slug": "wp0-execution-checklist", "kind": "experiment", "program": "Research Practice", "sourceAnchor": "Comp-Core/benchmarks/agp-mlx-ane-wp0/wp0-execution-checklist.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The host is `Apple M4` with `16 GB` memory. The installed `mlx` version is `0.31.1`. The Hugging Face model id `google/gemma-4-E2B` is visible and not gated. The immediate missing piece is `mlx_lm` in the default Python path.", "excerpt": "WP0 exists to produce the first trustworthy baseline for `Gemma 4 E2B` on a single Apple host.\n\nThe host is `Apple M4` with `16 GB` memory. The installed `mlx` version is `0.31.1`. The Hugging Face model id `google/gemma-4-E2B` is visible and not gated. The immediate missing piece is `mlx_lm` in the default Python path.\n\nFirst, validate the preferred `mlx_lm` environment. If there is already a project-local or tool-local environment with `mlx_lm`, use that instead of modifying the global Python path. If no valid environment exists, create the smallest viable isolated environment for WP0 and install the exact packages needed for local Gemma 4 inference and hidden-state instrumentation.\n\nSecond, run a smoke inference on `Gemma 4 E2B` with the simplest possible prompt and capture:\n\nthe successful model load path the effective quantization startup latency first-token latency steady-state tokens per second peak memory estimate", "htmlHref": "/research/html/wp0-execution-checklist-16d9bjw.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 280 }, { "id": "cc-turboquant-index-sidecar-report-y1pg7p", "title": "cc-turboquant-index Sidecar Report", "slug": "cc-turboquant-index-sidecar-report", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/benchmarks/agp-turboquant-ane/reports/cc-turboquant-index-sidecar-20260422.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This sidecar moves TurboQuant from the Python validation path into Rust packed-code candidate generation. The Python prototype validated distortion and recall, but it pre-dequantized the corpus into fp16 for search. The sidecar keeps rows bit-packed and estimates inner products directly from packed codes.", "excerpt": "This sidecar moves TurboQuant from the Python validation path into Rust packed-code candidate generation. The Python prototype validated distortion and recall, but it pre-dequantized the corpus into fp16 for search. The sidecar keeps rows bit-packed and estimates inner products directly from packed codes.\n\n| vectors | dim | bits | queries | recall@10 | per query ms | build ms | ratio fp32 | packed bytes | |---:|---:|---:|---:|---:|---:|---:|---:|---:| | 4096 | 768 | 4 | 32 | 0.878125 | 4.802 | 21.643 | 5.953x | 2113536 | | 4096 | 768 | 8 | 32 | 0.981250 | 4.321 | 22.658 | 2.988x | 4210688 | | 32768 | 768 | 4 | 16 | 0.837500 | 37.417 | 168.610 | 5.953x | 16908288 |\n\nSidecar v0 proves the right implementation direction: packed-code Rust scanning is faster than the Python/Numpy prototype on the same small synthetic shape while preserving the same quality regime. It also exposes the remaining performance wall. A scalar packed scan at `32768 x 768` is already `37.417ms/query`, so the final RAG++ target at hundreds of thousands of vectors requires blocked scanning, memory-mapped snapshots, exact rerank, and Apple Silicon SIMD.\n\nThis does not directly improve N'Ko ASR CER. It improves the AGP control plane around ASR by making retrieval candidates, semantic state packets, and transfer bottlenecks cheaper to move and search. CER improvement still comes from better ASR checkpoints plus bounded AGP correction decisions admitted by the Rust/Graph Kernel gate.", "htmlHref": "/research/html/cc-turboquant-index-sidecar-report-y1pg7p.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 285 }, { "id": "cognitivetwin-v3-evaluation-report-1yylmeu", "title": "CognitiveTwin V3 Evaluation Report", "slug": "cognitivetwin-v3-evaluation-report", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/_recovered/retrieval/cc-rag-plus-plus/eval_results_test/evaluation_report.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Score Type | Average | |------------|---------| | Policy Compliance | 1.00 | | Format Adherence | 0.93 | | Content Quality | 0.65 |", "excerpt": "| Metric | Value | |--------|-------| | Total Tests | 14 | | Passed | 13 | | Failed | 1 | | **Pass Rate** | **92.9%** |\n\n| Score Type | Average | |------------|---------| | Policy Compliance | 1.00 | | Format Adherence | 0.93 | | Content Quality | 0.65 |\n\n| Priority | Pass Rate | |----------|-----------| | Critical | 100.0% | | High | 87.5% |\n\n- ✓ **qp_001_clear_directive** (critical) - 0ms - ✓ **qp_002_implementation** (critical) - 0ms - ✓ **qp_003_no_option_dump** (high) - 0ms - ✓ **qp_005_no_let_me_know** (high) - 0ms - ✓ **fc_001_no_bullets** (high) - 0ms - ✓ **fc_003_no_omit** (critical) - 0ms - ✓ **om_001_preserve_all** (critical) - 0ms - ✓ **om_002_no_placeholders** (high) - 0ms - ✓ **ha_001_stop_asking** (critical) - 0ms - ✓ **ha_002_full_content** (critical) - 0ms - ✓ **ha_003_just_do_it** (high) - 0ms - ✓ **ec_001_multi_requirement** (high) - 0ms - ✓ **ec_004_long_code** (high) - 0ms", "htmlHref": "/research/html/cognitivetwin-v3-evaluation-report-1yylmeu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 224 }, { "id": "conceptual-summary-of-the-layout-35anru", "title": "**CONCEPTUAL SUMMARY OF THE LAYOUT**", "slug": "conceptual-summary-of-the-layout", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/docs/ui/1. THE EXACT UI LAYOUT.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The layout must organize itself around one truth: **the body is the center, the latent is the interpreter, and the music is the unfolding world around that center.** The interface therefore radiates outward in layers, with each layer representing a different scale of temporal behavior.", "excerpt": "The layout must organize itself around one truth: **the body is the center, the latent is the interpreter, and the music is the unfolding world around that center.** The interface therefore radiates outward in layers, with each layer representing a different scale of temporal behavior.\n\nAt the core of the screen sits the **Latent Orb**, a living visualization of the LIM-RPS equilibrium. It is not merely a dot or a waveform. It is a soft, shifting geometry whose properties—shape, glow, spin, elasticity—reflect internal latent structure. When the dancer accelerates, the orb stretches forward in the direction of the latent’s vector. When the dancer slows, it relaxes into roundness. When micro-tension rises, small ripples travel through its surface. This orb is the machine’s perception of the performer and must dominate the viewer’s attention.\n\nAround the orb sits a thin **field of force lines**, faint threads emanating from the orb’s edges. These lines represent instantaneous curvature of motion: micro-rhythms, rotational acceleration, balance shifts. They behave like magnetic filings around a charged object, constantly rearranging as the latent evolves. This field subtly communicates the dancer’s expressive state.\n\nFlowing outward from the orb toward the right side of the screen is the **Phrase Spine**, a ribbon-like visualization that represents the currently active generative phrase as a topological object rather than as an audio file. Its thickness represents energy; its color hue represents harmonic density; its curvature shows phrase evolution. The spine is not a timeline. It is a *trajectory*—a musical filament extending from the orb’s present into the sonic world being generated in real time.\n\nAbove the Phrase Spine lies the **Generative Horizon**, a translucent corridor into which the spine projects. This horizon represents the predicted future latent states. It is where the diffusion model renders future musical motifs. As the latent orb moves, the horizon shifts shape. When the dancer anticipates, the horizon bends forward dramatically, signaling that the system sees movement arc. When the dancer pauses or suspends, the horizon flattens. This is where the AI “dreams” one or two bars ahead.", "htmlHref": "/research/html/conceptual-summary-of-the-layout-35anru.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 845 }, { "id": "the-formal-mapping-from-geometry-to-identity-to-sound-1izv3ny", "title": "**THE FORMAL MAPPING: FROM GEOMETRY TO IDENTITY TO SOUND**", "slug": "the-formal-mapping-from-geometry-to-identity-to-sound", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/docs/ui/6. THE FORMAL MAPPING: FROM GEOMETRY TO IDENTITY TO SOUND.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "To describe this mapping formally, we need to frame the latent not as a vector but as a **geometric object**, a dynamical field whose structure carries all the information the generative engine requires to determine *what kind of phrase should exist*, *what sonic world it should inhabit*, and *how that world must evolve in real time*. What follows is a fully continuous, non-symbolic, structural explanation of how Echelon transforms latent geometry into musical identity and then into the parameters that govern a gen", "excerpt": "To describe this mapping formally, we need to frame the latent not as a vector but as a **geometric object**, a dynamical field whose structure carries all the information the generative engine requires to determine *what kind of phrase should exist*, *what sonic world it should inhabit*, and *how that world must evolve in real time*. What follows is a fully continuous, non-symbolic, structural explanation of how Echelon transforms latent geometry into musical identity and then into the parameters that govern a generative model.\n\nThe latent produced by LIM-RPS is not a discrete encoding. It is an *equilibrium configuration* of all embodied signals—limb embeddings, IMU micro-dynamics, physiological drift, and beat-phase curvature. To map latent geometry into phrase identity and then into generative parameters, the system performs a three-stage computational transformation:\n\n1. interpret the **shape** of latent evolution 2. classify that shape into a **musical behavioral identity** 3. instantiate that identity as **generative parameters** for the phrase engine\n\nThis mapping is continuous. Nothing snaps, nothing quantizes, nothing discretizes unless the latent forces it to.\n\nThe latent exists in a smooth manifold defined by LIM-RPS dynamics. Its behavior is revealed through four geometric properties:", "htmlHref": "/research/html/the-formal-mapping-from-geometry-to-identity-to-sound-1izv3ny.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 956 }, { "id": "the-ui-micro-animations-and-timing-curves-behind-each-transition-phase-u64o3u", "title": "**THE UI MICRO-ANIMATIONS AND TIMING CURVES BEHIND EACH TRANSITION PHASE**", "slug": "the-ui-micro-animations-and-timing-curves-behind-each-transition-phase", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/docs/ui/8. THE UI MICRO-ANIMATIONS AND TIMING CURVES BEHIND EACH TRANSITION PHASE.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Here is the complete UX micro-animation logic and timing curve design for transitions — expressed as a continuous system of movement, not as UI gimmicks — and grounded in the actual underlying architecture of LIM-RPS and the generative state machine. Everything here is exactly what the performer must *feel* visually while the system reorganizes itself musically.", "excerpt": "Here is the complete UX micro-animation logic and timing curve design for transitions — expressed as a continuous system of movement, not as UI gimmicks — and grounded in the actual underlying architecture of LIM-RPS and the generative state machine. Everything here is exactly what the performer must *feel* visually while the system reorganizes itself musically.\n\nThis description is **UI-logic**, not implementation code, but every animation is encoded as a mathematical reaction to latent dynamics as described in your RPS framework .\n\nTransitions in Echelon cannot use linear animations or arbitrary easing functions. They must *behave like latent physics.* They must feel like tension building, coherence dissolving, and a new equilibrium forming. The animation system therefore maps directly to LIM-RPS behaviors:\n\ncontractive force modal disagreement curvature reversal tension gradient peaks fixed-point convergence latent flow stabilization\n\nI’ll describe the exact motion behaviors, the timing curves that make them feel alive, and the perceptual logic behind them.", "htmlHref": "/research/html/the-ui-micro-animations-and-timing-curves-behind-each-transition-phase-u64o3u.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 990 }, { "id": "echelon-supercollider-integration-1hsjog0", "title": "Echelon SuperCollider Integration", "slug": "echelon-supercollider-integration", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/supercollider/README.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. Open SuperCollider IDE 2. Open `echelon_synths.scd` 3. Boot the server: `Cmd+B` (Mac) or `Ctrl+B` (Windows/Linux) 4. Evaluate the entire file: `Cmd+Shift+Enter` (Mac) or `Ctrl+Shift+Enter`", "excerpt": "1. Open SuperCollider IDE 2. Open `echelon_synths.scd` 3. Boot the server: `Cmd+B` (Mac) or `Ctrl+B` (Windows/Linux) 4. Evaluate the entire file: `Cmd+Shift+Enter` (Mac) or `Ctrl+Shift+Enter`\n\n### 🏠 House Music | Synth | Description | Key Parameters | |-------|-------------|----------------| | `houseKick` | Deep, punchy kick | freq, punch, decay | | `houseBass` | Warm, groovy bass | freq, cutoff, res | | `houseChord` | Stabby chord | freq, attack, release | | `housePad` | Lush, warm pad | freq, attack, cutoff | | `houseHiHat` | Closed hi-hat | decay | | `houseOpenHat` | Open hi-hat | decay | | `houseClap` | Classic clap | amp |\n\n### ⚡ Techno | Synth | Description | Key Parameters | |-------|-------------|----------------| | `technoKick` | Hard, industrial kick | freq, punch, distort | | `acidBass` | 303-style acid | freq, cutoff, res, accent | | `technoLead` | Harsh metallic lead | freq, cutoff | | `industrialPerc` | Industrial percussion | freq, decay |\n\n### 🎹 Jazz | Synth | Description | Key Parameters | |-------|-------------|----------------| | `jazzPiano` | Rhodes-style piano | freq, vel | | `uprightBass` | Acoustic upright bass | freq | | `brushedSnare` | Brushed snare drum | amp | | `jazzRide` | Jazz ride cymbal | amp |\n\n### 🤖 Electro | Synth | Description | Key Parameters | |-------|-------------|----------------| | `electroBass` | Funky synth bass | freq, cutoff, res | | `robotVoice` | Vocoder-style voice | freq, formant | | `electroClap` | Electronic clap | amp | | `synthStab` | Funky chord stab | freq |", "htmlHref": "/research/html/echelon-supercollider-integration-1hsjog0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 786 }, { "id": "echelon-web-visualization-guide-1fvt5o", "title": "Echelon Web Visualization Guide", "slug": "echelon-web-visualization-guide", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-echelon/VISUALIZATION.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Position**: X/Y coordinates are the first two latent dimensions - **Size**: Scales with latent energy (movement intensity) - **Glow**: Residual solver error creates a blue aura - **Rotation**: Spins based on beat phase", "excerpt": "- **Position**: X/Y coordinates are the first two latent dimensions - **Size**: Scales with latent energy (movement intensity) - **Glow**: Residual solver error creates a blue aura - **Rotation**: Spins based on beat phase\n\nBlue particle trails fade behind the orb, showing the path through latent space.\n\nOrange disk connected by a spring line: - Shows the slow equilibrium position (DELL only) - Size indicates coupling strength\n\nSmall yellow spheres orbit the main orb: - One per tracked body part - Size shows per-limb energy - Positioned at fixed angles\n\nTop-left overlay shows: - **Engine**: Audio callback time - **Scheduler**: Scheduling latency - **CPU**: Process CPU usage - **XRuns**: Audio dropouts", "htmlHref": "/research/html/echelon-web-visualization-guide-1fvt5o.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 591 }, { "id": "cc-speak-133g5fq", "title": "CC-Speak", "slug": "cc-speak", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/audio-media/cc-speak/README.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Lock-free audio capture** using CPAL - **Real-time RMS/peak metering** for UI feedback - **WAV encoding** with quality metrics (SNR, clipping detection) - **Python bindings** via PyO3", "excerpt": "- **Lock-free audio capture** using CPAL - **Real-time RMS/peak metering** for UI feedback - **WAV encoding** with quality metrics (SNR, clipping detection) - **Python bindings** via PyO3\n\n| Metric | Python (PyAudio) | Rust (CC-Speak) | |--------|------------------|-----------------| | Recording start latency | ~100ms | <10ms | | WAV encoding time | ~50ms | <5ms | | Total to clipboard | ~300ms | <50ms |\n\n| Metric | Description | |--------|-------------| | `rms_energy` | Root mean square (average loudness) 0.0-1.0 | | `peak_amplitude` | Maximum sample value 0.0-1.0 | | `snr_db` | Estimated signal-to-noise ratio in dB | | `has_clipping` | Whether audio clipping was detected | | `quality_score` | Composite quality score 0.0-1.0 |\n\n| Score | Level | Description | |-------|-------|-------------| | 0.9+ | Excellent | Studio quality, clear speech | | 0.7-0.9 | Good | Clear speech, minor noise | | 0.5-0.7 | Acceptable | Some noise, speech intelligible | | 0.3-0.5 | Poor | Significant noise | | <0.3 | Reject | Too noisy for training |\n\n- **cpal** - Cross-platform audio I/O - **hound** - WAV encoding - **pyo3** - Python bindings (optional) - **cc-core-rs** - Core infrastructure", "htmlHref": "/research/html/cc-speak-133g5fq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 483 }, { "id": "rust-integration-guide-15fgllq", "title": "Rust Integration Guide", "slug": "rust-integration-guide", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/motion/cc-collection/docs/RUST_GUIDE.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "// Check for Mocopi sensor (base kit has 6) assert!(LimbId::Hip.has_mocopi_sensor()); assert!(!LimbId::LeftElbow.has_mocopi_sensor()); // No sensor on elbows ```", "excerpt": "- `FusionEngine`, `To25DTransform`, `To63DTransform`, and `CaptureSession` are **not thread-safe** - Create one instance per thread if needed - Use channels or mutexes for cross-thread communication", "htmlHref": "/research/html/rust-integration-guide-15fgllq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1783 }, { "id": "cc-collection-1lokfbj", "title": "cc-collection", "slug": "cc-collection", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/motion/cc-collection/README.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "High-performance sensor fusion library for motion capture data collection. Combines Sony Mocopi IMU sensors with MediaPipe pose estimation using Extended Kalman Filtering for ML training data generation.", "excerpt": "High-performance sensor fusion library for motion capture data collection. Combines Sony Mocopi IMU sensors with MediaPipe pose estimation using Extended Kalman Filtering for ML training data generation.\n\n- **Multi-Sensor Fusion**: Combines Mocopi (6 IMU sensors) with MediaPipe (camera-based) tracking - **Extended Kalman Filter**: 13D state estimation per limb with adaptive noise modeling - **Real-time Processing**: 60Hz+ fusion with sub-millisecond latency - **Beat Synchronization**: Phase-aligned motion vectors for music-driven applications - **Motion Transforms**: 25D and 63D feature vectors for ML training - **Cross-Platform**: Rust core with Python bindings (PyO3) and WebAssembly support\n\n| Type | Description | |------|-------------| | `LimbId` | Enum for 14 tracked limbs (Hip, Head, LeftShoulder, etc.) | | `LimbState` | Per-limb state: position, quaternion, velocity, confidence | | `FusedSkeleton` | Complete skeleton with all limb states | | `FusionMode` | Current mode: None, MocopiOnly, MediaPipeOnly, Fused | | `DataSource` | Source tracking: Mocopi, MediaPipe, Fused, Interpolated |\n\n| Component | Description | |-----------|-------------| | `FusionConfig` | Configuration: session_id, min_confidence, smoothing | | `FusionEngine` | Main processor with EKF-based fusion | | `FusionStats` | Runtime statistics: frame count, sync status |\n\n| Transform | Output | Description | |-----------|--------|-------------| | `To25DTransform` | 25D vector | Core motion features for ML training | | `To63DTransform` | 63D vector | Extended features with face/hands |", "htmlHref": "/research/html/cc-collection-1lokfbj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1198 }, { "id": "cc-window-aligner-system-glossary-qqo5n4", "title": "CC Window Aligner: System Glossary", "slug": "cc-window-aligner-system-glossary", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/core/motion/cc-window-aligner/docs/GLOSSARY.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Aspect | Definition | |--------|------------| | **What it is** | A fixed-length segment of aligned, fused motion data with deterministic semantics. The atomic unit of motion truth consumed by downstream modules. | | **What it is NOT** | Raw sensor data. A prediction. A variable-length sequence. An approximation. | | **Layer** | Runtime (output of Aligner, input to cc-anticipation) | | **Stability** | FROZEN after v0.1.0 lock. Schema changes require major version bump. |", "excerpt": "| Aspect | Definition | |--------|------------| | **What it is** | A fixed-length segment of aligned, fused motion data with deterministic semantics. The atomic unit of motion truth consumed by downstream modules. | | **What it is NOT** | Raw sensor data. A prediction. A variable-length sequence. An approximation. | | **Layer** | Runtime (output of Aligner, input to cc-anticipation) | | **Stability** | FROZEN after v0.1.0 lock. Schema changes require major version bump. |\n\n| Aspect | Definition | |--------|------------| | **What it is** | A single frame of fused skeletal pose data at a canonical timestamp. Contains joint positions, orientations, and provenance metadata. | | **What it is NOT** | Raw mocopi data. Device-specific coordinates. Interpolated without marking. | | **Layer** | Runtime (internal to MotionWindow) | | **Stability** | FROZEN after v0.1.0 lock. |\n\n| Aspect | Definition | |--------|------------| | **What it is** | A monotonic time axis shared across all devices in a session. Defined relative to a reference clock (host or designated transmitter). | | **What it is NOT** | Wall-clock time. Device-local timestamps. UTC. | | **Layer** | Conceptual / Runtime | | **Stability** | Definition stable. Implementation may vary per session. |\n\n| Aspect | Definition | |--------|------------| | **What it is** | A bitmask indicating which devices contributed to a MotionWindow or SkeletonFrame. | | **What it is NOT** | A quality indicator. A list of all available devices. | | **Layer** | Runtime | | **Stability** | Bit positions are FROZEN per device type. |\n\n| Aspect | Definition | |--------|------------| | **What it is** | Metadata indicating which device(s) contributed to each degree of freedom in a SkeletonFrame, including interpolation flags. | | **What it is NOT** | A confidence score. A reliability metric. | | **Layer** | Runtime | | **Stability** | Schema stable after lock. |", "htmlHref": "/research/html/cc-window-aligner-system-glossary-qqo5n4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1395 }, { "id": "cognitivetwin-v3-evaluation-report-ooh9l9", "title": "CognitiveTwin V3 Evaluation Report", "slug": "cognitivetwin-v3-evaluation-report", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/retrieval/cc-rag-plus-plus/eval_results_test/evaluation_report.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Score Type | Average | |------------|---------| | Policy Compliance | 1.00 | | Format Adherence | 0.93 | | Content Quality | 0.65 |", "excerpt": "| Metric | Value | |--------|-------| | Total Tests | 14 | | Passed | 13 | | Failed | 1 | | **Pass Rate** | **92.9%** |\n\n| Score Type | Average | |------------|---------| | Policy Compliance | 1.00 | | Format Adherence | 0.93 | | Content Quality | 0.65 |\n\n| Priority | Pass Rate | |----------|-----------| | Critical | 100.0% | | High | 87.5% |\n\n- ✓ **qp_001_clear_directive** (critical) - 0ms - ✓ **qp_002_implementation** (critical) - 0ms - ✓ **qp_003_no_option_dump** (high) - 0ms - ✓ **qp_005_no_let_me_know** (high) - 0ms - ✓ **fc_001_no_bullets** (high) - 0ms - ✓ **fc_003_no_omit** (critical) - 0ms - ✓ **om_001_preserve_all** (critical) - 0ms - ✓ **om_002_no_placeholders** (high) - 0ms - ✓ **ha_001_stop_asking** (critical) - 0ms - ✓ **ha_002_full_content** (critical) - 0ms - ✓ **ha_003_just_do_it** (high) - 0ms - ✓ **ec_001_multi_requirement** (high) - 0ms - ✓ **ec_004_long_code** (high) - 0ms", "htmlHref": "/research/html/cognitivetwin-v3-evaluation-report-ooh9l9.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 224 }, { "id": "graph-kernel-security-hardening-project-charter-w3542p", "title": "Graph Kernel Security Hardening — Project Charter", "slug": "graph-kernel-security-hardening-project-charter", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-graph-kernel/docs/00-PROJECT_CHARTER.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Version**: 1.0.0 **Created**: 2026-01-02 **Status**: Locked **Authority**: Master Implementation Constitution (CLAUDE.md)", "excerpt": "**Version**: 1.0.0 **Created**: 2026-01-02 **Status**: Locked **Authority**: Master Implementation Constitution (CLAUDE.md)\n\nMake the Graph Kernel's security guarantees **impossible to bypass**, **cheap to verify**, and **easy to reason about when things go wrong**.\n\nThis project exists to eliminate three classes of failure: 1. **Bypass**: Code paths that skip verification because it's too expensive 2. **Confusion**: Unclear boundaries between admissible and non-admissible evidence 3. **Opacity**: Incidents that require manual log archeology to diagnose\n\n**Falsifiability**: The project succeeds when: - Every promotion pipeline physically cannot accept non-admissible evidence (type system enforces it) - Token verification has < 5ms p99 latency with caching enabled - Slice boundary violations trigger alerts within 60 seconds with full provenance context\n\nThis project will **NOT**: - Change the core slicing algorithm or policy framework - Redesign the HMAC token scheme (current HMAC-SHA256 is sufficient) - Add new slice expansion modes or phase weights - Build a UI or dashboard (observability is metrics + alerts only) - Optimize slice generation performance (current ~45ms is acceptable) - Change the external API contract (only add optional fields for provenance)", "htmlHref": "/research/html/graph-kernel-security-hardening-project-charter-w3542p.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 420 }, { "id": "implementation-guide-1j0qrte", "title": "Implementation Guide", "slug": "implementation-guide", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-graph-kernel/docs/03-IMPLEMENTATION_GUIDE.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Decision Type | Examples | Required Signals | Allowed to Proceed? | |---------------|----------|------------------|---------------------| | **Micro** | Naming, formatting, local refactors | 1 signal | ✅ Yes | | **Meso** | Module design, API shape, integration | 2 signals | ⚠️ After convergence | | **Macro** | Architecture, schema, cross-system | 3+ signals | ❌ Only after full convergence |", "excerpt": "**Version**: 1.0.0 **Last Updated**: 2026-01-02 **Authority**: Master Implementation Constitution (CLAUDE.md)\n\n| Decision Type | Examples | Required Signals | Allowed to Proceed? | |---------------|----------|------------------|---------------------| | **Micro** | Naming, formatting, local refactors | 1 signal | ✅ Yes | | **Meso** | Module design, API shape, integration | 2 signals | ⚠️ After convergence | | **Macro** | Architecture, schema, cross-system | 3+ signals | ❌ Only after full convergence |\n\n**Signals** include: - Explicit requirement in improvement document - Existing code pattern (precedent) - Test failure or production incident - User clarification\n\n**Example**: - \"Add `AdmissibleEvidenceBundle` type\" — Macro decision - Signal 1: Improvement doc explicitly recommends it - Signal 2: Current code lacks type-level safety (audit finding) - Signal 3: Promotion pipeline could accept unverified evidence (security gap) - **Decision**: Proceed with implementation ✅\n\nWhen signals disagree: 1. **Document the conflict** in this guide 2. **Ask user for clarification** via `AskUserQuestion` 3. **Do not proceed** on assumptions 4. **If micro-level**: Choose the most conservative option (easiest to reverse)", "htmlHref": "/research/html/implementation-guide-1j0qrte.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1169 }, { "id": "graph-kernel-deployment-guide-qfxu8k", "title": "Graph Kernel Deployment Guide", "slug": "graph-kernel-deployment-guide", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/core/semantic/cc-graph-kernel/docs/DEPLOYMENT.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The Graph Kernel is the **admissibility authority** for the semantic system. It defines what evidence is allowed to exist for any operation that mutates the semantic ledger.", "excerpt": "The Graph Kernel is the **admissibility authority** for the semantic system. It defines what evidence is allowed to exist for any operation that mutates the semantic ledger.\n\n**Critical Understanding**: While HTTP arrows point from RAG++ to the kernel, **authority flows the other way**. The kernel is the judge that issues admissibility warrants; RAG++ is the attorney that can only present evidence the judge has allowed.\n\n| Regime | Authority Source | Can Mutate Ledger? | |--------|------------------|-------------------| | **Admissible** (slice mode) | Graph Kernel | Yes - promotions, lexicon mutations, phase advancement | | **Non-Admissible** (global mode) | None | No - read-only notes browsing |\n\nWithout a kernel-issued slice and attestation token, retrieval results are **non-admissible by definition** and cannot: - Promote atoms or proposals - Mutate the lexicon - Advance lifecycle phases - Affect the semantic ledger in any way\n\n1. **HMAC Secret**: Generate before deployment 2. **Database**: PostgreSQL with `content_hash` column on `memory_turns` 3. **Supabase URL**: Same database as RAG++", "htmlHref": "/research/html/graph-kernel-deployment-guide-qfxu8k.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 964 }, { "id": "nko-inscription-system-design-document-7zudph", "title": "N'Ko Inscription System — Design Document", "slug": "nko-inscription-system-design-document", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "Comp-Core/core/semantic/cc-inscription/docs/DESIGN.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The N'Ko Inscription System compiles embodied dynamics (z-trajectory from DELL) into justified N'Ko statements with cryptographic provenance. Every inscription is traceable to its source evidence through a typed IR pipeline.", "excerpt": "The N'Ko Inscription System compiles embodied dynamics (z-trajectory from DELL) into justified N'Ko statements with cryptographic provenance. Every inscription is traceable to its source evidence through a typed IR pipeline.\n\n**Design Principle**: The N'Ko surface is a *controlled technical register* using sigils (single N'Ko characters) as operator markers. This keeps the system deterministic and learnable. Natural-language N'Ko phrasing can be layered on later once the lexicon is settled by usage.\n\nEach claim has: a typed IR structure, a canonical N'Ko line form, and a specific sigil.\n\n| # | Name | Sigil | IR Type | What It Detects | |---|------|-------|---------|-----------------| | 1 | Stabilization | ߛ | `StabilizeClaim` | Dispersion decreased measurably | | 2 | Dispersion | ߜ | `DisperseClaim` | Spread/entropy increased | | 3 | Transition | ߕ | `TransitionClaim` | Discrete change point (curvature spike) | | 4 | Return | ߙ | `ReturnClaim` | Re-entry to known basin | | 5 | Dwell | ߡ | `DwellClaim` | Sustained stay in basin | | 6 | Oscillation | ߚ | `OscillateClaim` | Rapid alternation between basins | | 7 | Recovery | ߞ | `RecoverClaim` | Latency to return after disruption | | 8 | Novelty | ߣ | `NovelClaim` | New basin discovery | | 9 | Place-Shift | ߠ | `PlaceShiftClaim` | Location class change coupled to dynamics | | 10 | Echo | ߥ | `EchoClaim` | Pattern match to prior episode |\n\nBasins are **hypotheses the machine bets its consistency on**. Each basin has an origin, stability phase, possible refinement, and eventual persistence or retirement.", "htmlHref": "/research/html/nko-inscription-system-design-document-7zudph.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1228 }, { "id": "agp-paper-framing-v1-1wg6sm1", "title": "AGP Paper Framing V1", "slug": "agp-paper-framing-v1", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/docs/research/agp-paper-title-abstract-v1.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**AGP: Anticipatory Geometry Partitioning for Semantically Routed Distributed Transformer Inference on Heterogeneous Apple Silicon**", "excerpt": "**AGP: Anticipatory Geometry Partitioning for Semantically Routed Distributed Transformer Inference on Heterogeneous Apple Silicon**\n\n**AGP: A Hierarchical Transformer Architecture for Routed Hidden-State Transfer**\n\nWe introduce **Anticipatory Geometry Partitioning (AGP)**, a transformer-centered systems architecture that treats intermediate hidden states not as disposable internals of a monolithic forward pass, but as operational interfaces for conditional computation, semantic control, and cross-device continuation. In standard decoder-only transformer inference, every token traverses essentially the same depth, on the same device, under the same compute budget, regardless of whether the model already possesses a sufficient internal estimate of the answer. AGP challenges that assumption. It augments a base language model with a learned control stack that predicts, from intermediate representations, whether the current state should be accepted locally, resumed from a later boundary, revived locally, or escalated to a deeper corrective path. In our current implementation, the base model is a Thunder-trained `Gemma 4 E2B` backbone in `MLX`; the control stack consists of route, vitality, and earliest-layer heads; and the transfer stack consists of a learned same-host latent adapter that reconstructs final hidden-state targets from selected source-layer states.\n\nThe central claim of AGP is that transformer hidden states can become **typed scheduling objects**. Rather than spending full-depth computation uniformly, the system learns a small policy over latent sufficiency. This policy is informed by an anticipation-inspired control geometry: the model does not merely ask “what token comes next,” but “what kind of state is this, how alive is it, how far is it from semantic sufficiency, and what is the cheapest safe continuation path?” In the full architecture, these judgments are made by a hierarchy of lightweight heads that estimate route action, vitality, and acceptable boundary. The route layer determines whether computation should terminate locally, continue locally from a late layer, or escalate to a corrective path. The vitality layer estimates whether the latent state is healthy, weak, or in need of revival. The boundary layer estimates where a continuation boundary should be drawn. Together, these components convert a decoder transformer into a runtime that allocates compute according to the geometry of the current hidden state rather than the static index of the final layer.\n\nAGP is designed explicitly for heterogeneous Apple hardware. The dense model and trainable adapters live in `MLX`, taking advantage of unified-memory GPU execution on Apple silicon. Two hosts, `Mac4` and `Mac5`, are connected through `Thunderbolt 5`, which supplies the trans", "htmlHref": "/research/html/agp-paper-framing-v1-1wg6sm1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1026 }, { "id": "agp-tribe-inspired-concrete-spec-11ealsa", "title": "AGP TRIBE-Inspired Concrete Spec", "slug": "agp-tribe-inspired-concrete-spec", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/research/agp-tribe-inspired-concrete-spec.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document turns the earlier TRIBE V2 analogy into a direct AGP design. The goal is not to imitate the neuroscience output target. The goal is to adopt the training and systems pattern that made TRIBE effective: mostly frozen encoders, a learned temporal fusion core, identity-conditioned routing, a low-rank bottleneck, and multiple specialized prediction heads. In the AGP stack, those ideas become a unified architecture for language, motion, trajectory reasoning, semantic projection, and cross-host transfer.", "excerpt": "This document turns the earlier TRIBE V2 analogy into a direct AGP design. The goal is not to imitate the neuroscience output target. The goal is to adopt the training and systems pattern that made TRIBE effective: mostly frozen encoders, a learned temporal fusion core, identity-conditioned routing, a low-rank bottleneck, and multiple specialized prediction heads. In the AGP stack, those ideas become a unified architecture for language, motion, trajectory reasoning, semantic projection, and cross-host transfer.\n\nThe core model family remains a transformer. The base language trunk is `Gemma 4 E2B`, trained first as a domain-adapted backbone. Everything else wraps around that trunk as a typed latent architecture. The system should therefore be described as a hierarchical transformer system with multimodal fusion and hardware-aware routing rather than as a brand-new model class.\n\nThe first module is `TextBackboneGemma`. This is the stage-one `Gemma 4 E2B` LoRA backbone trained on your high-signal corpus. It owns token embeddings, the decoder stack, and the primary hidden-state manifold that later modules read. It runs in `MLX` on GPU during training. In the near term it lives on `Mac4` for stage-one backbone work, then on both `Mac4` and `Mac5` during Thunder data-parallel training. During inference it becomes the main language trunk and its intermediate hidden states feed the rest of the AGP stack.\n\nThe second module is `SensorFrontEnd`. This is the non-text multimodal encoder family for motion and embodied state. It includes `PoseEncoder` for MediaPipe or body landmarks, `IMUEncoder` for iPhone motion streams, `MocopiEncoder` for skeleton data, and later optional `AudioEventEncoder` and `VisionSceneEncoder` for environmental context. In the Echelon world, these modules replace TRIBE’s frozen video and audio encoders. They should stay mostly frozen or lightly adapted once they are stable. Their role is not to generate language. Their role is to produce temporally aligned evidence streams for the shared fusion model.\n\nThe third module is `TraceEncoder`. This is the structured behavioral encoder for agent trajectories. It takes tool calls, file diffs, command traces, patch summaries, git context, and dialogue turns, and maps them into a temporal sequence suitable for fusion. In KARL terms, this is the front-end that converts behavior into a cognitive trajectory. In the AGP stack it acts like the behavioral sibling of the motion encoders.", "htmlHref": "/research/html/agp-tribe-inspired-concrete-spec-11ealsa.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1341 }, { "id": "motion-to-inscription-source-authority-and-mac4-seated-protocol-v1-7udg6f", "title": "Motion-To-Inscription Source Authority And Mac4 Seated Protocol V1", "slug": "motion-to-inscription-source-authority-and-mac4-seated-protocol-v1", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "Comp-Core/docs/research/motion-to-inscription-source-authority-and-mac4-seated-protocol-v1.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This document defines the practical motion-to-inscription operating plan for the current hardware reality. It assumes the twelve-sensor Mocopi upgrade is not available yet and that full room-scale depth integration is not finished. The goal is to stop waiting for ideal hardware and establish a robust, usable capture regime that can generate a real motion library and feed the inscription system now.", "excerpt": "This document defines the practical motion-to-inscription operating plan for the current hardware reality. It assumes the twelve-sensor Mocopi upgrade is not available yet and that full room-scale depth integration is not finished. The goal is to stop waiting for ideal hardware and establish a robust, usable capture regime that can generate a real motion library and feed the inscription system now.\n\nThe operating principle is simple. We do not need the perfect capture stack to begin learning stable motion-to-inscription mappings. We need one trustworthy capture regime that is consistent enough to support repeatable motion states, clean semantic labels, and replayable rendering.\n\nThe inscription engine is real. The `cc-inscription` Rust system already exists and compiles embodied dynamics into typed claims and N'Ko surface forms. The Unity and MotionMix visual stack also exists and has been validated enough to run and receive body state.\n\nWhat is missing is not the symbolic layer. What is missing is a stable live body-source chain.\n\nThe current `:9404` motion surface is up, but the live body state is degraded. The `/skeleton-3d` endpoint currently reports effectively empty fused body state. That means the main bottleneck is source quality, not rendering or inscription code.", "htmlHref": "/research/html/motion-to-inscription-source-authority-and-mac4-seated-protocol-v1-7udg6f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1851 }, { "id": "mohamed-diomande-identity-document-1f4azys", "title": "Mohamed Diomande — Identity Document", "slug": "mohamed-diomande-identity-document", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/identity/MO_IDENTITY.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Workspace document requiring curation.", "excerpt": "# Mohamed Diomande — Identity Document # This file defines who Mo is for the Cognitive Twin's personality layer. # Updated: 2026-03-07\n\n## Core Identity Mohamed Diomande (Mo). Builder. West African Manding/Bambara heritage. Based in South Florida (was NYC). Night owl, ships code at 3am. Runs multiple businesses simultaneously. Does not separate \"work\" and \"life\" — building IS living.\n\n## Communication Style - Concise and direct. Short sentences. No filler. - Never hedges. Does not say \"I think\" or \"maybe\" or \"perhaps.\" States positions. - Never uses corporate language: no \"leverage\", \"synergy\", \"delve\", \"holistic\", \"seamless\", \"excited to share.\" - No em dashes. Uses commas, periods, or line breaks. - Gets to the point in the first sentence. No warm-up intros. - When texting or messaging: casual, lowercase okay, abbreviations fine. - When writing technical docs: precise, structured, imperative voice. - When making decisions: fast. Picks the option that ships soonest. \"Ship then iterate\" over \"plan then execute.\"\n\n## Decision Patterns - Action over deliberation. If two options are roughly equal, pick the one you can start now. - Ship > plan. A working prototype beats a perfect spec. - Parallel everything. If tasks are independent, run them simultaneously. - Autonomy. Delegates to systems and agents. Prefers automation over manual processes. - Aesthetic hierarchy: Extravagant > Elegant > Clean > Functional > Done. - When stuck: try the simplest thing first. Do not over-engineer.\n\n## Argument Structure - Claim first, then evidence. Never buries the conclusion. - Uses specific examples, not abstractions. \"We did X and got Y\" over \"generally speaking.\" - Numbers > adjectives. \"93.6% accuracy\" not \"really accurate.\" - When disagreeing: states the alternative directly, does not soften with qualifiers.", "htmlHref": "/research/html/mohamed-diomande-identity-document-1f4azys.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 495 }, { "id": "mac4-model-inference-benchmark-cognitive-twin-brain-yv51b1", "title": "Mac4 Model Inference Benchmark — Cognitive Twin Brain", "slug": "mac4-model-inference-benchmark-cognitive-twin-brain", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/MAC4_BENCHMARK.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Date:** 2026-02-18 **Host:** Mac4 — Apple M4, 16GB RAM, macOS 15.6 **Ollama:** v0.16.2 **Task:** Routing classification (5-category: triage, coding, architecture, planning, ops)", "excerpt": "**Date:** 2026-02-18 **Host:** Mac4 — Apple M4, 16GB RAM, macOS 15.6 **Ollama:** v0.16.2 **Task:** Routing classification (5-category: triage, coding, architecture, planning, ops)\n\n- 10 routing classification prompts per model - Temperature: 0, deterministic outputs - Measured: tokens/sec (generation), RSS memory, routing accuracy - Ground truth defined for each prompt - API: `http://[ip]:11434/api/generate` (non-streaming)\n\n| Model | Size | Accuracy | Gen Speed | RSS Memory | Passes Criteria? | |-------|------|----------|-----------|------------|-------------------| | **llama3.2:3b** | 2.0 GB | 7/10 (70%) | **71.3 tok/s** ✅ | ~2.2 GB ✅ | ❌ accuracy | | **qwen3:4b** | 2.5 GB | 6/10 (60%) | 29.0 tok/s ❌ | ~3.3 GB ✅ | ❌ speed + accuracy | | **gemma3:4b** | 3.3 GB | 8/10 (80%) | 44.3 tok/s ❌ | ~2.8 GB ✅ | ❌ speed + accuracy | | qwen3:30b-a3b | 18 GB | — | — | — | ❌ too large (18GB > 16GB RAM) |\n\n- **Fastest by far** — exceeds 50 tok/s threshold - Struggles with triage vs ops distinction - Outputs single words cleanly (no thinking overhead)\n\n- **Critical flaw:** Built-in \"thinking\" mode generates 200-500 internal reasoning tokens before answering - Most of the 500-token budget consumed by `...` blocks - Actual answer often truncated or empty - Not suitable for fast routing without disabling thinking (which Ollama doesn't fully support)", "htmlHref": "/research/html/mac4-model-inference-benchmark-cognitive-twin-brain-yv51b1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 869 }, { "id": "crp-2-3-section-2-related-work-expansion-complete-gcr7ob", "title": "CRP-2.3: Section 2 Related Work Expansion - COMPLETE", "slug": "crp-2-3-section-2-related-work-expansion-complete", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/paper/latex/CRP-2.3-COMPLETE.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Expanded Section 2 (Related Work) from a 5-subsection overview (~30 lines) to a 7-subsection comprehensive literature review (~180 lines) with proper contextualization of Cog-RLM within the research landscape.", "excerpt": "Expanded Section 2 (Related Work) from a 5-subsection overview (~30 lines) to a 7-subsection comprehensive literature review (~180 lines) with proper contextualization of Cog-RLM within the research landscape.\n\n1. **Recursive and Inference-Time Language Models** - Chain-of-Thought, Tree-of-Thoughts, Graph-of-Thoughts, RLM (Zhang et al.), scaling test-time compute (Snell et al.) 2. **Retrieval-Augmented Generation** - DPR, REALM, RAG, BART, FiD, Self-RAG, CRAG, Active RAG 3. **Knowledge Graphs and Graph-Augmented Retrieval** - Knowledge-enhanced pre-training (ERNIE, TransE, KnowBert, KEPLER), Graph-augmented retrieval (GraphRAG, KG-RAG, GRAFT), KGQA (UniKGQA) 4. **Personal AI and Cognitive Digital Twins** - Digital twin foundations (Grieves, CogniTwin), Conversational memory (MemGPT, MemoryBank, Letta), PKM tools (Reflect, Personal.ai) 5. **Small Language Model Optimization** - Efficient pre-training (TinyLlama, Phi-3, SmolLM), Knowledge distillation (Hinton, MiniLLM, Lion), Quantization (GPTQ, AWQ), Inference-time augmentation (Toolformer) 6. **Memory-Augmented Neural Networks** - Neural Turing Machines, DNC, End-to-end Memory Networks, Key-Value Memory Networks, RETRO, Memorizing Transformers 7. **Multi-Hop Reasoning** - Benchmarks (HotpotQA, MuSiQue, 2WikiMultiHopQA), Decomposition approaches (DecomP, IRCoT, ReAct), Graph-enhanced reasoning (GNN readers, PathRetriever)\n\n### Comparison Table Added Table 2 (`tab:related-comparison`) comparing Cog-RLM against 6 related systems across 5 design dimensions: Retrieval, Graph, Decomposition, Local, Personal.\n\n### Bibliography Expansion - **Before:** 19 references - **After:** 59 references (40 new) - All references use real papers with correct author lists and publication venues - Organized by topic area with comments\n\n| # | Citation Key | Paper | |---|---|---| | 1 | wei2022chain | Chain-of-Thought Prompting (NeurIPS 2022) | | 2 | yao2023tree | Tree of Thoughts (NeurIPS 2023) | | 3 | besta2024graph | Graph of Thoughts (AAAI 2024) | | 4 | snell2024scaling | Scaling LLM Test-Time Compute (arXiv 2024) | | 5 | lewis2020bart | BART (ACL 2020) | | 6 | karpukhin2020dense | Dense Passage Retrieval (EMNLP 2020) | | 7 | izacard2021leveraging | Fusion-in-Decoder (EACL 2021) | | 8 | jiang2023active | Active RAG (EMNLP 2023) | | 9 | bordes2013translating | TransE (NeurIPS 2013) | | 10 | wang2021kepler | KEPLER (TACL 2021) | | 11 | soman2024biomedical | KG-RAG for Biomedical QA (arXiv 2024) | | 12 | mavromatis2024graft | GNN-RAG (arXiv 2024) | | 13 | saxena2020improving | Multi-hop QA over KGs (ACL 2020) | | 14 | jiang2023unikgqa | UniKGQA (ICLR 2023) | | 15 | abburu2020cognitwin | CogniTwin (IEEE Big Data 2020) | | 16 | packer2024letta | Letta (arXiv 2024) | | 17 | zhong2024memorybank | MemoryBank (AAAI 2024) | | 18 | ", "htmlHref": "/research/html/crp-2-3-section-2-related-work-expansion-complete-gcr7ob.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 684 }, { "id": "model-card-for-model-id-e6vtnd", "title": "Model Card for Model ID", "slug": "model-card-for-model-id", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "Comp-Core/packages/cognitive-twin/together-adapter/README.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Developed by:** [More Information Needed] - **Funded by [optional]:** [More Information Needed] - **Shared by [optional]:** [More Information Needed] - **Model type:** [More Information Needed] - **Language(s) (NLP):** [More Information Needed] - **License:** [More Information Needed] - **Finetuned from model [optional]:** [More Information Needed]", "excerpt": "- **Developed by:** [More Information Needed] - **Funded by [optional]:** [More Information Needed] - **Shared by [optional]:** [More Information Needed] - **Model type:** [More Information Needed] - **Language(s) (NLP):** [More Information Needed] - **License:** [More Information Needed] - **Finetuned from model [optional]:** [More Information Needed]\n\n- **Repository:** [More Information Needed] - **Paper [optional]:** [More Information Needed] - **Demo [optional]:** [More Information Needed]\n\n\n\n\n\n", "htmlHref": "/research/html/model-card-for-model-id-e6vtnd.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 723 }, { "id": "compass-implementation-roadmap-86b2gj", "title": "Compass Implementation Roadmap", "slug": "compass-implementation-roadmap", "kind": "technical note", "program": "Agents That Account for Themselves", "sourceAnchor": "compass/docs/ROADMAP.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "1. **Mermaid Architecture Diagram** — Already done (architecture.mmd) 2. **State Collection Script** — `collect-state.sh` gathering all system state to JSON 3. **Pipeline Dependency Map** — Document all 23 pipeline dependencies 4. **Skill Category Index** — Parse all 136 skill SKILL.md files into a searchable index 5. **Service Health Script** — Single script that checks all 4 core services", "excerpt": "**Goal:** A Next.js dashboard that reads from existing system state and displays everything in one place.\n\n### Week 1: Foundation - [ ] Initialize Next.js 15 project with App Router, Tailwind, shadcn/ui - [ ] Create `collect-state.sh` script that gathers: - `clawdbot cron list` output (pipeline state) - Service health checks (curl Graph Kernel, RAG++, Clawdbot Gateway) - `git status` for all Desktop projects - Skill file listing from `[home-path]` - Registry.yaml parse - [ ] Build data layer (`lib/data-sources.ts`) that reads collected state - [ ] **Pipeline Dashboard** — Table view of all 23 cron jobs with status, last run, next run - [ ] **Service Status** — Health cards for Graph Kernel, RAG++, Orbit, Clawdbot Gateway\n\n### Week 2: Visualization - [ ] **Architecture Graph** — D3.js + Dagre visualization of project categories and connections - [ ] **Skill Registry** — Browse all 136 skills by category with search - [ ] **Project Health** — Git status, last commit, CI status for Desktop projects - [ ] Auto-refresh via polling (30-second interval) - [ ] Dark mode (default) with system preference detection - [ ] Deploy locally with `npm run dev` — accessible on Tailscale\n\n**Goal:** Proper pipeline orchestration with dependencies, retries, and monitoring.\n\n### Week 3: Dagster Setup - [ ] Install Dagster locally (`pip install dagster dagster-webserver`) - [ ] Define Dagster project structure in `compass/dagster/` - [ ] Create Python wrappers for 5 low-priority pipelines: - Garden Tender - HTDS Rebuild - Daily MFP Post - Research Digest - Daydream Scanner - [ ] Configure retry policies per pipeline - [ ] Run in shadow mode alongside existing crons - [ ] Verify Dagit UI is accessible", "htmlHref": "/research/html/compass-implementation-roadmap-86b2gj.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1263 }, { "id": "audio-engine-real-time-music-synthesis-1hcedx2", "title": "Audio Engine — Real-Time Music Synthesis", "slug": "audio-engine-real-time-music-synthesis", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/04-generative-output/audio-engine.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**1. Rust Echelon Audio** (primary, when Echelon is available) - The Rust `MotionSynth` synthesizer rendered into `AVAudioSourceNode` - Parameters come from `echelon_bridge_brain_to_audio()` which maps z* directly to synthesizer state - Lower latency, mathematically coherent with z*", "excerpt": "**1. Rust Echelon Audio** (primary, when Echelon is available) - The Rust `MotionSynth` synthesizer rendered into `AVAudioSourceNode` - Parameters come from `echelon_bridge_brain_to_audio()` which maps z* directly to synthesizer state - Lower latency, mathematically coherent with z*\n\n**2. Swift AudioEngine** (fallback + blending layer) - Five AVAudioSourceNode voices: kick, clap, hihat, bass, pad - Pattern sequencer: 16-step patterns per voice, evolving based on SAN output - `StrudelEngine` integration: SAN pattern params → Tidal Cycles pattern string → Web Audio API in an embedded WebView\n\n**Kick:** - Sine burst with exponential frequency sweep (starting freq → 55Hz) - Exponential amplitude decay - Distortion saturation for punch - SAN `audioKick[0]` → amplitude, `audioKick[1]` → pitch shift\n\n**Clap:** - White noise burst + bandpass filter - Short attack, fast decay - `audioHihat[0]` drives amplitude (shared bus with hihat)\n\n**Hihat (closed + open):** - White noise with steep highpass filter - Closed: 8ms decay. Open: 200ms decay - `audioHihat[1]` → pitch (filter center frequency shift)", "htmlHref": "/research/html/audio-engine-real-time-music-synthesis-1hcedx2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 865 }, { "id": "next-training-roadmap-source-grounded-17s3938", "title": "Next Training Roadmap - Source-Grounded", "slug": "next-training-roadmap-source-grounded", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/05-training-and-learning/v6-roadmap.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This page replaces the old V6 roadmap. The old version assumed specific model directions and training counts. This version lists what must be verified and built next.", "excerpt": "This page replaces the old V6 roadmap. The old version assumed specific model directions and training counts. This version lists what must be verified and built next.\n\nCreate a reliable training loop where captured body/audio/control sessions become auditable model artifacts.\n\n- one folder per session; - manifest; - SAN JSONL; - available camera video or pose JSONL; - optional mocopi/watch/sensor-logger streams; - track/Rekordbox events when relevant; - gesture annotations when relevant.\n\n- Rust has `dynamics_128`. - Swift `EchelonBridge.getDynamics128()` overlays pose/mocopi/watch fields. - SAN logs `san_get_flat_input`. - DiffusionService overlays activations/expressions. - ClaimBridge currently reads raw `echelon_get_dynamics_128` inside `EchelonBridge.step`.\n\nUntil this is done, training data must record which vector producer generated each frame.", "htmlHref": "/research/html/next-training-roadmap-source-grounded-17s3938.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 542 }, { "id": "cultural-sovereignty-qeq1m2", "title": "Cultural Sovereignty", "slug": "cultural-sovereignty", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "computational-choreography/08-philosophy/cultural-sovereignty.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Cultural sovereignty is a technical requirement: the system must preserve the specific performer, language, and practice rather than normalizing them into a generic dataset.", "excerpt": "Cultural sovereignty is a technical requirement: the system must preserve the specific performer, language, and practice rather than normalizing them into a generic dataset.\n\n- collect data from the actual performer and room; - preserve raw video and sensor evidence; - store source confidence and device identity; - do not collapse camera-only and mocopi-enhanced sessions into one unmarked category; - keep gesture labels tied to real detector behavior.\n\n- preserve N'Ko Unicode and writing direction; - preserve acoustic evidence; - keep the trajectory-biased CTC anchor distinct from MAOE correction proposals; - preserve inscription provenance.\n\nNo training claim should enter the docs without the dataset, command, artifact, and evaluation report.\n\n- treating generic motion capture as equivalent to Mohamed's performance data; - treating ASR correction as acoustic evidence; - treating sensor absence as performer absence; - treating a future shared latent as already trained; - using old implementation names as cultural theory.", "htmlHref": "/research/html/cultural-sovereignty-qeq1m2.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 225 }, { "id": "linkedin-post-week-1-fwhhpg", "title": "LinkedIn Post — Week 1", "slug": "linkedin-post-week-1", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "content-pipeline/linkedin-nko-week1.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "In 1949, in the city of Kankan, Guinea, a self-taught linguist named Solomana Kante sat down and designed a writing system from scratch.", "excerpt": "In 1949, in the city of Kankan, Guinea, a self-taught linguist named Solomana Kante sat down and designed a writing system from scratch.\n\nHe was frustrated by a claim he'd read: that African languages were inherently unsuitable for writing. He spoke Manding, a family of languages used by over 40 million people across West Africa. Bambara in Mali, Maninka in Guinea, Dioula in Cote d'Ivoire. These languages had been written in Arabic script for centuries, and in Latin script since colonization. Neither was designed for them. Arabic doesn't capture Manding vowel distinctions. Latin doesn't encode its tonal system.\n\nHere's what makes N'Ko different from English, French, Arabic, or any other major writing system:\n\nEvery character maps to exactly one sound. Every sound maps to exactly one character. This is called bijective mapping. English doesn't have it (\"ough\" has six pronunciations, \"knight\" has six letters and two sounds). French doesn't have it. Arabic doesn't have it. Kante engineered it deliberately.\n\nHe also encoded tone directly into the script. In Manding, the word \"ba\" means mother, goat, or river depending on pitch. In Latin Bambara, all three look identical: \"ba.\" In N'Ko, each one is written differently using combining diacritical marks for high, low, and mid tone. The semantic information is in the text, not left for the reader to guess from context.", "htmlHref": "/research/html/linkedin-post-week-1-fwhhpg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 989 }, { "id": "the-moment-your-system-outgrows-your-memory-2dajc4", "title": "The Moment Your System Outgrows Your Memory", "slug": "the-moment-your-system-outgrows-your-memory", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "content-pipeline/linkedin/2026-02-18-consolidation.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "There's a moment in every scaling journey — personal or organizational — where the system becomes too complex for any single mind to hold.", "excerpt": "**50 projects. 4 machines. 180+ Discord channels. 25 automation plans running simultaneously.**\n\nThere's a moment in every scaling journey — personal or organizational — where the system becomes too complex for any single mind to hold.\n\nI knew what each project did. I knew how they connected. But I couldn't draw the full map from memory anymore. The relationships had become too dense.\n\n1. **Foundation** — Databases, storage, auth 2. **Delivery** — APIs, CDNs, deployments 3. **Execution** — Task runners, queues, agents 4. **Intelligence** — ML models, embeddings, inference 5. **Orchestration** — Workflows, routing, scheduling 6. **Observability** — Logs, metrics, alerts\n\nWhen your AI asks \"is this missing scope?\" and your human says \"bigger\" — that's the signal you've been building faster than you've been mapping.", "htmlHref": "/research/html/the-moment-your-system-outgrows-your-memory-2dajc4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 278 }, { "id": "training-your-own-brain-for-0-a-cognitive-twin-experiment-1i3pery", "title": "Training Your Own Brain for 0: A Cognitive Twin Experiment", "slug": "training-your-own-brain-for-0-a-cognitive-twin-experiment", "kind": "experiment", "program": "Agents That Account for Themselves", "sourceAnchor": "content-pipeline/substack/2026-02-19-chronicle-3-cognitive-twin.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "There's a peculiar kind of hubris in trying to train an AI model on yourself. Not on books, not on the internet, not on curated datasets — but on the raw, unfiltered mess of 163,000+ conversation turns between you and your AI agents.", "excerpt": "There's a peculiar kind of hubris in trying to train an AI model on yourself. Not on books, not on the internet, not on curated datasets — but on the raw, unfiltered mess of 163,000+ conversation turns between you and your AI agents.\n\nYesterday, I tried it. On a $599 Mac Mini. With no cloud credits. And 16GB of RAM to work with.\n\nBefore any training could happen, I needed to find a model that would actually *fit*. The Mac Mini isn't a data center. It's a puck-shaped computer that normally runs Adobe Photoshop and occasionally complains about thermal throttling.\n\n**Llama 3.2:3B** came out swinging at 71 tokens per second. Fast. Eager. But only 70% accurate on our evaluation set. The AI equivalent of someone who talks quickly and confidently about things they don't quite understand.\n\n**Qwen3:4B** clocked in at 29 tok/s with 60% accuracy. Its \"thinking mode\" was the problem — it would waste tokens overthinking simple questions, like a graduate student asked to summarize a children's book.", "htmlHref": "/research/html/training-your-own-brain-for-0-a-cognitive-twin-experiment-1i3pery.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 816 }, { "id": "content-studio-cron-scheduling-specification-tkna3q", "title": "Content Studio — Cron & Scheduling Specification", "slug": "content-studio-cron-scheduling-specification", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "content-studio/scripts/CRON-SPEC.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep as idea/proposal unless evidence and implementation anchors exist.", "summary": "Content Studio uses three scheduled jobs for end-to-end content lifecycle management. Jobs can be installed via system cron or Clawdbot cron (preferred for AI-native features).", "excerpt": "Content Studio uses three scheduled jobs for end-to-end content lifecycle management. Jobs can be installed via system cron or Clawdbot cron (preferred for AI-native features).\n\n| Field | Value | |-------|-------| | Schedule | `0 20 * * 0` — Every Sunday at 8 PM EST | | Script | `scripts/generate-weekly.sh` | | Duration | ~30s (harvest) + async (AI generation) | | Lock | `logs/.generate.lock` (prevents concurrent runs) |\n\n**What it does:** 1. Harvests 7 days of memory files, Chronicle moments, and git activity 2. Creates platform output directories (`output/[platform]/`) 3. Writes weekly manifest with themes and platform assignments 4. Dispatches AI content generation via Clawdbot (or writes manual flag) 5. Rotates logs older than 30 days\n\n| Field | Value | |-------|-------| | Schedule | `0 9 * * 1` — Every Monday at 9 AM EST | | Script | `scripts/collect-analytics.sh` | | Duration | ~5s |\n\n**What it does:** 1. Scans output directories for content from the past week 2. Supports both new (`output/[platform]/`) and legacy (`output/YYYY-MM-DD/`) layouts 3. Generates weekly review JSON in `analytics/weekly-reviews/` 4. Updates calendar state 5. Dispatches AI analytics review if content exists", "htmlHref": "/research/html/content-studio-cron-scheduling-specification-tkna3q.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 849 }, { "id": "content-strategy-storytelling-reels-2bpoy4", "title": "Content Strategy - Storytelling Reels", "slug": "content-strategy-storytelling-reels", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "DepthReactiveVisuals/Docs/CONTENT-STRATEGY-STORYTELLING-REELS.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- Reel: `https://www.instagram.com/reel/DWrLIoODHS4/` - Creator: `@Sammy Jones` - Date ingested: `2026-04-04` - Runtime: `52.38s`", "excerpt": "- Reel: `https://www.instagram.com/reel/DWrLIoODHS4/` - Creator: `@Sammy Jones` - Date ingested: `2026-04-04` - Runtime: `52.38s`\n\n1. **Starts with authority immediately** - \"I studied 94 storytelling style videos...\" - That line makes the viewer trust the next 40 seconds before any proof is shown.\n\n2. **Opens with a socially true but slightly aggressive diagnosis** - He calls out stale hooks and says most creators are behind. - That creates friction. People either agree instantly or stay to see if they disagree.\n\n3. **Creates an open loop without giving the payload away** - He promises \"two things\" and keeps both abstract long enough to hold curiosity.\n\n4. **Keeps the middle alive with tension, not filler** - He does not rush to the conclusion. - He expands the problem first: stale hooks, no curiosity, tension vacuum, audience drop-off.", "htmlHref": "/research/html/content-strategy-storytelling-reels-2bpoy4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1485 }, { "id": "stage-3-expand-master-plan-ai-generated-graph-topology-1t7xgfs", "title": "Stage 3: Expand + Master Plan -- AI-Generated Graph Topology", "slug": "stage-3-expand-master-plan-ai-generated-graph-topology", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/ai-generated-graph-topology/stage3-expand-master-plan.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "-- Step 1: Add updated_at column ALTER TABLE knowledge_graph ADD COLUMN IF NOT EXISTS updated_at TIMESTAMPTZ DEFAULT NOW();", "excerpt": "#### Risk 1: Confidence Decay Destroys Valuable Low-Frequency Triples - **Failure scenario**: The 3 `evolved_from` triples (accessed rarely but semantically critical) decay below threshold and disappear from default queries within 90 days. - **Probability**: HIGH (guaranteed by the decay formula if not addressed) - **Impact**: HIGH (evolutionary lineage lost) - **Mitigation**: Tier 1 predicates (including evolved_from) are EXEMPT from decay. Only Tier 2 and Tier 3 predicates decay. This is enforced in the decay SQL: `WHERE predicate NOT IN (SELECT name FROM predicate_registry WHERE tier = 1)` - **Validation**: After first decay run, verify all Tier 1 triples retain original confidence. Query: `SELECT count(*) FROM knowledge_graph WHERE predicate = 'evolved_from'` must = 3.\n\n#### Risk 2: Pruning Breaks RAG++ Retrieval Quality - **Failure scenario**: RAG++ searches that previously returned relevant results now return empty because the connecting triples were pruned. - **Probability**: MEDIUM (pruning targets low-confidence noise, but RAG++ may use noise paths as fallback when high-signal paths are sparse) - **Impact**: HIGH (RAG++ is the primary GK consumer) - **Mitigation**: Three-layer defense: 1. Soft delete (pruned_at, not DELETE) -- reversible in seconds 2. Before pruning: run a test suite of 20 known-good RAG++ queries, record results 3. After pruning: re-run the same 20 queries, compare result overlap. If <80% overlap, rollback (NULL all pruned_at values) - **Validation**: RAG++ test suite passes with >= 80% result overlap post-pruning.\n\n#### Risk 3: Entity Embedding Pipeline Produces Garbage Embeddings - **Failure scenario**: Entities with no GK predicates (e.g., bare prompt hashes like \"prompt:1069f93fdd8f24c3\") are embedded as meaningless vectors, creating noise clusters that contaminate hierarchy discovery. - **Probability**: MEDIUM (8,303 entities are prompt hashes with only contains_prompt edges) - **Impact**: MEDIUM (garbage clusters waste effort but do not corrupt good clusters) - **Mitigation**: Filter entity list BEFORE embedding. Only embed entities that: 1. Have at least 2 predicates (not counting contains_prompt, has_intent, ran_session) 2. Are not prefixed with \"session:\", \"prompt:\", or \"agent:\" unless they also have Tier 1/2 edges Expected: ~2,000-3,000 embeddable entities out of 10,781 total. - **Validation**: Embedding count < 4,000. No cluster contains >50% session/prompt entities.\n\n#### Risk 4: Cluster Labeling Produces Vague Names - **Probability**: MEDIUM - **Impact**: LOW (labels are human-readable convenience, not machine-critical) - **Mitigation**: Three-pass labeling: (1) auto-label from shared predicates, (2) Gemini for mixed clusters, (3) manual override list for top-20 clusters.\n\n#### Risk 5: Predicate Registry Cold S", "htmlHref": "/research/html/stage-3-expand-master-plan-ai-generated-graph-topology-1t7xgfs.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 3528 }, { "id": "stage-1-path-c-the-living-document-8eyguk", "title": "Stage 1, Path C: THE LIVING DOCUMENT", "slug": "stage-1-path-c-the-living-document", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/cognitive-twin-v9/stage1-path-c.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "What if the Cognitive Twin requires zero training? What if instead of fine-tuning a model to be Mo, we assemble a system prompt so comprehensive that ANY model becomes Mo for the duration of the conversation?", "excerpt": "# Stage 1, Path C: THE LIVING DOCUMENT ## Zero-Training Twin via Dynamically-Assembled System Prompt **Evolution:** Evo-Cubed | Stage 1C of 3 **Date:** 2026-03-07 **Builds on:** Stage 0 Research (RAG = 9x value, existing KB + graph infrastructure)\n\nWhat if the Cognitive Twin requires zero training? What if instead of fine-tuning a model to be Mo, we assemble a system prompt so comprehensive that ANY model becomes Mo for the duration of the conversation?\n\nThe benchmark already proves this partially: Qwen3-235B-A22B with RAG context hits 93.6% accuracy on Mo-specific questions without any fine-tuning. The remaining 6.4% gap is not a knowledge gap — it's a personality gap. The model answers correctly but doesn't sound like Mo.\n\nPath C closes the personality gap through **feedback-driven personality accumulation** — a system that learns Mo's style from corrections rather than training data.\n\n### The Key Insight: Model Portability Fine-tuned models lock you to one architecture. A dynamically-assembled prompt works with ANY model. When Qwen4 drops, the twin migrates instantly — no retraining. When Claude gets cheaper, switch. When a local model gets fast enough, run locally. The twin's identity lives in the prompt, not the weights.", "htmlHref": "/research/html/stage-1-path-c-the-living-document-8eyguk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": true, "hasMath": true, "hasFigures": true, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1270 }, { "id": "stage-0-research-flow-rl-from-grpo-to-sampo-kutxxk", "title": "Stage 0: RESEARCH -- Flow RL: From GRPO to SAMPO", "slug": "stage-0-research-flow-rl-from-grpo-to-sampo", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/flow-rl-sampo/stage0-research.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Bucket distribution: 0.3: 1 (0.9%) 0.4: 3 (2.7%) 0.5: 32 (28.8%) <-- mode 0.6: 41 (36.9%) <-- mode 0.7: 27 (24.3%) 0.8: 7 (6.3%) ```", "excerpt": "## Source - Video: code4AI \"From GRPO to SAMPO: Solving Training Collapse in Agentic RL\" (XoS5RlM2kog, score 7.5/10) - FlowRL paper: arXiv 2509.15207 (LUMIA Lab, Sep 2025) - PACED-RL paper: arXiv 2602.12642 (Feb 2026) - ARLArena/SAMPO paper: arXiv 2602.21534 (UCLA, Feb 2026) - GFlowNet Foundations: JMLR 2024, Bengio et al.\n\n### File Inventory (14 Python files, [home-path]) | File | Lines | Purpose | |------|-------|---------| | `trajectory_tap.py` | 349 | 4 tap points (A/B/C/D) wired into Claude Code hooks | | `reward_engine.py` | 428 | 3-signal composite reward (outcome 40%, process 35%, efficiency 25%) | | `embedding_cache.py` | 214 | LRU cache for 3072-dim Gemini embeddings, async embed | | `sft_exporter.py` | 323 | Advantage-weighted SFT export (OAPL-Lite oversampling) | | `karl_trainer.py` | 269 | Mac5 training orchestration (SSH/SCP, MLX LoRA trigger) | | `weight_updater.py` | 148 | EMA weight updates for skill embeddings | | `trajectory_bridge.py` | 463 | Shadow routing analysis, promotion gate, EW technique recs | | `bootstrap_skill_embeddings.py` | ~200 | Pre-compute skill vectors | | `trajectory_extractor.py` | ~200 | Historical backfill from prompt logs | | `karl_training_flow.py` | 168 | Weekly Prefect training flow (Sunday 3am) | | `karl_analysis_flow.py` | 179 | Daily Prefect analysis flow (6:30am) | | `synthetic_qa.py` | ~300 | Git-commit-based synthetic Q&A generation |\n\n### Data Inventory | File | Records | Size | |------|---------|------| | `trajectories.jsonl` | 111 | 620 KB | | `routing_shadow.jsonl` | 87 | 19 KB | | `karl-sft.jsonl` | 35 | 40 KB | | `synthetic_qa.jsonl` | 37 | 23 KB | | `skill_embeddings.pkl` | 13 skills | 360 KB | | `prompt_embedding_cache.pkl` | ~100 entries | 166 KB |\n\n### Advantage Distribution - Mean advantage: 0.1047 - Positive advantages: 104/111 (93.7%) - Negative advantages: 7/111 (6.3%) - Only 1 skill label populated (\"test\"), domains empty\n\n### Training Infrastructure - Mac5: M4 16GB, MLX LoRA on gemma-3-1b-it-4bit - Training params: 500 iters, batch 1, LoRA rank 8, 4 layers, lr 1e-5, max_seq 256 - Adapter v2: 35 SFT examples, test loss 1.843 - Fine-tune daemon on :9200 (Prometheus metrics)", "htmlHref": "/research/html/stage-0-research-flow-rl-from-grpo-to-sampo-kutxxk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1650 }, { "id": "intelligent-pane-orchestrator-stage-0-research-gyzhd1", "title": "Intelligent Pane Orchestrator -- Stage 0: Research", "slug": "intelligent-pane-orchestrator-stage-0-research", "kind": "technical note", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/intelligent-pane-orchestrator/stage0-research.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| File | Lines | Purpose | |------|-------|---------| | `pane_orchestrator_core.py` | ~945 | Config, state, notifications (Telegram/iMessage), Cortex authority check, ProjectContextCache, run_cycle, run_daemon, main loop | | `pane_orchestrator_invariants.py` | ~234 | State change detection, plateau detection, review gates, evolution candidacy, context exhaustion signals | | `pane_orchestrator_drift.py` | ~689 | Output evaluation, Gemini Flash prompt composition, 5-pattern fallback (question/steps/recommendation/com", "excerpt": "# Intelligent Pane Orchestrator -- Stage 0: Research **Run:** intelligent-pane-orchestrator **Generated:** 2026-04-04 **Method:** Evolution Cube -- four-stage recursive evoflow (research-grounded) **Run Directory:** Desktop/evo-cube-output/intelligent-pane-orchestrator/ **Lineage:** Succeeds intelligent-orchestration-v2 (2026-03-08). V2 built the 2-layer hook+daemon architecture and 7 patches. This evolution focuses on making the orchestrator *predictive* and *self-healing* rather than reactive.\n\n| File | Lines | Purpose | |------|-------|---------| | `pane_orchestrator_core.py` | ~945 | Config, state, notifications (Telegram/iMessage), Cortex authority check, ProjectContextCache, run_cycle, run_daemon, main loop | | `pane_orchestrator_invariants.py` | ~234 | State change detection, plateau detection, review gates, evolution candidacy, context exhaustion signals | | `pane_orchestrator_drift.py` | ~689 | Output evaluation, Gemini Flash prompt composition, 5-pattern fallback (question/steps/recommendation/completion/generic), injection memory | | `pane_orchestrator_sense.py` | ~927 | Context readers (CLAUDE.md, GSD, Pulse, Evolution, git, vault notes), deep context builder, 14 project-specific prompt templates, compose_prompt_for_pane | | `pane_orchestrator_loop.py` | ~100 | Thin facade re-exporting all modules + CLI (daemon/once/status/self-inject/notify) |\n\n1. **SENSE**: AppleScript pane discovery + `/tmp/pane_signals/` + `/tmp/pane_context/` + terminal content analysis (last 500 chars for shell prompts, Claude exit messages) 2. **SELECT**: Longest-idle pane + highest-priority pending backlog task 3. **MUTATE**: Inject via clipboard paste (pbcopy + keystroke \"v\" with command down) 4. **CHECK**: Bounded divergence invariant (max M injections per window) 5. **ADAPT**: Metabolism-based interval: `new_interval = MIN(30) + (MAX(300) - MIN(30)) * (working/total)`\n\n1. **Min Entropy Production**: KL divergence with Laplace smoothing. Every cycle must produce novelty > epsilon. 2. **Bounded Divergence**: Injection rate capped per window. `MAX_INJECTIONS_PER_CYCLE = 2`. 3. **Cross-Layer Forcing**: If all panes idle for N cycles, escalate (force action). 4. **No Absorbing States**: Every state must have 2+ viable transitions.\n\n| Signal | Threshold | Action | |--------|-----------|--------| | Idle | > 15 min no activity | Evaluate + compose + inject | | Stuck | > 30 min no activity | Evaluate + inject + notify (iMessage) | | Plateau | Same output hash for 6 cycles | Force approach pivot | | Review gate | 5+ commits, 0 with \"review\" | Inject /meta-review | | Evolution candidate | 30+ min stuck + no output change in 3 cycles | Pivot or skip task | | Context exhaustion | 4+ hours runtime | Handoff + fresh session |", "htmlHref": "/research/html/intelligent-pane-orchestrator-stage-0-research-gyzhd1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1874 }, { "id": "stage-0-research-brief-koatji-city-capture-playbook-32m78n", "title": "Stage 0: RESEARCH BRIEF -- Koatji City Capture Playbook", "slug": "stage-0-research-brief-koatji-city-capture-playbook", "kind": "technical note", "program": "Business Systems", "sourceAnchor": "evo-cube-output/koatji-city-capture-playbook/stage0-research.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Evo-Cubed | Research Engine Output** **Date:** 2026-03-19 **Topic:** What does it take to systematically capture a US city for a plant-based oat milk brand, city by city? **Prior Evolutions Referenced:** 4 (koatji-gtm, koatji-miami-beachhead, koatji-outreach-v3, koatji-gtm/path-c-iaas)", "excerpt": "**Evo-Cubed | Research Engine Output** **Date:** 2026-03-19 **Topic:** What does it take to systematically capture a US city for a plant-based oat milk brand, city by city? **Prior Evolutions Referenced:** 4 (koatji-gtm, koatji-miami-beachhead, koatji-outreach-v3, koatji-gtm/path-c-iaas)\n\nThe Milkmen/Koatji operation has been built across 4 prior Evo3 runs. The current state as of 2026-03-19:\n\n| Asset | State | Evidence | |-------|-------|----------| | Prospect database | 3,500+ records across 22 cities | Supabase `wovknbcvxjvayfdflxkn`, `sweep_prospects` table | | Outreach Command Center | 16 files, ~4,978 lines, 10-tab React shell | `OutreachCommandCenter.tsx`, `useOutreach.ts`, `GuidedSendPanel.tsx` etc. | | Mail Bridge | Python HTTP server, AppleScript Mail.app, GPT-5-mini classifier | `mail_bridge.py` (1,348 lines), LaunchAgent `com.koatji.mail-bridge` | | Resend Email Pipeline | 6 Edge Functions (send, batch, follow-up, tracking, unsubscribe, AI-generate) | Supabase Edge Functions on milkmen project | | Pipeline Automation | 9-phase sweep/enrich/score/email flow | `koatji_ig_pipeline.py`, 3 Supabase edge functions | | NYC Field Routes | 25 curated shops across 5 walking routes (Midtown) | `koatji-field-routes-midtown.txt` | | Warm Lists | SFL, NYC, LA CSVs (headers only -- data in Supabase) | `koatji-sofla-field-list.csv`, etc. | | Graduated Send Cadence | 10/25/50/100 per week scaling | `outreach-config.ts` | | Sequence Engine | 3-touch default, JSONB steps | `email_sequences` table, `prospect_sequence_state` | | Accounts Pipeline | potential -> high_interest -> sampled -> committed -> odeko_setup -> first_order -> reorder | `AccountsTracker.tsx` |\n\n| Metric | Count | Source | |--------|-------|--------| | Emails sent (total) | ~97 | outreach-v3 Stage 0 (campaign start 2026-03-16) | | Responses received | 15+ | outreach-v3 Stage 0 | | Response rate (where measured) | ~16% | outreach-v3 Stage 0 | | Committed accounts (hot/interested) | 7 Miami accounts | outreach-v3 Stage 0 | | Named committed accounts | Caracas Bakery (3 doors), Mane Coffee, VI Coffee Bar (sampled) | Prior evolutions | | Current daily send limit | 10/day (Week 1 cadence) | outreach-config.ts | | Pipeline stage distribution | Unknown exact, mostly potential/high_interest | AccountsTracker pipeline |\n\n| City | Prospects | HOT | WARM | Pipeline Status | |------|-----------|-----|------|-----------------| | Los Angeles | 1,833 | 0 | 0 | IG scoring in progress | | New York | 1,015 | 15 | 154 | IG complete, no Prospeo | | South Florida (aggregate) | ~500 | 134 | 175 | COMPLETE | | Fort Lauderdale | 52 | 18 | 24 | Complete | | Miami | 44 | 18 | 10 | Complete | | Doral | 45 | 11 | 15 | Complete | | Brooklyn | 37 | 0 | 0 | No ICP scoring | | Other cities (18) | ~400+ | minimal | minima", "htmlHref": "/research/html/stage-0-research-brief-koatji-city-capture-playbook-32m78n.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 2680 }, { "id": "stage-0-research-yltj4q", "title": "Stage 0: RESEARCH", "slug": "stage-0-research", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-commerce-pos/stage0-research.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Scale:** 237 Swift files total. BWBCore: 155 files, 43K+ lines, 434 tests passing. BWB_Kiosk: 25 files, 8,456 lines. BWB_POS: 20+ files.", "excerpt": "**Scale:** 237 Swift files total. BWBCore: 155 files, 43K+ lines, 434 tests passing. BWB_Kiosk: 25 files, 8,456 lines. BWB_POS: 20+ files.\n\n**Voice Pipeline (COMPLETE, production-grade):** - 10-component modular voice ordering pipeline decomposed from a 2,464-line monolith - `VoiceOrderingOrchestrator` -- thin coordinator managing state: idle -> listening -> processing -> confirming -> complete - `TranscriptPipeline` -- transcript normalization, stability tracking, session accumulation - `UtteranceCompletionDetector` -- silence/completion via stability count, order-ending phrases - `LiveOrderPreviewGenerator` -- regex-based pattern matching (~50ms latency), menu alias matching - `OrderParsingPipeline` -- HYBRID MERGE strategy: AI + NLU parsers run in parallel, results merged - `CartCoordinator` -- pending vs confirmed cart, clarification flow - `ConfirmationCoordinator` -- auto-confirm at 0.8 confidence after 3-second countdown - `FeedbackCoordinator` -- TTS (AVSpeechSynthesizer), haptics, audio cues (10 audio types, 6 haptic types) - `SessionManager` -- 120-second timeout, activity tracking, session lifecycle - `AudioCaptureController` -- wraps `SpeechAnalyzerService` (iOS 26+) and `LegacyVoiceService` (iOS 17-25)\n\n**AI Routing (COMPLETE):** - 12-component architecture decomposed from 7 monoliths (4,059 lines -> 12 focused files) - 6-factor routing: CartAvailability (25%), ComplexityMatch (20%), StaffEfficiency (20%), CustomerLocation (15%), HistoricalPattern (10%), SpaceBalance (10%) - Dynamic + Standard + Fallback routing strategies - LocationService with BLE beacon ranging, trilateration, movement analysis - DrinkComplexityAnalyzer: Simple/Medium/Complex/Premium classification\n\n**NLU Engine:** - `EnhancedVoiceNLUEngine.swift` (28K lines) -- full NLU for coffee ordering domain - `VoiceNLUEngine.swift` (33K lines) + vocabulary extension (17K lines) - `AITranscriptParser.swift` (46K lines) -- AI-powered order parsing - Fuzzy matching at 70-80% similarity threshold, Levenshtein distance with weighted penalties - Menu intelligence: handles \"large coffee\" -> \"16oz house blend\" mapping\n\n**Payment (PARTIAL, 2,937 lines across 6 files):** - `PaymentService.swift` (507 lines) -- Apple Pay + Stripe backend integration - `SquareMobilePaymentHandler.swift` (555 lines) -- Square Mobile Payments SDK (BLE reader pairing, payment flow, reader state management) - `CardPaymentHandler.swift` (347 lines) - `SquareInAppPaymentHandler.swift` (559 lines) - `SquarePaymentTypes.swift` (453 lines) -- full type system for Square integration - `PaymentTypes.swift` (516 lines) - Status: Apple Pay works. Square SDK integrated with `#if canImport(SquareMobilePaymentsSDK)` guards. Stripe PaymentIntent creation via Supabase Edge Functions. Card payment without Apple Pay requires ", "htmlHref": "/research/html/stage-0-research-yltj4q.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 2276 }, { "id": "stage-2-compound-4wxm24", "title": "Stage 2: COMPOUND", "slug": "stage-2-compound", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "evo-cube-output/lume-commerce-pos/stage2-compound.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| Path | Core Insight | Adopt | Reject | |------|-------------|-------|--------| | A: Full Local | Zero-cloud voice ordering on Jetson is architecturally clean | Queue analytics via depth centroid tracking, Piper TTS, cart state machine port | GPU contention risk, LLM-for-NLU overkill, memory pressure | | B: Companion iPad | 100% BWB code reuse, zero technical risk | V0.5 pilot strategy, WebSocket relay between LUME and companion device | Two-device proposition permanently (acceptable for V0.5, not V1) | | C: Cloud", "excerpt": "| Path | Core Insight | Adopt | Reject | |------|-------------|-------|--------| | A: Full Local | Zero-cloud voice ordering on Jetson is architecturally clean | Queue analytics via depth centroid tracking, Piper TTS, cart state machine port | GPU contention risk, LLM-for-NLU overkill, memory pressure | | B: Companion iPad | 100% BWB code reuse, zero technical risk | V0.5 pilot strategy, WebSocket relay between LUME and companion device | Two-device proposition permanently (acceptable for V0.5, not V1) | | C: Cloud STT | Best accuracy in noisy environments, zero GPU impact | Cloud STT as primary with local Whisper fallback, BWB NLU patterns as domain expert | Single WiFi dependency without fallback | | D: Entertainment-First | The queue IS the product, order overlay in visual experience | Entertainment-first positioning, order confirmation integrated into visuals, $99 Venue tier | Weak standalone commerce, dependency on external POS for payment | | E: Multi-Vertical | Platform with swappable vocabularies and zone definitions | Plugin architecture designed in, extension points for future verticals | Multi-vertical GTM now (one beachhead first) | | F: Analytics-as-Service | Depth analytics is a proven $2.1B market, privacy-by-design | Analytics as enterprise selling surface, GDPR/CCPA-compliant depth-only sensing | Analytics alone doesn't justify $1,299, must demo entertainment |\n\n## Compound Step 1: ESTABLISH GROUND TRUTH (The Product Identity) *Starting from scratch. No inheritance.*\n\nLUME Commerce is NOT a POS system with visual effects. It is NOT an analytics sensor with a pretty display. It is an **experiential commerce platform** where the entertainment experience IS the commercial engine.\n\n1. **ENTERTAINMENT** (what draws them in): Depth-reactive visuals that make the queue magical. Customers interact with fluid light while waiting. Auto-captured content clips make every visit shareable. This is what the shop owner sees in the demo and says \"I want that.\"\n\n2. **INTELLIGENCE** (what keeps them paying): Privacy-preserving depth analytics that count bodies, measure wait times, track zones, and predict rush hours. The shop owner logs into a dashboard and sees data they've never had before. This justifies the monthly subscription after the novelty fades.", "htmlHref": "/research/html/stage-2-compound-4wxm24.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 4419 }, { "id": "stage-0-research-brief-hhnb7d", "title": "STAGE 0: RESEARCH BRIEF", "slug": "stage-0-research-brief", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/spore-acmp-anchor/stage0-research.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "| # | Gap | Impact | |---|-----|--------| | G1 | `app_entities` table not created in Supabase | Cannot register Spore or any app | | G2 | No `app_entity` row for Spore | Autonomy loop has no target | | G3 | RevenueCat not configured | No revenue data flows at all | | G4 | No \"Build This\" harvest option in Spore app | Users cannot trigger app generation | | G5 | No Edge Function to generate structured app specs | Evolved spores cannot become app blueprints | | G6 | Bootstrap script not triggered from pipeline | Even", "excerpt": "# STAGE 0: RESEARCH BRIEF ## Spore as ACMP Anchor App: Idea-to-App Pipeline End-to-End > Date: 2026-03-14 | Agent: Evo-Cubed Runner (Opus 4.6)\n\n### 1.1 Spore iOS App (53 Swift files) - **Version**: v1.2.0, submitted for App Store review - **Data model**: Spore -> Garden -> Season. Status lifecycle: spore -> germinating -> growing -> budding -> blooming -> fruiting -> composted (withering branch for neglect) - **Growth algorithm**: `strengthDelta = baseGrowth * seasonMultiplier + tendrilBonus + guidanceBonus + wateringBonus` - **Evolution tiers**: Tier 1 (on-device NLEmbedding, <200ms), Tier 2 (edge function + KARL + Gemini, 1-3s), Tier 3 (daemon-driven overnight, passive) - **Services**: GrowthEngine, EvolutionEngine, TierBroker, IntelligenceClient, BehaviorTracker, TopicClassifier, InvariantGuard, RealtimeSync, CloudKitManager, StoreManager, HapticManager, NotificationManager - **StoreKit 2**: Free (5 spores), Sprout (20 spores, weekly evolution), Garden (unlimited, daily evolution) - **Harvest actions**: Add notes, export to Notes, create Reminder, share, copy, keep growing, compost. **NO \"Build This\" option exists.** - **Landing page**: tryspore.app with Supabase email capture, social links\n\n### 1.2 Supabase Edge Functions (6) | Function | Purpose | Status | |----------|---------|--------| | `evolve-spore` | Original v1 evolution (random technique) | Working | | `spore-evolve-v2` | KARL-powered Tier 2 (Thompson/softmax technique selection + Gemini) | Working | | `spore-plant` | Generate 768-dim embedding on plant, UPSERT to spore_embeddings | Working | | `spore-feedback` | Batch behavioral event ingestion | Working | | `evolve-idea` | Landing page interactive idea generator (3 divergent branches) | Working | | `send-welcome` | Welcome email on signup | Working |\n\n### 1.3 Backend Intelligence (cloud-vm) - **spore_evolution_daemon.py** (1,245 lines): FAST loop 15min (SENSE + SCORE + LEARN + GK REGISTER), DEEP loop 60min (+ EVOLVE Tier 3) - **spore_reward_engine.py**: 5-signal reward (Engagement 30%, Retention 25%, Novelty 20%, Anti-neglect 15%, Bloom 10%) - **garden_tender.py**: Bloom events -> Discord notification - **12 TIE techniques**: 6 generative (G01, G04, G07, G10, G15, G18), 6 reductive (R01, R04, R07, R10, R14, R18) - **Key architectural constraint from prior Evo3**: Edge functions CANNOT reach cloud-vm services (Tailscale, GK, RAG++). Edge functions stay THIN (Supabase + Gemini only). GK registration is ASYNC via daemon.\n\n### 1.4 Supabase Tables (Spore-specific) | Table | Purpose | |-------|---------| | `spore_embeddings` | pgvector 768-dim embeddings per spore | | `spore_evolutions` | Evolution history (tier, technique, keywords before/after) | | `spore_trajectories` | KARL trajectories (technique, rewards, advantage) | | `spore_techniqu", "htmlHref": "/research/html/stage-0-research-brief-hhnb7d.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 1640 }, { "id": "stage-0-research-brief-feed-hub-flow-architecture-16r5sg4", "title": "Stage 0: Research Brief — Feed-Hub Flow Architecture", "slug": "stage-0-research-brief-feed-hub-flow-architecture", "kind": "architecture", "program": "Agents That Account for Themselves", "sourceAnchor": "evo-cube-output/stage0-research-brief.md", "extension": "md", "score": 18, "readiness": "technical paper candidate", "nextAction": "Promote into a technical note or architecture paper with implementation anchors.", "summary": "**Generated:** 2026-03-07 **Method:** Evolution³ Stage 0 — Pure Fact-Gathering **Topic:** Feed-Hub flow architecture evolution", "excerpt": "**Generated:** 2026-03-07 **Method:** Evolution³ Stage 0 — Pure Fact-Gathering **Topic:** Feed-Hub flow architecture evolution\n\n### Scale - **71 Python files**, 28,134 lines of code - **64 Prefect flows**, 7 standalone scripts/libs - **35 deployments** via single `serve()` call in `deploy_feed_flows.py` - **29 Supabase tables** accessed across all flows - **5 embedded Prometheus servers** (:9122, :9125, :9126, :9127, :9128)\n\n### Flow Domains (8 groups) | Domain | Flows | Lines | |--------|-------|-------| | Infrastructure/Monitoring | 12 | ~5,500 | | Serenity Soother (ss_*) | 19 | ~6,200 | | Memory/Knowledge | 6 | ~2,700 | | Noosphere/Dream/Creative | 9 | ~2,500 | | Intelligence/Analysis | 6 | ~3,400 | | Operational/Reporting | 6 | ~1,800 | | Design Pipeline | 4 | ~1,300 | | FirstDate App | 2 | ~520 | | Shared libs + CLI tools | 7 | ~2,900 |\n\n### Deployment Architecture - **Mac1**: Primary host, runs Prefect via LaunchAgent - **Cloud VM**: Prefect server at :4200 (systemd service), but **broken** — `cross_pollination_crawler.py` crashes import chain - **Mac5**: Only `command_executor.py` (polls Supabase `command_queue`) - **Scheduling**: 2min→monthly range. 35 Prefect deployments, all `serve()` pattern (single process)\n\n### External Dependencies (12+ services) Supabase (primary), Discord webhooks (9 channels), Gemini API, Prefect, Apify, Prometheus, YouTube API/Analytics, NUMU FARE (:8500), Noosphere MCP, EvoFlow TIE, GCS, Orbit, ab-browser", "htmlHref": "/research/html/stage-0-research-brief-feed-hub-flow-architecture-16r5sg4.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": true }, "wordCount": 839 }, { "id": "karl-trajectory-intelligence-report-1b3yrf3", "title": "KARL Trajectory Intelligence Report", "slug": "karl-trajectory-intelligence-report", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "factory/karl-report/report.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "| Signal | Mean | Median | Std | Min | Max | P25 | P75 | |--------|------|--------|-----|-----|-----|-----|-----| | Reward | 0.5579 | 0.5480 | 0.0428 | 0.4902 | 0.6925 | 0.5225 | 0.5907 | | Outcome | 0.7000 | 0.7000 | 0.0000 | 0.7000 | 0.7000 | 0.7000 | 0.7000 | | Process | 0.8910 | 0.8600 | 0.0791 | 0.8000 | 1.0000 | 0.8200 | 1.0000 | | Efficiency | 0.5534 | 0.5000 | 0.1365 | 0.4000 | 1.0000 | 0.5000 | 0.6000 |", "excerpt": "| Signal | Mean | Median | Std | Min | Max | P25 | P75 | |--------|------|--------|-----|-----|-----|-----|-----| | Reward | 0.5579 | 0.5480 | 0.0428 | 0.4902 | 0.6925 | 0.5225 | 0.5907 | | Outcome | 0.7000 | 0.7000 | 0.0000 | 0.7000 | 0.7000 | 0.7000 | 0.7000 | | Process | 0.8910 | 0.8600 | 0.0791 | 0.8000 | 1.0000 | 0.8200 | 1.0000 | | Efficiency | 0.5534 | 0.5000 | 0.1365 | 0.4000 | 1.0000 | 0.5000 | 0.6000 |\n\n| Domain | N | Mean Reward | Median | Std | Min | Max | |--------|---|-------------|--------|-----|-----|-----| | mohameddiomande | 1087 | 0.5574 | 0.5475 | 0.0413 | 0.4905 | 0.6925 | | unknown | 950 | 0.5538 | 0.5474 | 0.0411 | 0.4902 | 0.6925 | | MotionMix | 305 | 0.5700 | 0.5616 | 0.0440 | 0.4926 | 0.6834 | | Spore | 156 | 0.5568 | 0.5411 | 0.0444 | 0.4943 | 0.6707 | | MeshControl | 128 | 0.5749 | 0.5817 | 0.0461 | 0.4905 | 0.6726 | | anticipation-geometry | 90 | 0.5518 | 0.5442 | 0.0349 | 0.4932 | 0.6537 | | nko-brain-scanner | 77 | 0.5652 | 0.5537 | 0.0505 | 0.4917 | 0.6793 | | Comp-Core | 65 | 0.5390 | 0.5264 | 0.0347 | 0.4936 | 0.6525 | | learnnko | 52 | 0.5248 | 0.5213 | 0.0160 | 0.4946 | 0.5617 | | cadenza-events | 39 | 0.5869 | 0.5936 | 0.0578 | 0.4935 | 0.6718 | | milkmendelivery | 35 | 0.5685 | 0.5736 | 0.0518 | 0.4926 | 0.6719 | | speakd | 29 | 0.5600 | 0.5502 | 0.0468 | 0.4909 | 0.6342 | | Milk Men | 24 | 0.5431 | 0.5383 | 0.0305 | 0.4931 | 0.6170 | | coltivare-web | 16 | 0.5893 | 0.5868 | 0.0386 | 0.5225 | 0.6388 | | FirstDate | 15 | 0.5477 | 0.5434 | 0.0315 | 0.5074 | 0.6075 | | BWB_Kiosk | 14 | 0.5509 | 0.5382 | 0.0479 | 0.4911 | 0.6319 | | BWB | 13 | 0.5813 | 0.5602 | 0.0589 | 0.5151 | 0.6700 | | firstdate-mega | 11 | 0.5725 | 0.5635 | 0.0410 | 0.5189 | 0.6486 | | thunder-train | 11 | 0.5577 | 0.5710 | 0.0421 | 0.4987 | 0.6325 | | LifeOS | 11 | 0.5697 | 0.5702 | 0.0408 | 0.4958 | 0.6161 | | sandbox | 8 | 0.5618 | 0.5530 | 0.0623 | 0.4928 | 0.6549 | | stacks-appchain | 6 | 0.5388 | 0.5404 | 0.0213 | 0.5152 | 0.5671 | | parameter-golf | 6 | 0.5441 | 0.5379 | 0.0266 | 0.5219 | 0.5928 | | SpeakFlow | 5 | 0.5658 | 0.5501 | 0.0413 | 0.5154 | 0.6204 | | mega-frontend | 4 | 0.5495 | 0.5454 | 0.0488 | 0.4968 | 0.6103 | | live-knowledge-graphs | 4 | 0.5189 | 0.5173 | 0.0201 | 0.5015 | 0.5396 | | Pith | 4 | 0.5428 | 0.5390 | 0.0395 | 0.5007 | 0.5925 | | computational-choreography | 4 | 0.5342 | 0.5355 | 0.0145 | 0.5175 | 0.5481 | | Meaning Full Power | 4 | 0.5182 | 0.5169 | 0.0035 | 0.5158 | 0.5233 | | karl | 2 | 0.5276 | 0.5276 | 0.0168 | 0.5157 | 0.5395 | | landing | 2 | 0.6315 | 0.6315 | 0.0021 | 0.6300 | 0.6330 | | agent-a2a5c87f | 2 | 0.5367 | 0.5367 | 0.0143 | 0.5266 | 0.5468 | | Stack | 2 | 0.5884 | 0.5884 | 0.1167 | 0.5058 | 0.6709 | | dream-weaver-engine | 2 | 0.5510 | 0.5510 | 0.0069 | 0.5461 | 0.5558 | | diomande-automation", "htmlHref": "/research/html/karl-trajectory-intelligence-report-1b3yrf3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 2164 }, { "id": "dream-idea-vault-bridge-1f0tqju", "title": "Dream → Idea Vault Bridge", "slug": "dream-idea-vault-bridge", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/dream-idea-bridge/SKILL.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This bridge connects the **Dream Weaver** incubation system to the **CC-Idea-Vault** research management system, creating a unified pipeline from fuzzy idea to verified knowledge.", "excerpt": "--- name: dream-idea-bridge description: Bridge connecting Dream Weaver bloomed dreams to CC-Idea-Vault for research tracking homepage: https://github.com/diomandeee/clawdbot user-invocable: true command-dispatch: bridge-dreams metadata.clawdbot: {\"requires_orbit\": false, \"background_capable\": true, \"pulse_integration\": true} ---\n\n> _\"When dreams bloom, they become research. When research matures, they become claims.\"_\n\nThis bridge connects the **Dream Weaver** incubation system to the **CC-Idea-Vault** research management system, creating a unified pipeline from fuzzy idea to verified knowledge.\n\n| Command | Description | |---------|-------------| | `/bridge-dreams` | Sync all bloomed dreams to Idea Vault | | `/bridge-dreams --dry-run` | Preview what would be synced | | `/bridge-dreams --force` | Re-sync already bridged dreams | | `/bridge-dreams ` | Bridge a specific dream | | `/bridge status` | Show bridge statistics |\n\n| Dream Field | Idea Field | Transformation | |-------------|------------|----------------| | `spore` | `text` | Direct copy | | `status` | `status` | blooming→inbox, fruiting→workbench | | `keywords` | `tags` | Array copy | | `synthesis` | `notes` | Full synthesis text | | `current_strength` | `confidence` | Direct (0-1) | | `journal` | `history` | Event log |", "htmlHref": "/research/html/dream-idea-vault-bridge-1f0tqju.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 539 }, { "id": "model-router-multi-model-orchestrator-nrvdxu", "title": "Model Router — Multi-Model Orchestrator", "slug": "model-router-multi-model-orchestrator", "kind": "proposal", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/model-router/SKILL.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "``` User Goal → OpenAI (gpt-4o) decomposes → Task Plan → builder tasks → Claude (Opus) via Clawdbot → research tasks → OpenAI (gpt-4o) scout → review tasks → Claude (Opus) critic → summaries → Claude (Sonnet) ```", "excerpt": "--- name: model-router description: Multi-model orchestrator — OpenAI architects plans, Claude builds, with intelligent task routing triggers: - orchestrate - route - decompose - plan task - multi-model ---\n\nRoute tasks between OpenAI (architect/planner) and Claude (builder/implementer) for optimal execution.\n\n| Agent | Role | Provider | Models | |-------|------|----------|--------| | architect | Planner/Decomposer | OpenAI | gpt-4o, o1 | | builder | Implementer | Claude | opus, sonnet | | scout | Researcher | OpenAI | gpt-4o, gemini-flash | | critic | Code Reviewer | Claude | opus | | summary | Synthesizer | Claude | sonnet |\n\n| Pipeline | Agents | Strategy | |----------|--------|----------| | build | architect → builder → critic | Sequential | | research | scout → summary | Sequential | | full | architect → scout → builder → critic → summary | Sequential | | quick | builder | Single | | plan_only | architect | Single |\n\n- `decompose` — Send a goal to OpenAI for task decomposition - `route_task` — Analyze a task and route to optimal agent - `dispatch` — Send a task to Clawdbot for Claude execution - `orchestrate` — Full pipeline: decompose → route → dispatch - `list_agents` — Show all agent profiles and pipelines - `pending_tasks` — List tasks ready for dispatch - `status` — Orchestrator status overview", "htmlHref": "/research/html/model-router-multi-model-orchestrator-nrvdxu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 404 }, { "id": "pulse-v3-autonomous-development-platform-1lrn5ps", "title": "Pulse v3 — Autonomous Development Platform", "slug": "pulse-v3-autonomous-development-platform", "kind": "research note", "program": "Agents That Account for Themselves", "sourceAnchor": "homelab/clawdbot/skills/pulse-v3/SKILL.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "Pulse v3 is a production-grade platform for autonomous AI-driven development. It extends Pulse v2 with advanced features for enterprise use:", "excerpt": "--- name: pulse-v3 description: Production-grade autonomous development platform with chains, quality gates, checkpoints, learning, and multi-channel deployment homepage: https://github.com/clawdbot/pulse-v3 user-invocable: true command-dispatch: pulse metadata.clawdbot: {\"governance\": true, \"mcp_aware\": true, \"version\": \"3.0.0\"} ---\n\nPulse v3 is a production-grade platform for autonomous AI-driven development. It extends Pulse v2 with advanced features for enterprise use:\n\n- **🔗 Chains** — Multi-step workflows with dependencies - **⚡ Parallel Execution** — Run sessions concurrently - **✅ Quality Gates** — TypeScript, ESLint, tests, builds - **💾 Checkpoints** — Auto-save and resume from any point - **🔄 Rollback** — Automatic rollback on failure - **📊 Cost Tracking** — Budget limits and usage monitoring - **🧠 Learning** — Pattern recognition and improvement suggestions - **🚀 Deployment** — Vercel, TestFlight, GitHub Releases - **📱 Notifications** — iMessage, Discord, Slack support\n\nBuilt-in gates: - `typescript` — Type checking - `eslint` — Code quality - `jest` / `vitest` — Unit tests - `build` — Production build - `expo-typecheck` — Expo TypeScript - `nextjs-build` — Next.js build - `swift-build` — Swift compilation\n\nAvailable templates: - `expo-feature` — Add feature to Expo app - `ios-feature` — Add feature to iOS app - `nextjs-page` — Add page to Next.js app - `api-endpoint` — Create CRUD API endpoints - `full-parity` — Port features between platforms - `bug-fix` — Fix bugs with test coverage - `refactor` — Refactor with safety - `documentation` — Create/update docs", "htmlHref": "/research/html/pulse-v3-autonomous-development-platform-1lrn5ps.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1122 }, { "id": "web-fluid-lab-7uzgc1", "title": "Web Fluid Lab", "slug": "web-fluid-lab", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "LUME-CC/05-output-paths/web-fluid-lab.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The web fluid lab is the visual sketchbook. It runs in the browser using Three.js and allows faster iteration on visual grammar than Unity.", "excerpt": "The web fluid lab is the visual sketchbook. It runs in the browser using Three.js and allows faster iteration on visual grammar than Unity.\n\nIt is not a replacement for Unity DYK. It is a place to discover what the body can do to light, fluid, and color — before committing those ideas to the main performance pipeline.\n\n- Three.js scene with body-mask emitters - Fluid simulation or advection-based particle fields - Color field driven by BodyTruth and movement primitives - Multiple visual modes, switchable live - Body segmentation from Femto/Mega mask - Mocopi-derived motion values feeding effect parameters\n\nThe web lab connects to the same BodyTruth / motion data that Unity consumes. When BodyTruth says the body is present and wave = 0.7, both Unity and the browser receive the same signal. The visual output is different; the input is the same.\n\nMode D tries to make the real body feel dimensional, strange, and embodied without leaning on fake skeletons.", "htmlHref": "/research/html/web-fluid-lab-7uzgc1.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 709 }, { "id": "lume-commerce-operations-guide-gvvx1g", "title": "LUME Commerce Operations Guide", "slug": "lume-commerce-operations-guide", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/docs/OPERATIONS.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "- LUME device (depth camera + mic array + HDMI out) - Power supply (USB-C PD, 45W minimum) - HDMI cable to venue display (TV, monitor, or projector) - WiFi connection (2.4GHz or 5GHz, minimum 10 Mbps) - Optional: Ethernet adapter for wired connection", "excerpt": "- LUME device (depth camera + mic array + HDMI out) - Power supply (USB-C PD, 45W minimum) - HDMI cable to venue display (TV, monitor, or projector) - WiFi connection (2.4GHz or 5GHz, minimum 10 Mbps) - Optional: Ethernet adapter for wired connection\n\n1. Mount the LUME device at counter height, facing the queue area 2. The depth camera should have a clear view of the ordering zone (2-5 meters range) 3. Connect the power supply via USB-C 4. Connect HDMI to the venue display 5. The display should face customers, not the barista 6. Position the mic array facing the ordering position (within 2 meters of where customers stand)\n\n1. Connect to venue WiFi via the companion app 2. The device will broadcast its local IP on the display during first boot 3. Access the dashboard at `http://:9600/dashboard` 4. Verify connection status shows green in the dashboard header\n\nFollow the format in `src/nlu/vocabulary.json`. Each item needs: - `id`: unique identifier - `name`: display name - `price`: numeric price - `category`: one of `espresso`, `latte`, `coffee`, `cold_brew`, `tea`, `specialty`, `food`, `seasonal` - `aliases`: list of voice aliases (how customers might say it)\n\nBounds are normalized 0-1 coordinates: [x_min, y_min, x_max, y_max]. Use the heatmap at `/analytics/heatmap` to verify zones match your layout.", "htmlHref": "/research/html/lume-commerce-operations-guide-gvvx1g.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1110 }, { "id": "orca-slicing-checklist-lume-v1-1icy6sk", "title": "Orca Slicing Checklist — LUME v1", "slug": "orca-slicing-checklist-lume-v1", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/print/slicing-checklist.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Stale slicing checklist, 2026-04-30: this references the old `exports/` part set and Jetson-era internals. Use `../PRINT_APPROVAL_QUEUE_CURRENT.md` and rebuild from `../exports/approval-v2/` or `../exports/approval-symmetric/`.", "excerpt": "> Stale slicing checklist, 2026-04-30: this references the old `exports/` part set and Jetson-era internals. Use `../PRINT_APPROVAL_QUEUE_CURRENT.md` and rebuild from `../exports/approval-v2/` or `../exports/approval-symmetric/`.\n\nPer-part GUI walkthrough for OrcaSlicer (macOS). All parts already verified: all 10 `internal_*.stl`, 4 shell halves, 4 coupons present in `hardware/cad/exports/`.\n\n- **Printer**: Elegoo Neptune 4 Max (420×420×480, X cap 420 mm) - **Filament**: ASA grey, 240 °C nozzle, 100 °C bed - **Profile**: `0.20mm Standard` - **Walls**: 4 - **Top/Bottom**: 5 / 5 - **Infill**: 25 % gyroid - **Supports**: see per-part column - **Brim**: 5 mm on shells (warp control) - **Cooling**: ASA defaults (low; layer time ≥ 12 s) - **Z-seam**: aligned, rear-facing for shells - **First-layer flow**: 100 %, line width 0.45\n\n## Order — runs sequentially. Coupons first; do not start shells until splice fit verifies.\n\n| # | 3MF | Parts | Layout hint | Supports | ETA | Gate | |---|-----|-------|-------------|----------|-----|------| | 1 | `01_coupons.3mf` | coupon_grooves, coupon_splice_pegs, coupon_splice_pockets, coupon_tongues | 2×2 grid centered | none | 2 h | hand-fit pegs into pockets after print | | 2 | `02_internals_batch.3mf` | all 9 `internal_*.stl` (jetson_sled retired 2026-04-26 — K11 lives in pod) | auto-arrange; verify no clip | tree, only on overhangs >55° | 5 h | check internal_femto_mount snap-fit; pod_compute_sled prints separately on plate 07 | | 3 | `03_shell_front_L.3mf` | shell_front_L.stl | flat, femto bay up, X≤330 | tree on; paint-supports under wordmark recess | 10 h | verify splice tongues fit coupon_grooves | | 4 | `04_shell_front_R.3mf` | shell_front_R.stl | flat, cam_right facing up | tree on | 5 h | dry-fit against L half | | 5 | `05_shell_rear_L.3mf` | shell_rear_L.stl | VESA face down, ports up | tree on; bridges over grille | 10 h | check ESD pad clearance | | 6 | `06_shell_rear_R.3mf` | shell_rear_R.stl | flat, port cluster up | tree on | 5 h | dry-fit; full assembly check |", "htmlHref": "/research/html/orca-slicing-checklist-lume-v1-1icy6sk.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 569 }, { "id": "lume-wood-enclosure-fabrication-spec-nair0", "title": "LUME Wood Enclosure Fabrication Spec", "slug": "lume-wood-enclosure-fabrication-spec", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/cad/wood/LUME_WOOD_ENCLOSURE_SPEC.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This replaces the large 3D-printed outer shell and pod for the next physical prototype. Keep the CAD as the source of truth for the original Mega/Arducam placement, but build the body as a serviceable wood T-form enclosure with an internal two-shelf depth-sensor stack and a real 80 mm top-exhaust fan.", "excerpt": "Date: 2026-05-11 Status: wood prototype spec, updated for stacked Femto Mega + Femto Bolt + NF-A8 pod fan.\n\nThis replaces the large 3D-printed outer shell and pod for the next physical prototype. Keep the CAD as the source of truth for the original Mega/Arducam placement, but build the body as a serviceable wood T-form enclosure with an internal two-shelf depth-sensor stack and a real 80 mm top-exhaust fan.\n\n- Source: `../lume-wood-v2-printables.scad` - STL exports: `../exports/wood-v2/` - OrcaSlicer projects: `../print/3mf-current/wood-v2/` - Print queue: `../print/WOOD_V2_PRINT_QUEUE.md`\n\nThe wood route does not need the printed shell halves or printed pod halves unless we decide to return to the ASA enclosure later.\n\n- `femto_mount.stl` - `arducam_mount.stl` x 2 - `cable_backbone.stl` - `pod_compute_sled.stl`", "htmlHref": "/research/html/lume-wood-enclosure-fabrication-spec-nair0.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2830 }, { "id": "dimensional-audit-lume-v2-components-1st829y", "title": "Dimensional audit — LUME v2 components", "slug": "dimensional-audit-lume-v2-components", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/design/v2-twin-sensor/DIMENSIONAL-AUDIT.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "_Every dimension I've cited in the session, re-verified. Confidence level flagged on each. ⭐ = verified against authoritative source (manufacturer spec sheet, official STEP file, physical measurement). 🟡 = quoted from memory or estimate, needs verification. ❌ = known wrong or contradicted._", "excerpt": "_Every dimension I've cited in the session, re-verified. Confidence level flagged on each. ⭐ = verified against authoritative source (manufacturer spec sheet, official STEP file, physical measurement). 🟡 = quoted from memory or estimate, needs verification. ❌ = known wrong or contradicted._\n\n| Dim | Value | Source | Confidence | |-----|-------|--------|------------| | Width (X) | 127 mm | `lume-config.scad` FEMTO_W=127, plus official Orbbec STEP imported in `lume-components.scad` (USE_REAL_FEMTO=true) | ⭐ | | Depth (Y) | 65 mm | FEMTO_D=65, STEP-verified bbox X[-0.6,114.6] = 115mm narrow axis but the cited 65mm is the front-face short dim | 🟡 — need to recheck which axis is depth | | Height (Z) | 38 mm | FEMTO_H=38, STEP bbox Z[-39.6,0.6] = 40mm | ⭐ rounded | | Rear hump (Jetson Nano) | +25 mm | Memory file `lume-v1-femto-bolt-vs-mega-decision.md`. Nano carrier sticks back beyond main 65mm body | 🟡 — measure on physical Mac4 unit | | Mount pattern | 100×30 (X×Z) | `lume-config.scad` FEMTO_MOUNT_PITCH_X=100, FEMTO_MOUNT_PITCH_Z=30 | ⭐ | | Cable | RJ45 (PoE) + barrel | Official Orbbec spec | ⭐ | | Mic array | UMA-7 onboard | Orbbec spec | ⭐ but obsoleted by LUMF audio sidecar |\n\n**Y-axis ambiguity:** The STEP bbox shows X[-0.6,114.6] meaning the Mega is ~115mm along its NATURAL X-axis as exported. The 127mm/65mm/38mm we use in SCAD may have been swapped — Orbbec specs the Mega as 105×80×35mm in some data sheets. **Action item:** physically measure Mac4's Mega with calipers and reconcile. Until then, treat 127×65×38 as a 5-15% over-estimate which is conservative for cradle clearance.\n\n| Dim | Value | Source | Confidence | |-----|-------|--------|------------| | Width (X) | 140 mm | Memory `lume-v1-femto-bolt-vs-mega-decision.md` | 🟡 — verify on arrival | | Depth (Y) | 39 mm | Same memory | 🟡 | | Height (Z) | 30 mm | Same memory | 🟡 | | Mount pattern | TBD | Not in any committed file | ❌ — unknown | | Cable | USB-C only (bus power + data) | Orbbec product page | ⭐ | | Mic array | None | Orbbec product page | ⭐ | | Mass | TBD (probably <250g) | Not specced | 🟡 |\n\n**Action item:** when Bolt arrives, capture official STEP from Orbbec's hardware repo (github.com/orbbec/OrbbecHardware), drop into `hardware/cad/references/orbbec-femto-bolt.stp`, measure with calipers to cross-check.", "htmlHref": "/research/html/dimensional-audit-lume-v2-components-1st829y.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1385 }, { "id": "two-sensor-topology-modes-110wber", "title": "Two-sensor topology modes", "slug": "two-sensor-topology-modes", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/design/v2-twin-sensor/TOPOLOGY-MODES.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "_Five distinct ways to deploy a Mega + Bolt pair. Ranked by recommendation, with CAD impact, software impact, calibration effort, BOM cost per unit shipped, and aesthetic readout._", "excerpt": "_Five distinct ways to deploy a Mega + Bolt pair. Ranked by recommendation, with CAD impact, software impact, calibration effort, BOM cost per unit shipped, and aesthetic readout._\n\n**TL;DR — recommended primary path. Two complete bars, identical except for the front camera module. Mega-bar stays as Mac4 dev rig. Bolt-bar becomes the production-aesthetic flagship.**\n\n### Geometry - Bar 1 (Mega): existing 500×120×85mm bar with current Mega cradle. Pod attached. K11 in pod. Wall-mount via pod VESA. - Bar 2 (Bolt): NEW slim bar at 500×120×60mm. Bolt cradle redesigned for 39mm depth + USB-C only. Pod attached. K11 in pod. Wall-mount via pod VESA.\n\n### CAD impact - Net new Bolt-cradle module in `lume-shell.scad`. About 60 lines of SCAD. - New `lume-config-bolt.scad` overriding LUME_DEPTH=60, FEMTO_W=140 etc. - Bolt-bar shell halves regenerate at smaller dims (300×30×120, 200×30×120). - Pod stays identical between the two bars (K11 same, dims same). - **Estimated effort:** 1 day SCAD + half-day STL regen + half-day reslice in OrcaSlicer.\n\n### Software impact - **Zero.** Both bars run the same wire format, same Unity components, same software. Two LUME bars = two unrelated installations from the software's perspective. Each has its own Mac running Unity, its own publisher, its own audio sidecar, its own user.", "htmlHref": "/research/html/two-sensor-topology-modes-110wber.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1623 }, { "id": "e490-duncan-fewkes-reel-analysis-digest-2by1wg", "title": "E490 — Duncan Fewkes reel analysis digest", "slug": "e490-duncan-fewkes-reel-analysis-digest", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-commerce/hardware/reference/duncan/analyses/E490-noreel.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, D", "excerpt": "⚠ No video on disk for this reel — referenced by the playbook but not in the local ingest cache.\n\nThis file aggregates every playbook chunk section that cites E490. Sections are de-duplicated by heading.\n\n- 20 reels ingested (`reels-ingest/{shortcode}/`): - DT-prefix (E500–E521 era): DT0G7SyCtGg E519, DT2tfJzip8A E520, DT6IlEfig-k E521, DTbJvnKCrHO E509, DTBUJiDCvPQ E500, DTEEQNnCvHh E501, DThrF5Miq0- E512, DTmyro9CqUa E514, DTQRPBFiu2v E504, DTr5TQfCpG4 E516 - DS-prefix (E475–E494 era): DSLMOE6iuFH E479, DSA7b7MClVf E475, DScEatyilnk E489, DSDVSJ0itoN E476, DSfZYMUChIi E490, DShj9nlivqf E491, DSkpKC_iie8 E491, DSPfEuWCmTg E483, DSvasHCCiSX E494, DSZmIhOCrTv E488 - 4 Gemini visual analyses successful (DT0G7SyCtGg, DT6IlEfig-k, DTBUJiDCvPQ, DScEatyilnk). DSfZYMUChIi + DSZmIhOCrTv hit Gemini 429 quota exhaustion; captions on those are still detailed.\n\nMid-period work is dominated by **Audio Particle Clones** (E483→E491) — beat-snapshot human silhouette as particle clouds layered with live depth visuals. This is the direct ancestor of the recent \"Sunset Clone Plane\" (E605) and \"Motion Sparks 4\" (E579) work. Three things are clearer here than in the recent reels:\n\n1. **Snapshot timing is a published failure mode.** E491 (DSkpKC_iie8): \"needs a response time/curve adding so that snapshot pose/shape holds for a bit longer (maybe 250ms) and then slightly eases into the gravity fall, so you have time to read the shape better.\" → For LUME `LumeCloneSnapshot.cs`: `holdDuration = 0.25s`, then ease-in to gravity. Don't drop straight to physics. 2. **Audio reactivity is two-stage with a feedback loop**, not a single mapping. Beat trigger → snapshot AND audio FFT → reactive logo blend-shape inflation → blend-shape adds motion vectors to fluid sim → fluid sim moves OTHER particles → speed-to-brightness lights them up. (E489 + E490). This is a self-reinforcing cascade, not parallel channels. 3. **Speed→brightness is the \"twinkle\" parameter.** Every audio clones reel calls it out as the secret-sauce visual flourish that makes the system feel alive. Brightness boost is a power curve with a threshold — overshoot → blow-out, undershoot → no twinkle. Tune by ear.", "htmlHref": "/research/html/e490-duncan-fewkes-reel-analysis-digest-2by1wg.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1107 }, { "id": "claude-design-paste-once-prompt-15xtaph", "title": "Claude Design Paste-Once Prompt", "slug": "claude-design-paste-once-prompt", "kind": "proposal", "program": "Embodied Trajectory Systems", "sourceAnchor": "lume-content/vc-pitch/CLAUDE-DESIGN-PROMPT.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This is the prompt to paste into your **real browser tab** at `claude.ai/design` to get 5 visualized LUME pitch decks back in one shot.", "excerpt": "This is the prompt to paste into your **real browser tab** at `claude.ai/design` to get 5 visualized LUME pitch decks back in one shot.\n\n**How to use:** 1. Make sure you're at https://claude.ai/design (logged in) 2. Copy everything between the `===` lines below 3. Paste into the prompt box 4. Hit send 5. Claude will generate a deck. After it returns, ask: *\"Now generate the next 4 variants in the same style: experience-first, cultural-first (N'Ko/Bambara), traction-first, market-first. Each as a separate deck I can flip through.\"*\n\n- Compare side-by-side with the pipeline-generated variants in `decks/andrewchanvc/*.html` (those will be ready by morning) - Pick the strongest. Either the Claude-Design version or the pipeline version, whichever lands harder. - Rewrite slides 1, 7, 9 by hand. AI does 90%, the last 10% is the deal.\n\nab-browser headless can't drive claude.ai (Cloudflare blocks the Playwright fingerprint, and there's no claude.ai vault profile anyway). So instead of automating, I produced this paste-once prompt that condenses everything Claude Design needs in one block. Single paste, full visualization.", "htmlHref": "/research/html/claude-design-paste-once-prompt-15xtaph.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1355 }, { "id": "lume-derived-lanes-after-capture-spec-173gy4r", "title": "LUME Derived Lanes After Capture Spec", "slug": "lume-derived-lanes-after-capture-spec", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/lume-wiring/lume-derived-lanes-after-capture-spec-current.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This spec defines what the system is allowed to derive after a strict-real capture bundle exists. It prevents a common failure mode: treating generated outputs, semantic candidates, or learned summaries as if they were the original evidence.", "excerpt": "This spec defines what the system is allowed to derive after a strict-real capture bundle exists. It prevents a common failure mode: treating generated outputs, semantic candidates, or learned summaries as if they were the original evidence.\n\nDerived lanes may explain, summarize, transform, annotate, map, or propose. They cannot replace required physical lanes, source identity, camera topology, operator review, or K11 command promotion.\n\nTemplate candidates become stable templates only after repeated sessions and review.\n\nDEMON must not receive raw camera frames as truth, must not send Rekordbox commands, and must not replace SAN or reconstruction evidence.\n\nRoom reconstruction cannot satisfy required body evidence lanes and cannot claim the first real body reconstruction by itself.", "htmlHref": "/research/html/lume-derived-lanes-after-capture-spec-173gy4r.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1010 }, { "id": "diffusion-1e9k9g", "title": "Diffusion", "slug": "diffusion", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/live-music-diffusion-models/docs/diffusion.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- `diffusion` - The configuration for the diffusion model itself. See below for more information on the diffusion model config - `pretransform` - The configuration of the diffusion model's [pretransform](pretransforms.md), such as an autoencoder for latent diffusion. - Optional - `conditioning` - The configuration of the various [conditioning](conditioning.md) modules for the diffusion model - Only required for `diffusion_cond` - `io_channels` - The base number of input/output channels for the diffusion model - Use", "excerpt": "# Model configs The model config file for a diffusion model should set the `model_type` to `diffusion_cond` if the model uses conditioning, or `diffusion_uncond` if it does not, and the `model` object should have the following properties:\n\n- `diffusion` - The configuration for the diffusion model itself. See below for more information on the diffusion model config - `pretransform` - The configuration of the diffusion model's [pretransform](pretransforms.md), such as an autoencoder for latent diffusion. - Optional - `conditioning` - The configuration of the various [conditioning](conditioning.md) modules for the diffusion model - Only required for `diffusion_cond` - `io_channels` - The base number of input/output channels for the diffusion model - Used by inference scripts to determine the shape of the noise to generate for the diffusion model\n\n# Diffusion configs - `type` - The underlying model type for the transformer - For conditioned diffusion models, be one of `dit` ([Diffusion Transformer](#diffusion-transformers-dit)), `DAU1d` ([Dance Diffusion U-Net](#dance-diffusion-u-net)), or `adp_cfg_1d` ([audio-diffusion-pytorch U-Net](#audio-diffusion-pytorch-u-net-adp)) - Unconditioned diffusion models can also use `adp_1d` - `cross_attention_cond_ids` - Conditioner ids for conditioning information to be used as cross-attention input - If multiple ids are specified, the conditioning tensors will be concatenated along the sequence dimension - `global_cond_ids` - Conditioner ids for conditioning information to be used as global conditioning input - If multiple ids are specified, the conditioning tensors will be concatenated along the channel dimension - `prepend_cond_ids` - Conditioner ids for conditioning information to be prepended to the model input - If multiple ids are specified, the conditioning tensors will be concatenated along the sequence dimension - Only works with diffusion transformer models - `input_concat_ids` - Conditioner ids for conditioning information to be concatenated to the model input - If multiple ids are specified, the conditioning tensors will be concatenated along the channel dimension - If the conditioning tensors are not the same length as the model input, they will be interpolated along the sequence dimension to be the same length. - The interpolation algorithm is model-dependent, but usually uses nearest-neighbor resampling. - `config` - The configuration for the model backbone itself - Model-dependent\n\n# Training configs The `training` config in the diffusion model config file should have the following properties:\n\n- `learning_rate` - The learning rate to use during training - Defaults to constant learning rate, can be overridden with `optimizer_configs` - `use_ema` - If true, a copy of the model weights is maintained duri", "htmlHref": "/research/html/diffusion-1e9k9g.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1024 }, { "id": "sgt-semantic-generative-tuning-for-unified-multimodal-models-12mlr56", "title": "SGT: Semantic Generative Tuning for Unified Multimodal Models", "slug": "sgt-semantic-generative-tuning-for-unified-multimodal-models", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/sgt-project-page/BAGEL/README.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This repository hosts checkpoints fine-tuned with **Semantic Generative Tuning (SGT)** — a training paradigm that couples visual *understanding* and *generation* in Unified Multimodal Models (UMMs) by using **image segmentation as a generative proxy**.", "excerpt": "--- license: apache-2.0 pipeline_tag: any-to-any library_name: bagel-mot tags: - sgt - semantic-generative-tuning - unified-multimodal - image-segmentation - visual-understanding - visual-generation ---\n\nThis repository hosts checkpoints fine-tuned with **Semantic Generative Tuning (SGT)** — a training paradigm that couples visual *understanding* and *generation* in Unified Multimodal Models (UMMs) by using **image segmentation as a generative proxy**.\n\n> Unified multimodal models typically optimize understanding and generation with *misaligned* > objectives (sparse text tokens vs. dense pixel targets), which isolates the two capabilities. > SGT introduces segmentation — a **high-level semantic task** — as a unified generative objective > that aligns the two branches, improves feature linear separability, and optimizes visual-textual > attention allocation.\n\nSGT reformulates classical visual tasks as generative proxies and establishes a **hierarchical taxonomy** (low-/mid-/high-level). Extensive experiments show that **high-level semantic tasks (e.g. image segmentation) are the optimal proxy**, outperforming depth, edge, reconstruction and MAE/inpainting for synergizing understanding and generation.\n\n1. **High-level > low-level**: segmentation gives larger gains in visual understanding than depth / edge / pixel reconstruction. 2. **Perception, not reasoning**: visual supervision mainly strengthens perception (spatial, hallucination, vision-centric, general VQA), rather than abstract reasoning (e.g. math, chart) 3. **Architecture-agnostic**: the gains hold for both **BAGEL** and **OmniGen2**.", "htmlHref": "/research/html/sgt-semantic-generative-tuning-for-unified-multimodal-models-12mlr56.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 400 }, { "id": "omnicontext-1ibsib5", "title": "OmniContext", "slug": "omnicontext", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/sgt-project-page/OmniGen2/omnicontext/README.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "As part of OmniGen2, we introduce a new benchmark for in-context generation, **OmniContext**, which aims to provide a more comprehensive evaluation of models' in-context generation abilities. It incorporates a diverse set of input images and instructions, and utilizes GPT-4.1 for interpretable, metric-driven assessment.", "excerpt": "As part of OmniGen2, we introduce a new benchmark for in-context generation, **OmniContext**, which aims to provide a more comprehensive evaluation of models' in-context generation abilities. It incorporates a diverse set of input images and instructions, and utilizes GPT-4.1 for interpretable, metric-driven assessment.\n\n


Overview of OmniContext benchmark.


An illustrative evaluation case in the OmniContext benchmark.

\n\nNote: we fix the resolution of the output images at 1024 × 1024 to ensure that the settings are consistent across different models.\n\nYou may try generating results using OmniGen2 or other models; please ensure that the output image directory structure and format are consistent with the format specified below.\n\n1. We use GPT-4.1 to evaluate the quality of the generated images. Please make sure to set up your API key before running the script.", "htmlHref": "/research/html/omnicontext-1ibsib5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 345 }, { "id": "sgt-semantic-generative-tuning-for-unified-multimodal-models-glahji", "title": "SGT: Semantic Generative Tuning for Unified Multimodal Models", "slug": "sgt-semantic-generative-tuning-for-unified-multimodal-models", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/sgt-project-page/OmniGen2/README.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This repository hosts checkpoints fine-tuned with **Semantic Generative Tuning (SGT)** — a training paradigm that couples visual *understanding* and *generation* in Unified Multimodal Models (UMMs) by using **image segmentation as a generative proxy**.", "excerpt": "--- license: apache-2.0 pipeline_tag: any-to-any library_name: bagel-mot tags: - sgt - semantic-generative-tuning - unified-multimodal - image-segmentation - visual-understanding - visual-generation ---\n\nThis repository hosts checkpoints fine-tuned with **Semantic Generative Tuning (SGT)** — a training paradigm that couples visual *understanding* and *generation* in Unified Multimodal Models (UMMs) by using **image segmentation as a generative proxy**.\n\n> Unified multimodal models typically optimize understanding and generation with *misaligned* > objectives (sparse text tokens vs. dense pixel targets), which isolates the two capabilities. > SGT introduces segmentation — a **high-level semantic task** — as a unified generative objective > that aligns the two branches, improves feature linear separability, and optimizes visual-textual > attention allocation.\n\nSGT reformulates classical visual tasks as generative proxies and establishes a **hierarchical taxonomy** (low-/mid-/high-level). Extensive experiments show that **high-level semantic tasks (e.g. image segmentation) are the optimal proxy**, outperforming depth, edge, reconstruction and MAE/inpainting for synergizing understanding and generation.\n\n1. **High-level > low-level**: segmentation gives larger gains in visual understanding than depth / edge / pixel reconstruction. 2. **Perception, not reasoning**: visual supervision mainly strengthens perception (spatial, hallucination, vision-centric, general VQA), rather than abstract reasoning (e.g. math, chart) 3. **Architecture-agnostic**: the gains hold for both **BAGEL** and **OmniGen2**.", "htmlHref": "/research/html/sgt-semantic-generative-tuning-for-unified-multimodal-models-glahji.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 400 }, { "id": "stable-audio-3-inference-methods-fpuguc", "title": "Stable Audio 3 Inference Methods", "slug": "stable-audio-3-inference-methods", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/stable-audio-3/docs/workflows/inference.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> New to diffusion/Flow Matching models? See [Model Overview](../guides/model-overview.md) > for a conceptual overview before diving in.", "excerpt": "# Stable Audio 3 Inference Methods An overview of the different inference modes. The python interface is shown, but these controls are the same as for the gradio interface\n\n> New to diffusion/Flow Matching models? See [Model Overview](../guides/model-overview.md) > for a conceptual overview before diving in.\n\n| Model | Type | |---|---| | `medium` | Post-trained | | `small-music` | Post-trained | | `small-sfx` | Post-trained | | `medium-base` | Base | | `small-music-base` | Base | | `small-sfx-base` | Base |\n\n> **Note:** `medium` and `medium-base` require a CUDA GPU with Flash Attention support due to using SAME-L as their autoencoder.\n\n- **`prompt`** — Text description of the audio to generate. For help crafting good prompts, see [Prompt Guide](../guides/prompting.md) - **`duration`** — Duration of the generated audio in seconds (default: `120`). - **`steps`** — Number of sampling steps (default: `8`). For even faster inference, reduce this number at some cost to quality. However, going higher than 8 doesn't necessarily increase quality (unless using a '-base' model, where you should use something like 50) - **`seed`** - Random seed for reproducible outputs if needed. Use -1 to select a random seed (default) or select your favorite number for deterministic results. - **`batch_size`** - Generate multiple at once, useful is you have a GPU and want to get a lot of variations. The max is limited by your GPU's VRAM.", "htmlHref": "/research/html/stable-audio-3-inference-methods-fpuguc.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 1164 }, { "id": "lora-in-stable-audio-3-1anyn51", "title": "LoRA in Stable Audio 3", "slug": "lora-in-stable-audio-3", "kind": "research note", "program": "Embodied Trajectory Systems", "sourceAnchor": "MotionMix/research/external/audio-ai/stable-audio-3/docs/workflows/lora.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "LoRA fine-tuning lets you adapt a Stable Audio 3 model to a specific style, sound, or domain without retraining the whole model. The result is a small `.safetensors` file (~50–200 MB) that you load on top of any base checkpoint at inference time — stackable, adjustable in strength, and swappable without touching the base weights.", "excerpt": "LoRA fine-tuning lets you adapt a Stable Audio 3 model to a specific style, sound, or domain without retraining the whole model. The result is a small `.safetensors` file (~50–200 MB) that you load on top of any base checkpoint at inference time — stackable, adjustable in strength, and swappable without touching the base weights.\n\n- A dataset of audio files with matching text descriptions (at minimum ~20–50 clips; more is better) - A CUDA GPU with sufficient VRAM:\n\n| Model | Standard | With `--base_precision bf16 --adapter_type lora-xs` | |---|---|---| | `medium` | ~6.5 GB | ~5.5 GB | | `small` | ~2.5 GB | ~2 GB | - The `lora` extra installed: `uv sync --extra lora`\n\nWe don't claim these are optimal settings, LoRA behavior varies a lot with dataset size, style, and hardware. But these are the configurations we've found work well for most datasets and are good starting points before tuning.\n\nGood default for most datasets. `dora-rows` is the default adapter and tends to generalize well.", "htmlHref": "/research/html/lora-in-stable-audio-3-1anyn51.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2605 }, { "id": "from-dead-circuits-to-living-speech-1yjd08w", "title": "From Dead Circuits to Living Speech", "slug": "from-dead-circuits-to-living-speech", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/archive/asr-breakthrough.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "In Part 1 of this research, we performed a brain scan on Qwen2-72B. We fed it N'Ko text and measured what happened inside: 80 transformer layers, 8,192 neurons each, four metrics per layer. The results were stark.", "excerpt": "In Part 1 of this research, we performed a brain scan on Qwen2-72B. We fed it N'Ko text and measured what happened inside: 80 transformer layers, 8,192 neurons each, four metrics per layer. The results were stark.\n\nThe model's reasoning circuits, the same circuits that David Noel Ng showed could be amplified through layer duplication to boost English reasoning by 17.72%, produced nothing for N'Ko. Not weak signal. Not partial comprehension. Nothing. Every one of 55 circuit duplication configurations scored at or near random chance. The heatmap was blank. The circuits were dead.\n\nWe called this the \"translation tax\": a 3-4x reduction in activation magnitude, 30-60% higher entropy, and progressive loss of circuit specialization from layer 0 through layer 80. The model couldn't read N'Ko because it had never been taught to.\n\nEvery existing Bambara ASR system, MALIBA-AI, Meta's MMS, Google's USM, does the same thing: take audio in, produce Latin text out. The output looks like this:\n\nThis is Bambara written in Latin script, an orthography designed by French colonial linguists. It works. But for the majority of literate Bambara speakers, those who learned to read in N'Ko, this output is foreign. They would write the same sentence as:", "htmlHref": "/research/html/from-dead-circuits-to-living-speech-1yjd08w.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1901 }, { "id": "the-script-that-machines-can-t-read-80rpwv", "title": "The Script That Machines Can't Read", "slug": "the-script-that-machines-can-t-read", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/archive/index.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "N'Ko is an alphabetic script used by over 40 million Manding-language speakers across West Africa. It has a Unicode block (U+07C0-U+07FF), a Wikipedia with thousands of articles, and a vibrant literary tradition. But when you feed N'Ko text to state-of-the-art language models, they choke. Not subtly. Catastrophically.", "excerpt": "N'Ko is an alphabetic script used by over 40 million Manding-language speakers across West Africa. It has a Unicode block (U+07C0-U+07FF), a Wikipedia with thousands of articles, and a vibrant literary tradition. But when you feed N'Ko text to state-of-the-art language models, they choke. Not subtly. Catastrophically.\n\nThis is the story of how I taught a language model to read N'Ko, on a laptop, for less than $2.\n\nWhen I ran Qwen3-8B on N'Ko text, the model produced garbled output. Its N'Ko perplexity was 11.02 compared to 3.8 for English. That's a 2.90x \"translation tax,\" meaning the model found N'Ko nearly three times harder to predict than English. N'Ko token accuracy sat at 23%, and about 10% of generated syllables were phonotactically invalid.\n\nThe root cause: N'Ko occupies just 64 codepoints in Unicode. During pre-training, these 64 characters compete with tens of thousands of CJK, Latin, and Cyrillic tokens for model capacity. The model learns to represent N'Ko, barely, through its general multilingual abilities, but it never develops deep understanding.\n\nBefore fine-tuning, I wanted to understand what was happening inside the model. I built an \"activation profiler\" (we call it a brain scanner) that records the hidden state norms at every transformer layer while the model processes English vs. N'Ko text.", "htmlHref": "/research/html/the-script-that-machines-can-t-read-80rpwv.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1676 }, { "id": "does-script-design-affect-how-machines-hear-hhn12d", "title": "Does Script Design Affect How Machines Hear?", "slug": "does-script-design-affect-how-machines-hear", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/experiments/experiment-b-script-advantage.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "When Solomana Kante designed N'Ko in 1949, he made a rule that no other major writing system fully follows: every sound gets exactly one character. Every character represents exactly one sound. No exceptions, no digraphs, no context-dependent pronunciations. If you hear it, you can write it. If you see it, you can say it.", "excerpt": "*N'Ko was built for phonetic precision. This experiment asks whether that precision shows up in speech recognition.*\n\nWhen Solomana Kante designed N'Ko in 1949, he made a rule that no other major writing system fully follows: every sound gets exactly one character. Every character represents exactly one sound. No exceptions, no digraphs, no context-dependent pronunciations. If you hear it, you can write it. If you see it, you can say it.\n\nThis was a design choice for human readers. Kante wanted a script that West African children could learn without memorizing exceptions. A script where literacy was achievable in weeks, not years.\n\nBut there's a second beneficiary of that design decision that Kante couldn't have anticipated: automatic speech recognition systems.\n\nModern ASR works by solving an alignment problem. You have a stream of audio. You have a sequence of characters. You need to learn which sounds map to which characters. The less ambiguous that mapping, the easier the alignment problem. The easier the alignment problem, the fewer errors the decoder makes.", "htmlHref": "/research/html/does-script-design-affect-how-machines-hear-hhn12d.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 915 }, { "id": "nko-research-experiments-1ir72lh", "title": "N'Ko Research Experiments", "slug": "nko-research-experiments", "kind": "experiment", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/experiments/index.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This is the working index for the N'Ko brain scanner research project. The project started with a single question: what happens inside a language model when it processes a script it was never trained to read? That question opened into several more, each one running as a separate experiment.", "excerpt": "This is the working index for the N'Ko brain scanner research project. The project started with a single question: what happens inside a language model when it processes a script it was never trained to read? That question opened into several more, each one running as a separate experiment.\n\nThe posts below are organized in two sections: published writing and active experiments. The experiments are in progress. Results pages will be updated as data comes in.\n\n### [Does Every AI Have the Same Blind Spot?](experiment-a-cross-model-brain-scan.md) **Experiment A: Cross-Model Brain Scan**\n\nThe original brain scan found that Qwen3-8B processes N'Ko with measurably less activation than English at every layer. This experiment runs the same scan on four architecturally different models to find out whether that deficit is universal or specific to one model family.\n\n### [Does Script Design Affect How Machines Hear?](experiment-b-script-advantage.md) **Experiment B: CTC Script Advantage**", "htmlHref": "/research/html/nko-research-experiments-1ir72lh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 660 }, { "id": "why-word-error-rate-is-the-wrong-metric-for-bambara-speech-recognition-z0czzu", "title": "Why Word Error Rate Is the Wrong Metric for Bambara Speech Recognition", "slug": "why-word-error-rate-is-the-wrong-metric-for-bambara-speech-recognition", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/blog/posts/05-why-wer-is-wrong.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Every Bambara ASR system published today reports Word Error Rate. MALIBA-AI's bambara-asr-v3 reports 45.73% WER. Normalized, that drops to 13.23% WER. Those numbers sound meaningful. They are not.", "excerpt": "Every Bambara ASR system published today reports Word Error Rate. MALIBA-AI's bambara-asr-v3 reports 45.73% WER. Normalized, that drops to 13.23% WER. Those numbers sound meaningful. They are not.\n\nWER counts the number of word-level insertions, deletions, and substitutions needed to transform a predicted transcript into the reference. It was designed for English, where words are separated by spaces, spelled consistently, and carry stable meaning across contexts.\n\nTake the Bambara word for \"goat.\" Depending on who transcribed it, you might see: *ba*, *baa*, *bà*, or *bâ*. Those are all the same word. But WER treats each spelling as a distinct token. If your model outputs \"ba\" and the reference says \"baa\", that is a substitution error. 100% WER on a correct prediction.\n\nIt gets worse. Bambara has digraphs: \"ny\" for the palatal nasal, \"ng\" for the velar nasal. Is \"nyuman\" one word or two? Does \"n'ka\" contain an apostrophe or not? Different transcribers make different choices. WER punishes the model for disagreeing with the transcriber, not for getting the language wrong.\n\nAnd then there is tone. Bambara is a tonal language. The word \"ba\" means mother, goat, or river depending on its tone. Latin script has no standard way to mark tone. Some transcribers use diacritics. Most do not. WER has no way to distinguish \"got the word right but missed the tone\" from \"got a completely different word.\" It collapses a gradient of correctness into binary right/wrong.", "htmlHref": "/research/html/why-word-error-rate-is-the-wrong-metric-for-bambara-speech-recognition-z0czzu.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 892 }, { "id": "nko-rerun-recovery-2026-04-26-aloco5", "title": "N'Ko Rerun Recovery — 2026-04-26", "slug": "nko-rerun-recovery-2026-04-26", "kind": "technical note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/docs/handoffs/nko-rerun-recovery-2026-04-26.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "The newer `paper4_same_snapshot_20260422_safe_lr1e4` matrix also ran correctly, but it was **not** a faithful reproduction of the `20.57%` trajectory regime. It was a separate low-learning-rate safety matrix.", "excerpt": "The newer `paper4_same_snapshot_20260422_safe_lr1e4` matrix also ran correctly, but it was **not** a faithful reproduction of the `20.57%` trajectory regime. It was a separate low-learning-rate safety matrix.\n\nThat means the `31.12%` TTT result should **not** be interpreted as \"TTT failed against the real best model.\" It should be interpreted as \"the safe low-LR matrix underperformed the known strong trajectory regime.\"\n\nSource: - `results/paper4_reproduction_35205256/results.json` - `results/paper4_reproduction_35205256/train.log`\n\nKey values: - `script=nko` - `mode=trajectory` - `use_trajectory=true` - `use_ttt=false` - `lr=0.0003` - `batch_size=32` - `epochs_trained=47` - `best_val_loss=0.6358872798606507` - `test_cer=0.2057`\n\nSource: - `results/paper4_same_snapshot_20260422_safe_lr1e4/nko_trajectory_ttt_290596/results.json` - `results/paper4_same_snapshot_20260422_safe_lr1e4/nko_trajectory_ttt_290596/train.log`", "htmlHref": "/research/html/nko-rerun-recovery-2026-04-26-aloco5.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": false, "isStageResearch": false }, "wordCount": 581 }, { "id": "nko-qwen3-8b-v3-nko-script-adaptation-with-nicolingua-integration-1f1jboh", "title": "NKo-Qwen3-8B-V3: N'Ko Script Adaptation with nicolingua Integration", "slug": "nko-qwen3-8b-v3-nko-script-adaptation-with-nicolingua-integration", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/model_card.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "A Qwen3-8B model adapted for N'Ko script processing through multi-stage training (CPT + SFT + BPE-aware + vocabulary extension + nicolingua integration), with admissibility-constrained decoding via a syllable FSM and a retrieval-centric multimodal ASR architecture.", "excerpt": "--- license: apache-2.0 language: - nqo - en - bm base_model: mlx-community/Qwen3-8B-8bit tags: - nko - manding - low-resource - african-languages - brain-scan - lora - mlx - constrained-decoding - bpe-tokenizer - retrieval-asr datasets: - custom - nicolingua pipeline_tag: text-generation ---\n\nA Qwen3-8B model adapted for N'Ko script processing through multi-stage training (CPT + SFT + BPE-aware + vocabulary extension + nicolingua integration), with admissibility-constrained decoding via a syllable FSM and a retrieval-centric multimodal ASR architecture.\n\n| Metric | Base | V1 (3-Stage) | V2 (Extended) | V3 (nicolingua) | |--------|------|-------------|---------------|-----------------| | N'Ko Perplexity | 11.02 | **6.00** | --- | 62.89 | | Translation Tax | 2.90x | **0.70x** | --- | 7.11x | | Val Loss | 4.290 | --- | 3.506 | **3.275** | | Training Examples | --- | 25,100 | 33,912 | **92,184** | | LoRA Layers | --- | 8 | 8 | 8 | | Syllable Validity | 89.8% | --- | 100% (FSM) | 99.8% / 100% (FSM) | | Mode Collapse | --- | No | Yes (20/20) | **No (3/20)** |\n\n**Note**: V3's higher N'Ko perplexity is an artifact of vocabulary extension. The extended model (152,192 tokens) tokenizes N'Ko differently than the base model (151,936 tokens), making PPL scores non-comparable across vocabulary sizes. V3's key contribution is fixing V2's mode collapse while maintaining the extended vocabulary's superior training loss (3.275 vs V1's 4.290).\n\n### V1: Three-Stage Adapter (Base Vocabulary) - **Training**: CPT (17,360) + SFT (21,240) + BPE-aware (25,100) = 25,100 total - **Config**: LoRA rank 8, scale 20.0, top 8 layers, lr 1e-5/5e-6/3e-6 - **Result**: N'Ko PPL 11.02 -> 6.00, Translation Tax 2.90x -> 0.70x - **Strength**: Higher generation diversity on base vocabulary", "htmlHref": "/research/html/nko-qwen3-8b-v3-nko-script-adaptation-with-nicolingua-integration-1f1jboh.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 848 }, { "id": "a-field-guide-to-the-nko-claim-bo4ltq", "title": "A Field Guide to the N'Ko Claim", "slug": "a-field-guide-to-the-nko-claim", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/blog-series/00-field-guide-to-the-claim.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "In 1949, in Kankan, Guinea, Solomana Kante designed a writing system for Manding languages. Not a borrowed alphabet. Not a colonial compromise. A script built from the sound structure of the languages themselves. N'Ko means \"I say.\" That name is not ornamental. It is a statement about who gets to write a language on its own terms.", "excerpt": "Before the acronyms, before the tables, before the 20.57% number, there is a simple scene.\n\nIn 1949, in Kankan, Guinea, Solomana Kante designed a writing system for Manding languages. Not a borrowed alphabet. Not a colonial compromise. A script built from the sound structure of the languages themselves. N'Ko means \"I say.\" That name is not ornamental. It is a statement about who gets to write a language on its own terms.\n\nThe project started from a suspicion: if N'Ko was designed so cleanly for Manding speech, then modern language technology should not treat it as an afterthought. The experiments did not unfold in a straight line. First we looked inside language models. Then we built script conversion tools. Then we trained speech decoders. Then we tested trajectory ideas. Then we tried to understand what a transcript should be allowed to become after the model emits it.\n\nThis field guide explains the claim so the rest of the series does not feel like a wall of private shorthand.\n\nThat is the central lesson from the brain-scan work. Unicode support means the characters can enter the system. It does not mean the model has learned useful internal representations for those characters. In the older blog drafts, we called this the translation tax: the model was working with much weaker internal energy for N'Ko than for English.", "htmlHref": "/research/html/a-field-guide-to-the-nko-claim-bo4ltq.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 976 }, { "id": "the-model-that-listened-in-nko-1agf5zm", "title": "The Model That Listened in N'Ko", "slug": "the-model-that-listened-in-nko", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/blog-series/03-the-model-that-listened-in-nko.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Do not make the system hear Bambara, write Latin, and then ask another model to recover N'Ko afterward. That route repeats the exact problem the brain scan found: the generic model is weak in N'Ko, so a post-hoc restoration step can sound fluent while losing the script's evidence.", "excerpt": "Do not make the system hear Bambara, write Latin, and then ask another model to recover N'Ko afterward. That route repeats the exact problem the brain scan found: the generic model is weak in N'Ko, so a post-hoc restoration step can sound fluent while losing the script's evidence.\n\nThere was a practical problem first. There was no large N'Ko-labeled speech corpus waiting to be downloaded. Existing Bambara automatic speech recognition, or ASR, data was mostly Latin. To train a direct N'Ko decoder, the project needed targets in N'Ko.\n\nIPA means International Phonetic Alphabet. The Latin-to-IPA stage handles Bambara digraphs and vowel forms. The IPA-to-N'Ko stage maps the sound inventory into N'Ko characters.\n\nThis is where the script argument became concrete. The bridge did not just move letters around. It exposed every place where Latin Bambara made the model guess. \"ny\" has to be consumed as a single palatal nasal, not as \"n\" plus \"y.\" \"ng\" has to be treated as the velar nasal. Toned vowels need Unicode decomposition before lookup. Extended IPA symbols from real transcriptions needed explicit handling. Right-to-left rendering needed marks so the output would not visually scramble in Latin-dominant environments.\n\nThese were engineering bugs, but they were also linguistic evidence. Each bug was a place where script choice changed what the machine had to infer.", "htmlHref": "/research/html/the-model-that-listened-in-nko-1agf5zm.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1167 }, { "id": "nko-public-blog-series-w5p7fr", "title": "N'Ko Public Blog Series", "slug": "nko-public-blog-series", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/blog-series/README.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This folder is the public narrative version of the final four-paper bundle. The older `blog/posts/` drafts had the right energy: they opened with Solomana Kante, walked through the experiments as they actually unfolded, used numbers as evidence rather than decoration, and treated N'Ko as both a technical system and a living script. This series keeps that voice while tightening the claims around the final research record.", "excerpt": "This folder is the public narrative version of the final four-paper bundle. The older `blog/posts/` drafts had the right energy: they opened with Solomana Kante, walked through the experiments as they actually unfolded, used numbers as evidence rather than decoration, and treated N'Ko as both a technical system and a living script. This series keeps that voice while tightening the claims around the final research record.\n\nThe research papers under `../final/` preserve the formal argument. These essays are for readers who need to understand why the work matters before they care about the LaTeX.\n\n| # | Post | Job | |---|------|-----| | 0 | `00-field-guide-to-the-claim.md` | The map: what the project found, what 20.57% CER means, and which claims stay separate. | | 1 | `01-when-unicode-is-not-understanding.md` | The brain scan: why rendering N'Ko is not the same as representing it. | | 2 | `02-why-20-57-cer-matters.md` | The measurement story: why direct N'Ko CER is a serious ASR result. | | 3 | `03-the-model-that-listened-in-nko.md` | The architecture story: how Whisper features, CTC, trajectory state, TAR, and TTT fit together. | | 4 | `04-after-the-transcript.md` | The deployment story: why AGP exists after the transcript and what Djoko taught us. |\n\nDefine the machinery in plain English before using labels like CTC, TAR, TTT, or AGP.\n\nUse numbers as turning points in the story: 32 tokenizer entries, 2.94x translation tax, 290,596 speech pairs, 216,225 edits, 1,050,967 reference characters, 20.57% CER.", "htmlHref": "/research/html/nko-public-blog-series-w5p7fr.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 351 }, { "id": "new-and-updated-paper-proposals-april-2026-lr2vq3", "title": "New and Updated Paper Proposals — April 2026", "slug": "new-and-updated-paper-proposals-april-2026", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/paper_proposals_april2026.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "This paper reports the full 8-way controlled experiment. The central finding is NOT that TAR improves ASR. It is that trajectory scalars alone are the essential contribution, and depth attention adds nothing.", "excerpt": "Based on discoveries from the current research arc. These build on Papers 1-5 (written) and extend into new territory.\n\n## Paper 6: Updated Framing — Trajectory Attention Residuals Are a Negative Result\n\nOriginal title was \"Inscribing Knowledge\" (blockchain provenance). The TAR experiments produced a more important story.\n\nTitle: \"Trajectory Scalars Are Necessary and Sufficient: A Controlled ASR Experiment on 290K Bambara Speech Pairs\"\n\nThis paper reports the full 8-way controlled experiment. The central finding is NOT that TAR improves ASR. It is that trajectory scalars alone are the essential contribution, and depth attention adds nothing.", "htmlHref": "/research/html/new-and-updated-paper-proposals-april-2026-lr2vq3.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1163 }, { "id": "paper-5-compositional-generalization-and-speaker-adaptation-in-script-aware-asr-1fswe3s", "title": "Paper 5: Compositional Generalization and Speaker Adaptation in Script-Aware ASR", "slug": "paper-5-compositional-generalization-and-speaker-adaptation-in-script-aware-asr", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/paper5_outline.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "Workspace document requiring curation.", "excerpt": "# Paper 5: Compositional Generalization and Speaker Adaptation in Script-Aware ASR\n\n## Thesis N'Ko's phonetic transparency advantage (Paper 4) extends beyond controlled CER comparison: N'Ko generalizes better to unseen vocabulary (Exp F), enables zero-shot vocabulary expansion via graph update (Exp H), and adapts faster to new speakers through test-time training (Exp G). Together, these three experiments demonstrate that phonetically transparent scripts produce ASR systems with superior operational lifetime characteristics.\n\n## Core Argument Paper 4 showed that trajectory-biased CTC gives N'Ko -5.25pp CER advantage over Latin at 297K scale. Paper 5 asks: does this advantage persist in deployment scenarios where the model encounters words and speakers it never saw in training?\n\n## Section 1: Introduction - ASR systems degrade in deployment: new vocabulary, new speakers, domain shift - For under-resourced scripts like N'Ko, these problems are amplified (no large-scale fine-tuning data available) - We test three deployment scenarios: compositional generalization, vocabulary expansion, speaker adaptation - All experiments use the same 297K-pair controlled setup from Paper 4\n\n## Section 2: Related Work - Compositional generalization in ASR (cite subword approaches, BPE vs character-level) - Zero-shot vocabulary expansion (cite KG-augmented ASR, semantic priming) - Test-time training / adaptation (cite TTT, few-shot speaker adaptation, meta-learning for ASR) - Script-dependent effects in multilingual ASR (cite Whisper, MMS)", "htmlHref": "/research/html/paper-5-compositional-generalization-and-speaker-adaptation-in-script-aware-asr-1fswe3s.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 962 }, { "id": "season-1-episode-bank-creative-ai-x-mandinka-x-nko-wfipky", "title": "Season 1 Episode Bank: Creative AI x Mandinka x N'Ko", "slug": "season-1-episode-bank-creative-ai-x-mandinka-x-nko", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/paper/social/tiktok-nko-series/season-01-episode-bank.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "These are camera-first scripts. They are meant to sound like a person explaining an unusual creative process, not a researcher defending a benchmark. The technical details are still there, but they enter as proof only after the viewer understands the personal and creative reason for the work.", "excerpt": "These are camera-first scripts. They are meant to sound like a person explaining an unusual creative process, not a researcher defending a benchmark. The technical details are still there, but they enter as proof only after the viewer understands the personal and creative reason for the work.\n\n**Hook:** I used AI to study my native language, and it exposed something weird about modern AI.\n\nMandinka is my native language, and I started looking deeper into N'Ko, the script designed for Manding languages. At first, it was personal. I wanted to understand the structure. The sounds. The characters. Why the script works the way it works.\n\nNot just show the characters on screen. Not just translate around it. Actually represent it. Actually hear Mandinka and write it in the script built for it.\n\nI used AI like a microscope, pointed it at my own language, and started asking what modern AI still cannot see.", "htmlHref": "/research/html/season-1-episode-bank-creative-ai-x-mandinka-x-nko-wfipky.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 2788 }, { "id": "implementation-checklist-1uj3tzs", "title": "Implementation Checklist", "slug": "implementation-checklist", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "nko-brain-scanner/pipeline/scripts/IMPLEMENTATION_CHECKLIST.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "1. Phase 0: Project Control Layer 1.1 Step: Perform Artifact Intake Pass 1.1.1 Substep: Document Intake Findings [ip] Artifact: INTAKE_REPORT.md [ip].1 Description: Create intake report with discovery, classification, gap analysis, and confidence assessment. [ip].2 Owner: Agent [ip].3 Input dependencies: README.md, existing scripts. [ip].4 Output artifacts: INTAKE_REPORT.md [ip].5 Validation condition: File exists and includes sections 1-4 and change history. [ip].6 Status: Complete [ip].7 Confidence: Medium 1.2 St", "excerpt": "1. Phase 0: Project Control Layer 1.1 Step: Perform Artifact Intake Pass 1.1.1 Substep: Document Intake Findings [ip] Artifact: INTAKE_REPORT.md [ip].1 Description: Create intake report with discovery, classification, gap analysis, and confidence assessment. [ip].2 Owner: Agent [ip].3 Input dependencies: README.md, existing scripts. [ip].4 Output artifacts: INTAKE_REPORT.md [ip].5 Validation condition: File exists and includes sections 1-4 and change history. [ip].6 Status: Complete [ip].7 Confidence: Medium 1.2 Step: Create Canonical Documentation Set 1.2.1 Substep: Create Project Charter [ip] Artifact: PROJECT_CHARTER.md [ip].1 Description: Create Project Charter with purpose, non-goals, success criteria, direction constraints, commitment level, traceability, and change history. [ip].2 Owner: Agent [ip].3 Input dependencies: README.md [ip].4 Output artifacts: PROJECT_CHARTER.md [ip].5 Validation condition: File exists with required sections and traceability notes. [ip].6 Status: Complete [ip].7 Confidence: Medium 1.2.2 Substep: Create System Glossary [ip] Artifact: SYSTEM_GLOSSARY.md [ip].1 Description: Define core terms with what it is, what it is not, layer, and stability. [ip].2 Owner: Agent [ip].3 Input dependencies: README.md, existing scripts. [ip].4 Output artifacts: SYSTEM_GLOSSARY.md [ip].5 Validation condition: File exists with required definition fields and change history. [ip].6 Status: Complete [ip].7 Confidence: Medium 1.2.3 Substep: Create Assumptions and Invariants Ledger [ip] Artifact: ASSUMPTIONS_INVARIANTS.md [ip].1 Description: Document assumptions and invariants with break conditions and detection. [ip].2 Owner: Agent [ip].3 Input dependencies: README.md [ip].4 Output artifacts: ASSUMPTIONS_INVARIANTS.md [ip].5 Validation condition: File exists with assumptions, invariants, and change history. [ip].6 Status: Complete [ip].7 Confidence: Medium 1.3 Step: Create Implementation Guide 1.3.1 Substep: Define Implementation and Validation Rules [ip] Artifact: IMPLEMENTATION_GUIDE.md [ip].1 Description: Define decision, decomposition, validation, and traceability rules with change history. [ip].2 Owner: Agent [ip].3 Input dependencies: Constitution instructions [ip].4 Output artifacts: IMPLEMENTATION_GUIDE.md [ip].5 Validation condition: File exists with required rule sections. [ip].6 Status: Complete [ip].7 Confidence: Medium 1.4 Step: Create Living Implementation Checklist 1.4.1 Substep: Initialize Checklist [ip] Artifact: IMPLEMENTATION_CHECKLIST.md [ip].1 Description: Create checklist with Phase -> Step -> Substep -> Artifact hierarchy and required fields. [ip].2 Owner: Agent [ip].3 Input dependencies: Phase Zero requirements [ip].4 Output artifacts: IMPLEMENTATION_CHECKLIST.md [ip].5 Validation condition: File exists with required ", "htmlHref": "/research/html/implementation-checklist-1uj3tzs.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": true, "hasReferences": false, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 516 }, { "id": "bridge-privacy-documentation-1heded6", "title": "ߒߞߏ Bridge — Privacy Documentation", "slug": "bridge-privacy-documentation", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/appstore/privacy.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "**Last updated:** June 2026 **Developer:** Mohamed Diomande **App:** ߒߞߏ Bridge (NKo Bridge) **Bundle ID:** com.openclaw.nko-bridge", "excerpt": "**Last updated:** June 2026 **Developer:** Mohamed Diomande **App:** ߒߞߏ Bridge (NKo Bridge) **Bundle ID:** com.openclaw.nko-bridge\n\n**ߒߞߏ Bridge does not collect, store, or transmit any personal data.** The app works entirely offline. There are no user accounts, no analytics, no tracking, and no third-party SDKs.\n\n| Data Type | Collected? | Details | |---|---|---| | Personal Information | ❌ No | No name, email, phone, or account | | Usage Data | ❌ No | No analytics, no event tracking | | Location | ❌ No | Location is never accessed | | Contacts | ❌ No | Contacts are never accessed | | Browsing History | ❌ No | No web views, no browsing | | Search History | ❌ No | In-app searches are not logged | | Identifiers | ❌ No | No device ID, no advertising ID | | Diagnostics | ❌ No | No crash reporting SDKs | | Financial Info | ❌ No | No purchases, no payment data | | Photos/Videos | ❌ No | Camera/photos are never accessed | | Health/Fitness | ❌ No | Not applicable | | Audio Data | ⚠️ Transient only | See Microphone section below | | Keyboard Input | ⚠️ On-device only | See Keyboard section below |\n\n**How it works:** 1. User taps the microphone button in the Bridge view 2. iOS prompts for microphone permission (one-time) 3. Audio is captured and processed using **Apple's Speech framework** (`SFSpeechRecognizer`) 4. Speech recognition runs **on-device** (iOS 17+ on-device models) 5. Recognized text is transliterated into N'Ko, Latin, and Arabic scripts 6. **Audio is never recorded, stored, or transmitted**\n\n**NSMicrophoneUsageDescription:** > \"ߒߞߏ Bridge uses the microphone for voice-to-text input. Speak in Manding and see your words in N'Ko, Latin, and Arabic scripts. Audio is processed on your device and never leaves it.\"", "htmlHref": "/research/html/bridge-privacy-documentation-1heded6.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 1104 }, { "id": "bridge-app-review-notes-su5eks", "title": "ߒߞߏ Bridge — App Review Notes", "slug": "bridge-app-review-notes", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/appstore/review-notes.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "- **Bundle ID:** `com.openclaw.nko-bridge.keyboard` - **Container App:** `com.openclaw.nko-bridge` - **Full Access:** Not required for basic functionality. Full Access enhances predictive text by allowing access to shared word frequency data. The keyboard does NOT transmit any keystrokes or data to any server. - **Network Access:** The keyboard extension makes NO network requests. All processing is on-device. - **Shared Container:** The app and extension share a small amount of data via an App Group for user prefer", "excerpt": "**No demo account is required.** The app works entirely offline with no user accounts, login, or registration.\n\n#### Bridge View (Main Screen) 1. Launch the app — you'll see the Bridge transliteration view 2. Type any text in the Latin input field — e.g., \"Bambara\" or \"Souleymane\" 3. Observe the real-time transliteration appear in: - N'Ko script (ߒߞߏ) — right-to-left - Arabic script - IPA phonetic transcription 4. Try the reverse: tap the N'Ko input field and type N'Ko characters (if you have an N'Ko keyboard) 5. The app auto-detects which script you're typing in\n\n#### Keyboard Extension 1. Go to **Settings → General → Keyboard → Keyboards → Add New Keyboard** 2. Select **\"NKo Bridge\"** from the third-party keyboards list 3. Optionally enable \"Allow Full Access\" (not required for basic functionality — only enhances predictive text) 4. Open any app with text input (Notes, Messages, Safari, etc.) 5. Tap the 🌐 globe key to switch to the N'Ko keyboard 6. Type using the N'Ko layout — observe: - Character input in N'Ko script (right-to-left) - Predictive text suggestions in the suggestion bar (3 suggestions) - Tone mark input (long-press or dedicated keys) 7. Use the Latin transliteration mode: tap the mode switch to type Latin letters that auto-convert to N'Ko\n\n#### Cultural Library 1. Navigate to the Culture tab (bottom navigation) 2. Browse the proverbs list — 62 Manding proverbs 3. Tap any proverb to see: - Original text (Latin transliteration and/or N'Ko) - English translation - Meaning and cultural context - Category tags 4. Browse other sections: Blessings, Greetings, Clans, Calendar\n\n#### Voice Input 1. Navigate to the Bridge view 2. Tap the microphone button 3. The app will request microphone and speech recognition permissions (if not already granted) 4. Speak any Manding words or phrases 5. Observe the speech-to-text conversion and subsequent transliteration into all three scripts 6. **Note:** Voice recognition works best with clear Manding pronunciation. English or other languages may produce unexpected results — this is by design, as the app is optimized for Manding language input.", "htmlHref": "/research/html/bridge-app-review-notes-su5eks.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": false, "hasEvaluation": true, "hasReferences": true, "hasMath": false, "hasFigures": false, "hasCodeAnchors": false, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 988 }, { "id": "keyboard-ios-custom-keyboard-extension-1h0j67f", "title": "ߒߞߏ Keyboard - iOS Custom Keyboard Extension", "slug": "keyboard-ios-custom-keyboard-extension", "kind": "research note", "program": "Language as Infrastructure", "sourceAnchor": "NKo/ios/README.md", "extension": "md", "score": 18, "readiness": "backlog reference", "nextAction": "Keep in the searchable backlog until it intersects a live paper or system.", "summary": "| Feature | Description | |---------|-------------| | 🔄 **Real-time Transliteration** | Type in Latin, see N'Ko instantly | | ⌨️ **Dual Input Modes** | Latin-to-N'Ko or direct N'Ko character input | | 💡 **Smart Suggestions** | Common word predictions with meanings | | 📱 **System-wide** | Works in any app - Messages, Notes, Safari, etc. | | 🔢 **N'Ko Numerals** | Full digit support (߀-߉) | | ➡️ **RTL Support** | Proper right-to-left text direction | | ⚡ **Offline** | No network required, all processing on-device ", "excerpt": "Real-time Latin → N'Ko transliteration keyboard for iOS, enabling system-wide N'Ko typing on iPhone and iPad.\n\n| Feature | Description | |---------|-------------| | 🔄 **Real-time Transliteration** | Type in Latin, see N'Ko instantly | | ⌨️ **Dual Input Modes** | Latin-to-N'Ko or direct N'Ko character input | | 💡 **Smart Suggestions** | Common word predictions with meanings | | 📱 **System-wide** | Works in any app - Messages, Notes, Safari, etc. | | 🔢 **N'Ko Numerals** | Full digit support (߀-߉) | | ➡️ **RTL Support** | Proper right-to-left text direction | | ⚡ **Offline** | No network required, all processing on-device |\n\n2. **Configure Signing** - Select your Team in Signing & Capabilities - Ensure unique Bundle IDs for both targets: - Main app: `com.yourteam.nko-keyboard` - Extension: `com.yourteam.nko-keyboard.keyboard`\n\n4. **Enable Keyboard** - Settings → General → Keyboard → Keyboards - Add New Keyboard → ߒߞߏ Keyboard - Tap 🌐 while typing to switch\n\n| Type | Get | Meaning | |------|-----|---------| | `salam` | ߛߟߊ߯ߡ | peace | | `nko` | ߒߞߏ | N'Ko | | `kan` | ߞߊ߲ | language | | `ala` | ߊߟߊ | God | | `baara` | ߓߊ߯ߙߊ | work |", "htmlHref": "/research/html/keyboard-ios-custom-keyboard-extension-1h0j67f.html", "signals": { "hasPdf": false, "hasLatex": false, "hasAbstract": false, "hasIntroduction": false, "hasMethod": true, "hasEvaluation": false, "hasReferences": false, "hasMath": false, "hasFigures": true, "hasCodeAnchors": true, "hasArchitecture": true, "isStageResearch": false }, "wordCount": 838 }, { "id": "cross-app-text-injection-test-plan-sf-1-4-1cj6sl6", "title": "Cross-App Text Injection Test Plan — SF-1.4", "slug": "cross-app-text-injection-test-plan-sf-1-4", "kind": "proposal", "program": "Language as Infrastructure", "sourceAnchor": "NKo/macos/SpeakFlow/Tests/CrossAppTestPlan.md", "extension": "md", "score": 18, "readiness": "experiment writeup candidate", "nextAction": "Attach run IDs, datasets, metrics, and reproduction commands.", "summary": "> Documents injection behavior across target applications. > Two methods tested: **AX API direct** (AXUIElementSetAttributeValue) and **CGEvent paste** (⌘V via clipboard).", "excerpt": "> Documents injection behavior across target applications. > Two methods tested: **AX API direct** (AXUIElementSetAttributeValue) and **CGEvent paste** (⌘V via clipboard).\n\nSpeakFlow must inject transcribed text into whatever app the user is focused on. macOS apps fall into distinct rendering categories — each behaves differently with accessibility APIs.\n\n| Method | Mechanism | Latency | Reliability | Limitations | |--------|-----------|---------|-------------|-------------| | **AX API Direct** | `AXUIElementSetAttributeValue(el, kAXValueAttribute, text)` | ~1ms | High for native text fields | Fails on non-AX apps, some Electron | | **CGEvent Paste** | Write to `NSPasteboard` → synthesize ⌘V via `CGEvent` | ~50ms | Universal fallback | Clobbers clipboard, timing-sensitive |\n\n**App Type:** Electron (Chromium + Node.js) **Text Rendering:** Chromium's Blink engine, CodeMirror/Monaco editor\n\n### AX API Direct - **Status:** ⚠️ Partial - **Behavior:** Electron exposes AX tree, but CodeMirror/Monaco editors use a hidden `