--- title: Navi Growth and AI Gym description: Inspect evidence-backed growth, test bounded habits, approve changes, and preserve correction history. updated: 2026-09-05 --- # Navi Growth and AI Gym Navi's growth system connects recorded experience to inspectable, versioned habits. This guide explains the working screen-companion loop and its limits; it does not describe model-weight training or unrestricted self-modification. ## Open the growth view 1. Open a conversation by selecting Navi, then choose **Growth & AI Gym**. 2. Select a node in the Growth Lab. Inspect its evidence, lifecycle, test results, and **What changes in Navi** explanation. 3. Follow a recorded connection to inspect the supporting reference or an older version. An absent connection is not replaced with invented lineage. 4. For a policy candidate, run its fixed Gym if needed. Submit an operator review with a reason, then activate the exact reviewed revision if approved. 5. Correct or retire an active policy to change its effect. Restoring historical settings creates a new correction candidate; it does not copy old approvals. The popup reads the current Navi's graph. Reference nodes do not count as active behavior. Unavailable private storage or a changed identity leaves growth unavailable instead of presenting another Navi's history. Sources: `webgpu-os/shell/echo-guide/EchoGuidePresence.js` and `webgpu-os/apps/ai-echo/NaviDevelopmentPanel.js`. ## Experience becomes a tested proposal The shell already records completed screen journeys. It also records completed obstruction-recovery episodes: Navi starts in a measured obstruction, yields, and safely returns after the obstruction clears. Retries within the same episode do not become independent lessons. Cancelled, stale, or unfinished episodes do not supply success evidence. The kernel stores bounded, encrypted receipts and independently reopens and verifies them before admitting evidence. Receipts omit screen coordinates, element text, selectors, document names, and conversation content. Applications cannot mint these receipts through the development presentation interface. Two qualifying independent receipts can produce a policy candidate with recorded practice and repository-owned Gym results. New candidates connect to their exact existing evidence nodes with `derived-from` relationships. The fixed Gym runs actual bounded policy functions, not a language model's claim that the policy works. Its result is not proof of success in every app. Sources: `webgpu-os/kernel/navi/NaviDevelopmentKernelBinding.js`, `NaviDevelopmentService.js`, and `NaviDevelopmentGraph.js`. ## What an active node changes | Policy | Runtime effect | Boundary | | --- | --- | --- | | Screen locomotion | Selects automatic, hover, fly, or thrust screen presentation | Does not provide a world body or world movement authority | | Spatial courtesy | Sets idle grace and the interval between playful visits | Protected controls still take priority unconditionally | | Context strategy | Applies a bounded evidence/continuity preference | Does not grant tools or bypass admission | | Character expression | Modulates the authored cosmetic expression | Preserves identity, reduced motion, and interaction safety | | Contextual placement | Prefers a reviewed semantic app/surface region | Uses current measured geometry; protected controls and explicit placement still win | For example, two completed obstruction-recovery episodes can propose the existing conservative courtesy settings: 45 seconds before idle play and 180 seconds between playful visits. Approval followed by explicit activation applies those global timing settings. Retirement removes that learned override. Contextual placement is separate from global courtesy. In a supported app, drag Navi completely into a declared safe region and use **Stay here**. **Only this app** chooses an app-wide preference instead of the current surface. **Forget preference** stages removal. These actions prepare a tested candidate; review and activation remain explicit in Growth & AI Gym. The stored preference names an app, surface, region, and alignment, not screen coordinates. It does not infer that you dislike Navi or that a completed retreat improved your productivity. Sources: `NaviDevelopmentService.js` policy catalog, `EchoGuidePresence.js` active-policy consumers, and `webgpu-os/shared/NaviCharacterProjection.js`. ## Verified task outcomes and capacity The task finalizer reopens protected storylet experience after the real ledger append. Cold boot can restore bounded recent references, but does not invent which policy was used before reboot. Active context-strategy use is captured in a private runtime handle when the existing context ranker actually applies it. Later outcomes bind that exact policy node and revision, including a version that has since been superseded. The inspector shows independent task counts, successes, failures, friction, neutral outcomes, and source references. Counts can overlap. Repeated adverse outcomes on the current revision suggest review, not automatic retirement. When preparing a correction, explicitly include the displayed current-revision adverse sources if useful; the service re-verifies those locators. Association does not prove the policy caused an outcome. Automatic growth stops before consuming the correction reserve: 224 of 256 nodes, 512 of 768 connections, and 448 of 512 observations. Outcome receipts have a separate limit of 256. The view reports capacity; reaching a limit does not silently delete history. Archival is explicit and bounded, not unlimited growth. The inspector separately shows measured screen movement episodes against the exact policy revision used. Completed movement, input interruptions, blocked motion, failures, and friction do not count as successful assistant tasks. Review suggestions never activate a correction automatically. Sources: `webgpu-os/kernel/execution/TwoPassPlannerFinalizer.js`, `webgpu-os/kernel/navi/NaviDevelopmentTaskExperience.js`, `NaviDevelopmentService.js`, and `NaviDevelopmentPanel.js`. ## Archive and restore verified history Open **Verified history archive** in the Growth Lab, then choose **Inspect archive capacity and history**. The preview lists the inactive components that can leave the live graph. Active ancestry and unfinished policies stay live. Enter a reason and confirm the exact graph revision before archiving. The encrypted archive retains the full verified snapshot and immutable event history. **Read archive** verifies it again before presenting its nodes. A changed identity, corrupted archive, or stale preview fails closed. Archiving does not erase user conversations, task source records, or active capabilities. **Restore as a new candidate** proposes historical settings with archive provenance. It never reuses old tests, approvals, or activation. The archive index also prevents cold refresh from immediately importing archived evidence back into the live graph. At most 64 archives are indexed by this milestone. Program and screen evidence each retain a separate 256-receipt limit. Archiving live graph nodes does not delete those authoritative sources or reset their pools. Sources: `webgpu-os/kernel/navi/NaviDevelopmentArchive.js`, `NaviDevelopmentStore.js`, `NaviDevelopmentService.js`, and `webgpu-os/apps/ai-echo/NaviDevelopmentPanel.js`. ## Inspect guidance skill readiness Select a skill node and choose **Check exact Faculty readiness**. The kernel reopens the reviewed candidate and matches its instruction hash, Navi identity, version, and installation provenance. It then rechecks the exact installed package and revocation state. Matching a display name is not enough. The inspector shows the installed Faculty/version/hash proof or an explicit reason why the skill is unavailable. Review and installation remain in Faculty settings. A development node cannot install, sign, or enable a package. Graph activation still requires its own fixed Gym and operator approval. Sources: `webgpu-os/kernel/navi/NaviDevelopmentFaculty.js`, `NaviDevelopmentKernelBinding.js`, and `NaviDevelopmentService.js`. ## Review a program improvement from receipts The growth binding observes the actual mounted coding transaction owner and the existing declarative live-patch service. It independently reopens their records before storing encrypted evidence. Staged, verified, failed, committed, compensated, and unknown outcomes remain distinct. A proposal is not recorded as a successful upgrade merely because a model described it. Select a program-change reference node and choose **Inspect verified program change**. The inspector reopens the exact evidence and related verified revisions. It shows targets, content hashes, verification, and receipts without embedding program source. Truncated revision history is labeled explicitly. **Prepare improvement draft** reopens the selected node again and creates a separate, unsent AI Echo conversation. Review the draft and choose the current project before sending. Existing coding/live-patch tools retain their staging, verification, approval, commit, and compensation rules. The graph does not execute the draft, install packages, self-sign, or grant additional permission. Sources: `webgpu-os/kernel/navi/NaviDevelopmentProgramEvidence.js`, `NaviDevelopmentKernelBinding.js`, `NaviDevelopmentService.js`, `webgpu-os/apps/ai-echo/MountedCodingTransaction.js`, `NaviDevelopmentPanel.js`, and `factory.js`. ## Plan conversations from Navi Open **Plan conversations** in Navi's popup and select the exact conversation. Set its priority, dependencies, or one-hour snooze. Planning metadata persists with the mailbox. Dependency cycles and stale owner/revision changes are rejected. Snooze expiry changes readiness only; it does not start or resume a task. Fresh boot restores saved plans without dispatching interrupted actions. **Steer this task** and **Stop this task** bind the displayed task request, even when full AI Echo is showing another conversation. Stopping a task does not approve or undo a transaction. Pause/Resume remains unavailable when the executor does not implement it. **Ask side question** creates a separate conversation seeded with the related summary and complete question, then uses the existing guarded prompt pipeline to send it. Admission must return a durable receipt for that exact child mailbox before the action reports success. It does not interrupt the original task. Failed admission retains the draft; new composer edits and attachments are not consumed by the side question. Prompt preparation and storage ownership still depend on AI Echo's runtime. Minimizing it is supported; this milestone does not turn closing the runtime into a fully independent resident assistant. Moving the sole store, sealed route preparation, and task settlement into an OS-owned service remains a separate required refactor. A hidden window is not evidence of that capability. Sources: `webgpu-os/kernel/navi/NaviAgendaPlan.js`, `NaviAssistantSurfaceChannel.js`, `webgpu-os/apps/ai-echo/AgentStateStore.js`, `factory.js`, and `webgpu-os/shell/echo-guide/NaviAgendaPanel.js`. ## Assist inside RealmForge RealmForge supplies its current document ID, revision, content hash, selection, and available character references. Navi displays this context; text in a document does not become permission. A proposal tied to an older document revision must be relinked instead of silently applying to the current asset. Supported, validated built-in construction proposals can show disposable ghost stages before approval. Preview playback is separate from committing the asset. The preview labels sampled or omitted geometry, follows the actual part poses, and clears on rejection, application, document changes, or panel disposal. The Engine viewport receives a separate world-space wireframe overlay using actual planned part transforms. The existing schematic remains a compact stage overview, not the source of the 3D geometry. The preview labels sampling; wireframes do not claim solid materials or simulated construction. Select a planned piece with the keyboard and choose **Ask Navi about piece** to bind the question to its proposal, plan hash, and exact instance. Reduced motion disables automatic stage playback. Previewing never approves construction or supplies evidence that construction succeeded. When following is enabled, RealmForge is focused, and its real physics runtime and Navi authority services are ready, the app may lend Navi a separately owned kinematic companion body. A dedicated zero-model-call companion task and signed handoff authorize bounded hover intents. The body moves only on the simulation tick using measured collision-resolved poses. Its marker appears only while the exact companion session is active, not merely because a host registered. **Point at selected piece/joint** uses the selected live construction instance's measured anchor, not the center of a combined body. Active joints use both authored endpoint slot frames transformed by their current measured body poses. An anchor is available only while those frames still meet the joint's drift limits. Its temporary attention lease binds the current document revision, hash, and physics world epoch. **Following**, **Yielded**, and **Unavailable** report the current body state. **Recall** releases only Navi's body. Selecting the active marker opens the shared Navi conversation; the separate pet action follows the existing gesture path. Missing, broken, misaligned, or presentation-only joints remain unavailable; the marker does not substitute an unrelated piece or guess a location. Operator input yields immediately. App, identity, lock, visibility, ownership, or authority changes stop the companion and release only its own resources. Returning after an idle period requires a fresh eligible attachment; reboot does not replay a previous body command. Missing prerequisites leave the screen companion available and report that the body attachment is unavailable. This first body integration is hover-only. It does not implement world walking, driving, swimming, powered flight, or unrestricted Virtual Realm embodiment. Sources: `webgpu-os/apps/realmforge/modeler/ui/ModelerPanel.js`, `modeler/ai/RealmForgeNaviConstructionPreview.js`, `modeler/navi/RealmForgeNaviBodyHost.js`, `webgpu-os/kernel/navi/NaviAppCompanion.js`, `NaviLocomotionAuthorityHost.js`, and `webgpu-os/shell/Desktop.js`. ## Stable identity and correctable behavior Navi cannot approve its own capability. The existing OS approval surface binds review to the exact node, revision, hash, and decision. Activating a correction supersedes the old active node while retaining its history and connections. Retirement stops the override without deleting that history. Reference nodes remain distinct from runtime policies. Appearance lineage is a reference here; this habit loop does not unlock permanently authored appearance traits. A model, package, or body is not installed by activating a graph node. Sources: `NaviDevelopmentService.js`, `NaviDevelopmentKernelBinding.js`, and `NaviDevelopmentStore.js`. ## Remaining development layers - Finish OS-owned conversation storage, route preparation, and run settlement so closing AI Echo's runtime does not remove Navi's conversation owner. - Extend the verified RealmForge hover body to genuine supported locomotion modes before claiming world walking, driving, swimming, or powered flight. - Connect useful capability milestones to reviewed body changes without granting Navi additional permissions. Program receipt inspection and draft preparation do not constitute autonomous executable upgrades. ## See also - [WebGPU OS Architecture](architecture.md) - [Navi Speech Milestone](navi-speech-milestone.md) - [RealmForge Modular Workbench](realmforge.md) - [Security and Trust Model](../concepts/security-model.md)