Systems and methods for software design and execution based on interpretable containers

Interpretable containers address software fragmentation by enabling modular execution and real-time updates across platforms, optimizing resources and customizability, while reducing bandwidth and memory demands.

WO2026102343A1PCT designated stage Publication Date: 2026-05-15CHARIOT TECHNOLOGIES LAB INC
View PDF 3 Cites 0 Cited by

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
CHARIOT TECHNOLOGIES LAB INC
Filing Date
2025-11-07
Publication Date
2026-05-15

AI Technical Summary

Technical Problem

Modern software programs face fragmentation across different platforms and programming languages, leading to increased bandwidth consumption, memory demands, and difficulty in updating and customizing applications, especially in devices with limited resources.

Method used

The use of interpretable containers that can be interpreted into instructions associated with various programming languages and platforms, enabling modular execution of functionality, real-time updates, and seamless customization without requiring complete code installation.

Benefits of technology

This approach reduces bandwidth consumption, optimizes memory usage, enhances flexibility and customizability, and improves computational efficiency by activating only necessary modules, making applications lightweight and difficult to decompile.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure US2025054682_15052026_PF_FP_ABST
    Figure US2025054682_15052026_PF_FP_ABST
Patent Text Reader

Abstract

Systems and methods for software design and execution based on interpretable containers. An example method is implemented by a system of one or more processors. The example method includes determining functionality to be executed, with the functionality being executed based on an interpretable container. The interpretable container includes information configured for interpretation into instructions associated with one or more programming languages, with the instructions enabling execution of the particular functionality. The interpretable container is accessed or generated. To generate the interpretable container the system generates information that can be interpreted into instructions associated with one or more programming languages. Execution of the particular functionality is caused based on interpretation of the information included in the interpretable container.
Need to check novelty before this filing date? Find Prior Art

Description

SYSTEMS AND METHODS FOR SOFTWARE DESIGN AND EXECUTION BASED ON INTERPRETABLE CONTAINERSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U. S. Prov, Patent App. No. 63 / 718366 titled “SYSTEMS AND METHODS FOR SOFTWARE DESIGN AND EXECUTION BASED ON INTERPRETABLE CONTAINERS” and filed on November 8, 2024, the disclosure of which is hereby incorporated herein by reference in its entirety.BACKGROUND TECHNICAL FIELD

[0002] The present disclosure relates to data execution, and more particularly, to data execution based on interpretable containers.DESCRIPTION OF RELATED ART

[0003] Modem software programs are increasingly fragmented between different platforms. For example, an entity which has released an application may be required to create different versions of the application for different platforms. In this example, a first version of the application may be released for a first mobile platform while a second version may be released for a second mobile platform. Similarly, different devices or platforms may use different programming languages. As an example, a first device may execute applications written in JAVA while a second device may execute applications written in SWIFT.

[0004] Additionally, programs are increasingly large. For example, an entity may include substantial functionality in a program. As may be appreciated, the entity may update the program and cause an update to be downloaded on an end-user device. Due to its size, frequent updates may consume bandwidth and reduce an extent to which the program may be used on short notice. Moreover, these programs may often demand significant memory, which can further limit accessibility on devices with limited memory resources.SUMMARY

[0005] In some embodiments a method, system, and computer readable media are described. An example method is implemented by a system of one or more processors and the method comprises determining particular functionality to be executed, wherein the particular functionality is configured to be executed based on an interpretable container, the interpretable container including, at least, information configured for interpretation into instructions associated with one or more programming languages, and wherein the instructions enable execution of the particular functionality; accessing, or generating, the interpretable container, and wherein to generate the interpretable container the system is configured to generate information that can be interpreted into instructions associated with one or more programming languages; and causing execution of the particular functionality based on interpretation of the information included in the interpretable container.

[0006] In some embodiments a method, system, and computer readable media are described. An example method comprises causing presen tation of an interactive user interface associated with an application, wherein the interactive user interface: presents one or more interactive elements, and responds to selection of a particular interactive element, wherein the selection triggers a request for an interpretable container, wherein the interpretable container includes, at least, information configured for interpretation into instructions associated with one or more programming languages, and wherein the instructions are associated with updating the interactive user interface based on the particular interactive element; obtaining, the interpretable container, wherein the information included in the interpretable container is interpreted into instructions associated with a programming language of the interactive user interface; and updating the interactive user interface based on the instructions associated with the programming language of the user interface, wherein the updated interactive user interface updates in accordance with selection of the particular interactive element.

[0007] In some embodiments, a method, system, and computer readable media are described. An example system that comprises one or more processors and non-transitory computer storage media storing instructions that when executed by the one or more processors, cause the one or more processors to perform operations comprising determining particular functionality to be executed, wherein the particular functionality is configured to be executed based on an interpretable container, the interpretable container including, at least, information7configured for interpretation into instructions associated with one or more programming languages, and wherein the instructions enable execution of the particular functionality; accessing, or generating, the interpretable container, and wherein to generate the interpretable container the system is configured to generate information that can be interpreted into instructions associated with one or more programming languages; and executing the particular functionality based on interpretation of the information included in the interpretable container.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1A is a block diagram of an example system executing an application based on a multitude of interpretable containers,

[0009] Figure IB is a block diagram of the example system updating a user interface associated with the application.

[0010] Figure 1C illustrates example detail of a processor receiving, or transmitting, an interpretable container.

[0011] Figure 2 A is a block diagram of example processors interacting via an interpretable container.

[0012] Figure 2B is a block diagram of example processors interacting via an interpretable container based on a computation task.

[0013] Figure 2C is a block diagram of example processors executing sub-tasks based on a multitude of interpretable containers.

[0014] Figure 3 is a flowchart an example process for executing functionality based on an interpretable container,

[0015] Figure 4 is a flowchart of an example process for updating a user interface associated with an application based on an interpretable container,

[0016] Figure 5 is a flowchart of an example process for transmitting a new interpretable container responsive to a request for custom functionality.

[0017] Figure 6 is a block diagram illustrating use of interpretable containers for artificial intelligence, such as use of interpretable containers for inference and training.

[0018] Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like referencenumerals are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same.DETAILED DESCRIPTIONIntroduction|0019] This specification describes innovative techniques for modularizing functionality for execution by one or more processors. As will be described, information may be included in a modular form, such as a discrete file or data structure, and may be interpretable into multiple programming languages. For example, a system may interpret information into instructions associated with a programming language or platform. In this example, the information may define, or otherwise describe, functionality which is to be performed. The system may execute the instructions to cause execution of the functionality. Similarly, a different system may execute the functionality via interpreting the information into instructions associated with a same, or different, programming language or platform. Thus, in some embodiments the information may be substantially universal and cause execution of functionality regardless of a programming language, or platform, used by a system.

[0020] The above-described modularized functionality is referred to herein as an interpretable container. Example information included in an interpretable container may include text, code, reference(s) to different interpretable container(s), reference(s) to information used for associated functionality, a byte record (e.g., an image, audio, video), and so on. As one example of referenced information, an interpretable container may reference parameters (e.g., weights, biases, and so on) associated with an artificial intelligence (Al) model. For example, the parameters may be specific to a deep learning model or a portion of a deep learning model. In this example, a system may interpret the interpretable container and compute a forward pass through the deep learning model or a portion thereof,|0021] As will be described below, for example with respect to Figures 1A-1B, an application or computer program (collectively' ‘application’) may be executed based on a multitude of interpretable containers. For example, a user device may' present a user interface associated with an application. The user device may receive user input selecting a portion of the user interface (e.g., an interactive element). The application may lack code to respond to the selected portion. Thus, the user device may access an interpretable container which causesthe user interface to update based on the user input. In some embodiments, the user device may request the interpretable container based on a unique identifier (ID), description or other information, associated with the selected portion. For example, the user device may request the interpretable container from a system (e.g., a cloud system, server system, and so on).

[0022] Thus, in some embodiments the user interface of the above-described application may be updated in substantially real-time based on interpretation of interpretable containers. For example, as a user interacts with the application, the user device may access, or receive, interpretable containers to effectuate updates. In this way, the application may be substantially low weight at the user device side and cannot be decompiled to the full source code as it may not include the complete set of interpretable containers required for full functionality. As an example, the underlying application code may trigger access to different interpretable containers based on the actions of the user (e.g., the interpretable containers as needed). Furthermore, the application may trigger access based on actions of the application. For example, the application may determine that it is to perform particular functionality. As one example, the application may determine that it requires inference of a particular deep learning model. As another example, the application may determine that it is to update (e.g., train or refine) the particular deep learning model. As another example, the application may represent an agentic model which decides implementation of disparate tasks to pursue a goal or larger computation task.

[0023] With respect to an application, an entity developing the application may accelerate the development process through modular development. For example, different functionality enabled by the application may be developed simultaneously by multiple developers on different programming languages and enabled for inclusion in the application through deployment of interpretable containers. Additionally, the entity may rapidly update the application through updated interpretable containers. Furthermore, in some embodiments the application may be updated in piecemeal such that the application may, in some embodiments, not need to be reinstalled. For example, updated interpretable containers may be obtained as needed by the application. As another example, updated interpretable containers may be obtained based on the application anticipating need (e.g,, the application may pre-fetch interpretable containers). In this way, the application may be seamlessly updated as it is used (e.g., on a user device).

[0024] Advantageously, an application may be easily customizable for a user. For example, the application may be personalized such that the user may use custom settings, custom visualappearance, custom functionality and so on. In some embodiments, a system (e.g., a back-end system, such as a cloud system or server) may store interpretable containers as being associated with a user ID or hash. As will be described, in some embodiments these interpretable containers may be generated by the system based on the user’s preferences. Thus, the application may obtain these interpretable containers to cause customizable functionality, and / or a customized visual appearance, of the application.

[0025] Additionally, the interpretable containers may reduce the burden associated with developing an application across programming languages or platforms. For example, different mobile devices may execute an application based on receipt of the same interpretable containers. In this example, each mobile device may interpret information included in the interpretable containers into respective programming languages or platforms used by the mobile device.

[0026] As known by those skilled in the art, there are disparate techniques to interpret information into different programming languages. For example, a source-to-source translator may be used to output instructions associated with a particular programming language. In this example, the source-to-source translator, such as a transpiler, may use example transcompilation techniques. In some embodiments, a rule-based or machine learning based interpreter may be used. In this specification the term interpreter is to be understood broadly. For example, an interpretable container may be interpreted into instructions for compilation into executable code. As another example, an interpretable container may be interpretable into instructions which are to be interpreted (e.g., Python instructions).

[0027] Without being constrained by way of theory, a system or user device may execute code associated with, or otherwise implement, an interpreter. These interpreters may be customized based on the programming language(s) or platform associated with the system or user device. As an example, a user device may use a particular operating system. For this example, the interpreter may output instructions which leverage application programming interfaces (APIs) associated with the particular operating system. Similarly, a user device may use a particular interface language. For this example, the interpreter may output instructions which leverage functions associated with the particular interface language.

[0028] The description above described that interpretable containers may be used to update a user interface associated with an application or may enable, or add, functionality associated with the application. For convenience, portions of the description referenced a user devicewhich receives interpretable containers from a system. More generally, and as will be described, an interpretable container may be used to enable any functionality which may be discretely modularized. Additionally, interpretable containers may be used solely by a system. For example, a processor of a system may implement functionality based on one or more interpretable containers. In this example, the processor may access an interpretable container, or interpretable containers, to perform particular functionality. The processor may additionally generate an interpretable container, which it may then interpret into instructions for execution.

[0029] Furthermore, in some embodiments a multiprocessor system may implement functionality based on one or more interpretable containers. For example, the multiprocessor system may include multiple processors (e.g., on separate integrated circuits) which may be wired or have wireless communication. In this example, a first processor and a second processor may effectuate functionality based on one or more interpretable containers. As another example, the multiprocessor system may include a multicore processor. For this example, a first processing core (e.g., central processing unit (CPU)) and a second processing core may effectuate functionality based on one or more interpretable containers. As an example, a first processing unit may interpret an interpretable container received from the second processing unit. In another example, interpretable containers may be executed in parallel on multiple processing cores.

[0030] In some embodiments, multiple processes (e.g., processes executing on an operating system) or systems may effectuate functionality based on one or more interpretable containers. As an example, a first process, or set of processes, may communicate with a second process, or set of processes, to effectuate functionality’. As another example, one system (e.g, device) may trigger functionalities in the other system (e.g. other device) by sending one or more interpretable containers which can be seen as more flexible alternative to microservice or API approach.

[0031] Reference herein to a processor may additionally encompass use of a virtual processor. For example, a cloud system may enable use of virtualized processors which leverage hardware processors. Similar to the above, a virtualized processor may execute functionality based on one or more interpretable containers. As may be appreciated, processor is to be interpreted broadly and may encompass use of graphical processing units (GPUs), neural processing units, application specific integrated circuits (ASICs), and so on. In some embodiments, a processor, such as a CPU, may interpret information included in an interpretable container and cause execution of instructions on a GPU, NPU, ASIC, and so on.Similarly, in some embodiments a hardware-based interpreter (e.g., an ASIC or field programmable gate array (FPGA)) may be used to interpret information in an interpretable container. The hardware-based interpreter may then output instructions for execution by a CPU, GPU, NPU, ASIC, and so on.

[0032] Thus, the disclosed technology addresses technical problems associated with software and / or hardware. For example, traditional offline software poses a significant risk of decompilation and unauthorized duplication, especially when the complete source code resides on a user’s device. In contrast, use of interpretable containers may hide the executable logic from a user.

[0033] With respect to artificial Al, designing a multimodal Al system as a single program is challenging, especially due to the need to train on multiple modalities (e.g., text, images, audio) and the high resource usage (e.g., energy and computational resources). Although still heavy in weight Mixture of Experts (MoE) and Modular Mixture of Experts (MMoE) architectures partly help mitigate issues with resource intensity by activating only a subset of experts at inference, which reduces the computation load. However, these approaches come with their own set of challenges, particularly during training as adding a new expert often requires retraining the entire system. This is because introducing a new expert can disrupt the balance or shift the data distribution, which may degrade the model's performance. Solutions to this issue could involve progressive learning (where new modules are added gradually), selective retraining (only training specific parts of the model), or dynamically training just the new experts without affecting existing ones.

[0034] Another challenge is to combine advantages of various possible software solutions (LEM, ML and rule-based algorithms and so on) in an Al system configured as a single program, A sophisticated gating function is needed, for example, to determine when to route inputs to the LLM or ML versus the rule-based expert. Other issues include tire complexity of integrating diverse systems with different architectures and data requirements, managing data silos, ensuring data quality and consistency, and balancing resource allocation.

[0035] With respect to the above, interpretable containers may be used to address, at least, the described technical problems. For example, modular Al systems, for example as described herein, may significantly improve computational efficiency, memory usage, and energy consumption by activating, in some embodiments, only the necessary modules (e.g,, interpretable containers) during training or inference and distributing tasks across multipleprocessing units. This selective activation may not only optimize resource use but also enhance flexibility, allowing for seamless scaling and adaptability in complex environments. Additionally, when designed and executed with interpretable containers these systems may offer higher performance and reliability, especially in multimodal contexts, as they enable more targeted and accurate training among specialized experts or modalities and employ optimal software solutions for each specific task as described above,

[0036] Example advantages of the disclosed technology may therefore include, at least, one or more of flexibility in program development, cross-platform / cross-language capabilities, easy program maintenance / update management, flexible personalization, possibility to operate in all modes (online / offline / any combination thereof), efficiency in processing resources / energy due to decentralized and distributed execution (multiples processing units / cores), lightweight programs - efficient memory (both RAM and non-volatile memory ) utilization, difficulty to decompile the whole program without all containers available, and so on.

[0037] The above will now be described in more detail below.Block Diagrams

[0038] Figure 1A is a block diagram of an example system 100 executing an application 110 based on a multitude of interpretable containers 112A-112N. The system 100 may be an example of a system of one or more processors, such as a wearable device, a mobile device, a laptop or computer, a server system, and so on. In some embodiments, the system 100 may be a multiprocessor system. For example, the system 100 may include a multitude of processors, such as central processing units (CPUs), graphics processing units (GPUs), neural processing units (NPUs), and so on. As described above, the system 100 may include hardware and / or virtualized processor(s).

[0039] In the illustrated embodiment, the system is executing an application 110. In some embodiments, the system 100 may output a user interface 120 via a display associated with the system 100. For example, the system 100 may include a mobile device and the application 110 may represent a mobile application. In some embodiments, the system 100 may output information for presentation via a different system. As an example, the application 110 may represent a web application. For this example, the application 110 may render, at least in part, the user interface 120 for presentation via the different system. Additionally, the system 100may output information for inclusion in the user interface 120 which may be rendered by the different system.|0040] The application 110 may be executed based on interpretable containers 112A-112N. As described herein, an interpretable container may include information which may be interpreted into instructions to perform functionality. In some embodiments, an interpretable container may include instructions associated with a client-agnostic programming language and may be configured for a particular environment. As one example, performing functionality may include performing an arbitrary' computation task. The instructions may' be associated with a particular programming language, for example C / C++, PYTHON, SWIFT, JAVA, and so on. Additionally, the instructions may be associated with a particular platform, such a mobile platform, an operating system, and so on, which may also be referred to as an environment.

[0041] Thus, the system 100 may execute disparate functionality of the application 110 based on the interpretable containers 112A-112N. In some embodiments, an entirety, or substantially all, of the application’s 110 functionality may be based on interpretable containers. For example, the application 110 may be executed in substantially real-time based on the interpretable containers 112A-112N. in some embodiments, the application 110 may include interpretable container(s) to effectuate performance of specific functionality. As an example, the application 110 may include code (e.g., the illustrated app functionality 164) which is executed by the system 100 (e.g., by the execution engine 160). For this example, the system 100 may execute the code to execute the application 110 (e.g., execute the application to output or generate user interface 120), The system 100, or a user of the system 100, may-then trigger specific functionality of the application 110 which may be based on interpretable container(s). Thus, the application’s 110 functionality may be supplemented using interpretable containers.

[0042] In the illustrated example, the user interface 120 reflects a front-end associated with a network analysis application. As may be appreciated, the application’s 110 functionality is arbitrary,, and the network analysis application is used by way of example. In some embodiments, the application 110 may be headless such that no user interface is generated.

[0043] The system 100 may execute the application via interpreting the interpretable containers I12A-112N. For example, a user of application 110 may interact with the user interface 120. As an example, the user may select an interactive element of the userinterface 120. In response, the system 100 may obtain an interpretable container, or set of interpretable containers, associated with the interactive element. The system 100 may then interpret the obtained interpretable container(s) to cause an update to the user interface 120 which corresponds to the selection.

[0044] As an example, the user may select the ‘network map’ selectable option. For this example, the selectable option may be associated with a particular interpretable container. For example, a unique identifier, or hash, may be associated with the selectable option. The system 100 may then access the corresponding interpretable container. The system 100 may also provide a request for the interpretable container to an outside system (e.g., a cloud system, server system) which stores interpretable containers.

[0045] In response to obtaining the particular interpretable container, the system 100 may interpret the information included in the container into instructions. The instructions may enable the application 110 to determine the network map. For example, the instructions may trigger analyses of a network associated with the system 100. The instructions may additionally cause updating of the user interface 120 to depict the determined network map. An example of an updated user interface is illustrated in Figure IB. As will be described in, at least, Figure 1C, the obtained interpretable container may include other interpretable containers or references to other interpretable containers. Thus, as one example the obtained interpretable container may include information which causes a back-end determination of then network map. The interpretable container may include an interpretable container, or a reference to an interpretable container, that enables a front-end view of the network map.

[0046] The system 100 includes an interpretation engine 150 that interprets interpretable containers into instructions 154. In Figure 1A, the instructions 154 are illustrated as being associated with programming language A (e.g,, an interface programming language, back-end language, and so on). The interpretation engine 150 may, in some embodiments, represent code which is executed by the system 100. In some embodiments, a processor of the system 100 may include local memory, or have access to local memory, which includes, or otherwise stores, the code or executable instructions associated with the code. Thus, individual processors of the system 100 may interpret information included in interpretable containers.

[0047] As known by those skilled in the art, the interpretation engine 150 may use example interpretation techniques to output instructions 154, In some embodiments, the interpretation engine 154 may use transpiling techniques to interpret the included information intoinstructions 154. In some embodiments, the interpretation engine 150 may use machine learning techniques, such as a neural network, to output instructions. For example, the neural network may be trained to output instructions based on input of interpretable containers.

[0048] The interpretation engine 150 may, as an example, be specific to a type of programming language. The interpretation engine 150 may, as an example, be configured to output instructions associated with more than one programming language. For example, the interpretation engine 150 may receive information (e.g., from the system 100, from an interpretable container) indicating which of a set of programming languages is to be used for output,

[0049] In some embodiments, an interpretable container may be configured to be executed on heterogeneous computing platforms (e.g., operating environments) by an interpreter that may be resident on a client system, on a server system, or on both. As described, an interpreter can be embedded into either the program interface on the client or the backend on the server and may interpret a received container for execution on the device to which the container is delivered, thereby supporting execution on different endpoints within a distributed application architecture. Additionally, containers are designed for cross-platform operation such that clients across operating systems, including mobile and desktop environments, accept the same container format for interpretation and execution.

[0050] In certain implementations, the interpretable container includes an environment descriptor that specifies requirements for an operational environment in which interpretation of the container’s information and execution of functionality’ based on that interpretation are to occur. The environment descriptor may identify, for example, target operating system families or versions, processor architectures or instruction sets, runtime libraries, graphics or accelerator frameworks, device drivers, and security policies. Because a container can be expressed as text, the environment descriptor may be included as structured metadata within the same textual artifact that carries the instructions, without restriction on the particular schema used to represent such metadata. In this configuration, the interpretable container itself conveys both executable semantics and the operational parameters under which those semantics are to be realized.

[0051] The disclosed technology may employ an environment manager that, upon receipt of an interpretable container, evaluates the environment descriptor to select an appropriate execution strategy. In one mode, the environment manager identifies a compatible interpreteralready present on the host and invokes it directly. In another mode, the environment manager creates an operational environment specific to the container by obtaining and configuring one or more runtime components specified by the descriptor. After the operational environment is prepared, the interpreter interprets the container and, as appropriate for the target platform, may further cause the interpreted results to be compiled to intermediate representations and machine code for final execution on the host device. Thus, the same container can be executed either on an existing host environment or within a created environment tailored to the container.

[0052] In some embodiments, the environment manager resolves heterogeneity by selecting among multiple platform variants or by provisioning missing platform capabilities. For example, when the host platform differs in operating system or processor architecture from that assumed by the container, the environment descriptor may either point to host-native interpreters or identify compatible alternatives, enabling cross-platform execution across clients that include iOS, Android, macOS, or Windows systems. As another example, when the host lacks a necessary accelerator, such as a GPU required for a specified algorithm, the system can detect that deficiency and either create a software-emulated environment or delegate execution to a server that satisfies the specified capability, as contemplated for tasks that cannot be executed locally due to hardware constraints. In each case, the environment is specific to the interpretation and execution requirements declared for the container.

[0053] To create an operational environment, the environment manager may instantiate a virtualized, sandboxed, or emulated runtime isolated from the host operating system. In one arrangement, the environment manager provisions a user-space container, micro-virtual machine, or emulator and installs a minimal operating system layer or subset of components sufficient to host the interpreter and any declared dependencies. In another arrangement, the environment manager downloads and attaches a prebuilt image referenced in the environment descriptor, verifies its integrity, and mounts or boots the image in isolation. These components may include language runtimes, graphics stacks, device drivers, and security configurations that are applied before interpretation begins, thereby ensuring that execution semantics match those expected by the container. In some embodiments, the created environment is ephemeral and discarded after use; in other embodiments, the environment can be cached for reuse to improve performance and to support offline execution modes in which containers and required components are available locally on the client.

[0054] The operational environment can be created at the client or at the server, depending on policy, capability, and latency considerations. For instance, when client policy restrictskernel-level changes or driver installation, the interpreter on the server can create the required environment, execute the container, and return results to the client, consistent with arrangements in which interpretation and execution may occur at either endpoint. Conversely, when the client holds the interpreter and required dependencies, the container may be executed locally, reducing round trips while preserving the ability to offload tasks that exceed local capability, such as those requiring specialized hardware or data available only at the server.

[0055] In scenarios involving disparate device classes, the interpretable container can include multiple environment profiles that map to different operational systems and hardware characteristics. As one example, a profile targeting a smartphone may specify an interpreter and runtime libraries compatible with the device’s mobile operating system, while a profile targeting a desktop workstation may specify a different interpreter binding and optional accelerator interfaces. The environment manager selects the profile that matches the detected platform and either runs the container within the existing system or creates the specified environment, thereby enabling a single container artifact to execute consistently across heterogeneous hosts.

[0056] In view of the foregoing, the interpretable container can be configured either to be run on an available host environment or to cause creation of an operational environment that is specific to interpretation of information in the container and to execution of particular functionality based on that interpretation. This capability supports device-local operation when feasible, transparent provisioning of needed platform components when absent, and controlled delegation to server-side execution environments when appropriate, all within the container-centric model in which interpretation and execution occur at the point of receipt.

[0057] In Figure I A, the instructions 154 are instructions associated with programming language A. For example, the instructions may be SWIFT code. Additionally, in some embodiments the instructions may leverage particular libraries, application programming interfaces (APIs), and so on. As an example with respect to the system being a mobile device, the instructions 154 may leverage libraries associated with a mobile platform of the mobile device. The instructions 154 may additionally leverage APIs associated with the mobile platform. For example, the instructions may leverage SWIFT functions associated with the mobile platform. In this way, the instructions 154 may cause performance of functionality similar to that of an application which does not utilize the modularized interpretable containers described herein.

[0058] As described above, during operation of the application 110, the system 100 may obtain interpretable containers to perform different functionality. In Figure 1A, the interpretation engine 150 has obtained container 152 from the interpretable containers 112A-112N. For example, the user of user interface 120 may have interacted with an interactive element. As described above, the obtained container 152 may be obtained based on a unique ID or hash which is responsive to the interactive element. In some embodiments, the application 110 may therefore store information associating functionality with interpretable containers. For example, the stored information may reflect an association between functionality and unique IDs or hashes of interpretable containers.

[0059] The obtained container 152 may be stored by the system 100 prior to the interpretation engine 150 obtaining it. For example, the container 152 may have been previously obtained such that the system 100 cached the container 152. As another example, the container 152 may have been pre-fetched based on use of the application 110. For example, pre-fetching may be based on measures of likelihood of use of different functionality as the application 110 is executed. These measures may be determined based on common user flows through the application 110, based on a model predicting likely upcoming functionality, and so on.

[0060] The container 152 may optionally be obtained from a different system. For example, the different system may store interpretable containers which the system 100 may require. The different system may thus store, as an example, all interpretable containers associated with the application 110. In this way, the system 100 may request the container 152 and receive the container 152 in response. While a different system is described above, in some embodiments a different processor of the system 100 may provide the container 152. For example, a first processor, or set of processors, of the system 100 may execute the application 110. In this example, a second processor, or set of processors, of the system 100 may receive requests for interpretable containers. Tire second processor, or set of processors, may then access storage and respond to the requests.

[0061] Thus, the interpretation engine 150 may interpret information included in the container 152 to output instructions 154. An example of information included in an interpretable container is illustrated in Figure 1C. The information may, in some embodiments, reflect pseudocode which may follow example schema or syntax. In some embodiments, the information may be written substantially in prose or human readable text and the interpretation engine 150 may be trained to output responsive instructions, in some embodiments, theinformation may include back-end logic (e.g., syntax of program logic), interface or front-end syntax, interaction between the back-end and interface, and so on. As described above, the information may be interpretable into, as an example, a multitude of programming languages such that the same container 152 may be used across programming languages, platforms, and so on. Thus, information included in the interpretable container may be viewed as a separate container-specific programming language (CSPL) with its own syntax and application rules.

[0062] The system 100 includes an execution engine 160 which executes tire instructions 154. The execution engine 160 may convert the instructions 154 into an executable form by processor(s) of the system 100. For example, and with respect to an example programming language, the instructions may be compiled into object code and then into machine code for execution. The instructions 154 may cause execution on particular processors of the system 100. For example, the container 152 may include information which implicates, or otherwise configures, certain processors of the system 100. As an example, the instructions 154 may leverage a library or API which uses GPU(s). For this example, the execution may occur on CPU(s), along with GPU(s), of the system 100.

[0063] An interpretable container may leverage or use a framework, such as a container framework, that may refer to a collection of executable components and interfaces against which an interpretable container is interpreted and executed. This may include, for example, a library (code library), application programming interface (API), endpoints, and so on. In various embodiments, the framework may include a container interpreter as described herein. The framework may include one or more runtime libraries and / or language runtimes implementing container-level APIs. The framework may include a binding layer that maps container-level API calls to host-platform services (e.g., graphics, storage, network, accelerator drivers). Tire framework may include versioned interface contracts that specify callable functions, datatypes, and capability flags. A container can declare, for example, via metadata, a framework identifier and version and one or more capability requirements. The environment manager matches the declaration to a compatible framework present on the host or provisions a compatible framework instance prior to interpretation.

[0064] As one example of use of GPU(s), the instructions 154 may be associated with a forward pass through a neural network. For this example, the obtained container 152 may include information indicating that certain referenced data is to be used as input to a referenced neural network. As will be described below in more detail, with respect to at least Figure 6, the container 152 may reference one or more interpretable containers associated with the neuralnetwork. The instructions 154 may therefore cause access to data stored by, or otherwise accessible to, the system 100. The GPU(s) may then obtain output based on the forward pass through the neural network. In the example of Figure 1A, the output may be associated with the network map. As described above, the output may be used, as one example, to update the user interface 120. For example, the obtained container 152 may include interface or front-end syntax that causes CPU(s) to update the user interface 120 based on the determined output,

[0065] The system 100 may, in some embodiments, generate a container. For example, the system 100 may generate a container to add new, or different, functionality to the application 110, With respect to the illustrated example, the user of the application 110 may request 162 that the application add particular functionality. As one example, the user may prefer that the user interface 120 add an option to filter aspects of the network when generating the network map. The user may generate a request 162 which, in some embodiments, may be included in an interpretable container.

[0066] Without being constrained by way of example, the user may describe the new functionality (e.g., in high-level description, pseudocode, graphically as a mockup with respect to new user interface functionality or features, and so on). For example, the user may indicate that a new interface element associated with filtering be added. In this example, the user may additionally indicate that the new interface element cause filtering to be performed. In some embodiments, the user may use a user interface that presents different types of logic, front-end elements, and so on. The user may then select from the types to add functionality. As an example, the user interface may include common processing operations, interface elements, and the user may select combinations of these. In some embodiments, the user interface may allow for a drag-and-drop operation such that the user may drag-and-drop interface elements and associate them with particular processing operations and / or logic.

[0067] In this way, a generated container 156 may be obtained that includes information which effectuates new, or different, functionality. In some embodiments, the interpretation engine 150 may analyze the request 162 and generate a responsive container 156. With respect to the request 162 being included in an interpretable container, in some embodiments the engine 150 may interpret the information into instructions. The instructions may cause generation of container 156. In some embodiments, the request 162 may be provided to a different system. For example, and with respect to the system 100 being a mobile device, the different system may represent a cloud system or server. In this example, the mobile device may thus receive generated container 156 to enable the new, or different, functionality. Once received, theinterpretation engine 150 may interpret the information included in the container 156 to output instructions for execution by engine 160.|0068] In some embodiments, individual interpretable containers may be provisioned with dedicated storage associated with the system 100. In some embodiments, the dedicated storage can include a volatile working region used as access memory during interpretation and execution, and a non-volatile region used to persist intermediate artifacts and to exchange data with other containers or with the host application. The storage may be established per container identifier or per running instance and is addressable through the interpretation framework so that read / write operations are performed on behalf of the container under capability controls rather than through unrestricted host memory access.

[0069] The access-memory portion of the dedicated storage can serve as a scratchpad for values produced during interpretation and execution, including but not limited to decoded inputs, intermediate tensors, compiled or transpiled instruction fragments, lookup tables, and temporary indices. The size of this region can be fixed at provisioning time or elastically grown subject to a quota. In some configurations, pages of the access memory are pinned to reduce copy overhead, and the execution engine may reuse or clear the region between invocations according to a policy associated with the container.

[0070] The non-volatile portion of the dedicated storage can operate as a mailbox for exchange of data. A container can publish outputs to one or more named channels in its mailbox, and other containers that declare a corresponding subscription may retrieve those outputs without coupling to the publisher’s internal representation. Tire mailbox can be realized using any of a memory-mapped file, a key-value store, a ring buffer, a shared-memory segment, or a named pipe abstraction, and may support single-writer / multiple-reader or multiple-writer coordination with lightweight locking or version tags to resolve concurrent access. In some cases, mailbox entries include a content descriptor (type, schema / version, and optional integrity hash) to assist consumers in validating and transforming the exchanged data.

[0071] Isolation and security can be enforced at the storage boundary. Each container can be assigned a namespace and a set of capabilities that limit visibility to its own access memory and to only those mailboxes it is authorized to read or write. Data written to non-volatile regions may be encrypted at rest and authenticated with per-container keys. The system can apply retention, eviction, and garbage-collection policies to the dedicated storage, for examplediscarding access-memory contents on completion while retaining mailbox entries until consumed or until an expiry time elapses.|0072] Lifecycle management of the dedicated storage can be coordinated with container deployment and updates. On first load, the system creates the storage regions according to a container’s declared requirements; on update, the system can migrate the mailbox while preserving compatible entries and clearing incompatible ones based on schema versioning. Dedicated storage may be cached across sessions to support offline execution, and quotas can be enforced per container or per application to bound resource usage. Through this arrangement, containers use their access memory for efficient local computation and their mailbox for structured data exchange, enabling the computer program to execute as a set of modular, cooperating units without exposing or fragmenting the host system’s general memory.

[0073] Figure IB is a block diagram of the example system 100 updating a user interface 122 associated with the application. As described above, the obtained container 152 may cause updating of the interface 120 illustrated in Figure 1A. An example updated interface 122 is included in Figure IB. Tire example interface 122 includes an example network map, for example depicting connections between nodes of the network map.

[0074] Figure 1C illustrates example detail of a processor receiving, or transmitting, an interpretable container 172. As described above, with respect to Figure 1A, an interpretable container may include information which is interpretable into instructions associated with a programming language. In some embodiments, the information may be interpretable into a multitude of programming languages. The illustrated example includes example information which may be included in interpretable container 172.

[0075] The container 172 may include text or code which is to be interpreted into a programming language. Example text or code may follow a schema or template, and may reflect pseudocode, scripting code, and so on. The text or code may include, in some embodiments, one or more of logic, functionality, interface syntax, interactions between interface syntax and logic or functionality, and so on. Thus, as one example an interpretable container may be associated with adjusting a language used in an application. In this example, the text or code may include references to identifiers, or locations, associated with existing text in an existing language used by the application. The interpretable container may additionally include updated text in the adjusted language or may include reference(s) to locations (e.g., network locations, storage locations) to the adjusted language.

[0076] The container 172 may additionally include references to locations of other interpretable containers. The container 172 may leverage other containers to perform more complex functionality. With respect to the example of adjusting the language, the container 172 may reflect a modularized update to the language. The container 172 may reference one or more other containers which add functionality which is specific to, or commonly used by, persons who speak the updated language. The container 172 may also reference one or more other containers which have adjusted graphics or interface elements which are associated with the adjusted language. Similarly, referenced containers may themselves reference other containers such that the containers may be nested during execution.

[0077] More generally, the container 172 may add additional modularized functionality through reference to other containers. For example, the container 172 may cause execution of back-end functionality. The container 172 may include references to containers which present front-end visualizations associated with the output of the back-end functionality. In this way, the processor 170A may execute both back-end and front-end functionality. As may be appreciated, the referenced containers may be separately updatable such that the front-end visualizations may be updated in quality, complexity, and so on without affecting container 172.

[0078] The container 172 may additionally include other interpretable containers. For example, the container 172 may include text or code associated with back-end functionality. The container 172 may then include interpretable container(s) associated with front-end functionality. In some embodiments, the interpretable containers may be associated with a hierarchy. For example, when interpreting the container 172, the included interpretable containers may modify, or otherwise be subject to, the text or code in the container 172.

[0079] The container 172 may additionally include a byte record. An example byte record may include a video, sound or audio, image, and so on. For example, the container 172 may include a media file. In some embodiments, the container 172 may include a reference to a network location or storage location. For example, the processor 170A may retrieve the byte record or media file when interpreting the information included in the container 172. The processor 170A may additionally output one or more instructions that cause retrieval of the byte record or media file.

[0080] The container 172 may additionally include references to data. As an example, the data may reflect deep-learning parameters (e.g., weights, biases, and so on). For this example, interpretable container 172 may cause execution of a machine learning model which uses theparameters. As an example, the container 172 may include logic that defines the model. Example logic may include, with respect to a neural network, information defining layers, connections between the layers, and so on. For example, the container 172 may indicate that particular convolutional layers are included followed by particular fully-connected layers.

[0081] As will be described in Figure 6, execution of a machine learning model may include a confluence of a multitude of interpretable containers. Different portions of the machine learning model may be included in different interpretable containers. These interpretable containers may trigger access to other interpretable containers to enable inference or training of the model. Thus, complicated models (e.g., multi-modal models, multi-task models, mixture-of-experts (MoE) models, multi-gate mixture-of-experts (MMoE) models, and so on) may be implemented using interpretable containers.

[0082] Figure 2A is a block diagram of example processors 200A-200B interacting via an interpretable container 222. In the illustrated embodiment, processors 200A-200B may represent processors included in a same, or different, system. The processors 200A-200B may additionally represent processing cores of a same multicore processor. The processors 200A-200B may additionally represent virtualized processors. The processors 200A-200B may additionally represent processes executing on a system.

[0083] Processor A 200A, which may include one or more processors, includes an interpretation engine 210 and an execution engine 220. As described in Figure 1A, the interpretation engine 210 may interpret information included in interpretable containers and output instructions 212 associated with a programming language. In the illustrated embodiment, interpretation engine 210 is outputting instructions associated with programming language A. Similarly, processor B 200B, which may include one or more processors, includes an interpretation engine 230 and an execution engine 240. In the illustrated embodiment, interpretation engine 230 is outputting instructions 232 associated with programming language B.

[0084] Processor A 200A has determined that it is to execute particular functionality. For example, processor A 200A may be executing an application. In this example, and as described in Figure 1A, a user of the application may have interacted with an interface element which is associated with particular functionality. As another example, processor A 200A may be executing instructions associated with a first interpretable container. For this example, the first interpretable container may reference another interpretable container. As another example, theparticular functionality may be associated with a machine learning model or a portion thereof. For example, processor A 200A may determine that it is to obtain output from a machine learning model which is defined, at least in part, using an interpretable container. In this example, processor A 200A may configure, or otherwise instruct, additional processors (e.g., GPUs).

[0085] Processor A 200A may therefore generate a functionality request 222 for an interpretable container, or set of interpretable containers, associated with the particular functionality. In some embodiments, the request may indicate a unique ID or hash associated with an interpretable container. Processor B 200B may receive the request and provide a responsive interpretable container 242. For example, processor B 200B may obtain the container 242 from local or networked storage.

[0086] The interpretation engine 210 of processor A 200A may then interpret the information included in the interpretable container 242 to generate instructions 212. These instructions 212 may be executed by execution engine 220 to implement the particular functionality. In some embodiments, processor A 200A may cache or otherwise store the interpretable container 242 for further use or delete it after interpretation to free up memory if needed. In some embodiments, processor A 200A may cache or otherwise store the generated instructions 212. For example, the instructions 212 may be associated with container 242 such that the processor A 200A may rapidly implement the particular functionality (e.g., in the future).

[0087] Processor A 200A may additionally provide a request 224 to processor B 200B for a new interpretable container. As described herein, the request 224 may describe requested functionality, such as new logic, interface element, application or program functionality, and so on. In some embodiments, the request 224 may be provided as an interpretable container to interpretation engine 230. In response, interpretation engine 230 may interpret the request 224 and output instructions 232. These instructions 240 may enable execution engine 240 to generate a new interpretable container (e.g., container 242).

[0088] While the description above focused on processor A 200A obtaining interpretable container 242 from processor B 200B, in some embodiments processor A 200A may alone perform the functionality described in Figure 2A. For example, the same processor may determine functionality 222 which is to be performed. In this example, the processor may obtain (e.g., access) an interpretable container 242 which is associated with the functionality.Similarly, in some embodiments processor A 200A may generate interpretable container 242.

[0089] In some embodiments, processor A 200A may instruct processor B 200B to execute the interpretable container 242. For example, processor A 200A may provide a functionality request 222 which is associated with particular functionality. In this example, processor B 200B may obtain a responsive interpretable container 242 as described above. In contrast to the above, however, the request 222 may indicate that processor B 200B is to execute the container 242 (e.g., interpret the included information and execute resulting instructions 232). Processor B 200B may then provide results, or other output, associated with container 242 to processor A 200A.

[0090] Figure 2B is a block diagram of example processors 200A-200B interacting via an interpretable container based on a computation task 226. In some embodiments, processor A 200A may cause additional processors, such as processor B 200B, to perform a computation task 226. The computation task 226 may be described, or otherwise defined, in an interpretable container. For example, the computation task 226 may relate to processing of data which is referenced in the container.

[0091] Similar to the above, processor B 200B may interpret the information included in task 226. For example, interpretation engine 230 may output instructions 232 to execution engine 240. Results 244 associated with the task 244 may then be provided to processor A 200A. The computation task 226 may reference additional interpretable containers. For example, interpretation engine 230 may obtain, and interpret, these additional interpretable containers to generate instructions 232. In some embodiments, the interpretation engine 230 may determine that one or more additional interpretable containers are to be obtained. For example, the computation task 226 may describe complex processing which the engine 230 may implement through use of multiple interpretable containers. In some embodiments, the interpretable containers may be associated with metadata describing their functionality. In this way, the engine 230 may identify containers which will enable processing of the task 226.

[0092] Figure 2C is a block diagram of example processors 200A-200N executing subtasks based on a multitude of interpretable containers 252A-252D. As illustrated, processor(s) N 200N, which may include one or more processors, has separated a computation task into a multitude of sub-tasks. Processor(s) N 200N may then instruct processors 200A-200D to execute the sub-tasks. In some embodiments, processors 200A-200D may select from available sub-tasks to execute.

[0093] Individual sub-tasks may be included in individual interpretable containers 252A-252D. Thus, each processor may obtain an interpretable container and interpret the included information into instructions. Advantageously, the processors may use different programming languages, different platforms, and so on. Each processor may then execute its instructions to form partial results 254. Processor(s) N 200N may then aggregate the results 252 using, for example, a task aggregation engine 250. In this way, processor(s) N 200N may obtain a result (e.g., result information, such as a digital file) associated with the computation task. In some embodiments, the result of the computation task may include an interpretable container. For example, processor(s) bl 200N may trigger generation of a new interpretable container using processors 200A-200N. As described above, these processors may be included in a same system or in different systems. Thus, processor(s) M 200N may leverage processing power of different systems which may be connected to processor(s) N 200N via a network. And in its turn processor(s) N 200N may be part of a larger system that may leverage processing power of processors 200A-200N via processor(s) N 200N.

[0094] Processor N 200N may determine the size and composition of the sub-tasks based on an analysis of the computation task. For example, a computational task may have data dependencies such that it is separable in a particular way. As another example, a more complex (e.g., data intensive) computation task may benefit from a greater number of sub-tasks. Processor N 200N may additionally analyze computational resources associated with available processors. Thus, processors 200A-200D may represent available processors of a system or may represent processors which meet certain performance characteristics and altogether form a distributed network of processing resources. The ability to distribute computations across multiple systems and processors in various locations is invaluable in the Al-driven world, where the concentration of compute and energy resources in specific physical locations has become a significant challenge.Example Flowcharts

[0095] Figure 3 is a flowchart an example process 300 for executing functionality based on an interpretable container. For convenience, the process 300 will be described as being performed by a system of one or more processors. For example, the process 300 may be performed by system 100 or a system that includes one or more of processors 200A-200N.

[0096] At block 302, the system determines particular functionality to be executed based on an interpretable container. As described above, particular functionality may be based on execution of an application. For example, the application may be executed using one or more interpretable containers. In this example, the particular functionality may relate to functionality of the application which requires receipt of the interpretable container.

[0097] At block 304, the system accesses, or generates, the interpretable container. The system may obtain the interpretable from local or networked storage. For example, the container may be cached such that it was previously used by the system. The system may obtain the interpretable container from a different system, for example based on an ID or hash associated with the interpretable container.

[0098] In some embodiments, the system may include a first processor, or processors, which determines the particular functionality and a second processor, or processors, which obtains the interpretable container. For these embodiments, the second processor, or processors, may provide the interpretable container to the first processor or processors. In some embodiments, the first processor, or processors, may additionally trigger or otherwise instruct the second processor, or processors, to execute the particular functionality based on the interpretable container.

[0099] At block 306, the system causes execution of the particular functionality based on interpretation of information included in the interpretable container. As described herein, the sy stem may interpret the information into instructions for execution. These instructions may be executed by the system to enable the particular functionality.

[0100] Figure 4 is a flowchart of an example process 400 for updating a user interface associated with an application based on an interpretable container. For convenience, the process 400 will be described as being performed by a system of one or more processors. For example, the process 400 may be performed by system 100 or a system that includes one or more of processors 200A-200N.

[0101] At block 402, the system causes presentation of a user interface associated with an application. For example, Figures 1 A- IB illustrate an example user interface. The application may include, or be formed from, a multitude of interpretable containers. Thus, execution of the application may be based on interpreting the interpretable containers into instructions.

[0102] At block 404, the system responds to selection of an interactive element. The system may receive user input indicating the selection, for example a user may provide the userinput to the user interface. The system may then trigger a request for an interpretable container associated with the interactive element. For example, the system may not have access to functionality associated -with updating the user interface based on the selection.

[0103] The request may identify the interactive element (e.g., a unique ID), such that an associated interpretable container is identifiable. Optionally, the request may include an identifier associated with a user of the system. In this way, the user’s setings, or preferences, may be used to obtain the interpretable container. For example, there may be a multitude of versions of the interpretable container. In this example, a particular container which matches the user’s settings or preferences may be obtained.

[0104] At block 406, the system interprets an obtained interpretable container into instructions associated with a particular programming language. For example, the programming language may be associated with a programming language of the user interface or application. In some embodiments, the interpretable container may be indicative of high-level interface adjustments and the instructions may include discrete instructions to effectuate the high-level interface adjustments.

[0105] At block 408, the system updates the user interface in accordance with selection of the interactive element. As described above, the system executes the instructions to cause updating of the user interface. In this way, the application may be substantially more lightweight than using existing techniques. For example, the application may obtain modularized functionality based on actual need for the functionality.

[0106] Figure 5 is a flowchart of an example process 500 for transmiting a new interpretable container responsive to a request for custom functionality. For convenience, the process 500 will be described as being performed by a system of one or more processors. For example, the process 500 may be performed by system 100 or a system that includes one or more of processors 200A-200N.

[0107] At block 502, the system receives a request for a new interpretable container. As described above, the request may be associated with custom functionality or custom adjustment of an application. In some embodiments, the request may be included in an interpretable container.

[0108] At block 504, the system interprets the interpretable container into instructions. For example, a first processor of the system may provide the request, and a second processor may interpret the request into instructions. As another example, the system may receive the requestfrom an outside system (e.g., a mobile device, a laptop, and so on). As another example, a first processor of the system may generate, and interpret, the request into instructions.|001091 At block 506, the system generates a new interpretable container. The request may include, for example, a description of the custom functionality. As an example, the description may reflect high-level user interface adjustments. As another example, the description may reflect logic associated with particular processing to be performed. The system may generate information for inclusion in the new interpretable container which, when interpreted into instructions, causes performance of the custom functionality. In some embodiments, the system may leverage a machine learning model which is trained to translate between a request and a resulting interpretable container.

[0110] At block 508, the system transmits the new interpretable container. For example, the system may transmit the new interpretable container to an outside system (e.g., a mobile device, a laptop, and so on). As another example, the system may transmit the new interpretable container to a particular processor of the system. In some embodiments, a same processor which generated the request may execute the new interpretable container.Example Block Diagram - Artificial Intelligence (Al)

[0111] Figure 6 is a block diagram illustrating use of interpretable containers for artificial intelligence, such as use of interpretable containers for inference and training. As described above, interpretable containers may be used to modularize, or otherwise separate, portions of complex Al models. For example, a computer vision model may be a multi-task learning model which outputs a multitude of information (e.g., different output tensors). In this example, different outputs may be implemented using different interpretable containers. Examples of Al models which can be implemented using interpretable containers is described below,

[0112] In various embodiments, interpretable containers that participate in artificialintelligence workloads may declare an operation mode that tire interpreter may honor at execution time. The operation mode identifies whether execution is to (i) perform inference using a stored parameterization, (ii) perform one or more training updates to a stored parameterization, or (iii) orchestrate a sequence or graph of other containers that together realize an Al pipeline, The same container artifact can therefore be invoked for different phasesof model use, with the interpreter selecting an execution path in view of the declared mode and the available compute resources.100113 ] While multiple different realizations of the same are possible, the example Al model 600 described in Figure 6 that uses the interpretable containers techniques may include but is not limited to a number of various fimctionalities of the Al model 600 such as a distributing model 602, a verifying model 618, a classifying model 612, expert models 610A-610N. Each of those functionalities may represent an interpretable container which may include, or reference, interpretable containers, each of which can, in turn, include or reference additional levels of containers, thereby creating multiple nested layers (e.g., in accordance with, or otherwise similar to, the matryoshka principle). Optionally, the Al model 600 or any of its functionalities may operate as an application that also incorporates or references interpretable containers, potentially including numerous additional levels of containers, enhancing its complexity and functionality. For the sake of simplicity, the Figure 6 refers to containers A-N as the lowest level; however, containers A-N could be understood as containers of any level within the structure.

[0114] The Al model 600 may be decomposed into subparts that are each expressed as an interpretable container with explicit interface contracts. By way of example and without limitation, subparts can include data ingestion and preprocessing, tokenization or feature extraction, encoder and decoder blocks, attention or gating components, loss and metric computation, optimization steps, post-processing, and evaluation. Each subpart container declares required inputs and produced outputs (e.g., tensor shapes, dtypes, serialization schema) and a binding to persistent parameters, enabling independent update, rollback, or replacement of any subpart without code changes to the remaining subparts.

[0115] In some embodiments, orchestration containers may specify’ a directed acyclic graph of subpart containers and define routing behavior among al ternative paths. For instance, a routing policy may first invoke a lightweight classifier to select among expert containers and subsequently combine expert outputs using a verifier container that enforces consistency constraints. Because the graph is described in the container’s metadata, the interpreter schedules subparts across heterogeneous processors while preserving subpart isolation and deterministic interfaces.

[0116] In some embodiments, subparts correspond to distinct functionalities of the Al model or Al system. A distributing or gating subpart allocates requests among expert subparts;a verifying subpart evaluates candidate outputs and can request re-execution with modified inputs; and task-specific expert subparts generate intermediate or final predictions. These functionalities are realized as separate containers that interact through the declared interfaces and through parameter stores referenced by stable identifiers, thereby enabling concurrent execution, pipelining, and partial recomputation.

[0117] In some embodiments, the subparts may be implemented using different software paradigms while remaining interoperable through the container abstraction. In some embodiments, one or more subparts is a generative model (e.g., a large language model acting as a code -synthesis or reasoning component), one or more subparts is a conventional machinelearning model (e.g., a gradient-boosted tree for routing or a convolutional block for feature extraction), and one or more subparts is a rule-based algorithm (e.g., schema validation, constraint enforcement, or safety filtering). Because each paradigm is encapsulated in its own container with a declared interface and parameter bindings, the system combines generative, learning-based, and rule-based functionalities within a single Al pipeline and permits any subpart to be updated or replaced independently.

[0118] In the example Al model 600, the distributing model 602 is depicted as including example interpretable containers (e.g., containers A-N). The distributing model 602 may represent an interpretable container which may include, or reference, containers A-N. Optionally, the model 602 may represent an application which may include containers A-N. The distributing model 602 may receive a request 604, for example from a user, and may distribute the request to all, or a subset of, expert models A-N 610A-610N. In another example the distributing model 602 may receive the request, analyze it, break it down to subtasks and distribute subtasks between expert models A-N 610A-610N for producing quality output (e.g. output 606).

[0119] The request 604 may include, or reference, input data which is to be used in the Al model. The distributing model 602 may determine which expert models 610A-610N are to be used to service the request 604. For example, the model 602 may implement a gating function which takes the input data and determines weightings associated with the experts. As described herein, the model 602 may use one or more of the containers A-N to effectuate the distribution. For example, interpretable container A may be used to analyze the request and break it down into a number of smaller subtasks. As another example, interpretable container B may be used to find optimal experts for each subtask. As another example, interpretable container C may be used to approach the classifying model 612 (e.g. its container C as described below in moredetails for classifying model 612) to create a new expert model or a new container A-N within the existing expert models 610A-610N. As another example, interpretable container D may be used to compute the gating function and distribute subtasks to respective experts. As another example, interpretable container E may be used to compile the output and respond to the request.

[0120] The distributing model 602 may trigger execution of some, or all, of the expert models A-N 610A-610N. For example, the expert models 610A-610N may obtain the input data. In this example, the distributing model 602 may reference a location of the input data (e.g., network location). The expert models 610A-610N may then compute output, for example using associated interpretable containers. As one example, expert model 610A may be defined using layers of a neural network. The expert model 610A may be executed using an associated interpretable container which may define the layers and / or the logic associated with the model 610A, As illustrated, the expert model 610Amay include interpretable containers which may work together to effectuate computation through the model 610A. In some implementations responses of expert models may go through the verifying model 618 (e.g., either through the distributing model 602 or directly from expert models 610A-620N) which may initiate error correction process if needed.

[0121] For example, the interpretable containers may define portions of the model 610A (e.g. portions of the layers) and include references to data, such as parameters (e.g., weights, biases), used in the defined portions. The interpretable containers may be interpreted, for example by a processor or processors, and instructions to implement the model 610A may be executed. As described above, the instructions may cause processing of tire model to be performed using GPUs. For example, execution of one of the interpretable containers may trigger instructions to GPUs to obtain the above-described input data, parameter data, and compute a forw ard pass through a portion of the model 610A. The interpretable container may additionally specify a location (e.g., a network location) associated with where to store the output through the portion. Thus, the output may be provided as input to a subsequent portion of the model 610A (e.g., defined by a different interpretable container).

[0122] In this way, processing through the expert models 610A-610N may be performed over arbitrary'- distances and over an arbitrary number of systems. Tire interpretable containers may reference a location of input data to be used, a location of parameters to be used, the logic to be used in processing, and a location of output data. In this way, the interpretable containers may trigger execution of other interpretable containers to process a forward pass through an arbitrarily complex model.

[0123] Thus, output 606 associated with the request 604 may be provided by distributing model 602. For example, the output 606 may be provided to a user device associated with a user. The output 606 may also be provided as a result of a computation task. For example, a user device executing an application may trigger a computation task associated with the distributing model. In this example, the user device may be executing an interpretable container which triggers the computation task.

[0124] Figure 6 additionally includes the classifying model 612 and the verifying model 618. By way of example, the classifying model 612 may be used for training of the expert models 610A-610N. For example, the classifying model 612 may represent an interpretable container that determines classes of data, controls training of the expert models A-N 610A-610N, and / or creates new expert models. Similar to the above, training of the expert models A-N 610A-610N may be performed modularly, such as through use of interpretable containers.

[0125] As an example, an interpretable container may include a location of input data to be used for training at least a portion of a model. The interpretable container may also include a location of parameters associated with the portion, logic to be used in processing, and a location of output data. When training, and as an example, gradient descent may be used. Thus, the parameters may be updated using gradients which are passed downstream through the models. Advantageously, the training may be performed using an arbitrary number of processors or systems which are spread over arbitrary distances.

[0126] As described herein, for training, an interpretable container can specify’ one or more of dataset sources, batching and sharding policy, augmentation pipelines, optimizer configuration, learning-rate scheduling, mixed-precision settings, and checkpoint cadence. Gradients produced within a compute subpart may be propagated to parameter subparts using the declared interfaces, and parameter updates are committed atomically to the referenced parameter store. For inference, a container can specify decoding procedures (e.g., greedy, beam search, temperature-controlled sampling), non-maximum suppression, calibration, or other post-processing as nested sub-containers, permitting the same model topology to be executed with different decoding policies by substituting the relevant container.

[0127] As mentioned above the classifying model 612 (for example interpretable container C of the model’s 612 containers A-N) may also be responsible for creation of new expert models or new containers within containers A-N of the existing expert models 610A-610N. For example, creation may be based on situations in which there is no appropriate expertavailable within the system to resolve certain task. In this situation, the classifying model 612 may automatically initiate the training of newly created expert model or new interpretable container within the existing expert model by deriving data from internet network, structuring datasets and perform the training.

[0128] In some embodiments, in distributed settings, the interpreter (e.g., interpretation engine 150 described herein) can instantiate multiple replicas of a training or inference container, assign replicas to heterogeneous accelerators, and coordinate parameter synchronization using the parameter bindings declared in the containers. Replicas may exchange interface-conformant messages (e.g., minibatch tensors, gradients, metrics), which enable elastic scaling and fault isolation without exposing application memory or requiring monolithic model code on any single node.

[0129] Additionally, in some implementations the classifying model 612, (e.g. its interpretable container D) may actively manage memory utilization to ensure optimal memory availability. This can be achieved by reducing the size of the least frequently used expert models 610A-610N or their corresponding sub-expert interpretable containers A-N either by retraining them on smaller datasets or by deleting infrequently accessed or unused containers from memory. This proactive memory management may not only free up essential space for other operations but also enhance the overall efficiency of the system.

[0130] The verifying model 618 may be used, as an example, verify training processes and / or response accuracy. For example, the verifying model 618 may be used to verify correctness of response received from certain expert (e.g., to reveal hallucinations, for fact checking, to test generated code and so on) and return result to distributing model 602 or to expert models directly for correction if needed. The model 618 may additionally trigger updates to training. For example, the model 618 may trigger updated training based on receipt of information from a user indicating the output 606 was inaccurate. The verifying model 618 may enable this functionality using different interpretable containers (e.g., interpretable containers A-N).

[0131] In certain implementations the distributing model 602, the classifying model 612, the verifying model 618, the expert models 610A-610N or any other functionality within an Al system based on interpretable containers and their respective containers A-N may be represented by various software structures, including any type of Al models (LLM, ML and so on) or rule-based algorithms. This flexibility enables such hybrid Al systems to leverage thedistinct advantages of each approach, effectively addressing specific types of tasks.

[0132] Thus, modular Al systems, for example as described herein, may significantly improve computational efficiency, memory usage, and energy consumption by activating, in some embodiments, only the necessary modules (e.g., interpretable containers) during training or inference and distributing computations across multiple processing units. This selective activation may not only optimize resource use but also enhance flexibility, allowing for seamless scaling and adaptability in complex environments. Additionally, when designed and executed with interpretable containers these systems may offer higher performance and reliability, especially in multimodal contexts, as they enable more targeted and accurate training among specialized experts or modalities and employ optimal software solutions for each specific task as described above.Other Embodiments

[0133] All of the processes described herein may be embodied in, and fully automated, via software code modules executed by a computing system that includes one or more computers or processors. The code modules may be stored in any type of non -transitory’ computer-readable medium or other computer storage device. Some or all the methods may be embodied in specialized computer hardware.

[0134] Many other variations than those described herein will be apparent from this disclosure. For example, depending on the embodiment, certain acts, events, or functions of any of the algorithms described herein can be performed in a different sequence or can be added, merged, or left out altogether (for example, not all described acts or events are necessary for the practice of the algorithms). Moreover, in certain embodiments, acts or events can be performed concurrently, for example, through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially. In addition, different tasks or processes can be performed by different machines and / or computing systems that can function together.

[0135] The various illustrative logical blocks, modules, and engines described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a processing unit or processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, orany combination thereof designed to perform the functions described herein. A processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor may also include primarily analog components. For example, some or all of the signal processing algorithms described herein may be implemented in analog circuitry or mixed analog and digital circuitry. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.

[0136] Conditional language such as, among others, "‘can,” ‘"could,” “might” or “may,” unless specifically stated otherwise, are understood within the context as used in general to convey that certain embodiments include, while other embodiments do not include, certain features, elements and / or steps. Thus, such conditional language is not generally intended to imply that features, elements and / or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and / or steps are included or are to be performed in any particular embodiment.

[0137] Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (for example, X, Y, and / or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

[0138] Any process descriptions, elements or blocks in the flow diagrams described herein and / or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or elements in the process. Alternate implementationsare included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown, or discussed, including substantially concurrently or in reverse order, depending on the functionality involved as would be understood by those skilled in the art.

[0139] Unless otherwise explicitly stated, articles such as “a” or “an” should generally be interpreted to include one or more described items. Accordingly, phrases such as “a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations. For example, “a processor configured to carry out recitations A, B and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

[0140] It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. All such modifications and variations are intended to be included herein within the scope of this disclosure.

Claims

WHAT IS CLAIMED IS:

1. A method implemented by a system of one or more processors, the method comprising:determining particular functionality to be executed, wherein the particular functionality is configured to be executed based on an interpretable container, the interpretable container including, at least, information configured for interpretation into instructions associated with one or more programming languages, and wherein the instructions enable execution of the particular functionality;accessing, or generating, the interpretable container, and wherein to generate the interpretable container the system is configured to generate information that can be interpreted into instructions associated with one or more programming languages; andcausing execution of the particular functionality based on interpretation of the information included in the interpretable container.

2. The method of claim 1, wherein the particular functionality forms part of a computer program, and w'herein execution of the computer program is based on a plurality of interpretable containers.

3. The method of claim 2, wherein individual interpretable containers are configured to use dedicated storage associated with the system, and wherein to use dedicated storage the individual interpretable containers are configured to use the dedicated storage as access memory and / or for exchange of data to enable execution of the computer program.

4. The method of claim 2, wherein the system includes a plurality of processors, wherein a first subset of the processors determines the particular functionality, and wherein a second subset of the processors executes the computer program.

5. The method of claim 4, wherein the second subset of the processors is configured to access or generate the interpretable containers.

6. The method of claim 4, wherein the first subset of the processors transmits a first subset of the interpretable containers to the second subset of the processors for execution or wherein the second subset of the processors transmits execution results in the form of a second subset of the interpretable containers and / or byte arrays to the first subset of the processors.

7. The method of claim 1, wherein one or more of the system’s processors are configured, based on respective memories of the processors, to interpret the information included in the interpretable container and execute the particular functionality based on the interpretation.

8. The method of claim 1, wherein the interpretable container is configured to be run on or configure an operational environment specific for execution of the particular functionality.

9. The method of claim 1, wherein the interpretable container use a particular framework configured to enable execution of the particular functionality, wherein the particular framework includes one or more code libraries.

10. The method of claim 1, wherein a same processor of the one or more processors is configured to determine the particular functionality, access or generate the interpretable container, and interpret information included in the interpretable container.

11. The method of claim 1, wherein interpreting of information included in the interpretable container into instructions associated with one or more programming languages is performed by a rule-based program or an Al model trained for the task,12. The method of claim 1, wherein at least some processors of the one or more processors are virtual processors.

13. The method of claim 1, wherein individual processors of the one or more processors are individual processing cores of a multicore processor.

14. The method of claim 1, wherein the information included in the interpretable container represents text or code that can be interpreted into instructions associated with the one or more programming languages.

15. The method of claim 1, wherein the interpretable container or the information included in the interpretable container includes a description or an input format and / or an output format of the particular functionality.

16. The method of claim 1, wherein the information included in the interpretable container includes a different interpretable container or a reference to a different interpretable container or a byte record.

17. The method of claim 16, wherein the reference is a web address or a directory path to the interpretable container.

18. The method of claim 16, wherein the byte record reflects video or sound content.

19. The method of claim 1, wherein the one or more processors include at least a first processor and a second processor, and wherein the first processor determines the particular functionality followed by:a request addressed to the second processor to provide the interpretable container, ora task addressed to the second processor, the task being to execute the interpretable container.

20. The method of claim 19, wherein the request to provide the interpretable container comprises a request to access or generate the interpretable container associated with the particular functionality.

21. The method of claim 19, wherein either of the request or the task is included in the interpretable container or includes the interpretable container.

22. The method of claim 19, wherein the request or the task includes a unique identifier or location information associated with the interpretable container.

23. The method of claim 19, wherein the request or the task includes a description of the interpretable container and wherein the system accesses or generates the interpretable container based on the description.

24. The method of claim 19, wherein the first or the second processor executes the particular functionality.

25. The method of claim 19, wherein the second processor transmits the interpretable container to the first processor responsive to the request, or wherein the second processor transmits results associated with execution of the particular functionality to the first processor.

26. The method of claim 1, wherein interpreting comprises transpiling.

27. The method of claim 1, wherein accessing the interpretable container comprises accessing the interpretable container from storage.

28. The method of claim 27, wherein the interpretable container is cached.

29. The method of claim 1, wherein accessing the interpretable container comprises accessing the interpretable container from a network location.

30. The method of claim 1, wherein generating the interpretable container comprises generating information configured for interpretation into instructions associated with one or more programming languages, and wherein the instructions enable execution of the particular functionality.

31. The method of claim 1, wherein execution of the particular functionality is caused by execution of instructions associated with one or more programming languages derived from interpretation of the information included in the interpretable container.

32. The method of claim 1, wherein accessing or generating the interpretable container is based on an identifier associated with a user and / or based on the description of the interpretable container.

33. The method of claim 32, wherein the interpretable container is customized based on settings identified by, or preferable to, the user.

34. The method of claim 1, further comprising:configuring one or more additional processors to interpret the information included in the interpretable container and / or execute the particular functionality based on interpretation of the information included in the interpretable container.

35. The method of claim 1, wherein the one or more processors include a plurality of processors, wherein the particular functionality reflects a computation task, wherein the system isconfigured to generate subsets of the computation task, and wherein the subsets are configured for execution by the processors of the system.

36. The method of claim 35, wherein a first processor of the processors is configured to execute a first subset of the generated subsets, and wherein a second processor of the processors is configured to execute a second subset of the generated subsets.

37. The method of claim 35, wherein the computation task is a computational task within an application which is executable by the system.

38. The method of claim 35, wherein a subset of the computation task is included in or includes the interpretable container.

39. The method of claim 38, wherein the one or more processors of the system receives or calls additional interpretable containers for execution.

40. The method of claim 35, wherein to generate the subsets of the computation task the system determines number, size and composition of the subsets based on an analysis of the computation task and / or computational resources associated with the processors of the system.

41. The method of claim 35, wherein the system is configured to execute the subsets of computation task, collect execution results for each subset and generate result of the computation task based on the execution results of the subsets.

42. The method of claim 41, wherein the execution result of the subset and / or the result of the computation task includes a particular interpretable container or a byte array.

43. The method of claim 1, wherein the particular functionality is associated with training an artificial intelligence (Al) model or inference of the Al model or running of an Al system associated with the Al model.

44. The method of claim 43, wherein the Al model or the Al system includes one or more subparts configured as interpretable containers.

45. The method of claim 44, wherein individual subparts are associated with individual functionalities of the Al model or the Al system.

46. The method of claim 45, wherein the individual functionalities of the Al system are represented by one or more of the generative Al model, a machine learning (Al) model, or a rulebased algorithm.

47. The method of claim 44, wherein a particular subpart of the one or more subparts includes one or more interpretable containers.

48. The method of claim 43, wherein the training or the inference comprises execution of at least a subset of the subparts.

49. A system comprising one or more processors and non-transitory computer storage media storing instructions that when executed by the one or more processors, cause the one or more processors to perform the method of claims 1-48.

50. A method implemented by a user device of one or more processors, the method comprising:causing presentation of an interactive user interface associated with an application, wherein the interactive user interface:presents one or more interactive elements, and responds to selection of a particular interactive element, wherein the selection triggers a request for an interpretable container,wherein the interpretable container includes, at least, information configured for interpretation into instructions associated with one or more programming languages,and wherein the instructions are associated with updating the interactive user interface based on the particular interactive element; obtaining, the interpretable container, wherein the information included in the interpretable container is interpreted into instructions associated with a programming language of the interactive user interface; andupdating the interactive user interface based on the instructions associated with the programming language of the user interface, wherein the updated interactive user interface updates in accordance with selection of the particular interactive element.

51. The method of claim 50, wherein the application includes at least one interpretable container.

52. The method of claim 50, wherein prior to receipt of the selection of the particular interactive element, the application does not have instructions associated with updating in accordance with the selection.

53. The method of claim 50, wherein the particular interactive element is associated with one or more identifiers assigned to the interpretable container, and wherein the request includes the one or more identifiers.

54. The method of claim 53, wherein the one or more identifiers include a particular identifier associated with a user of the user device.

55. The method of claim 50, wherein the interpretable container is associated with a user of the user device, and wherein the interpretable container is customized based on settings identified by, or preferable to or assigned to the user.

56. The method of claim 50, wherein at least some of the instructions included in the interpretable container are indicative of interface adjustments to the interactive user interface.

57. The method of claim 50, wherein the interpretable container is indicative of high-level interface adjustments, and wherein the instructions include discrete instructions to effectuate the high-level interface adjustments.

58. The method of claim 50, wherein at least some of the instructions included in the interpretable container cause execution of logic or processing by the user device.

59. The method of claim 50, wherein the interpretable container references one or more media files.

60. The method of claim 59, wherein the one or more media files are included in information of the interpretable container.

61. The method of claim 59, wherein the one or more media files are received via network locations specified in the interpretable container.

62. The method of claim 50, wherein interpreting comprises transpiling into the instructions associated with the programming language.

63. The method of claim 50, wherein the interpreter is a transcompiler.

64. The method of claim 50, wherein interpreting is based on application of a neural network.

65. The method of claim 50, further comprising:obtaining information from the user device describing features for inclusion in the application, wherein a second interpretable container is generated based on the obtained information; andobtaining the second interpretable container to cause adjustment of the application.

66. The method of claim 65, wherein the information is indicative of high-level interface adjustments, and wherein the second interpretable container effectuates the high-level interface adjustments,67. A system comprising one or more processors and non-transitory computer storage media storing instructions that when executed by the one or more processors, cause the one or more processors to perform the method of claims 50-66.

68. A system comprising one or more processors and non-transitory computer storage media storing instructions that when executed by the one or more processors, cause the one or more processors to perform operations comprising:determining particular functionality to be executed, wherein the particular functionality is configured to be executed based on an interpretable container, the interpretable container including, at least, information configured for interpretationinto instructions associated with one or more programming languages, and wherein the instructions enable execution of the particular functionality;accessing, or generating, the interpretable container, and wherein to generate the interpretable container the system is configured to generate information that can be interpreted into instructions associated with one or more programming languages; andexecuting the particular functionality based on interpretation of the information included in the interpretable container.

69. The system of claim 68, wherein the operations performed by the one or more processors further comprise transmitting the interpretable container to other one or more of the system’s processors.

70. The system of claim 68, wherein at least some of the processors are virtual processors.

71. The system of claim 68, wherein individual processors of the one or more processors are individual processing cores of a multicore processor.

72. The system of claim 68, wherein the one or more processors include at least a first processor and a second processor, and wherein the first processor determines the particular functionality followed by:a request addressed to the second processor to provide the interpretable container, ora task addressed to the second processor, the task being to execute the interpretable container.

73. The system of claim 72, wherein the first or the second processor executes the particular functionality.

74. The system of claim 68, wherein the system is configured to set up one or more additional processors to interpret the information included in the interpretable container and / or execute the particular functionality based on interpretation of the information included in the interpretable container.

75. The system of claim 68, wherein the one or more processors include a plurality of processors, wherein the particular functionality reflects a computation task, wherein the system is configured to generate subsets of the computation task, and wherein the subsets are configured as or include the interpretable containers for execution by the processors of the system.

76. The system of claim 75, wherein a first processor of the processors is configured to execute a first subset of the generated subsets, and wherein a second processor of the processors is configured to execute a second subset of the generated subsets.

77. The system of claim 75, wherein the one or more processors of the system receives or calls interpretable containers from the system for execution.

78. The system of claim 75, wherein to generate the subsets of the computation task the system determines number, size and composition of the subsets based on an analysis of the computation task and / or computational resources associated with the processors of the system.

79. The system of claim 75, wherein the system is configured to execute the subsets of computation task, collect execution results for each subset and generate result of the computation task based on the execution results of the subsets.