The Code Review and Audit milestone established the factual baseline for the entire Phase 3 update programme. Before any changes could be scoped, prioritised, or assigned, the full HeroEngine Legacy codebase required a systematic examination to determine its current state with precision. This milestone produced the authoritative technical record that defines the work in every subsequent milestone — what exists, what is broken, what is outdated, and what the dependency relationships are across all major systems. It is complete, and its outputs are the direct inputs to Milestones 11 through 16.

Inventory and Document All Active and Deprecated Codebases

The first task of the audit was establishing a complete and accurate inventory of everything that exists within the HeroEngine Legacy codebase. This meant identifying all active systems, all deprecated or abandoned code paths, all legacy components still in use by downstream systems, and all external dependencies that had not been reviewed or updated in the intervening years since original development. The inventory was conducted systematically across all subsystems — engine core, database layer, account management, graphics pipeline, art pipeline, and build system — and the results were documented in sufficient detail to allow any team member to locate, understand, and assess any component without requiring institutional memory. This document became the master reference for all subsequent Phase 3 scoping decisions.

Identify and Log Critical Issues, Technical Debt, and Incompatibilities

With the inventory established, the audit moved into active analysis — examining each component against current standards, dependency requirements, and known compatibility constraints to identify and categorise every significant issue. Critical issues affecting platform stability or security were flagged immediately and elevated to the top of the remediation priority order. Technical debt — code that functions but is architecturally unsound, undocumented, or incompatible with the modernisation goals of the relaunch — was logged with sufficient context to allow informed decisions about whether to refactor, replace, or isolate each affected component. Incompatibilities between the legacy codebase and current SQL, AMS, graphics, and build system requirements were mapped in full, providing the technical justification for the scope of each downstream milestone.

Establish Coding Standards and Documentation Requirements for Updates

A modernisation effort conducted without consistent standards produces a codebase that is more heterogeneous after the work than before it. This component of the audit established the coding standards, documentation requirements, and review processes that all Phase 3 update work must adhere to, ensuring that the output of Milestones 11 through 16 is internally consistent and maintainable long term. Standards cover naming conventions, code structure, inline documentation requirements, change logging, and the minimum documentation threshold for any component before it can be marked complete. These standards are not aspirational — they are enforced gates in the review process for every milestone that follows.

Map Dependencies Across SQL, AMS, Graphics, and Build Systems

One of the most consequential outputs of the audit was a complete dependency map across all four major update areas. HeroEngine Legacy was developed over many years, and the interdependencies between the database layer, account management system, graphics pipeline, and build system are not always explicit or well-documented in the original codebase. The dependency mapping exercise traced these relationships systematically, identifying which components in each system rely on the state or output of components in other systems, and therefore which update sequences must be observed to avoid cascading failures during the Phase 3 work. This map is the operational guide for the order in which Milestones 11 through 15 are executed and validated.

Prioritise Remediation Tasks and Assign to Downstream Milestones

The final output of the Code Review and Audit milestone was a fully prioritised remediation task list, with every identified issue assigned to the appropriate downstream milestone based on system area, dependency order, and severity. Prioritisation was conducted against three criteria: risk to platform stability if left unaddressed, effort required to resolve relative to the impact delivered, and sequencing constraints imposed by the dependency map. The result is a structured, sequenced work programme that allows Milestones 11 through 16 to proceed with a clear and agreed scope rather than discovering additional issues mid-execution. The audit is complete. The work it defined is now underway.

The AMS Updates milestone reviews and modernises the HeroEngine Legacy Account Management System to align with current platform architecture, security requirements, and the integration demands of the broader Apex Engine ecosystem. The AMS is the identity and access layer for every HEL user interaction — authentication, session management, permission enforcement, and team access all route through it. Bringing it to current standard is a prerequisite for the Pre-Release Finalisation milestone and for ensuring that existing HEL client accounts transition cleanly into the unified Apex Hub identity model without data loss or access disruption.

Audit Existing AMS Structure and Document Current State

The first step of the AMS update process is a complete structural audit of the existing system, conducted in parallel with the broader code review completed in Milestone 10. Every component of the AMS is examined — authentication handlers, session management logic, permission models, role definitions, API surface, and database schema dependencies — and the current state of each is documented in full. The audit identifies which components are sound and require only minor updates, which require significant refactoring, and which are sufficiently outdated or architecturally incompatible that replacement is the correct decision. This documented current state becomes the baseline against which all subsequent AMS update work is scoped and validated.

Identify Integration Gaps Between HEL AMS and Apex Engine Account Systems

HeroEngine Legacy and Apex Engine are distinct platforms with separately developed account systems, and the path to a unified user identity layer runs through a clear understanding of where those systems are compatible and where they diverge. This component maps every point of integration between the HEL AMS and the Apex Engine AMS developed in Milestone 5, identifying schema mismatches, authentication protocol differences, permission model incompatibilities, and any data that exists in the HEL system without a defined home in the Apex Engine account architecture. The output is a gap analysis document that drives the integration design decisions for both this milestone and the Apex Hub development in Milestone 6, ensuring that the two systems can share identity data correctly without requiring users to maintain separate accounts.

Update Authentication and Session Management Systems

The HEL authentication and session management implementation predates several generations of security best practice evolution, and this component brings both into alignment with current standards. Authentication is updated to support modern credential handling, including properly salted and hashed password storage, secure token generation, and the infrastructure required to support multi-factor authentication for accounts that require it. Session management is reviewed for known vulnerability patterns — including session fixation, insufficient expiry enforcement, and insecure token transmission — and all identified issues are resolved. The updated authentication layer is designed to be compatible with the SSO integration architecture established in the Apex Engine AMS, enabling the unified login experience that the Apex Hub identity model requires.

Refine Role-Based Access Controls and Permission Structures

The original HEL permission model was designed for a specific set of use cases that has since expanded significantly. This component reviews the existing role and permission structure against the full range of access scenarios required by current HEL deployments and the planned migration to Apex Engine infrastructure, identifying roles that are too broad, permissions that are ambiguously defined, and access control gaps that allow unintended resource access. The refined permission model is designed to map cleanly onto the role-based access control architecture established in the Apex Engine AMS, so that accounts migrating from HEL to Apex Engine carry their access rights correctly without requiring manual reassignment. All permission changes are tested against the full range of existing account types to confirm that no legitimate access is inadvertently revoked during the update.

Validate AMS Compatibility with Updated SQL Layer

The AMS is one of the highest-frequency consumers of the HEL database layer, and every change made in Milestone 11 has potential implications for AMS query performance, data retrieval correctness, and transaction handling. This component validates that the updated AMS operates correctly against the modernised SQL layer produced by Milestone 11, covering schema changes that affect account and session tables, engine version differences that may alter query plan behaviour, and encryption changes that affect how credential and session data is stored and retrieved. Validation is conducted in a staging environment that mirrors the production configuration, with the full AMS functional test suite executed against the updated database before any changes are promoted.

Test Account Workflows End-to-End Across All User Types

The AMS milestone closes with comprehensive end-to-end testing of all account workflows across every user type supported by HeroEngine Legacy — individual developers, team administrators, enterprise licensees, and internal operational accounts. Testing covers the complete lifecycle of each account type: creation, authentication, permission assignment, session management, password recovery, team membership management, and account suspension or closure. Each workflow is validated both in isolation and in combination with concurrent sessions to confirm that the updated AMS handles real-world usage patterns without race conditions, data inconsistencies, or permission leakage. Any failure identified during end-to-end testing is resolved and retested before the milestone advances to the next stage of the Phase 3 update sequence.

The SQL Updates milestone modernises and stabilises the HeroEngine Legacy database layer to meet current production, security, and operational standards. The database is the foundation upon which every other HEL system depends — account management, session state, world data, asset tracking, and telemetry all flow through it. Deficiencies at this layer compound across every system built on top of it, which is why SQL Updates is the first active remediation milestone following the completed code audit. Work is underway, with schema analysis and engine patching already in progress as of April 2026.

Audit Existing Schema Structure and Identify Outdated or Non-Compliant Configurations

The schema audit examines the full structure of the HEL database layer against current standards for relational database design, data integrity enforcement, and operational compliance. Tables, indexes, foreign key relationships, constraint definitions, and stored procedures are all reviewed in full. Configurations that were acceptable practice at the time of original development but no longer meet current standards — including implicit type conversions, missing constraints, undocumented stored procedures, and schema elements that exist only to support deprecated systems — are identified, documented, and flagged for remediation or removal. The audit output provides the precise scope of schema changes required and the order in which they must be applied to avoid disrupting dependent systems during the update process.

Upgrade Database Engine Version and Apply Outstanding Patches

The HEL database engine version predates several significant releases that introduced performance improvements, security patches, and feature additions that the platform now requires. The upgrade process is not a simple version bump — each intermediate release must be reviewed for breaking changes, deprecated features in use by the existing schema, and behavioural differences that could affect query results or transaction handling. Patches are applied in a controlled sequence across non-production environments first, with full regression testing of all database-dependent systems at each stage before the changes are promoted toward production. The upgrade is complete when the production instance is running a fully patched, current engine version with all dependent systems validated against it.

Resolve Storage Threshold and Monitoring Gaps Identified in Infrastructure Review

The infrastructure review conducted in March 2026 identified specific operational gaps in the production database instance, including storage thresholds approaching critical levels and an absence of active monitoring coverage across key performance and health metrics. Both categories of gap represent operational risk that must be resolved before the broader SQL update work can proceed safely. Storage remediation involves both immediate capacity management and structural changes to data retention, archival, and partitioning strategies that prevent recurrence. Monitoring gaps are addressed by implementing comprehensive coverage across query performance, connection pool utilisation, storage consumption, replication lag where applicable, and error rates — with alerting thresholds configured to provide actionable warning ahead of any critical threshold being reached.

Enable Encryption at Rest and in Transit Across All Production Instances

Encryption at rest and in transit is a baseline security requirement for any production database handling user data, session state, or transactional records, and its absence in the current HEL production configuration is a finding that this milestone resolves without exception. Encryption at rest is implemented at the storage layer, ensuring that all data written to disk is encrypted regardless of how it is accessed. Encryption in transit is enforced across all connection paths between the database and the systems that query it, with certificate management and rotation procedures established as operational standards rather than one-time configurations. Both implementations are validated against the security requirements that inform the platform's SOC 2 and ISO 27001 compliance posture.

Validate Credential Management and Document Access Controls

Credential management for the production database instance requires both immediate remediation and the establishment of durable processes that prevent recurrence of the access control gaps identified in the March 2026 review. All database credentials are inventoried, ownership is assigned, and access is scoped to the minimum required for each connecting system or user. Master credentials are secured in a managed secrets store with access logging, and rotation schedules are established and enforced. The full access control model — which systems connect, under which credentials, with which permissions, and through which network paths — is documented completely and stored in a location accessible to authorised team members without depending on any individual's institutional memory.

Regression Test All Database-Dependent Systems Post-Update

Every change applied during this milestone has downstream implications for the systems that depend on the database layer, and no update is considered complete until its effects on those systems have been validated through structured regression testing. Testing covers the full surface area of database interaction across HEL — session management, world state persistence, asset tracking, account data retrieval, and any reporting or telemetry pipelines that query the production instance. Regression tests are executed in sequence after each significant change is applied, rather than as a single pass at the end of the milestone, so that issues are identified close to their source and resolved before subsequent changes are layered on top. The milestone closes when all dependent systems pass regression testing against the fully updated database layer.

The Direct3D / DX11 / DX12 Finalisation milestone completes and validates the HeroEngine Legacy graphics layer across both DX11 and DX12 targets, bringing the rendering implementation to a production standard that supports the full range of hardware configurations in active use by HEL licensees and their end users. Graphics pipeline work is among the most technically demanding in the update programme — rendering bugs are often non-deterministic, hardware-dependent, and difficult to reproduce consistently, and incomplete feature implementations can produce results that appear correct in limited testing but fail under specific hardware and driver combinations. This milestone resolves all known outstanding work in the D3D implementation with the rigour that a production graphics layer requires.

Audit Current D3D Implementation State and Document Outstanding Work

The D3D implementation audit examines the current state of the full Direct3D graphics layer — device initialisation, swap chain management, resource handling, shader compilation and binding, render target management, and the feature sets exposed through both the DX11 and DX12 APIs. Every component is assessed against its intended specification, with the current implementation state documented as one of three categories: complete and validated, partially implemented with known gaps, or present in the codebase but non-functional under current conditions. The audit output is a precise map of outstanding work across the entire D3D layer, prioritised by the impact of each gap on rendering correctness and platform stability, and sequenced to respect the technical dependencies between components that must be resolved in a specific order.

Resolve Known Rendering Issues and Incomplete Feature Implementations

The code audit completed in Milestone 10 surfaced a set of known rendering issues and incomplete feature implementations within the D3D layer that have been carried forward from earlier development stages. This component works through that list systematically, addressing each issue with a resolution that is validated against the specific conditions under which the original problem was observed. Rendering issues are resolved at the root cause rather than papered over with workarounds — a workaround in a graphics pipeline tends to produce a category of subtle visual artefacts that are difficult to attribute and nearly impossible to fully eliminate without eventually returning to the underlying cause. Incomplete feature implementations are brought to a defined completion state, with any features that cannot be completed within the current milestone scope clearly documented with their current state and the remaining work required.

Finalise DX11 Support for Legacy Hardware Compatibility

DX11 support is the compatibility baseline for HeroEngine Legacy, covering the substantial portion of the active licensee hardware base that does not support DX12. Finalising DX11 support means resolving all outstanding implementation gaps, validating correct behaviour across the full feature set exposed through the DX11 API, and confirming that performance is acceptable across the range of hardware configurations that DX11 encompasses — from older integrated graphics through dedicated GPUs that predate DX12 support. Shader correctness, resource state management, and the handling of DX11-specific rendering paths are all validated in full. The DX11 implementation is considered finalised when it passes the complete graphics validation suite across all target hardware tiers without rendering errors, driver warnings, or performance regressions relative to the established baseline.

Complete DX12 Integration for Modern Hardware Targets

DX12 integration addresses the modern hardware tier, providing access to lower-level GPU control, improved multi-threading of rendering work, and the performance headroom that current high-fidelity real-time environments require. The DX12 implementation in HeroEngine Legacy was initiated but not brought to completion, and this component finalises that work — covering command list management, descriptor heap architecture, resource barrier handling, pipeline state object compilation, and the explicit memory management model that DX12 requires compared to DX11. The DX12 path must produce visually identical output to the DX11 path for all shared rendering features, with differences limited to performance characteristics and the additional capabilities that DX12 exposes. Cross-API consistency validation is conducted across the full rendering feature set to confirm parity before DX12 support is marked complete.

Performance Profile and Optimise Rendering Pipeline Under Representative Load

Correctness is the first requirement of a production graphics pipeline; performance is the second, and neither can be sacrificed for the other. Once the DX11 and DX12 implementations are functionally complete, the full rendering pipeline is profiled under load conditions that represent real HEL usage — active world environments with typical asset density, dynamic lighting, particle systems, and multiple simultaneous render targets. Profiling identifies bottlenecks at the CPU submission side, the GPU execution side, and the API boundary between them, with optimisations applied in priority order based on the magnitude of their impact on the overall frame budget. Performance targets are defined per hardware tier before profiling begins, ensuring that optimisation work is directed toward outcomes that matter for the actual licensee hardware distribution rather than toward benchmark performance on idealised configurations.

Conduct Cross-Hardware Validation Testing Across Target Configurations

The final validation stage for the D3D layer tests the complete, optimised implementation across the full matrix of target hardware configurations — spanning GPU vendors, driver versions, and capability tiers from DX11 minimum specification through current high-end DX12 hardware. Cross-hardware validation is the only reliable method for surfacing the category of rendering issues that are hardware or driver-specific and therefore invisible in single-configuration testing. Each configuration in the target matrix is tested against the full graphics validation suite, with any failures classified by whether they represent implementation errors, driver workarounds required, or hardware limitations that must be documented as known constraints. The milestone is marked complete when the full validation suite passes across all configurations in the target matrix, with all failures either resolved or formally documented with their scope and impact clearly stated.

The Art Pipeline Updates milestone reviews and modernises the HeroEngine Legacy art pipeline to ensure full compatibility with current asset formats, tooling standards, and rendering requirements. The art pipeline is the production pathway through which all visual content enters the engine — models, textures, animations, and effects all pass through it before they can be used in a live environment. A pipeline with broken stages, deprecated format handlers, or incompatible tooling does not just slow down content production; it produces incorrect results that are often difficult to diagnose and costly to correct downstream. This milestone resolves those issues systematically, producing a validated, documented pipeline that content teams and licensees can rely on through the relaunch and beyond.

Audit Existing Import and Export Pipelines for All Supported Asset Formats

The pipeline audit begins with a complete examination of every import and export pathway currently supported by HeroEngine Legacy, tested against the full range of asset formats the engine was designed to handle. Each pathway is evaluated for correctness — does it produce the expected output from a known input without data loss, artefacts, or silent errors — and for compatibility with the current versions of the external tools and format specifications it interfaces with. Format specifications evolve over time, and pipelines built against older versions of FBX, OBJ, DDS, and other common formats may silently mishandle assets produced by current content creation tools. Every discrepancy between expected and actual pipeline behaviour is logged with sufficient detail to drive targeted remediation in the subsequent update stages.

Identify Deprecated Tools, Broken Pipeline Stages, and Format Incompatibilities

The audit output is analysed to produce a categorised findings list covering three distinct problem types, each requiring a different remediation approach. Deprecated tools are pipeline components that were functional at the time of original development but are no longer maintained, no longer compatible with current operating environments, or have been superseded by superior alternatives — these require replacement decisions rather than repair. Broken pipeline stages are components that are expected to function but currently do not, producing errors, incorrect output, or silent failures under specific input conditions — these require targeted debugging and repair. Format incompatibilities are cases where the pipeline's handling of a specific format has diverged from the current format specification, producing output that is technically processable but visually or structurally incorrect — these require updates to the format handling logic to realign with current specifications.

Update Asset Format Handling to Support Current Production Standards

With the audit findings categorised and prioritised, format handling components are updated systematically across the full pipeline. Updates address both the import side — ensuring that assets produced by current versions of industry-standard content creation tools are ingested correctly — and the export side, ensuring that assets processed through the HEL pipeline produce output that is compatible with the rendering and runtime systems they feed into. Where format specifications have evolved significantly, handling logic is rewritten rather than patched, ensuring that the updated pipeline operates against the current specification rather than an incrementally modified version of an outdated one. All format handling updates are validated against representative asset sets drawn from actual production content to confirm that results are correct under real-world conditions rather than only under idealised test inputs.

Validate Animation Pipeline Integrity and Resolve Known Issues

The animation pipeline warrants dedicated validation given the complexity of animation data and the number of systems it touches — skeletal rigs, blend shapes, physics-driven secondary motion, and timeline-based playback all depend on animation data being imported, stored, and played back with precision. Known issues identified in the code audit and the pipeline audit are addressed here, covering incorrect bone transform handling, animation compression artefacts, blend tree evaluation errors, and any cases where the animation pipeline produces results that diverge from the source content in ways that are not intentional optimisations. Validation is conducted with a representative set of animations spanning the full range of complexity supported by HEL — from simple looping ambient animations through complex multi-layer character rigs — to confirm that the updated pipeline handles the complete complexity range correctly.

Test Full Pipeline End-to-End with Representative Asset Sets

Individual component updates are validated in context, but the pipeline as a whole must also be tested end-to-end to confirm that all updated stages work correctly in sequence and that no integration issues have been introduced between components that were individually sound. End-to-end testing is conducted with asset sets that represent the full range of content types, complexity levels, and format combinations that HEL licensees actually use in production. Test assets travel the complete pipeline path from source file through import, processing, internal format conversion, and runtime use, with the output at each stage inspected for correctness before the next stage is executed. Any issue identified during end-to-end testing that was not caught in component-level validation is logged, resolved, and retested before the milestone advances.

Document Updated Pipeline Specifications for Development and Client Reference

A validated pipeline without documentation is a pipeline that only the people who built it can use reliably. This component produces complete, accurate documentation of the updated art pipeline covering supported formats and their version requirements, pipeline stage sequence and configuration, known limitations and their workarounds, and the export settings required from common content creation tools to produce assets that import correctly. Documentation is written to serve two distinct audiences: the internal development team, who need sufficient technical detail to maintain and extend the pipeline, and HEL licensees, who need practical guidance on preparing and delivering assets that work correctly with the platform. Both documentation sets are reviewed for accuracy against the validated pipeline before the milestone is marked complete.

The Build System Updates milestone modernises and stabilises the HeroEngine Legacy build system to support reliable, repeatable builds across the fully updated codebase produced by Milestones 11 through 14. A build system is the operational infrastructure through which all code changes become deployable software, and one that has not been maintained in step with the codebase it serves accumulates its own category of technical debt — broken toolchain dependencies, undocumented build configurations, fragile environment assumptions, and the absence of automated validation that allows build failures to reach downstream stages before they are detected. This milestone addresses all of those accumulated issues, producing a build system that is trustworthy, documented, and capable of supporting the release cadence the relaunch requires.

Audit Current Build Pipeline and Document All Known Issues and Gaps

The build system audit examines the complete pipeline from source checkout through compilation, linking, asset processing, packaging, and deployment artefact generation. Every stage is evaluated for correctness, reliability, and compatibility with the updated codebase that Phase 3 is producing. Toolchain components are inventoried against their current versions and assessed for compatibility with the compiler, linker, and runtime requirements of the updated HEL codebase — version mismatches between build tools and the code they process are a common source of subtle, difficult-to-reproduce build failures that only manifest under specific conditions. All identified issues and gaps are documented in sufficient detail to allow prioritised remediation, with particular attention to any build system dependencies that are shared with the SQL, AMS, graphics, or art pipeline systems updated in earlier milestones.

Modernise Build Toolchain and Resolve Version Incompatibilities

The HEL build toolchain was assembled and configured during an earlier period of the platform's development, and several of its components have since been superseded, deprecated, or allowed to fall out of version alignment with the systems they interact with. This component updates the toolchain systematically — compiler versions, linker configurations, build script interpreters, dependency management tooling, and any third-party build utilities — resolving version incompatibilities identified in the audit and ensuring that the complete toolchain operates as a coherent, compatible set rather than a collection of independently versioned components that happen to produce working output under current conditions. All toolchain updates are validated by executing a full build of the updated codebase and confirming that the output is functionally identical to that produced by the previous toolchain, with any differences investigated and resolved before the update is accepted.

Implement Automated Build Validation and Error Reporting

A build system without automated validation is a system that relies on manual discipline to catch errors — and manual discipline, however well-intentioned, is not a scalable quality control mechanism as release cadence increases. This component implements automated validation at every significant stage of the build pipeline, confirming that each stage produces the expected output before the next stage is initiated. Validation covers compilation success and warning thresholds, link integrity, asset processing correctness, packaging completeness, and deployment artefact integrity. Error reporting is designed to produce actionable output — when a build fails, the error report identifies the specific stage, the specific component, and where possible the specific change that introduced the failure, rather than producing a generic failure notification that requires manual investigation to diagnose. Automated build validation runs on every commit to the main development branch, ensuring that build health is continuously monitored rather than assessed only at release time.

Test Full Build Pipeline Against Updated Codebase Post-Milestones 1 Through 5

The build system does not operate in isolation — it must process the complete, integrated codebase produced by all preceding Phase 3 milestones as a unified whole, and the interactions between the updated SQL layer, AMS, graphics pipeline, art pipeline, and build system itself introduce integration surface that component-level testing cannot fully cover. This component executes a full end-to-end build of the complete updated HEL codebase through the modernised build pipeline, treating the output as the candidate build for the Pre-Release Finalisation milestone that follows. The build is validated not only for successful completion but for output correctness — the compiled platform is deployed to a staging environment and subjected to functional testing across all major systems to confirm that the build process has not introduced any regressions relative to the component-level validated state of each subsystem. A clean, validated full build is the gate condition for advancing to Milestone 16.

The Pre-Release Finalisation milestone is the last gate before HeroEngine Legacy returns to live service. Where every preceding milestone in Phase 3 focused on a specific system or subsystem, this milestone treats the platform as a unified whole — validating that all updated components work correctly together, that the security posture meets the standard required for a production relaunch, that existing client deployments have a clear and tested migration path, and that the documentation and support materials needed for a successful return to service are complete and accurate. Nothing in this milestone is optional. Every item is a relaunch prerequisite, and the milestone does not close until all of them are satisfied.

Conduct Full Integration Testing Across All Updated Systems

Integration testing at this milestone is not a repeat of the component-level validation conducted within each preceding milestone — it is a systematic test of the complete platform as a unified system, executed against the full range of scenarios that HEL licensees and their end users actually encounter in production. Test scenarios are drawn from documented real-world usage patterns across all supported deployment types, covering the interaction between the updated SQL layer, AMS, graphics pipeline, art pipeline, and build system under concurrent load conditions that reflect actual production environments. Any integration failure identified at this stage — a failure that did not manifest in component-level testing because it only emerges when multiple updated systems interact simultaneously — is treated as a blocking issue and resolved before integration testing advances to the next scenario category. The integration test suite, once passed in full, becomes the regression baseline for all post-relaunch maintenance.

Complete Security Audit and Resolve All Outstanding Findings

A production relaunch is a security event as much as a technical one — it expands the attack surface, reactivates dormant authentication pathways, and introduces updated components whose security characteristics must be validated in the context of the complete system rather than in isolation. The pre-release security audit covers the full updated HEL platform, examining authentication and session management, credential storage and transmission, permission enforcement across all access control boundaries, network exposure, dependency vulnerability status, and the encryption implementations validated in Milestone 11. All findings from the audit are categorised by severity, and all critical and high-severity findings are resolved and re-validated before the milestone advances. Medium and low-severity findings are either resolved or formally accepted with documented rationale and a defined remediation timeline. The security audit report, including all findings and their resolution status, is retained as part of the relaunch documentation record.

Prepare and Validate the Migration Path for Existing Active Production Deployments

HeroEngine Legacy has existing licensees with active production deployments, and the relaunch must not disrupt those deployments or place the burden of a complex migration on clients without clear guidance and validated tooling. This component designs, documents, and tests the migration path that existing production deployments will follow to move from their current HEL version to the relaunched platform. The migration path covers database schema migration, AMS account data migration, asset pipeline compatibility for existing content libraries, and build system reconfiguration where required. Migration tooling is tested against representative production deployment configurations — not just clean installations — to confirm that it handles the real-world variation in how licensees have configured and extended their deployments over time. The migration documentation is written to be executable by a technically competent licensee without requiring direct support intervention for the standard case.

Finalise Client-Facing Documentation, Release Notes, and Support Materials

The relaunched HeroEngine Legacy platform must be accompanied by documentation that accurately reflects its current state — not its state at the time of original development, and not an aspirational description of intended behaviour. Client-facing documentation is reviewed and updated across all areas affected by Phase 3 changes, covering the SQL layer, AMS, graphics pipeline, art pipeline, and build system. Release notes are prepared in full, documenting every significant change made during Phase 3 in terms that are meaningful to licensees — what changed, why it changed, what the impact on existing workflows is, and what action if any is required from the licensee. Support materials covering the most common migration questions, known limitations, and troubleshooting procedures for the updated platform are prepared and validated by the support team before the relaunch. No documentation is marked complete until it has been reviewed for accuracy against the validated platform by a team member who did not write it.

Conduct Controlled Internal Soft Launch and Resolve Any Final Issues Before Live Release

The final step before HeroEngine Legacy returns to live service is a controlled internal soft launch — a period during which the fully updated platform operates in a production-equivalent environment under conditions that mirror real licensee usage as closely as possible, without being publicly accessible. The soft launch exercises every system validated in the preceding milestone steps under sustained operational load, with the team actively monitoring for issues that only emerge under extended real-world conditions rather than structured test scenarios. Any issue identified during the soft launch is triaged immediately — critical issues halt the relaunch process until resolved, while lower-severity issues are assessed for whether they can be accepted at launch with a defined post-launch fix timeline or must be resolved first. The soft launch period concludes when the platform has operated stably under representative load for a defined minimum duration without critical issues, at which point HeroEngine Legacy is cleared for live release and Phase 3 is complete.