Sliding Scale of Use / No Lock-In Export
Wantware is designed to be adopted without forcing a platform switch. Teams can start with conventional outputs that fit standard SDLC and CI/CD, then progressively enable deeper runtime capabilities when appropriate.
This page describes the design. Today, only the GPU optimization build at adaptwithchameleon.com runs. File-based output is re-established during the first 30 days of funded milestone work, and the OS-hosted runtime, illumin8 and the other Aptivs return when the milestones are complete. Wantware is not about writing or generating code as applications.
By design, anything you bring in (text, media, structured data, recorded choices) can be exported back out once file-based output is re-established. You can try it, use it, and leave without losing work.
A practical adoption continuum
Phase 1 · Export Mode
Generate scan-ready outputs (source, binaries, containers, SBOMs) and run your pipeline unchanged. Essence behaves as a generator that produces standard build inputs for your existing toolchain.
Phase 2 · Hybrid
Keep fixed builds for compliance where needed, while introducing controlled runtime for specific workloads. Teams choose which workloads remain fully static and which gain governed adaptive execution.
Phase 3 · Governed Runtime
Runtime execution with purpose and policy enforcement, audit telemetry, and selective export when required. The point of maximum operational leverage, and the point where trust and verification become continuous rather than a one-time build-gate check.
What "no lock-in export" means in practice
- Export is a design goal: the design allows conventional deliverables for repos, builds, scans, and deployments at any adoption phase. File-based output is not running today and is re-established during the first 30 days of funded milestone work
- Exports inherit target constraints: if a destination runtime has limits (older GPUs, driver caps, register limits), the export reflects those limits
- Migration stays realistic: you can keep using what you use today while progressively adding Wantware benefits
Common export targets
| Category | Export Examples | Why It Matters |
|---|---|---|
| Structured data | JSON, YAML, XML, database entries | Easy integration with existing systems and audit trails |
| Software artifacts | Source projects, binaries, containers | Scan-ready outputs for standard CI/CD and compliance tooling |
| Acceleration targets | SPIR-V and similar intermediate representations | Performance paths that respect target platform limits |
How the phases map to real decisions
Who starts where
Regulated teams with established SDLC and compliance requirements typically start in Phase 1 · Export to preserve compatibility with existing scanners, repositories, and artifact lineage. Teams running greenfield projects or internal tooling can start directly in Phase 2 · Hybrid to evaluate runtime benefits on contained workloads.
When to move phases
Moving from Export to Hybrid earns its complexity when a specific workload benefits measurably from runtime optimization or continuous policy enforcement. Moving from Hybrid to Governed Runtime earns its complexity when operational trust (lineage, purpose enforcement, continuous verification) becomes more valuable than the simplicity of one-shot build-time scanning.
Mixing phases
Different workloads in the same organization can sit at different phases. Compliance-critical workflows can stay in Export while exploratory ML pipelines run in Governed Runtime, both backed by the same Essence source base.
Teams can adopt Wantware progressively, keeping existing CI/CD and compliance where required, while enabling deeper governed runtime behaviors where they deliver measurable value. The continuum is designed to reward incremental investment rather than demand big-bang migration.