---

---

1. Abstract

Modern accelerated computing systems waste significant computational, energy, and human resources because execution is bound to static artifacts rather than synthesized as an explicit, controllable design. While hardware capability has advanced rapidly, prevailing execution models increasingly struggle to deliver predictable performance, efficient energy usage, and scalable optimization across heterogeneous silicon. Optimization remains dependent on hand-tuned kernels, heuristic decision-making, and extensive human intervention, leaving substantial execution capacity unrealized.

As AI systems are increasingly used to generate goals, plans, and execution directives, the limitations of artifact-centric execution models become more pronounced: without an execution substrate that can govern, verify, and adapt realization itself, AI-driven intent remains difficult to translate into predictable, efficient, and certifiable behavior on real hardware.

This paper introduces Composite Job Designs (CJDs), an execution model in which execution itself—rather than source code or compiled binaries—is treated as a first-class design object. CJDs synthesize bounded execution designs directly from declared intent and constraints, generate hardware-native instruction realizations on demand, and execute them ephemerally by default. Where regulatory, safety, or certification requirements apply, CJDs can also generate fixed, auditable instruction artifacts suitable for offline validation and deployment.

We describe the CJD execution synthesis model, including intent specification, constraint enforcement, execution design formation, and instruction realization, and explain how ephemerality and determinism are supported within a single unified framework. We further compare CJDs to existing approaches such as compilers, agent-based optimizers, mixture-of-experts routing, and orchestration systems.

Finally, we present validated results from single-silicon executions demonstrating substantial reductions in execution waste. This paper describes improvements in performance, energy efficiency, and utilization without manual kernel tuning or middleware-driven control. We conclude by outlining a roadmap for extending CJD-based execution synthesis to multi-silicon environments, indicating that treating execution as a synthesized, verifiable design enables a fundamentally different optimization regime for accelerated computing.

---

2. Introduction: Why Execution Design Must Be Automated

Modern accelerated computing systems are capable of extraordinary performance. In practice, however, realizing that performance remains slow, expensive, and risky. Achieving near-optimal execution for a non-trivial workload typically requires months of effort by highly specialized engineers, repeated experimentation across hardware configurations, and significant upfront investment—often with no guarantee of success.

Composite Job Designs (CJDs) address this problem directly by automating the parts of execution design that are traditionally performed by human experts. Instead of relying on manual kernel tuning, ad-hoc experimentation, or brittle optimization pipelines, CJDs enable systems to synthesize valid execution designs automatically, converge rapidly toward optimal realizations, and do so within explicitly declared intent and constraints.

The core value of CJDs is not incremental performance improvement, but time-to-optimal execution. Where traditional approaches require long optimization cycles and repeated human intervention, CJDs compress this process to minutes or hours by replacing manual execution design with systematic, hardware-native synthesis.

---

2.1 The Cost and Risk of Manual Optimization

Today, the dominant path to high performance on GPUs and other accelerators is manual optimization. Engineers write or rewrite kernels, select launch parameters, restructure memory access patterns, and iteratively test performance across data shapes and hardware generations. Even when assisted by profiling tools or automated tuners, the optimization loop remains fundamentally human-driven.

This approach imposes several structural costs:

• Time: Optimization cycles span weeks to months.
• Expertise: Results depend on scarce, non-transferable knowledge.
• Risk: There is no guarantee that a given tuning effort will succeed.
• Fragility: Optimizations are tightly coupled to assumptions that degrade as workloads, data, or hardware change.

As a result, many production systems operate permanently below their achievable performance, not because better execution is impossible, but because it is impractical to obtain reliably.

---

2.2 Static Execution as the Root Constraint

The reason manual optimization remains necessary is that execution behavior is largely fixed ahead of runtime. In current systems, kernels and execution artifacts are authored, tuned, and compiled into static forms that must generalize across unknown future conditions. Once deployed, these artifacts cannot adapt meaningfully without re-entering the human optimization loop.

This early binding of execution decisions creates a structural limitation:

• Execution structure is fixed before real data, contention, or hardware behavior is observed.
• Optimization opportunities that emerge only at runtime remain inaccessible.
• Each new hardware generation or workload variation requires renewed tuning effort.

Automated tuning systems mitigate some of these issues, but they typically operate offline and still produce static artifacts that must be selected and managed explicitly.

---

2.3 Automating Execution Design

CJDs eliminate this bottleneck by shifting optimization from code and kernels to execution design itself. Rather than treating execution as a side effect of compilation, CJDs treat execution as a first-class design object that can be synthesized, constrained, and realized dynamically.

CJDs are agnostic to how intent is produced, whether by humans, traditional software, or AI systems; they exist to govern, constrain, and realize that intent as executable designs.

In the CJD model:

• The system explores a space of valid execution designs rather than tuning a single kernel.
• Execution decisions are made using observed hardware behavior, not static assumptions.
• Optimization converges automatically toward the best realizations without human intervention.

This enables systems to reach expert-level execution quality without requiring expert-level effort.

---

---

2.4 Performance Without Sacrificing Control

Importantly, CJDs do not require sacrificing determinism, predictability, or trust. Execution is always governed by declared intent, constraints, and policy. Where adaptive refinement is permitted, it occurs within bounded and verifiable limits. Where determinism or certification is required, CJDs produce fixed, auditable instruction artifacts suitable for existing validation workflows.

This avoids the false tradeoff between performance and control that characterizes many adaptive or heuristic approaches.

---

2.5 Implications for Execution Models

The implications of automating execution design extend beyond incremental performance improvement. By shifting optimization from static kernels and artifacts to synthesized execution designs, Composite Job Designs fundamentally change where control, adaptability, and risk reside in the system.

In the CJD model, execution quality no longer depends on the longevity of human-authored assumptions embedded in code or binaries. Instead, execution behavior is derived from declared intent and constraints and realized in forms appropriate to the operational context—whether ephemeral and adaptive or fixed and certifiable.

This reframing exposes a limitation shared by existing execution models: compilers, middleware, and orchestration systems all assume that execution structure must be decided early and encoded into persistent artifacts. The following section examines these historical approaches and explains why they struggle to eliminate execution waste in modern accelerated systems.

---

3. Background: Compilers, Middleware, and Their Limits in Accelerated Computing

Modern GPU and accelerator programming does not primarily rely on classical ahead-of-time or just-in-time compilation in the way general-purpose CPU software does. Instead, performance-critical execution is dominated by explicitly authored kernels, handwritten or semi-generated in languages such as CUDA, HLSL, or similar low-level representations. These kernels are then combined with runtime systems, drivers, and scheduling layers that manage execution at scale.

On GPUs, execution behavior is dominated by hand-authored kernels (e.g., CUDA, HLSL), not classical ahead-of-time or just-in-time compilation. While intermediate representations such as PTX exist, they primarily serve as delivery formats rather than dynamic execution design layers.

While this approach has enabled rapid adoption of accelerators, it also defines the limits of what current systems can achieve.

Programming languages are inherently artifact-centric, producing persistent representations that encode execution decisions ahead of runtime and thereby constrain how performance and optimization can be achieved.

---

3.1 Hand-Tuned Kernels as the De Facto Control Plane

On GPUs, execution behavior is largely controlled through kernel design rather than compilation strategy. Engineers explicitly encode assumptions about:

• Parallel decomposition and synchronization
• Memory access patterns and locality
• Launch geometry and occupancy
• Hardware-specific instructions and intrinsics

Once written, these kernels act as fixed execution templates. Runtimes may choose when and where to run them, but they do not meaningfully alter how they execute.

Key point: this “artifact-as-control-plane” pattern is not unique to GPUs; analogous control constraints appear across heterogeneous compute stacks whenever execution is locked into fixed deliverables rather than synthesized as an explicit design.

As a result, the kernel itself becomes the de facto control plane for performance. Any significant optimization—improving throughput, reducing energy, or adapting to new hardware—requires modifying or replacing the kernel. This is why performance engineering on GPUs remains labor-intensive and hardware-specific.

---

3.2 The Limits of Runtime and Middleware Adaptation

Frameworks and runtimes—such as deep learning frameworks, graph executors, or scheduling layers—operate above kernels. They can:

• Select between pre-existing kernels
• Adjust scheduling, batching, or placement
• Manage data movement and orchestration across devices

However, they do not redesign execution. The fundamental execution structure encoded in kernels remains unchanged.

Even advanced systems that perform auto-tuning or kernel selection operate by searching over variants of fixed artifacts. They explore parameter spaces, reorder operations, or choose among precompiled options, but they do not synthesize new execution designs based on observed hardware behavior.

This creates a hard ceiling on optimization: once the kernel space is exhausted, no further improvement is possible without human intervention.

---

3.3 Search and Heuristic Systems Still Target Artifacts

Automated tuning systems and search-based optimizers have improved performance in many domains, particularly for dense tensor workloads. These systems typically generate large numbers of candidate kernels or schedules and evaluate them empirically.

While effective, they share a common limitation:

• The search space is defined in terms of artifacts (kernels, schedules, graphs), not execution designs.
• The output is still a static artifact that must be stored, selected, and reused.
• Adaptation stops once a “best” artifact is chosen.

In practice, this means optimization is episodic rather than continuous. Each new workload shape, data distribution, or hardware configuration reintroduces the need for search, tuning, and validation.

---

3.4 Why Human Optimization Persists

Because execution semantics are locked into kernels, human engineers remain responsible for resolving tradeoffs that systems cannot express explicitly:

• Compute vs. memory balance
• Latency vs. throughput
• Energy vs. performance
• Determinism vs. flexibility

These decisions are encoded indirectly, through code structure and kernel design, rather than declared directly as constraints. As a result, optimization becomes an interpretive process rather than a controlled one.

This is why performance engineering does not scale linearly with hardware capability. As accelerators grow more powerful and heterogeneous, the gap between theoretical and realized performance widens.

---

3.5 The Missing Layer: Execution Design

What is absent from current GPU stacks is an explicit representation of execution design—a layer where execution structure, parallelism, dataflow, and resource usage can be defined, constrained, and reasoned about independently of any single kernel or instruction sequence.

Without this layer:

• Execution decisions are frozen too early
• Adaptation requires replacing artifacts rather than refining designs
• Optimization remains tied to human effort

Composite Job Designs introduce this missing layer. By treating execution design itself as a synthesized object—separate from kernels, binaries, or graphs—CJDs enable systems to automate what is currently done manually, while remaining grounded in real hardware behavior.

The next section formalizes Composite Job Designs and defines how they represent execution independently of instruction artifacts.

---

4. Composite Job Designs: Execution as a First-Class Design Object

---

4.1 Definition

A Composite Job Design (CJD) is a formal execution construct that defines how a computation is realized on hardware. Unlike source code, kernels, or execution graphs, a CJD does not represent an algorithmic description of work. Instead, it represents a space of valid execution realizations derived from explicit intent, constraints, and policy.

A CJD specifies:

• Execution structure and ordering
• Parallelism and scheduling boundaries
• Dataflow and memory movement
• Hardware placement and resource usage
• Determinism and trust constraints

CJDs are synthesized by the system and are not authored or maintained by humans. They exist as execution designs, not as persistent software artifacts.

---

4.2 Decoupling Intent From Execution

Traditional systems treat execution as a downstream consequence of compilation. Code is written first; execution behavior emerges indirectly after multiple layers of translation, optimization, and abstraction.

CJDs invert this relationship.

In the CJD model:

• Intent precedes execution
• Execution design precedes instruction generation
• Instructions are a realization of a design, not the design itself

This shift allows execution to be reasoned about, constrained, and verified directly, rather than inferred from compiled artifacts.

By elevating execution to a first-class design object, Composite Job Designs decouple intent from any single instruction realization while preserving explicit control over behavior. A single CJD can be realized in multiple execution modes depending on declared constraints and policy, without changing the underlying execution design.

---

4.3 Unified Execution Model

Although CJDs are independent of any specific execution strategy, they are designed to support multiple realization modes within a single conceptual framework. Figure 2 illustrates this unified model: the same CJD is synthesized from intent and constraints and then realized through different execution pathways, while remaining governed by the same design boundaries.

---

4.4 Intent, Constraints, and Policy

CJDs are derived from three explicit inputs:

1. Declared Intent
   The semantic description of the work to be performed (e.g., computation, transformation, or processing goals).
2. Constraints
   Quantitative and qualitative limits, such as performance targets, energy budgets, latency bounds, determinism requirements, or resource ceilings.
3. Policy
   Rules governing what forms of adaptation or optimization are permitted, including certification boundaries, security requirements, and operational modes.

These inputs define the valid execution space from which CJDs are synthesized. Execution designs that violate intent, constraints, or policy are not permitted.

---

4.5 Instruction Realization

From a CJD, the system generates hardware-native instruction realizations (e.g., SPIR-V) that implement a valid execution design on a specific hardware configuration.

Two properties distinguish CJD-based instruction realization from traditional compilation:

• Ephemerality by default: In deployed systems, instructions are generated, executed on real hardware, and deleted. No persistent binary is assumed or retained.
• Observation-driven refinement: Instruction realizations are evaluated using observed hardware behavior rather than static heuristics or cost models.

For explanatory and validation purposes, it is useful to describe this process as progressing from naïve to increasingly refined execution designs. In production systems, however, CJDs directly synthesize optimized instruction realizations without retaining intermediate artifacts.

---

4.6 Operating Modes

CJDs support multiple operating modes within a single execution framework.

---

4.6.1 Adaptive Execution Mode

In adaptive execution mode:

• Execution refinement is permitted
• Adaptation occurs only within declared intent and constraints
• Instruction realizations remain ephemeral
• No persistent artifacts are introduced

This mode enables continuous optimization while preserving predictability and policy compliance.

---

4.6.2 Deterministic / Certifiable Mode

In regulated, safety-critical, or mission-critical contexts:

• CJDs operate offline
• Fixed instruction artifacts are generated
• Artifacts are reviewed, frozen, hashable, and auditable
• Execution behavior is deterministic and repeatable

No adaptive or self-modifying behavior is introduced into certified execution paths. This mode aligns with existing OEM and regulatory workflows (e.g., ISO 26262).

---

4.7 Relationship to Existing Approaches

CJDs differ fundamentally from other optimization techniques:

• Compilers and JITs optimize code into fixed instruction artifacts.
• Middleware and orchestrators adapt scheduling and placement but do not alter execution semantics.
• AI agents and heuristic systems adapt decisions but introduce probabilistic behavior.
• Model-level techniques (e.g., MoE) optimize inference paths, not execution structure.

CJDs instead treat execution design itself as the optimization target, enabling deterministic or adaptive realization as policy permits.

---

4.8 Summary

Composite Job Designs redefine execution as a synthesized, verifiable design derived from intent and constraints. By separating execution design from instruction artifacts, CJDs eliminate reliance on static binaries, middleware layers, and hand-tuning while supporting both adaptive optimization and certifiable determinism.

The next section describes how CJDs are realized in practice and how instruction-level optimization is performed on real hardware.

---

5. Execution Synthesis Model

Declared intent, constraints, and policy define a bounded execution design space from which valid execution designs are synthesized. Instruction realizations are generated directly from the execution design and executed on real hardware. In adaptive mode, instruction realizations are ephemeral and may be refined within declared boundaries; in deterministic mode, fixed instruction artifacts are generated offline for review and certification. Execution design precedes instruction generation in all cases.

Figure 4 provides a structural overview of this process, showing how declared intent, constraints, and policy define a bounded execution space from which valid execution designs are synthesized and realized on hardware.

---

5.1 Inputs: Declared Intent

Intent is the explicit description of what the computation must accomplish—expressed independently of any specific kernel, framework, or instruction sequence. In the CJD model, intent is a first-class input to synthesis and serves as the invariant that all realizations must preserve.

Intent typically includes:

• Task definition: what operation(s) must be performed and what constitutes a correct result
• Input/output meaning: required structure, formats, ranges, and allowable transformations
• Correctness rules: invariants, tolerances, and validation conditions
• Trust requirements: declared boundaries for what may execute and under what verification rules

Unlike traditional approaches where “intent” is implied by code and framework behavior, CJDs treat intent as explicit and verifiable—so that execution can be synthesized without relying on implicit assumptions embedded in a kernel or a stack.

---

5.2 Inputs: Constraints

Constraints define the allowable execution envelope: quantitative targets and qualitative requirements that bound the execution design space. Constraints are not optimization hints; they are enforceable limits that determine which execution designs are valid.

Common constraints include:

• Performance targets: throughput, latency, deadlines
• Energy and power limits: energy-per-task, watt caps, thermal constraints
• Resource ceilings: memory budgets, bandwidth limits, occupancy or concurrency bounds
• Determinism requirements: repeatability expectations, audit constraints, certification boundaries
• Operational constraints: permissible adaptation modes, allowable retries, stability targets

Constraints bound the optimization space and prevent “optimizing by surprise.” If a candidate execution design violates declared constraints, it is invalid—regardless of whether it might be faster in some uncontrolled scenario.

---

5.3 Synthesis: From Intent + Constraints to a CJD

Given intent and constraints, the system synthesizes a Composite Job Design: a formal execution construct that defines a space of valid execution realizations. Figure 4 illustrates this synthesis pipeline and where verification and policy gates occur.

Synthesis is not a single-shot compilation step. It is a controlled process that (a) defines valid execution structures, (b) enforces constraints, and (c) selects realizations that reduce execution waste by improving utilization, minimizing unnecessary data movement, and avoiding brittle artifact dependence—without violating declared intent.

---

5.4 Execution Design Space vs. Instruction Realization Space

The term execution design refers to the structured decisions that determine how work is realized on hardware—independent of any single instruction sequence. In MindAptiv’s hierarchy, execution design spans Levels 1–5, while instruction realization spans Levels 6–8. Figure 4 maps this boundary explicitly.

The eight levels are:

1. Architecture — system topology and execution domain (single machine, multi-GPU, multi-node)
2. Engine — global coordination, conflict resolution, scheduling domains, priority rules
3. Service — lifecycle-managed computation units (start/pause/resume/end) and resource governance
4. Parallel Algorithm — deterministic parallel structure, partitioning/merge semantics, synchronization boundaries
5. Serial Algorithm — local sequential execution, control flow, parameter binding
6. Procedure — state-affecting operations (shared updates, transactional effects, memory updates)
7. Operator — pure computational transforms (register/stack-local; side-effect free)
8. Instruction — hardware-native instruction realization (format depends on operating mode)

CJDs synthesize and constrain execution primarily across Levels 1–5, ensuring that coordination, placement, and structure are explicitly governed. Levels 6–8 then realize the design into the necessary instruction form for the selected operating mode.

---

5.5 Instruction Generation

Instruction generation produces a concrete instruction realization that implements a valid execution design on specific hardware under the declared constraints. This can be expressed as a target-appropriate artifact (e.g., SPIR-V today; other formats as supported) or executed ephemerally depending on operating mode.

Critically, instruction generation is not the “design step.” It is the realization step. The design is defined by the CJD and its bounded execution design space. This separation enables both: (a) rapid convergence toward reduced execution waste, and (b) deterministic, auditable outputs when required.

---

6. Ephemeral vs. Exported Execution Artifacts

CJDs separate execution design from instruction artifacts and treat instructions as realizations that may be ephemeral or exported, depending on policy. This enables a single execution model to support both continuous optimization (where permitted) and conventional deployment workflows (where required).

---

6.1 Ephemeral Execution by Default

In deployed systems, the default mode is ephemeral instruction execution: the system generates an instruction realization, executes it on real hardware, and deletes it. No long-lived binary is assumed or retained as a primary artifact.

Ephemerality matters because it:

• prevents accumulation of brittle, versioned kernel variants
• avoids “library lock-in” to prior assumptions about data shapes and hardware behavior
• enables continuous reduction of execution waste as conditions change (power, contention, device mix)

For explanatory purposes, the process is often described as progressing from naïve to refined realizations. In production, CJDs synthesize optimized realizations directly without preserving intermediate steps.

---

6.2 Exported Instruction Artifacts When Required

In offline or regulated contexts, CJDs can generate fixed, auditable instruction artifacts suitable for existing deployment and validation workflows. A primary example is exporting optimized instructions as SPIR-V for use cases that utilize the Chameleon service for that purpose.

Exported artifacts are produced under explicit policy boundaries, then reviewed, frozen, and integrated using the customer’s standard build, test, and certification processes. Export does not change the CJD model; it selects a different realization policy.

---

6.3 Separation of Synthesis and Deployment

A defining property of the execution synthesis model is the strict separation between:

• Instruction generation — producing a valid realization of an execution design
• Artifact lifecycle — whether realizations are ephemeral or persisted
• Runtime execution — where and how instructions are executed on hardware

Execution synthesis is responsible solely for producing instruction realizations that conform to declared intent, constraints, and policy. It does not determine whether those realizations are retained, exported, or executed persistently.

Decisions about artifact persistence, review, certification, and deployment context are governed entirely by policy and operational environment—not by the synthesis mechanism itself.

As a result, the same Composite Job Design can be realized in multiple deployment modes, including:

• Ephemeral execution, where instruction realizations are generated, executed on target hardware, evaluated, and discarded within authorized adaptive environments
• Exported execution artifacts, where fixed instruction realizations are generated offline, reviewed, frozen, and integrated into conventional deployment and certification workflows

In all cases, the underlying Composite Job Design remains unchanged. Only the realization policy and artifact handling differ, ensuring that execution design, optimization, and deployment concerns remain cleanly separated.

---

6.4 Why This Distinction Eliminates Waste

Traditional systems accumulate waste by persisting instruction artifacts that encode obsolete assumptions about hardware topology, memory behavior, drivers, and data characteristics. As conditions change, these artifacts continue to execute inefficiently, consuming excess memory bandwidth, over-allocating resources, and wasting energy.

This artifact persistence also forces repeated human optimization cycles to refresh or replace binaries—each cycle reintroducing delay, cost, and risk.

Composite Job Designs reduce this waste by defaulting to ephemeral instruction realizations that are synthesized against current execution conditions. Memory usage, data movement, and scheduling decisions are derived from the execution design during instruction realization, rather than inherited from stale artifacts.

Persistent instruction artifacts are exported only when policy explicitly demands a fixed, reviewable deployment object. In those cases, execution design governs memory and energy behavior at realization time, ensuring that exported artifacts embody an optimized, constraint-compliant execution realization rather than a conservative, worst-case template.

---

7. Determinism, Certification, and Safety

Important clarification on deployment, certification, and determinism

Chameleon supports deterministic, auditable execution as a first-class operating mode, making it suitable for regulated, safety-critical, and mission-critical systems where fixed behavior is required (for example, ISO 26262 ASIL safety paths).

In these contexts, Chameleon operates offline and produces static, deterministic instruction artifacts (such as SPIR-V) that are reviewed, frozen, hashable, and validated using the OEM’s existing build, test, and certification workflows. No adaptive or self-modifying behavior is introduced into certified production paths.

Where variability or optimization is explicitly permitted, Chameleon can operate in bounded adaptive modes. In all cases, adaptation occurs only within declared intent, execution designs, and policy constraints—ensuring predictable behavior and resistance to unauthorized modification.

---

7.1 Deterministic / Certifiable Mode

Deterministic mode exists to satisfy environments where predictable behavior is required: safety paths, mission-critical flows, and regulated deployments. In this mode, CJDs are realized into fixed instruction artifacts that are repeatable and auditable.

---

7.2 Bounded Adaptation Where Permitted

Where adaptation is allowed, CJDs permit refinement only within the pre-declared execution design space and constraint envelope. This is not open-ended variability: it is controlled optimization governed by policy.

---

7.3 Trust and Audit Boundaries

CJDs enforce that nothing executes unless intent is declared and constraints/policy gates are satisfied. In deterministic deployments, the artifact itself becomes a reviewable object (hashable, testable, traceable) within existing customer workflows.

---

8. Comparison to Existing Approaches

---

8.1 How Compilers Optimize Instructions

Traditional compilers optimize instruction sequences using static analysis, heuristics, and cost models—making optimization decisions under incomplete knowledge of real runtime conditions.

Key characteristics:

• Execution behavior is bound early into binaries or cached kernels
• Optimization targets code structure, not execution design
• Runtime behavior is largely fixed once artifacts are produced
• Adaptation requires recompilation or retuning

In contrast, CJDs do not treat instruction artifacts as the primary control plane. CJDs define a space of valid execution realizations derived from intent and constraints, from which instruction realizations are synthesized as needed. Execution behavior is governed by the design, not by static compiler output.

---

8.2 Agent-Based and Heuristic Optimization Systems

Agent-based systems and heuristic optimizers seek to improve execution outcomes by dynamically selecting parameters, kernels, or scheduling decisions based on observed behavior. These systems often employ probabilistic decision-making, learned policies, or runtime heuristics to guide execution choices.

Common characteristics include:

• Adaptation expressed as decision-making rather than execution design
• Run-to-run behavioral variability under identical inputs
• Limited guarantees of determinism or repeatability
• Challenges in auditability, certification, and safety validation

Composite Job Designs differ fundamentally in that adaptation, when permitted, occurs only within a bounded execution design space derived from declared intent, constraints, and policy. Execution realizations are synthesized deterministically from that design space; probabilistic behavior is not introduced into the execution path. Deterministic execution remains available as a first-class operating mode.

CJDs are not intended to replace generative or agentic AI systems. Instead, they operate at a different layer of the stack.

Agentic and generative systems may be used to interpret goals, generate intent, propose constraints, or explore solution spaces at semantic or planning levels. CJDs take those declared intents and constraints—regardless of whether they originate from a human or an AI system—as inputs, and are responsible for synthesizing deterministic, verifiable execution designs that realize those decisions on hardware.

In this sense, CJDs complement agentic AI by providing a trustworthy execution substrate beneath it. Agentic or generative systems may decide what should be done—interpreting goals, generating intent, or proposing constraints— but CJDs govern how execution is realized on hardware.

In this role, Composite Job Designs can be understood as chaperoning execution: intent may originate from humans, traditional software, or AI systems, but CJDs ensure that any resulting execution is realized deterministically, within declared intent, constraints, and policy—without introducing probabilistic behavior into the execution path.

---

8.3 Mixture-of-Experts (MoE) and Model-Level Routing

MoE approaches optimize model execution by routing inputs through different expert sub-networks. This improves model efficiency, but it primarily changes model routing, not the underlying execution design of the hardware realization.

CJDs operate below the model layer. They focus on synthesizing execution designs and instruction realizations that reduce execution waste for the workload, independent of model topology.

---

8.4 Orchestration Systems

Orchestration systems manage deployment, scaling, placement, and service availability across infrastructure. They optimize how artifacts are scheduled and where they run, but they do not synthesize new execution designs or instruction realizations.

CJDs complement orchestration by reducing the waste inside each executed workload—while also enabling multi-device execution designs that can be expressed explicitly rather than inferred indirectly.

---

9. Validated Results (Single-Silicon)

The results below should be interpreted as measured outcomes within a defined validation scope, not as guarantees that every workload, execution design, or silicon target will achieve the same multiplier. Reported ranges reflect the gap between the least- and most-efficient execution realizations observed under identical intent and constraint declarations.

---

9.1 Validation Scope

The current validation focuses on single-node, single-silicon execution within the Chameleon optimization service context. Evaluations were conducted on standard hyperscaler accelerator instances under representative workload conditions.

The workloads selected for this validation are representative of execution-bound accelerated computing tasks—where performance, energy efficiency, and utilization are primarily governed by execution design (e.g., scheduling, data movement, and memory behavior) rather than by algorithmic or model-level restructuring.

Outcomes were independently validated within the evaluation scope and are reported as execution-level measurements rather than model- or framework-specific benchmarks.

---

9.2 Observed Execution and Energy Outcomes

Across the evaluated workloads and implementations, measured results show substantial reductions in execution waste expressed as:

• Execution efficiency gains on the order of ~20×–55× between the least- and most-efficient realizations observed
• Energy reduction on the order of ~90%–97% in measured cases (energy per completed result)
• Utilization improvements reflected in higher sustained throughput per device under the same operational envelope

These outcomes are consistent with the CJD model: reducing wasted work, minimizing unnecessary data movement, and converging toward efficient instruction realizations under declared intent and constraints—without manual kernel hand tuning or middleware-driven control.

---

9.3 Interpreting the Range Safely

The reported improvement range does not represent a comparison against a single, intentionally poor baseline. Instead, it reflects the observed spread across a set of reasonable execution choices and realizations evaluated within the same validation scope.

The primary takeaway is not a specific multiplier, but the size of the execution design space and the system’s ability to converge rapidly toward superior realizations once execution design is treated as a first-class object.

---

9.4 Why These Results Translate to CAPEX Avoidance

When the same workload targets can be met with materially fewer devices—or when the same fleet can deliver materially higher throughput—the practical implication is CAPEX avoidance and/or deferral.

This is the basis for ROI modeling: reducing execution waste translates into fewer accelerators required to meet throughput targets, lower energy and cooling demand, and a reduced operational burden from tuning, variant management, and hardware-specific optimization cycles.

---

9.5 Reproducibility and Validation

All measurements reported in this section were performed on real hardware using observed execution behavior rather than simulated environments or heuristic cost models. Results reflect execution-level measurements taken under controlled conditions within the stated validation scope.

Independent validation efforts are ongoing and are focused on reproducibility, measurement transparency, and workload diversity. As validation scope expands, additional results will be reported using consistent measurement methodologies.

At this stage, results should be interpreted as evidence of the achievable variance within valid execution designs—rather than as guarantees of specific performance or energy multipliers for all workloads or environments.

---

9.6 Implications

The key implication of these results is not a particular speedup figure, but the elimination of the traditional optimization bottleneck. By synthesizing execution designs directly from declared intent and constraints, Chameleon automates what is typically a prolonged, risky, and human-driven process.

In this sense, Composite Job Designs do not promise a single optimal outcome. They enable rapid discovery and realization of more efficient executions within a bounded, well-defined, and verifiable execution design space.

---

10. Multi-Silicon Execution Roadmap

The current validated scope focuses on single-node, single-silicon execution. Extending Composite Job Designs to multi-silicon execution—spanning multiple heterogeneous processing substrates such as GPUs, CPUs, and specialized accelerators— expands the execution design space substantially. This expansion introduces new opportunities to eliminate execution waste across scheduling, synchronization, communication, and data movement.

---

10.1 What Changes in the Execution Design Space

Moving from single-silicon to multi-silicon execution introduces additional degrees of freedom at the execution-design boundary:

• Partitioning: how work is decomposed and distributed across devices and execution contexts
• Placement: where computation and data reside, are staged, and are reused
• Synchronization: coordination boundaries, barriers, and determinism constraints
• Communication: peer-to-peer transfers, topology-aware data movement, and overlap strategies
• Scheduling: cross-device timing, contention management, and priority enforcement

These decisions remain part of execution design (Levels 1–5), not instruction realization. CJDs operate explicitly at these levels, enabling synthesis of multi-silicon execution designs rather than relying on emergent behavior from layered runtimes or middleware.

---

10.2 Single-Node vs. Multi-Node Execution

Multi-silicon execution may occur within a single machine or across multiple machines. CJDs treat this distinction as an architectural and engine-level design choice rather than an after-the-fact orchestration concern:

• Single-node, multi-silicon: topology-aware execution design within a single host boundary
• Multi-node, multi-silicon: execution design spanning network boundaries and distributed coordination domains

---

10.3 Expected Implications

Extending CJDs to multi-silicon execution is expected to produce materially stronger outcomes because optimization shifts from kernel-level efficiency to system-level elimination of execution waste. This includes improved scheduling, reduced idle time, more effective overlap of computation and communication, and higher utilization under contention and constraint.

This is particularly relevant in environments where throughput targets are currently met by scaling device count rather than by reducing waste within the execution itself.

---

11. Limitations and Assumptions

---

11.1 Scope of Claims

• Results discussed in this paper reflect measured outcomes within a defined validation scope. They should not be interpreted as guarantees for every workload, execution design, or deployment environment.
• CJDs define an execution model rather than a fixed performance technique; realized benefits depend on workload characteristics, declared constraints, hardware composition, and operating mode.
• Current validated results focus on single-node, single-silicon execution. Multi-silicon execution is discussed as an execution-design extension rather than a validated performance claim.

---

11.2 Workload Dependence

Workloads vary widely in compute intensity, memory behavior, control-flow structure, and data movement requirements. Some workloads are primarily bandwidth-bound, others are compute-bound, and many exhibit mixed or phase-dependent behavior.

As execution design must respect these characteristics, no fixed performance multiplier can be credibly guaranteed across all workloads, execution designs, or silicon combinations.

---

11.3 Determinism vs. Adaptation Policy

CJDs support deterministic execution as a first-class operating mode. Where bounded adaptive operation is permitted, refinement occurs only within declared intent, constraints, and policy.

The degree of adaptation allowed—ranging from fully static execution to bounded refinement—is an explicit operational decision and may be restricted or disabled entirely in regulated, safety-critical, or mission-critical environments.

---

11.4 Export Formats and Platform Coverage

Exported instruction artifacts are produced in target-appropriate forms (for example, SPIR-V for supported accelerator paths). Availability of additional export formats depends on platform support, execution context, and integration considerations for each silicon class.

The execution model itself is not tied to a specific instruction format; exported artifacts represent one realization mode selected under policy.

---

11.5 Measurement and Reproducibility

Reported results depend on measurement methodology, system state, driver and runtime configuration, and workload setup. Independent validation and reproducible benchmarking are essential for external comparison and are treated as a core requirement for expanding validation scope—particularly for multi-silicon execution.

---

11.6 Roadmap Dependencies

The multi-silicon execution roadmap described in Section 10 is forward-looking and depends on successful extension of execution synthesis across heterogeneous devices. Timelines, scope, and outcomes may be influenced by hardware availability, integration complexity, and validation and certification requirements.

---

12. Conclusion and Future Work

Composite Job Designs (CJDs) introduce an execution model in which execution is treated as a synthesized, verifiable design derived from declared intent and constraints. By separating execution design from instruction artifacts, CJDs reduce reliance on static binaries, layered middleware, and manual kernel hand-tuning—while supporting both deterministic, certifiable execution and bounded adaptive refinement where permitted.

The core value of CJDs is time-to-optimal execution. By automating execution design, CJDs compress months of performance engineering into a controlled synthesis process that can converge in minutes or hours, depending on workload characteristics and validation requirements.

Eliminating execution waste translates directly into higher utilization, improved energy efficiency, and reclaimed capacity. At scale, these effects often manifest as CAPEX avoidance or deferral rather than incremental per-workload speedups.

---

12.1 Future Work

• Multi-silicon CJDs: extend execution synthesis across heterogeneous devices (GPUs, CPUs, and specialized accelerators), encompassing cross-device scheduling, synchronization, and data movement
• Broader validation: expand measured results across additional workload families, silicon targets, and reproducible benchmark suites
• Operational tooling: refine policy authoring, audit artifacts, and deterministic export workflows for regulated deployments
• Format expansion: support additional instruction realization formats and integration pathways as execution contexts require

---

References

1. A. V. Aho, M. S. Lam, R. Sethi, and J. D. Ullman, Compilers: Principles, Techniques, and Tools, 2nd ed., Pearson, 2006.
2. C. Lattner and V. Adve, “LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation,” Proceedings of the International Symposium on Code Generation and Optimization (CGO), 2004.
   https://llvm.org/pubs/2004-09-30-Lattner-Adve-LLVM.pdf
3. T. Chen et al., “TVM: An Automated End-to-End Optimizing Compiler for Deep Learning,” 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2018.
4. L. Zheng et al., “Ansor: Generating High-Performance Tensor Programs for Deep Learning,” OSDI, 2020.
5. M. Abadi et al., “TensorFlow: A System for Large-Scale Machine Learning,” OSDI, 2016.
6. A. Burns et al., “A Survey of Deterministic Execution in Safety-Critical Systems,” ACM Computing Surveys, 2019.
7. N. Jouppi et al., “In-Datacenter Performance Analysis of a Tensor Processing Unit,” International Symposium on Computer Architecture (ISCA), 2017.
8. J. Ross, “The Groq LPU: A Deterministic Processor Architecture for Low-Latency AI,” Groq white paper / public architecture talks, 2020–2023.
9. Groq, “Groq and Nvidia Enter Non-Exclusive Inference Technology Licensing Agreement to Accelerate AI Inference at Global Scale,” Press release, Dec 24, 2025.
10. N. Shazeer et al., “Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer,” ICLR, 2017.
11. B. Burns, B. Grant, D. Oppenheimer, E. Brewer, and J. Wilkes, “Borg, Omega, and Kubernetes,” Communications of the ACM, 2016.
12. ISO, ISO 26262: Road Vehicles – Functional Safety, International Organization for Standardization, 2018.
13. NVIDIA Corporation, CUDA C++ Programming Guide, NVIDIA Developer Documentation.
14. AMD Corporation, ROCm Documentation, Advanced Micro Devices.
15. Intel Corporation, Intel oneAPI Programming Guide, Intel Developer Documentation.