The architecture behind intelligent AI execution.

This page is for engineers and technical evaluators. It describes how H33-HIVE routes, reuses, schedules and recovers AI work, how it composes with H33’s authority components, and exactly which parts are research, which are integration-tested, and which are not yet built.

Status Research prototype. Every figure on this page comes from simulated providers or offline measurements on one machine, and the authorization interface is a placeholder. Nothing here is a production guarantee.

Execution pipeline

The proposed order of operations for one unit of work:

Steps 6 and 7 are deliberately separate. An independently verified result is not the same as an independently authorized action: a verifier can establish that an answer is correct within its limits, and only the authority layer can establish that acting on it is permitted.

Rust routing architecture

The current router is a Rust research library. Its executor enforces a small set of rules whatever the routing policy asks for:

Routing quality has been measured offline against recorded model outputs, not on live serving traffic. Those measurements are what showed that smaller model tiers did not reduce cost per correct answer on the task families tested — so the router’s job is to prove a cheaper path is good enough, not to assume it.

Cachee integration

HIVE consumes Cachee; it does not build a cache of its own. Cachee remains the sole computational-reuse layer, and the research router talks to it through an adapter that models Cachee’s governed reuse decision. A reusable result is bound to:

• an input commitment — a hash of the exact input;
• the tenant, with isolation enforced on lookup;
• the model generation that produced it;
• the policy version in force;
• the verifier identity and version that accepted it;
• freshness, an authority epoch and revocation state.

Lookup fails closed, and every refusal has a named reason and its own test: integrity failure, input, tenant, authority, generation, verifier or policy mismatch, stale or revoked authority, revoked verifier, unverified or failed verification, staleness, and a producer that cannot be independently verified. A tampered read is refused, never served. A hit can never turn unverified content into verified evidence, and a reused result never inherits the authority of the session that produced it — it passes the same authorization check as a fresh call.

Reuse is not free. Admission requires independent verification, and at low repeat rates that verification costs more than reuse saves. The integrity check in the research build is a test stand-in, not cryptography; the canonical check plugs in behind the same interface.

CPU/GPU scheduling

The hardware-adaptive scheduler is planned. Its intended design:

• execution classes for CPU work (routing, admission, preprocessing, verification, suitable inference) and GPU work (large-model inference, parallel computation, training);
• batching and queueing per class, with cold-start cost counted explicitly;
• cost-based placement, where a placement must beat its baseline on measured latency percentiles, throughput, cost and energy — not on expectation.

None of this scheduler behaviour has been benchmarked end to end. Until it is, it is described here as design intent only.

Authority integration

HIVE is designed to sit inside the boundary that Agent-008 enforces. Its intended interfaces, and their honest status today:

In the research build, every attempt — fresh call, escalation, failover, idempotent re-send and reuse hit — passes through one authorization hook, and tests confirm a denial stops the task with no bypass. But the only implementation of that hook allows everything. It is a test seam, not a security control, and this page will not describe it as one. Three levels are kept distinct as integration proceeds: interfaces that compile, interfaces tested with synthetic authority, and enforcement independently verified in production.

Fault handling

Failures are handled per provider and per execution scope, so one tenant’s failures do not change another tenant’s routing:

• Circuit breakers. A windowed breaker opens when at least half of the last ten seconds’ results fail, once twenty results have been seen. While half-open it admits at most three probes and closes only after three succeed.
• Bounded retries. Every retry passes the budget gate and the idempotency rule above.
• Ambiguous outcomes. Ambiguity is preserved as Unknown. In an exhaustive 256-case fault sweep of the research build there were zero duplicate executions, zero duplicate charges and zero unsafe re-sends.
• Failover. A definite failure fails over to another healthy provider; an ambiguous one does not, until it is resolved.

The trade-offs are real, and they are published rather than hidden. Because the windowed breaker needs a window of traffic to see an outage, it keeps sending to a dead provider longer than a simple failure-count breaker, and at low traffic it may never trip at all. Recovery is slower, because each scope closes on its own; a two-second burst can leave a scope recovering for well over ten seconds; and when outages flap faster than the cooldown, it rarely recovers within an up-window. These are simulation results with synthetic, instant failures, not measurements of production reliability.

Performance methodology

A HIVE performance claim is publishable only with its full context:

• baseline hardware and the model revision under test;
• concurrency level and the workload’s task mix;
• latency at p50, p95 and p99, and throughput;
• correctness, measured by an independent verifier;
• the repeat-rate assumption behind any reuse figure;
• energy and cost, against a stated no-HIVE baseline.

Independently reproducible benchmarks will be linked here once they qualify. Until then this page publishes no blanket latency, throughput, savings or security guarantee.

Limitations and readiness

A passing component test does not imply a production-qualified composition. When a row changes, it changes here first, with the evidence that moved it.

Back to H33-HIVE. Developer material: H33-HIVE documentation. Related: Agent-008 · Cachee · H33-API-G · H33-74.