Roadmap

The four phases at a glance

Phase 1: observability defaults (current)

Phase 1 is the foundation every later phase builds on. The single flag -XX:EliyaProfile=Production activates a curated set of observability defaults that survive incidents, crashes, and audits:

• JFR one flag away: diagnostic options unlocked so a recording starts in one step (continuous 24-hour recording by default arrives in Phase 2)
• Heap dump on OOM with structured filesystem path
• Native Memory Tracking summary mode
• GC logging with rotation (Phase 2)
• Crash log path configuration
• Container awareness reinforced
• Diagnostic VM options unlocked
• Three-level diagnostic path layout (${ELIYA_DIAGNOSTIC_PATH}/${service}/${replica}/${category}/) for per-replica audit attribution
• asymm CLI Phase 1 surface (info, version, help)

Full Phase 1 capability surface: flags reference and asymm CLI.

Phase 2: bundled tooling + FIPS variant

Phase 2 expands the JDK distribution with diagnostic tools and procurement-relevant variants. Target H2 2026, once Phase 2 ships.

Bundled diagnostic tooling

No other major OpenJDK distribution bundles Eclipse MAT or async-profiler in the JDK itself. Engineers today install them separately. Eliya bundles both alongside the runtime, sidestepping the "diagnostic tool installation" friction in air-gapped or policy-restricted environments:

• Eclipse MAT (headless): EPL-2.0. Offline heap analysis with the new asymm eliya analyze-heap wrappers (--duplicates, --histogram, --oql 'SELECT...').
• async-profiler: Apache-2.0. Hardware-counter and wall-clock profiling via asymm eliya profile (--hw-counters, --wall, --ttsp, --alloc).
• asymm eliya jfr {start, stop, dump, scrub}: ad-hoc JFR convenience wrappers around jcmd.
• Optional installers (asymm eliya install-mat-gui, install-jitwatch, install-jol) for less-bundled tooling that stays out of the default install.

FIPS-validated variant

Separate artifact (eliya-jdk-fips) with the Bouncy Castle FIPS provider (CMVP cert #4943) preinstalled and registered, with java.security configured for FIPS-mode operation. Addresses procurement requirements for FedRAMP, FISMA, and other federal-aligned frameworks. FIPS variants carry additional CPU lag versus non-FIPS because of CMVP recertification; target one CPU cycle behind standard Eliya.

Platform expansion

• macOS aarch64: native binary for Apple Silicon, demand-gated on developer-machine sign-ups.
• DEB / RPM packages: Q4 2026 target. Includes eliya-diagnostics system group and automatic update-alternatives registration.
• Distroless variant (:25-lts-distroless): minimal container image with no shell and no package manager, for compliance-conscious environments where attack surface is a primary concern. Demand-gated.
• UBI variant (:25-lts-ubi): built on Red Hat Universal Base Image for OpenShift and RHEL environments. Demand-gated.

Sign up to signal demand for any Phase 2 deliverable.

Phase 3: Asymm Forensics

Target 2027. Asymm Forensics is a cross-correlation diagnostic platform: it analyses JFR + heap dumps + thread dumps + GC logs + crash logs together, rather than as separate analyses.

• Local execution. No SaaS dependency. Diagnostic data never leaves your perimeter. Critical for BFSI settlement systems, healthcare integrations, government workloads, sovereign cloud.
• Cross-artifact correlation. Answers questions APM cannot: "which heap allocation pattern preceded this GC pause spike?", "which threads were blocked when this JFR sample fired?", "what was the last NMT diff before this crash?"
• asymm forensics CLI: analyze, ingest, report subcommands.
• Compliance reports: framework-aligned audit reports (PCI DSS, HIPAA, SOX initially; FedRAMP, GDPR, ISO 27001, SOC 2, and combined-profile reports follow Phase 4 demand).

Phase 3 platform expansion. Independent of Asymm Forensics itself, Phase 3 also brings two platform deliverables:

• Windows x64 binaries: demand-gated platform expansion, separate from Asymm Forensics. Ships in Phase 3 because it depends on the same resourcing milestone, not because the two are coupled.
• FreeBSD GA graduation: the Research Preview promotes to a supported GA build, also demand-gated.

For the architectural distinction between APM and JVM forensics, see JVM forensics vs APM. Phase 3 details: Asymm Forensics.

Phase 4: compliance-aligned profiles

Demand-gated. Each profile ships when sustained enterprise demand emerges, typically 5+ prospects with concrete framework requirements and usable use-case descriptions. The threshold isn't a guarantee; it's a meaningful prioritisation signal that helps Asymm Systems sequence Phase 4 delivery against the highest-demand frameworks first. Phase 4 expands the EliyaProfile enum with framework-aligned values:

• EliyaProfile=PCIDSS: PCI DSS Section 10-aligned
• EliyaProfile=HIPAA: HIPAA Technical Safeguards-aligned
• EliyaProfile=SOX: SOX IT general controls-aligned
• EliyaProfile=FedRAMP: FedRAMP-aligned
• EliyaProfile=GDPR: GDPR data-handling-aligned
• EliyaProfile=ISO27001: ISO 27001-aligned
• EliyaProfile=SOC2: SOC 2-aligned

Combined profiles. For industries needing the union of multiple frameworks, Phase 4 ships explicit combined values rather than allowing operators to stack profile flags:

• EliyaProfile=Healthcare-Payment: PCI DSS + HIPAA
• EliyaProfile=Financial-SaaS: SOC 2 + ISO 27001
• EliyaProfile=Federal-Defense: FedRAMP + CMMC

Profiles are mutually exclusive by design; only one value is active at runtime. Combined profiles are designed by Asymm Systems with documented capability unions, never stacked from single-framework values. The auditor sees one profile name on the JVM command line; compliance attribution is unambiguous.

Framework versioning. Each profile aligns with the current version of its framework (PCI DSS v4.0, HIPAA Technical Safeguards current rule, etc.). When a framework revises, the corresponding profile is updated in the next available CPU. Operators pinning to a specific Eliya version pin to a specific framework-version interpretation; rolling updates track framework revisions.

Activating a compliance profile aligns JVM defaults with framework requirements. It does not certify the application or organisation as compliant; compliance is a holistic posture across application code, infrastructure, processes, and controls.

Sign up with your specific framework requirement to signal demand. Profile shipping order tracks demand mix.

Adoption planning across phases

Two questions matter for multi-year planning:

"What can I count on today?"

Phase 1 is committed: EliyaProfile=Production + the diagnostic path layout + asymm CLI Phase 1 surface. Linux x64, Linux aarch64, Docker multi-arch ship today. The quarterly CPU cadence is documented on the lifecycle page with concrete dates through Q3 2027.

"What's my adoption path if my requirements are Phase 2+?"

Adopt Phase 1 today. The migration path you adopt today (Eliya runtime + EliyaProfile=Production) remains the foundation across all phases. Phase 2/3/4 capabilities are additive; no migration is required when they ship. The runtime is the same; the additions arrive as new bundled tools, new variants, new CLI subcommands, and new profile values within the existing EliyaProfile namespace.

If your requirements are specifically Phase 2+ (FIPS variant, bundled MAT, compliance profiles), sign up on the relevant waitlist and adopt Phase 1 as the foundation now. Your signup is the demand signal that determines shipping order.

Demand-gating mechanics

Several Phase 2 / 3 / 4 deliverables are demand-gated: they ship when customer demand signals are concrete enough to justify the engineering investment. The mechanics:

• Phase 2 platform variants (macOS aarch64, distroless, UBI): ship when sustained signups indicate operational demand. Single waitlist on the downloads page.
• Phase 2 FIPS variant: ships when 5+ procurement-restricted prospects sign up with FIPS as a requirement.
• Phase 4 compliance profiles: each profile ships when 5+ enterprise prospects have signed up with that specific framework requirement and provided usable use-case descriptions. PCI DSS, HIPAA, SOX are the highest-demand profiles based on early waitlist signals; FedRAMP, ISO 27001, SOC 2, GDPR follow based on the demand mix.
• Phase 4 combined profiles: ship when the underlying single-framework profiles have both shipped and combined-use customer demand emerges.

Demand signals matter; speculative engineering ahead of signals doesn't. Sign up on the relevant waitlist with a concrete use-case description; that's the input the roadmap responds to.

Phases are loosely sequenced, not strictly sequential. Phase 4 compliance profiles could ship before Phase 3 Asymm Forensics if enterprise demand for a specific framework emerges faster than Phase 3 engineering requires. The "phase" designation reflects strategic funding milestones and engineering complexity, not strict temporal ordering.

Beyond Phase 4. Phase 4 completes the current strategic horizon. Beyond Phase 4, Asymm Systems may extend the platform with additional capabilities (compliance-aligned Dial integrations, multi-JVM cross-correlation for distributed systems, sector-specific profile bundles) as the customer base and demand patterns evolve. Phase 5+ is unbounded today; it's driven by what customers tell us they need.