A direct answer to a question we get from nearly every prospective partner and investor: what can you show us right now, and why isn't it a code-built application demo. The short version: we have a GPU evaluation tool running that generates Composite Job Designs (CJDs). CJDs are evaluated differently than software made from fixed code, by design, and the live build reflects that.
A benchmark is a contract between a workload and a moment in time: useful, and irrelevant the moment the workload, hardware, or objective changes. A Composite Job Design does not measure a fixed point. It declares the classes of work a system performs. Essence generates Composite Job Designs directly from that declaration, and the execution (instructions, memory access, kernel boundaries, scheduling) is generated against it, not frozen into it.
SPEC CPU, MLPerf, and LINPACK are each useful precisely because they hold everything else fixed so hardware can be compared. That same constraint is what makes a fixed benchmark, or a fixed application demo built from code, a poor description of what a CJD actually does. A CJD's value is in governing execution across changing workloads and hardware, not in performing one scripted task well. Asking to see that as a static demo is asking to see the wrong thing.
This is also why we don't build a one-off demo from code to answer the question quickly. We are not a software company; we are a wantware company. Software is code-driven: fixed code, typically submitted to a compiler. Wantware is intent-driven: machine instructions generated in real time from declared intent. Essence does not create software applications; that's a different category of product, built and evaluated a different way. A code-built demo would be easy to produce and would show you nothing about what Essence actually governs.
The Execution Chain above shows where a CJD is generated. What it doesn't show is what the CJD governs once generated: deterministic artifacts, bounded adaptive refinement, and, when needed, exportable certification. The figure below breaks that out in more detail.
Figure 1b is the relevant one for the code-export question below: "certifiable via offline review and validation" and "exported artifacts only when certification or offline deployment is required" describe the same governed export path that lets Chameleon produce conventional code once that's the preferred output for a given use case.
adaptwithchameleon.com is the current build, and it's the right reference point until the milestones below are complete. It was made from Meaning Coordinates, not from code, and not from natural language. It's the most accurate representation available right now of Essence generating execution directly from declared intent.
| Status | What It Means |
|---|---|
| Available now | adaptwithchameleon.com: Composite Job Designs generated in real time, live today |
| Under active development | Assimilating thousands of workloads in preparation for natural-language Aptiv generation, gated on two milestones (Buffer Feeds and Synergy Expansion), see below |
| Pilot-ready, workload-dependent | Limited today to the GPU evaluation tool. Anything beyond that scope waits for the milestones below; see Adoption Phases |
Aptivs were previously generated from natural language as well as from Meaning Coordinates. That path is currently paused while two milestones are completed, not because the underlying capability doesn't exist, but because this next version needs to cover a materially wider set of products than the earlier version did. Both milestones gate the next demo and generation capability together; neither is sufficient on its own.
Distributes work across all components within a single node, including multi-GPU configurations such as the Nvidia A100 and B100, with no hypervisor dependency at the node level. Separate networking technology extends that distribution across nodes, enabling multi-node deployment without a hypervisor layer between nodes.
→ Node-level: multi-GPU distribution, no hypervisor · Cross-node: networking layer extends distribution across the fabric
Expands Essence's capacity to understand, create, edit, and materialize Aptivs across the full range of what computing can do, assimilating software's historical workarounds as governed, direct capability.
→ Full-spectrum Aptiv creation · GenAI proposals governed by Meaning Coordinates
Once both are complete, natural-language generation returns with broader product coverage and native multi-node distribution, rather than reintroducing it narrowly and re-doing the work later.
This progress isn't limited to Meaning-Coordinate generation. A separate, two-year effort to evolve beyond the Apple ecosystem to Linux is complete. Windows and POSIX-based operating systems (Android, iOS, macOS, ChromeOS, tvOS, watchOS, and others) are comparatively short projects from here. Essence products (Aptivs) run on all of them without modification: CJDs are generated based on the operating environment, not fixed code written in the past.
Once the milestones are complete, and where there's interest, Chameleon can also be configured to generate code in conventional programming languages. This isn't a reversal of the wantware-not-software point above; it's Essence producing a code export as one available output, the same way it can produce other scan-ready artifacts today. There are use cases where a code-based output is the preferred path, and that option will be available once this next version is in place.
Until the milestones are complete, go to adaptwithchameleon.com for the accurate, current representation of what Essence generates from Meaning Coordinates. It is not a placeholder for a future demo; it is the demo, and it's built the same way Essence builds everything else: governed, not coded. For a deeper technical treatment of why CJDs are a different design primitive than a benchmark or an application, see Qcode & Morpheus.
Explore the live build, watch the demo library, or talk to us about pilots and partnerships.