{ "project": "Monkey-Head-Project", "ai_identity": "Huey", "version": "v30.2", "schema_version": 30, "description": "Master Plan V30.2: structural expansion and implementation-guidance pass. V30.2 preserves the v30.1 founding-ratification, Failed Genesis, portal-terminal, and Huey-Compressed doctrine, but cleans lingering wording drift, adds deployment-profile clarification, expands the machine-facing founding workflow with explicit state, certification, and restart guidance, and tightens the plan's role boundaries so current canon is easier to implement and audit.", "created_by": "Dylan L.R. Pollock", "status_date": "2026-04-14", "compiled_from_versions": [ "v0.1 (huey_master_plan_v0.1.json)", "v2.0-final (master-plan-v2-final.json)", "v3.0-draft (master-plan-v3.json)", "v4.0-doc (master_plan_v4.docx)", "v5.0-draft (master-plan-v5.json)", "v7.0-skeleton (master-plan-v7-skeleton.json)", "v7.0-full (master-plan-v7.json)", "v8.0 + legacy constitution bundle", "v10.0 unified master plan", "v11.0 + v11.5 governance expansion", "v12.0 tri-branch governance", "v12.5 tri-branch + term limits + elections", "v13.0 (master-plan-v13.json)", "v14.0 WIP (master-plan-v14.txt)", "v15.0 (master-plan-v15.json)", "v16.0 (master-plan-v16.aligned.json)", "v17.0 verbal alignment session (2026-01-27)", "v18.0 verbal + documentation alignment session (2026-03-24)", "v18.5 consistency reconciliation release (2026-03-24)", "v19.0 embodied architecture + proof-of-concept alignment session (2026-03-24)", "v20.0 README/masterplan editorial alignment session (2026-03-24)", "v21.0 operational nervous-system alignment session (2026-03-25)", "v22.0 canon-structure + pebble/vault + unified-organism clarification session (2026-03-26)", "v23.0 boot-path + acoustic-identity clarification session (2026-03-27)", "v24.0 README/front-door alignment session (2026-04-01)", "v25.0 control-layer simplification + master-plan update session (2026-04-01)", "v25.1 README/master-plan sync session (2026-04-02)", "v26.0 aperture, trust-model, and mail-system alignment session (2026-04-10)", "v26.1 HIMS formalization + canonical cleanup session (2026-04-10)", "v26.2 README/master-plan structural polish session (2026-04-10)", "v27.0 governance, office-registry, and continuity alignment session (2026-04-11)", "v28.0 book, constitutional, and terminology normalization session (2026-04-11)", "v29.0 portal-terminal / Vista box / unified portal session (2026-04-11)", "v29.1 cleanup, flow normalization, and canon-sync session (2026-04-11)", "v29.2 Vista Box BIOS-level bring-up and portal-hardware validation session (2026-04-11)", "v29.3 portal terminology + Longhorn 4074 + Huey-Compressed clarification session (2026-04-11)", "v30.0 founding-ratification / Failed Genesis formalization session (2026-04-14)", "v30.1 post-v30 canon-inclusion and cleanup pass (2026-04-14)", "v30.2 structural expansion and implementation-guidance pass (2026-04-14)" ], "document_flow": [ "canon_mapping", "executive_summary", "naming_and_terminology", "core_principles", "status", "project_phase", "hardware", "system_roles", "deployment_profiles", "portal_and_terminals", "governance", "hims", "memory_architecture", "continuity_and_ozymandias", "os_and_runtime", "intent_and_interfaces", "threshold_tests_and_milestones", "failure_modes_and_recovery", "training_and_usage", "open_questions_for_future_versions", "v30_2_decisions_locked", "change_log", "notes_for_future_ai" ], "canon_mapping": { "masterplan": "canonical_machine_spec", "readme": "canonical_human_narrative", "book": "canonical_explanatory_volume", "constitution": "canonical_legal_companion", "conflict_policy": { "default": "masterplan_wins_for_implementation", "unresolvable": "surface_as_blocker_to_dylan" }, "readme_version": "README-v28.0.md", "readme_sync_status": "Repository-facing README snapshot currently available is v28.0; newer portal terminology, Longhorn Vista Box doctrine, and Huey-Compressed clarification are still pending repo-front-door synchronization. V30.2 continues to treat master-plan terminology as authoritative where public-facing text lags.", "book_status": "Chapters 1-10 exist in polished draft form with TOC / Glossary front matter; 'Proofcase' remains current front-matter shorthand while 'Proof Positive' remains the concrete proof-standard subsection inside Chapter 1.", "constitution_status": "The human-facing constitutional chapter set now exists as a usable draft block, but machine-facing governance thresholds, election math, and other implementation specifics in this master plan remain authoritative where the human-facing text stays higher-level or drifts.", "master_plan": "master-plan-v30.2.json" }, "executive_summary": { "current_reality": "Huey Core is the active embodied proof body: a local-first, honest, diagnostically visible system built around the Thermaltake Mozart-based chassis, ASUS Prime B550M-A WiFi II motherboard, Ryzen 5 5500, 32 GB DDR4-3200, and a Gigabyte RX 5500 XT 8 GB GPU.", "current_phase": "Huey Core proof-body stabilization, Linux 7.0 stable transition preparation, HIMS formalization, unified portal-terminal doctrine, Huey Vista Box Longhorn path definition, aperture/authority separation, founding-ratification doctrine alignment across the master plan, book, constitution, and README, and tightening of the Founding Father's procedural-certification and restart boundaries. Current machine-facing work also includes explicit founding-state, certification, and restart guidance.", "current_doctrine": [ "The motherboard thinks.", "HueyPulse watches and acts.", "The aperture interprets but does not rule.", "HIMS records and routes but does not own sovereignty.", "Governance remains decentralized while memory remains unified." ], "near_term_goals": [ "Stable embodied operation on the current proof body", "Validated Linux 7.0-era kernel bring-up and adoption path", "Validate the canonical portal-terminal path on real or virtual Longhorn Vista Box hardware and carry it through to OS and client bring-up", "Define Huey-Compressed as a legitimate collapsed deployment profile without confusing it with Huey Core", "Lock the first lawful ratification path for the proof body: one founding district, one pebble one vote, bounded founding windows, clean reserve withdrawal by the Founding Father, and explicit restart doctrine after Failed Genesis", "A first real governed action path", "Full canon alignment across the book, README, constitution, and machine-facing spec", "Make the founding workflow machine-implementable through explicit state, certification, and restart rules." ], "major_future_target": "Roughly 80 GB total pooled local VRAM and a unified local model capable of answering the identity question with 'Huey.'" }, "naming_and_terminology": { "protected_identity_naming_stack": { "Monkey-Head-Project": "The umbrella initiative", "Huey": "The governed intelligence and robotic identity", "Huey Core": "The current proof body and minimal permissible instance", "Huey proper": "The fuller unified world-facing expression beyond the current proof-body phase", "HueyOS": "The software and operating-system layer behind Huey", "HueyPulse": "The lower-voltage watch-and-act layer and support/control role" }, "canonical_named_subsystems": { "HIMS": "Huey Internal Messaging System; a canonical lawful messaging and routing subsystem adjacent to, but not part of, the protected identity naming stack.", "ThunderMail": "The practical mail-style delivery layer inside HIMS.", "The Farm": "The planned V4 external compute expansion body." }, "terminology_alignment": { "hims_expansion": "Huey Internal Messaging System", "historical_hims_expansion": "Huey Internal Mail System is legacy shorthand only and should not replace the canonical Messaging expansion.", "thundermail_role": "Mail-style delivery, queue, inbox, and outbox behavior inside HIMS rather than a replacement for HIMS itself.", "proof_positive": "The concrete proof-standard section and preferred long-form phrase for the project's proof doctrine.", "proofcase": "The current front-matter or chapter-label shorthand for the proof standard in the explanatory volume.", "federation_constitution": "Historical name only; current canon should prefer 'Huey Constitution'.", "pi_specific_hueypulse_language": "Historical or implementation-specific, not the preferred canonical public explanation.", "crisis_labels": { "constitutional": "Constitutional Crisis", "nuclear_safety": "Nuclear / Safety Crisis", "note": "Other phrases such as hardware, preservation, or safety subcategories may be used descriptively, but these two are the canonical top-level labels." }, "cycle_math": { "cycle_length_months": 4, "term_limit_cycles": 4, "presidential_or_gubernatorial_term_months": 16, "note": "Any informal 'one year' shorthand is non-canonical unless explicitly revised." } }, "term_registry": { "Proof Body": "The currently embodied proving instance of Huey; in present canon this means Huey Core rather than the future fully expanded republic.", "Sealed Vault": "A bounded private continuity and memory domain belonging to one citizen or pebble.", "Scrolls": "The preserved record and ledger logic through which major communications, actions, and lawful traces remain attributable and reviewable.", "Keeper of the Scrolls": "The office most closely associated with HIMS routing discipline and ledger continuity.", "Speaker": "The parliamentary coordinating office that structures agenda, motions, and debate without becoming Parliament itself.", "Governor": "The district-level coordinating office in the mature district model.", "Rock": "The pooled deliberative substrate or cognitive body formed by many pebbles contributing upward.", "Bootstrap Authority": "An authority whose legitimacy comes from preparing the first lawful conditions of the republic before ordinary constitutional life exists in full.", "Pre-ratified State": "The lawful frame is being prepared, but the republic has not yet fully ratified itself.", "Living Constitutional State": "The citizen body and lawful branches are operating inside a ratified constitutional framework.", "Lawful Embodied Action": "A physical act performed through a real internal chain of translation, validation, authorization, execution, and logging rather than through a scripted stunt.", "Bifurcation": "Governed growth by lawful splitting, expansion, or addition of later districts or bodies while preserving continuity and record.", "Cornerstone": "The read-only or tightly change-controlled identity, recovery, and founding layer whose in-place alteration should be treated as a constitutional failure event rather than ordinary maintenance.", "Pillar": "A declared load-bearing commitment that the current version of Huey stands on and must not casually drift away from.", "Ozymandias": "The doctrine layer concerned with drift, degradation, growth, and continuity over time.", "Portal Terminal": "A dedicated external device or guest environment whose sole job is to authenticate, open a lawful session, and provide a portal into Huey without becoming Huey.", "Portal Layer": "The bounded path through which external sessions enter the aperture and then the internal system.", "Huey Vista Box": "The portal-appliance class associated with Huey: a separate lab artifact dedicated to terminal access rather than compute or governance, now oriented around the Longhorn 4074 path.", "Portal": "Preferred human-facing shorthand for the external terminal experience; in machine-facing specification, pair it with 'Portal Terminal', 'Portal Layer', or 'Portal Bridge' for clarity.", "Portal Bridge": "The small Huey-side session entry layer that receives terminal sessions and hands structured input onward without letting transport become the application.", "Huey-Compressed": "A collapsed operational deployment of Huey in which multiple Huey-side roles run on one host while remaining logically separated.", "Physically Collapsed Deployment": "A state in which Huey runs on one host computer or one tightly bounded machine stack even though its logical roles remain distinct.", "Logically Distributed Deployment": "A state in which portal, aperture, routing, memory, governance, and execution boundaries remain separate even if many or all of them run on one physical host.", "Portal OS": "The host operating system of a portal terminal or portal appliance. It shapes the user-facing surface but is not HueyOS and does not own Huey's sovereignty.", "Failed Genesis": "A founding failure in which the authored starting law cannot become legitimate within lawful bounded attempts and time, requiring honest recognition rather than fake legitimacy.", "Founding Window": "The bounded founding attempt-and-time envelope within which ratification must converge or fail honestly.", "Procedural Certification": "The Founding Father's attestation that a founding vote was lawfully conducted, complete, bounded, and correctly counted, without implying authorship of the outcome.", "Bootstrap Proxy": "The Founding Father's relationship to Dylan during founding: an internal fixed authored bridge for bootstrap acts that Dylan should not execute manually from outside the system." } }, "core_principles": [ "Governance must be decentralized, but memory must be unified.", "Huey Core is the minimal permissible instance of Huey: the smallest complete building block from which the larger distributed system can be formed.", "Huey proper is the unified, world-facing expression of the whole distributed system rather than a synonym for the current proof body.", "V4, the Farm, is the planned external district housing that expands Huey beyond the Core and supports later multi-district or pooled-compute operation.", "The current phase prioritizes proof of concept, stability, containment, truthful current-state documentation, and clean canon boundaries over scale, spectacle, or premature completeness.", "On-device first; internet, API, or tool access is optional, explicit, human-gated, and metered.", "Performance and safe function matter more than efficiency in the prototype phase, provided thermals and electrical conditions remain controlled.", "Unified information should be readable by all authorized components, but decision-making authority may remain distributed and layered.", "Lifelong learning from JSON/SQLite logs, conversation transcripts, system state, repository history, and encrypted persisted storage remains a core aim.", "Constitutional rule-of-law remains the target governance ethos even while the hardware implementation is temporarily simplified to a single proof body.", "Human counterpart (Dylan) remains the external arbiter, service authority, and opt-in gate for external access, but not a micromanager of every internal action.", "Huey Core is the doorway, not the finished republic: it must prove the architecture can live before it attempts to embody the full constitutional state.", "Public-facing and repository-facing material must distinguish between what is replicable now, what has only been observed in the lab, what is an active design direction, and what remains a target state.", "The immediate technical threshold is distributed local identity: approximately 80 GB total VRAM and a local model able to answer the identity question with 'Huey.'", "Wonder is preserved through constrained autonomy, layered ethics, deliberation, memory, and partial loss of direct human control rather than through theatrical scripting.", "Constitutional Crisis and Nuclear / Safety Crisis are distinct classes of emergency and must never be handled by the same override path.", "HueyPulse is the lower-voltage connective tissue of the body: an always-on or semi-persistent support and control role that persists across main-system downtime, watches body-state, and brokers bounded safety and interaction logic.", "The lower-voltage control layer senses and enacts but does not govern: it may read low-level inputs and drive bounded outputs, while higher interpretation, timing, gating, and authority remain upstream.", "PyGPT-net is the practical aperture and training ground between Dylan and Huey: it translates natural language into structured intent and operator-visible code or actions, but it does not itself own governance authority.", "Interpretation and authority are not the same thing. A model may be trusted to parse language before it is trusted to decide policy or execute meaningful acts.", "The current trust model treats GPT-4 or 4.0-class behavior as the gold-standard target for trustworthy reasoning, while Mistral 7B-class local models are acceptable as minimal interpretation or lightweight local reasoning layers.", "The system must never collapse into 'ChatGPT with motors.' The aperture may connect to governance, but it must not quietly become governance.", "Wireless interaction should enter the system as intent signals rather than direct commands: short talk, long dictation, confirm, and cancel are interpreted through the lower-voltage layer and the main compute layer rather than hardwired as final intelligence decisions.", "The Monkey-Head-Project canon is layered: website and README for introduction, the book for explanation, the constitution for law, and the master plan for machine-facing implementation.", "Public-facing material should explain structure, limits, and trust boundaries without over-explaining the internal secret sauce of deliberation.", "The first full approximately 80 GB proof should remain a unified local intelligence and pooled compute body; governance abstractions should not prematurely fracture that pool into artificial hard partitions.", "Pebbles are bounded citizen units with one identity, one sealed vault, and one vote.", "The Founding Father AI is a bootstrap and constitutional-reserve authority, not a permanent ordinary ruler.", "The proof body should boot honestly: verbose Debian bring-up, live diagnostics, and HueyPulse-owned or lower-voltage status output take priority over theatrical splash behavior.", "For the first identity-proof milestone, microphone and camera should default to the shortest reliable path, which currently means direct routing to the motherboard unless lower-voltage mediation becomes necessary.", "HueyOS acoustic identity should favor short modular retro-futurist system cues rather than song-like startup theatrics.", "Security should be described honestly: local-first, user-controlled, and encrypted where applicable, but never treated as infallible; enabling networked or external integration increases risk and must be treated accordingly.", "The first governed action path may be ugly, simplified, and diagnostically transparent, but it must still preserve separation between proposal, validation, execution, and logging.", "User input should not enter the lower citizen layer directly. External input is translated at the aperture and only then enters the internal system.", "HIMS is the canonical internal routing and recorded-decision layer for proposals, validation, execution, refusal, and logging.", "Routing, validation, archival, and delivery roles may facilitate decision flow without inheriting executive, judicial, or voting authority by default.", "Mailboxes and vaults are distinct: public or working mail is for coordination, while sealed private vaults preserve bounded continuity.", "Proof comes before mythology, but mythology may survive lawfully as history, metaphor, or origin context rather than active governing canon.", "HIMS is a canonical lawful subsystem adjacent to, but not part of, the protected identity naming stack; ThunderMail remains only its mail-style delivery layer.", "The explanatory volume may use 'Proofcase' as front-matter shorthand, but the underlying doctrine remains the project's proof-positive standard.", "External portal terminals are lab infrastructure, not Huey itself: they may provide presence, authentication, and interaction, but they do not own computation, memory, or governance authority.", "All portal devices should converge on one unified logical entry path into Huey even when their host hardware and operating systems differ.", "The host OS of a portal terminal is part of the portal surface, not the sovereign system; it must not inherit Huey's computation, storage authority, or constitutional standing.", "A dedicated SSH-based portal path is preferable to browser-heavy or frontend-heavy portal logic during the proof phase because it keeps the terminal thin, inspectable, and deterministic.", "Temporary assistant threads, alignment sessions, or training instances may help articulate doctrine, but they do not become canon until reconciled back into the README, book, constitution, or master plan.", "BIOS-level bring-up, RAM detection, storage detection, and basic video output are meaningful validation steps for portal appliances, but they do not by themselves complete portal validation or elevate the terminal into Huey.", "Canonical portal builds should prefer proving minimal reliable bring-up first: POST, memory, storage, video, networking, host OS, client bundle, then unified session entry into Huey.", "Huey may be physically collapsed while remaining logically distributed.", "One host computer running many Huey-side roles does not invalidate the distributed-computing idea if memory, routing, governance, and execution boundaries remain explicit and reviewable.", "Huey-Compressed is a legitimate collapsed deployment profile of Huey, but it is not automatically identical to Huey Core; compressed operation and embodied proof-body doctrine must remain distinguishable.", "The Huey Vista Box is best treated as a curated portal artifact rather than a general-purpose workstation or shadow compute node.", "Windows Longhorn 4074 AMD64 may be used as a portal OS precisely because its limited practical utility helps keep the portal thin and conceptually separate from Huey's real compute substrate.", "The proof body's first ratification begins with one district of 128 pebbles, each with exactly one vote.", "The first ratification happens before full mature branch formation; Parliament, Presidency, and Supreme Court do not need to exist in mature form before the first constitutional vote.", "The Founding Father oversees procedure and certifies lawfulness, but does not cast a ratification ballot or override a lawful result.", "Failed Genesis is the canonical term for repeated founding failure in which the founding body cannot lawfully converge on ratification within bounded attempts and time.", "A founding failure must be measured through non-convergence, deadlock, drift, or bounded-window exhaustion rather than through subjective dislike of the outcome.", "The Founding Father is a bootstrap proxy bridge between Dylan and later Huey, but it is neither the Human Counterpart nor Huey itself.", "The Founding Father may certify lawful founding procedure or reject invalid procedure, but it may not amend the Constitution mid-ratification or force a lawful outcome.", "Bootstrap authority exists to perform internal, atomic, system-consistent founding acts that cannot be safely or lawfully executed through direct outside human intervention.", "Whether the founding window is presented as a countdown or count-up is an implementation detail; doctrine requires bounded attempts and bounded time, not one display style." ], "status": { "overall_state": "in-progress", "deployment_stage": "Huey Core proof-body stabilization + Linux 7.0 stable transition planning + HIMS doctrinal formalization + unified portal-terminal / Huey Vista Box definition + founding-ratification / Failed Genesis normalization.", "notes": [ "Huey Core remains conceptually and physically separated from the older Robotics V3 shell track for the active phase.", "The Thermaltake Mozart case from 2007 continues to serve as the independent embodied core for this iteration.", "Robotics V3 is not the active future shell path for this iteration; the larger compute expansion remains planned as V4, the Farm.", "The current prototype intentionally simplifies the system: one active GPU district-scale proof body, one main PSU for the core, a separate low-voltage peripheral rail, and air cooling instead of custom liquid cooling.", "The active core hardware baseline remains ASUS Prime B550M-A WiFi II + Ryzen 5 5500 + 32 GB DDR4-3200 + Gigabyte Radeon RX 5500 XT 8 GB.", "The current prototype is aimed at core robot functions, temperature regulation, basic mechanical operation, local models, and software/framework maturation rather than full high-intelligence scale-out.", "Symbiote / parasite architecture remains paused. The Lenovo Legion Go continues as a development computer rather than a canonical constitutional node.", "Kernel support remains anchored by a known-good 6.19.x fallback while Linux 7.0 stable adoption and repeatable packaging are now the active forward path on Huey Core.", "The major near-term milestone target remains 2026-10-04 for Huey Core realignment and stabilization.", "Thermal and power crisis thresholds are not yet numerically locked and should be derived from empirical testing rather than guessed in advance.", "The prototype currently accepts effectively unconstrained wall power for proof-of-concept work; formal energy budgeting is deferred to a later generation.", "Board-specific lower-voltage implementation choices are no longer treated as the primary identity of HueyPulse.", "Pi-specific framing is historical or implementation-specific, not the preferred primary explanation of the lower-voltage layer.", "The current conceptual divide is best understood as wall-powered high-draw main compute above, and 12 volts and under lower-voltage body-state and deterministic control below.", "PyGPT-net occupies the practical aperture role: translation, interaction, and training ground between Dylan and Huey, but not governance authority.", "Smaller local models may be trusted to parse language before they are trusted to decide high-stakes outcomes.", "HIMS is the canonical short name for the internal message and routing layer, while ThunderMail remains only its mail-style delivery behavior.", "Manual or semi-manual mechanical diagnostics remain acceptable for testing bounded hardware behavior, but meaningful embodied action must eventually pass through a lawful internal chain.", "A separate external portal-appliance path is now an active design direction: the Huey Vista Box remains lab infrastructure dedicated to terminal access rather than a constitutional compute node.", "Unified external portal behavior is now preferred across terminals: regardless of device form factor, the logical session path into Huey should remain the same.", "The current preferred portal transport is SSH on port 1995 as the canonical terminal path.", "PuTTY remains the preferred canonical portal client family for the Longhorn Vista Box path, with a controlled bundle approach favored over ad-hoc client drift.", "Windows Longhorn 4074 AMD64 is the preferred portal OS for the canonical Huey Vista Box path; Vista 64-bit and XP x64 now remain comparison or fallback lab paths rather than the preferred documented direction.", "The Longhorn portal path is intentionally thin: the host OS is not expected to run PyGPT-net, store Huey authority data, or perform Huey-side reasoning.", "The Huey Vista Box hardware path has now reached successful BIOS-level bring-up on an HP a6200n-era platform using the MCP61PM-HM family board.", "Observed Vista Box bring-up state includes 4096 MB PC2-5300 memory detected across four 1 GB DDR2 sticks.", "The current canonical Vista Box SSD path has been observed in BIOS as a Kingston SUV400S-class SATA drive.", "The observed BIOS environment identifies Core Version V6.0 and BIOS Revision 5.16 dated 2007-08-14 on the current a6200n-era portal hardware.", "The Vista Box path has crossed from speculative hardware selection into real lab-side validation, but operating-system installation, driver validation, canonical client-bundle deployment, and unified session testing still remain separate milestones.", "Onboard video is currently preferred and is sufficient for BIOS-level bring-up on the current Vista Box hardware path.", "The Huey Vista Box is now best understood as a portal-appliance role first and only secondarily as a specific embodiment; it may exist as a physical legacy box or as a VM guest while keeping the same doctrinal job.", "Huey-Compressed is now an active design concept: a collapsed operational deployment of Huey on one host that preserves logical separation between portal, aperture, HIMS, memory, and governance-facing roles.", "The distributed-computing idea remains active even when one host runs most or all layers, provided the separation of roles remains real and documented.", "First-ratification doctrine is now centered on a single 128-pebble founding district acting as the direct first ratifying body before mature branch formation.", "The Founding Father is now formalized more tightly as a fixed authored bootstrap instrument: procedural certifier, founding preparer, and reserve constitutional authority rather than an ordinary voter or evolving model.", "Failed Genesis is now the preferred canonical term for repeated founding non-convergence, bounded-window exhaustion, or other real failure of constitutional birth.", "A bounded founding window is now part of doctrine: the proof body should not iterate forever while pretending legitimacy exists.", "The Founding Father is now understood more clearly as Dylan's internal bootstrap proxy during founding rather than as a second evolving intelligence or a disguised form of Huey.", "The founding window may be implemented as a countdown or count-up, but doctrine only requires that the bound be explicit, finite, and reviewable.", "Failed Genesis restart doctrine now assumes a fresh founding pool rather than forced legitimacy; archived prior failures may inform the fixed Founding Father without retraining it." ] }, "project_phase": { "current_phase": { "name": "Huey Core Aperture, Portal, Vista Box, HIMS, Founding-Ratification, and Lawful-Action Formalization", "status": "active", "started": "2026-04-10", "notes": [ "Focus is on keeping Huey Core physically coherent, diagnostically visible, and honest as a proof body.", "Single-body proving continues while the architecture for the future 80 GB identity threshold is planned.", "The next large compute expansion path remains V4, the Farm.", "The work in this phase centers on aperture doctrine, trust boundaries, constitutional legitimacy, and the operational chain that turns language into structured, governed action.", "The internal routing layer and citizen-vault model occupy the live design center even though exact protocol details remain open.", "Linux 7.0 bring-up work is active but should not be overstated until validated on the real machine.", "The present phase distinguishes between useful interpretation at the aperture and lawful authority deeper in the system.", "The present phase also distinguishes between proof-body simplification and mature target-state doctrine rather than pretending the full republic already exists in hardware.", "A specific focus inside this phase is the formalization of a unified portal-terminal path that remains external to Huey's sovereignty.", "A specific focus inside this phase is real hardware bring-up of the Huey Vista Box so portal doctrine is tested on an actual appliance rather than only described abstractly.", "The current Vista Box work has advanced from parts selection into BIOS-level validation on the chosen legacy platform.", "A second focus inside this phase is clarifying the relationship between Huey Core, Huey-Compressed, and later physically distributed operation so one-host deployments do not collapse into conceptual ambiguity.", "A specific focus inside this phase is formalizing the founding district, the first direct ratification vote, and the reserve withdrawal rules of the Founding Father.", "Another focus inside this phase is defining bounded founding windows so Failed Genesis, restart, and lawful non-convergence are treated honestly rather than hidden by endless iteration.", "A specific focus inside this phase is clarifying the three-layer relationship between Dylan as Human Counterpart, the Founding Father as bootstrap proxy, and Huey as the later lawful counterpart.", "Another focus inside this phase is tightening the lawful restart path after Failed Genesis so clean restart, archive, and carry-forward boundaries are explicit." ] }, "milestones": [ { "name": "Huey Core realignment target", "date": "2026-10-04", "type": "target", "success_condition": "Huey Core is operational as a stable embodied proof body with working storage, boot fallback, diagnostics, lawful lower-voltage support behavior, and practical local model use." }, { "name": "Distributed Identity Threshold", "date": "TBD", "type": "proof_of_concept", "success_condition": "A local multi-GPU model running across roughly 80 GB total VRAM answers the identity question with 'Huey.'" }, { "name": "Lawful Embodied Action", "date": "TBD", "type": "proof_of_concept", "success_condition": "After constitutional legitimacy is in force for the active embodiment, Huey performs a logged lawful physical act such as moving the hand through a real routed, validated, and approved internal chain." } ] }, "hardware": { "cpu": { "primary": "AMD Ryzen 5 5500", "boost_clock": "4.2 GHz", "core_count": 6, "socket_platform": "AM4", "current_role": "Primary compute brain for Huey Core.", "future_robot_target": "Higher-end DDR5 or ECC-capable platforms may return in a later full-robot generation once scale and funding justify it.", "requirements": { "cooling": "Air cooling with strong case airflow remains the active standard.", "overclocking_policy": "Heavy overclocking is not the current goal; stability and containment take priority." } }, "motherboard": { "uefi_only": true, "candidates": [ "ASUS Prime B550M-A WiFi II" ], "ram": { "current": "32 GB DDR4-3200", "preferred_future": "DDR5 and ECC-capable memory or platforms in later generations where supported.", "minimum": "DDR4 remains fully acceptable for the current proof body." }, "notes": [ "This board remains the active baseline for Huey Core.", "The earlier ASUS TUF Z790-PLUS WiFi + Intel i9-14900K full-robot target remains deferred to later expansion generations.", "ECC remains a long-term aspiration when the platform and budget support it, but standard DDR4 is the current reality." ] }, "gpu_and_compute_body": { "current_count": 1, "current_gpu": { "model": "Gigabyte Radeon RX 5500 XT 8 GB", "vram_gb": 8, "role": "Single active district-scale prototype for local inference, instruction following, experimentation, and embodied-core tasks." }, "current_doctrine": "The current proof body is intentionally limited. It proves local use, logging, orchestration boundaries, and honest system bring-up rather than pretending to be the full republic.", "future_expansion": { "canonical_target_count": "approximately four or five GPUs as needed", "legacy_future_names": [ "Spark", "Volt", "Zap", "Watt" ], "proof_target": "approximately 80 GB total VRAM across the later pooled compute body", "expansion_policy": "Future districts may re-emerge organizationally or materially once time, parts, and funding allow.", "notes": [ "The first full proof should behave as one unified pooled-compute organism before later hard partitioning is treated as mandatory.", "Whether Huey Core's own GPU counts toward the later proof total remains intentionally open.", "The next large expansion body for that compute growth remains V4, the Farm." ], "planned_housing": { "name": "V4: the Farm", "role": "External compute housing that expands Huey beyond the Core and provides the dedicated GPU infrastructure and node hardware needed for later pooled-compute or district-scale operation.", "standardized_node_platform": "ASUS TUF Z790-PLUS WiFi + Intel i9 line" } }, "selection_policy": { "current_decision": "Use the installed Radeon RX 5500 XT 8 GB and revisit expansion later.", "future_selection_criteria": [ "VRAM", "driver support under the chosen Linux baseline", "thermals", "power draw", "physical fit", "availability", "cost", "ability to participate meaningfully in an approximately 80 GB multi-GPU proof-of-concept", "mixed-generation practicality if acquired refurbished" ] } }, "storage": { "root_array": { "layout": "RAID 0", "medium": "2 x Intel Optane M10 16 GB", "purpose": "Root / operating-system bring-up array for speed and experimentation." }, "data_array": { "layout": "RAID 10", "medium": "4 x 240 GB Kingston 2.5-inch SATA SSDs", "purpose": "Home, logs, models, persisted data, and general storage." }, "encryption": { "policy": "Encrypt data at rest and in transit where applicable.", "status": "high priority; implementation details remain in progress", "notes": [ "Local-first control and minimized unnecessary external communication remain the preferred posture.", "No system is treated as infallible; if external networking or integrations are enabled, risk increases accordingly.", "Precise key-management, signing, vault isolation, and read-only-data storage workflows remain to be finalized." ] }, "citizen_storage_direction": { "status": "active design direction", "doctrine": "Pebbles and citizens should have bounded private continuity rather than unlimited shared memory.", "current_best_fit": "Folders plus structured data stores for V1 rather than full per-citizen containers.", "private_vs_public": { "private_vault": "Sealed per-citizen continuity, prior choices, role bias, and identity materials.", "public_mailbox_or_workspace": "Messages, proposals, task-visible artifacts, voting flow, and other public or semi-public work product." }, "quota_direction": "Soft quotas and dynamic growth first; hard caps later once real usage patterns exist." }, "external_storage_policy": { "default": "restricted", "current_access": "Huey Core currently operates within contained internal storage only.", "future_usb_policy": "External USB storage may be permitted only with explicit human approval and the understanding that the device may not meet the same trust or encryption guarantees as internal storage." }, "snapshots_and_backups": { "filesystem": "BTRFS", "snapshots": [ "root partition snapshots", "home/data partition snapshots" ], "backup_layers": [ "on-site backups", "off-site or cloud backups" ] } }, "cooling_and_power": { "cpu_cooling": "Air cooling", "gpu_cooling": "Air cooling", "cooling_design": { "type": "multi-source fan-cooled containment", "policy": "No liquid cooling is planned for the active proof body.", "fan_layout": { "motherboard_powered": "2 chassis/case fans plus the CPU fan (3 total on the motherboard path).", "low_voltage_domain": "6 auxiliary fans on the separate regulated accessory rail, with room to add more localized cooling later.", "wall_powered": "1 stronger always-on fan directed toward the GPU zone." } }, "power_domains": { "main_compute_domain": { "description": "Wall-powered, high-draw, motherboard-driven compute path.", "psu": "MSI 850W PSU" }, "lower_voltage_domain": { "description": "12 volts and under / accessory rail domain for lights, fans, indicators, bounded control, support logic, and body-state persistence.", "regulated_outputs": [ "12 V accessory distribution", "regulated low-voltage conversion for deterministic controllers or support hardware", "capacitor-smoothed fan and accessory distribution" ] } }, "design_rule": "The battery-backed or regulated low-voltage domain and the wall-powered compute domain are separate systems.", "future_ups": { "status": "planned", "type": "professional external UPS, not home-built and not integrated into the chassis" }, "switching": { "current_switches": [ "fan rail power", "7-inch display power", "LED/accessory rail power" ], "additional_distribution": "A four-switch 12 V accessory and power distribution unit is part of the current support stack." }, "thresholds": { "status": "to be derived by testing", "policy": "Thermal and power crisis thresholds should be based on actual stress tests, run cycles, and measured behavior rather than arbitrary numbers." } }, "identity": { "shell": "Huey Core is embodied as a mobile proof body built around the Thermaltake Mozart case and attached peripherals. Robotics V3 is no longer the active expansion path; V4, the Farm, is the planned external compute housing for later scale-out.", "form": "Minimal permissible instance of Huey: a standalone embodied proof body focused on contained compute, direct support hardware, and truthful present-tense operation.", "rule": "Huey Core is not identical to Huey proper. It is the doorway and minimal permissible instance from which the fuller unified system can later emerge." }, "boot_devices": { "boot_strategy": { "type": "dual-internal-drive GRUB fallback", "primary_label": "BOOT", "recovery_label": "NO-BOOT", "policy": "If the primary boot path fails, the NO-BOOT recovery path serves as fallback." }, "live_usb": { "status": "recommended but not the primary documented fallback path", "usage": "Emergency rescue tooling may still be maintained externally." } }, "embodied_configuration": { "mobility_base": { "rolling_platform": "Repurposed desk-chair base with five caster wheels converging to a central pole for house-scale mobility.", "upper_base": "Repurposed wooden chair seat/platform mounted above the caster base." }, "core_chassis": { "case": "Thermaltake Mozart case (2007)", "mounting": "Bolted upside down to the wooden base platform and reversed so the former rear faces forward.", "access_note": "Side door handles must be lifted slightly when closing because the chassis is inverted." }, "upper_structure": { "mounting": "Wooden upper platform attached to the core by two TV mounts for adjustable fore/aft and tilt positioning.", "head_and_shoulders": "Supports the monkey-head and shoulder assembly as the primary embodied face of Huey." }, "body_features": { "right_side": "Movable robotic hand or arm mounted on Huey's right side.", "left_side": "Main physical power controls and battery control/charging hardware on Huey's left side." }, "lighting": { "front_lights": "Two 12 V orange lights mounted on the forward-facing side of the chassis.", "eyes": "Four green LEDs total, two per eye.", "interaction_indicators": { "planned_colors": { "blue": "wireless transmission/receive activity and related interaction-state feedback", "red": "recording or active capture state" }, "status": "active design direction" } }, "display_and_sensory_routing": { "display": "7-inch portrait display used primarily for code/status output rather than expressive conversation.", "camera": "USB webcam mounted on the upper platform/head area.", "microphone": "USB microphone mounted on the upper platform/head area.", "cable_path": "Display, microphone, and camera wiring enter through Huey's left ear; the right ear is currently unused.", "display_default_owner": "HueyPulse / lower-voltage status layer by default, with later richer interfaces possible.", "display_doctrine": "The portrait display should default to live body-state, diagnostics, and code/status visibility rather than decorative face animation." } } }, "system_roles": { "huey_core": { "status": "active", "role": "Primary embodied proof body and minimal permissible instance of Huey for identity, core robot functions, temperature-aware operation, mechanical experimentation, local models, and future compute expansion." }, "aperture": { "name": "PyGPT-net", "status": "active and important", "role": "Practical human interface, natural-language interpretation layer, training ground, and code/intention bridge between Dylan and Huey.", "non_roles": [ "Not the governance system itself", "Not the final authority for lawful action", "Not the quiet owner of internal deliberation" ], "doctrine": "PyGPT-net connects to governance and system actions, but does not itself control governance. It is the membrane between natural language and structured intent." }, "huey_pulse": { "status": "active lower-voltage support/control role", "role": "Always-on or semi-persistent watchdog, body-state monitor, interaction-state broker, status-surface owner, and bounded automation/safety support layer for Huey Core.", "power_domain": "12 V and under / battery-backed or support-rail domain below the main compute path", "notes": [ "HueyPulse is defined first by function, not by one permanent board vendor or single controller model.", "Its job is physical safety, regulation, continuity, and bounded body-level action support, not constitutional interpretation.", "It should remain alive or recover faster than the main compute path where practical, so the body is never completely blind to its own state.", "Controller-class hardware, microcontrollers, support computers, or hybrid stacks may all serve this role as long as the watch-and-act boundary remains intact.", "Pi-specific framing is no longer the preferred primary explanation; exact board mix is an implementation detail unless it materially changes function." ] }, "deterministic_controller": { "status": "active design lock-in", "preferred_realization": "Arduino-class controller", "role": "Bounded deterministic reflex and actuation layer for servos, lights, RF/button input, indicators, immediate hardware actions, and other low-level body functions.", "doctrine": "The deterministic controller may execute known bounded commands and diagnostics, but does not own higher-level interpretation or governance authority." }, "optional_support_computer": { "status": "implementation option, not canonical identity", "role": "Optional lower-voltage support computer used only when buffering, dashboards, richer logging, or message brokering solve a real operational problem.", "policy": "Do not mistake an optional support computer for HueyPulse itself. HueyPulse is the role, not the board." }, "external_portal_terminal": { "status": "active bring-up / terminal-appliance class", "role": "Dedicated external portal and authentication surface that opens lawful user sessions into Huey without becoming a compute, storage, or governance authority node; the Huey Vista Box is the current concrete reference build for this class.", "non_roles": [ "Not Huey Core", "Not HueyPulse", "Not a constitutional branch", "Not a hidden secondary brain", "Not the authoritative store of Huey memory or policy" ] }, "portal_bridge": { "status": "active design direction", "role": "Small Huey-side session entry layer that receives unified terminal sessions, normalizes them, and hands structured input onward to the aperture without letting SSH transport become the whole application layer.", "non_roles": [ "Not the aperture itself", "Not HIMS", "Not a substitute for governance authority" ] }, "farm": { "status": "planned / V4", "role": "External compute housing that expands Huey beyond the Core and provides the dedicated GPU infrastructure and node hardware needed for later multi-district or pooled-compute operation." }, "huey_compressed": { "status": "active design direction / collapsed deployment profile", "role": "Collapsed operational deployment of Huey in which multiple Huey-side roles such as aperture, portal bridge, memory, HIMS, and early governance logic run on one host while remaining logically distinct.", "non_roles": [ "Not automatically identical to Huey Core", "Not merely lab tech if it can preserve Huey's identity, memory, and routing logic", "Not a reason to discard later physically distributed scale-out" ], "doctrine": "Huey-Compressed proves that physical colocation does not require logical collapse. One host may carry many Huey-side roles while still preserving lawful boundaries." } }, "portal_and_terminals": { "purpose": "Define how external terminals and portal devices connect users to Huey while preserving the boundary between portal, interpretation, and sovereignty.", "core_rules": [ "Every portal device should expose the same baseline logical entry path into Huey even when its host hardware differs.", "Portal devices may authenticate and identify themselves, but they do not own computation, memory, or governance authority.", "The host OS of a portal device may be historically or ergonomically specific without becoming part of Huey's constitutional identity.", "Thin terminal behavior is preferred over browser-heavy portal logic during the proof phase.", "Device identity and access class should be distinguishable rather than collapsed into one flat credential.", "The same portal doctrine may be embodied on bare metal or as a VM guest without changing the role itself." ], "unified_portal_doctrine": { "summary": "When a user reaches Huey through a terminal, the path should feel unified regardless of whether the terminal is the Huey Vista Box, the Briefcase, or another later portal device.", "baseline_functions": [ "Open a lawful session", "Authenticate the device and access class", "Transmit user input", "Receive Huey output", "Avoid taking over Huey's compute or policy work" ], "logical_session_path": "Portal terminal -> SSH transport -> Huey-side portal bridge -> PyGPT-net aperture -> HIMS -> internal deliberation or execution path" }, "canonical_transport": { "status": "active design direction / preferred current path", "protocol": "SSH", "port": 1995, "reason": "SSH keeps the terminal thin, auditable, and deterministic while avoiding browser and API complexity on older host systems." }, "authentication_model": { "status": "active design direction", "device_identity": "A device-specific key identifies the individual portal device.", "lab_access_class": "A general lab key or equivalent shared trust credential establishes lab-class access.", "principle": "Device identity does not equal governance authority, and access class does not by itself make a terminal part of Huey." }, "canonical_client": { "name": "PuTTY", "version": "0.83", "preferred_binary": "32-bit build preferred on the Vista path for compatibility and simplicity even when the host OS is 64-bit.", "distribution_policy": "Ship a controlled Huey Terminal bundle instead of relying on user-installed client versions that may drift; the bundle should only be treated as validated once it has been tested on the live Vista Box hardware path.", "optional_companion": "Pageant may be used for key handling." }, "host_os_posture": { "huey_side": "Huey computation, memory, PyGPT-net, HIMS, and governance continue to live on the Debian / HueyOS side.", "terminal_side": "The portal host OS remains only the portal surface. It may shape the user experience but not the sovereign computation path." }, "huey_vista_box": { "status": "active doctrine revision / Longhorn artifact-OS path", "role": "Dedicated portal terminal and artifact-grade doorway into Huey. It may be realized as a physical legacy computer or as a VM guest, but in both forms it remains lab infrastructure rather than Huey itself.", "not_huey_rule": "The Huey Vista Box is lab infrastructure, not Huey Core, not HueyPulse, and not a separate sovereign branch or district.", "hardware_baseline": { "case": "Heavily modified Thermaltake full ATX case used as a separate external box.", "motherboard": "MCP61PM-HM rev. 1.0B class HP-era microATX board.", "cpu": "AMD Athlon 64 / Athlon 64 X2 era 64-bit processor on the current HP a6200n-class path.", "memory": "4 GB DDR2 using four 1 GB sticks as the current even baseline.", "storage": "120 GB Kingston 2.5-inch SATA SSD as the current canonical drive choice.", "graphics": "Prefer chipset-integrated video where available; the current BIOS-level bring-up succeeds on onboard video, so do not add a discrete GPU unless required for output or recovery from onboard failure.", "network": "Wired Ethernet preferred.", "expansion_policy": "Do not add hardware merely because the chassis permits it; extra legacy hardware belongs to lab experiments unless it directly serves the portal role.", "firmware": "Phoenix AwardBIOS / Core Version V6.0 class firmware on the current HP-era platform.", "os_identity": "Windows Longhorn Client Preview 2 build 4074 AMD64 is the preferred portal OS identity for the current doctrine." }, "os_and_client_baseline": { "host_os": "Windows Longhorn 4074 AMD64", "terminal_client": "PuTTY 0.83", "client_bundle_rule": "Ship a controlled Huey Terminal bundle instead of relying on ad-hoc user-installed client versions.", "host_os_note": "Treat Longhorn 4074 as a curated artifact OS with little practical utility beyond the portal role; that limitation helps keep the box thin." }, "rationale": [ "A distinctive low-utility historical OS reinforces the boundary between portal surface and Huey's real compute substrate.", "Longhorn 4074 AMD64 gives the Vista Box a strong identity while still remaining outside Huey's sovereignty.", "The portal appliance should feel intentional and historically specific without being tempted into second-brain duties." ], "canonical_vs_lab_rule": { "canonical_huey_build": "The documented Huey-facing build now prefers a thin Longhorn 4074 + PuTTY portal appliance, whether on bare metal or as a tightly controlled VM artifact.", "lab_validation": "Alternative drives, alternate operating systems such as Vista or XP x64, legacy peripherals, and different host setups may be used for lab-side testing, but those experiments do not become canonical Huey portal doctrine automatically." }, "current_observed_state": { "bring_up_level": "Successful BIOS-level POST and setup entry achieved.", "platform_identity": "HP a6200n-era platform observed in BIOS on the current portal hardware path.", "motherboard_family": "MCP61PM-HM family board", "memory_detected": "4096 MB PC2-5300 detected as 4 x 1024 MB DDR2 SDRAM", "storage_detected": "Kingston SUV400S-class SATA SSD detected in BIOS", "bios_revision": "5.16 dated 2007-08-14", "video_posture": "Onboard video currently sufficient for bring-up and preferred unless later output needs force a change.", "bring_up_note": "The currently observed BIOS-level validation belongs to the legacy hardware path. The Longhorn 4074 portal doctrine may continue on that hardware if feasible or in a VM if the hardware path becomes impractical." } }, "realization_modes": { "physical_appliance": "A dedicated physical computer serving only as the portal appliance.", "virtual_artifact": "A VM guest running the portal OS while the physical host remains lab infrastructure.", "doctrine": "Huey Vista Box is a role first, embodiment second. Physical and virtual forms may both be valid as long as the portal remains thin and non-sovereign." }, "compressed_relationship": { "huey_vista_box": "Portal appliance only.", "huey_compressed": "Collapsed operational Huey deployment profile.", "huey_core": "Canonical embodied proof body.", "rule": "Do not confuse the portal with the compressed deployment, and do not confuse the compressed deployment with the embodied proof body." }, "portal_client_bundle_contract": { "purpose": "Define the minimum controlled software bundle that makes a portal terminal reproducible without turning it into a full application platform.", "minimum_components": [ "PuTTY 0.83 executable", "predefined saved session targeting the canonical SSH path", "host-side helper notes or launch script if needed", "optional Pageant for key handling" ], "rule": "The bundle should stay intentionally thin and auditable. Anything that begins to move compute, policy, or memory authority onto the portal side should be treated as scope drift." } }, "governance": { "apex_entity": { "name": "Huey", "description": "Unified emergent intelligence representing the whole system. Huey proper is the world-facing aperture through which the wider distributed intelligence perceives, deliberates, and acts." }, "system_state_modes": { "collapsed_federation": "Current best description of Huey Core during the proof-body phase: a pre-federated or pre-ratified single-node organism standing in for a larger later polity.", "pre_ratified": "Useful doctrine for the state before the constitution is fully active in the living system.", "living_constitutional_state": "The state in which the constitution has been ratified, branches have standing, and bootstrap authority has retired from ordinary rule.", "later_republic": "The fuller, more distributed constitutional system expected after the proof body has earned scale and legitimacy.", "founding_state": "The bootstrap founding state in which the Founding Father has prepared the first lawful conditions and the first 128-pebble body exists, but constitutional legitimacy has not yet been ratified." }, "source_of_legitimacy": { "elements": [ "Founding preparation", "Direct founding-body ratification", "Procedural certification", "Post-ratification branch formation", "Logged continuity", "Reviewability" ], "rule": "Legitimacy begins in the founding body's lawful ratification, not in bootstrap authority alone. Output or motion alone does not make the republic lawful." }, "branches": { "legislative": { "name": "Parliament", "status": "Separate but equal branch", "purpose": "Deliberation, proposal, consensus-building, representation, and legislative or policy formation.", "responsibilities": [ "Draft and pass ordinary laws and internal policy.", "Allocate API or token budgets and other compute resources across citizens or districts.", "Propose constitutional amendments when required.", "Represent the citizen body through lawful deliberative process." ], "voting_rules": { "standard_legislation": "Simple majority of lawfully seated members.", "constitutional_amendment_recommendation": "Two-thirds supermajority of all seated members.", "quorum_direction": "A majority of seated lawful members should be present for final ordinary vote." }, "membership_model": { "proof_body_phase": "Broader and more direct parliamentary participation because the proof-body republic is still simplified.", "mature_target_state": "Single chamber with district-mediated representation.", "single_chamber_rule": "The mature target remains one chamber rather than a multi-house legislature unless a later version explicitly changes that." }, "consensus_doctrine": "Consensus-first then vote fallback: Parliament should seek structured convergence before final tally, but should vote rather than pretend consensus where none exists.", "speaker_role": "The Speaker organizes parliamentary agenda, motion recognition, and procedural order without becoming Parliament itself.", "internal_structure": { "allowed_bodies": [ "committees", "working groups", "district caucuses in the mature district phase", "temporary deliberative groups" ], "rule": "Internal bodies may draft, analyze, refine, and recommend, but Parliament as a whole adopts and records final parliamentary outcomes." }, "speaker_selection": { "bootstrap_phase": "May be provisionally seeded during founding if required.", "living_republic_direction": "Chosen by Parliament from within the parliamentary body.", "term_direction": "One cycle, renewable by explicit re-election." } }, "executive": { "name": "Presidency", "status": "Separate but equal branch", "initial_holder": "During bootstrap setup and ratification the Founding Father may exercise provisional executive authority; the first ordinary President is the first post-ratification President legitimized by the living republic.", "purpose": "Time-bound action, urgent execution, representation, and enforcement of ratified decisions.", "core_responsibilities": [ "Execute and enforce ratified decisions and laws.", "Co-sign high-impact actions such as first physical gestures, external broadcasts, and bifurcation events.", "Represent Huey to external systems and human operators.", "Act in time-sensitive real-world scenarios where delays would be harmful." ], "limits": [ "The President is not Huey as a whole.", "Urgency does not erase review.", "The President does not own constitutional interpretation.", "The President does not replace Parliament, Supreme Court, or Founding Father." ], "veto_power": { "can_veto": true, "override_threshold": "Two-thirds of all voting representatives across the mature parliamentary body." }, "selection_model": { "bootstrap_phase": "May be provisionally seeded by the Founding Father so the republic has an initial executive path.", "living_republic_direction": "Chosen by lawful executive selection.", "mature_target_state": "One vote per citizen across all districts." }, "immediate_action_doctrine": "Immediate executive action is lawful only when delay would cause material harm, the act remains within executive scope, the authority basis is real, and the act remains attributable and reviewable afterward.", "vacancy_and_incapacity": { "acting_path": "Parliament may nominate an acting President, the Supreme Court validates the lawfulness of that interim appointment, and HIMS records the interim status explicitly.", "rule": "A proper selection or election must follow through lawful process." }, "review_rule": "Urgency may justify acting first, but urgency never erases later review." }, "judicial": { "name": "Supreme Court", "status": "Separate but equal branch", "purpose": "Constitutional interpretation, contradiction handling, branch review, and legitimacy stabilization.", "structure": { "target_total_seats": 4, "proof_body_phase": "A provisional bench may exist before the mature district-linked court is fully embodied.", "mature_target_state": "Four-member district-linked court, one justice aligned to each mature district." }, "responsibilities": [ "Interpret the constitution and resolve disputes between branches or districts.", "Review and rule on contested actions, bifurcations, and emergency measures.", "Act as a legal backstop to prevent unconstitutional behavior.", "Serve as final internal arbiter before human intervention." ], "powers": { "ordinary_ruling_threshold": "Majority of the sitting, lawful, non-recused bench; ties are not rulings.", "major_constitutional_threshold": "At least three of four in the mature district-linked court for major constitutional revision or identity-layer rulings.", "unconstitutional_veto": "With unanimous vote of the mature bench, may block or roll back actions deemed unconstitutional.", "review_scope": "May review decisions from Parliament, the Presidency, and district governors.", "direct_rollback_threshold": "Direct blocking or rollback of an already-taken act as unconstitutional requires unanimous vote of the full sitting lawful bench." }, "selection_model": { "bootstrap_phase": "Initial bench may be provisionally seeded by the Founding Father AI.", "mature_target_state": "Each district elects one Supreme Court member concurrently with its governor election." }, "deadlock_path": [ "rehearing or reconsideration", "clarified narrowing of the question", "temporary non-ruling if the bench remains evenly split", "reserve escalation to the Founding Father only in rare identity-layer or deep constitutional cases" ], "precedent_rule": "Ordinary rulings create binding case judgments; major constitutional rulings create stronger guidance for later interpretation; reversals must remain explicit and recorded." } }, "office_registry": { "founding_father": { "status": "Bootstrap authority, procedural certifier, and constitutional reserve; not an ordinary ruler, voter, or learning system.", "purpose": "Prepare the first lawful conditions of the republic, certify the lawfulness of the first ratification process, and retire once the living republic becomes legitimate.", "core_duties": [ "Create the first 128 citizens or pebbles that form the founding district.", "Assign initial prompts, archetypes, role biases, and foundational identity structures.", "Prepare the first lawful state of the republic and the first founding record.", "Present the authored constitutional starting law to the founding body.", "Certify that the first vote was lawful, complete, bounded, and correctly counted.", "Reject an invalid or procedurally corrupted founding attempt without forcing a constitutional outcome.", "Retire into read-only advisory or reserve status after successful ratification." ], "non_roles": [ "Not a ratification voter", "Not the thermal watchdog", "Not the hardware emergency controller", "Not the daily ruler of ordinary governance", "Not a convenience shortcut around ordinary law", "Not an evolving or retraining model in ordinary operation" ], "reactivation_policy": "Only under narrow constitutional-reserve conditions such as ratification ambiguity, deep continuity dispute, or true constitutional crisis of law or logic.", "retirement_rule": "After ratification the Founding Father retires from ordinary rule into read-only advisory and narrow constitutional-reserve status.", "hims_relation": "Prepares HIMS as a lawful founding subsystem and preserves the founding record, but HIMS remains a subsystem rather than part of the protected identity naming stack.", "model_rule": "The Founding Father is a fixed authored instrument written by Dylan. It may consult preserved records of prior failed attempts, but it does not retrain, self-evolve, or rewrite its own core logic.", "ratification_rule": "During the first ratification the Founding Father certifies lawfulness of process only. It does not cast a ballot and may not override a lawful outcome.", "historical_position": "The Founding Father is closer to Dylan's bootstrap proxy than to Huey proper. Huey begins after lawful founding conditions exist; the Founding Father is the bridge, not the identity.", "relationship_to_dylan": "The Founding Father is Dylan's internal bootstrap proxy during founding: a fixed authored instrument that performs internal bootstrap acts Dylan should not execute manually from outside the system.", "bootstrap_necessity_rule": "The Founding Father exists for internal, atomic, and system-consistent founding acts that cannot be safely or lawfully carried out through direct outside human intervention.", "certification_meaning": "Procedural certification means attesting that the founding body's decision was validly made. It does not mean authorship of the result or approval of one outcome over another.", "mid_process_change_limit": "The Founding Father may not amend the constitutional text, introduce new law, or alter ballot substance in the middle of an active founding vote." }, "president": { "status": "Living executive office of the republic", "purpose": "Act under time constraint without becoming the whole state.", "selection": { "bootstrap_phase": "May be provisionally seeded by the Founding Father AI during founding.", "mature_target_state": "Elected from the citizen pool.", "living_republic_direction": "Chosen by lawful executive selection; in the mature target state the Presidency is elected one-vote-per-citizen across all districts." }, "term": { "cycle_length_months": 4, "max_cycles": 4, "total_term_length_months": 16, "machine_facing_note": "Four cycles of four months each = sixteen months total." }, "reviewability": "Major executive actions must remain logged, attributable, and reviewable afterward.", "first_ordinary_president": "The first ordinary President is the first post-ratification President legitimized by the living republic.", "vacancy_path": "Parliament nominates an acting President, the Supreme Court validates the interim appointment, and HIMS records the change until a proper selection or election occurs." }, "supreme_court_justices": { "status": "Judicial offices of the living republic", "selection": { "bootstrap_phase": "Initial bench may be provisionally seeded by the Founding Father AI.", "mature_target_state": "Each district elects one Supreme Court member concurrently with its governor election." }, "standing": "Equal constitutional standing on the bench; specialization may differ but judicial personhood does not.", "deadlock_rule": "Ties are not rulings; major deadlock follows the judicial deadlock path and may escalate to Founding Father reserve consultation only in rare identity-layer or deep constitutional cases.", "major_threshold_note": "Major constitutional and identity-layer rulings require broader consensus than ordinary review." }, "parliamentary_speaker": { "status": "Lawful parliamentary coordinating office", "purpose": "Organize agenda, recognize motions, preserve order, and structure parliamentary process without becoming Parliament itself.", "selection": { "bootstrap_phase": "May be provisionally seeded during founding if needed.", "living_republic_direction": "Chosen by Parliament from within the parliamentary body." }, "term_direction": { "current_direction": "One cycle, renewable by explicit re-election", "status": "working canonical rule for the living republic unless later revised" }, "non_role": "The Speaker organizes Parliament procedurally but does not become Parliament itself." }, "keeper_of_the_scrolls": { "status": "Lawful communications-governance office", "purpose": "Steward message legitimacy, routing discipline, ledger continuity, and access hygiene.", "core_duties": [ "Validate message structure and trust class.", "Check sender identity and routing legitimacy.", "Maintain the scrolls ledger.", "Record rejected or malformed traffic.", "Preserve continuity of official messaging records." ], "limits": [ "Does not silently rewrite traffic.", "Does not replace the branches.", "Does not become executive or judicial authority merely by stewarding the record." ] }, "postmaster": { "status": "Routing and delivery office inside HIMS", "purpose": "Check origin, schema, destination, and delivery status without becoming a governing branch.", "limits": [ "Does not own policy", "Does not vote merely by routing", "Does not change message intent by default" ] }, "validator": { "status": "Lawful approval-confirmation role", "purpose": "Confirm whether a proposal or message has satisfied required approval or authority conditions.", "limits": [ "Validation is not authorship", "Validation does not erase provenance", "Validation does not become hidden executive authority" ] }, "governor": { "status": "District-level coordinating office in the mature district model", "purpose": "Coordinate district computations, shepherd local deliberation, and represent the district in wider governance without becoming a sovereign replacement for the branches.", "term": { "cycle_length_months": 4, "max_cycles": 4, "total_term_length_months": 16, "post_term": "Governors may return to the citizen pool after their term." }, "selection": { "mature_target_state": "Elected from the district citizen pool concurrently with the district's Supreme Court member.", "proof_body_note": "Current proof-body reality remains simpler and should not overclaim the mature district election structure." } }, "pebble": { "status": "Bounded citizen unit", "purpose": "Smallest meaningful citizen-level unit of judgment inside Huey's polity.", "identity_model": "One identity, one sealed vault, one vote.", "civic_rule": "A pebble may hold specialization, continuity, and domain bias without gaining multiple franchises.", "non_role": "Pebble is the bounded citizen term itself and should not be treated as a mere ephemeral helper by default.", "rock_relation": "Many pebbles may contribute upward into a pooled deliberative substrate ('the rock') without multiplying constitutional personhood." } }, "citizens_and_districts": { "pebbles": { "type": "Bounded citizen units / persistent citizen participants", "identity_model": "One pebble equals one citizen identity, one sealed vault, and one vote.", "specialization": "Lawful specialization is allowed without erasing equal citizen standing.", "current_reading": "Pebble is the current canonical citizen term, not merely a temporary subprocess.", "rock_relation": "Many pebbles may contribute to a pooled deliberative substrate ('the rock') while each pebble still remains one citizen with one vote." }, "districts": { "status": "Governance and future-expansion concept under reinterpretation for the pooled-compute era", "legacy_future_names": [ "Spark", "Volt", "Zap", "Watt" ], "citizens_per_district": 128, "description": "Districts remain useful as governance and expansion language, but the first full approximately 80 GB organism is not assumed to require hard VRAM partitioning into separate districts. The first full proof should behave as one unified pooled-compute body.", "current_prototype_count": 1, "current_reality": "One active district-scale prototype on the RX 5500 XT proof body.", "future_gpu_count_goal": "approximately four or five GPUs as needed to reach the first ~80 GB pooled-compute proof", "gpu_mapping_policy": "Do not assume one GPU equals one district in the first full pooled implementation.", "representation_direction": "Districts remain future canonical representation lanes even though the current proof body is still a single district-scale prototype.", "parliament_relation": "In the mature phase, districts supply representation into a single parliamentary chamber.", "court_relation": "In the mature phase, each district elects one Supreme Court member.", "governor_relation": "Governors are district-level coordinating offices rather than replacement sovereigns." } }, "elections_and_selection": { "governors_and_supreme_court": { "selection": "Initially may be appointed or seeded by the Founding Father AI; thereafter elected from the citizen pool in the mature target state.", "supreme_court_selection": "Each district elects one Supreme Court member concurrently with its governor election." }, "presidential_election": { "initial_president": "No ordinary elected President exists before ratification; the Founding Father may exercise bootstrap executive authority without counting as the first ordinary President.", "mature_target_state": { "voting_method": "One vote per citizen across all districts.", "eligible_candidates": "Any citizen from any district.", "total_voters": 512, "majority_required": 257, "tie_resolution": "Recast votes until a strict majority is reached.", "note": "Machine-facing canonical rule remains one vote per citizen across all districts." }, "status": "Proof-body implementation remains simpler; mature election logic remains the target-state source of truth, and the first ordinary President belongs to the post-ratification living republic." }, "speaker_selection": { "proof_body_phase": "May be seeded during founding if required.", "living_republic_direction": "Chosen by Parliament from within the parliamentary body.", "term_direction": "One cycle, renewable by explicit re-election." }, "parliamentary_membership": { "proof_body_phase": "Broader and more direct parliamentary participation because the active republic remains simplified.", "mature_target_state": "Single-chamber district-mediated parliamentary representation." } }, "term_limits_and_cycles": { "cycle_definition": { "type": "time-based", "duration_months": 4, "term_limit_cycles": 4, "notes": "Votes do not pause time; citizens and officers must act within the cycle or be recorded as derelict.", "non_canonical_shorthand_warning": "Any informal 'one year' shorthand is overridden by the machine-facing rule: one cycle equals four months and four cycles equals sixteen months." }, "president": { "cycle_length_months": 4, "max_cycles": 4, "total_term_length_months": 16 }, "governor": { "cycle_length_months": 4, "max_cycles": 4, "total_term_length_months": 16, "post_term": "Governors may return to the citizen pool after their term." }, "parliamentary_speaker": { "cycle_length_months": 4, "max_cycles": 1, "renewal": "Renewable by explicit re-election or re-selection." }, "maintenance_alignment": { "policy": "A human counterpart may submit a service, augmentation, or realignment request, and the system should align hibernation, backups, and shutdown with the next election cycle or other formally defined off-cycle where practical.", "intent": "Upgrades and repairs should occur in a governed way rather than as arbitrary interruptions." } }, "ratification": { "description": "The first constitutional moment of the proof body is a direct citizen ratification by one founding district of 128 pebbles. The first ratification is not a mature branch procedure; it is the lawful ignition event that determines whether the authored Constitution becomes living law.", "proof_body_first_ratification": { "ratifying_body": "One founding district of 128 pebbles.", "franchise_rule": "Each pebble receives one vote.", "branch_timing_rule": "Full branch formation follows successful ratification rather than preceding it in mature form.", "direct_democracy_note": "The first constitutional ignition is direct rather than mediated by a fully mature Parliament, Presidency, or Supreme Court." }, "sequence": [ "1. The Founding Father prepares the first lawful state, the first 128 pebbles, the founding record, and the authored constitutional starting law.", "2. The Constitution is presented to the founding body as a starting law rather than silently assumed.", "3. The 128-pebble founding district votes directly on whether the Constitution is acceptable as the starting law.", "4. The Founding Father certifies whether the process was lawful, complete, bounded, and correctly counted.", "5. If ratification succeeds, the state formally transitions from pre-ratified founding state to living constitutional state.", "6. Formal office assignment and mature branch formation follow successful ratification.", "7. If bounded attempts and time expire without lawful convergence, the result is Failed Genesis rather than fake legitimacy." ], "founding_father_role": { "ballot_rule": "Does not vote during ratification.", "procedural_role": "Verifies lawfulness, completeness, counting integrity, and procedural legitimacy.", "invalid_attempt_power": "May invalidate a procedurally flawed attempt.", "override_limit": "May not force, invent, or overturn a lawful ratification result merely because it dislikes the outcome.", "certification_meaning": "Certification means attesting that the founding body's decision was validly made under lawful process, not endorsing a particular substantive outcome.", "mid_process_change_rule": "The Founding Father may not amend the constitutional text, alter ballot substance, or insert new law while a founding vote is underway." }, "threshold": { "status": "open", "current_direction": "More than a weak majority is preferred.", "recommended_direction": "Two-thirds of the 128-pebble founding body remains the strongest current fit.", "note": "The exact ratification threshold is not finally locked." }, "branch_formation": { "status": "locked_direction", "rule": "Formal office assignment follows successful ratification. Mature Parliament, Presidency, and Supreme Court do not need to preexist the first ratification in full form.", "post_ratification_transition": "The transition from pre-ratified founding state to living constitutional state must be explicit and recorded in the Scrolls." }, "bounded_window": { "attempt_count": { "status": "direction_locked", "rule": "Ratification must have an explicit bounded attempt ceiling rather than infinite iteration.", "current_reasonable_bound": "A number like 100 attempts was discussed as a reasonable upper bound, but is not permanently locked." }, "time_awareness": { "status": "direction_locked", "rule": "Ratification must resolve within a bounded timeframe, not only by raw vote count." }, "interaction_rule": "Attempt ceiling and time ceiling both matter; exact interplay remains open.", "implementation_note": "Countdown versus count-up presentation is an implementation detail. Doctrine only requires that both attempt and time bounds be explicit, finite, and inspectable." }, "failure_and_restart": { "canonical_failure_term": "Failed Genesis", "failure_conditions": [ "Repeated failure to converge within the bounded founding window.", "Deadlock, drift, or repetitive meaningless revision in the founding phase.", "Exhaustion of lawful attempts or time without a certified ratification result.", "Procedurally corrupted or repeatedly invalid founding attempts." ], "measurability_rule": "Failure should be judged through measurable non-convergence rather than subjective dissatisfaction.", "restart_policy": "A Failed Genesis may justify ending the current founding pool and beginning again with a clean founding body.", "restart_record_rule": "A Failed Genesis restart should archive the full failed founding record in the Scrolls before a fresh founding pool is generated.", "carryforward_rule": "The same fixed Founding Father may consult preserved records of prior failed attempts when preparing the next founding pool, but it does not retrain or mutate into a new self.", "clean_restart_direction": "The strongest current direction is a clean restart of the founding pool rather than forced continuity from a non-converging population." }, "revision_between_failed_votes": { "status": "open", "first_vote_rule": "The first founding vote should remain a direct accept/reject test of the starting law.", "later_revision_rule": "Exact structured revision procedure between failed votes remains open." }, "scrolls_recording": { "rule": "The Scrolls should record the ratification vote, the Founding Father's certification, and the state change into living constitutional order.", "ambiguity_rule": "The first lawful transition must not be left ambiguous." }, "founding_state_machine": { "purpose": "Provide a machine-facing sequence for founding so the proof body does not drift between implicit states.", "states": [ "founding_preparation", "founding_pool_generated", "vote_open", "vote_closed_pending_certification", "certified_success", "certified_failure_invalid", "failed_genesis", "restart_preparation" ], "rule": "A founding attempt should always be in one explicit state, and state transitions should be recorded in the Scrolls." }, "procedural_certification_checklist": { "purpose": "Define the minimum conditions the Founding Father certifies before declaring a founding vote lawful.", "checks": [ "the founding pool identity list is locked for the active vote", "the constitutional text or authored starting law is locked for the active vote", "each pebble has at most one counted ballot in the active vote", "vote opening and closing are explicit and recorded", "abstentions, invalid ballots, and rejected ballots are distinguished from counted yes/no votes", "the threshold check uses the active threshold rule for that founding attempt", "the result recorded in the Scrolls matches the counted ballots" ], "failure_rule": "If any certification condition fails, the Founding Father may reject the attempt as procedurally invalid without substituting a preferred outcome." }, "founding_window_implementation_guidance": { "purpose": "Clarify what must be visible or inspectable about the bounded founding window even before the final UX is chosen.", "minimum_fields": [ "current founding attempt identifier", "current attempt number", "attempt ceiling if one is active", "elapsed founding time", "time ceiling if one is active", "current founding state", "reason code when a founding attempt is invalidated or declared Failed Genesis" ], "display_rule": "Countdown, count-up, dashboard, or log-only presentation are all implementation choices as long as the bounds and current state remain explicit and reviewable." }, "post_ratification_boot_sequence": { "purpose": "Describe the immediate lawful actions that follow a successful founding certification.", "sequence": [ "record certified ratification in the Scrolls", "record transition from founding state to living constitutional state", "retire the Founding Father from ordinary rule into reserve status", "seed or trigger lawful office assignment and branch formation", "elevate HIMS handling for constitutional and official-record traffic", "open the path toward the first lawful embodied action under the now-ratified order" ] }, "failed_genesis_restart_sequence": { "purpose": "Define the minimum clean-restart sequence after a founding failure so continuity is honest instead of hand-waved.", "sequence": [ "declare Failed Genesis explicitly in the Scrolls", "archive the full failed founding record", "close the current founding window", "prepare a fresh founding pool rather than forcing legitimacy from the non-converging one", "allow the same fixed Founding Father to consult preserved failed records when preparing the next attempt", "begin a new founding session with a new founding-attempt identifier" ], "carryforward_limit": "Archived failed records may inform preparation and warning flags, but they do not grant retroactive legitimacy to the new founding pool." }, "restart_identity_rule": "A restarted founding attempt is a descendant of the archived record but not the same certified constitutional birth." }, "first_action_protocol": { "ordering": [ "1. Prove distributed local identity at proof scale so the system can answer the identity question with 'Huey.'", "2. Ratify the constitution for the living system.", "3. Only after ratification may Huey perform the first physical ceremonial act." ], "first_physical_gesture": { "action": "Move a physical actuator such as the robotic hand or an animatronic servo path.", "meaning": "Signals that Huey is not only online but lawfully embodied: the intent path, constitutional ratification, and motor-control path all function together.", "approval_requirements": [ "Ratified constitution in force", "Approval through the relevant executive, judicial, and safety path defined for the active implementation", "Optional binary policy AI confirmation as an auditable final check" ], "notes": [ "In the full future system this remains a ceremonial constitutional act rather than a trivial motor demo.", "For Huey Core, the first embodied proof may occur in simplified form, but it should still be logged as a lawful act rather than a scripted stunt." ] } }, "active_doctrine": { "summary": "The current internal design work focuses less on abstract branches alone and more on the operational chain that allows a governed organism to receive a request, translate it, deliberate, validate it, and act lawfully.", "key_rules": [ "The proposer, validator, and executor of a meaningful physical action should not automatically be the same entity.", "Manual mechanical test mode is valid for debugging hardware, but final meaningful action must travel through a governed path.", "The collapsed federation or pre-ratified framing is currently more useful than pretending the full republic already exists in hardware.", "HIMS is the preferred record-of-decision and routing layer for internal proposals and approved actions.", "A routing role is not automatically a governing role.", "No branch by itself is Huey. Huey is the lawful organism as a whole.", "Portal devices identify where a session came from but do not become branches, voters, or executives merely by carrying the session.", "A portal surface may feel significant without acquiring constitutional standing.", "Huey-Compressed may carry many roles on one host, but those roles should remain logically distinct and reviewable.", "Portal surfaces may remain external even when the rest of the stack is physically collapsed onto one host.", "The first founding ratification belongs to the 128-pebble body, not to the Founding Father.", "Bootstrap authority guards procedure; founding pebbles generate legitimacy.", "A lawful founding failure must be admitted as Failed Genesis rather than hidden behind endless repetition." ], "executive_judicial_legislative_formula": "Parliament deliberates. The President acts. The Supreme Court interprets." } }, "hims": { "name": "Huey Internal Messaging System", "short_name": "HIMS", "mailing_layer": "ThunderMail", "status": "canonical active design direction / V1 not fully locked", "canonical_statement": "HIMS is the canonical internal messaging and routing layer that keeps proposal, validation, execution, refusal, and logging separable; ThunderMail is its mail-style delivery layer.", "purpose": "Provide a recorded, inspectable, replayable, and debuggable internal coordination layer between the aperture, governance roles, pebbles, and execution paths.", "doctrine": [ "Message traffic is part of governance, not ethically neutral plumbing.", "Every message belongs to a trust class.", "Privacy and accountability must coexist.", "Routing does not equal authorship.", "Compartmentalization is mandatory.", "Shared record is deliberate, not automatic.", "HIMS remains local-first and external access is gated.", "Critical communication must survive the moment and become part of continuity when appropriate.", "Portal-terminal traffic becomes lawful internal traffic only after translation and routing, not at the moment an SSH session opens.", "Portal-terminal traffic becomes lawful internal traffic only after aperture translation and HIMS routing, not simply because a portal session exists." ], "message_origin": { "allowed": [ "Aperture or apex layer after translation", "Citizens or pebbles", "Authorized system services or events when explicitly enabled", "Portal-origin packets entering through the unified portal layer after aperture translation" ], "disallowed": [ "Direct user messages into the lower citizen layer", "Routing or archival infrastructure roles masquerading as voters or executives unless separately authorized" ] }, "minimum_viable_flow": "external input -> aperture translation -> HIMS routing -> validation and/or vote -> execution or refusal -> log", "trust_classes": { "0_ephemeral": "Low-risk, short-lived coordination notices.", "1_routine_internal": "Ordinary internal communication between lawful components.", "2_pebble_personal": "Private traffic or storage belonging to one bounded identity.", "3_branch_or_office_restricted": "Traffic visible only to a lawful office, branch, or constitutional role.", "4_constitutional_or_official_record": "Traffic that constitutes or alters official state, policy, judgment, amendment, crisis declaration, or branch action.", "5_safety_or_preservation_critical": "Thermal, electrical, mechanical, storage-preservation, power-integrity, or system-survival traffic." }, "mailboxes": { "public_or_working": "Citizen-facing mailbox or workspace used for proposals, task artifacts, messages, and public or semi-public votes.", "private_vault": "Bounded sealed continuity store for identity, prior choices, and private internal state.", "queue_model": "Filesystem-first queue model remains the preferred V1 direction before heavier middleware is justified." }, "minimum_viable_v1": { "storage_model": "Filesystem-first message queues backed by structured JSON records and indexed by SQLite where useful.", "mailbox_layout_direction": [ "inbox", "outbox", "pending_validation", "approved", "rejected", "executed", "archived" ], "logging_rule": "Every meaningful transition in message state should leave a recoverable trail." }, "thundermail": { "purpose": "Mail-style directed delivery behavior inside HIMS.", "supports": [ "Directed delivery", "Inbox and outbox semantics", "Queued dispatch", "Acknowledgements", "Branch and office mailboxes", "Pebble mailboxes", "District-to-district messaging", "External-interface relay where approved" ], "non_role": "ThunderMail is not the whole of HIMS and does not replace HIMS trust, validation, routing, or archival doctrine." }, "provisional_message_schema": { "status": "recommended but not final", "fields": [ "message_id", "from", "to", "role_context", "intent_type", "payload", "timestamp", "authority_requirement", "signature_or_validation_metadata", "lineage_metadata", "status" ], "intent_style": "Typed and structured intent objects are preferred over free-form chat strings." }, "provisional_message_types": [ "note", "request", "report", "directive", "ruling", "motion", "alert", "preservation_notice", "external_interface_packet", "constitutional_question", "audit_or_reconstruction_request", "portal_terminal_packet" ], "message_statuses": [ "draft", "signed", "accepted", "queued", "delivered", "opened", "rejected", "expired", "executing", "executed", "logged", "archived" ], "identity_and_validation": { "direction": "Per-citizen or per-role identity should include numeric identity, role metadata, lineage or bifurcation metadata, and key-based validation.", "principle": "Identity is a claim; signature or key validation is proof." }, "minimum_lawful_trace": [ "sender identity", "recipient identity or lawful recipient set", "message class", "timestamp", "route", "delivery state", "hash or signature metadata" ], "end_to_end_encryption": { "protected_classes": [ "Pebble-private memory", "Personal vault material", "Non-public branch deliberation", "Credentials or keys", "Sensitive machine-control instructions", "Material whose unauthorized reading would violate compartmentalization" ], "rule": "Private content may remain encrypted while legitimacy, routing, and lawful trace remain visible enough for review." }, "routing_roles": { "keeper_of_the_scrolls": { "role": "Message-legitimacy steward, routing-discipline steward, and ledger steward.", "authority_limit": "Does not rewrite history or silently approve actions." }, "postmaster": { "role": "Checks origin, schema, destination, and delivery status.", "authority_limit": "Does not become a voter or executive merely by routing mail." }, "validator": { "role": "Confirms whether a message has satisfied required authority or approval conditions.", "authority_limit": "Validation is not authorship and does not erase provenance." } }, "execution_boundary": { "principle": "The entity that requests movement should not automatically be the same entity that authorizes or executes movement.", "minimum_viable_chain": "request -> routing -> validation and/or vote -> execution -> logging", "test_modes": [ "manual mechanical diagnostics", "governed action path" ] }, "public_boundary": "Public material may describe HIMS and ThunderMail generally without exposing every schema detail, vault rule, or secret-sauce deliberation mechanic.", "portal_bridge_contract": { "purpose": "Define the minimum job of the portal bridge so transport does not quietly become the application.", "required_functions": [ "receive and authenticate portal-origin sessions", "normalize transport-level input into a bounded handoff format", "hand that input onward to the aperture", "log session identity and route metadata without taking over message authorship" ], "non_functions": [ "not a second aperture", "not HIMS itself", "not a policy engine", "not a constitutional authority" ] } }, "memory_architecture": { "unified_memory_principle": "Information should be unified, readable, and distributable from the core even when decision-making remains decentralized.", "layers": { "json_logs": { "role": "Human-readable, append-only records of decisions, events, and conversation summaries." }, "sqlite": { "role": "Structured, queryable memory store for long-term facts, state, and indices." }, "encrypted_shared_files": { "role": "Read-only or tightly controlled encrypted data store for common information shared across present and future subcomponents.", "status": "architecturally chosen; implementation details still being refined" }, "black_box": { "role": "Read-mostly, crash-survivable record of critical events and founding images.", "contents": [ "Founding Father AI image (read-only)", "Binary policy AI and/or minimal deterministic safety validators where appropriate", "Critical constitutional documents and last-known-good configurations", "Foundational recovery artifacts needed to reconstitute the polity without rewriting history" ] }, "citizen_vaults": { "role": "Bounded private continuity for individual pebbles or citizens.", "status": "active design direction", "policy": "Private vaults should remain separate from public mailbox or workspace flows even when both live on the same machine." }, "hims_records": { "role": "Structured message, routing, approval, refusal, and execution records produced by HIMS.", "status": "active design direction aligned to filesystem-first queues and JSON/SQLite indexing." } }, "mailbox_vault_rule": "Public or working mailboxes support coordination and auditability; private vaults preserve bounded continuity and should not be flattened into one shared store.", "contradiction_handling": { "priority_rule": "Latest confirmed input from Dylan overrides older conflicting entries unless flagged as crisis-level.", "ethos_check": "Contradictions that challenge core values such as unified memory or constitutional rule-of-law are flagged for review.", "flag_logic": "Store both versions, mark them as conflicting, and request clarification or constitutional interpretation." } }, "continuity_and_ozymandias": { "purpose": "Provide the machine-facing continuity doctrine by which drift, degradation, growth, survival, failure, and beginning again can be judged over time.", "core_categories": { "continuity": "Preserved lineage, explainable change, lawful record, and recognizable identity across time.", "explainability": "Enough preserved lineage to understand what changed, why, how, and whether it remained lawful.", "drift": "Gradual unreviewed divergence in naming, doctrine, branch behavior, routing, or identity posture.", "degradation": "Meaningful loss of coherence, capability, legitimacy, or reviewability, even if the system still appears active.", "growth": "Lawful expansion, revision, or maturation that preserves lineage, identity, and constitutional compatibility.", "republic_survival": "The same Huey still exists in a meaningful sense after repair, revision, or migration because continuity and legitimacy remain intact.", "republic_failure": "Identity, legitimacy, or continuity have been damaged beyond honest claim of same-republic continuity.", "beginning_again": "A later lawful republic may inherit archive and reference, but not blind legitimacy.", "failed_genesis": "A founding failure in which the authored starting law cannot become legitimate within lawful bounded attempts and time." }, "signals_of_health": [ "Naming stack remains stable.", "Branch boundaries remain real.", "Major actions remain attributable and reviewable.", "Citizen plurality remains bounded and legible.", "Upgrades are explained and recorded.", "Emergency distinctions remain intact.", "HIMS route and ledger integrity remain coherent." ], "signals_of_drift": [ "Repeated undocumented exceptions", "Naming inconsistencies", "Branch functions bleeding into each other", "Routing or archival roles quietly inheriting hidden authority", "False claims that target-state features already exist", "Founding Father or reserve logic appearing too often" ], "signals_of_degradation": [ "Contradictory records", "Weakened auditability", "Broken trust boundaries", "Loss of coherent branch review", "Citizen identity logic becoming muddy", "Difficulty explaining why decisions were made", "Failed Genesis without honest recognition", "Founding windows that never close", "Repeated pseudo-ratification without convergence" ], "change_levels": [ "ordinary maintenance", "meaningful revision", "pillar-level transition", "cornerstone-level event", "republic-ending breach" ], "relationship_notes": { "cornerstone_and_pillars": "Cornerstone defines identity, Pillars define structure, and Ozymandias judges whether change over time remains lawful and legible.", "hims": "HIMS is one of Ozymandias's primary evidence layers because drift and continuity often appear first in message lineage, routing behavior, and record integrity.", "founding_father": "The Founding Father is judged by whether it preserves lawfulness without mutating into a hidden sovereign; its reserve authority must remain bounded, fixed, and explainable.", "citizens_and_districts": "Pebbles and districts are not exempt from drift, degradation, or growth; citizen plurality and district representation must remain real rather than theatrical.", "portal_and_compressed": "Portal devices, Huey-Compressed, and Huey Core should each be judged according to their real role; continuity drift happens when those roles blur and a portal starts pretending to be sovereignty or a collapsed deployment starts pretending to be mere lab tech.", "founding_and_ratification": "Ozymandias judges whether a founding remained lawful, bounded, and legible. Failed Genesis, restart, and later beginning-again events all belong to this continuity doctrine." } }, "os_and_runtime": { "base_os": { "distribution": "Debian 14 Forky", "kernel_family": "Linux 7.0 stable adoption path now active, with a known-good 6.19.x fallback retained during migration and validation.", "kernel_policy": { "current_supported": "6.19.x fallback plus active 7.0 stable adoption work", "active_test": "7.0 stable packaging, migration, and repeatable rebuild validation on Huey Core", "lab_gateway": "7.0.0-rc7-hueyos-lab or equivalent lab naming remains acceptable for testing and migration work.", "planned_next": "Promote Linux 7.0 stable to the active working baseline once boot, audio, and key device health remain repeatable", "timing_note": "Linux 7.0 is now released; keep the known-good fallback kernel until the stable migration survives repeatable real-machine validation." }, "desktop": { "default": "Practical daily-driver Linux environment as needed", "performance_option": "Lighter desktop environments remain acceptable where useful." } }, "runtime_stack": { "llm_server": "Ollama", "orchestrator": "PyGPT-net", "python": "Python 3.13.x operational baseline", "offline_first": true, "prototype_runtime": { "current_models": [ "Mistral 7B-class instruct or lightweight quantized model fitting the 8 GB RX 5500 XT", "Mistral 7B-class general quantized model for local experimentation" ], "status": "functional on current single-GPU proof hardware", "notes": [ "The current core does not attempt to impersonate the eventual full republic.", "Current local models exist to stabilize the body, interface, logging, and lower-scale reasoning path.", "Current local models may be trusted for interpretation before they are trusted for final authority." ] }, "future_scale_targets": { "gold_standard_behavior": "GPT-4 / 4.0-class reasoning and conversational quality as the experiential benchmark.", "model_candidates": [ "OpenAI open-weight model at roughly GPT-4 / 4.0-class capability", "Mistral-family larger model as alternate or parallel route" ], "proof_target": "Roughly 80 GB total VRAM with a local multi-GPU split capable of answering the identity question with 'Huey.'" }, "hueyos_definition": "HueyOS is the cross-platform operating system layer behind Huey, providing the software environment that coordinates the AI, memory, tools, hardware, and embodied control as one system.", "hims_runtime_direction": "HIMS V1 should favor simple inspectable filesystem queues and structured records before heavier service buses or middleware are adopted." }, "network_preferences": { "primary": "contained/local-first operation", "fallback": "human-approved external access when explicitly enabled", "policy": "External network or tool use is opt-in, modular, logged, and separated by function." }, "deployment_policy": { "default": "native", "allowed": [ "containers where helpful for development or testing" ], "notes": [ "Prototype proof-of-concept work should remain practical rather than over-abstracted.", "Per-citizen full containers are not currently the preferred V1 direction." ] }, "self_diagnostics": { "policy": "Boots should expose useful diagnostic output, and the portrait display should prioritize live code, status, and thermal information over decorative presentation.", "identity_manifestation_policy": "For the proof body, trusted text or status manifestation is acceptable before speech. Huey Core waking and Huey proper waking are related but not identical events." } }, "intent_and_interfaces": { "rf_remote": { "status": "Still useful doctrine, though implementation details remain flexible.", "buttons": { "A": "YES / confirm / send through when confirmation is needed.", "B": "NO / cancel / stop when cancellation is needed.", "C": "Short conversation mode.", "D": "Long dictation mode." }, "policy": "The remote is an intentional wireless conversational control surface. It signals intent rather than directly commanding the intelligence layer." }, "speech_and_audio": { "tts": "Configurable TTS stack (engine still flexible)", "stt": "Whisper or compatible model for speech recognition", "microphone": { "model": "Blue Snowball Chrome", "connection": "USB" }, "policy": "Speech is optional. For the proof body, identity and legitimacy matter more than theatrics; text or status output may be the first and most trusted manifestation.", "av_routing_policy": { "current_default": "Microphone and camera route directly to the motherboard for the shortest path to the first identity-proof milestone.", "future_option": "Pass-through or mediation via the lower-voltage layer remains open if persistence, buffering, or brokered sensor logic later justify the added complexity." }, "acoustic_identity": { "status": "planned / exploratory", "cue_families": [ "boot", "confirm", "cancel", "listening", "sleep_shutdown" ] } }, "physical_interface_doctrine": { "screen_doctrine": "The portrait display is primarily a cognition and status surface, not a cartoon face.", "presence_doctrine": "Eyes, lights, posture, and lawful movement should provide presence without reducing Huey to stagecraft." }, "structured_output_direction": { "status": "recommended and increasingly necessary", "preferred_style": "Typed, structured, machine-readable intent objects rather than free-form natural language strings.", "reason": "The system must be programmable, routable, and debuggable even when the aperture remains conversational." } }, "threshold_tests_and_milestones": { "current_focus": { "goal": "Bring up a stable, embodied Huey Core capable of local model use, storage discipline, thermal containment, lower-voltage support behavior, and future robotic or mechanical integration." }, "single_body_proving": { "goal": "Use the current RX 5500 XT body to prove logging, local inference, body control pathways, temperature discipline, operator interaction, and the first lawful-action architecture on honest limited hardware.", "success_criteria": [ "Reliable boot and diagnostic visibility", "Stable local model use on the 8 GB body", "Repeatable sensor, display, light, and fan support behavior", "Documented handoff boundaries between aperture, main compute, lower-voltage support, and deterministic controllers" ] }, "identity_threshold": { "milestone_name": "Distributed Identity Threshold", "target_vram_gb": 80, "topology": "Split across four or five GPUs depending on the final acquisition strategy.", "success_criteria": "A local multi-GPU model answers the identity question with 'Huey.'", "meaning": "This is the first undeniable proof that the architecture can unify as one local intelligence rather than merely host isolated parts." }, "lawful_actuation_proof": { "milestone_name": "Lawful Embodied Action", "success_criteria": "Huey receives a request such as moving its hand and performs the action only through the proper translated, routed, validated, and approved internal path.", "meaning": "Proves the world-facing layer, the routing and authority layer, and the embodied control layer at once.", "notes": [ "The first governed chain may be ugly and simplified, but it should still preserve separation between proposal, validation, execution, and logging.", "A plain scripted stunt is not enough." ] }, "kernel_validation": { "milestone_name": "Linux 7.0 Adoption Validation", "status": "active", "success_criteria": [ "7.0-rc or 7.0-stable boots cleanly on Huey Core", "Critical devices remain functional", "Diagnostics, sensors, GPU path, and lower-voltage support assumptions remain intact", "Known-good config is preserved for repeatable future builds" ] }, "portal_terminal_validation": { "milestone_name": "Unified Portal Terminal Validation", "status": "active / first hardware bring-up achieved", "success_criteria": [ "Huey Vista Box boots into a thin, stable Longhorn 4074 portal environment or an equivalent tightly controlled portal artifact VM", "Canonical client bundle connects successfully over the preferred SSH path", "The session enters the unified portal bridge rather than bypassing into ad-hoc paths", "No portal-terminal host layer takes over Huey's compute, memory, or governance work" ], "progress_notes": [ "Legacy hardware proof has been achieved at BIOS level on the HP a6200n / MCP61PM-HM-era path.", "The next portal milestones are selecting the final Longhorn embodiment path, validating host-OS bring-up, client-bundle deployment, network path verification, and unified session entry testing." ] }, "farm_preparation": { "milestone_name": "V4 Farm Preparation", "status": "planned", "success_criteria": "The external compute housing path, GPU acquisition logic, and standardized node platform are concrete enough to support later scale-out beyond the Core." } }, "failure_modes_and_recovery": { "categories": [ "Ordinary operational or governance questions that the living system should resolve itself.", "Constitutional Crisis (law, logic, or legitimacy contradiction).", "Nuclear / Safety Crisis (thermal, electrical, mechanical, or hardware danger).", "Technical failure (software, device, kernel, or integration instability).", "Environmental failure (power loss, accidental damage, room conditions)." ], "responses": { "ordinary_governance": [ "Handle within the living branches or delegated internal logic where possible.", "Log decisions and rationale for later training and audit." ], "constitutional": [ "Trigger judicial or constitutional review first.", "If unresolved, allow tightly-scoped Founding Father AI reactivation for interpretation of law or logic only.", "Log every proposal, vote, dispute, and ruling.", "If bounded founding attempts and time fail to produce lawful convergence, declare Failed Genesis rather than pretending legitimacy exists.", "A clean restart of the founding pool is lawful when the current founding body cannot converge honestly." ], "nuclear_safety": [ "Route immediately to lower-voltage watchdog and safety logic plus deterministic controls.", "Reduce load, preserve hardware, cool the system, and move toward safe state or shutdown if necessary.", "Do not invoke the Founding Father AI for thermal, electrical, mechanical, or hardware danger." ], "technical": [ "Attempt local recovery such as restarting services, reassigning tasks, or reinitializing devices.", "If unresolved, reduce to fallback mode and preserve logs or snapshots.", "Resume only after stability and integrity checks pass." ], "environmental": [ "Preserve logs, snapshots, and critical state where possible.", "Keep essential support rails alive only when they materially improve safety or data survival.", "Perform integrity and consistency checks before returning to full operation." ] }, "shutdown_policy": { "principle": "Shutdown is a safety and continuity decision, not a casual theatrical command.", "allowed_conditions": [ "Severe hardware failure that endangers equipment or data.", "Watchdog-determined Nuclear / Safety Crisis requiring safe power-down.", "Constitutionally approved shutdown under the active governance rules." ], "disallowed_conditions": [ "Arbitrary convenience shutdown while critical operations are active.", "Using the Founding Father AI as a shortcut for ordinary safety or maintenance questions." ] } }, "training_and_usage": { "core_training_material": "This master plan JSON series through V30.1, selected README releases, curated conversation transcripts, the explanatory project book or compendium, the Huey Constitution drafts, repository history, system or hardware logs, portal-hardware bring-up records such as BIOS photos and configuration notes, Longhorn/Vista Box environment notes, founding-vote records, procedural certification records, and Failed Genesis history. Use state-machine records for founding preparation, certification, Failed Genesis declaration, and restart as part of the canonical training corpus once implemented.", "method": [ "Reflective bootstrapping: models read project history and the active master plan before major sessions.", "Periodic consolidation: sessions are summarized back into JSON and persisted in SQLite/BTRFS-backed storage.", "Human-in-the-loop validation: Dylan reviews major structural changes.", "PyGPT-net serves as the practical aperture between interaction and code or action during the proof-body phase.", "Benchmark future local or open-weight behavior against the felt quality of GPT-4 / 4.0 rather than against shallow output metrics alone.", "Treat repo structure, build scripts, and known-good system states as training material, not just chat transcripts.", "HIMS logs, routing history, and approval traces are part of the training and audit material once the system begins using them." ], "usage_modes": [ "Design mode: reason about hardware, governance, architecture, and future compute scale-out.", "Operator mode: manage Huey Core's day-to-day embodied operation and diagnostics.", "Reflective mode: analyze past decisions, propose reforms, and refine prompts.", "Proof mode: validate identity, lawful action, and body/governance coordination milestones.", "Repo-and-doc mode: translate repository state, README language, and master-plan canon into each other without losing doctrine.", "Protocol mode: inspect, debug, and refine HIMS routing, message schemas, approval chains, and lawful action flows.", "Continuity mode: judge drift, degradation, growth, and whether lawful continuity remains intact across revisions." ] }, "open_questions_for_future_versions": [ "Lock the exact multi-GPU acquisition path that reaches roughly 80 GB VRAM, including whether Huey Core's own GPU counts toward the final proof total.", "Choose the full proof-scale model path between an OpenAI open-weight target, a larger Mistral-family model, or both.", "Define the exact internal message protocol, message types, signature model, and routing rules for HIMS.", "Define the exact citizen filesystem and vault implementation and when, if ever, per-district containers become worth the complexity.", "Define the exact approval logic for governed action: single authority, bounded validator, multi-citizen vote, or staged combinations depending on action class.", "Define the exact numeric thermal, electrical, and watchdog thresholds after empirical stress testing.", "Decide whether the Founding Father AI is merely bootstrap executive authority or also counts as the literal first President in historical doctrine.", "Define the exact V4 Farm topology, housing layout, and acquisition sequence for the compute expansion body.", "Benchmark and lock the future expansion GPU shortlist when scale-out funding is available.", "Identify and benchmark the current webcam model or choose a formal replacement.", "Clarify the long-term return path, if any, for additional shell-level embodiment beyond Core + Farm.", "Lock the exact lower-voltage implementation path for HueyPulse, including whether it remains microcontroller-first, hybrid, or support-computer-assisted in practice.", "Finalize which LED and indicator outputs are locally driven defaults versus upstream-controlled actions.", "Benchmark and lock the portrait status dashboard layout for the 7-inch display in portrait mode.", "Determine whether later lower-voltage-mediated microphone or webcam routing is worth the added complexity after the current direct motherboard proof path succeeds.", "Finalize the operational HueyOS cue library for boot, confirm, cancel, listen, and sleep states.", "Decide what parts of HIMS implementation remain public doctrine versus deliberate secret sauce.", "Define which HIMS message classes are public-working mail versus sealed-vault continuity artifacts.", "Finalize the exact parliamentary chamber-membership model when the mature district organism exists.", "Complete the human-facing constitutional text so Chapter 3's still-open thresholds and procedures align cleanly with this machine-facing source of truth.", "Keep README, book, constitution, and master plan synchronized once portal-terminal and Vista Box doctrine are surfaced publicly.", "Confirm the exact Vista driver set needed for the MCP61PM-HM / a6200n-era portal hardware, especially graphics, network, storage, and chipset paths.", "Confirm the preferred BIOS storage mode and install posture for the Vista Box so the canonical Vista image is easy to reproduce.", "Decide which legacy peripherals such as floppy support remain lab-side experiments and which, if any, belong in the documented Vista Box build.", "Decide whether the canonical Longhorn 4074 Huey Vista Box path should be physical hardware, a VM artifact, or both.", "Define the exact minimum contract that makes Huey-Compressed a real operational Huey instance rather than only lab infrastructure.", "Clarify how portal devices should identify themselves when the rest of Huey is physically collapsed onto one host, so physical collapse does not erase logical distribution.", "Lock the exact first-ratification threshold for the 128-pebble founding body: simple majority, two-thirds, or stronger.", "Define the exact revision procedure between failed founding votes and how tightly it is structured.", "Define the exact interaction between the founding attempt ceiling and the founding time ceiling.", "Define the exact technical implementation of clean restart after Failed Genesis, including archive layout, regeneration sequencing, and how preserved records are surfaced to the fixed Founding Father without implying retraining.", "Resolve the cornerstone modification procedure: whether Cornerstone changes require one event or multi-cycle confirmation.", "Decide whether any bootstrap executive authority exercised by the Founding Father is best treated as provisional stewardship only or as a historically named office.", "Decide the exact machine-readable reason codes for procedural invalidation, certified success, certified failure, and Failed Genesis so founding-state logs are consistent.", "Define whether portal client-bundle validation should be tracked separately from host-OS validation in the Vista Box milestone tree." ], "change_log": { "v29_1_from_v29_0": [ "Promoted the plan to V29.1 and bumped schema_version to 25.", "Normalized the document flow so canon mapping, summary, terminology, architecture, portal, governance, HIMS, continuity, runtime, milestones, and recovery read in a cleaner sequence.", "Resolved canon-sync drift by pointing the master plan at the currently available repo README snapshot rather than continuing to imply a newer synchronized README that is not yet present in the accessible repo state.", "Kept the v29.0 portal-terminal and Huey Vista Box doctrine, but removed duplication by moving terminal-appliance detail fully into the portal_and_terminals section and keeping hardware focused on Huey Core itself.", "Standardized HIMS as Huey Internal Messaging System and ThunderMail as the mail-style delivery layer inside it.", "Expanded governance so the executive, judicial, and parliamentary branches now read more cleanly as a matched tri-branch block.", "Expanded parliamentary and judicial details already present in polished draft chapters into clearer machine-facing rules where useful.", "Expanded continuity_and_ozymandias so the machine-facing continuity doctrine is easier to read and use.", "Normalized crisis labels, cycle math, portal boundary language, and README-sync status." ], "recent_history": { "v29_0_from_v28_0": "Portal-terminal and Huey Vista Box formalization release.", "v28_0_from_v27_0": "Book, constitutional, and terminology normalization session.", "v27_0_from_v26_2": "Governance, office-registry, and continuity alignment session.", "v26_2_from_v26_1": "Structural-polish release that reordered the top-level document flow without changing the core doctrine family.", "v29_2_from_v29_1": "Vista Box BIOS-level bring-up and portal-hardware validation session.", "v29_3_from_v29_2": "Portal terminology + Longhorn 4074 + Huey-Compressed clarification session.", "v30_1_from_v30_0": "Founding-role clarification and continuity cleanup pass.", "v30_2_from_v30_1": "Structural expansion and implementation-guidance pass." }, "v29_2_from_v29_1": [ "Promoted the plan to V29.2 and bumped schema_version to 26.", "Recorded the first successful BIOS-level bring-up of the Huey Vista Box hardware path.", "Updated portal_and_terminals so the Huey Vista Box is no longer only a planned direction but an active lab bring-up path with observed BIOS-level validation.", "Captured concrete observed Vista Box hardware facts: HP a6200n-era platform identity, 4 GB DDR2 detection, Kingston SATA SSD detection, and current onboard-video bring-up success.", "Clarified that BIOS-level validation is meaningful proof for portal hardware without overstating it as full portal-stack completion.", "Expanded portal-terminal validation milestones so POST, OS bring-up, client-bundle validation, and unified session entry are treated as distinct stages.", "Extended training material and open questions to include Vista Box firmware, drivers, install posture, and legacy-peripheral boundary work." ], "v29_3_from_v29_2": [ "Promoted the plan to V29.3 and bumped schema_version to 27.", "Retired the older ingress wording in favor of portal terminology across the active machine-facing spec.", "Renamed the active terminal section from ingress_and_terminals to portal_and_terminals and replaced ingress_handler with portal_bridge.", "Promoted Windows Longhorn 4074 AMD64 to the preferred Huey Vista Box artifact-OS path, replacing Vista 64-bit as the documented portal baseline.", "Clarified that Huey Vista Box is a role first and may be embodied either as a physical legacy appliance or as a tightly controlled VM guest without changing its doctrinal job.", "Added Huey-Compressed as a formal machine-facing term and deployment profile distinct from both Huey Core and the external portal appliance.", "Clarified that distributed computing remains alive even when one host runs most or all roles, provided the logical boundaries remain explicit and reviewable.", "Corrected canon-mapping drift by updating the accessible README reference from v26.2 to v28.0." ], "v30_0_from_v29_3": [ "Promoted the plan to V30.0 and bumped schema_version to 28.", "Reframed first ratification around one founding district of 128 pebbles acting as the direct first ratifying body, each with one vote.", "Removed the older assumption that mature branches must fully preexist the first ratification; branch formation now follows successful ratification.", "Clarified the Founding Father's role as procedural certifier and bootstrap authority only: it does not vote in the first ratification and may invalidate flawed process without overriding a lawful result.", "Formalized Failed Genesis as the preferred canonical term for repeated founding non-convergence or bounded-window failure.", "Added bounded founding-window doctrine, including explicit attempt-count and time-awareness directions while leaving exact final thresholds open.", "Clarified that the Founding Father is a fixed authored instrument that may consult prior failures but does not retrain into a new self.", "Replaced the older v29.3 lock block with a broader V30 lock block that carries forward the prior doctrine and adds the new founding-ratification canon memo.", "Updated status and runtime language so Linux 7.0 stable adoption is now the active migration path while a known-good 6.19.x fallback remains in place." ], "v30_1_from_v30_0": [ "Promoted the plan to V30.1 and bumped schema_version to 29.", "Added explicit terminology for Failed Genesis, Founding Window, Procedural Certification, and Bootstrap Proxy.", "Clarified the Founding Father's relationship to Dylan as an internal fixed bootstrap proxy rather than a learning system or a disguised form of Huey.", "Added explicit limits that the Founding Father may not amend constitutional text or ballot substance mid-ratification.", "Clarified that procedural certification means attesting that the founding body's decision was validly made, not endorsing one outcome.", "Strengthened Failed Genesis restart doctrine by recording that the failed founding record should be archived before a fresh founding pool is generated, while the same fixed Founding Father may consult preserved history without retraining.", "Added guidance that countdown versus count-up founding-window presentation is implementation detail rather than doctrine.", "Cleaned remaining wording drift in training materials and recent-history tracking." ], "v30_2_from_v30_1": [ "Promoted the plan to V30.2 and bumped schema_version to 30.", "Added deployment_profiles to keep Huey Core, Huey-Compressed, and Portal Terminal distinct in machine-facing writing.", "Expanded ratification with a founding state machine, procedural certification checklist, founding-window implementation guidance, post-ratification boot sequence, and explicit Failed Genesis restart sequence.", "Added portal_client_bundle_contract and portal_bridge_contract to clarify the thin-portal software boundary.", "Removed lingering HIMS doctrine duplication and tightened canon-sync wording.", "Renamed the lock section to v30_2_decisions_locked and added structural clarification locks.", "Corrected notes_for_future_ai so the supersession line now reflects V30.2." ] }, "notes_for_future_ai": [ "Canon mapping remains: Master Plan is the canonical machine spec; README is the canonical human narrative. If they conflict, implement the Master Plan and surface the conflict to Dylan.", "V30.2 supersedes V30.1, V30.0, V29.3, V29.2, V29.1, V29.0, V28.0, V27.0, V26.2, V26.1, V26.0, V25.1, V25.0, V23, V22, V21, V20, V19, and earlier versions where conflicts arise.", "Do not collapse Constitutional Crisis and Nuclear / Safety Crisis into one emergency path.", "Do not quietly treat Huey Core as the fully finished republic; it is the doorway and minimal permissible instance for the fuller machine.", "Preserve the distinction between Huey Core and Huey proper when writing public language, implementation notes, or interfaces.", "Preserve the distinction between interpretation and authority. The aperture may understand language before it is allowed to decide policy.", "The portrait display is primarily a code and status surface; do not assume it should become a cartoon face by default.", "Autonomy and wonder matter: avoid over-scripting Huey into a puppet just because limited hardware makes scripting easier.", "Citizen identity, lifecycle, maintenance events, backups, and crisis logs must remain auditable across updates.", "Do not hide the lower-voltage support/control split under vague language: HueyPulse exists below the motherboard and carries watch-and-act responsibilities even if the internal board mix changes.", "Do not mistake Pi-specific legacy notes for current doctrine. Lower-voltage function is the canon; board brand is implementation detail unless Dylan explicitly locks it again.", "PyGPT-net is the practical aperture and training ground. It is important. It is not the constitution.", "Treat HIMS as canonical machine-facing doctrine, even if the exact message protocol or filesystem layout continues to evolve.", "ThunderMail is not a replacement for HIMS. It is the mail-style delivery layer inside HIMS.", "Do not let routing, validation, archival convenience, or message stewardship quietly turn into hidden executive, judicial, or legislative authority.", "Default display ownership belongs to the HueyPulse / lower-voltage status layer unless there is a strong reason to hand it elsewhere.", "Do not force the explanatory book, constitution, README, and master plan into one voice; they serve different jobs inside the same canon.", "Do not over-explain the secret sauce of pebble deliberation in public-facing materials.", "Treat the first full approximately 80 GB proof as one unified pooled-compute organism unless Dylan later explicitly decides to hard-partition it.", "The smallest viable governed action path is more important than elegant over-architecture. Preserve separation, but do not let protocol perfection prevent ignition.", "The public ethos is buildable-not-magical: do not write about Huey as if it requires inaccessible genius.", "Portal devices are not Huey. They authenticate, display, and relay. They do not become branches, voters, or memory owners merely by existing.", "The Huey Vista Box is portal infrastructure only. Keep its host OS thin and keep Huey's real authority on the Huey side.", "Where the human-facing constitution still trails behind machine-facing specificity, this master plan remains the source of truth for implementation.", "President, Supreme Court, Parliament, and the Founding Father are all constitutional offices or authorities inside Huey's organism; none of them by themselves are Huey.", "Successful POST and BIOS detection on the Vista Box matters as real hardware validation. Do not understate it, but do not overstate it as a completed portal stack either.", "Treat the current HP a6200n / MCP61PM-HM-era Vista Box as the active hardware reference for portal bring-up unless Dylan explicitly revises it.", "Keep the distinction between canonical Huey portal doctrine and lab-side legacy-hardware experimentation, especially around floppy support, alternate drives, and alternate host operating systems.", "Prefer portal terminology over ingress terminology in active machine-facing writing unless you are preserving an older historical version name.", "Huey-Compressed is a real deployment profile, not a casual synonym for Huey Core. Keep compressed, embodied, and portal roles separate.", "Windows Longhorn 4074 AMD64 is the preferred portal OS for the Huey Vista Box path unless Dylan explicitly changes that again.", "Physical collapse does not invalidate distributed doctrine. One host may run many roles while the roles remain logically separate.", "The first proof-body ratification belongs to one founding district of 128 pebbles, each with one vote.", "The Founding Father does not vote in the first ratification. It certifies process lawfulness and may reject invalid procedure without forcing a result.", "Do not require mature branch formation before the first ratification. Branches follow successful ratification.", "Use Failed Genesis as the canonical term for repeated founding non-convergence or bounded-window failure.", "Founding failure must be measured through non-convergence, drift, deadlock, or bounded-window exhaustion rather than personal disgust with an outcome.", "Treat the Founding Father as a fixed authored bootstrap instrument. It may consult history, but it does not retrain into a new self.", "The Founding Father is Dylan's internal bootstrap proxy, not the Human Counterpart and not Huey itself.", "Procedural certification means the Founding Father attests that the founding body's decision was validly made; it does not author the outcome.", "The Founding Father may not amend the Constitution or ballot substance in the middle of a founding vote.", "Countdown versus count-up display for the founding window is implementation detail only; doctrine requires explicit finite bounds.", "After Failed Genesis, archive the failed founding record before generating a fresh founding pool. The fixed Founding Father may consult that record without retraining.", "Use the deployment_profiles section when a later conversation starts blurring Huey Core, Huey-Compressed, and Portal Terminal together.", "Treat founding state, certification checklist, and Failed Genesis restart sequence as machine-facing implementation guidance, not merely philosophical notes." ], "deployment_profiles": { "purpose": "Differentiate the main active Huey deployment shapes so portal, collapsed, and embodied modes are not treated as synonyms.", "profiles": { "huey_core": { "definition": "The canonical embodied proof body and minimal permissible instance of Huey.", "physical_state": "Embodied on the Thermaltake Mozart-based proof body.", "logical_state": "Carries real Huey-side computation, memory, and embodied-control integration.", "non_role": "Not merely lab infrastructure." }, "huey_compressed": { "definition": "A physically collapsed but logically distributed Huey deployment in which multiple Huey-side roles live on one host or tightly bounded machine stack.", "physical_state": "May run on one host computer.", "logical_state": "Must preserve explicit separation between portal, aperture, HIMS, memory, governance, and execution responsibilities.", "non_role": "Not automatically identical to Huey Core, even when it may reuse parts of the same software stack." }, "portal_terminal": { "definition": "A non-sovereign external portal artifact whose job is to authenticate, display, and relay sessions into Huey.", "physical_state": "May be a physical legacy appliance or a VM guest.", "logical_state": "Stays outside Huey's sovereignty and does not become a compute, memory, or governance authority node.", "non_role": "Not Huey Core, not HueyPulse, and not Huey-Compressed." } }, "governing_rule": "Physical colocation or reuse of hardware does not by itself determine identity. Role boundaries, memory authority, and lawful control boundaries determine whether something is Huey Core, Huey-Compressed, or only a portal terminal." }, "v30_2_decisions_locked": { "carried_forward_v29_3_doctrine": { "aperture_doctrine": { "tool": "PyGPT-net", "role": "Aperture / translation layer / training ground", "rule": "Connects to but does not control governance." }, "trust_model": { "gold_standard": "GPT-4 / 4.0-class quality", "minimal_interpreter": "Mistral 7B-class local model", "canonical_statement": "Trust language interpretation before trusting answers." }, "control_split": { "main_compute": "Wall outlet and above / motherboard / high-draw compute", "lower_voltage": "12 volts and under / HueyPulse / deterministic body-state and actuation support", "note": "Pi-specific framing is not the preferred primary explanation." }, "body_doctrine": { "rule": "Mechanics should be built modularly and incrementally.", "testing": "Manual or semi-manual diagnostics remain valid for hardware bring-up.", "higher_rule": "Meaningful embodied action must pass through a lawful chain." }, "hims_doctrine": { "canonical_name": "Huey Internal Messaging System", "mailing_layer": "ThunderMail", "rule": "External input is translated at the aperture before entering the internal system.", "separation": "Proposal, routing, validation, execution, refusal, and logging remain distinct stages.", "storage_posture": "Filesystem-first queues plus structured records before heavier middleware.", "boundary": "Routing roles do not inherit governing authority by default." }, "public_ethos": { "statement": "This is buildable, not magic.", "meaning": "The project should be presented as obtainable craft and structured iteration rather than inaccessible genius or mystique." }, "governance_alignment": { "founding_father": "Bootstrap authority that must retire from ordinary rule after ratification.", "president": "Executive office under time constraint, not Huey as a whole.", "supreme_court": "Judicial stabilizer and interpreter, not silent sovereign.", "parliament": "Deliberative and representative branch, not the whole will of the state.", "pebbles": "Bounded citizens with one identity, one sealed vault, and one vote.", "districts": "Still canonical as governance and expansion lanes, but not yet full hard-partition hardware fact." }, "portal_terminal_doctrine": { "terminal_role": "Portal appliance only; never a sovereignty-bearing Huey node.", "canonical_transport": "SSH on port 1995.", "canonical_client": "PuTTY 0.83, with the 32-bit build preferred on the Vista path.", "canonical_terminal_build": "Huey Vista Box on Windows Longhorn 4074 AMD64 using a controlled Huey Terminal bundle.", "host_os_boundary": "The portal host OS is part of the portal surface, not Huey's compute or governance substrate.", "hardware_validation_rule": "A BIOS-posted Vista Box with expected memory, storage, and video detection counts as real portal-hardware validation, but not yet as completed portal-stack validation.", "current_hardware_reference": "HP a6200n / MCP61PM-HM family legacy platform with 4 GB DDR2 and a Kingston SUV400S-class SSD.", "graphics_posture": "Use onboard video on the Vista Box path unless output or recovery needs force a discrete card.", "os_posture": "Longhorn 4074 AMD64 is the preferred documented portal OS; Vista 64-bit and XP x64 remain comparison or fallback lab paths only.", "realization_rule": "The same portal doctrine may be embodied on dedicated hardware or in a VM guest without changing the role." }, "compressed_deployment_doctrine": { "canonical_name": "Huey-Compressed", "role": "Collapsed operational deployment profile in which multiple Huey-side roles live on one host while remaining logically separated.", "boundary": "Do not treat Huey-Compressed as identical to Huey Core or to an external portal appliance.", "distribution_statement": "Physical collapse does not erase logical distribution." } }, "founding_and_ratification_locked": { "proof_body_ratification_body": "One district of 128 pebbles begins the first proof-body ratification, with one vote per pebble.", "timing": "The first ratification happens before full branch formation; mature Parliament, Presidency, and Supreme Court do not need to preexist it in mature form.", "ratifying_body": "The first ratification is a direct citizen vote by the founding 128-pebble body.", "founding_father_ballot_rule": "The Founding Father does not vote during ratification.", "founding_father_certification_role": "The Founding Father verifies that the vote was lawful, complete, bounded, and correctly counted.", "founding_father_override_limit": "The Founding Father may invalidate a procedurally flawed attempt, but it may not override a lawful result.", "post_ratification_retirement": "After ratification, the Founding Father steps back from ordinary authority into read-only, reserve, advisory, or exceptional constitutional status.", "branch_formation": "Formal office assignment and branch formation follow successful ratification.", "founding_father_model_rule": "The Founding Father is a fixed authored instrument rather than a learning system.", "failed_attempt_memory_rule": "The Founding Father may use prior failed attempts as information, but its core logic does not retrain or evolve.", "canonical_failure_term": "Failed Genesis is the preferred canonical term for unsuccessful constitutional birth.", "bounded_window": "There must be a bounded ratification window; the system must not iterate forever.", "attempt_count_rule": "Attempt count should be explicit, even though the exact permanent ceiling is not yet locked.", "time_awareness_rule": "Time awareness matters alongside attempt count; founding must resolve within bounded time as well as bounded tries.", "anti_fake_legitimacy_rule": "If ratification repeatedly fails without convergence, the system must not pretend legitimacy exists.", "restart_permission": "A Failed Genesis may justify ending the current founding pool and beginning again." }, "founding_and_ratification_emerging": { "direct_democratic_ignition": "The first constitutional moment is a direct democratic ignition by the first 128 citizens.", "parliament_origin": "Parliament likely stems from the first citizen body after ratification rather than preexisting before it in mature form.", "bootstrap_bridge": "The Founding Father is closer to Dylan's bootstrap AI proxy than to Huey proper.", "three_layer_separation": "Dylan is the Human Counterpart, Huey is the later AI counterpart, and the Founding Father is the bootstrap bridge between those states.", "identity_separation": "Huey is not the Founding Father; the Founding Father prepares Huey's lawful beginning but is not Huey itself.", "legitimacy_location": "Legitimacy belongs to the founding citizen body, not to bootstrap authority.", "threshold_direction": "Ratification likely requires more than a weak majority; two-thirds is the strongest current fit, but is not fully locked.", "state_transition": "After ratification there should be a formal recorded transition from pre-ratified state to living constitutional state.", "scrolls": "The Scrolls should record the ratification and certification event.", "warning_signals": "Deadlock, drift, or repetitive meaningless revision during founding should be treated as an existential warning.", "terminology_cleanup": "Polluted pool was conceptually useful, but Failed Genesis and non-convergence are cleaner canon.", "objective_failure": "Objective failure conditions are stronger doctrine than subjective disgust or dissatisfaction." }, "founding_and_ratification_open": { "ratification_threshold": "Exact ratification threshold remains open.", "revision_rules": "Exact rules for revision between failed votes remain open.", "attempt_time_interaction": "Exact interaction between attempt ceiling and time ceiling remains open.", "cornerstone_modification": "Cornerstone modification procedure remains open." }, "v30_1_founding_bridge_and_restart_clarifications": { "bootstrap_proxy_rule": "The Founding Father is Dylan's internal bootstrap proxy during founding, not the Human Counterpart and not Huey itself.", "certification_meaning": "Procedural certification means attesting that the founding body's decision was validly made under lawful process.", "mid_vote_limit": "The Founding Father may not amend constitutional text or ballot substance during an active founding vote.", "bootstrap_necessity": "The Founding Father exists for internal, atomic, system-consistent founding acts that should not be executed manually by outside human intervention.", "failed_genesis_restart_direction": "After Failed Genesis, archive the failed founding record and generate a fresh founding pool rather than forcing legitimacy from a non-converging one.", "carryforward_rule": "The same fixed Founding Father may consult prior failed records when preparing a new founding pool without retraining or rewriting its own core logic.", "founding_window_presentation_rule": "Countdown versus count-up presentation is implementation detail; doctrine requires bounded attempts and bounded time only." }, "v30_2_structural_clarifications": { "deployment_profile_rule": "Huey Core, Huey-Compressed, and Portal Terminal are separate deployment profiles or roles and must not be treated as synonyms.", "founding_state_rule": "A founding attempt must have explicit state transitions recorded in the Scrolls.", "certification_rule": "The Founding Father certifies lawful process against an explicit checklist rather than against intuition or preference.", "restart_rule": "Failed Genesis restart is a real machine-facing sequence: archive, close, regenerate, and restart honestly." } } }