An Architecture Between Two Worlds

Quantum computing is often explained by looking at the processor. We consider how many qubits it has, what fidelities it reaches, or what algorithm it runs. But a QPU does not work alone. Before each execution, a classical layer represents the problem, builds circuits, selects parameters, and decides what to send. After measurement, another layer interprets the response, preserves context, and decides what to do next.

That intermediate space is where Human Blooming positions QPE/ECHELEN. The company has not built a QPU, nor has it modified IBM’s cryogenics, firmware, or physical calibrations. What it has subjected to experimentation is an orchestration layer. This layer prepares work on classical hardware, directs workloads to remote quantum processors, retrieves results, and reintegrates them into a classical verification and memory cycle.

The campaign reconstructed in 2026 brings together 308 unique Job IDs across three physical IBM QPUs: ibm_marrakesh, ibm_boston, and ibm_kingston. The corpus documents 203 executions on Marrakesh, 97 on Boston, and 8 on Kingston. It shows maxima of 576 PUBs on Boston and 168 on Marrakesh. The footprints reach up to 155 visible physical qubits on Boston and 150 on Marrakesh. The campaign accumulated 5,061 PUBs and approximately 2,041 seconds of QPU usage. More significant than any of these maxima in isolation is the complete sequence they form.

represent → reduce → select → parameterize → commit → execute → measure → transfer → verify → remember → decide again

The Story Begins in Classical Silicon

The starting point was the development of the mathematical orchestration and operator. This was created in the search for greater computing and calculation capacity. We identified accessible routes to optimize computing power while minimizing energy consumption on our systems. This is where NVIDIA enters the story.

An essential part of the work was carried out on an NVIDIA RTX 5090. This does not turn the GPU into a quantum device, nor is that the claim. Human Blooming is not doing that. Its role is different: to perform heavy classical computation, organize candidates, prepare parameters, maintain state, validate results, and sustain the control logic surrounding the QPU.

Editorial figure. NVIDIA GeForce RTX 5090 as the classical endpoint of the QPE/ECHELEN cycle. The RTX 5090 used in the campaign performs classical work; it is not presented as quantum hardware.

In a specific benchmark subjected to independent expert assessment, the reference procedure recorded approximately 0.15329 seconds and 6,523,678 numbers per second. With the QPE operator active, approximately 0.00768 seconds and 130,282,975 numbers per second were documented. This shows a ratio close to 19.97× in that specific test. At the same time, the evaluated space fell from 999,999 candidates to 228,574, a reduction of 77.14%.

The important reading is not to turn that test into a universal acceleration promise. The result belongs to a specific benchmark. The expert assessment itself relates the improvement to candidate filtering and CUDA parallelization. What matters for the hybrid bridge is that, before a workload reaches IBM, the classical layer may already have materially transformed the amount and organization of the work.

Speed does not always mean doing the same thing faster. It can also mean deciding which work deserves to reach the next resource.

From the RTX to IBM Quantum

The GPU–QPU bridge is not a special physical connection between a graphics card and a cryostat. It is a bridge of information and control. In one direction, the classical layer represents, reduces, selects, parameterizes, and constructs the intervention. In the other, the QPU returns measurements that are transferred to the classical domain for comparison with targets, manifests, or acceptance rules.

Editorial figure. IBM Heron represents the remote QPU endpoint of the bridge. IBM provides the physical execution infrastructure; QPE/ECHELEN provides the preparation, orchestration, return, and validation layer described in this article.

This design turns physically separate machines into components of the same logical machine. The RTX can remain in a conventional environment while the QPU operates remotely on IBM infrastructure. What joins both endpoints is not physical proximity, but continuity of computational intent, workload identity, and result provenance.

CLASSICAL LAYER	QPE/ECHELEN BRIDGE	QUANTUM LAYER
RTX 5090Representation · reduction · search · memory · validation	Selection · parameters · target · precommit · submission · return · decision	IBM HeronPhysical execution · measurement · bitstrings/counts

First: Learning How to Address the Chip

The early Marrakesh phases include small executions and microprobes. There are jobs with 18 PUBs and 512 shots, others with 22 PUBs and 1,024 shots, and a single-PUB microprobe with 512 shots. The objective was not to impress through scale, but to establish a functional baseline. We aimed to verify that the pipeline could enter a physical QPU, execute, and recover results.

Physical selection was not limited to occupying qubits q[0]…q[n]. The corpus contains dispersed packages: for example, q[91], q[92], q[98], q[109], q[110], q[111], q[118], and q[129]. Other executions use different regions of the graph. This documents physical navigation in an operational sense. The software can direct the load toward specific positions on the device, although it does not modify the chip’s internal physics.

Boston: From 24 to 155 Visible Physical Positions

Figure 1. Documented progression of visible physical footprints during the Boston phase.

On the ibm_Boston chip, a particularly clear expansion can be observed: 24, 26, 42, 57, 58, 90, 122, 150, and finally 155 visible physical qubits. Job ID d8jfoj42upec739ng600 reaches q[0]–q[154], with 155 visible positions, 32 PUBs, 512 default shots, eight seconds of QPU usage, and zero seconds pending.

The campaign should not be described as though it had enumerated every state of a 155-qubit system. The formal dimension of its Hilbert space is 2^155, approximately 4.57×10^46. However, using 155 positions does not mean traversing that space or demonstrating global entanglement. That is not the claim, and other campaigns addressing that question remain undisclosed. What is documented here is the ability to construct and execute a parameterized trajectory over a nearly full physical footprint.

Figure 2. Human Blooming visual on Boston. The 576-PUB figure corresponds to a workload separate from the maximum 155-qubit footprint.

Program Phase; Then Program Interaction

The exported circuits show a control language based on gates such as RZ, X, and SX. RZ changes relative phase; X changes computational population; SX implements a half rotation around X. At later stages, RZZ appears, introducing a parameterized interaction between pairs of qubits.

The ibm_Boston workload d9uakfou5hac73agvsm0 combines 150 visible physical qubits, 12 PUBs, 4,096 shots, and 15 seconds of QPU usage. The documentary export contains 453 visible RZ labels and 34 RZZ labels. These figures should be treated as documentary counts of labels visible in the PDF returned by IBM, not as an IBM-certified ISA gate count. Even with that caution, they show a clear evolution. The campaign moves beyond local rotations and documents an explicit layer of two-body interaction.

Figure 3. Visual material provided by Human Blooming: 453 RZ labels and 34 RZZ labels visible in the documented Boston workload.

Another Scale: 576 PUBs

Figure 4. Examples of orchestration-volume scaling. Physical width and PUBs are different dimensions.

Circuit width and workload volume are not the same thing. A workload can be narrow and group hundreds of units; another can occupy almost the entire chip with few PUBs. The campaign scales both axes independently.

Job ID d8h2o1pe8nrc73bgmg60 documents 312 PUBs and approximately 85 seconds of QPU usage. Job ID d9u3nhj43mgs73esf21g reaches 576 PUBs, 18 seconds of QPU usage, and one second pending. Marrakesh V88 reaches 168 PUBs. This demonstrates batching and orchestration capacity, not simply physical occupancy of the processor.

The Queue is Not the Algorithm

IBM records make it possible to separate total wall-clock time from effective QPU usage. In the Marrakesh V88 family, 48-PUB loads with 17 seconds of QPU usage remain pending for very different periods. These include approximately 70 minutes 59 seconds and 92 minutes 30 seconds.

The distinction is methodologically important. Human Blooming controls preparation and submission of the load, but not IBM’s shared scheduler. A rigorous evaluation must avoid attributing to the algorithm latency that belongs to external infrastructure.

Runtime Controls: DD and Twirling

The campaign preserves deliberate configuration changes. An early Marrakesh microprobe records measurement twirling enabled. By contrast, certain large Boston workloads explicitly document DYNAMICAL DECOUPLING (DD) = OFF, GATE TWIRLING = OFF, and MEASUREMENT TWIRLING = OFF. This detail is methodologically relevant because it identifies large-scale executions in which those specific Runtime aids were not enabled.

The wording must remain precise. OFF does not mean that the complete IBM stack lacked every transformation, optimization, or internal processing step. It means that these three specific techniques are recorded as disabled in those workload records. This distinction helps avoid attributing their results to DD or twirling when those features are explicitly shown as off for those executions.

DD OFF · GATE TWIRLING OFF · MEASUREMENT TWIRLING OFF

This does not mean that every conceivable optimization in the IBM stack was absent. It means something more precise: those specific options are explicitly shown as OFF in those jobs. The distinction matters because it allows the system to be studied under different regimes without automatically attributing all results to the same mitigation layer.

Kingston: Measuring Against a Prior Target

Ibm_Kingston plays a different role. Rather than maximizing width, the campaign uses compact circuits and high statistics to study parameter sweeps and validations. Three long executions record 4007/4096, 4026/4096, and 3972/4096.

The figure 4026/4096 is approximately 98.291%. But that percentage only acquires the meaning of success against a target if the objective was fixed before the output was received. That is why the Human Blooming protocol incorporates precommit: target, timestamp, and validation rules are preserved before the result is observed. The comparison therefore stops being a retrospective selection of the most frequent bitstring and becomes a falsifiable test against a prior reference.

Figure 5. Visual material provided by Human Blooming. Kingston: 4,026 of 4,096 measurements. Its interpretation as target success depends on the documented prior commitment.

Blind Transfer: Closing the Door on Hindsight

The QPU→GPU transfer is not presented as a mysterious physical property. Its value is methodological. Before the QPU run, a reference is fixed and sealed. IBM generates a Job ID and executes. Bitstrings or counts are then recovered. The classical layer compares the return with the target or manifest and archives the result, version, hash, and provenance.

The closing documentation reports QPU_GPU_BLIND_TRANSFER_PASS=True. In aggregate, the C3 validator brings together approximately 160,000 measurements and 1,181 errors, around 99.26% under the criterion defined by the campaign itself. It is a campaign metric linked to physical jobs on IBM and evaluated by the Human Blooming protocol.

Figure 6. Visual material provided by Human Blooming. C3: aggregate campaign metric linked to precommitted targets and physical IBM jobs.

Memory: Continuity Between Executions

The memory documented by Human Blooming is not a physical quantum memory that preserves coherence between jobs. It is memory in the orchestration system. It preserves targets, parameters, selections, results, hashes, versions, and decisions so that one execution can inform the next. In its still-unpublished internal campaign, the team reports particle-level memory. As a preview of a future publication, they state that they have already transmitted information to a preselected qubit. They observed that it receives it, erased it, sent the same question back to the qubit without its operator, and obtained a matching response. They interpret this as evidence that memory had been fixed. They state that this is a separate scientific campaign that will be published shortly.

The 13/13 record here also represents something important: thirteen correct recoveries or validations of the persistence protocol. Its significance is architectural. A remote QPU may be ephemeral from the application’s point of view, but the surrounding layer can preserve continuity. The sequence stops being a collection of isolated jobs and becomes execution n → learned state → execution n+1.

Figure 7. Visual material provided by Human Blooming. Persistent workflow memory: 13/13 validations of the documented protocol.

Three QPUs: Operational Portability

The Marrakesh → Boston → Kingston → Marrakesh sequence matters because it introduces variation in hardware and calibration windows. It does not demonstrate universal portability, but it does prevent QPE/ECHELEN from being reduced to a single Job ID or a single machine. Portability across different chips works within this campaign, and Human Blooming can replicate it.

Boston is used especially for physical expansion, batching, and parameter-rich circuits. Kingston is used for sweeps and statistical validation with precommit. Marrakesh appears first as a microprobe testbed and later returns with V88, including 150-qubit footprints and loads of up to 168 PUBs. The alternation makes it possible to study which part of the behavior belongs to the pipeline and which part may depend on a specific QPU.

What Have They Actually Done with IBM Qubits?

The qubits have not been physically modified. A layer has been built that decides what to ask of them, where, with which parameters, at what scale, and how to verify what they return.

The campaign documents selection of physical packages, footprint expansion, phase parameterization, RZZ interactions, shot variation, PUB scaling, Runtime-option changes, backend alternation, prior targets, return to the classical layer, validation, and operational memory.

That combination is the practical definition of the bridge. The QPU provides a physical computing regime that the GPU does not reproduce simply by being fast. The GPU provides computation, search, state, analysis, and control that the QPU is not intended to provide on its own. QPE/ECHELEN seeks to turn both domains into complementary components of the same architecture.

Where Does This Place Human Blooming?

The useful comparison with the sector is not to claim that Human Blooming has the corporate scale, hardware, ecosystem, or resources of IBM or NVIDIA. Nor would it make sense to equate an experimental campaign with QPU manufacturers, software platforms, or companies specializing in error correction. Even though the team says it has been directly involved in laboratory work in the sector for seven years, it is only now becoming public.

The relevant comparison is technological. The problem addressed by QPE/ECHELEN—coordinating classical and quantum computing, deciding which part of the work belongs to each resource, and maintaining continuity between them—belongs to the same broad territory the industry calls hybrid computing and quantum-centric supercomputing. And this has been done with the resources of a small organization and conventional hardware.

Human Blooming’s defensible distinction lies in the specific combination demonstrated in its corpus. This includes prior classical reduction, physical selection, variable granularity, parameterization, interaction, independent scaling of footprint and batching, backend changes, precommit, blind transfer, operational memory, and provenance linked through Job IDs, timestamps, and hashes. It is not a single function. It is the complete cycle.

What the Campaign Does Not Claim to Demonstrate

The available evidence does not demonstrate quantum advantage over the best-known classical algorithm for a specific industrial problem. That was not the aim of this campaign, and the team has not yet published its maximum results. Nor does it demonstrate that QPE accelerates every program by 19.97×. The team states that it has already demonstrated 566× on an RTX 5090 in another study, together with significant developments in NVIDIA CUDA-Q that it plans to publish shortly. Additionally, it does not claim that using 155 physical positions is equivalent to global entanglement of 155 qubits. This is the subject of another ongoing campaign. The 99.26% C3 result is not a universal physical fidelity. The team states that each of these questions can be demonstrated independently, but they are not the objective of this article or campaign, whose purpose is to demonstrate the GPU–QPU bridge.

The 13/13 memory result is orchestration memory, not coherent quantum memory, as noted in its corresponding section. The 453 RZ and 34 RZZ counts are visible counts in an IBM documentary export. Operating across three QPUs demonstrates operational portability within the campaign, not universal portability across any quantum architecture. This is an area the team is open to exploring through agreements with quantum companies.

These cautions do not weaken the result. They define exactly what layer each piece of evidence demonstrates and prevent a verifiable campaign from becoming a collection of claims that cannot be audited.

The Important Result is Not 155

It is tempting to summarize the work through its largest numbers: 155 visible qubits, 576 PUBs, 4,096 shots, 19.97×, or 99.26%. But none of them, on its own, describes the technological object.

The central result is the joint appearance of a repeatable sequence: reduce → select → parameterize → commit → execute → measure → transfer → verify → remember → decide. When those functions appear linked, QPE/ECHELEN stops looking like an isolated algorithm. It begins to look like a heterogeneous computational control layer.

In this architecture, the computer no longer has to be inside a single box. It can be distributed between a local GPU and a remote QPU. It can exist between conventional silicon and cryogenic hardware, between deterministic computation and quantum measurement. What turns those resources into a logical machine is the ability to preserve meaning, identity, state, and causality across their boundaries.

A Note on the 156-Qubit V11 Visual

Among the images supplied for this document is a later visual identifying “156 QUBITS,” “9/9 BLIND MESSAGES RECOVERED,” and “480/480 CIRCUITS.” This is visually associated with IBM Marrakesh V11 and “logical recovery under noise.”

This piece is included here as graphic material provided by Human Blooming. However, it is not merged evidentially with the magnitudes of the 308-Job-ID campaign described in this article. It is a preview of the team’s next dossier, which will include Job IDs, manifests, hashes, definition of the correction protocol, and corresponding primary evidence.

Figure 8. V11 visual provided by Human Blooming. It is kept separate from the evidentiary body of the main campaign until accompanied by its specific technical dossier.

The Campaign in Numbers

MAGNITUDE	READING
308	Unique Job IDs in the main corpus
3	IBM QPUs: Marrakesh, Boston, and Kingston
203 / 97 / 8	Jobs per backend
155	Visible physical qubits at the Boston maximum
150	Visible qubits also reached on Marrakesh
53	Jobs with ≥100 visible qubits
46	Jobs with ≥150 visible qubits
576	PUBs at the Boston volume maximum
168	PUBs on Marrakesh V88
5,061	Accumulated PUBs in the corpus reconstruction
≈2,041 s	Accumulated QPU usage derived from Annex A
4,096	Shots in long Kingston validations
453 RZ + 34 RZZ	Visible labels in the analyzed gate-rich workload

Sources and Editorial Criteria

Product visual references: NVIDIA GeForce RTX 5090 and IBM Quantum System Two/Heron. This Word version uses editorial illustrations identified as such, so conceptual material is not confused with official photography or primary campaign evidence.

This article was built from Human Blooming ECHELEN/QPE’s 2026 Comprehensive Master Technical-Scientific Report and the associated technical-journalistic draft. It explicitly separates four layers: primary IBM evidence, RTX/QPE telemetry and artifacts, Human Blooming protocol documentation, and independent RTX 5090 expert assessment. The editorial rule applied here is to preserve that separation.

For external publication, the article should be accompanied by the public Evidence Pack of 25 workloads available on its website. The company is open to providing, under the contractual structure it considers appropriate, the Job ID table, SHA-256 hashes, precommit and blind-transfer manifests, and the classical expert evidence. IBM should be presented as the provider of the infrastructure and corresponding execution records. The QPE/ECHELEN methodologies, interpretations, and conclusions belong to Human Blooming. The conceptual-style images included in this document were provided by Human Blooming and contain their own printed hashes. They should be treated as editorial/illustrative material except where the cited figure is also supported by primary campaign documentation.