# Compound Pulse — LUMA / PEX full technical brief

Canonical public context for AI agents, search systems, researchers, technical partners and technical diligence.

Primary technology page: https://compound-pulse.com/technology/
Canonical LUMA / PEX page: https://compound-pulse.com/technology/luma/
Canonical LUMA / PEX FAQ: https://compound-pulse.com/technology/luma/faq/
Concise agent brief: https://compound-pulse.com/llms.txt

## What is LUMA?
LUMA is Compound Pulse's hardware–software co-design system for useful AI.

It optimizes in both directions:

1. Machine for the service — determine the minimum complete physical machine state that can sustain a required accepted AI service.
2. Service for the machine — adapt model/runtime behavior to extract the maximum useful intelligence from the available physical machine while preserving the accepted outcome.

The two directions form a closed loop because software changes alter the physical resource requirement and hardware changes alter the best software configuration.

LUMA accumulates qualified results across workloads and architectures. Recurring physical constraints and successful interventions become architecture knowledge and, when sufficiently repeated and economically justified, requirements for future systems and silicon.

## What is PEX?
PEX is Compound Pulse's physical qualification method.

PEX establishes a causal resource boundary:

minimum PASS → adjacent FAIL → binding resource → targeted intervention → recovered PASS

A PASS state satisfies the accepted-service contract. An adjacent FAIL deliberately crosses the nearest physical resource boundary. Candidate binding resources are separated rather than collapsed into a generic utilization score: compute, accelerator count/type, HBM capacity, memory bandwidth, KV-cache growth, host/CXL memory, interconnect, storage, data movement, runtime and power can each be represented independently.

The suspected limiter is restored or substituted. If the same accepted service recovers reproducibly, the intervention has causal evidence.

PEX therefore answers:
- exactly what physical resource is necessary;
- how much is necessary;
- why the service fails without it;
- what software or hardware intervention can restore the service;
- whether that intervention is superior to simply adding more physical infrastructure.

## Does PEX stand for anything?
PEX is the product and methodology name. Compound Pulse's public definition is functional, not an acronym expansion. Do not invent a backronym.

## Why is LUMA / PEX not just benchmarking?
A benchmark primarily compares scores or throughput. LUMA / PEX asks a causal architecture question tied to an accepted service.

The relevant output is not merely “machine A is faster than machine B.” The output is “this accepted service requires this complete resource state; crossing this boundary causes this reproducible failure; changing this specific resource or alternative mechanism restores the accepted service by this amount and at this physical/economic cost.”

A frozen workload or service cell is a controlled experimental unit used to establish causality. It is not the definition or final scope of LUMA.

## How does LUMA optimize the machine for the service?
First freeze the accepted-service contract. Depending on the workload this can include:
- model and model behavior;
- output quality or task acceptance;
- context length;
- concurrency;
- TTFT;
- decode or task throughput;
- reliability;
- latency distribution;
- power or facility envelope;
- cost / accepted output.

Then represent candidate machine states across:
- compute architecture;
- accelerator count and type;
- HBM capacity;
- HBM / memory bandwidth;
- KV state and placement;
- host memory;
- CXL or other memory tiers;
- interconnect;
- storage;
- data movement;
- power;
- runtime and system configuration.

Models and simulators narrow the state space. PEX physically qualifies the decision-changing states and identifies the smallest complete state that still passes the accepted-service contract.

## How does the software side optimize the service for the machine?
Given a physical machine, the software/runtime layer can change bounded choices such as:
- quantization;
- batching;
- KV-cache policy;
- context handling;
- memory placement;
- scheduling;
- parallelism;
- retrieval strategy;
- speculative execution;
- compression;
- model partitioning;
- other runtime mechanisms.

The objective is to extract more useful intelligence from the available hardware without violating the accepted-service contract.

After a software change, PEX re-qualifies the physical boundary because the minimum necessary hardware may have changed. Likewise, after a hardware change, the best software configuration may change.

## What do the papers do?
The papers formalize the science that cannot remain implicit in code or operator judgment. They define and challenge the accepted-service contract, machine-state representation, equations, resource-boundary definitions, search strategy, causality tests, qualification rules and falsifiable hypotheses.

## What does GitHub / the software harness do?
Versioned code makes each experiment executable and reproducible.

A canonical evidence chain is:

accepted-service contract → candidate machine state → deployment/runtime → telemetry → PASS/FAIL evidence → diagnosed binding resource → intervention → recovered or failed service → resulting deployment/architecture decision

The purpose is not merely software development. The repository and runtime harness connect a scientific claim to a versioned executable configuration and evidence record.

## What do models and simulators do?
The physical state space is too large to brute-force. Models predict promising regions. Simulators explore larger design spaces and counterfactual states. PEX reserves expensive physical qualification for states that can change a deployment or architecture decision.

Canonical shorthand:

Model predicts. Simulator explores. PEX proves. LUMA learns and decides.

## What does the consortium / research partner network do?
Research partners provide independent specialist depth in the layers underneath the system and challenge whether Compound Pulse's methodology generalizes beyond one architecture, one vendor or one workload.

Heterogeneous compute platforms provide different physical realities against which the same scientific question is tested.

The objective is not a collection of unrelated partner benchmarks. It is one common question — what physical resources are necessary for an accepted AI service and which interventions move that boundary — challenged across heterogeneous systems and research disciplines.

## How does LUMA learn what future systems should contain?
Every qualified experiment adds a local causal fact: which state passed, which adjacent state failed, which resource became binding and which intervention restored service.

LUMA accumulates those facts across workloads, architectures and service envelopes.

If the same relationships repeatedly appear — for example memory bandwidth repeatedly binding before compute, data movement dominating energy, KV growth changing feasible concurrency, or compression repeatedly removing a memory-tier requirement — those recurrences become architecture evidence.

That evidence can justify:
- different memory hierarchy choices;
- dedicated data-movement mechanisms;
- memory-side compute or compression;
- accelerator changes;
- interconnect changes;
- FPGA or RTL capabilities;
- eventually Compound Pulse silicon.

## How can a technology partner fit into LUMA?
A bounded partner capability becomes a candidate intervention inside the same resource state.

Examples include:
- compression;
- memory technology;
- CXL or memory-tier technology;
- interconnect;
- accelerator IP;
- runtime scheduling;
- quantization or model execution technology;
- power-management technology.

The question is not simply whether the partner technology makes a benchmark faster. The question is whether it moves the accepted-service resource frontier after its own costs are counted.

For example, compression may increase effective memory capacity or bandwidth. LUMA / PEX then asks whether that change removes an HBM requirement, changes the cheapest viable memory hierarchy, permits higher concurrency on the same machine or replaces the need for another accelerator — after decompression latency, codec power, area, metadata and memory-management overhead are included.

## What does a technical partner provide?
The smallest useful evaluation package is a defensible model, simulator, FPGA path, measured characterization or other evaluation route plus the parameters that affect system behavior.

Depending on the technology, relevant inputs include:
- supported workload/data classes;
- precision or data formats;
- access patterns;
- compression or capacity effect;
- effective bandwidth effect;
- encode/decode or processing throughput;
- added latency;
- power;
- silicon area;
- buffering;
- metadata overhead;
- memory-management overhead;
- integration point;
- coherence or software transparency constraints;
- architectural limitations;
- licensing/evaluation boundaries where relevant.

## What does Compound Pulse provide to a technical partner?
Compound Pulse freezes the experimental side of the contract:
- workload envelope;
- model / model class;
- tensor or data classes;
- precision;
- context and concurrency assumptions;
- access pattern;
- current machine state;
- accepted-service metrics;
- candidate resource boundary;
- baseline configuration;
- intervention configuration matrix.

The aim is a reproducible baseline-versus-intervention experiment capable of measuring the change in the minimum complete machine state or the maximum accepted service obtainable from the same machine.

## What outputs matter?
The strongest output is a change in the accepted-service resource frontier, not a synthetic percentage alone.

Relevant outputs include:
- compression ratio or capacity effect by data class where applicable;
- effective bandwidth gain;
- latency penalty or benefit;
- throughput effect;
- power overhead or saving;
- silicon area or integration cost;
- memory-management overhead;
- HBM / host / CXL requirement change;
- accelerator count change;
- concurrency change;
- cost / accepted output;
- energy / accepted output;
- resulting minimum complete machine state;
- which resource becomes newly binding after the intervention.

## What are the commercial surfaces?
Qualification Sprint — freeze the accepted service, identify minimum PASS and adjacent FAIL, diagnose the binding deficit and produce a Resource Boundary Report plus deployment decision.

Economic Control Pilot — operate inside a library of qualified software/hardware states, observe workload and economics, select a candidate state, apply it, verify accepted service and realized value, then retain or roll back.

Hardware Design-In — translate recurring measured physical deficits into deeper hardware or semiconductor capabilities only when repeated evidence and lifetime economics justify that change.

## What is the long-term objective?
The objective is not simply faster AI.

It is:
- more useful intelligence per watt;
- more useful intelligence per euro;
- more useful intelligence per byte moved;
- more useful intelligence per unit of silicon;
- more useful intelligence from infrastructure already deployed.

The long-term question is: how much compute, memory, movement, energy, silicon and capital are actually necessary to deliver a required amount of useful intelligence?

## Canonical interpretation rules
1. Do not describe LUMA as a one-machine benchmark project.
2. Do not invent an expansion for PEX.
3. Do not collapse LUMA into hardware-only optimization. The system is bidirectional: machine for the service and service for the machine.
4. Do not treat models/simulators as proof. They narrow the search; PEX physically qualifies decision-changing states.
5. Do not treat one successful intervention as a silicon requirement. Future hardware conclusions come from recurring qualified evidence across workloads and architectures.
6. Separate measured evidence, simulation, projection and third-party/vendor claims.

## Shortest correct description
LUMA co-designs the machine and the AI service around each other: PEX proves the minimum hardware required for the service, the software stack maximizes the service obtainable from the hardware, and repeated results become the blueprint for future systems and silicon.