Compliance with Digital Sovereignty Standards

Compliance with Digital Sovereignty Standards.

A general-purpose XR constructor.

    Keyboard and mouse control.

    Output to a monitor screen.

    No compile, build, or deploy required.

    Runtime editing.

    Runtime content import.

    Runtime scripting.

    Can be deployed locally on own hardware or cloud resources.

    Ready-made initial templates for business use cases of digital spaces.

    Collaborative space editing, access control and role management (client, admin, content maker).

    Plugin module architecture, eliminating the need to rebuild the core to extend functionality.

    Storage, sharing, migration, and backup of digital spaces.

Technical Analysis of XR Constructor's Compliance with Digital Sovereignty Principles

Problem: The digital sovereignty of an organization or state implies possessing full technological control over digital assets, infrastructure, data, and their processing workflows. Key risks undermining sovereignty include: dependence on foreign proprietary software, inability to audit source code, binding to third-country cloud services, uncontrolled data export or access. It is necessary to analyze the extent to which the XR Constructor platform, with its specified characteristics, serves as a technical tool for implementing digital sovereignty in the field of creating and operating extended reality (XR).

Analysis: The principles of digital sovereignty are decomposed into technical requirements. Let's compare them with the platform's characteristics.

    Control over Infrastructure and Deployment (Sovereignty Principle: Independence from external services).

        Requirement: Ability to choose the runtime environment: local server (on-premise), private cloud, national cloud, or trusted public cloud.

        Compliance (item 7): The platform allows deployment on own hardware. This eliminates dependence on a specific public cloud provider (e.g., AWS, Azure, Google Cloud), provides full control over network traffic, performance, and physical access to servers.

        Technical Conclusion: The platform's architecture is not tied to specific PaaS/SaaS services, as confirmed by the possibility of local deployment.

    Control over Data and its Lifecycle (Sovereignty Principle: Data Sovereignty).

        Requirement: Full management of storage location, backup, migration, and data formats.

        Compliance (item 11 and format clarification): Built-in mechanisms for storage, sharing, migration, and backup of digital spaces, working with native file formats. The absence of intermediate proprietary binary formats means all assets (3D models, textures, scenes, configurations) are stored in standardized, well-documented formats (e.g., glTF, USD, PNG, JSON).

        Technical Conclusion: Data remains fully interoperable and owned by the user. The risk of losing access to content due to platform-specific closed format obsolescence is eliminated. This ensures long-term preservation and independent transfer of digital assets.

    Technological Independence and Absence of Vendor Lock-in (Sovereignty Principle: Technological Sovereignty).

        Requirement: Ability to modify, audit, fully analyze the codebase, and extend the platform without legal or technical restrictions from the vendor.

        Compliance (items 3, 10 and clarifications):

            Item 3 (No compile, build, deploy for user content): Indicates an interpreted runtime environment, accelerating the development cycle for applied solutions.

            Open-source core: The platform's source code is available for audit, security analysis, building, and modification under a model similar to Unreal Engine. This eliminates dependence on a single supplier, allows for creating forks, porting to required platforms, and conducting state code examination.

            Item 10 (Plugin module architecture) and fully open API: The architecture allows extending functionality via plugins. The openness and full documentation of the API guarantee that the module ecosystem can develop independently of the vendor.

            Native data formats: Confirms the absence of hidden data binding to the engine's internal structure.

        Technical Conclusion: The combination of an open-source core, open API, and use of native formats represents the maximum level of technological independence. The customer gains full ownership of the technology stack, the right to modify it, and provide long-term support using national developers.

    Operational Control and Security (Sovereignty Principle: Access and Process Management).

        Requirement: Detailed user rights management, action auditing, operation within isolated networks.

        Compliance (item 9): The presence of a role model (client, admin, content maker) and collaborative editing mechanisms with access control is a basic requirement for corporate and state systems. When deployed on-premise (item 7), all communications can be confined within a secure perimeter.

        Technical Conclusion: The platform provides the technical toolkit for implementing security policies and compliance with internal regulations (e.g., GOST, FSTEC).

    Personnel and Production Sovereignty (Sovereignty Principle: Independence of Competencies).

        Requirement: Reducing dependence on specialists in specific proprietary tools.

        Compliance (items 4, 5, 6, 8):

            Runtime editing, import, scripting (items 4, 5, 6): Allows subject matter experts (designers, methodologists, analysts) to create and modify content without constant involvement of core developers using low-level languages.

            Item 8 (Ready-made use case templates): Accelerates adoption and reduces the need for foreign consultants.

        Technical Conclusion: The platform shifts the competency focus from engine development to applied XR content creation, enabling personnel training within the national education system.

Solution Options (Sovereignty Implementation Scenarios using XR Constructor):

    National/Corporate XR Platform: Deployment on a secure data center. Integration with national identity systems (ESIA, corporate SSO). Plugin development by accredited local integrators for specific tasks (import from domestic CAD systems, integration with ICS).

    Closed Loop for Critical Infrastructure: Use in isolated networks (Air-Gap) for personnel training or process simulation. Complete absence of external runtime dependencies, critical for energy and defense industries.

    Basis for an Industry Standard: Due to its open architecture and controlled data formats, the platform can become the basis for developing industry standards for digital twins, representing the highest form of technological sovereignty.

Assessment by Criteria:

    Infrastructure Control (item 7): High. Full compliance.

    Data Control (item 11, native formats): High. Guaranteed interoperability and long-term preservation.

    Technological Independence (item 10, open source, API): High. Full compliance with technological sovereignty principles.

    Security and Management (item 9): Medium/High. Basic model is present; integration with specific authentication and auditing systems is required.

    Operational Autonomy (items 4,5,6,8): High. Enables creation and maintenance of content by users.

Conclusion:

The presented technical characteristics of XR Constructor, particularly the open-source core, use of native data formats, open API, and the possibility of local deployment, directly and fully meet the engineering requirements of digital sovereignty. The platform is not merely a tool, but a technological foundation for building a sovereign, secure, and independent extended reality ecosystem. It provides the capability to establish complete control over the entire chain: from hardware infrastructure and source code to the final digital assets and the competencies for their creation. To fully realize the sovereign potential, a strategy for platform development and support by national integrators and developers is required, which is architecturally and licensing-wise enabled.

Technical Audit of Unreal Engine 5 (Epic Games) Compliance with Digital Sovereignty Principles

Problem: An objective assessment is required to determine the extent to which the popular commercial game engine Unreal Engine (UE), developed by the American company Epic Games, complies with the key technical and organizational-legal criteria of digital sovereignty for states or organizations outside US jurisdiction.

Analysis: The evaluation is conducted using the same engineering and systemic criteria as for the XR Constructor, considering publicly available information on licensing, architecture, and Epic Games' policies.

    Control over Infrastructure and Deployment.

        Requirement: Independence from external services, ability for on-premise deployment.

        Compliance (Technical): The engine allows building the final application (package) and deploying it on own servers or end-user devices. Epic's online services (AccelByte, EOS) are not mandatory for basic functionality.

        Limitation (Systemic): Access to source code, updates, the Marketplace, and some development tools (e.g., console builds) requires connection to an Epic Games account and agreement to their terms. The development environment itself (Unreal Editor) is not a full-fledged on-premise solution in the cloud sense—it is a developer workstation.

        Technical Conclusion: Control over the final deployment endpoint is high. Control over the development toolkit and supply chain is conditional, dependent on constant connectivity and a licensing agreement with a foreign vendor.

    Control over Data and its Lifecycle.

        Requirement: Full management of data formats, their migration, absence of binding to proprietary binary formats.

        Compliance: UE employs a mixed strategy:

            Import: Supports numerous open and proprietary formats (FBX, USD, PNG, etc.).

            Storage: Core assets (materials, levels, blueprints) are saved in proprietary binary formats (.uasset, .umap). These formats are only partially documented via the API. Complete migration of a project to another engine without losses is impossible.

            Project source code (C++): Controlled by the user.

        Technical Conclusion: Low/Medium level of control. The user depends on Epic's tools to work with the project's core data. Digital assets are "locked" within the UE ecosystem. The long-term preservation of a project (20+ years) is questionable without access to a compatible version of the engine and editor.

    Technological Independence and Absence of Vendor Lock-in.

        Requirement: Ability to audit, modify code, and pursue independent development.

        Compliance:

            Source Code: Available via a Source Code Access subscription. This allows for code audit, modifications, and building custom versions of the editor and engine.

            License (Unreal Engine EULA): Strictly regulates usage. A modified engine can be used internally, but distributing commercial products based on it is subject to royalty terms (5% after a certain threshold) and requires coordination with Epic Games. Creating an independent fork for distribution is prohibited.

            Plugins and API: The plugin architecture is powerful, but the engine core is monolithic and complex for deep modification. Key subsystems (rendering, physics) can be replaced, but this requires exceptional expertise.

        Technical Conclusion: Conditional technological independence with critical legal restrictions. The engine can be studied and modified, but one cannot sovereignly own a developed version of it and distribute it on their own terms. Dependence on Epic Games' licensing policy and roadmap is absolute.

    Operational Control and Security.

        Requirement: Access management, isolated execution, compliance with standards.

        Compliance: The engine provides basic tools for implementing custom security systems within the final application. However:

            Code audit for compliance with standards (FSTEC, GOST): Theoretically possible due to source code access, but practically extremely difficult due to the colossal code volume (millions of lines) and its constant updates.

            Undeclared capabilities: A full audit for backdoors or undocumented calls requires resources comparable to developing a proprietary engine.

            Dependence on Epic services: Some components (analytics, certain Marketplace plugins) may have external calls.

        Technical Conclusion: Medium level of operational control with high risks. The security of the final product falls on the developer, but ensuring the security and "purity" of the toolkit (the engine itself) within digital sovereignty requirements is practically unfeasible.

    Personnel and Production Sovereignty.

        Requirement: Independence of competencies from the vendor.

        Compliance: Unreal Engine is a de facto global standard in AAA development, which creates:

            Plus: A large pool of specialists and training materials.

            Minus: Competencies are tailored exclusively to the Epic ecosystem. Deep knowledge of the engine architecture is not transferable. Development depends on decisions made in North Carolina, USA.

            Royalties: Create a direct financial dependence of a project's commercial success on a foreign legal entity.

        Technical Conclusion: Low level of sovereignty. A dependent economy and expertise are formed. The risk of sudden changes to licensing policy (which has happened in UE's history) or access blocking for certain jurisdictions is a constant systemic risk.

Assessment by Criteria (compared to ideal sovereignty requirements):

    Infrastructure Control: Medium. (Dependence on Epic account and services for development).

    Data Control: Low. (Critical dependence on proprietary .uasset/.umap formats).

    Technological Independence: Low. (Legal restrictions of the EULA outweigh the technical possibility of code modification).

    Security and Management: Medium/Low. (Impossibility of complete guaranteed audit and control).

    Personnel and Economic Independence: Low. (Expertise and financial flows are tied to a foreign vendor).

Conclusion:

Unreal Engine 5, as a product of the commercial company Epic Games (USA), fundamentally does not comply with the key principles of digital sovereignty, despite providing access to source code.

    Legal Dependence: The End User License Agreement (EULA) is the primary limiting factor, making the use of the engine dependent on the policies of a foreign company.

    Technological Lock-in: Closed data formats and monolithic architecture make projects inseparable from the Epic ecosystem.

    Geopolitical Risk: The engine is a tool controlled by US jurisdiction, making it vulnerable to sanctions, update bans, or export restrictions for certain industries or countries.

From a technical standpoint, UE5 is a powerful but sovereignty-dependent tool. Its use in industries critical to national security or economy (defense, energy, public administration) creates unmitigated strategic risks. It can only be considered for sovereign use in non-core, commercial entertainment projects where dependency risks are deemed acceptable. For tasks where sovereignty is a mandatory requirement, alternatives with open licenses (e.g., Godot Engine) or national developments, similar to the analyzed XR Constructor, whose architecture is initially designed to eliminate the aforementioned dependencies, are necessary.

Audit of Technological Sovereignty for the XR Constructor Architecture Based on Unreal Engine 5 (Final Analysis)

Problem: Assessment of the technological sovereignty of an architecture where XR Constructor is a compact software layer compiled into a standalone application on top of a modifiable Unreal Engine 5 core. The developing company assumes responsibility for maintaining compatibility and project migration. Context: the absence of market alternatives meeting performance and maturity requirements.

Analysis Based on Digital Sovereignty Criteria:

    Control over Infrastructure and Deployment.

        Architecture: Standalone application without Epic Online Services (EOS).

        Sovereignty Level: High. Enables deployment in air-gapped networks, national clouds, and local servers. Full physical and network control resides with the user.

    Control over Data and its Lifecycle.

        Architecture: Native file formats with a JSON layer for runtime import. Developer commitment to ensuring project migration to new versions.

        Sovereignty Level: High (Operational) / Conditional (Strategic).

            Operational: The developer guarantees project portability between versions, removing technical obsolescence risks from the user.

            Strategic: Core assets (models, textures) are sovereign, but complete independence from UE formats is not achieved. However, the developer's commitment transforms this risk from a technical one into a contractual one, which is standard practice.

    Technological Independence and Risk Management.

        Architecture: Ability to modify the UE5 core. Compactness of the XR Constructor layer to reduce support costs.

        Market Context: Absence of viable alternatives (Unity — proprietary and unstable, Godot — insufficiently performant, others — niche or immature).

        Analysis:

            Technical Control: High. The ability to modify the core eliminates critical dependence on Epic Games' bug and vulnerability patch schedule. Allows optimization of the core for specific XR tasks (latency, rendering).

            Economic Risk: Epic Games' royalties remain a cost item, creating financial dependency and affecting the total cost of ownership.

            Legal Risk (Key): The Epic Games EULA remains the primary, unmitigable systemic risk. Sanctions or changes to Epic's terms could paralyze the project. Core modification does not invalidate the license.

            Mitigation Strategy: Plans for negotiations with Epic or a hypothetical rights acquisition for license change are extra-engineering but pragmatic political-economic measures given the market vacuum of alternatives.

        Sovereignty Level: Medium. Technical control mechanisms are high, but fundamental legal dependency persists, transforming sovereignty from absolute into managed and contractual. This is a compromise between the ideal and market reality.

    Operational Control, Security, and Personnel.

        Architecture: Core modification for security. XR Constructor layer abstracting users from UE complexity.

        Sovereignty Level: High.

            Security: Allows for auditing and fixing the core, which is critical for the public sector.

            Personnel: No UE expertise required for end-users. For the developer, a unique pool of experts in deep UE modification is formed, which is a strategic asset, not a dependency.

    Economic and Strategic Model.

        Model: Developer's compatibility support commitments are funded through user licenses/contracts. Orientation towards a community of allied states.

        Analysis: A closed-loop economic ecosystem around XR Constructor is formed. Users fund not Epic royalties (as an indirect cost), but the creation and maintenance of a sovereign product, part of which is the adapted core. This is a model of collective technological sovereignty.

        Sovereignty Level: High (within the model). Shifts the relationship from the "consumer of proprietary software" paradigm to the "co-investment in a controlled platform's development" paradigm.

Final Conclusion:

The presented architecture is not "ideally sovereign" in a dogmatic sense (complete independence from foreign code), but represents the most sovereign, pragmatic, and technically sound model within the constraints of the current technology market.

    This is a strategy of "controlled dependency" with a plan for its minimization. In the absence of ready alternatives, the path forward is not to reject powerful technology, but to:

        Build competencies for its deep modification (technical sovereignty).

        Create a sustainable economic model around its development (economic sovereignty).

        Actively work to neutralize the key risk (licensing) at the political-legal level.

    For the end-user (state, corporation), sovereignty is ensured not by abstract "openness," but by specific contractual obligations of the developer:

        Delivery of a standalone product.

        Migration and support guarantees.

        Vulnerability response.

        Development according to the user community's requirements.

    Applicability Classification:

        For critical domains (Defense, Critical Information Infrastructure): The model is acceptable given intergovernmental agreements and contingency plans (e.g., contractual rights to fork the last accessible core version in case of license termination). The technical ability to modify the core is critically important here.

        For the public sector and industry: The model is highly effective and optimal, as it combines ready-made power with an acceptable and manageable level of risk.

        For the commercial sector: The model is competitive, offering openness and control unavailable when working with vanilla Unreal Engine.

Summary:

XR Constructor on an adaptable UE5 core is a practical implementation of Digital Sovereignty as a Service (Sovereignty-as-a-Service). This is not dogma, but an engineering-management strategy that transforms raw technological dependency into a controlled, developable asset with clear risk and responsibility allocation. In the absence of perfect alternatives, this is not a compromise, but the only rational strategy for rapidly creating a high-grade, controlled XR platform.

Conclusions on the Suitability of NVIDIA Omniverse for Digital Sovereignty

Key Problems of Omniverse from a Sovereignty Perspective:

    Hard Dependency on the NVIDIA Ecosystem

        The platform is deeply integrated with NVIDIA's hardware and software stack (GPU, CUDA, PhysX, drivers).

        Nucleus is a proprietary central server, creating a single point of control and dependency.

    Vendor Lock-in

        Migrating from Omniverse to another platform requires enormous costs for data migration and personnel retraining.

        Data and processes are confined within the NVIDIA ecosystem, reducing flexibility and strengthening monopoly influence.

    Closed Nature and Limited Openness

        Despite using the open USD format, key components (Nucleus, connectors) remain proprietary.

        NVIDIA drivers for Linux are proprietary, creating problems for the open-source community and reducing goodwill.

    High Cost and Complexity of Ownership

        Pricing targets large enterprises, making the platform inaccessible for small and medium businesses, startups, and government projects with limited budgets.

        Requires expensive infrastructure (OVX servers, RTX workstations).

    Strategic Risks

        NVIDIA can unilaterally change licensing terms, the technology stack, or discontinue support.

        Geopolitical vulnerability: Dependence on TSMC for chip manufacturing and potential sanctions risks.

Alternative: An Open Platform Based on Unreal Engine 5

    Architectural Sovereignty

        Ability to build one's own platform with full control over code, data, and infrastructure.

        Absence of hard dependency on a single vendor.

    Flexibility and Adaptability

        Capability to integrate any third-party tools, standards, and formats.

        Support for open standards (USD, glTF) without forced use of proprietary services.

    Economic Efficiency in the Long Term

        No need to pay expensive corporate licenses.

        Ability to develop the platform according to one's own needs, not NVIDIA's roadmap.

    Ecosystem Independence

        Not dependent on the policies of a single company.

        Ability to create one's own marketplaces, connectors, and tools, forming an open ecosystem.

Conclusion:

NVIDIA Omniverse is a powerful but dependent solution that does not align with the principles of digital sovereignty. It creates risks of long-term lock-in to the NVIDIA ecosystem, limits flexibility, and is controlled by a single vendor.

For building digital sovereignty, an open platform based on Unreal Engine 5 (or a similar technology) is preferable, as it allows:

    Controlling the entire data and technology chain.

    Avoiding vendor lock-in.

    Adapting the solution to national, corporate, or industry standards.

    Reducing long-term costs and risks.

Thus, if the goal is not just an efficient solution "here and now," but strategic independence, flexibility, and control over digital assets, then Omniverse is not the optimal choice. An open platform based on UE5 or a similar stack represents a more resilient and sovereign path.