Hardware Innovation
Intelligence Engine

Modern AI systems excel at language, code generation, and analysis within predefined boundaries. What does not yet exist is a system capable of reasoning from an abstract human problem statement through to a physically buildable, commercially patentable, ethically validated engineered solution — autonomously delegating specialized cognitive roles the way a world-class engineering organization would.

HIIE is that system. It is not a chatbot or a code assistant in isolation. It is a complete innovation pipeline: taking the rawest form of human intent and, through recursive reasoning, multi-agent collaboration, and physics-grounded validation, producing outputs that can enter the real world.

Alice and Bob — The HIIE Interaction Model

In the classical cryptographic and distributed systems tradition, Alice and Bob are the canonical principals in any secure, trust-based protocol. HIIE adopts this framing deliberately. Alice is the primary user and directing intelligence — the human who submits intent, approves requirements, and holds final authority over all outputs. Bob represents any secondary principal, collaborator, counterparty, or reviewer interacting with Alice's outputs downstream. In practice, Watson Lewis-Rodriguez occupies the Alice role as founder and director; clients, partners, or contract reviewers occupy the Bob role.

This framing is not cosmetic. It reflects HIIE's architectural assumption that every system must have a verifiable, non-repudiable human principal chain. Alice's sign-off at every gate is cryptographically analogous to a digital signature — it cannot be forged, delegated to an agent, or bypassed by any instruction.

Guiding Principles

• »Ethics above all engineering outputs — no design exits without ethical validation
• »Human oversight is non-negotiable — HIIE is directed intelligence, never autonomous in consequence
• »Agent control is exception-based — agents run unless stopped; Alice holds veto and kill-switch authority, not a spawn-approval queue
• »Physical feasibility is a hard constraint — theoretical elegance without manufacturability is rejected
• »Environmental net-positivity is a default design target, not an afterthought
• »Full transparency in every reasoning step — the system explains every recommendation
• »AI slop prevention is an architectural requirement — every output is validated, recursive, and human-perspective-tested before delivery

HIIE operates as a layered pipeline. Each layer is a discrete processing stage that feeds both downward into execution and upward into refinement. The architecture is deliberately non-linear — outputs at any stage can trigger re-evaluation upstream.

Every completed project feeds back as a training signal — including into the persistent fine-tuning layer (§8.9), which runs MLX-LM on GPU during post-project idle cycles and benchmarks concurrent ANE training as a research path — improving HIIE's domain accuracy and real-world feasibility calibration over time.

HIIE Phase 1 runs on a single Mac Mini M4 Pro node, hosted at Registered Agentics facilities. Apple Silicon's unified memory architecture eliminates the PCIe bandwidth bottleneck present in traditional CPU/GPU/RAM split configurations.

Target Configuration

Storage Architecture — SSD-Constrained Design

Given the 256GB SSD versus 5TB HDD constraint, HIIE implements a streaming-first data architecture. The core principle is:

Internet content, patent databases, research papers, and GitHub repositories are analyzed entirely in RAM and never written to disk. Only extracted structured embeddings — typically < 0.1% of the original corpus size — are persisted to ChromaDB on HDD. This means:

Storage Tier Lifecycle. HIIE enforces a two-tier storage lifecycle with explicit, directional data flow:

• »SSD — Working Tier: All data required for active inference lives here: model weights, hot vector shards for active projects, current LoRA adapters, active project outputs, and agent state checkpoints. The inference pipeline reads exclusively from SSD during active operation.
• »HDD — Archive Tier: Completed project directories, the full ChromaDB collection suite (excluding hot shards on SSD), versioned adapter history, and curated datasets are committed to HDD at project close. HDD is not read during active inference — only at project initialization (adapter loading) and on-demand archive retrieval.

Per-Project SSD Budget. Each active project consumes approximately 30 GB of SSD working space: hot vector shards, intermediate outputs, agent state, and session logs. Given the 60 GB SSD allocation for hot cache and active outputs (§3.3), two concurrent active projects is the practical maximum before the SSD working budget is exhausted.

Memory Allocation Strategy

CPU / GPU Task Assignment

CPU/GPU/RAM Load Model

The following mathematical model governs resource allocation under multi-agent load. Let N be the number of active agents, M_i the memory footprint of agent i, and T_inference the per-token inference time:

When RAM_required > 0.85 × RAM_available, the Celery task queue throttles agent spawning:

Registered Agentics — Cloud Infrastructure Partner

Registered Agentics (https://registeredagentics.ai/), co-authored and operated by Marko Ruble, provides the physical cloud infrastructure layer for HIIE deployment at scale. Registered Agentics functions as a Wyoming-incorporated registered agent service that additionally provides:

• »Physical Mac Mini hosting — dedicated machines allocated per client or project tier, maintained at Registered Agentics facilities
• »Property allocation — each Mac Mini is registered as a dedicated asset under a client's contract, with full hardware isolation
• »Logistics and transfer — upon contract termination (standard one-year term), the Mac Mini is physically transferred and delivered to the client
• »Wyoming registered agent services — reduces state-level administrative fees and provides legal registered presence
• »Maintenance contracts — on-site hardware maintenance, network uptime guarantees, and physical security

Coolify — Deployment & Orchestration

All HIIE microservices run as containerized Coolify applications locally. Key capabilities: automatic SSL via Let's Encrypt, Cloudflare Tunnel for external access without a static IP, per-service monitoring and restart policies, environment variable management, and one-click rollback for any service version.

OpenClaw — Chat Interface & Relay Layer

OpenClaw functions simultaneously as the user-facing chat application and the internal message bus through which agents communicate during active projects. It provides file upload support (spec sheets, PDFs, Gerber files, whitepapers), real-time streaming output from all active domain agents, and human sign-off gates — HIIE cannot proceed past key checkpoints without explicit OpenClaw confirmation from Alice.

Core Service Stack

"AI slop" refers to outputs that are syntactically plausible but semantically hollow, physically infeasible, or epistemically unchecked — outputs that look like answers but are not engineering solutions. HIIE treats slop prevention as an architectural first-class concern, not a post-hoc filter.

Three Pillars of Slop Prevention

Pillar 1: Recursive Validation with Divergence Enforcement

Each domain output undergoes iterative self-critique and cross-agent challenge. Let O_k be the output at iteration k and sim(·, ·) be cosine similarity in the output embedding space. The recursion continues until:

If sim(O_k, O_k−1) ≥ 0.92, the system forces a divergence prompt — injecting a contrastive perspective that challenges the current reasoning path. This prevents circular loops where agents reinforce each other's errors.

Stack overflow protection is enforced via a hard recursion depth limit D_max = 8, after which the current best output is escalated to Alice with a flag rather than continuing to recurse:

Pillar 2: Human Perspective Injection

At defined checkpoints, HIIE generates a layperson summary and a domain-expert critique of every technical output. These are required inputs to the Feasibility Manager's scoring function:

where w₁ = 0.35, w₂ = 0.30, w₃ = 0.20, w₄ = 0.15 and all S_i ∈ [0, 100]. Outputs with F_score< 65 are rejected and returned to the agent team for rework. Outputs with F_score ∈ [65, 80) are flagged for Alice's attention. Outputs with F_score ≥ 80 proceed to the Ethics Board.

Pillar 3: Physical Ground-Truth Validation

Every design claim must be anchored to a verifiable physical reference:

• »Material properties sourced from NIST, Matweb, or ASM International — not generated from model weights
• »Electrical designs validated against PySpice simulation before proceeding
• »Mechanical designs stress-tested in FreeCAD Python API before BOM generation
• »Chemistry outputs cross-referenced against PubChem and ChemRxiv before synthesis feasibility is asserted

Preparation Steps for Anti-Slop Implementation

1. 1
   Embed ground-truth retrieval at every domain module entry point.

   Before any generative step, the relevant module retrieves authoritative source data (NIST, PubChem, USPTO, IEEE). The model reasons from data, not toward plausible-sounding data.
2. 2
   Implement the cosine similarity divergence check (τ = 0.92) in the Celery task wrapper.

   Every agent output is embedded and compared to its predecessor before the next iteration is spawned.
3. 3
   Deploy the Feasibility Manager as a separate model instance.

   It must not share context with the generating agent — independence is required for genuine critique.
4. 4
   Configure Dmax = 8 and automatic escalation in the FastAPI orchestration layer.

   Hard-code this limit; do not make it a configurable parameter that can be overridden by a project prompt.
5. 5
   Require layperson and expert summaries at every approval gate.

   Alice reads both before signing off on requirements, interim designs, and final outputs.
6. 6
   Log all validation failures with full reasoning traces to the immutable audit log.

   Failure patterns become training signals for improving domain module prompts.

Feasibility Manager as Training Signal Gatekeeper

The Feasibility Manager's role extends beyond active validation into the training pipeline. Before any labeled output pair is written to the ChromaDB training partition, the F_score assigned by the Feasibility Manager is attached as mandatory metadata. The MLX-LM fine-tuning process at project close weights training examples by this score:

• »F_score ≥ 80 — full gradient weight; example enters the training batch at standard importance
• »F_score ∈ [65, 80) — reduced gradient weight; example contributes but at diminished influence
• »F_score< 65 — flagged and excluded from the active fine-tuning batch unless the batch is otherwise too small to train effectively

This closes a critical feedback loop: an agent consistently producing mediocre outputs would otherwise generate mostly mediocre training data, fine-tuning itself toward mediocrity over time. The Feasibility Manager as training signal gatekeeper breaks this loop.

Because the FM's output now influences every other agent's future capability, Arthur monitors FM adapter health with elevated priority. FM adapter rollback thresholds are tighter than other agents — a smaller F_score delta drop should trigger a rollback flag for the FM than for domain agents (§8.9.4).

Recursive Reasoning — Overflow Prevention

HIIE uses iterative deepening with hard depth limits and SSD checkpointing rather than pure recursion. A similarity detection threshold (τ = 0.92) forces divergent reasoning when outputs converge. RAM pressure monitoring triggers state serialization to SSD above 85% utilization.

Each project spawns a full agent team. Alice and Arthur are the two permanent principals across all projects.

Runtime Initiation — Two-Layer Delegation

Agent spawning is governed by a two-layer authority model that separates strategic initiation (Arthur's domain) from operational initiation (the Project Manager's domain). Neither layer can act without the other, and both are blocked by the agent registry for any role Alice has disabled.

Arthur — Strategic Initiation

Before any project begins, Arthur evaluates project similarity to prior work, assesses adapter maturity for required roles, reviews system KPI health (§8.8.2), and proposes an agent roster and resource configuration to Alice. Alice's approval of the requirements document implicitly approves this roster unless she explicitly modifies it. Arthur's initiation decision is grounded in project history, system economy data, and Alice's stated intent.

Project Manager — Operational Initiation

Once Arthur's roster is confirmed, the PM executes the spawn sequence:

• »Loads adapters from warm HDD archive into the SSD working tier
• »Sequences agent spawns to respect the RAM pressure formula (§3.5)
• »Communicates resource requirements to the Treasury Agent
• »Establishes the agent dependency graph for the project
• »Selects which adapter version to load per role by consulting Arthur's system economy KPI data — the version with the best recent F_score delta is selected

Agent Registry & Exception-Based Control

A persistent agent registry maintained by the PM holds an enabled/disabled flag per agent role. Agents run unless stopped. Alice can disable any agent at any time through the OpenClaw interface with no justification required. Disabled agents release their RAM allocation to the pool immediately; the Treasury Agent logs the disable event and its resource impact. Arthur flags to Alice if a disabled agent creates a capability gap affecting project output quality. The registry check occurs before any spawn command is issued. The registry also tracks adapter maturity per role:

• »Cold — newly commissioned; no training history; conservative HCT assignment; PM generates a gap report before spawning
• »Developing — 1–5 project cycles completed; adapter improving; standard HCT assignment
• »Mature — 6+ cycles; F_score delta consistently positive; eligible for base HCT reduction as efficiency grows

When a project requires a role not in the registry, the PM generates a gap report to Alice rather than silently spawning a cold-start agent. When a new role is commissioned, the PM initializes it at cold maturity and flags to Arthur that no training history exists.

Project Manager — Expanded Responsibilities

The PM is elevated from coordination role to active runtime decision-maker. In addition to operational initiation (§7.2), its expanded responsibilities are:

• »Scope estimation — evaluates Alice's requirements document and translates it into a projected HCT budget, projected timeline in project cycles, and a risk flag if scope is significantly outside prior project patterns; feeds into the intake quality gate
• »Resource state translation — reads real-time system metrics (RAM utilization, HCT spend rates, agent queue depth, SSD working budget) and produces plain-language status summaries surfaced through the admin dashboard (§13); provides the narrative interpretation layer on top of raw metrics when Alice requests a status briefing
• »Onboarding registry management — maintains the agent registry (§7.3); initializes cold-start roles with conservative HCT; flags capability gaps to Alice before spawning

The PM's LoRA adapter trains on project-level telemetry: milestone timing, agent conflict patterns, HCT spending distributions, and Alice approval gate outcomes. This is meta-knowledge, not domain knowledge — the PM does not need to understand circuit design; it needs to understand that Hardware Engineering tasks at a given complexity tier historically cost N HCT and produce first-pass F_score values around M.

Research Agent Architecture

The three Research Group agents run on Qwen3.5-9B with retrieval-specialized LoRA adapters. Model size is intentionally constrained — high retrieval throughput and extraction precision are the primary requirements, not deep domain reasoning. Domain agents consume Research outputs; Research agents do not need to reason deeply about what they find.

• »Source quality discrimination is a trained capability, not a hardcoded list. Each Research agent's adapter trains on labeled examples of high-quality versus low-quality sources per domain (e.g., USPTO and NIST are authoritative; SEO aggregators are not). This discrimination lives in adapter weights and improves with each project cycle.
• »Negative knowledge is its own training signal. When a retrieved source contributes to an output flagged by the anti-slop validator or rejected by Alice at a gate, that source receives a negative training signal. The Research agent gradually learns the topology of reliable versus unreliable information space for each domain.
• »Credential management is operational infrastructure attached to the Research agents. A credentials store holds authenticated access tokens for IEEE Xplore, PubChem, USPTO, Google Patents, arXiv, and other high-value sources. Research agents query this store before attempting retrieval. Paywalled sources without available credentials generate a credential gap flag to the PM's onboarding registry rather than a retrieval failure.
• »Context sizing is moderate — sufficient to hold several retrieved documents for cross-referencing, not maximized. Memory headroom is better allocated to the Theoretical Engineer and Hardware Engineering agents that perform deep reasoning on Research outputs.

Inter-Agent Communication Protocol

Agents do not communicate through conversational exchange. All inter-agent communication is mediated through structured typed outputs via the FastAPI message bus. Each agent role has a defined output schema. An agent consuming another agent's output receives a typed object, not free-form text — the Hardware Engineer produces a structured component specification; the Materials Engineer consumes it. Co-evolution happens through shared interface contracts, not direct coupling.

• »The PM has read access to all message bus traffic for coordination
• »Arthur has read access for drift detection
• »As adapters mature, agents produce more precisely structured outputs — specialization improves the shared interface rather than fragmenting it

Individual KPIs are tracked per agent. The system-level KPI dashboard (§8.8.2) aggregates them. The individual signal identifies if a specific agent is degrading; the aggregate signal identifies if the system as a whole is improving or regressing. Both are required and serve different diagnostic purposes.

HIIE operates as more than a technical pipeline — it is a self-governing economic system. Every participant, human or agent, operates within a measurable framework of resource allocation, performance accountability, and convergent incentives. The goal is not punishment for failure but continuous refinement toward precision: a closed loop in which every decision, at every level, improves the quality of subsequent decisions.

§8.1HIIE Compute Token (HCT) — The Internal Unit of Account

The HIIE Compute Token (HCT) is the internal resource accounting unit governing all agent activity. It is not a currency, carries no external value, and has no relationship to client billing or any outside economy. It exists solely to make resource consumption visible, attributable, and optimizable within the system. One HCT represents a normalized bundle of compute resources:

where α, β, and γ are weighting coefficients reflecting the relative scarcity of each resource on the Mac Mini M4 Pro node (α > β > γ, GPU time being the most constrained). The Treasury Agent recalibrates these coefficients at the start of each project based on current system load.

§8.2Dynamic Resource Pricing — Self-Determining Allocation

Rather than a static throttle ceiling, resource costs fluctuate continuously as a function of real-time utilization U(t) ∈ [0, 1]:

where P_base is the nominal HCT cost per resource unit, λ is the price sensitivity parameter, andϵ prevents division by zero near full saturation. This produces a self-correcting market signal:

• »Underserved environment (U(t) < 0.50) — HCT cost falls below P_base, incentivizing the scheduler to allocate more work to available capacity
• »Nominal range (0.50 ≤ U(t) < 0.85) — HCT cost near baseline; agents operate at standard allocation
• »Overserved environment (U(t) ≥ 0.85) — HCT cost spikes sharply; agents are naturally incentivized to compress context, yield memory, or queue rather than compete for resources

This replaces the existing hard throttle with a continuous price gradient, preserving the 85% ceiling as an economic signal rather than an abrupt cutoff.

§8.3Agent Payroll — Base HCT Allocation per Project Cycle

Each agent role receives a guaranteed base HCT allocation at project initialization — the payroll. This is the minimum resource floor the agent is entitled to regardless of project complexity. The Treasury Agent distributes these allocations before any task execution begins.

§8.4Performance Bonuses — HCT as Quality Signal

Agents that exceed baseline performance earn bonus HCT redeemable within the same project cycle to request additional compute, spawn sub-agents, or extend live retrieval sessions. Bonus HCT cannot be accumulated across projects — it expires at project close. The bonus for agent i is computed at each project milestone:

where F_i is the agent's Feasibility Score contribution, F_target = 80, d_i is the recursion depth at which the agent resolved its task, D_target = 4 (the efficient midpoint of the D_max = 8 limit), andA_i ∈ {0.5, 1.0, 1.5} reflects Alice's final gate decision (rework required / accepted / accepted with commendation). Outputs blocked by the Feasibility Manager return zero bonus for that cycle. Outputs rejected by the Ethics Officer trigger a bonus claw-back: previously awarded HCT for that task is reclaimed by the Treasury Agent.

§8.5Treasury Agent — Self-Auditing & Checks and Balances

The Treasury Agent is a lightweight, always-on process running independently of the domain agent team. It holds no domain knowledge and participates in no engineering tasks. Its sole function is economic governance:

• »Project-level HCT cap enforcement — total spend across all agents cannot exceed the project budget ceiling, set at initialization based on project complexity tier
• »Spending velocity monitoring — flags any agent whose HCT consumption rate exceeds 2× its base allocation per time window without a corresponding milestone output
• »Claw-back execution — reclaims bonus HCT from agents whose outputs are subsequently rejected downstream
• »Gate suspension accounting — when Alice has not approved a gate, the Treasury Agent suspends all blocked agents, releases their RAM allocation back to the pool, and logs the idle period. Upon Alice's approval, agents are reinstated with their HCT entitlements preserved but their held RAM re-priced at the current dynamic rate
• »Immutable spending ledger — a tamper-evident log of all HCT allocations, spends, bonuses, and claw-backs per project, parallel to the ethics audit log and exportable alongside it

The Treasury Agent's own audit logic is protected from modification by any agent instruction, mirroring the immutability of the ethics framework. No agent, including Arthur, can alter the Treasury Agent's accounting rules.

§8.6Alice Accountability Protocol — Convergence Without Penalty

Exception-Based Agent Control

Alice's operational authority over the agent system is a kill switch and veto right, not a spawn- approval queue. Agents run unless stopped. The persistent agent registry (§7.3) holds an enabled/disabled flag per agent role. Alice can disable any agent at any time through the OpenClaw interface with no justification required. Disabled agents release their RAM allocation to the pool immediately. The Treasury Agent logs the disable event and its resource impact. Arthur flags to Alice if a disabled agent is creating a capability gap affecting project output quality. Alice's gate authority — approving requirements documents, interim outputs, and final deliver- ables — is unchanged and non-negotiable. What is eliminated is any implicit requirement for Alice to manage operational agent state. She governs outputs, not operations.

Output Authority & Convergence Mechanism

Alice holds final authority over all HIIE outputs and bears no resource loss, HCT deduction, or score penalty under any circumstance. Her accountability mechanism is entirely Socratic and convergent: the system will not advance past a stage until Alice's input meets the minimum quality threshold for that stage. The mechanism is designed to eliminate the worst outcome in any AI-assisted system — a vague input accepted without challenge that generates a plausible-looking but fundamentally misaligned output, trapping the entire pipeline in a slop cycle from which recovery requires a full restart.

Project Commitment Declaration

Before any agent is spawned or any HCT is allocated, Alice must pass an intake quality gate. The system evaluates her problem statement across three dimensions:

where w_s = 0.40, w_c = 0.35, w_b = 0.25 and all scores ∈ [0, 100]. If Q_Alice< 70, the system returns a single targeted Socratic question — not a list of problems, not a form to fill out, but one precise question aimed at the largest ambiguity. This repeats until the threshold is met. No compute is allocated until Q_Alice ≥ 70. This is not a friction mechanism. It is waste prevention at source — the most efficient point in the entire pipeline to correct a misalignment is before any work begins. Every Socratic exchange brings Alice closer to the precision required for a high-quality outcome. The loop never punishes; it only refines.

Exploratory vs. Committed Mode

Alice explicitly declares her intent before the intake gate opens:

• »Exploratory Mode — limited agent instantiation, reduced HCT allocation, no deliberation scoring, no intake quality gate. Alice is thinking out loud. The system assists without full commitment. Exploratory sessions do not feed into Alice's system-level contribution history.
• »Committed Mode — full agent team, full HCT allocation, intake quality gate active, deliberation scoring active. Alice is initiating a real project. All gates and accountability mechanisms are live.

The system never silently treats an exploratory session as a committed project. Resource allocation scales to declared intent.

Deliberation Scoring at Approval Gates

At each approval gate, the system records a deliberation signal: the time elapsed between gate presentation and Alice's decision, and whether she engaged with both the layperson summary and the expert critique before approving. Rapid sequential approvals — gates cleared without meaningful engagement — are flagged in the immutable audit log and surfaced to Arthur. Arthur is then required to present a structured alternative perspective before the next gate opens. Alice can still proceed — her authority is absolute — but she does so on the record, with Arthur's analysis attached to the project audit trail. The deliberation signal does not block Alice. It ensures that when she chooses to move fast, the system has done its duty to surface what she may have passed over.

§8.7Arthur as Bilateral Auditor

Arthur's existing role — persistent AI co-director, long-term memory keeper, advocate for Alice's original intent — is extended bilaterally. He audits both directions of the pipeline:

• »Downward — agents drifting from Alice's stated requirements, output quality regression between milestones, domain modules producing internally inconsistent results (already defined in Arthur's role)
• »Upward — Alice's gate decisions contradicting her own requirements document, approval patterns that correlate with downstream rework, input patterns that historically produce low-F_score outcomes

When Arthur identifies an upward inconsistency, he surfaces it as a structured alternative: a concise statement of what Alice originally declared, what she is approving now, and what the predicted HCT cost of the divergence is. Arthur never blocks Alice. He ensures that every consequential decision is made with full awareness of its implications.

§8.8Cross-Project Durability — The Two-Layer Economy

The HCT economy operates across two distinct temporal scopes:

Project Economy (Ephemeral): HCT budgets, bonus pools, spending ledgers, and per-project scores reset completely at project close. No agent carries debt or surplus into a subsequent project. Each project begins on an equal footing.

System Economy (Persistent): Agent specialization weights, base HCT allocation adjust- ments, Arthur's memory of Alice's input patterns, and system-level KPI trends persist across the lifetime of the system. A Hardware Engineering agent that has completed forty PCB projects reaches the same F_score threshold with fewer HCT than one on its second project. That efficiency delta is a system-level asset, tracked by Arthur and reflected in future base payroll assignments.

Reputation Decay Function

To prevent early-project performance from permanently defining an agent's allocation — and to prevent one poor session from permanently coloring Alice's Socratic treatment — all system- economy scores apply an exponential decay:

where λ_d is the decay rate (default: half-life of 90 days), t₀ is the timestamp of the last project, and ∆R_i is the performance delta from the most recent project. Recent performance always outweighs historical performance. The system learns from history without being imprisoned by it.

System-Level KPI Dashboard

Arthur maintains and surfaces a set of macro-level KPIs across all projects that reflect the health and trajectory of HIIE as a whole:

Sustained degradation in any KPI triggers Arthur to surface a structured system health report to Alice, recommending specific adjustments to agent payroll weights, intake quality thresholds, or project scoping practices. Arthur proposes; Alice decides.

Reserve Pool — Project Insurance

Each project initializes a reserve pool of HCT set at 15% of the total project budget. The reserve is held by the Treasury Agent and is not accessible to individual agents during normal operation. It is deployed only under two conditions:

• »Cascade failure absorption — if a domain module produces a catastrophically rejected output requiring full rework, the reserve covers the rework cycle without stripping HCT from other agents mid-project
• »Ethics Officer override costs — if the Ethics Officer vetoes an output and triggers a mandatory redesign, the redesign cycle is funded from the reserve, not from agent bonuses

Unused reserve HCT at project close is not distributed as bonus. It returns to the system pool, recorded in the spending ledger as reserve returned, which is itself a positive system-level signal: a project that did not need its reserve is a well-scoped, well-executed project.

§8.9Persistent Intellectual Capital — LoRA Fine-Tuning, ANE Benchmarking & Specialist Adapter Compounding

The HCT economy governs how HIIE allocates compute during active project execution. Section 8.9 extends that economy into a dimension that operates beneath active inference: the continuous, silent improvement of specialist model weights using dedicated silicon that would otherwise sit idle.

This is HIIE's persistent intellectual capital layer. Every project produces labeled training signal. Every idle GPU cycle is an opportunity. Every completed year of operation leaves the Mac Mini more capable than when it started — not because its hardware changed, but because its specialist models have been fine-tuned on real, validated, Arthur Labs project outcomes.

§8.9.1 The Idle Silicon Problem

HIIE's fine-tuning infrastructure addresses idle silicon on two fronts, at two different maturity levels.

Between-project idle GPU (production path). During active inference, HIIE's GPU (20-core M4 Pro) is fully allocated to running Qwen3.5-35B-A3B for orchestration, Qwen3.5-9B specialist agents, domain reasoning, and embeddings. But between projects — during the break state (§9.2.4) — the GPU sits idle while Arthur runs system health checks and prepares the next project roster. This represents continuous waste of the primary compute resource. MLX-LM closes that gap by running LoRA fine-tuning passes on all agent adapters during break state windows, using the full 40GB unified pool without any contention with active inference. Training and inference are sequential, not concurrent — but every break state is a fine-tuning opportunity that would otherwise be lost.

During-inference ANE (experimental path). The Apple Neural Engine (16-core, 38 TOPS) is architecturally separate silicon that receives no work from Metal or Ollama during standard GPU inference. This represents potential for concurrent fine-tuning — training while inference runs, on genuinely separate hardware. HIIE is actively benchmarking ANE-based LoRA training via reverse-engineered private APIs (the _ANEClient / _ANECompiler pathway). Current benchmarks show ∼91–110 ms/step at ∼5–9% ANE utilization on 109M-parameter models — a research-grade result, not yet production-stable. The primary limitations are API stability across macOS updates and CPU fallback for weight-gradient accumulation.

The two paths are complementary: MLX-LM provides a reliable, high-utilization production fine-tuning runtime today; ANE benchmarking is building toward concurrent zero-contention fine-tuning in a future phase. Both results feed into the same adapter versioning and ChromaDB training partition infrastructure.

§8.9.2 What Is Being Trained — LoRA Adapters, Not the Base Model

HIIE's primary inference model (Qwen3.5-35B-A3B at 4-bit quantization) is never modified. It remains frozen on SSD, serving as the stable reasoning foundation for the orchestrator. Specialist agents share a frozen Qwen3.5-9B base model. What the fine-tuning layer trains are Low-Rank Adaptation (LoRA) adapters — lightweight parameter overlays that modify how the base model behaves for a specific domain task without altering its weights.

LoRA adapters are architecturally small: typically 10–50MB per adapter versus 14GB+ for the base model. They are loaded at agent instantiation and unloaded when the agent completes. Multiple adapters can coexist on SSD simultaneously, each representing a different specialist agent's accumulated learning.

Base Qwen3.5-9B Specialist (frozen on SSD, ∼5GB)
  ⊢ Adapter A: Patent Strategist    (∼30MB)
  ⊢ Adapter B: Chemistry Agent      (∼25MB)
  ⊢ Adapter C: Feasibility Manager  (∼20MB)
  ⊢ Adapter D: Hardware Engineer    (∼35MB)
  ⊢ Adapter E: Materials Engineer   (∼28MB)

Each adapter represents a branch off the frozen base model trunk. The trunk never changes. The branches grow continuously as HIIE completes projects. This is the hardware expression of the two-layer economy described in §8.8: the System Economy's persistent learning is literally encoded into separate silicon and stored as versioned adapter files on HDD.

§8.9.2a Individual vs. Collective Training — Architectural Rationale

The frozen base model is the collective intelligence layer. All agents share identical foundational language understanding, reasoning capability, and world knowledge through the shared Qwen3.5 base. The LoRA adapters are the individualistic specialization layer. The architecture is both collective and individual simultaneously — collective at the base, individual at the specialization boundary.

Individual adapters are necessary because each role optimizes for a different and partially conflicting reward signal:

• »The Patent Strategist is rewarded for claim precision and novelty window identification
• »The Feasibility Manager is rewarded for calibrated scoring accuracy
• »The Chemistry Agent is rewarded for Tanimoto novelty scores and synthesis feasibility assessment

Collectively training these reward signals into a single adapter would produce averaging toward mediocrity rather than specialization toward excellence.

Partial exceptions. The Feasibility Manager's adapter is inherently cross-domain — its job is to evaluate every other agent's outputs, so its training data spans all domains. Its adapter should be trained on labeled output pairs from every domain, making it the only agent with a genuinely collective training signal. This reinforces the requirement that it run as an independent model instance: it cannot share context with the agents it is evaluating. The PM's adapter is also partially collective, trained on project-level telemetry that spans all domain types — but its learning target is meta-level patterns, not domain content.

§8.9.3 Single-Layer Fine-Tuning — Architectural Placement

HIIE's current fine-tuning configuration targets single-layer transformer fine-tuning per training pass: one complete attention + FFN block. The question of which layer to target is not arbitrary. Transformer layers are not equivalent in function. Early layers (0–8 in a 32-layer model) encode syntax and surface patterns — foundational knowledge that does not benefit from domain-specific adaptation. Mid-to-late layers (layers 16–28) encode domain reasoning, concept formation, and task-specific behavior. These are the highest-value targets for specialist fine-tuning.

HIIE targets late-layer fine-tuning for all specialist adapters. A Patent Strategist adapter trained on layers 19–26 improves how the agent reasons about novelty windows and claim structure — without touching the foundational language understanding that makes it useful in the first place.

§8.9.4 The Training Data Pipeline — Project Outcomes as Labels

HIIE does not require external datasets to fine-tune its specialist models. Every completed project generates labeled training signal automatically through the existing validation and approval architecture:

• »Feasibility Manager outputs carry Fscore labels — scored pairs of (agent output, feasibility score) are ground-truth training examples for the Feasibility Manager adapter
• »Alice acceptance decisions at approval gates provide binary and graded labels (rework required / accepted / accepted with commendation) for all domain agent adapters
• »Ethics Officer assessments label dual-use risk, environmental impact, and structural compliance — training signal for the Ethics scoring model
• »Anti-slop divergence flags identify outputs that required forced re-reasoning — negative training examples that teach agents to avoid convergence traps
• »Simulation validation results (PySpice pass/fail, FreeCAD stress test outcomes) anchor training signal in physical ground-truth — not model preference

Fscore-weighted gradient application. Before any labeled output pair is written to the training partition, the Fscore assigned by the Feasibility Manager is attached as mandatory metadata (§5.3). The fine-tuning process at project close weights training examples by this score: full gradient weight above 80, reduced weight in [65, 80), excluded below 65. This ensures agents cannot fine-tune themselves toward mediocrity using their own low-quality outputs as training signal.

This loop requires no human curation, no external dataset acquisition, and no additional infrastructure. The training data is a natural byproduct of HIIE's existing validation architecture. The fine-tuning layer simply harvests what the pipeline already produces.

§8.9.5 RAG and Fine-Tuning as Complementary Memory Systems

RAG (ChromaDB) and LoRA fine-tuning serve distinct and non-competing memory functions. They operate at different layers of the intelligence stack and must be understood as complementary, not redundant:

The interaction between the two systems is multiplicative, not additive. A fine-tuned Patent Strategist adapter improves the agent's ability to reason about the patent documents retrieved by RAG. A well-populated ChromaDB provides richer retrieval context that the fine-tuned model is better equipped to synthesize. Each layer makes the other more effective.

§8.9.6 Adapter Versioning, Storage, and the Machine as Asset

All LoRA adapters are versioned and stored on the 5TB HDD alongside ChromaDB. Storage overhead is minimal — a full suite of specialist adapters across all HIIE agent roles consumes less than 500MB total, a negligible fraction of available HDD capacity.

Adapter versioning follows the project lifecycle:

• »Each adapter version is tagged with the project batch that produced it and the Fscore delta observed across that batch
• »Previous adapter versions are archived, not deleted — rollback is available if a fine-tuning batch degrades performance
• »The Treasury Agent monitors HCT efficiency ratios across adapter versions — a version that produces lower Fscore outputs at equal HCT cost triggers an automatic rollback flag to Alice
• »Arthur tracks adapter performance trends as part of the System-Level KPI Dashboard (§8.8.2), surfacing degradation before it affects client-facing output quality

This versioning architecture produces a significant commercial property: the Mac Mini delivered to a Builder or Enterprise client at contract year-end is not the same machine that was initialized twelve months prior. It carries trained specialist adapters derived from real project outcomes — accumulated intellectual capital encoded in weights, archived in ChromaDB, and versioned in the adapter store. The hardware asset appreciates over the contract term.

§8.9.7 Maturity Trajectory — Phase Alignment

The fine-tuning capability matures across HIIE's development phases. MLX-LM provides the production-stable path from Phase 1; ANE concurrent training matures as a research track in parallel:

1. 1
   Problem Statement Input

   Alice submits goal in any form through OpenClaw: sentence, paragraph, spec sheet upload, reference images, prior art documents.
2. 2
   Socratic Clarification Loop

   HIIE asks one targeted question at a time. Arthur flags contradictions. No assumptions made without confirmation.
3. 3
   Requirements Document — Human Approval Gate

   Structured requirements presented to Alice. No project work begins without explicit sign-off. This document governs all subsequent agent decisions.
4. 4
   Agent Team Spawn & Research Phase

   Full agent team initialized. Research Group begins live retrieval. Theoretical Engineer generates first-principles concepts. Patent Strategist scans global landscape.
5. 5
   Parallel Domain Generation

   Domain modules execute via async task queues. Feasibility Manager cross-validates. Alice receives streaming progress and can redirect any agent in real-time.
6. 6
   Anti-Slop Validation Loop

   Cosine similarity divergence checks, Feasibility scoring (F_score ≥ 65 required), and physical ground-truth anchoring execute before simulation.
7. 7
   Simulation & Validation Loop

   Electrical, mechanical, and thermal simulations run against designs. Results feed back to agents for refinement. Loop continues until thresholds are met or escalated.
8. 8
   Ethics Board Review — Human Approval Gate

   Full output reviewed by Ethics Officer. Any flag requires Alice's explicit acknowledgment before final output proceeds.
9. 9
   Final Output Package & Archive

   Documentation Architect compiles complete deliverable set. Alice performs final review. Upon sign-off, outputs archived to HDD, patent strategy initiated, and project outcomes written to the fine-tuning training partition (§8.9).

Project Lifecycle State Machine

HIIE operates as a four-state system. Every project is a complete cycle through these states. Feedback loops are explicit — the system never advances without conditions being met, and never silently regresses. Direction of flow is always defined; no transition is implicit.

State 1 — Initialization

Entry: Alice initiates a project (Committed Mode) or Arthur flags readiness from the break state.

Arthur proposes an agent roster and resource configuration based on project similarity to prior work and adapter maturity. The PM loads adapters from HDD archive into the SSD working tier, sequences spawn order against the RAM pressure formula, and establishes the agent dependency graph. The Treasury Agent allocates HCT budgets. Research agents begin live web retrieval. Alice passes the intake quality gate and approves the requirements document. Alice's approval of the requirements document implicitly approves Arthur's proposed roster unless explicitly modified.

Exit: Alice signs off on the requirements document ⇒ transition to Active Execution. If requirements change during Active Execution, the system loops back here.

State 2 — Active Execution

Entry: Requirements document approved.

Agents run in parallel lanes. All inter-agent communication is mediated through structured typed outputs via the FastAPI message bus (§7.6) — not conversational exchange. The anti-slop validation loop, Feasibility Manager scoring, simulation runs, and Ethics Board review all execute within this state. Alice receives streaming progress and can redirect any agent or veto any output in real-time. Each agent accumulates labeled training pairs in ChromaDB's training partition throughout this state.

Internal loop: Validation failures or Feasibility scores below threshold return the output to the originating agent for rework — loop continues until thresholds are met or D_max is reached and escalated to Alice.

Exit: Alice signs off on the final output package ⇒ transition to Project Close. If Alice modifies requirements significantly, loop back to State 1.

State 3 — Project Close

Entry: Alice final sign-off on deliverables.

Active inference load drops. MLX-LM LoRA fine-tuning runs on GPU for each agent role whose adapter has accumulated sufficient new training pairs (with F_score-weighted gradients, §8.9.4). Each adapter is versioned and archived to HDD. The active symlink for each role is updated to the new version if F_score delta is positive; if delta is negative, the previous version is retained and a rollback flag is surfaced to Arthur. ANE benchmarking runs if active. The Treasury Agent finalizes the spending ledger. All project outputs are archived to HDD.

Exit: Fine-tuning and archival complete ⇒ transition to Break State.

State 4 — Break State

Entry: Project close archival complete.

Arthur runs system health checks against the KPI dashboard (§8.8.2). Degraded KPIs surface to Alice as structured reports. Arthur prepares the roster recommendation for the next project based on updated adapter performance data. The PM has no active project responsibilities in this state. The system is available for Exploratory Mode sessions without committing to a full project cycle.

Exit: Alice initiates a new project ⇒ return to State 1 (Initialization).

The following use cases illustrate HIIE's intended scope and demonstrate the system's reasoning range from precision instrumentation to large-scale manufacturing. Each represents a full HIIE project cycle from intent to deliverable.

Use Case 1 — Localized Atomic Force Microscope (≤ 3 × 3 ft)

Alice's Intent: "Architect me a localized atomic microscope that is under 3x3 feet and has a remote connection point to view the microscope and control it."

HIIE Approach: Hardware Engineering generates a cantilever-based AFM design with piezoelectric XYZ stage. The constraint V ≤ (0.9 m)³ governs all mechanical envelope decisions. Materials Engineer specifies silicon nitride cantilevers sourced from US suppliers. A Raspberry Pi 5 + custom FPGA control board provides the remote WebRTC connection layer. Civil & Structural Engineer validates vibration isolation table requirements.

where E is Young's modulus, w is cantilever width, t is thickness, and L is cantilever length. Target: k ≈ 0.1–1 N/m for contact mode. Force sensitivity F_min = k · δz_min where δz_min ≈ 0.1 nm for the piezo stage.

Expected Outcomes: Full mechanical CAD (FreeCAD), PCB schematic (KiCad), BOM with US sourcing, remote control software package, provisional patent draft, viability report. Estimated BOM cost: $8,000–$25,000 depending on detector quality.

Use Case 2 — Novel vRAM Architecture

Alice's Intent: "Architect a new design system for vRAM that is material cost effective and easy to access the materials in the United States."

HIIE Approach: Hardware Engineering and Materials Science modules run in parallel. The Patent Strategist performs real-time prior art sweep across HBM, GDDR, and LPDDR patent families. The system targets SRAM-on-DRAM stacking alternatives using domestically available silicon and substrate materials.

HIIE's architecture exploration targets B> 1 TB/s at < 30% of current HBM2e material cost. Bandwidth efficiency η = B/P_watts is optimized against domestic supply chain constraints.

Expected Outcomes: Architecture whitepaper, provisional patent claims, BOM with US supplier pricing, VHDL/Verilog controller specification. Yellow paper for formal protocol specification if a novel memory bus protocol emerges.

Use Case 3 — GPU Batch Manufacturing Asset System

Alice's Intent: "Create a manufacturing asset system that batch produces a specific kind of product — like a GPU."

HIIE Approach: Manufacturing Systems module designs the full factory line: wafer handling, die bonding, substrate attachment, thermal interface application, and burn-in testing stations.

where A is die area (mm²) and D₀ is defect density (defects/cm²). The system optimizes batch size B^∗ to maximize throughput-per-dollar:

Expected Outcomes: Process flow diagram (SVG), equipment specification list, facility layout CAD, yield model, QC system design, environmental report.

Use Case 4 — Environmentally Net-Positive AI Compute Machine

Alice's Intent: "Generate an environmentally net positive AI machine that produces a positive carbon offset."

HIIE Approach: Environmental Systems module leads. The design targets a carbon offset ∆C> 0:

Options explored: waste heat capture for building heating, on-site solar generation, direct air capture integration, and renewable energy certificate procurement. The carbon payback period t^∗ is computed as:

Expected Outcomes: Carbon accounting report, hardware specification, renewable integration plan, net-positive certification pathway.

Use Case 5 — Drone Fleet Factory with Headwear Control Interface

Alice's Intent: "Make a factory line that produces fleets of drones that use headwear for controlling the drones."

HIIE Approach: Manufacturing Systems designs drone assembly line. Software Engineering generates the EEG/EMG headwear signal processing pipeline. The control latency constraint drives the firmware architecture:

(50 ms is the human proprioceptive threshold for natural control feel.) Typical budget: τ_EEG ≈ 10 ms, τ_proc ≈ 15 ms, τ_radio ≈ 5 ms, τ_actuator ≈ 10 ms.

Expected Outcomes: Factory line design, drone PCB schematic, headwear firmware, BOM, patent novelty analysis, viability report.

Use Case 6 — Chemical Compound Analysis Agent for Novel Materials

Alice's Intent: "Find bounties and train a local agent AI model that all it does is analyze chemical compounds for creating new materials."

HIIE Approach:Chemistry & Materials module deploys a fine-tuned specialist model trained on PubChem, ChemRxiv, and materials science literature. The persistent fine-tuning layer (§8.9) continuously improves this specialist model using compound analysis outcomes as training signal, with MLX-LM running post-project LoRA passes and ANE benchmarked as a concurrent path. The agent participates in open science bounty programs (Materials Project, NIST challenge programs). Outputs feed back into HIIE's ChromaDB as a curated materials corpus.

where A_j is the fingerprint bit-set of compound j. Compounds with S_novel> 0.85 trigger provisional patent drafting.

Expected Outcomes: Fine-tuned specialist model, materials database, novel compound candidates, provisional patent drafts, bounty participation record.

Use Case 7 — Localized Hadron Collision Experiment Platform

Alice's Intent: "Make a localized version of the CERN hadron collider."

HIIE Approach:This use case represents HIIE's most ambitious scope. The Theoretical Engineer and Civil & Structural Engineer immediately establish the physically achievable envelope. HIIE is honest about the energy gap:

A tabletop RF quadrupole linac achieves E_cm ∼ 10–100 keV, suitable for educational use and materials analysis. Cyclotron radius scales with momentum:

For a compact design targeting r ≤ 0.5 m, field strength B ≈ 1 T and beam energy ∼ 10 MeV are achievable with superconducting coils.

Ethics Officer reviews radiation safety under NRC 10 CFR Part 30. Feasibility Manager flags the gap between popular conception and buildable reality. HIIE designs what is buildable, not what is aspirationally described.

Expected Outcomes: Feasibility-scoped design (tabletop cyclotron/linac), radiation shielding specification, CAD files, safety protocols, patent landscape analysis.

Ethics is not a terminal filter — it is a continuous layer woven through every stage of reasoning and generation. No technological capability justifies ethical compromise. This is an architecture decision, not a policy position.

Six Core Pillars

• »Harm Prevention — Dual-use detection on all outputs. Weaponizable designs trigger mandatory Alice review.
• »Environmental Responsibility — All designs carry a carbon impact score. Net-negative outputs flagged; greener alternatives actively recommended.
• »Full Transparency — Every recommendation includes a complete reasoning trace. No black-box outputs.
• »Human Primacy — HIIE has no autonomous consequence. Every real-world physical action requires explicit human authorization from Alice.
• »Equitable Design — Outputs must not create systems that systematically disadvantage protected groups or enable inappropriate concentration of power.
• »Immutable Audit Trail — Tamper-evident log of all ethics decisions per project, exportable for third-party review.

Escalation Protocol

Ethics Officer → Arthur (AI Co-Director) → Alice (human principal). Risk scoring R ∈ [0, 100]:

HIIE cannot self-modify its ethics framework — this layer is protected from all instruction overrides.

Three-Tier Data Model

Research Group agents retrieve and analyze live internet sources entirely in the 8GB streaming RAM buffer. Only extracted structured insights are embedded and written to ChromaDB on HDD.

ChromaDB Collection Architecture

ChromaDB performs Approximate Nearest Neighbour (ANN) search natively via HNSW (Hierarchical Navigable Small World graphs). No additional binary search layer is implemented — HNSW handles all ANN retrieval optimally for HIIE's embedding workloads at the operating collection sizes. HIIE partitions ChromaDB into three explicit, non-overlapping collections:

• »Active RAG Collection — hot vector shards for all currently active projects. This collection's index resides on SSD (§3.2), not HDD, for sub-millisecond retrieval during agent reasoning. At project close, the collection is migrated to the archive collection on HDD.
• »Training Partition — labeled output pairs from completed projects, batch-consumed by the fine-tuning process at project close (§8.9). Partitioned separately to prevent live retrieval queries from contaminating the training data distribution.
• »Archive Collection — embeddings from completed projects retained for cross-project retrieval and long-term pattern analysis. Stored on HDD; queried only on explicit demand, never during active inference.

Metadata Indexing. All embeddings across all collections carry four mandatory metadata fields, indexed at write time:

These fields are enforced at write time — any embedding submitted without all four fields populated is rejected by the FastAPI ingestion layer before reaching ChromaDB.

HDD Directory Structure

The 5 TB HDD uses a deterministic directory hierarchy. Every path is structured and machine-readable, enabling automated archival, retrieval, and adapter version management without filesystem scanning.

/projects/{id}_{client}_{date}/
   /outputs/       -- final deliverable package
   /specs/         -- spec sheets and BOMs
   /cad/           -- FreeCAD, KiCad, SVG files
   /patents/       -- patent drafts and prior art records
   /ethics/        -- immutable Ethics Officer reports
   /checkpoints/   -- serialized agent state snapshots
   metadata.json   -- project manifest and Fscore summary
/adapters/{agent_role}/{version}_{date}/
   versioned LoRA adapter files per agent role
   active -> symlink to current deployed version
/chromadb/
   /training_partition/ -- labeled pairs for LoRA fine-tuning (§8.9)
   /project_embeddings/ -- archive collection (completed projects)
   /archive/            -- compressed snapshots for point-in-time restore

Project directory naming follows {id}_{client}_{date} where id is the 8-character project UUID prefix, client is a sanitized client identifier, and date is the project close date in YYYYMMDD format — producing lexicographically sortable, human-readable paths with no filesystem metadata dependency. Adapter versioning follows {version}_{date} under each agent role directory, consistent with the versioning scheme in §8.9.6. An active symlink in each role directory points to the currently deployed adapter. Treasury Agent rollback (§8.9.6) operates by atomically repointing this symlink — no file moves required.

ChromaDB persistence maps each collection to a dedicated subdirectory, matching ChromaDB's native per-collection layout. The /archive/ subdirectory holds periodic compressed snapshots of the project_embeddings collection, enabling point-in-time restoration without full ChromaDB reconstruction.

Data Sources by Domain

Research Agent Credential Store & Source Quality

High-value sources require authenticated access. A credentials store holds authenticated access tokens for IEEE Xplore, PubChem, USPTO, Google Patents, arXiv, and other premium databases. Research agents query this store before attempting retrieval. Paywalled sources without available credentials generate a credential gap flag to the PM's onboarding registry (§7.3) rather than a silent retrieval failure — the distinction matters for Alice's provisioning decisions.

Source quality discrimination is a trained capability, not a hardcoded filter. Each Research agent's LoRA adapter trains on labeled examples of high-quality versus low-quality sources per domain. USPTO patents and NIST data are authoritative for their domains; SEO content aggregators are not. This discrimination lives in adapter weights and improves with each project cycle.

Negative knowledge is an explicit training signal. When a retrieved source contributes to an output that the anti-slop validator flags or that Alice rejects at a gate, that source receives a negative training signal attached to the labeled pair in the ChromaDB training partition. The Research agent gradually learns which corners of the information space are reliable versus unreliable for each domain — without requiring manual curation.

HIIE's outputs are not static documents delivered to Alice for manual processing. The self-hosted toolchain enables AI agents to autonomously generate, render, and iterate on designs within a pre-configured visual environment. Every tool listed below is pre-installed, containerized under Coolify, and accessible via authenticated web interface.

Toolchain Overview

Layering and Cross-Section Visualization

For mechanical designs (use cases 1, 5, 7), HIIE generates layered FreeCAD assemblies where each sub-system is an independent body on a named layer. Alice can:

• »Toggle layer visibility to inspect internal structures (e.g., view PCB traces inside an enclosure)
• »Export cross-section views as SVG for inclusion in patent drawings
• »Run FreeCAD's FEM workbench for finite element stress analysis
• »Animate kinematic assemblies to validate mechanical motion

Self-Hosted Architecture Auditing

• »Custom audit dashboard — FastAPI endpoint queries ChromaDB for all decisions, flags, and validation results on a given project, rendered in Grafana
• »Immutable ethics log viewer — read-only interface for all ethics officer reports, exportable to PDF via Stirling
• »Dependency graph renderer — visualizes agent task dependencies and completion state in real-time
• »BOM diff tool — compares successive BOM versions to flag cost or sourcing regressions between design iterations

Next.js Admin Dashboard

The primary Alice-facing system interface is the Next.js admin dashboard — a purpose-built React application that queries the Grafana HTTP API and renders metrics as purpose-built components. Grafana and Prometheus remain as the metrics collection and storage backend. The Next.js layer is the application Alice actually interacts with.

Variable-Driven Data Architecture

All metrics are stored in allocated fixed slots — defined data contracts between the Grafana HTTP API and the frontend. Adding a new metric requires only defining its slot and writing a component; no dashboard infrastructure rebuild is needed. This makes the frontend extensible without touching the metrics layer.

Dashboard Surfaces

• »Real-time RAM, GPU, and CPU utilization with the 85% throttle threshold visually marked as a reference line
• »Per-agent HCT spend rate and remaining budget
• »Active project count and SSD working budget consumption
• »Agent Fscore trends rolling over the last 10 projects
• »Adapter version history with Fscore delta per version and rollback status
• »System KPI health indicators (§8.8.2) displayed as status chips (green/amber/red) against defined targets
• »Agent kill switches — toggle controls per agent role that write directly to the agent registry (§7.3); Alice-accessible at any time, no confirmation required

Operational Parameter Control

Modifications to operational parameters — base HCT weights, throttle thresholds, adapter version pinning — are made through the dashboard frontend, not through direct infrastructure access. All parameter changes are logged to the immutable audit trail. No infrastructure-level access is required for routine system management.

Stage 1 — Internal Capability (Months 1–6)

HIIE used exclusively by Arthur Labs. Every client project benefits from HIIE-quality output: validated spec sheets, patent strategy, feasibility reports. Arthur Labs competes differently from any other development organization. Self-funding through existing contracts. Registered Agentics hosts the primary Mac Mini node.

Stage 2 — API Product (Months 6–18)

Stage 3 — Licensed Platform (Months 18–36)

HIIE licensed as a deployable platform to large manufacturers, defense contractors (non-weapons applications), and universities. Licensees run on their own infrastructure or via Registered Agentics. Arthur Labs provides model updates, ethics framework maintenance, and support contracts.

IP Strategy

• »Arthur Labs retains full IP on HIIE system architecture, pipeline, ethics framework, and all domain modules
• »Clients own the IP in outputs generated for their projects — no Arthur Labs claim
• »Open-source non-core components to build developer ecosystem; keep inference core and ethics layer proprietary

Provisional Patent Applications

HIIE generates provisional patent application drafts for client review. Provisional applications establish a priority date without requiring full examination. Key fee structure (USPTO, effective 2025):

Note: Fees subject to change. HIIE-generated drafts are reviewed by a licensed patent attorney before filing. HIIE documents human-in-the-loop involvement at every step to satisfy USPTO inventorship requirements.

Global Patent Coverage — Estimated Costs

HIIE's Patent Strategist tracks all deadlines and generates cost projections as part of every project's viability report.

The Hardware Innovation Intelligence Engine represents a genuine category creation in applied AI — not a tool, not an assistant, but a complete innovation organization compressed into an ethically-governed intelligence system. Where existing AI systems excel at fragments of the innovation pipeline, HIIE is designed to own the entire chain from human intent to physical engineered reality. It is what emerges when the reasoning capabilities of frontier language models are combined with the disciplined, domain-grounded methodology of a world-class engineering firm — the closest existing analogy being what one would achieve if CRISPR-GPT and a frontier reasoning model produced a system capable of touching physical space.

The Mac Mini M4 Pro implementation, hosted at Registered Agentics, proves viability at minimum hardware cost, generating commercial revenue before scaling to purpose-built infrastructure. The Persistent Intellectual Capital layer (§8.9) means the machine does not merely execute projects — it compounds from them. Every validated output encodes learning into specialist model weights via MLX-LM fine-tuning during post-project idle cycles, with concurrent ANE fine-tuning under active benchmarking as a future concurrent path.

Ethics and anti-slop validation are not HIIE's constraints — they are HIIE's competitive advantage. As AI systems become more capable, those trusted with consequential engineering decisions will be the ones with demonstrably robust human oversight, embedded governance, and validation architectures that prevent plausible-sounding nonsense from entering the physical world.

The future of machines will not be designed by humans alone, nor by AI alone. It will be designed through the collaboration HIIE is built to enable — human intent directed by values, executed with engineering precision, validated against the physical world, and improved with every project that completes.

Intellectual Property Notice

Arthur Labs, Inc., incorporated in Wyoming, retains all intellectual property rights in the HIIE system architecture, pipeline design, ethics governance framework, anti-slop validation methodology, and all domain modules described in this whitepaper. Outputs generated by HIIE on behalf of a client are the exclusive property of that client under the applicable service agreement. Arthur Labs asserts no ownership over client-directed outputs.

Patent and Filing Disclaimer

HIIE generates provisional patent application drafts and patent strategy analyses as an informational service. These materials are not legal advice and do not constitute the work product of a licensed patent attorney. All patent filings must be reviewed, amended, and submitted by a licensed patent practitioner in the relevant jurisdiction. Alice (the directing human principal) is responsible for ensuring compliance with USPTO inventorship and duty-of-disclosure requirements. Arthur Labs makes no representations regarding patentability, freedom to operate, or enforceability of any HIIE-generated patent draft.

Engineering Liability Disclaimer

HIIE-generated engineering specifications, schematics, bills of materials, process designs, and other technical outputs are provided for informational and prototyping purposes only. The Anti-Slop Validation Framework (§5) is designed to minimize physically infeasible outputs through simulation validation, ground-truth anchoring, and feasibility scoring — but it does not constitute professional engineering certification and does not reduce the obligation for qualified review prior to implementation. They have not been certified, stamped, or reviewed by a licensed professional engineer (PE) unless explicitly contracted. Any implementation of HIIE outputs in a physical product, manufacturing environment, or safety-critical application must be reviewed and approved by qualified licensed engineers before use. Arthur Labs, Inc. accepts no liability for physical, financial, or consequential damages arising from the implementation of HIIE outputs without appropriate professional review.

Registered Agentics Service Terms

Registered Agentics, operated by Marko Ruble, provides physical hardware hosting, registered agent services, and logistics under separate service agreements. Arthur Labs, Inc. and Registered Agentics are independent entities. HIIE's intellectual property and ethical constraints are governed solely by Arthur Labs, Inc. Registered Agentics has no authority to modify, override, or grant exceptions to HIIE's ethics framework or operational constraints.

Data and Privacy

HIIE does not retain raw internet content analyzed during live retrieval sessions — it is processed in RAM and discarded. Structured embeddings stored in ChromaDB are retained as part of the project record under the applicable client service agreement. The fine-tuning training partition stores only labeled output pairs — no raw internet content, no PII. Clients should not submit personally identifiable information (PII) as part of project inputs unless explicitly covered by a data processing agreement with Arthur Labs, Inc.

Version and Architecture Notice

This document (HIIE v1.1.1, April 2026) represents the architectural specification as of its publication date. It is subject to revision as development progresses. The most current version is maintained internally by Arthur Labs, Inc. Ambition grounded in ethics and engineering rigor is how the future gets built.

Governing Law

This whitepaper and any service relationships described herein are governed by the laws of the State of Wyoming, United States of America. Disputes shall be subject to binding arbitration in Laramie County, Wyoming.