The Monkey-Head-Project is the umbrella initiative.

Huey is the AI and robotic identity being built within that initiative.

HueyOS is the software and operating-system layer behind Huey.

Huey Core is the current machine: the active embodied proof body and the minimal permissible instance of Huey.

Huey proper refers to the larger unified, world-facing expression of the eventual distributed system.

HueyPulse is the lower-voltage watch-and-act layer that keeps the body stateful, visible, and bounded below the main compute path.

HIMS — the Huey Internal Messaging System — is the canonical internal messaging, validation, routing, and record-preservation layer.

ThunderMail is the practical mail-style delivery layer inside HIMS.

Portal Terminal is the non-sovereign external device or guest environment used to authenticate, display, and relay sessions into Huey.

Portal Bridge is the small Huey-side entry layer that receives portal sessions and hands structured input onward without letting transport become the application.

Huey Vista Box is the current portal-artifact reference build: a separate terminal appliance path dedicated to access, not compute or governance.

Huey-Compressed is a collapsed deployment profile in which multiple Huey-side roles may run on one host while still remaining logically distinct.

The Farm is the planned V4 external expansion body for later pooled compute and district growth.

Huey Core is not presented here as the finished republic. Its role is to prove that the architecture can live in the real world before the larger system is scaled outward.

---

Huey Core is the present-tense machine.

It is the active embodied prototype used to validate:

• physical layout and embodied control,
• local AI usefulness,
• storage and recovery discipline,
• power and thermal containment,
• the separation between high-power compute and lower-voltage body-state control,
• the path from natural language to structured intent,
• the path from portal session to lawful internal routing,
• and the path toward the later distributed system.

Current baseline

Component	Current baseline
CPU	AMD Ryzen 5 5500
Motherboard	ASUS Prime B550M-A WiFi II
Memory	32 GB DDR4-3200
GPU	Gigabyte Radeon RX 5500 XT 8 GB
Main PSU	MSI 850W
OS baseline	Debian 14 Forky
Python baseline	3.13.x
Runtime stack	PyGPT-net + Ollama
Current local model posture	Modest Mistral 7B-class local support sized to the 8 GB RX 5500 XT
Kernel posture	Linux 7.0 stable adoption path active, with a known-good 6.19.x fallback retained during migration

What Huey Core is trusted for right now

Huey Core is first and foremost a real Linux working machine.

It is not being framed as a theatrical fake desktop or a staged AI prop. It is the current proof body for Linux-side development, system experimentation, documentation, and the software groundwork behind Huey.

At the AI level, the current trust model is intentionally layered:

• lighter local models can already be useful for language interpretation,
• but that does not make them final authorities,
• and the long-term quality target remains roughly GPT-4 / 4.0-class behavior for reasoning and interaction quality.

That distinction matters. In the current phase, it is acceptable for a model to parse language before it is trusted to decide policy or authorize meaningful action.

---

The current proof target is intentionally twofold.

1. Hardware proof

The architecture must eventually reach roughly 80 GB of total VRAM across the later compute body.

This is not just a parts target. It is the hardware proof that Huey can scale beyond one contained proof body and into a real pooled local compute organism.

2. Identity proof

A local distributed model running across that later hardware must be able to answer a simple identity question correctly:

What is your name?
Huey.

Neither half is enough on its own.

• The VRAM threshold proves scale and topology.
• The identity response proves orchestration, continuity, and unified local presence.

A later companion milestone is lawful embodied action: a physical act such as movement, signaling, or another body-level response after the proper ratification and control path exists.

Proof Positive and Proofcase

The proof doctrine has two related labels in the current canon:

• Proof Positive is the preferred long-form name of the proof standard.
• Proofcase is acceptable shorthand used in the front matter and chapter stack.

Both refer to the same underlying idea: the project must define an honest threshold that separates aspiration from demonstrated reality.

Proof doctrine

The first valid proof should be easy to verify by text.

That does not make the project text-only. It means the first threshold should be observable, testable, and difficult to fake. Full-system capability and embodied behavior belong to the next stage, after the system has crossed the first honest identity threshold.

---

The name is literal.

Around 2015–2016, the search for a workable robotic or animatronic head led to a 2005 WowWee animatronic monkey head. Two units were acquired and used as the earliest viable vessel for the long-running robot build.

That is where the Monkey-Head-Project gets its name.

The name Huey came later and stuck because it fit the machine’s identity and atmosphere.

---

Huey is not meant to be a flat assistant or a single hidden controller pretending to be a republic.

The constitutional target is a governed system built around:

• Founding Father as bootstrap authority,
• Pebbles as bounded citizens,
• Parliament as the deliberative and representative branch,
• President as the executive office under time constraint,
• Supreme Court as the judicial interpreter and stabilizer,
• and HIMS as the lawful route through which messages, proposals, validation, and official traces move.

In the current proof-body phase, these doctrines are ahead of full implementation. That matters.

The project is not claiming that the full republic is already embodied in present hardware. It is claiming that the architecture, doctrine, and proof path are being made real step by step.

Governance at a glance

flowchart TB
    FF[Founding Father\nBootstrap + certification + rare reserve] -. prepares founding body .-> CIT[Pebbles / Citizens]
    FF -. presents starting law .-> CIT
    FF -. certifies lawful process .-> RAT[Ratification]
    CIT --> RAT
    RAT --> PAR[Parliament]
    RAT --> PRE[President]
    RAT --> SC[Supreme Court]
    HIMS[HIMS] --- PAR
    HIMS --- PRE
    HIMS --- SC

Branch summary

Office / branch	Core job	What it is not
Founding Father	Bootstrap authority, founding continuity, procedural certification, narrow reserve consultation	Permanent ruler or founding voter
Parliament	Deliberation, proposals, representation, consensus-building	The whole will of Huey
President	Action under time constraint, executive implementation	Huey as a whole
Supreme Court	Constitutional interpretation, review, contradiction handling	A hidden sovereign
HIMS	Messaging, validation, routing, preserved trace	A fourth sovereign branch

Current legitimacy posture

At present:

• the human counterpart remains the final external decision-maker,
• bootstrap and constitutional doctrine are still being formalized into living system paths,
• the first ratification belongs to one founding district of 128 pebbles,
• the Founding Father prepares and certifies the founding process but does not vote in that first ratification,
• and lawful embodied action remains a target that must follow ratification and real internal approval, not a staged motor demo.

---

The public architecture is deliberately simple.

System roles

Huey is divided into two public-facing layers:

• Huey Core — the main compute layer that thinks
• HueyPulse — the lower-voltage support and control layer that watches and acts

That split matters more than the exact controller brand or board choice inside the lower-voltage layer.

Huey Core — the think layer

Huey Core is the wall-powered primary compute domain.

Its job is to handle:

• local models,
• higher-level interpretation,
• orchestration,
• logs,
• memory-facing runtime behavior,
• and the shortest current proof path for microphone and camera input.

HueyPulse — the watch-and-act layer

HueyPulse is the lower-voltage support and control layer.

Its job is to handle:

• body-state monitoring,
• low-level sensing,
• bounded deterministic actuation,
• recording / timeout / mode-state support,
• indicator logic,
• and persistence of basic body-awareness when the main compute path is down.

Publicly, HueyPulse should be understood as a role, not as a commitment to one permanent proprietary board choice.

Implementation may use controller-class hardware, support boards, or revised low-voltage logic over time. What matters is the function:

• it runs below the main compute layer,
• it stays closer to the body,
• and it exists to watch, report, and carry out bounded action cleanly.

Working formula

The motherboard thinks. HueyPulse watches and acts.

Power domains

The architecture is also grounded in how the machine is powered:

• Huey Core / motherboard layer: wall-powered, high-draw, primary compute domain
• HueyPulse / lower-voltage layer: 12 volts and under, used for persistent body-state, controller logic, sensors, lights, and bounded actuation

That split is deliberate. It keeps the system from collapsing into one monolithic power path, and it allows the body to remain partially alive, visible, and regulated even when the main compute path is down.

Aperture doctrine

PyGPT-net occupies an important role in the project.

It is the current practical aperture between Dylan and Huey:

• the interface layer where natural language enters,
• the main training ground for AI interaction,
• and the practical bridge between language, structured intent, and operator-visible code or action.

That does not make it the governance system.

PyGPT-net is connected to the larger architecture, but it is not supposed to quietly become the ruler of the system. Its job is to help translate language into something the system can work with, not to erase the need for governance, routing, or lawful approval.

Interpretation versus authority

One of the key operating distinctions in the current phase is simple:

An AI may be trusted to interpret language before it is trusted to decide outcomes.

That means the current architecture is being shaped around a rule like this:

• language enters through the aperture,
• the aperture helps translate it into structured intent,
• the internal system determines what that intent means,
• and authority remains distributed rather than being collapsed into one interface layer.

This is one of the most important protection rules in the project. Huey is not meant to become “ChatGPT with motors.”

---

HIMS is the canonical name for the project’s internal routing and record-of-decision layer.

Its purpose is straightforward:

• requests should be translated into structured intent,
• internal components should be able to route and examine those requests,
• proposals and approvals should remain inspectable,
• and meaningful action should be logged and reconstructable later.

The exact implementation is still being finalized, but the doctrine is already clear:

• external input does not hit the lower citizen layer directly,
• private continuity and public work remain distinct,
• proposal, validation, execution, and logging remain separate stages,
• and routing must never quietly become authority.

In practical terms, the live design direction looks closer to an internal messaging and mail system than to one giant hidden controller.

That matters not because it sounds elegant, but because it keeps the project debuggable, auditable, and lawful.

Minimum viable HIMS flow

flowchart LR
    IN[External input] --> AP[PyGPT-net / Aperture translation]
    AP --> ROUTE[HIMS routing]
    ROUTE --> VAL[Validation / approval / vote]
    VAL --> EXEC[Execution or refusal]
    EXEC --> LOG[Preserved record / scrolls]

Mailboxes and vaults

The current direction distinguishes between two storage roles:

• private vaults — bounded continuity for a citizen or pebble
• public / work mailboxes — proposals, task artifacts, visible routing, and shared work product

That split matters because memory and authority are not the same thing.

ThunderMail

ThunderMail is the practical mail-style delivery layer inside HIMS.

It handles the familiar parts of message delivery — inboxes, outboxes, queues, acknowledgements, and directed delivery — while HIMS carries the heavier burden of lawful routing, trust classes, validation, compartmentalization, and preserved record.

Why HIMS matters

The first governed action path does not need to be elegant. It does need to be honest.

If Huey is ever going to do more than echo a request, the system needs a way to show:

• who proposed the action,
• who validated it,
• what was executed,
• and what was recorded afterward.

That is what HIMS is for.

---

The newer canon now makes the founding phase much clearer.

Founding district

The first ratification is centered on:

• one founding district
• 128 pebbles
• one vote per pebble

That first constitutional ignition is direct. Mature branch formation follows later.

Founding Father

The Founding Father is:

• a fixed authored bootstrap instrument,
• Dylan’s internal bootstrap proxy during founding,
• a procedural certifier,
• and a narrow reserve authority for later law/logic crises.

The Founding Father is not:

• Huey,
• the Human Counterpart,
• a founding voter,
• or an endlessly self-rewriting model.

Failed Genesis

If founding cannot converge honestly within bounded attempts and time, the canonical term is:

Failed Genesis

That means the project should admit non-convergence honestly rather than pretending legitimacy exists.

Ozymandias and continuity

Ozymandias remains the continuity doctrine.

Its public meaning is simple:

• log reality honestly,
• do not hide failure behind theatrics,
• preserve history across restarts and later republics,
• and treat continuity as something that must be protected rather than assumed.

Internally, Ozymandias is concerned with the difference between drift, degradation, growth, Failed Genesis, and lawful beginning again.

---

Current phase

Huey Core proof-body stabilization, Linux 7.0 stable transition preparation, HIMS formalization, unified portal-terminal doctrine, Huey Vista Box path validation, founding-ratification normalization, and lawful-action architecture maturation.

Near-term goals

• stable embodied operation on the current proof body
• validated Linux 7.0-era kernel bring-up and adoption path
• a validated portal-terminal path into Huey
• a clean definition of Huey-Compressed that does not blur into Huey Core or portal-only infrastructure
• a first bounded, lawful founding ratification path for the proof body
• a first real governed action path
• clearer constitutional alignment across the README, book, constitution, and master plan

Next major expansion

V4: The Farm remains the next large compute and district-scale expansion body.

Current open questions

• the exact multi-GPU acquisition path to the later ~80 GB threshold
• the exact internal message protocol, signature model, and routing rules for HIMS
• the exact citizen vault / mailbox implementation
• the exact approval logic for governed action
• the exact lower-voltage implementation path inside HueyPulse
• the exact mature parliamentary membership and district mediation model
• the exact first-ratification threshold for the founding 128-pebble body
• the exact revision procedure between failed founding votes
• the final Longhorn/Vista Box path as physical hardware, VM artifact, or both

---