Versioning of digital artifacts for collaborative workflows in digital model platforms

Abstract

Systems and methods for versioning digital resources and recording a snapshot of a system configuration on a digital model platform are disclosed. Hie methods include steps to: receive a request to generate the snapshot of the system configuration that defines a state of a file system. The file system comprises resource files, the system configuration references tracked files, and each tracked file identifies a revision of a resource file. Identify, for each tracked file, a corresponding file revision of a corresponding resource file. Generate snapshot data items at a time of snapshot generation. A snapshot data item is generated for each identified file revision to represent a binding of the identified file revision to the snapshot. Lastly, record, at the time of snapshot generation, the snapshot data items as the snapshot, where the snapshot represents the state of the file system at the time of snapshot generation.

Description

[0001] Docket No. IST-03.012PCT

[0002] Versioning of Digital Artifacts for Collaborative Workflows

[0003] in Digital Model Platforms

[0004] Reference to Related Applications

[0005] If an Application Data Sheet (“ADS7’) or PCT Request Form (“Request”) has been filed on the filing date of this application, it is incorporated by reference herein. Any applications claimed on the ADS or Request for priority under 35 U.S.C. §§119, 120, 121, or 365(c), and any and all parent, grandparent, great-grandparent, etc., applications of such applications, are also incorporated by reference, including any priority claims made in those applications and any material incorporated by reference, to the extent such subject matter is not inconsistent herewith.

[0006] Furthermore, this application is related to the U.S. patent applications listed below, which are incorporated by reference in their entireties herein, as if fully set forth herein:

[0007] • PCT application No. PCT / US24 / 61606 (Docket No. IST-03.008PCT), filed on December 21, 2024, entitled “Alternative Digital Tool Selection and Optimization in Digital Model Platforms, ” relates to digital tool selection and usage..

[0008] • PCT application No. PCT / US24 / 58547 (Docket No. IST-04.001PCT), filed on December 4. 2024, entitled “Data Sovereignty Assurance for Artificial Intelligence (Al) Models f relates to data sovereignty assurance during Al model training and evaluation.

[0009] • PCT application No. PCT / US24 / 49149 (Docket No. IST-02.006PCT), filed on September 28, 2024, entitled “Artificial Intelligence (Al) Assisted End-to-End Workflow Integration for Software Development in Digital Model Platforms f describes workflow integration with Al-assistance. • PCT application No. PCT / US24 / 47434 (Docket No. IST-03.010PCT), filed on September 19, 2024, entitled “Platform-Enabled Orchestration and Optimization of Digital Workflows ,” describes digital workflow optimization.

[0010] • PCT application No. PCT / US24 / 44938 (Docket No. IST-03.006PCT), filed on September 1, 2024 entitled “Multimodal Digital Document Interfaces for Dynamic and Collaborative Reviews,” describes interface enhancement for digital software platforms.

[0011] • PCT application No. PCT / US24 / 42768 (Docket No. IST-02.004PCT), filed on August 16. 2024, entitled “Artificial Intelligence (Al) Assisted Automation of Testing in Software Environments,” describes workflow enhancement for digital softw are platforms.

[0012] • PCT application No. PCT / US24 / 40624 (Docket No. IST-03.003PCT), filed on August 1, 2024, entitled “Machine Learning Engine for Workflow Enhancement in Digital Workflows f describes workflow enhancement for digital software platforms.Docket No. IST-03.012PCT

[0013] • PCT application No. PCT / US24 / 40468 (Docket No. IST-03.004PCT), filed on July 31, 2024, entitled “Multimodal User Interfaces for Interacting with Digital Model Files,” describes multimodal user interfaces for digital software platforms.

[0014] • PCT application No. PCT / US24 / 38878 (Docket No. IST-03.002PCT), filed on July 19, 2024, entitled “Generative Artificial Intelligence (Al) for Digital Workflows,” describes efficient Al-assisted script generation methods that preserve customer data sovereignty.

[0015] • PCT application No. PCT / US24 / 35885 (Docket No. IST-02.002PCT), filed on June 27, 2024, entitled “Artificial Intelligence (Al) Assisted Integration of New Digital Model Types and Tools into Integrated Digital Model Platform,” describes the enhancement of model splicer technology through Al-assistance.

[0016] • PCT application No. PCT / US24 / 27912 (Docket No. IST-02.003PCT), filed on May 5, 2024, entitled “Secure and Scalable Sharing of Digital Engineering Documents.” describes secure and scalable document splicing technology.

[0017] • PCT application No. PCT / US24 / 27898 (Docket No. IST-03.001PCT), filed on May 4, 2024, entitled “Digital Twin Enhancement using External Feedback within Integrated Digital Model Platform,” describes digital and physical twin management and the integration of external feedback within a DE platform.

[0018] • PCT application No. PCT / US24 / 19297 (Docket No. 1ST-01.002PCT). filed on March 10. 2024, entitled “Software-Code-Defined Digital Threads in Digital Engineering Systems with Artificial Intelligence (Al) Assistance.” describes Al-assisted digital threads for digital engineering platforms.

[0019] • PCT application No. PCT / US24 / 18278 (Docket No. IST-02.001PCT), filed on March 3, 2024, entitled “Secure and Scalable Model Splicing of Digital Engineering Models for Software-Code-Defined Digital Threads,” describes model splicing for digital engineering platforms.

[0020] • PCT application No. PCT / US24 / 14030 (Docket No. IST-01.001PCT), filed on February 1, 2024, entitled “Artificial Intelligence (Al) Assisted Digital Documentation for Digitcd Engineering,” describes Al-assisted documentation for digital engineering platforms.

[0021] • U.S. provisional patent application No. 63 / 442.659 (Docket No. IST-01.001P), filed on February 1, 2023, entitled “AI-Assisted Digital Documentation for Digital Engineering with Supporting Systems and Methods,” describes Al-assistance tools for digital engineering (DE), including modeling and simulation applications, and the certification of digitally engineered products.Docket No. IST-03.012PCT

[0022] • U.S. provisional patent application No. 63 / 451,545 (Docket No. IST-01.002P), filed on March 10, 2023, entitled “Digital Threads in Digital Engineering Systems, and Supporting AI-Assisted Digital Thread Generation," describes model splicer and digital threading technology.

[0023] • U.S. provisional patent application No. 63 / 451,577 (Docket No. IST-02.001P1), filed on March 11, 2023, entitled “Model Splicer and Microservice Architecture for Digital Engineering," describes model splicer technology.

[0024] • U.S. provisional patent application No. 63 / 462,988 (Docket No. IST-02.001P2), filed on April 29, 2023, also entitled “Model Splicer and Microservice Architecture for Digital Engineering," describes model splicer technology.

[0025] • U.S. provisional patent application No. 63 / 511,583 (Docket No. IST-02.002P), filed on June 30, 2023, entitled “AI-Assisted Model Splicer Generation for Digital Engineering." describes model splicer technology with Al-assistance.

[0026] • U.S. provisional patent application No. 63 / 516,624 (Docket No. IST-02.003P), filed on July 31, 2023, entitled “Document and Model Splicing for Digital Engineering," describes document splicer technology.

[0027] • U.S. provisional patent application No. 63 / 520,643 (Docket No. IST-02.004P), filed on August 20, 2023, entitled “Artificial Intelligence (AI)-Assisted Automation of Testing in a Software Environment," describes software testing with Al-assistance.

[0028] • U.S. provisional patent application No. 63 / 590,420 (Docket No. IST-02.005P), filed on October 14, 2023, entitled “Commenting and Collaboration Capability within Digital Engineering Platform," describes collaborative capabilities.

[0029] • U.S. provisional patent application No. 63 / 586,384 (Docket No. IST-02.006P), filed on September 28, 2023. entitled “Artificial Intelligence (AI)-Assisted Streamlined Model Splice Generation. Unit Testing, and Documentation," describes streamlined model splicing, testing and documentation with Al-assistance.

[0030] • U.S. provisional patent application No. 63 / 470,870 (Docket No. IST-03.001P), filed on June 3, 2023, entitled “Digital Twin and Physical Twin Management with Integrated External Feedback within a Digital Engineering Platform," describes digital and physical twin management and tire integration of external feedback within a DE platfonn.

[0031] • U.S. provisional patent application No. 63 / 515,071 (Docket No. IST-03.002P), filed on July 21, 2023, entitled “Generative Artificial Intelligence (Al) for Digital Engineering," describes an Al-enabled digital engineering task fulfillment process within a DE software platform.Docket No. IST-03.012PCT

[0032] • U.S. provisional patent application No. 63 / 517,136 (Docket No. IST-03.003P), filed on August 2, 2023, entitled "Machine Learning Engine for Workflow Enhancement in Digital Engineering.' describes a machine learning engine for model splicing and DE script generation.

[0033] • U.S. provisional patent application No. 63 / 516,891 (Docket No. IST-03.004P), filed on August 1, 2023, entitled "Multimodal User Interfaces for Digital Engineering,” describes multimodal user interfaces for DE systems.

[0034] • U.S. provisional patent application No. 63 / 580,384 (Docket No. IST-03.006P), filed on September 3, 2023, entitled “Multimodal Digital Engineering Document Interfaces for Certification and Security Reviews,” describes multimodal user interfaces for certification and security reviews.

[0035] • U.S. provisional patent application No. 63 / 613,556 (Docket No. IST-03.008P), filed on December 21, 2023. entitled “Alternative Tool Selection and Optimization in an Integrated Digital Engineering Platform.” describes tool selection and optimization.

[0036] • U.S. provisional patent application No. 63 / 584,165 (Docket No. IST-03.010P), filed on September 20, 2023, entitled “Methods and Systems for Improving Workflows in Digital Engineering,” describes workflow optimization in a DE platform.

[0037] • U.S. provisional patent application No. 63 / 590.456 (Docket No. IST-04.001P1), filed on October 15, 2023, entitled “Data Sovereignty Assurance for Artificial Intelligence (Al) Models.” relates to data sovereignty assurance during Al model training and evaluation.

[0038] • U.S. provisional patent application No. 63 / 606,030 (Docket No. IST-04.001P2), filed on December 4, 2023, also entitled “Data Sovereignty Assurance for Artificial Intelligence (Al) Models,” further details data sovereignty assurances during Al model training and evaluation. • U.S. provisional patent application No. 63 / 721,250 (Docket No. IST-04.001P3), filed on November 15, 2024, entitled “Data Sovereignty Assurance for Artificial Intelligence (Al) Models,” further details data sovereignty assurances during Al model training and evaluation. • U.S. provisional patent application No. 63 / 650,498 (Docket No. IST-05.001P), filed on May 22, 2024, entitled “Fyber: Distributed Digital Threading Platform for Trusted Data Sources.”

[0039] • U.S. provisional patent application No. 63 / 664,676 (Docket No. IST-05.002P), filed on June 26, 2024, entitled “Discontinuous Access to Interconnected Digital Model Platforms. ’’

[0040] • U.S. Patent No. 11,775,707 (Docket No. 54332-0057001) filed on October 25, 2022, entitled “Interconnected Digital Engineering and Certification Ecosystem.”

[0041] • U.S. provisional patent application No. 63 / 489,401, filed on March 9, 2023, entitled “Security Architecture for Interconnected Digital Engineering and Certification Ecosystem. ”Docket No. IST-03.012PCT

[0042] Notice of Copyrights and Tradedress

[0043] A portion of the disclosure of this patent document contains material which is subject to copyright protection. This patent document may show and / or describe matter which is or may become tradedress of the owner. The copyright and tradedress owner has no objection to tire facsimile reproduction by anyone of the patent disclosure as it appears in the U.S. Patent and Trademark Office files or records, but otherwise reserves all copyright and tradedress rights whatsoever.

[0044] ISTARI DIGITAL is a trademark name carrying embodiments of the present invention, and hence, the aforementioned trademark name may be interchangeably used in the specification and drawings to refer to the products / process offered by embodiments of tire present invention. Tire terms ISTARI and ISTARI DIGITAL may be used in this specification to describe the present invention, as well as the company providing said invention.

[0045] Field of the Invention

[0046] This invention relates to digital model platforms, and more specifically to the facilitation of collaborative workflows within said digital model platforms.

[0047] Background of the Invention

[0048] Tire statements in the background of the invention are provided to assist with understanding the invention and its applications and uses, and may not constitute prior art.

[0049] Digital workflows that thread digital models have become indispensable across various fields of human endeavor, revolutionizing how tasks are accomplished. From healthcare and finance to manufacturing and creative industries, these automated sequences of digital operations streamline complex procedures, enhance collaboration, and boost productivity. Digital engineering (DE), an integrated digital approach to systems engineering, exemplifies this trend by utilizing authoritative sources of system data and digital models across disciplines to support lifecycle activities from conception through disposal.

[0050] Digital workflow management and collaborative workflows have become increasingly critical in digital engineering and product development processes. As projects grow in complexity and scale, organizations face challenges in managing digital artifacts, tracking changes, and maintaining consistency across distributed teams. Traditional file and software package management systems often struggle to provide the level of traceability, version control, and data integrity required for complex engineering workflows.

[0051] In industries such as aerospace and automotive, the ability to track the evolution of digital models and artifacts throughout the product lifecycle is essential. However, conventional methods of fileDocket No. IST-03.012PCT

[0052] versioning and change management frequently rely on manual processes, spreadsheets, and email communications. These approaches are prone to errors, lack robust traceability, and can lead to inconsistencies in data across different stages of development.

[0053] Furthermore, as organizations adopt more distributed and collaborative work environments, the need for secure, efficient sharing of digital artifacts has become paramount. Traditional centralized storage systems may not provide the flexibility and scalability required for large-scale, multi-site collaborations. Additionally, ensuring that all team members have access to the most up-to-date versions of files while maintaining proper access controls presents ongoing challenges.

[0054] Tire integration of various digital tools and platforms used throughout the product development process also poses difficulties in maintaining a cohesive workflow. Different software applications may¬ handle versioning and file management in disparate ways, leading to potential incompatibilities, disconnects, and data silos. This fragmentation can hinder effective collaboration and impede the ability to maintain a clear audit trail of changes and decisions made during the development process.

[0055] As regulatory? requirements and industry standards become more stringent, particularly in sectors dealing with safety-critical systems, the need for comprehensive data provenance, auditability, and accountability has intensified. Organizations must be able to demonstrate the lineage of their digital artifacts, from initial design concepts through to final production, with comprehensive, tamper-evident records of changes and approvals, in a manner that is both transparent and verifiable.

[0056] Therefore, there is a clear unsolved need for flexible, interoperable, and secure management of the versioning and lineage of digital artifacts. Accordingly, it would be an advancement in the state of the art to enable a system for digital artifact management that can seamlessly integrate with existing workflows while providing robust versioning, traceability, and collaboration capabilities in model-based digital engineering across various industries.

[0057] It is against this background that various embodiments of the present invention were developed.

[0058] Brief Summary of the Invention

[0059] This summary of the invention provides a broad overview of the invention, its application, and uses, and is not intended to limit the scope of the present invention, which will be apparent from the detailed description when read in conjunction with the drawings.

[0060] According to a first aspect of the present invention, in one embodiment, a non-transitory physical storage media storing program code for recording a snapshot of a system configuration on a digital model platform is provided. The program code is executable by a hardware processor. Tire hardware processor when executing the program code causes the hardware processor to receive a request to generate the snapshot of the system configuration that defines a state of a file system, where the file system comprisesDocket No. IST-03.012PCT

[0061] resource files, where the system configuration references tracked files, and where each tracked file identifies a given revision of a given resource file in the file system; identify, for each tracked file referenced by the system configuration, a corresponding file revision of a corresponding resource file; generate snapshot data items at a time of a snapshot generation, where a snapshot data item is generated for each identified file revision to represent a binding of the identified file revision to the snapshot; and record, at the time of the snapshot generation, the snapshot data items as the snapshot of the system configuration, where the snapshot represents the state of the file system at the time of the snapshot generation.

[0062] In some embodiments, the program code further causes the processor to identify the tracked files referenced by the system configuration.

[0063] In some embodiments, the file system comprises a first resource file corresponding to a first digital resource generated using a first digital tool, and a second resource file corresponding to a second digital resource generated using a second digital tool, where the first digital tool and the second digital tool are non -interoperable.

[0064] In some embodiments, the system configuration defines a dependency scope, where the dependency scope is a bounded set of dependencies among file revisions identified by the tracked files.

[0065] In some embodiments, where the program code further causes the processor to: identify a digital thread executable within the dependency scope, where the digital thread comprises one or more functions executable on file revisions within the dependency scope: and execute the digital thread, wherein the program code to record the snapshot comprises program code to determine the digital thread has executed correctly.

[0066] In some embodiments, each file revision has a unique file revision identifier, and each snapshot item binds a corresponding file revision identifier to the snapshot.

[0067] In some embodiments, for each given file revision, a content of the given file revision is associated with a first cryptographic token comprising a first cryptographic hash value, and a file property of the given file revision is associated with a second cryptographic token comprising a second cryptographic hash value.

[0068] In some embodiments, the program code further causes the processor to verify an immutability of the given file revision by checking the first cryptographic hash value and the second cryptographic hash value.

[0069] In some embodiments, each resource file represents a digital engineering resource selected from the group consisting of a digital model, a digital artifact, and a user comment.

[0070] In some embodiments, the program code further causes the processor to: receive an update to a given digital resource associated yvith a resource file identified by at least one tracked file; generate anewDocket No. IST-03.012PCT

[0071] revision of the resource file based on the update; and update the system configuration to identify the new revision of the resource file.

[0072] In some embodiments, the program code to record the snapshot further causes the processor to: identify a source resource file in the file system, based on dependency data in tire system configuration, where the source resource file corresponds to a source digital resource that the given digital resource depends upon; and determine whether the source digital resource is up-to-date, where the recording of the snapshot of the system configuration is in response to determining that the source digital resource is up-to-date.

[0073] In some embodiments, the program code to record the snapshot further causes the processor to: identify a product resource file in the file system based on dependency data in the system configuration, where the product resource file corresponds to a product digital resource that depends on the given digital resource; generate an updated product file revision based on the new file revision; and update the system configuration to identify the updated product file revision.

[0074] In some embodiments, the program code further causes the processor to: generate a document revision from a document template and the system configuration, wherein the document revision comprises references to one or more of the plurality of the tracked files.

[0075] In some embodiments, the program code further causes the processor to: select the snapshot for document rendering; and generate a rendered document from the document revision and the snapshot, by¬ resolving the snapshot data items in the snapshot to respective file revisions identified by tracked files referenced in the document revision.

[0076] In some embodiments, each reference in the document revision to a tracked file is associated with an externally addressable document endpoint, and where the externally addressable document endpoint comprises an identifier to the document revision, and an identifier for the reference to the tracked file.

[0077] In some embodiments, the file system is a first file system, the system configuration is a first system configuration of the first file system, and the document revision is generated based on the first system configuration of the first file system and on a second system configuration of a second file system.

[0078] In some embodiments, the snapshot is a first snapshot of a first system configuration of a first file system, and the rendered document is generated from tire first snapshot of the first system configuration of the first file system and a second snapshot of a second system configuration of a second file system.

[0079] According to a second aspect of the present invention, in one embodiment, a method is provided for recording a snapshot of a system configuration, comprising: receiving a request to generate the snapshot of the system configuration that defines a state of a file system, where tire file system comprises resource files, where the system configuration references tracked files, and where each tracked file identifies a given revision of a given resource file in the file system; identifying, for each tracked fileDocket No. IST-03.012PCT

[0080] referenced by the system configuration, a corresponding file revision of a corresponding resource file; generating snapshot data items at a time of a snapshot generation, where a snapshot data item is generated for each identified file revision to represent a binding of the identified file revision to the snapshot; and recording, at the time of the snapshot generation, the snapshot data items as the snapshot of the system configuration, where the snapshot represents the state of tire file system at the time of snapshot generation.

[0081] According to a third aspect of the present invention, in one embodiment, a non-transitory physical storage media storing program code for recording a snapshot of a system configuration on a digital model platform is provided. The program code is executable by a hardware processor. Tire hardware processor when executing tire program code causes the hardware processor to receive a user request to update a given digital resource in a file system on the digital model platform, where the file system comprises one or more resource files, where each resource file is associated with a tracked file tracking a given revision of the resource file, and where a state of the file system is defined by a system configuration referencing one or more tracked files; identify a given resource file corresponding to the given digital resource in the file system; identify, from a current system configuration defining a current state of tire file system, a current tracked file for a current file revision of the given resource file; generate a new file revision of the given resource file, based on the user request; generate a new tracked file for the new file revision, where the new tracked file comprises an identifier of the new file revision; generate an updated system configuration by updating the current system configuration to identify the new tracked file in place of the current tracked file; and record a snapshot of the file system, where the snapshot comprises the updated system configuration at a time of tire snapshot, and one or more tracked files referenced by the updated system configuration.

[0082] In some embodiments, the file system comprises a first resource file corresponding to a first digital resource generated using a first digital tool, a second resource file corresponding to a second digital resource generated using a second digital tool, and where the first digital tool and the second digital tool are non-interoperable.

[0083] In another aspect or embodiment of tire present invention, a non-transitory, computer-readable storage medium is provided, the non-transitory, computer-readable storage medium storing executable instructions which when executed by a processor, causes the processor to perform a process for versioning digital resources and recording a snapshot of a system configuration on a digital model platform including the aforementioned steps.

[0084] In yet another aspect or embodiment of the present invention, a computer program product is provided. Tire computer program may be used for versioning digital resources and recording a snapshot of a system configuration on a digital model platform and may include a computer-readable storageDocket No. IST-03.012PCT

[0085] medium having program instructions, or program code, embodied therewith, the program instructions executable by a processor to cause the processor to perform the aforementioned steps.

[0086] In yet another aspect or embodiment of the present invention, a system for versioning digital resources and recording a snapshot of a system configuration on a digital model platform is provided, the system including a memory that stores computer-executable components, and a hardware processor, operably coupled to the memory, and that executes the computer-executable components stored in the memory, where the computer-executable components may include components communicatively coupled with the processor that execute the aforementioned steps.

[0087] In yet another aspect or embodiment of the present invention, a system for versioning digital resources and recording a snapshot of a system configuration on a digital model platform is provided, the system including a user device having a processor, a display, a first memory; a server including a second memory and a data repository; a communications link between said user device and said server: and a plurality of computer codes embodied on said first and second memory of said user device and said server, said plurality of computer codes which when executed causes said server and said user device to execute a process including the steps described herein.

[0088] In yet another aspect or embodiment of the present invention, a computerized server is provided, including at least one processor, memory, and a plurality of computer codes embodied on said memory, said plurality of computer codes which when executed causes said processor to execute a process including the steps described herein. Other aspects and embodiments of the present invention include the methods, processes, and algorithms including the steps described herein, and also include the processes and modes of operation of the systems and servers described herein.

[0089] In yet another aspect or embodiment of the present invention, an edge computerized system is provided, the edge computerized system running on a physical system or physical twin (PTw) with either access to, or dedicated, processing, memory, computer code stored on a non-transitory computer-readable storage medium of the physical system or PTw, and a plurality of sensor data being measured on said physical system or PTw, the computer code causing the processor to perform the aforementioned steps.

[0090] Features which are described in the context of separate aspects and / or embodiments of the invention may be used together and / or be interchangeable wherever possible. Similarly, where features are, for brevity, described in the context of a single embodiment, those features may also be provided separately or in any suitable sub-combination. Features described in connection with the non-transitory physical storage medium may have corresponding features definable and / or combinable with respect to a digital documentation system and / or method and / or system, or vice versa, and these embodiments are specifically envisaged.Docket No. IST-03.012PCT

[0091] Yet other aspects and embodiments of the present invention will become apparent from the detailed description of the invention when read in conjunction with the attached drawings.

[0092] Brief Description of the Drawings

[0093] The accompanying drawings, which are incorporated in and constitute part of this specification, illustrate embodiments of the invention and together with the description, serve to explain the principles of the disclosed embodiments. For clarity, simplicity, and flexibility, not all elements, components, or specifications are defined in all drawings. Not all drawings corresponding to specific steps or embodiments of the present invention are drawn to scale. Emphasis is instead placed on illustration of the nature, function, and product of the manufacturing method and devices described herein.

[0094] Embodiments of the present invention described herein are exemplary, and not restrictive. Embodiments will now be described, by way of examples, with reference to the accompanying drawings, in which:

[0095] Interconnected Digital Model Platfomr (ID MP)

[0096] Fig. 1 shows an exemplary interconnected digital model platfonn (IDMP) architecture, in accordance with some embodiments of the present invention.

[0097] Fig. 2 shows an exemplary implementation of an 1DEP as an interconnected digital engineering (DE) and certification ecosystem, and exemplary digitally certified products, in accordance with some embodiments of the present invention.

[0098] Fig. 3 shows another exemplar}' implementation of the IDEP illustrating its offered services and features, in accordance with some embodiments of the present invention.

[0099] Fig. 4 shows potential scenarios for instantiating an IDEP in connection to a customer's physical system and IT environment, in accordance with some embodiments of the present invention.

[0100] Fig. 5 shows exemplar}' multimodal interface designs for integration of feedback in an IDEP, in accordance with some embodiments of the present invention.

[0101] Fig. 6 is a schematic diagram comparing exemplary digital threads that connect DE models, in accordance with some embodiments of the present invention.

[0102] Fig. 7 is a schematic showing an exemplary DE model splicing setup, in accordance with some embodiments of the present invention.

[0103] Fig. 8 is a schematic showing digital threading of DE models via model splicing, in accordance with some embodiments of the present invention.

[0104] Fig. 9 is a schematic illustrating the linking of DE model splices in a splice plane and comparing digital threading with and without model splicing, in accordance with some embodiments of the present invention.Docket No. IST-03.012PCT

[0105] Fig. 10 shows an exemplary directed acyclic graph (DAG) representation of pipelined DE tasks related to digital threads, in accordance with some embodiments of the present invention.

[0106] Fig. 11 is an exemplary schematic illustrating the interplay between a digital thread and the individual models or artifacts it uses, defining outer and inner loop processes, in accordance with some embodiments of the present invention.

[0107] Fig. 12 illustrates an exemplary digital engineering process in the aerospace industry, showing outer loop processes, in accordance with some embodiments of the present invention.

[0108] Digital Model Splicing and Document Model Splicing Examples

[0109] Fig. 13 shows an illustrative example of computer aided design (CAD) model splicing result within tire IDMP, in accordance with some embodiments of the present invention.

[0110] Fig. 14 shows an illustrative example of document splicing or document model splicing within the IDMP. in accordance with some embodiments of the present invention.

[0111] Fig. 15 shows a screenshot of an exemplary graphical user interface (GUI) for viewing and interacting with a generated document, in accordance with some embodiments of the present invention.

[0112] Versioning of Digital Artifacts in Digital Model Platfonns

[0113] Fig. 16 is a database schema diagram illustrating an exemplary data architecture within the IDMP to support digital artifact versioning and collaborative workflows, in accordance with some embodiments of the present invention.

[0114] Figs. 17A and 17B show an exemplary entity relationship diagram of data entities within a registry service that supports resource versioning in the IDMP, in accordance with some embodiments of the present invention.

[0115] Figs. 18A and 18B show another exemplary entity relationship diagram of data entities within a registry service that supports resource versioning in tire IDMP, in accordance with some embodiments of the present invention.

[0116] Fig. 19 shows an exemplary7process for checking whether a digital artifact is up-to-date, in accordance with some embodiments of the present invention.

[0117] Fig. 20 shows an exemplary7process for updating a source model and resolving model and artifact dependencies, in accordance with some embodiments of the present invention.

[0118] Fig. 21 shows an exemplary system snapshot and document-rendering architecture for managing versioned digital assets in a configuration-scoped manner, in accordance with some embodiments of the present invention.

[0119] Fig. 22, shows an exemplary7workflow for rendering a snapshot-consistent document or system view, in accordance with some embodiments of the present invention.Docket No. IST-03.012PCT

[0120] Fig. 23 shows illustrative examples of system configuration records for a project, in accordance with some embodiments of the present invention.

[0121] Fig. 24 shows an illustrative comparison between two versions of a Magic Doc, in accordance with some embodiments of the present invention.

[0122] Fig. 25 shows an illustrative comparison between two versions of an exemplary systems requirement document, in accordance with some embodiments of the present invention.

[0123] Machine Learning Implementation Architecture for IDMP / IDEP Operations Fig. 26 describes neural network operation fundamentals, in accordance with some embodiments of the present invention.

[0124] Fig. 27 shows an overview of an IDMP neural network training process, in accordance with some embodiments of the present invention.

[0125] Fig. 28 is an illustrative flow diagram showing the different phases and datasets involved in training an IDMP machine learning model, in accordance with some embodiments of the present invention.

[0126] Hardware and Software Architecture for IDMP / IDEP Operations

[0127] Fig. 29 provides illustrative schematics of a server (management computing entity) and a client (user computing entity) used within an IDMP, in accordance with some embodiments of the present invention.

[0128] Detailed Description of the Invention

[0129] In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these specific details. In other instances, structures, devices, activities, methods, and processes are shown using schematics, use cases, and / or diagrams to avoid obscuring the invention. Although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and / or alterations to suggested details are within the scope of the present invention. Similarly, although many of tire features of the present invention are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the invention is set forth without any loss of generality to, and without imposing limitations upon, the invention.

[0130] Broadly, the present invention relates to methods and systems for a robust, unified, scalable versioning framework that tracks digital model and data artifact lineage, preserves comprehensive contextual relationships, and facilitates secure, decentralized sharing for collaborative workflows inDocket No. IST-03.012PCT

[0131] model-based digital engineering. This framework ensures that digital artifacts extracted from digital models and saved as digital files remain auditable, verifiable, and consistently aligned with their source, even as model files and artifact files undergo updates and are utilized in distributed and collaborative environments. Tire present invention further provides a snapshot mechanism that captures a point-in-time state of a digital resource file system, capturing specific file revisions as tracked at the time of snapshot generation, thereby enabling deterministic resolution of system states for consistent versioning, revision-based data immutability, repeatable document rendering, historical comparisons, and verifiable reconstruction of system states for audit, certification, and compliance purposes.

[0132] Specifically, embodiments of the present invention are directed to the implementation and utilization of a file primitive architecture within the IDMP to standardize versioning management of digital artifacts and other similar resources. A file primitive is a fundamental unit within the IDMP for managing digital resources in the IDMP’s versioning system. Each resource within the IDMP. including digital models, digital artifacts, comments, and collections of such, is associated with a file primitive or an platform “file” having one or more immutable revisions. A file primitive is associated with metadata that describes various attributes of the resource and its revisions. A digital resource file system as disclosed herein represents the state of all digital resource data within a common context. That is, a digital resource file system is a collection of files, their revisions, and derivations within a logical boundary that groups related digital resources together. Tire state of such a file system or simply “system” is defined by a system configuration that indicates the files contained within the system, revisions or versions of the files as tracked, and dependency relationships among the files or file revisions. One exemplary dependency between revisions of files of various types is a bi-directional relationship involving an upstream source file revision and a downstream product file revision in a data flow. Snapshots further capture the system configuration at a particular time and provide an immutable record of the system at that particular time.

[0133] To facilitate the versioning process, a database or registry is configured to track metadata and relationships between file primitives and revisions to maintain consistent versioning, while a decentralized storage system may store file primitives across distributed environments. In alternative embodiments, the registry' may be tokenized on a blockchain rather than stored as a secure database, resulting in a decentralized registry on the blockchain. A decentralized registry may offer advantages such as decentralization, transparency, and greater security. Both centralized and decentralized registries are referred to as “registry” or “registry service” herein, and are both considered to be within the scope of the present invention.

[0134] Changes to a file of a digital resource are tracked by creating new immutable revisions, while preserving lineage information in the registry. The registry may be configured to store cryptographic signatures for each file revision to ensure data integrity. The registry may be further configured to trackDocket No. IST-03.012PCT

[0135] timestamps and user identifiers associated with each file revision. In an exemplary implementation, the versioning system may be implemented over an enclave -exclave architecture as disclosed herein, where the registry operates within a secure enclave, and file management tasks are executed by agents operating within decentralized exclaves. Tire agents may be configured to retrieve specific file revisions based on instructions from the enclave, execute operations on the files, and update the registry with new revision information, all without the file revisions ever leaving the exclaves which may locate within secure, access-controlled customer environments.

[0136] In short, the IDMP’s versioning system supports collaboration, ensures data consistency, and guarantees data provenance throughout digital workflows. Each file of a digital resource is tracked as a unique revision, recorded with a cryptographic signature to maintain an immutable history of changes, thus eliminating version mismatches, and providing all collaborators with synchronized and verified file versions. Collaboration is enhanced through automated synchronization of file revisions across distributed teams. All contributors work on consistent, authenticated data without manual reconciliation. Consistency is ensured by tracking every file and artifact revision as immutable, linked to workflows through metadata-driven relationships. Finally, data provenance is achieved through an auditable chain of custody that ties each artifact to its inputs, the personnel involved, and the systems used. With these automated processes, the IDMP improves efficiency, reduces errors, and ensures reliable audit trails, critical for industries where compliance and accountability are essential.

[0137] With reference to the figures, embodiments of the present invention are now described in detail. First, an interconnected digital model platform (IDMP) and its digital engineering embodiment (IDEP) are explained in detail. Next, digital model splicing and threading operations are described in detail. The file primitive architecture, and file management and versioning processes across distributed environments are then detailed within the framework of model splicing, digital threading, and secure collaborative workflows on the IDMP.

[0138] Terminology

[0139] Some illustrative terminologies used herein are provided at the end of this document to assist in understanding the present invention, but these are not to be read as restricting the scope of tire present invention. The terms may be used in the form of norms, verbs, or adjectives, within the scope of the definition.

[0140] An Interconnected Digital Model Platform (IDMP) Architecture

[0141] Fig. 1 shows an exemplary interconnected digital model platform (IDMP) architecture, in accordance with some embodiments of the present invention. In the context of digital engineering (DE),Docket No. IST-03.012PCT

[0142] IDMP 100 streamlines the process of product development from conception to production, by using a virtual representation or digital twin (DTw) 122 of the product to optimize and refine features before building a physical prototype or physical twin (PTw) 132, and to iteratively update DTw 122 until DTw 122 and PTw 132 are in sync to meet the product’s desired performance goals. In what follows, the terms IDMP and IDEP are used interchangeably, as an interconnected digital engineering platfonn (IDEP) is a representative type of ID MPs.

[0143] Specifically, a product (e.g., airplane, spacecraft, exploration rover, missile system, automobile, rail system, marine vehicle, remotely operated underwater vehicle, robot, drone, medical device, biomedical device, pharmaceutical compound, drug, power generation system, smart grid metering and management system, microprocessor, integrated circuit, building, bridge, tunnel, chemical plants, oil and gas pipeline, refinery, etc.) manufacturer may use IDMP platform 100 to develop a new product. Tire engineering team from the manufacturer may create or instantiate digital twin (DTw) 122 of tire product in a virtual environment 120, encompassing detailed computer-aided design (CAD) models and finite element analysis (FEA) or computational fluid dynamics (CFD) simulations of component systems such as fuselage, wings, engines, propellers, tail assembly, and aerodynamics. DTw 122 represents the product's design and performance characteristics virtually, allowing the team to optimize and refine features before building a physical prototype 132 in a physical environment 130. In some embodiments, PTw 132 may be an existing entity, while DTw 122 is a digital instance that replicates individual configurations of PTw 132, as-built or as-maintained. In the present disclosure, for illustrative purposes only, DTw 122 and PTw 132 are discussed in the context of building a new product, but it would be understood by persons of ordinary skill in the art that the instantiation of DTw 122 and PTw 132 may take place in any order, based on the particular use case under consideration.

[0144] Digital models (e.g., CAD models. FEA models, CFD models) used for creating DTw 122 are shown within a model plane 180 in Fig. 1. Also shown in model plane 180 is a neural network (NN) model 184, which may provide machine -learning based predictive modeling and simulation for a DE process. A DE model such as 182 may be spliced into one or more model splices, such as 172 and 173 within a splice plane 170. Individual DTws such as 122 are instantiated from splice plane 170 via an application plane 160. A model splice such as 172 may be linked to another model splice such as 171 by a platform script or application 162 on application plane 160 into a digital thread. Multiple digital threads such as 162 and 163 may be further linked across different stages or phases of a product life cycle, from concept, design, testing, to production. Digital threads further enable seamless data exchange and collaboration between departments and stakeholders, ensuring optimized and validated designs.

[0145] As model splicing provides input and output splice functions that can access and modify DE model data, design updates and DE tasks associated with the digital threads may be represented byDocket No. IST-03.012PCT

[0146] scripted, interconnected, and pipelined tasks arranged in Directed Acyclic Graphs (DAGs) such as 124. A DE task DAG example is discussed in further detail with reference to Fig. 10.

[0147] To enhance the design, external sensory data 140 may be collected, processed, and integrated into application plane 160. This process involves linking data from different sources, such as physical sensors 134 on prototype 132, physical environmental sensors 136, and other external data streams such as simulation data from model plane 180. API endpoints provide access to digital artifacts from various environments (e.g., physical twin (PTw) sensor 134 data) and integrate them into the spliced plane 170 for the DTw 122. Model splices on the splice plane 170 enable autonomous data linkages and digital thread generation, ensuring DTw 122 accurately represents the product’s real-world performance and characteristics.

[0148] To validate DTw 122's accuracy, the engineering team may build or instantiate PTw 132 based on the same twin configuration (i.e., digital design). Physical prototype 132 may be equipped with numerous sensors 134, such as accelerometers and temperature sensors, to gather real-time performance data. This data may be compared with the DTw’s simulations to confirm the product’s performance and verify its design.

[0149] Processed sensory data 144 may be used to estimate parameters difficult to measure directly, such as aerodynamic forces or tire contact patch forces. Such processed sensory data provide additional data for DTw 122, further refining its accuracy and reliability. Processed sensory data 144 may be generated from physical environment sensors 136 with physical environment 130, and may be retrieved from other external databases 142, as discussed below.

[0150] During development, feedback from customers and market research may be collected to identify potential improvements or adjustments to the product's design. At an analysis & control plane (ACP) 150, subject matter experts (SMEs) may analyze processed sensory data 144 and external expert feedback 114, to make informed decisions on necessary design changes. Such analysis may be done by an analysis module 154, and may be enhanced or entirely enabled by algorithms (i.e., static program code) or artificial intelligence (Al) modules. Linking of digital threads such as 162, physical sensors 134 and 136, processed sensory data 144, and expert feedback data 114 occurs at ACP 150, where sensor and performance data is compared, analyzed, leading to modifications of the underlying model files through digital threads. Within the ACP 150, the analysis module 154 may carry out testing of the product. Additionally, testing of the twin configuration set 156. which includes feature testing, may occur in the connection between the analysis module 154 and the twin configuration set 156.

[0151] In particular, sensory data 144 from physical environment 130 and performance data 126 from virtual environment 120 may be fed into a comparison engine 152. Comparison engine 152 may compriseDocket No. IST-03.012PCT

[0152] tools that enable platform users to compare various design iterations with each other and with design requirements, identify performance lapses and trends, and run verification and validation (V&V) tools.

[0153] Model splicing is discussed in further detail with reference to Figs. 7 to 9. Model splicing enables the scripting of any DE operation involving DE model files in model plane 180, where each DE model is associated with disparate and siloed DE tools. Codification of DE models and DE operations with a unified corpus of scripts enable IDMP 100 to become an aggregator where a large space of DE activities associated with a given product (e.g., airplane, spacecraft, exploration rover, missile system, automobile, rail system, marine vehicle, remotely operated underwater vehicle, robot, drone, medical device, biomedical device, pharmaceutical compound, drug, power generation system, smart grid metering and management system, microprocessor, integrated circuit, building, bridge, tunnel, chemical plants, oil and gas pipeline, refinery, etc.) may be threaded through program code. Thus, model splicing enables the linking and manipulation of all model files (e.g., 182. 184) associated with a given product within the same interconnected platform or ecosystem 100. As a consequence, the generation and training of Al modules for the purpose of manipulating DE models (e.g., 182), digital threads (e.g., 162), and digital twins (e.g., 122) become possible over the programmable and unified IDMP 100.

[0154] Virtual and Physical Feedback Loops

[0155] Fig. 1 uses letter labels “A” to H to denote different stages of a product’s lifecycle. At each stage, IDMP 100 enables feedback loops whereby data emanating from a PTw or a DTw is analyzed at ACP 150, leading to the generation of a new twin configuration based on design modifications. The new twin configuration may be stored in a twin configuration set and applied through the application and splice planes, yielding modified model files that are registered on tire digital thread.

[0156] A virtual feedback loop 104 starts with a decision 106 to instantiate new DTw 122. A DAG of hierarchical tasks 124 allows the automated instantiation of DTw 122 within virtual environment 120, based on a twin configuration applied at a process step 108 from a twin configuration set 156. DTw 122 and / or components thereof are then tested in virtual environment 120, leading to the generation of DTw performance data 126. Concurrently, DTw 122 and / or components thereof may be tested and simulated in model plane 180 using DE software tools, giving rise to test and simulation performance data 174. Performance data 126 and 174 may be combined, compared via engine 152, and analyzed at ACP 150, potentially leading to the generation and storage of a new twin configuration. The eventual decision to instantiate a DTw from the new twin configuration completes virtual feedback loop 104.

[0157] A physical feedback loop 102 starts with a decision 106 to instantiate a new PTw 132. PTw 132 may be instantiated in a physical environment 130 from the model files of model plane 180 that arc associated with an applied twin configuration from the twin configuration set 156. PTw 132 and / orDocket No. IST-03.012PCT

[0158] components thereof are then tested in physical environment 132, leading to the generation of sensory data from PTw sensors 134 and environmental sensors 136 located in physical environment 130. This sensory data may be combined with data from external databases to yield processed sensory data 144. In one exemplary embodiment, temperature readings from environmental sensors located within the physical environment are completed, adjusted (e.g., shifted), and / or calibrated using data from external temperature databases.

[0159] Data from PTw sensors 134 may be directly added to the model files in model plane 180 by the DE software tools used in the design process of PTw 132. Alternatively, PTw sensor data may be added to digital thread 162 associated with PTw 132 directly via application plane 160. In addition, processed sensory data 144 may be integrated into IDMP 100 directly via application plane 160. For example, processed sensory data 144 may be sent to ACP 150 for analysis, potentially leading to the generation and storage of a new twin configuration. The eventual decision to instantiate a PTw from the new twin configuration completes physical feedback loop 102.

[0160] At each stage A to H of the product life cycle, the system may label one twin configuration as a current design reference, herein described as an ‘‘authoritative twin” or “authoritative reference”. The authoritative twin represents the design configuration that best responds to actual conditions (i.e., the ground truth). PCT application No. PCT / US24 / 27898 (Docket No. IST-03.001PCT) provides a more complete description of authoritative twins and their determination, and is incorporated by reference in its entirety herein.

[0161] With faster feedback loops from sensor data and expert recommendations, the system updates DTw 122 to reflect latest design changes. This update process may involve engineering teams analyzing feedback 154 and executing the changes through IDMP 100, or automated changes enabled by IDMP 100 where updates to DTw 122 are generated through programmed algorithms or Al modules. This iterative updating process continues until DTw 122 and PTw 132 are in sync and the product’s performance meets desired goals. While IDMP 100 may not itself designate the authoritative reference between a DTw ora PTw, the platform provides configurable mechanisms such as policies, algorithms, voting schema, and statistical support, whereby agents may designate a new DTw as the authoritative DTw, or equivalently in what instances the PTw is the authoritative source of truth.

[0162] When significant design improvements are made, a new PTw prototype may be built based on the updated DTw. This new prototype undergoes further testing and validation, ensuring the product's performance and design align with project objectives.

[0163] Once DTw 122 and PTw 132 have been validated and optimized, the product is ready for production. A digital thread connecting all stages of development can be queried via splice plane 170 to generate documentation as needed to meet validation and verification requirements. The use of modelDocket No. IST-03.012PCT

[0164] splicing, along with the feedback architecture shown in Fig. 1, improves the efficiency of the overall product innovation process.

[0165] Interconnected DE Platform and Product Lifecycle

[0166] In Fig. 1, letter labels “A" to “H” indicate the following major steps of a product lifecycle, according to some embodiments of the current invention:

[0167] A. Digital models reside within customer environments: a product may be originally represented by model files that are accessible via software tools located within customer environments. Model plane 180 encompasses all model files (e.g., 182) associated with the product.

[0168] B. Preparatory steps for design in the digital realm: splice plane 170 encompasses model splices (e g., 172) generated from DE model file through model splicing. Model splicing enables the integration and sharing of DE model files within a single platfonn. as described in detail with reference to Figs. 7 to 9.

[0169] C. Link threads as needed among model splices: to implement a product, model splices are linked through scripts within application plane 160. A digital tw in (DTw) 122 englobing as-designed product features may be generated from application plane 160 for running in virtual environment 120. The complete twin configuration of a generated DTw is saved in tw in configuration set 156 located at the analysis & control plane (ACP) 150. Features or parts of DTw 122 may be simulated in model plane 180, with performance data 174 accessed through splice plane 170. In one embodiment, features or parts of PTw 132 or DTw 122 configuration may be simulated outside the platform, where performance data is received by the ACP 150 for processing, in a similar way as performance data 126 received from DTw 122.

[0170] D. Finalize "As-designed": perfonnance data 126 from DTw 122 or simulation performance data 174 attained through model plane 180 and accessed through model splicing may be collected and sent to ACP 150 for analysis. Performance data from different iterations of DTw 122 may be compared via engine 152 to design requirements. Analysis of the differences may lead to the generation of new' twin configurations that are stored at twin configuration set 156. Each twin configuration in twin configuration set 156 may be applied at application plane 160 and splice plane 170 via process step 108 to instantiate a corresponding DTw. Multiple DTws may be generated and tested, consecutively or simultaneously, against the design requirements, through comparison engine 152 and analysis module 154. Verification and validation tools may be ran on the various DTw iterations.

[0171] E. Finalize “As-manufacturcd”: once a DTw 122 satisfies the design requirements, a corresponding PTw 132 prototype may be instantiated from the spliced model files (e.g., 172). Sensor dataDocket No. IST-03.012PCT

[0172] originating from the PTw 134 or from within the physical environment 136 may be collected, combined with other external data 142 (e.g., sensor data from other physical environments). The resulting processed sensory data 144 may be sent to the analysis & control plane 150 to be compared with performance data 126 from DTws and simulations (e.g., 174), leading to further DTw 122 and PTw 132 iterations populating the twin configuration set 156. Processed sensory data 144 may also be mapped to the digital threads (e.g., 164) and model splices (e.g., 172) governing the tested PTw 132 through the application plane 160.

[0173] F. Finalize “As-assembled”: once the manufacturing process is completed for the various parts, as a DTw and as a PTw, the next step is to finalize tire assembled configuration. This involves creating a digital representation of the assembly to ensure it meets the specified requirements. Tire digital assembly takes into account the dimensions and tolerances of the “as-manufactured” parts. To verify the feasibility of the digital assembly, tests are conducted using tire measured data obtained from the physical assembly and its individual components. Measurement data from the physical component parts may serve as the authoritative reference for the digital assembly, ensuring alignment with the real-world configuration. The digital assembly is compared with the actual physical assembly requirements for validation of the assembled configuration. Subsequently, the digital assembly tests and configurations serve as an authoritative reference for instructions to guide the physical assembly process and ensure accurate replication. IDEP 100 components described above may be used in the assembly process. In its authoritative iteration, DTw 122 ultimately captures the precise details of the physical assembly, enabling comprehensive analysis and control in subsequent stages of the process.

[0174] G. Finalize “As-operated”: to assess tire perfonnance of the physical assembly or its individual component parts, multiple digital twins 122 may be generated as needed. These digital twins are created based on specific perfonnance metrics and serve as virtual replicas of the physical system. Digital twins 122 are continuously updated and refined in real-time using the operational data (e.g., 144) collected from monitoring the performance of the physical assembly or its components. This data may include, but are not limited to, processed sensory data, performance indicators, and other relevant information. By incorporating this real-time operational data, digital twins 122 stay synchronized with the actual system and provide an accurate representation of its operational performance. Any changes or improvements observed via sensory- data 144 during the real-world operation of the assembly are reflected in DE models within the digital twins and recorded in the twin configuration set 156. This ensures that the digital twins remain up-to-date and aligned with the current state of the physical system.Docket No. IST-03.012PCT

[0175] H. Predictive analytics / Future performance: The design process may continue iteratively in virtual environment 120 through new DTw 122 configurations as the product is operated. Multiple digital twins may be created to evaluate tire future performance of the physical assembly or its component parts based on specific performance metrics. Simulations are conducted with various control policies to assess the impact on performance objectives and costs. Hie outcome of these simulations helps in deciding which specific control policies should be implemented (e.g., tail volume coefficients and sideslip angle for an airplane product). The digital twin DE models (e.g., 182) are continuously updated and refined using the latest sensor data, control policies, and performance metrics to enhance their predictive accuracy. This iterative process ensures that the digital twins (e.g., 122, 156) provide reliable predictions of future performance and assist in making informed decisions.

[0176] The hardware components making up IDMP 100 (e.g., servers, computing devices, storage devices, network links) may be centralized or distributed among various entities, including one or more DE service providers and DE clients, as further discussed in the context of Figs. 3 and 4. Fig. 4 shows an illustration of various potential configurations for instancing a DE platform within a customer's physical system and information technology (IT) environment, usually a virtual private cloud (VPC) protected by a firewall.

[0177] Digital Documentation through Live Digital Objects

[0178] The methods and systems described herein enable the updating and generation of digital documents using the full functionality of the IDMP shown in Fig. 1. In Fig. 1, the IDMP virtual feedback loop 104 allows the scripting of program code within a digital thread 162 for the generation, storing, and updating of digital twins 122 and twin configurations 156. Similarly, the IDMP virtual feedback loop 104 also allows the scripting of program code within a digital thread 162 for the generation, storing, and updating of digital documents. This enables the creation and maintenance of so-called live digital objects.

[0179] Live digital objects are more akin to a DTw than a conventional static document in that they are configured, through a digital thread, to be continuously updated to reflect the most current changes within a particular twin configuration. In particular, an authoritative / trusted live digital object is configured to reflect the latest authoritative / trusted twin configuration. Specifically, live digital objects are digital objects that (1) include a digital artifact extracted from a digital model through a model presentation (e.g., model splice), where (2) a modification of the digital artifact appears in the live digital object within a predetermined delay. In various embodiments, tire updates are effectively real-time or near real-time.Docket No. IST-03.012PCT

[0180] Live digital objects may use a document interface, yielding live digital documents, or live documents. Live digital documents may pull data from multiple model files. Preliminary design reviews may thus take the form of a live digital document.

[0181] Live digital objects may also use a dashboard interface, yielding live digital boards, or live boards. In some embodiments, a live digital board may display one or more documents and one or more applications on a two-dimensional (2D) screen rendered on a modality of a multimodal interface such as a 2D display, a two-and-a-half-dimensional (2.5D) display, and a three-dimensional (3D) semi-immersive or fully immersive display. Live digital boards may combine multiple documents through a VR / AR and / or conversational interface, into a board / screen 2D, 2.5D format. For example, a live board may combine multiple model fdes from a CAD software with collaboration chat rooms over a 2D screen rendered on a 2D display (traditional display), a 2.5D display, or a 3D semi immersive or fully immersive display. In one embodiment, the live board combines multiple view screens.

[0182] Finally, a live digital object may take the form of a live digital space (or live space), a 3D virtual environment or an augmented environment. In some embodiments, a live digital space displays one or more documents and one or more other applications in a virtual space rendered through a 3D spatial display. Live digital spaces may combine multiple documents through VR / AR and / or conversational interfaces into a 3D spatial representation. For example, a live space may display multiple 3D model files from a CAD software with collaboration chat rooms over a 3D semi immersive or fully immersive display- spatial display.

[0183] Live digital objects may be stored and accessed through an IDMR Specifically, live digital objects may be used to provide tire background context for a given digital thread, and may specifically be used to display and organize a digital thread’s associated artifacts, as described herein.

[0184] Live digital objects may hence be known as magic objects (i.e., live documents may be denoted ‘"magic documents”, live boards may be denoted “magic boards”, and live spaces may be denoted “magic spaces”) as changes implemented within a twin configuration (e g., through a modification of a model file) may appear instantaneously within the relevant data fields of the live digital objects. Similarly, authoritative / trusted live digital objects may also be known as authoritative / trusted magic objects as they continuously reflect data from the authoritative twin, thus always representing the authoritative source of truth.

[0185] Given tire massive quantities of data and potential modifications that are carried out during a product's lifecycle, the scripts implementing live digital objects may be configured to allow for a predefined maximum delay between the modification of a model file (e.g., the modification of a digital artifact) and the execution of the corresponding changes within a live digital object. Moreover, for similar reasons, the scripts implementing live digital objects may be restricted to operate over a specified subsetDocket No. IST-03.012PCT

[0186] of model files within a DTw or a system, thus reflecting changes only to key parameters and configurations of the DTw or the system.

[0187] Tire “printing” of a live digital document or board corresponds to the generation of a frozen (i.e., static) time-stamped version of a live digital document or board. Therefore, “printing” - for a live digital document or board - is equivalent to “instantiation” for a digital twin. Similarly, the “printing” of a live digital space may also be envisaged, yielding a frozen 3D representation of a given system or digital thread.

[0188] In one embodiment of the present invention, an IDMP script (e.g., an IDEP application) having access to model data via one or more model splices and digital document templates to create and / or update a live digital object may dynamically update the live digital object using software-defined digital threads over an IDMP platform. In such an embodiment, the IDMP script may receive user interactions dynamically. In response to tire user updating data for a model and / or a specific parameter setting, the IDMP script may dynamically propagate the user's updates into the digital object through a corresponding digital thread.

[0189] In another embodiment of the present invention, an IDMP script may instantiate a digital object with sufficient specification to generate a physical twin (PTw). In such an embodiment, the IDMP script may receive a digital twin configuration of a physical twin, generate a live digital object associated with the digital twin configuration, receive a predetermined timestamp, and generate a printed digital object (i.e., a static, time-stamped version of the live digital object at the predetermined timestamp). Such an operation may be referred to as the "printing of a digital twin" .

[0190] In yet another embodiment of the present invention, an IDMP script may instantiate (i.e., "print") a digital object specifying an updated digital twin upon detecting the update. In such an embodiment, tire IDMP script may detect a modification of a digital model or an associated digital thread. In response to detecting the modification, the IDMP script may update relevant data fields and sections of the live digital object based on the detected modification, and generate an updated printed digital object with the updated relevant data fields and sections based on the always-updated live digital object.

[0191] In various embodiments, a software-defined digital thread can be associated with a companion magic document (or “magic doc”) that encompasses live updates for one or more core parameters of the digital thread. In one embodiment, the magic doc includes key parameters describing the implementation of a user’s intent. For example, In one embodiment, a companion magic doc for a given digital thread may include key data points and key orchestration script examples illustrating a user’s intent (e.g., “increase a drone’s wing span by 1%”). In one embodiment, a script-generating ML model receiving as input pseudocode or detailed user instructions derived from a user's intent, is trained on prior IDEP digital threads and documents. In addition to generating a digital thread (with orchestration scripts andDocket No. IST-03.012PCT

[0192] comments), the script-generating ML model is also configured to generate a magic doc that explains how the generated digital thread addresses the user intent.

[0193] In some embodiments, receiving user interactions with a DE model, modifications to a DE model, or modifications to an associated digital thread, may be carried out through a push configuration, where a model splicer or a script of the digital thread sends any occurring relevant updates to the IDEP script immediately or within a specified maximum time delay. In other embodiments, receiving user interactions with a DE model, modifications of a DE model, or modifications of an associated digital thread, may be carried out through a pull configuration, where a model splicer or a script of the digital thread flag recent modifications until the IDEP script queries relevant DE models (via their model splices) or associated digital threads, for flagged modification. In these embodiments, the IDEP script may extract the modified information from the modified DE models (via their model splices) or the modified digital threads, in order to update a live DE document. In yet other embodiments, receiving user interactions with a DE model, modifications of a DE model, or modifications of an associated digital thread, may be carried out through a pull configuration, where the IDEP script regularly checks relevant DE models (via their model splices) or associated digital threads, for modified data fields, by comparing the data found in the live DE document with regularly extracted model and digital thread data. In these embodiments, the IDEP script may use the modified data to update the live DE document.

[0194] Dynamic Document Updates

[0195] Some embodiments described herein center around documentation, or document preparation and update and on document management (e.g., for reviews). As discussed, some embodiments of the system allow for dynamic updates to documents, which pertain to software -defined digital threads in the IDEP platform and tire accompanying documentation.

[0196] Use of an ML engine with the model data and templates to create and / or update documents almost instantaneously as a one-time action have been presented. Furthermore, the digital engineering platform interacts dynamically with the user. As the user interacts with the system and updates data for a model or a specific parameter setting, these changes may be propagated through the corresponding digital threads and to the associated documentation. Tire Al architectures involved include locally-instanced large language model (LLMs, for data security reasons) as well as non-LLM approaches (e.g., NLP -based), in order to create, update, or predict documentation in the form of sentences, paragraphs, and whole documents. At the same time, trying to update the entire system of digital threads for every update may be prohibitively slow and may present security risks to the system. Generating live DE documents that arc updated based on a subset of a system’s DE models and within a maximum time delay may therefore be more efficient.Docket No. IST-03.012PCT

[0197] Interconnected Digital Engineering and Certification Ecosystem

[0198] Fig. 2 shows an exemplary implementation of the IDEP as an interconnected digital engineering (DE) and certification ecosystem 200, and exemplary digitally certified products, in accordance with some embodiments of the present invention. Interconnected DE and certification ecosystem 200 may be viewed as a particular instantiation or implementation of IDEP 100 shown in Fig. 1. The IDEP may also be referred to as a '‘DE Metaverse.”

[0199] Interconnected DE and certification ecosystem 200 is a computer-based system that links models and simulation tools with their relevant requirements in order to meet verification, validation, and certification purposes. Verification refers to methods of evaluating whether a product, service, or system meets specified requirements and is fit for its intended purpose. For example, in the aerospace industry, a verification process may include testing an aircraft component to ensure it can withstand the forces and conditions it will encounter during flight. Verification also includes checking externally against customer or stakeholder needs. Validation refers to methods of evaluating whether the overall performance of a product, service, or system is suitable for its intended use, including its compliance with regulator}' requirements and its ability to meet the needs of its intended users. Validation also includes checking internally against specifications and regulations. Interconnected DE and certification ecosystem 200 as disclosed herein is designed to connect and bridge large numbers of disparate DE tools and models from multitudes of engineering domains and fields, or from separate organizations who may want to share models with each other but have no interactions otherwise. In various embodiments, the system implements a robust, scalable, and efficient DE model collaboration platform, with extensible model splices having data structures and accompanying functions for widely distributed DE model types and DE tools, an application layer that links or connects DE models via APIs, digital threads that connect live engineering model files for collaboration and sharing, digital documentation management to assist with the preparation of engineering and certification documents appropriate for verification and validation (V&V) purposes, and Al-assistance with the functionalities of the aforementioned system components.

[0200] More specifically, Fig. 2 show s an example of an interconnected DE and certification ecosystem and examples of digitally certified products 212A, 212B, and 212C (collectively referred to as digitally certified products 212). For example, in some implementations, digitally certified product 212A may be an unmanned aerial vehicle (UAV) or other aircraft, digitally certified product 212B may be a drag or other chemical or biologic compound, and the digitally certified product 212C may be a process such as a manufacturing process. In general, the digitally certified products 212 can include any product, process, or solution that can be developed, tested, or certified (partially or entirely) using DE tools such as 202. In some implementations, digitally certified products 212 may not be limited to physical products, but canDocket No. IST-03.012PCT

[0201] include non-physical products such as methodologies, processes and software, etc. While physical and physically-interacting systems often require multiple DE tools to assess for compliance with common V&V products simply by virtue of the need for modeling and simulation (M&S), many complex non-physical systems may also require multiple DE tools for product development, testing, and / or certification. With this in mind, various other possibilities for digitally certified products will be recognized by one of ordinary skills in the art. The inclusion of regulatory and certification standards, compliances, calculations, and tests (e.g., for the development, testing, and certification of products and / or solutions) enables users to incorporate relevant regulatory and certification standards, compliances, calculations, and test data directly into their DE workflow. Regulatory and certification standards, compliances, calculations, and tests are sometimes referred to herein as “common validation and verification (V&V) products.”

[0202] Digitally certified products 212 in Fig. 2 may be designed and / or certified using interconnected DE and certification ecosystem 200. Interconnected DE and certification ecosystem 200 may include a user device 206A, API 206B, or other similar human-to-machine, or machine-to-machine communication interfaces operated by a user. A user may be a human 204 of various skill levels, or artificial users such as algorithms, artificial intelligence, or other software that interface with ecosystem 200 through API 206B. Ecosystem 200 may further comprise a computing and control system 208 (“computing system 208” hereinafter) connected to and / or including a data storage unit 218, an artificial intelligence (Al) engine 220, and an application and service layer 222. In some embodiments, the artificial intelligence (Al) engine 220 is a machine learning (ML) engine. References to “machine learning engine 220 “or “ML engine 220” may be extended to artificial intelligence (Al) engine 220 more generally. For the purposes of clarity, any user selected from various potential human or artificial users is referred to herein simply as the user 204. In some implementations, computing system 208 may be a centralized computing system; in some implementations, computing system 208 may be a distributed computing system. In some cases, user 204 may be considered part of ecosystem 200, while in other implementations, user 204 may be considered separately from ecosystem 200. Ecosystem 200 may include one or more DE tools 202, such as data analysis tool 202A, computer-aided design (CAD) and finite element analysis (FEA) tool 202B, simulation tool 202C, drug modeling and simulation (M&S) tools 202D-202E, manufacturing M&S tools 202F-202G, etc. Ecosystem 200 may also include a repository of common V&V products 210. such as regulatory standards 210A-210F related to the development and certification of a UAV, medical standard 210G (e.g., CE marking (Europe), FCC Declaration of Conformity (USA), IECEE CB Scheme (Europe, North America, parts of Asia & Australia), CDSCO (India), FDA (USA), etc.), medical certification regulation 210H (e.g., ISO 13485, ISO 14971, ISO 9001, ISO 62304, ISO 10993, ISO 15223, ISO 11135, ISO 11137, ISO 11607, IEC 60601, etc.), manufacturing standard 2101 (e.g., ISO 9001, ISO 9013, ISODocket No. IST-03.012PCT

[0203] 10204, EN 1090, ISO 14004, etc.), and manufacturing certification regulation 210J (e.g., General Certification of Conformity (GCC), etc.), etc.

[0204] In Fig. 2, computing system 208 is centrally disposed within the architecture and is configured to communicate with (e.g., receive data from and transmit data to) user device 206A or API 206B such as an API associated with an artificial user, DE tools 202 via an API or software development kit (SDK) 214, and repository of common V&V products 210 via an API / SDK interface 216. For example, computing system 208 may be configured to communicate with user device 206A and / or API 206B to send or receive data corresponding to a prototype of a design, information about a user (e.g., user credentials), engineering-related inputs / outputs associated with DE tools 202, digitized common V&V products, an evaluation of a product design, user instructions (e.g., search requests, data processing instructions, etc.), and more. Computing system 208 may also be configured to communicate with one or more DE tools 202 to send engineering -related inputs for executing analyses, models, simulations, tests, etc., and to receive engineering-related outputs associated with the results. Computing system 208 may also be configured to communicate with repository of common V&V products 210 to retrieve data corresponding to one or more digitized common V&V products 210 and / or upload new common V&V products, such as those received from user 204, to repository of common V&V products 210. All communications may be transmitted and corroborated securely, for example, using methods relying on zero-trust security. In some implementations, the computing system of the ecosystem may interface with regulatory and / or certification authorities (e.g., via websites operated by the authorities) to retrieve digitized common V&V products published by the regulatory authorities that may be relevant for a product that a user is designing. In some implementations, the user may upload digitized common V&V products to the ecosystem themselves.

[0205] Computing and control system 208 may process and / or store the data that it receives to perform analysis and control functionalities, and in some implementations, may access machine learning engine 220 and / or application and service layer 222, to identify usefill insights based on the data, as further described herein. The central disposition of computing system 208 within the architecture of the ecosystem has many advantages including reducing the technical complexity’ of integrating the various DE tools; improving the product development experience of user 204; intelligently connecting common V&V products such as standards 210A-210F to DE tools 202 most useful for satisfying requirements associated with the common V&V products: and enabling the monitoring, storing, and analysis of the various data that flows between the elements of the ecosystem throughout the product development process. In some implementations, the data flowing through and potentially stored by the computing system 208 can also be auditable to prevent a security’ breach, to perform data quality control, etc.Docket No. IST-03.012PCT

[0206] Similarly, any analysis and control functions performed via computing system 208 may be tracked for auditability and traceability considerations.

[0207] Referring to one particular example shown in Fig. 2, user 204 may use the DE and certification ecosystem to produce a digitally certified UAV 212B. For example, user 204 may be primarily concerned with certifying tire UAV as satisfying the requirements of a particular regulatory standard 210E relating to failure conditions of the UAV (e.g., “MIE-HDBK 516C 4.1.4 - Failure Conditions”). In this usage scenario, user 204 may develop a digital prototype of the UAV on user device 206A or using API 206B and may transmit prototype data (e.g., as at least one of a CAD file, a MBSE file, etc.) to computing system 208. Along with tire prototype data, user 204 can transmit, via user device 206A, additional data including an indication of the common V&V product that user 204 is interested in certifying the product for (e.g., regulatory standard 210E), user credential infonnation for accessing one or more capabilities of computing system 208, and / or instructions for running one or more digital models, tests, and / or simulations using a subset of DE tools 202.

[0208] Referring to another example shown in Fig. 2, user 204 can use the DE and certification ecosystem to produce a digitally certified drug, chemical compound, or biologic 212A. For example, user 204 may be primarily concerned with certifying drug, chemical compound, or biologic 212A as satisfying the requirements of a particular medical standard 210G and medical certification regulation 21 OH. In this usage scenario, user 204 can develop a digital prototype of the drug, chemical compound, or biologic on user device 206A or using API 206B and can transmit the prototype data (e.g., as a molecular modeling file) to computing system 208. Along with the prototype data, user 204 can transmit, via user device 206A, additional data including an indication of the common V&V products that user 204 is interested in certifying the product for (e.g., medical standard 210G and medical certification regulation 210H), user credential infonnation for accessing one or more capabilities of computing system 208, and / or instructions for running one or more digital models, tests, and / or simulations using a subset of DE tools 202 (e.g., drug M&S tools 202D-202E).

[0209] Referring to yet another example shown in Fig. 2, user 204 can use the digital engineering and certification ecosystem to produce a digitally certified manufacturing process 212C. For example, user 204 may be primarily concerned with certifying manufacturing process 212C as satisfying the requirements of a particular manufacturing standard 2101 and manufacturing certification regulation 210J. In this usage scenario, user 204 can develop a digital prototype of the manufacturing process on user device 206A or using API 206B and can transmit the prototype data to computing system 208. Along with the prototype data, user 204 can transmit, via the user device 206A, additional data including an indication of the common V&V products that user 204 is interested in certifying the process for (e.g., manufacturing standard 2101 and manufacturing certification regulation 210J), user credential informationDocket No. IST-03.012PCT

[0210] for accessing one or more capabilities of computing system 208, and / or instructions for running one or more digital models, tests, and / or simulations using a subset of DE tools 202 (e.g., manufacturing M&S tools 202F-202G).

[0211] In any of tire aforementioned examples, computing system 208 can receive tire data transmitted from user device 206A and / or API 206B and can process the data to evaluate whether the common V&V product of interest (e.g., regulatory standard 210E. medical standard 210G, medical certification regulation 21 OH, manufacturing standard 2101, manufacturing certification regulation 210J, etc.) is satisfied by the user’s digital prototype, in the context of analysis and control plane 150 shown in Fig. 1. For example, this can involve communicating with tire repository of common V&V products 210 via the API / SDK 216 to retrieve the relevant common V&V product of interest and processing tire regulatory and / or certification data associated with the common V&V product to identify one or more requirements for the UAV prototype: the drug, chemical compound, or biologic prototype; the manufacturing process prototype; etc. In some implementations, repository of common V&V products 210 can be hosted by a regulatory and / or certification authority (or another third party), and retrieving the regulatory and / or certification data can involve using API / SDK 216 to interface with one or more data resources maintained by tire regulatory and / or certification authority (or another third party). In some implementations, the regulatory and / or certification data can be provided directly by user 204 via user device 206A and / or API 206B (e.g., along with the prototype data).

[0212] Evaluating whether the common V&V product of interest is satisfied by the user’s digital prototype can also involve processing the prototype data received from user device 206A or API 206B to determine if the one or more identified requirements are actually satisfied. In some implementations, computing system 208 can include one or more plugins, local applications, etc., to process the prototype data directly at the computing system 208. For example, model splicing and digital threading applications are discussed in detail later with reference to Figs. 6 to 9. In some implementations, the computing system can simply pre-process the received prototype data (e.g., to derive inputs for DE tools 202) and can then transmit instructions and / or input data to a subset of DE tools 202 via API / SDK 214 for further processing.

[0213] Not all DE tools 202 are necessarily required for the satisfaction of particular regulatory and / or certification standards. Therefore, in the UAV example provided in Fig. 2, computing system 208 may determine that only a data analysis tool 202A and a finite element analysis tool 202B are required to satisfy regulatory standard 210E for failure conditions. In the drug, chemical compound, or biologic example provided in Fig. 2, computing system 208 may determine that only drug M&S tools 202D-202E arc required to satisfy medical standard 210G and medical certification regulation 21 OH. In the manufacturing process example provided in Fig. 2, computing system 208 may determine that onlyDocket No. IST-03.012PCT

[0214] manufacturing M&S tools 202F-202G are required to satisfy manufacturing standard 2101 and manufacturing certification regulation 210J. In other implementations, user 204 may themselves identify the particular subset of DE tools 202 that should be used to satisfy the common V&V product of interest, provided that user 204 is a qualified subject matter expert (SME). In other implementations, user 204 may input to computing system 208 some suggested DE tools 202 to satisfy a common V&V product of interest, and computing system 208 can recommend to user 204 a modified subset of DE tools 202 for final approval by user 204, provided that user 204 is a qualified SME. After a subset of DE tools 202 has been identified, computing system 208 can then transmit instructions and / or input data to the identified subset of DE tools 202 to run one or more models, tests, and / or simulations. The results (or “engineering-related data outputs" or “digital artifacts”) of these models, tests, and / or simulations can be transmitted back and received at computing system 208.

[0215] In still other implementations, user 204 may input a required DE tool such as 202F for meeting a common V&V product 2101, and the computing system 208 can determine that another DE tool such as 102G is also required to satisfy common V&V product 2101. The computing system can then transmit instructions and / or input data to both DE tools (e.g., 202F and 202G), and tire outputs of these DE tools can be transmitted and received at computing system 208. In some cases, the input data submitted to one of the DE tools (e.g., 202G) can be derived (e.g., by computing system 208) from the output of another of the DE tools (e.g., 202F).

[0216] After receiving engineering-related data outputs or digital artifacts from DE tools 202, computing system 208 can then process the received engineering-related data outputs to evaluate whether or not the requirements identified in the common V&V product of interest (e.g., regulatory standard 210E, medical standard 2 HOG, medical certification regulation 21 OH, manufacturing standard 2101, manufacturing certification regulation 210J, etc.) are satisfied. For example, applications and services 222 may provide instructions for orchestrating validation or verification activities. In some implementations, computing system 208 can generate a report summarizing the results of the evaluation and can transmit the report to device 206A or API 206B for review by user 204. If all of the requirements are satisfied, then the prototype can be certified, resulting in digitally certified product 212 (e.g., digitally certified drug, chemical compound, or biologic 212A; digitally certified UAV 212B: digitally certified manufacturing process 212C. etc.). However, if some of the regulatory requirements are not satisfied, then additional steps may need to be taken by user 204 to certify the prototype of the product. In some implementations, the report that is transmitted to the user can include recommendations for these additional steps (e.g., suggesting one or more design changes, suggesting the replacement of one or more components with a previously designed solution, suggesting one or more adjustments to the inputs of the models, tests, and / or simulations, etc.). If the requirements of a common V&V product are partially met, or are beyondDocket No. IST-03.012PCT

[0217] the collective capabilities of distributed engineering tools 202, computing systems 208 may provide user 204 with a report recommending partial certification, compliance, or fulfillment of a subset of the common V&V products (e.g., digital certification of a subsystem or a sub-process of the prototype). The process of generating recommendations for user 204 is described in further detail below.

[0218] In response to reviewing the report, user 204 can make design changes to the digital prototype locally and / or can send one or more instructions to computing system 208 via user device 206A or API 206B. These instructions can include, for example, instructions for computing system 208 to re-evaluate an updated prototype design, use one or more different DE tools 202 for the evaluation process, and / or modify the inputs to DE tools 202. Computing system 208 can, in turn, receive the user instructions, perform one or more additional data manipulations in accordance with these instructions, and provide user 204 with an updated report. Through this iterative process, user 204 can utilize the interconnected digital engineering and certification ecosystem to design and ultimately certify (e.g., by providing certification compliance information) the prototype (e.g., the UAV prototype, drug prototype, manufacturing process prototype, etc.) with respect to the common V&V product of interest. Importantly, since all of these steps occur in the digital world (e.g., with digital prototypes, digital models / tests / simulations, and digital certification), significant amount of time, cost, and materials can be saved in comparison to a process that would involve the physical prototyping, evaluation and / or certification of a similar UAV, drug, manufacturing process, etc. If the requirements associated with a common V&V product are partially met, or are beyond the collective capabilities of DE tools 202, computing system 208 may provide user 204 with a report recommending partial certification, compliance or fulfillment of a subset of the common V&V products (e.g., digital certification of a subsystem or a sub-process of the prototype).

[0219] While the examples described above focus on the use of tire interconnected digital engineering and certification ecosystem by a single user, additional advantages of the ecosystem can be realized through the repeated use of the ecosystem by multiple users. As mentioned above, the central positioning of computing system 208 within the architecture of the ecosystem enables computing system 208 to monitor and store the various data flows through the ecosystem. Thus, as an increasing number of users utilize the ecosystem for digital product development, data associated with each use of the ecosystem can be stored (e.g., in storage 218), traced (e.g.. with metadata), and analyzed to yield various insights, which can be used to further automate the digital product development process and to make the digital product development process easier to navigate for non-subject matter experts.

[0220] Indeed, in some implementations, user credentials for user 204 can be indicative of the skill level of user 204, and can control the amount of automated assistance the user is provided. For example, non-subjcct matter experts may only be allowed to utilize the ecosystem to browse pre-made designs and / or solutions, to use DE tools 202 with certain default parameters, and / or to follow a predetenninedDocket No. IST-03.012PCT

[0221] workflow with automated assistance directing user 204 through the product development process. Meanwhile, more skilled users may still be provided with automated assistance, but may be provided with more opportunities to override default or suggested workflows and settings.

[0222] In some implementations, computing system 208 can host applications and services 222 that automate or partially automate components of common V&V products; expected or common data transmissions, including components of data transmissions, from user 204: expected or common interfaces and / or data exchanges, including components of interfaces, between various DE tools 202; expected or common interfaces and / or data exchanges, including components of interfaces, with machine learning (ML) models implemented on computing system 208 (e.g., models trained and / or implemented by the ML engine 220); and expected or common interfaces and / or data exchanges between the applications and services themselves (e.g.. within applications and services layer 222).

[0223] In some implementations, the data from multiple uses of the ecosystem (or a portion of said data) can be aggregated to develop a training dataset. For example, usage records 217 collected via computing system 208 may be de-identified or anonymized, before being added to the training set. Such usage records may comprise model parameters and metadata, tool configurations, common V&V product matching to specific models or tools, user interactions with the system including inputs and actions, and other user-defined or system-defined configurations or decisions in using the ecosystem for digital engineering and certification. For instance, an exemplary de-identified usage record may comprise the combination of a specific DE tool, a specific target metric, a specific quantity deviation, and a corresponding specific user update to a DE model under this configuration. Another exemplary de-identified usage record may comprise a user-identified subset of DE tools 202 that should be used to satisfy a common V&V product of interest.

[0224] Uris training dataset can then be used to train ML models (e.g.. using ML engine 220) to learn the steps and actions for certification processes and to perform a variety of tasks including the identification of which of DE tools 202 to use to satisfy a particular common V&V product; the identification of specific models, tests, and / or simulations (including inputs to them) that should be performed using DE tools 202; the identification of the common V&V products that need to be considered for a product of a particular type; the identification of one or more recommended actions for user 204 to take in response to a failed regulatory requirement; the estimation of model / test / simulation sensitivity to particular inputs: etc. The outputs of the trained ML models can be used to implement various features of the interconnected digital engineering and certification ecosystem including automatically suggesting inputs (e.g., inputs to DE tools 202) based on previously entered inputs, forecasting time and cost requirements for developing a product, prcdictivcly estimating the results of sensitivity analyses, and even suggesting design changes, original designs or design alternatives (e.g., viaDocket No. IST-03.0t2PCT

[0225] assistive or generative Al) to a user’s prototype to overcome one or more requirements (e.g., regulatory and / or certification requirements) associated with a common V&V product. In some implementations, with enough training data, ML engine 220 may generate new designs, models, simulations, tests, common V&V products and / or digital threads on its own based on data collected from multiple uses of the ecosystem. Furthermore, such new designs, models, simulations, tests, common V&V products and digital threads generated by ML engine 220, once approved and adjusted by a user, may be added to the training set for further fine-tuning of ML algorithms in a reinforcement learning setup.

[0226] As shall be discussed in the context of Figs. 7 to 9, the aforementioned collection of training datasets and the training of ML and Al modules including ML engine 220 may be enabled by model splicing technologies. Model splicing, as described herein, allows the scripting of DE model operations encompassing disparate DE tools into a corpus of normative program code, and facilitates the code-defined digital threading of a large space of DE activities involving DE models across different disciplines. ML and Al techniques may be used to create scripts to cany out almost any DE task and to execute any digital thread, allowing for programmable, machine-learnable, and dynamic changes to DE model files, digital threads, and ultimately to digital or physical twins, throughout the product life cycle. For example, in the embodiment shown in Fig. 2, ML engine 220 may manage or orchestrate the interactions between spliced DE models, DE tools, and common V&V products (e.g., DE requirements), based on digital thread options specific to user's intent and input. Sample DE tasks that may be carried out by ML engine 220 include, but are not limited to, (1) aligning model s / analy sis to certification lifecycle requirement steps, (2) optimizing compute by determining the appropriate fidelity of each model, (3) optimizing compute resources for specific tools / models, or (4) optimizing compute resources across multiple models. ML-enabled executions of DE tasks are not limited to certification or resource optimization, but encompass the whole DE space of operations. Rather, ML engine 220 may act as an Al multiplexer for the DE platfonn.

[0227] In addition to storing usage data to enable the development of ML models, previous prototype designs and / or solutions (e.g., previously designed components, systems, models, simulations and / or other engineering representations thereof) can be stored within the ecosystem (e.g., in storage 218) to enable users to search for and build upon the work of others. For example, previously designed components, systems, models, simulations and / or other engineering representations thereof can be searched for by user 204 and / or suggested to user 204 by computing system 208 in order to satisfy one or more requirements associated with a common V&V product. The previously designed components, systems, models, simulations and / or other engineering representations thereof can be utilized by user 204 as is, or can be utilized as a starting point for additional modifications. This store, or repository, of previously designed components, systems, models, simulations and / or other engineering representationsDocket No. IST-03.012PCT

[0228] thereof (whether or not they were ultimately certified) can be monetized to create a marketplace of digital products, which can be utilized to save time during the digital product development process, inspire users with alternative design ideas, avoid duplicative efforts, and more. In some implementations, data corresponding to previous designs and / or solutions may only be stored if the user who developed the design and / or solution opts to share the data. In some implementations, the repository of previous designs and / or solutions can be containerized for private usage within a single company, team, organizational entity, or technical field for private usage (e.g., to avoid the unwanted disclosure of confidential information). In some implementations, user credentials associated with user 204 can be checked by computing system 208 to determine which designs and / or solutions stored in the repository can be accessed by user 204. In some implementations, usage of the previously designed components, systems, models, simulations and / or other engineering representations thereof may be available only to other users who pay a fee for a usage.

[0229] Exemplary IDEP Implementation Architecture with Services and Features

[0230] Fig. 3 shows another exemplar}' implementation of the IDEP illustrating its offered services and features, in accordance with some embodiments of the present invention. Specifically, an exemplary implementation architecture diagram 300 is shown in Fig. 3 to include multiple illustrative components: an IDEP enclave 302, cloud services 304, and a customer environment 310 which optionally includes an IDEP exclave 316. This exemplary architecture 300 for the IDEP is designed in accordance with zero-trust security principles and is further designed to support scalability as well as robust and resilient operations. IDEP enclave 302 and IDEP exclave 316 together instantiate IDEP 100 shown in Fig. 1, with IDEP exclave 316 implementing model splicing and splice plane 170 in some embodiments of the present invention. An enclave is an independent set of cloud resources that are partitioned to be accessed by a single customer (i.e., single -tenant) or market (i.e., multi-tenant) that does not take dependencies on resources in other enclaves. An exclave is a set of cloud resources outside enclaves managed by the IDEP, to perform work for individual customers. Examples of exclaves include virtual machines (VMs) and / or servers that the IDEP maintains to run DE tools for customers who need such services.

[0231] In particular, IDEP enclave or DE platform enclave 302 may serve as a starting point for sendees rendered by the IDEP, and may be visualized as a central command and control hub responsible for the management and orchestration of all platform operations. For example, enclave 302 may be implemented using computer system 208 of the interconnected DE and certification ecosystem shown in Fig. 2. DE platform enclave 302 is designed to integrate both zero-trust security models and hyperscale capabilities, resulting in a secure and scalable processing environment tailored to individual customer needs. Zero-trust security features include, but are not limited to, strict access control, algorithmic impartiality,Docket No. IST-03.0t2PCT

[0232] and data isolation. Enclave 302 also supports an ML engine such as 220 for real-time analytics, auto-scaling features for workload adaptability, and API-based interoperability with third-party services. Security and resource optimization are enhanced through multi-tenancy support, role-based access control, and data encryption both at rest and in transit. DE platfonn enclave 302 may also include one or more of the features described below.

[0233] First, IDEP enclave 302 may be designed in accordance with zero-trust security principles. In particular, DE platform enclave 302 may employ zero-trust principles to ensure that no implicit trust is assumed between any elements, such as digital models, platform agents or individual users (e.g., users 204) or their actions, within the system. That is, no agent may be inherently trusted and tire system may always authenticate or authorize for specific jobs. The model is further strengthened through strict access control mechanisms, limiting even the administrative team (e g., a team of individuals associated with the platform provider) to predetermined, restricted access to enclave resources. To augment this robust security stance, data encryption is applied both at rest and in transit, effectively mitigating risks of unauthorized access and data breaches.

[0234] IDEP enclave 302 can also be designed to maintain isolation and independence. A key aspect of the enclave’s architecture is its focus on impartiality and isolation. DE enclave 302 disallows cryptographic dependencies from external enclaves and enforces strong isolation policies. Tire enclave’s design also allows for both single-tenant and multi-tenant configurations, further strengthening data and process isolation between customers 306 (e.g., users 204). Additionally, DE enclave 302 is designed with decoupled resource sets, minimizing interdependencies and thereby promoting system efficiency and autonomy.

[0235] IDEP enclave 302 can further be designed for scalability and adaptability, aligning well with varying operational requirements. For example, the enclave 302 can incorporate hyperscale-like properties in conjunction with zero-trust principles to enable scalable growth and to handle high-performance workloads effectively.

[0236] IDEP enclave 302 can further be designed for workflow adaptability, accommodating varying customer workflows and DE models through strict access control mechanisms. This configurability allows for a modular approach to integrate different functionalities ranging from data ingestion to algorithm execution, without compromising on the zero-trust security posture. Platfonn 300's adaptability makes it highly versatile for a multitude of use-cases, while ensuring consistent performance and robust security.

[0237] IDEP enclave 302 can further be designed to enable analytics for robust platfonn operations. At the core of the enclave’s operational efficiency is a machine learning engine (e.g., machine learning engine 220) capable of performing real-time analytics. This enhances decision-making and operationalDocket No. IST-03.012PCT

[0238] efficiency across platform 300. Auto-scaling mechanisms can also be included to enable dynamic resource allocation based on workload demand, further adding to the platform’s responsiveness and efficiency.

[0239] In the exemplary embodiment shown in Fig. 3, IDEP enclave 302 includes several components as described in further detail herein.

[0240] A “Monitoring Service Cell, may provide “Monitoring Service” and “Telemetry Service.” A cell may refer to a set of microservices, for example, a set of microservices executing within a kubemetes pod. These components focus on maintaining, tracking and analyzing the performance of platform 300 to ensure good service delivery, including advanced machine learning capabilities for real-time analytics. A “Search Service Cell” provides “Search Service” to aid in the efficient retrieval of information from DE platfonn 300, adding to its overall functionality. A “Logging Service Cell” and a “Control Plane Service Cell” provide “Logging Service,” “File Service”, and “Job Service” to record and manage operational events and information flow within platform 300, and are instrumental in the functioning of platform 300. A“Static Assets Service Cell,” provides “Statics Service”, and may house user interface, SDKs, command line interface (CLI), and documentation for platform 300. An “API Gateway Sendee Cell” provides “API Gateway Service,” and may provide DE platfonn API(s) (e.g., APIs 214, 216) and act as a mediator for requests between the client applications (e g., DE tools 202, the repository of common V&V products 210, etc.) and the platform services. In some embodiments, the API gateway service cell may receive and respond to requests from agents such as DE platform exclave 316 to provide splice functions for model splicing purposes.

[0241] As shown in Fig. 3, the architecture of DE platform 300 may also include a cloud services 304 that provide services which cannot interact with customer data but can modify tire software for the orchestration of DE platfonn operations. In example implementations, several cloud resources provide support and foundational services to the platform. For example, in the embodiment of the DE platform 300 shown in Fig. 3, cloud services 304 includes a “Customer Identity and Access Management (IAM) Service” that ensures secure and controlled access to platform 300. Cloud services 304 also includes a “Test Service” that tests tools to validate platform operations. In the context of software testing, the Test Service can be thought of as the execution layer that manages and orchestrates the different types of tests on the platform. The Test Service may utilize the test scripts generated, and additionally has functionality to generate tests for specific U1 or API level testing. Cloud services 304 may also include an “Orchestration Service” that controls and manages the lifecycle of containers on the platform 300. Cloud services 304 may also include an “Artifact Service” and “Version Control and Build Services,” which may be used to maintain the evolution of projects, codes, and instances in the system, while also managing artifacts produced during the product development process.Docket No. IST-03.012PCT

[0242] As shown in Fig. 3, the architecture of DE platform 300 may also include a customer environment 310 with an “Authoritative Source of Truth” 312, customer tools 314, and an optional DE platform exclave 316. Customer environment 310 is where customer data resides and is processed in a zero-trust manner by DE platform 300. As described previously, DE platform enclave 302, by focusing on both zero-trust principles and hyperscale-like properties, provides a robust and scalable environment for the secure processing of significant workloads, according to the customer's unique needs. In some examples, DE platform exclave 316 may be situated within customer environment 310 in order to assist the customer(s) 306 with their DE tasks and operations, including model splicing and digital threading.

[0243] When a customer 306 (e.g., user 204) intends to perform a DE task using DE platform 300 (e.g., IDEP 100), typical operations may include secure data ingestion and controlled data retrieval. Derivative data generated through the DE operations, such as updated digital model files or revisions to digital model parameters, may be stored only within customer environment 310, and DE platfonn 300 may provide tools to access the metadata of the derivative data. Here metadata refers to data that can be viewed without opening the original data, and may comprise versioning information, time stamps, access control properties, and the like. Example implementations may include secure data ingestion, which utilizes zero-trust principles to ensure customer data is securely uploaded to customer environment 310 through a pre-validated secure tunnel, such as Secure Socket Layer (SSL) tunnel. This can enable direct and secure file transfer to a designated cloud storage, such as a simple storage service (S3) bucket, within customer environment 310. Example implementations may also include controlled data retrieval, in which temporary; pre -authenticated URLs generated via secure token-based mechanisms are used for controlled data access, thereby minimizing the risk of unauthorized interactions. Example implementations may also include immutable derivative data, with transformed data generated through operations like data extraction being securely stored within customer environment 310 while adhering to zero-trust security protocols. Example implementations may also include tokenization utility, in which a specialized DE platform tool referred to as a “tokenizer” is deployed within customer environment 310 for secure management of derivative metadata, conforming to zero-trust guidelines.

[0244] Customer environment 310 may interact with other elements of secure DE platform 300 and includes multiple features that handle data storage and secure interactions with platform 300. For example, one element of the customer environment 310 is “Authoritative Source of Truth” 312, which is a principal repository for customer data, ensuring data integrity and accuracy. Nested within this are “Customer Buckets” where data is securely stored with strict access controls, limiting data access to authorized users or processes through pre-authenticated URL links. This setup ensures uncompromising data security within customer environment 310 while providing smooth interactions with other elements of DE platform 300.Docket No. IST-03.012PCT

[0245] Customer environment 310 may also include additional software tools such as customer tools 314 that can be utilized based on specific customer requirements. For example, a “DE Tool Host” component may handle necessary DE applications for working with customer data. It may include a DE Tools Command-Line Interface (DET CLI), enabling user-friendly command-line operation of DE tools (e.g., DE tools 102). A “DE platform Agent” ensures smooth communication and management between customer environment 310 and elements of DE platform 300. Furthermore, there can be another set of optional DE tools designed to assist customer-specific DE workflows. Native DE tools are typically access-restricted by proprietary licenses and end-user license agreements paid for by tire customer. IDEP platform functions call upon native DE tools that are executed within customer environment 310, therefore closely adhering to the zero-trust principle of the system design. Exemplary DE tools include, but are not limited to, proprietary and open-source versions of model-based systems engineering (MBSE) tools, augmented reality (AR) tools, computer aided design (CAD) tools, data analytics tools, modeling and simulation (M&S) tools, product lifecycle management (PLM) tools, multi-attribute trade-space tools, simulation engines, requirements model tools, electronics model tools, test-plan model tools, cost-model tools, schedule model tools, supply-chain model tools, manufacturing model tools, cyber security model tools, or mission effects model tools.

[0246] In some cases, an optional “IDEP Exclave” 316 may be employed within customer environment 310 to assist with customer DE tasks and operations, supervise data processing, and rigorously adhering to zero-trust principles while delivering hyperscale-like platform performance. IDEP exclave 316 is maintained by the IDEP to run DE tools for customers who need such services. IDEP exclave 316 may contain a “DE Tool Host” that runs DE tools and a “DE Platform Agent” necessary for the operation. Again, native DE tools are typically access-restricted by proprietary licenses and end-user license agreements paid for by the customer. IDEP exclave 316 utilities and manages proprietary DE tools hosted with customer environment 310, for example, to implement model splicing and digital threading functionalities.

[0247] In some embodiments, the machine learning (ML) models and artificial intelligence (Al) assistance approaches as described herein adapt to suit different customer instances of the IDEP (see Fig.

[0248] 4) and the availability of training data. In an example, a pre-trained ML or Al model (e.g., within tire IDEP enclave 302) is deployed in instances where there are restrictions around sharing customer data. In another example, Al models are deployed in a federated manner adjacent to DE agents and DE tools in the customer environment (e.g., within IDEP exclave 316). In another example, an Al model deployed inside the customer environment is trained behind its firewalls. In yet another example, the customer may allow sharing of subsets of their metadata for a training database located within the IDEP enclave.Docket No. IST-03.012PCT

[0249] IDEP Deployment Scenarios

[0250] Fig. 4 shows potential scenarios for instantiating an IDEP in connection to a customer's physical system and IT environment, in accordance with some embodiments of the present invention. Specifically, Fig. 4 illustrates various potential configurations for instancing or instantiating an IDEP ("DE platform) 402 in connection to a customer's IT environment and physical system 404. The IT environment may be located on a virtual private cloud (VPC) protected by a firewall. The physical system may refer to a physical twin as discussed with reference to Fig. 1. In some embodiments, IDEP 402 may be instanced as an enclave such as 302 shown in Fig. 3. For example, IDEP 402 may be instanced on the cloud, possibly in a software-as-a-service (SaaS) configuration. The platform instances in these embodiments include software and algorithms, and may be described as follows:

[0251] 1. External Platfonn Instance 410: This option showcases the IDEP as a separate platform instance.

[0252] The platform interacts with the physical system through the customer's virtual environment, or a Customer Virtual Private Cloud (“Customer VPC”), which is connected to the physical system.

[0253] 2. External Platform Instance with Internal Agent 420: The IDEP is instantiated as a separate platform, connected to an internal agent (“DE Agent”) wholly instanced within the Customer VPC. For example, the IDEP may be instantiated as enclave 302, and the DE agent may be instantiated as exclave 316 within the Customer VPC linked to the physical system.

[0254] 3. External Platform Instance with Internal Agent and Edge Computing 430: This scenario displays the IDEP as a separate instantiation, connected to an internal DE Agent wholly instanced within the Customer VPC, which is further linked to an edge instance (“DE Edge Instance”) on the physical system. Tire DE agent is nested within tire customer environment, with a smaller edge computing instance attached to the physical system.

[0255] 4. Edge Instance Connection 440: This option shows the DE platform linked directly to an DE edge instance on the physical system. The DE platform and the physical system are depicted separately, connected by an edge computing instance in the middle, indicating the flow of data.

[0256] 5. Direct API Connection 450: This deployment scenario shows the DE platform connecting directly to the physical system via API calls. In this depiction, an arrow extends directly from the platfomi sphere to the physical system sphere, signifying a direct interaction through API.

[0257] 6. Air-Gapped Platfomi Instance 460: This scenario illustrates the IDEP being completely instanced on an air-gapped, or isolated, physical system as a DE agent. The platform operates independently from any networks or Internet connections, providing an additional layer of security by eliminating external access points and potential threats. Interaction with the platfomi in this context would occur directly on the physical system, with any data exchange outside die physicalDocket No. IST-03.012PCT

[0258] system being controlled following strict security protocols to maintain the air-gapped environment.

[0259] Across these deployment scenarios, the IDEP plays an important role in bridging the gap between a digital twin (DTw) established through the IDEP and its physical counterpart. Regardless of how the IDEP is instantiated, it interacts with the physical system, directly or through the customer's virtual environment. The use of edge computing instances in some scenarios demonstrates the need for localized data processing and the trade-offs between real-time analytics and more precise insights in digital -physical system management. Furthermore, tire ability of the platform to connect directly to the physical system through API calls underscores tire importance of interoperability in facilitating efficient data exchange between the digital and physical worlds. In all cases, the DE platform operates with robust security measures.

[0260] In some embodiments, the IDEP deployment for the same physical system can comprise a combination of the deployment scenarios described above. For example, for the same customer, some physical systems may have direct API connections to the DE platform (scenario 5), while other physical systems may have an edge instance connection (scenario 4).

[0261] Multimodal User Interfaces

[0262] Fig. 5 illustrates the use of multimodal user interfaces 590 for the interconnected DE platform, which can handle various input and output modalities such as Virtual Reality (VR), Mixed Reality (MR), auditory, text, and code. These interfaces are designed to manage the complexity of data streams and decision-making processes, and provide decision support including option visualization, impact prediction, and specific decision invocation. Specifically, data streams 502 and 504 are processed in the Analysis & Control Plane (ACP) 150 of Fig. 1. The user interface may receive data streams from physical and virtual feedback loops 102 and 104, as well as external expert feedback 114, analysis module 154, and twin configuration set 156 of ACP 150.

[0263] Tire multimodal interfaces illustrated in Fig. 5 are configured to carry out all the DE tasks and actions described in the context of Fig. 1, by catering to both humans and bots / algorithms, handling tire intricacies of data stream frequency and complexity, decision-making time scales, and latency impacts. In the case of human decision makers, the user interface may need to manage inputs and outputs while for algorithmic decision making, the user interface may need to present rationale and decision analysis to human users. Some examples of human interfaces include a dashboard-style interface 594, a workflow-based interface 596, conversational interfaces 598, spatial computer interfaces 592, and code interfaces 599.Docket No. IST-03.012PCT

[0264] Dashboard-style interface 594 offers a customizable overview of data visualizations, performance metrics, and system status indicators. It enables monitoring of relevant information, sectional review of documents, and decision-making based on dynamic data updates and external feedback. Such an interface may be accessible via web browsers and standalone applications on various devices.

[0265] Workflow -based interface 596 guides users through the decision-making process, presenting relevant data, options, and contextual information at each stage. It integrates external feedback and is designed as a progressive web app or a mobile app. In the context of alternative tool selection, workflow-based interface 596 may provide options on individual tools at each stage, or provide combinations of tool selections through various stages to achieve better accuracy or efficiency for the overall workflow.

[0266] Conversational interfaces 598 are based on the conversion of various input formats such as text, prompt, voice, audio-visual, etc. into input text, then integrating the resulting input text within the DE platform workflow. Outputs from the DE platform may undergo the reverse process. This enables interoperability with the DE platform, and specifically the manipulation of model splices. In the broad context of audio-visual inputs, the conversational interfaces may comprise data Bonification, which involves using sound to represent data, infomiation, or events, and using auditory cues or patterns to communicate important infomiation to users, operators, or reviewers. Sonified alerts (e.g.. alerts sent via sound, e.g., via a speaker) are especially useful when individuals need to process information quickly without having to visually focus on a screen. For example, sonified alerts can be used to notify security analysts of potential threats orbreaches.

[0267] According to the latest prior art, a “conversational interface” or “conversational user interface” refers to a human-computer interaction model that enables users to interact with digital systems through natural language, either via text or voice. These interfaces utilize advanced natural language processing (NLP), machine learning, and artificial intelligence technologies to understand and respond to user inputs in a manner that mimics human conversation. Conversational interfaces can take various forms, including chatbots, voice assistants, and messaging platforms, allowing users to communicate with systems using everyday language rather than traditional graphical user interface elements. The goal of these interfaces is to provide a more intuitive, accessible, and personalized user experience by leveraging the familiar paradigm of conversation, enabling users to accomplish tasks, retrieve infomiation, or control devices through natural dialogue without requiring specialized knowledge of complex commands or navigation structures.

[0268] Fig. 5 also illustrates the use of spatial computing interfaces 592 and code interfaces 599 in the management of DTws and PTws. Spatial computing interfaces allow for more immersive and intuitive user experiences, and enable real-time synchronization between DTws and PTws. Code interfaces allowDocket No. IST-03.0I2PCT

[0269] bots and digital engineers to interact with the DE platform through scripting and code. It also allows the collection of user preference, task history, and tool usage patterns for alternative tool selection purposes.

[0270] A “spatial interface” or “spatial user interface” refers to a user interaction paradigm that leverages three-dimensional space and spatial relationships to present and manipulate digital information. This approach goes beyond traditional 2D graphical user interfaces by incorporating depth, volume, and spatial positioning to create more intuitive and immersive user experiences. Spatial interfaces often utilize technologies such as augmented reality (AR), virtual reality (VR), or mixed reality (MR) to overlay digital content onto the physical world or create entirely virtual environments. These interfaces allow users to interact with digital objects and information as if they were physical entities in space, using natural gestures, body movements, direction of audio or eye gaze, and spatial awareness to navigate, manipulate, and organize content in ways that more closely mimic real-world interactions.

[0271] Note that in the context of multimodal interfaces. “2.5 dimension” (often referred to as 2.5D) describes a visual representation that falls between traditional 2D and full 3D interfaces. It typically involves adding depth and perspective to 2D elements to create a pseudo-3D effect, without fully rendering a complete 3D environment. The 2.5D approach is typically designed to create the illusion of depth and dimensionality on flat, two-dimensional displays such as computer monitors, smartphone screens, or tablets, although it may be used within a 3D setting (e.g., 2D screens overlaid into 3D). This approach often uses techniques such as layering, parallax scrolling, or isometric projections to give the illusion of depth and volume while maintaining the simplicity and familiarity of 2D interfaces.

[0272] Digital Threads and Autonomous Data Linkages

[0273] As discussed previously, a “digital thread” is intended to connect two or more digital engineering (DE) models for traceability across the systems engineering lifecycle, and collaboration and sharing among individuals performing DE tasks. In a digital thread, appropriate outputs from a preceding digital model may be provided as the inputs to a subsequent digital model, allowing for information and process flow. That is, a digital thread may be viewed as a communication framework or data-driven architecture that connects traditionally siloed elements to enable the flow of information and actions between digital models.

[0274] Fig. 6 describes the architecture and inherent complexity of digital threads, in accordance with the examples disclosed herein. Specifically, Fig. 6 is a schematic diagram comparing exemplary digital threads 600 of various complexities that manipulate and / or connect DE models, in accordance with some embodiments of the present invention. In the most basic sense, a digital thread may “thread” together DE models into a simple daisy-chain architecture 602 where modifications in any upstream DE model will affect all DE models downstream from the modified DE model. For example, a modification of anyDocket No. IST-03.0t2PCT

[0275] parameter or process of a DE model B will cause changes in DE model C, which in turn will cause changes in DE model D. Cause-and-effect changes will therefore cascade downstream. As another example, diagram 604 represents a more complex digital thread where a change in one DE model may affect more than one downstream model. In both 602 and 604, digital threads are represented by a directed acyclic graph (DAG).

[0276] DAGs are frequently used in many kinds of data processing and structuring tasks, such as scheduling tasks, data compression algorithms, and more. In the context of service platforms and network complexities, a DAG might be used to represent the relationships between different components or services within the platform. In digital thread 604, different models may depend on each other in different ways. Model A may affect models B, C, and D, with models B and C affecting model E, and models D and E affecting model G. Such dependencies are denoted as a DAG, where each node is associated with a component (e.g., a model), and each directed edge represents a dependency.

[0277] A major issue with dealing with interdependent DE models is that graph consistencies can be polynomial, and potentially exponential, in complexity. Hence, if a node fails (e.g., a model is unreliable), this can have a cascading effect on the rest of the digital thread, disrupting the entire design. Furthermore, adding nodes or dependencies to the graph does not yield a linear increase in complexity because of the interdependencies between models. If a new model is added that affects or depends on several existing models, the resulting increase in graph complexity is multiplicative in nature, hence potentially exponential. The multiplicative nature of digital thread consistencies is compounded by the sheer number of interconnected models, which may number in the hundreds or thousands. Diagram 606 is a partial representation of a real-world digital thread, illustrating the complexity of digital threads and its multiplicative growth.

[0278] Fig. 6 further shows special cases 603, 605, 607, 608, and 609 of exemplary simple digital threads. Diagram 607 represents a degenerate digital thread where data is shared from a single DE model. Diagram 608 represents a model-to-document digital thread where data (e.g., system attributes, performance attributes) extracted from a single DE model may be used to generate or update a text-based document (e.g., a Capability Development Document (CDD)). Diagrams 603 and 605 are generalized from 608 to represent cases where data extracted from a single model may be used to update multiple models, or vice versa. Specifically, diagram 605 may represent tire dynamic updates of live or magic documents discussed in the context of Fig. 1. Here, the logic to connect the DE models shown is clear: data are extracted from multiple DE models A, B, and C to update a document model D. There are no interactions between the extracted data. Furthermore, diagram 609 shows a special case of a digital thread where data is loaded to and extracted from only a single model A. For example, as discussed in the context of Fig. 7 next, input splice functions of the model A shown in 609 may be executed to update theDocket No. IST-03.012PCT

[0279] model, and output splice functions of model A shown in 609 may be executed to produce digital artifacts for sharing. For these special simple threads, the IDEP may provide a GUI -based interface to the user to connect the models and execute tire digital threads. For complex threads such as 606, a code-based interface may be necessary.

[0280] Model Splicing for Digital Threading and Digital Twin Generation

[0281] As disclosed herein, model splicing encapsulates and compartmentalizes digital engineering (DE) model data and model data manipulation and access functionalities. As such, model splices provide access to selective model data within a DE model fde without exposing the entire DE model file, with access control to the encapsulated model data based on user access permissions. Model splicing also provides the DE model with a common, extemally-accessible Application Programming Interface (API) for the programmatic execution of DE models. Model splices thus generated may be shared, executed, revised, or further spliced independently of the native DE tool and development platform used to generate the input digital model. The standardization of DE model data and the generalization of API interfaces and functions allow the access of DE model type files outside of their native software environments, and enable the linking of different DE model type files that may not previously be interoperable. Model splicing further enables the scripting and codification of DE operations encompassing disparate DE tools into a corpus of normative program code, facilitating the generation and training of artificial intelligence (Al) and machine learning (ML) models for the purpose of manipulating DE models through various DE tools across different stages of a DE process, DE workflow, or a DE life cycle.

[0282] Digital threads are created through user-directed and / or autonomous linking of model splices. A digital thread is intended to connect two or more DE models for traceability across the systems engineering life cycle, and collaboration and sharing among individuals performing DE tasks. In a digital thread, appropriate outputs from a preceding digital model are provided as inputs to a subsequent digital model, allowing for information flow. That is, a digital thread may be viewed as a communication framework or data-driven architecture that connects traditionally siloed elements to enable tire flow of infomration between digital models. The extensibility of model splicing over many different types of DE models and DE tools enables the scaling and generalization of digital threads to represent each and every stage of the DE life cycle.

[0283] A digital twin (DTw) is a real-time virtual replica of a physical object or system, with bi-directional information flow between the virtual and physical domains, allowing for monitoring, analysis, and optimization. Model splicing allows for making individual DE model files into executable splices that can be autonomously and securely linked, thus enabling the management of a large number of DE models as a unified digital thread. Such a capability extends to link previously non-interoperable DEDocket No. IST-03.012PCT

[0284] models to create digital threads, receive external performance and sensor data streams (e.g., data that is aggregated from DE models or linked from physical sensor data), calibrate digital twins with data streams from physical sensors outside of native DTw environments, and receive expert feedback that provides opportunity to refine simulations and model parameters.

[0285] Unlike a DTw, a virtual replica, or simulation, is a mathematical model that imitates real-world behavior to predict outcomes and test strategies. Digital twins use real-time data and have bidirectional communication, while simulations focus on analyzing scenarios and predicting results. In other words, a DTw reflects the state of a physical system in time and space. A simulation is a set of operations done on digital models that reflects the potential future states or outcomes that the digital models can progress to in the future. A simulation model is a DE model within the context of the IDEP as disclosed herein.

[0286] When testing different designs, such as variations in wing length or chord dimensions, multiple DTws (sometimes numbering in 100s to 1,000s) may be created, as a bridge between design specifications and real-world implementations of a system, allowing for seamless updates and tracking of variations through vast numbers of variables, as detailed in the context of Fig. 1. As an example, if three variations of a system are made, each one would have its own DTw with specific measurements. These DTws may be accessed and updated via API function scripts, which allow for easy input of new measurements from the physical parts during the manufacturing process. By autonomous linking with appropriate data, a DTw may be updated to reflect the actual measurements of the parts, maintaining traceability and ensuring accurate data representation through hundreds or thousands of models.

[0287] Exemplary Model Splicing Setup

[0288] Fig. 7 is a schematic 700 showing an exemplary model splicing setup, according to some embodiments of the present invention. Specifically, Fig. 7 is a schematic showing an embedded CAD model splicing example.

[0289] In the present disclosure, a “model splice”, “model wrapper”, or “model graft” of a given DE model file comprises locators to or copies of (1) DE model data or digital artifacts extracted or derived from the DE model file, including model metadata, and (2) splice functions (e.g., API function scripts) that can be applied to the DE model data. A model splice may take on the fonn of a digital file or a group of digital files. A locator refers to links, addresses, pointers, indexes, access keys, Uniform Resource Locators (URL) or similar references to the aforementioned DE digital artifacts and splice functions, which themselves may be stored in access-controlled databases, cloud-based storage buckets, or other types of secure storage environments. The splice functions provide unified and standardized input and output API or SDK endpoints for accessing and manipulating the DE model data. The DE model data arc model-type-specific, and a model splice is associated with model-type-specific input and output schemas.Docket No. IST-03.012PCT

[0290] One or more different model splices may be generated from the same input DE model file, based on the particular user application under consideration, and depending on data access restrictions. In some contexts, the shorter terms “splice”, “wrapper”, and / or “graft” are used to refer to spliced, wrapped, and / or grafted models.

[0291] Model splicing is the process of generating a model splice from a DE model file. Correspondingly, model splicers are program codes or uncompiled scripts that perform model splicing of DE models. A DE model splicer for a given DE model type, when applied to a specific DE model file of the DE model type, retrieves, extracts, and / or derives DE model data associated with the DE model file, generates and / or encapsulates splice functions, and instantiates API or SDK endpoints to the DE model according to input / output schemas. In some embodiments, a model splicer comprises a collection of API function scripts that can be used as templates to generate DE model splices. “Model splicer generation” refers to the process of setting up a model splicer, including establishing an all-encompassing framework or template, from which individual model splices may be deduced.

[0292] Thus, a DE model type-specific model splicer extracts or derives model data from a DE model file and / or stores such model data in a model type-specific data structure. A DE model splicer further generates or enumerates splice functions that may call upon native DE tools and API functions for application on DE model data. A DE model splice for a given user application contains or wraps DE model data and splice functions that are specific to the user application, allowing only access to and enabling modifications of limited portions of the original DE model file for collaboration and sharing with stakeholders of the given user application.

[0293] Additionally, a document splicer is a particular type of DE model splicer, specific to document models. A “document” is an electronic file that provides information as an official record. Documents include human-readable files that can be read without specialized software, as well as machine-readable documents that can be viewed and manipulated by a human with the help of specialized software such as word processor and / or web services. Thus, a document may contain natural language-based text and / or graphics that are directly readable by a human without the need of additional machine compilation, rendering, visualization, or interpretation. A “document splice”, “document model splice” or “document wrapper” for a given user application can be generated by wrapping document data and splice functions (e.g., API function scripts) that are specific to the user application, thus revealing text at the component or part (e.g., title, table of contents, chapter, section, paragraph) level via API or SDK endpoints, and allowing access to and enabling modifications of portions of an original document or document template for collaboration and sharing with stakeholders of the given user application, while minimizing manual referencing and human errors.Docket No. IST-03.012PCT

[0294] In the CAD model splicing example shown in Fig. 7, a CAD model file diesel-engine. prt 704 proceeds through a model splicing process 710 that comprises a data extraction step 720 and a splice function generation step 730. This input DE model 704 is in a file format .prt native to certain DE tools. Data extraction may be performed via a DE model crawling agent implemented as model crawling scripts within a model splicer to crawl through the input DE model file and to distill model data with metadata 722. Metadata are data that can be viewed without opening the entire input DE model file, and may include entries such as file name, file size, file version, last modified date and time, and potential user input options as identified from a user input 706. Model data are extracted and / or derived from the input DE model, and may include but are not limited to, parts (e.g., propeller, engine cylinder, engine cap, engine radiator, etc.), solids, surfaces, polygon representation, and materials, etc. When a model splicer crawls through the model file, it detennines how model data may be organized and accessed, as fundamentally defined by a DE tool 702 that is being used in splicing the DE model, and establishes a model data schema. This data schema describes the structure and format of the model data, some of which are translated into, or used to create input / output API endpoints with corresponding input / output schemas. In some embodiments, model data with metadata 722 may be stored in an access-restricted storage 726, such as the “customer buckets” 312 within customer environment 310 in Fig. 3, so that model splices such as 742, 744, and 746 may be generated on-demand once an input DE model 704 has been crawled through.

[0295] The model splicer further generates splice functions (e.g., API function scripts) 732 from native APIs 702 associated with the input CAD model. In the present disclosure, “native” and “primal” refer to existing DE model files, functions, and API libraries associated with specific third-party DE tools, including both proprietary and open-source ones. Native API 702 may be provided by a proprietary or open-source DE tool. For example, the model splicer may generate API function scripts that call upon native APIs of native DE tools to perform functions such as: HideParts(parts Jist), Generate 2DView(), etc. These model-type-specific splice functions may be stored in a splice function database 736, again for on-demand generation of individual model splices. A catalog or specification of splice functions provided by different model splices supported by the IDEP, and orchestration scripts that link multiple model splices, constitutes a Platform API. This platfonn API is a common, universal, and extemally-accessible platform interface that masks native API 702 of any native DE tool integrated into the IDEP, thus enabling engineers from different disciplines to interact with unfamiliar DE tools, and previously non-interoperable DE tools to interoperate freely.

[0296] Next, based on user input or desired user application 706, one or more model splices or wrappers 742, 744, and 746 may be generated, wrapping a subset or all of the model data needed for the user application with splice functions or API function scripts that can be applied to the original input modelDocket No. IST-03.0t2PCT

[0297] and / or wrapped model data to perform desired operations and complete user-requested tasks. In various embodiments, a model splice may take on the form of a digital file or a group of digital files, and a model splice may comprise locators to or copies of the aforementioned DE digital artifacts and splice functions, in any combination or pennutation. Any number of model splices / wrappers may be generated by combining a selective portion of the model data such as 722 and the API function scripts such as 732. As the API function scripts provide unified and standardized input and output API endpoints for accessing and manipulating the DE model and DE model data, such API handles or endpoints may be used to execute the model splice and establish links with other model splices without directly calling upon native APIs. Such API endpoints may be formatted according to an input / output scheme tailored to the DE model file and / or DE tool being used, and may be accessed by orchestration scripts or platfomr applications that act on multiple DE models.

[0298] In some embodiments, when executed, an API function script inputs into or outputs from a DE model or DE model splice. '‘Input” splice functions or '‘input nodes” such as 733 are model modification scripts that allow updates or modifications to an input DE model. For example, a model update may comprise changes made via an input splice function to model parameters or configurations. “Output” splice functions or “output nodes” 734 are data / artifact extraction scripts that allow data extraction or derivation from a DE model via its model splice. An API function script may invoke native API function calls of native DE tools. An artifact is an execution result from an output API function script within a model splice. Multiple artifacts may be generated from a single DE model or DE model splice. Artifacts may be stored in access-restricted cloud storage 726, or other similar access-restricted customer buckets.

[0299] One advantage of model splicing is its inherent minimal privileged access control capabilities for zero-trust implementations of the IDEP as disclosed herein. In various deployment scenarios discussed with reference to Fig. 4, and within the context of IDEP implementation architecture discussed with reference to Fig. 3, original DE input model 704 and model data storage 726 may be located within customer buckets 312 in customer environment 310 of Fig. 3. Splice functions 732 stored in database 736 call upon native APIs 702. The execution or invocation of splice functions 732 may rely on job-specific authentication or authorization via proprietary' licenses of DE tools (e.g., residing within customer environment 310 of Fig. 3 and / or information security clearance levels of the requesting user. Tirus, model splicing unbundles monolithic access to digital model-type files as whole files and instead provides specific access to a subset of functions that allow limited, purposefill, and auditable interactions with subsets of the model-type files built from component parts or atomic units that assemble to parts.

[0300] Digital Threading of DE Models via Model SplicingDocket No. IST-03.012PCT

[0301] Fig. 8 is a schematic showing digital threading of DE models via model splicing, according to some embodiments of the present invention. A digital thread is intended to connect two or more DE models for traceability across the systems engineering lifecycle, and collaboration and sharing among individuals performing DE tasks.

[0302] Linking of model splices generally refers to jointly accessing two or more DE model splices via API endpoints or splice functions. For example, data may be retrieved from one splice to update another splice (e.g., an input splice function of a first model splice calls upon an output splice function of a second model splice); data may be retrieved from both splices to generate a new output (e.g., output splice functions from both model splices are called upon); data from a third splice may be used to update both a first splice and a second splice (e.g., input splice functions from both model splices are called upon). In the present disclosure, “model linking” and “model splice linking” may be used interchangeably, as linked model splices map to correspondingly linked DE models. Similarly, linking of DE tools generally refers to jointly accessing two or more DE tools via model splices, where model splice functions that encapsulate disparate DE tool functions may interoperate and call each other, or be called upon jointly by an orchestration script to perform a DE task.

[0303] Thus, model splicing allows for making individual digital model files into model splices that can be autonomously and securely linked, enabling the management of a large number of digital models as a unified digital thread written in scripts. Within the IDEP as disclosed herein, a digital thread is a platform script that calls upon the platform API to facilitate, manage, or orchestrate a workflow through linked model splices. Model splice linking provides a communication framework or data-driven architecture that connects traditionally siloed elements to enable the flow of information between digital models via corresponding model splices. Tire extensibility of model splicing over many different types of digital models enables the scaling and generalization of digital threads to represent each and every stage of the DE lifecycle and to instantiate and update DTws as needed.

[0304] In the particular example shown in Fig. 8, an orchestration script 894 is written in Python code and designed to interact via API endpoints such as 892 to determine if a CAD model meets a total mass requirement. API endpoint 892 is an output splice function and part of a platform API 890. Platform API 890 comprises not only splice functions but also platform scripts or orchestration scripts such as 894 itself.

[0305] Orchestration script 894 is divided into three main steps:

[0306] 1. Get Data From a CAD Model Splice: A POST request may be sent via the IDEP platform API to execute a computer-aided design (CAD) model splice 871. This model splice provides a uniform interface to modify and retrieve infonnation about a CAD model 881. The parameters for the CAD model, such as hole diameter, notch opening, flange thickness, etc., may be sent in theDocket No. IST-03.012PCT

[0307] request and set via an input splice function. The total mass of the CAD model may be derived from model parameters and retrieved via an output splice function. The response from the platform API includes the total mass of CAD model 881, and a Uniform Resource Identifier / Locator (URL) for the CAD model. Tire response may further comprise a URL for an image of the CAD model.

[0308] 2. Get Data From a SvsML Model Splice: Another POST request may be sent via the IDEP platform API to execute a Systems Modeling Language (SysML) model splice 872. SysML is a general-purpose modeling language used for systems engineering. Output function 892 of model splice 872 retrieves the total mass requirements for the system from a SysML model 882. The response from the platform API includes the total mass requirement for the system.

[0309] 3. Align the Variables and Check If Requirement Met: Hie total mass from CAD model 881 is compared with the total mass requirement from SysML model 882. If the two values are equal, a message is printed indicating that the CAD model aligns with the requirement. Otherwise, a message is printed indicating that the CAD model does not align with the requirement.

[0310] In short, orchestration script 894, which may be implemented in application plane 160 of IDEP 100 shown in Fig. 1, links digital models 881 and 882 via model splice API calls. Orchestration script 894 is a scripted platfonn application that modifies a CAD model, retrieves the total mass of the modified CAD model, retrieves the total mass requirement from a SysML model, and compares the two values to check if the CAD model meets the requirement. In some embodiments, a platform application within IDEP 100 utilizes sets of functions to act upon more than one DE model.

[0311] Model Splice Plane

[0312] Fig. 9 is a schematic illustrating the linking of DE model splices in a splice plane and comparing digital threading with and without model splicing, according to some embodiments of the present invention. The bottom model plane 180 demonstrates current digital threading practices, where each small oval represents a DE model, and the linking between any two DE models, such as models 982 and 984, requires respective connections to a central platform 910, and potential additional linkages from every model to every other model. Hie central platform 910 comprises program code that is able to interpret and manipulate original DE models of distinct model types. For example, platfonn 910 under the control of a subject matter expert may prepare data from digital model 982 into formats that can be accessed by digital model 984 via digital model 984’s native APIs, thus allowing modifications of digital model 982 to be propagated to digital model 984. Any feedback from digital model 984 to digital model 982 would require similar processing via platform 910 so that data from digital model 984 arc converted into fonnats that can be accessed by digital model 982 via digital model 982’s native APIs. This hub-and-spokeDocket No. IST-03.012PCT

[0313] architecture 934 is not scalable to the sheer number (e.g., hundreds or thousands) of digital models involved within typical large-scale DE projects, as model updates and feedback are only possible through central platform 910.

[0314] In contrast, once the DE models are spliced, each original model is represented by a model splice including relevant model data, unified and standardized API endpoints for input / output, as shown in the upper splice plane 170. Splices within splice plane 170 may be connected through scripts (e.g., python scripts) that call upon API endpoints or API function scripts and may follow a DAG architecture, as described with reference to Fig. 1 and Fig. 6. Note that in Fig. 1, only a set of generated splices is shown within splice plane 170, while in Fig. 9, scripts that link model splices are also shown for illustrative purposes within the splice plane. Such scripts are referred to as orchestration scripts or platform scripts in this disclosure, as they orchestrate workflow through a digital thread built upon interconnected DE model splices. Further note that while splice plane 170 is shown in Fig. 1 as part of IDEP 100 for illustrative purposes, in some embodiments, splice plane 170 may be implemented behind a customer firewall and be part of an agent of the DE platform, as discussed in various deployment scenarios shown in Fig. 4. That is, individual API function scripts generated via model splicing by a DE platform agent may be tailored to call upon proprietary tools tire customer has access to in its private environment. No centralized platform 910 with proprietary access to all native tools associated with all individual digital models shown in Fig. 9 is needed. Instead, orchestration scripts call upon platform API function scripts that may be implemented differently in different customer environments.

[0315] Hence, model splicing allows model splices such as model splice 972 from digital model 982 and model splice 974 from digital model 984 to access each other’s data purposefully and directly, thus enabling the creation of a model-based “digital mesh” 944 via platform scripts and allowing autonomous linking without input from subject matter experts.

[0316] An added advantage of moving from the model plane 180 to the splice plane 170 is that the DE platform enables the creation of multiple splices per native model (e.g., see Fig. 7), each with different subsets of model data and API endpoints tailored to the splice’s targeted use. For example, model splices may be used to generate multiple digital twins (DTws) that map a physical product or process or object design into the virtual space. Two-way data exchanges between a physical object and its digital object twin enable the testing, optimization, verification, and validation of the physical object in the virtual world, by choosing optimal digital model configuration and / or architecture combinations from parallel digital twins built upon model splices, each reacting potentially differently to the same feedback from the physical object.

[0317] Supported by model splicing, digital threading, and digital twinning capabilities, the IDEP as disclosed herein connects DE models and DE tools to enable simple and secure collaboration on digitalDocket No. IST-03.012PCT

[0318] engineering data across engineering disciplines, tool vendors, networks, and model sources such as government agencies and institutions, special program offices, contractors, small businesses, Federally Funded Research and Development Centers (FFRDC), University Affiliated Research Centers (UARC), and the like. An application example 950 for the IDEP is shown on the right side of Fig. 9, illustrating how data from many different organizations may be integrated to enable cross-domain collaboration while maintaining data security, traceability, and auditability. Here DE models from multiple vendors or component constructors are spliced or wrapped by IDEP agents, and data artifacts are extracted with data protection. Turning DE models into data artifacts enables cross-domain data transfer and allows for the protection of critical information, so that model owners retain complete control over their DE models using their existing security and IT stack, continue to use DE tools that best fit their purposes, and also preserve the same modeling schema / ontology / profile that best fit their purposes. The IDEP turns DE models into micro-services to provide minimally privileged data bits that traverse to relevant stakeholders without the DE models ever leaving their home servers or being duplicated or surrogate. The IDEP also provides simple data access and digital threading options via secure web applications or secure APIs.

[0319] DAG Representation of Threaded Tasks

[0320] Model splicing provides a unified interface among DE models, allowing model and system updates to be represented by interconnected and pipelined DE tasks. Fig. 10 shows an exemplary directed acyclic graph (DAG) representation 1000 of pipelined DE tasks related to digital threads, in accordance with some embodiments of the present invention. In diagram 1000, tasks performed through a digital thread orchestration script (e.g., 894) are structured as nodes within a DAG. Actions are therefore interconnected and carried out in a pipeline linking the DE model splices with a range of corresponding parameter values. Therefore, a digital thread can be created by establishing, via interpretable DE platform scripts, the right connections between any model splices for their corresponding models at the relevant endpoints.

[0321] Referring to Figs. 1 and 8, DAGs of threaded tasks are built from digital threads and are part of the DE platform's application plane 160. Different DAGs may target different DE actions. For example, in Fig. 1, building or updating a DTw 122 in the virtual environment 120 has its own DAG 124. Model splicing turns DE models into data structures that can be accessed via API. thus enabling the use of software development tools, from simple python scripts to complex DAGs, in order to execute DE actions. A digital thread of model splices eliminates the scalability issue of digital thread management, and speeds up the digital design process, including design updates based on external feedback.Docket No. IST-03.012PCT

[0322] Inner / Outer Loop Architecture for Digital Threads in Cyber-Physical Systems

[0323] Fig. 11 is an exemplary' schematic 1100 illustrating the interplay between a digital thread and the individual digital models or digital artifacts it uses, thus defining outer and inner loop processes, in accordance with some embodiments of the present invention.

[0324] In various embodiments of the IDMP, the architecture for managing digital threads and their associated digital models in cyber-physical systems involves an interaction between an Outer Loop (representing the digital thread) and an Inner Loop (representing individual models or artifacts). This structure enables secure, permission-based collaboration across multiple models, ensuring traceability, controlled data flow, and efficient interaction within the digital workflow. Based on software engineering principles, this inner / outer loop design is modular: the Outer Loop manages high-level coordination and communication, while the Inner Loop handles tire detailed, iterative operations of each model or system. While the Outer Loop and Inner Loop interactions commonly seen in software packages may involve access to all of the software packages within the same Integrated Development Environment (IDE), the Outer Loop / Inner Loop interactions for cyber-physical systems must manage to link interoperably with different digital models and tools, while also ensuring zero trust security. Various embodiments of the IDMP are well suited to manage such digital threads for cyber-physical systems as the platform is able to interoperably link with various digital models and tools (in different Inner Loops) through the model splicer architecture (see Figs. 7 and 8). Additionally, tire IDMP uses zero trust and zero knowledge security, ensuring that every interaction, whether within the same security network or across different networks, is strictly authorized, while keeping sensitive data private (e.g., through tokenization).

[0325] In tire embodiment shown in 1110, an Outer Loop 1104 manages the sequence of tasks in a digital workflow, where user actions are authorized for access through a process 1120 in an Inner Loop 1116. Outer Loop 1104 can issue instructions to Inner Loop 1116 to:

[0326] • Create models by defining structure, behavior, and parameters.

[0327] • Fetch data artifacts from a model .

[0328] • Update artifacts with controlled, traceable changes.

[0329] For example, when Outer Loop 1104 commands a data artifact retrieval, the IDMP platform may manage it using zero trust principles, as described in Fig. 3. Each user request in Outer Loop 1104 is authorized through an enclave 302 and its Control Plane sendee cell, coordinated with platfonn exclave 316. Different Inner Loops exist within Customer Tools 314, each operating in specific Customer Environments 310 where each request is authorized for access to the necessary data operations.

[0330] After retrieving data artifacts from Inner Loop 1116, Outer Loop 1104 handles configuration control 1106, versioning, and integrates the artifacts into the broader digital thread 1108 for testing or validation at a process step 1112.Docket No. IST-03.012PCT

[0331] Inner Loop 1116, by contrast, is responsible for localized operations related to individual digital models, including:

[0332] • Model creation, where digital models are initialized or updated.

[0333] • Model execution, through automation, simulations or data analysis.

[0334] • Saving results, preserving outcomes from model runs.

[0335] • Analyzing data, providing insights and validation for digital workflow improvements. Outer Loop 1104 interacts with any step in Inner Loop 1116 to access or update data artifacts. Outer loop computations often compare the current workflow to a baseline 1110.

[0336] Outer and Inner Loops 1104 and 1116 work together in an iterative process, integrating localized model adjustments with system-wide digital workflow coordination and validation. The Outer Loop manages tasks like configuration control, system integration, and VVUQ (Verification, Validation, and Uncertainty Quantification), while the Inner Loop handles model-based operations. Fig. 11 shows the Outer Loop performing authorized access 1120, configuration control 1106, digital thread integration 1108, and VVUQ / testing 1112. In various implementations of digital threads in the ID MP, these steps can vary in sequence or iterate as needed. Ultimately, the outer and inner loop architecture enables continuous integration and development (CI / CD) of digital workflows and digital threads across the digital platform.

[0337] Decentralized Digital Threads in the 1DMP

[0338] The IDMP enables decentralized management of digital threads across different models, security networks, and user permissions under a zero trust security principle. This architecture enforces strict access controls and permission-based interactions between models, ensuring security across diverse environments. In some embodiments, a zero knowledge approach further secures sensitive data during orchestration, ensuring no unauthorized access (e.g.. by using tokenization).

[0339] In Fig. 11, two exemplary setups 1122 and 1132 illustrate IDMP embodiments with decentralized digital threads across different security networks. In 1122, Outer Loop 1 operates within Security Network 1, connecting to multiple Inner Loops (e.g., Inner Loop 1, Inner Loop 2, and Inner Loop 3). These Inner Loops manage data operations within tire same security framew ork, allowing collaboration while maintaining security.

[0340] In 1132, Outer Loop 2 operates in a separate Security Network 2. linking to additional Inner Loops (e.g.. Inner Loop 4, Inner Loop 5, and Inner Loop 6). For links from Outer Loop 1, dotted lines and "X" symbols represent isolated models or components, indicating access restrictions enforced by the zero trust framework. Only authenticated users can access authorized models and artifacts.

[0341] In various implementations, 1122 and 1132 can be regarded as different instances of the Customer environment 310 shown in Fig. 3.Docket No. IST-03.012PCT

[0342] In the IDMP, digital threads handle both simple and complex model connections. Fig. 6 shows simple threads with sequential model links (e.g., 602, 604), while the more complex thread 606 is shown in Fig. 11 as an illustrative element 1142. Simple threads propagate changes in a linear fashion, while complex threads manage branching dependencies, where changes in one model affect multiple downstream models. In complex threads implemented by the IDMP, the Outer Loop coordinates interactions across multiple Outer loops and Inner loops, ensuring secure, scalable execution of the entire digital workflow with appropriate permission controls.

[0343] Converting Digital Workflows into Digital Threads with Data Relationships

[0344] Tire IDMP links different types of digital model files in a decentralized fashion with zero-trust security. When a user requests a data operation on a digital model file using a specific digital tool, IDMP executes the request via digital tool-specific and platform agents within the customer's environment. These agents extract data artifacts and, when changes to a digital artifact occur, a newer version of the digital model file is made. During the versioning step, platform agents ensure sensitive data is protected through tokenized version control.

[0345] Extracted data artifacts are securely stored in the customer's cloud data storage (e.g., an S3 bucket). If changes are made to the digital model, the agents save the updated version of the model or data artifact, extract the relevant data artifacts, and store it securely.

[0346] Using the IDMP, users are able to link data artifacts into a magic doc for documentation and commentary; which can include Al-assistance in various embodiments. A digital thread accompanying the magic doc lists data artifacts in sequence, creating a digital workflow. The IDMP further tracks data relationships between data artifacts (e.g., derivation, grouping, or data flow). Uris digital workflow of user actions and data relationships is stored in a non-proprietary fonnat within tire customer’s environment.

[0347] Emergent digital workflows and sequence of tasks captured by data relationships of various types:

[0348] 1. Generational - (Between version 1 and version 2 of a model)

[0349] 2. Parent / Child - (Tire Model and Derived infonnation from a model)

[0350] 3. Sibling - (Different bits of derived data from the same model (e.g., an image view of a CAD model and an associated parameter)

[0351] 4. Generational (derived) - The same piece of data extracted from version 1 or version 2 of a model

[0352] 5. Data Context (Connected by how they are used for a mission or business purpose in a Magic Doc)

[0353] 6. Data Flow (Connected via digital threads - data from one model into another)Docket No. IST-03.012PCT

[0354] Such data relationships can van7from one user to another even for the same overall digital workflow task.

[0355] Converting Digital Workflows into Digital Thread Scripts in an API-First Manner

[0356] Fig. 12 illustrates an exemplary digital engineering process in the aerospace industry, showing outer loop processes, according to one embodiment of the present invention. The left of Fig. 12 contains a simplified depiction 1202 of current engineering processes related to a digital engineering operation in the aerospace industry. The digital platform is instrumental in mapping those processes 1204 to digitized (software-defined) workflows. Each process step may be connected to software-defined digital threads (outer loop) using Git Workbooks or Runbooks. The generated workflows may belong to tire inner or outer loops, as depicted in Fig. 11. For completeness and compliance, the digital platfonn may further add tests for the key steps and tasks of the digitized workflows in the outer loop 1206. These outer-loop threads incorporate built-in feature tests and unit tests, ensuring the digital thread is validated as it is being created. Finally, the scripts for the digital threads are executed, generating outputs that can be presented as dynamic reports, such as magic docs, linked to digital models or data artifacts. The digital platfonn may hence generate dynamic reports 1208 (e.g., Magic Docs) linked to the inner-loop models used by tire digital workflows. In various implementations, the IDMP adopts an API-first approach, where digital workflows are structured around secure and modular API integrations. In the IDMP, digital threads link to specific data artifacts through authorized API endpoints in a zero-trust framework, ensuring secure access. Process steps are connected to software-defined workflows using tools like Git Workbooks or Runbooks, with user intent driving both platform and tool-specific API calls. This approach enables seamless integration, modularity, and validation, with built-in feature and unit tests ensuring the reliability of each API interaction throughout the system.

[0357] Digital Model Splicing and Document Model Splicing Examples

[0358] To illustrate the similarities between digital model splicing and document splicing, Fig. 13 shows an illustrative example of CAD model splicing result within the IDMP, in accordance with some embodiments of the present invention. In this example, an input CAD file 1300 for a propeller engine is spliced into model data and splice functions written as scripts that call upon native digital tool APIs. Exemplary model data are shown in an GUI interface 1310 with input parameter fields on the left, and an output visualization on the right. Data schemas and / or API scripts may be accessed via a separate tab 1320 in the GUI, listing input schemas and output schemas for API endpoints to pass needed values into the CAD model, or for providing output locations of modified native files.Docket No. IST-03.012PCT

[0359] By comparison. Fig. 14 shows an illustrative example of document splicing or document model splicing within the IDMP, in accordance with some embodiments of the present invention. Fig. 14 is structured similarly to Fig. 13. During document splicing, an input document file is first parsed into chunks, parts, subunits, or components, with or without hierarchy, and each with at least one API endpoint for access and handling. In this illustrative example shown in Fig. 14, an input document 1400 is written in paragraph fonn, in text only, and parsed, divided, or segmented into individual paragraphs as delineated by carriage returns and paragraph spacing. In various embodiments, document parts or subunits may be classified according to type, structural form, formatting, spacing, syntax, sectioning, content, theme, or any other predefined or user-defined rules. For example, a subunit may be a structural component such as a title, a chapter, a section, a subsection, a paragraph, a sentence, a word, a sheet, a page, a line, a comment, a hyperlink, a table, a graph, an image, an equation, and sub-parts thereof. In some embodiments, parts or subunits of the same structural form may be of different types, for example, title, version number line, author line and publisher line: table of contents, table of numerical parameters: sections, subsections; header, footers; front cover, back cover; stakeholder name field, signature field, and the like. In some embodiments, an LLM may be deployed to understand user-defined rules for splicing a document. In some embodiments, subunits are non-overlapping; in some embodiments, subunits may overlap (e g., a word subunit being a part of a paragraph subunit).

[0360] In Fig. 14, exemplary document model data are shown in an GUI 1410 with input parameter fields on the left, and an output visualization on the right. Parts of input document 1400 are organized by sections (e.g., 1.0 Intro, 2.0 Background, 3.0 Design Requirements, 4.0 Cost requirements). For illustrative purposes, each section is shown as containing a single paragraph. In practice, each section may contain multiple individual paragraphs as sub-parts, and each paragraph may be identified by a unique paragraph identifier (ID). API 1420 is shown below for the document splice, with a single splice or wrapper ID 1430 and individual paragraph IDs 1440 for document parts in paragraph form. The combination of the wrapper ID and paragraph ID may be viewed as an API endpoint for each paragraph. Alternatively, the paragraph ID alone may be viewed as an API endpoint. A splice function provided by the IDEP platform API or contained in the identified wrapper may be used to access tire identified paragraph from the identified wrapper.

[0361] Further in GUI 1410. an API wrapper / script or splice function titled ‘“Hide Paragraphs & Share document” is displayed. The splice function’s input parameter fields are listed on the GUI’s left side, where each document part or sub-part is represented by a label and arranged in a tree-shaped hierarchy similar to a CAD model with components and subcomponents. A creator of the document splice has the option to choose which part(s) to hide or conceal from viewing by users with whom the document splice is shared, and the result of this action is visualized on the right side of the GUI, with selected paragraphsDocket No. IST-03.012PCT

[0362] ‘'hidden” or blurred from view. In this particular example, '‘hidden text” appears as crossed-out. Conversely, users of the document splice can propose changes or suggest modifications only to the parts or sections they have access to. Alternatively, in some embodiments, the selected paragraphs may be redacted in black or white; in some embodiments, the redaction may be indicated by an in-line symbol. In some embodiments, an additional editor window may be used, and non-hidden paragraphs may be displayed to and edited directed by a user. In some embodiments, the redacted paragraphs may not be shown in the document view. For example, the recipient may only see document data that they are authorized to view, with no additional context for other document data they are not authorized to view.

[0363] While Fig. 14 illustrates how a document splice may be generated by decomposing an input document, it would be understood that a document splice may be created constructively as well, where document subunits (e.g., sections, paragraphs) are created individually, for example, using generative Al, or by modifying excerpts from template documents.

[0364] Exemplary Document Viewing Options: Document Editing

[0365] Fig. 15 shows a screenshot of an exemplary graphical user interface (GUI) 1500 for viewing and interacting with a generated document, in accordance with some embodiments of the present invention. In this screenshot, the user has navigated into a filled Initial Capabilities Document (ICD). Tire complete document is presented in a scrollable format, accompanied by a hyperlinked table of contents menu positioned on the left side. This is an example of a Magic Document that encompasses spliced documents parts and live updates for digital artifacts linked to source digital threads.

[0366] GUI 1500 includes a browser window header 1502 which includes a document link for easy navigation. Below the header, a domain and security level banner 1504 displays the domain, platfonn software version, and security level, ensuring that users are aware of the domain they are operating in and the security protocols in place. A security level indicator 1506 displays the user's maximum security access level within the platform (e.g., “Level 1”).

[0367] The interface also includes a search bar 1512, allowing the user to carry out comprehensive cross-platform searches through tire IDMP for digital models, files, and documents, thus facilitating efficient retrieval of information across the platform. Next to the search bar, a user and domain field 1510 provides infonnation on the user’s domain (e.g., client name). User and domain field 1510 may allow the user to login and to access user profile and subscription information.

[0368] A top menu of GUI 1500 offers additional functionalities. For example, a document name field 1520 displays the document’s name, and may include its version. A document security level indicator 1522 displays a security level (e.g., “Level 1”) of document 1520. In one embodiment, using an expandable security level menu adjacent to document security level indicator 1522, the user may selectDocket No. IST-03.012PCT

[0369] the document’s target security access level “view”, thus filtering only the parts of the document accessible through a given security level. In other embodiments, the user may also use document security level indicator 1522 to down-select tire security level while sharing the document, thus sharing portions of the document that correspond to tire specified security level. Only security access levels below the user's security level (e.g., “Level 1” in Fig. 15) would be available for the user to view and share. Furthermore, user interface buttons 1524 include options to request access to all models related to this document, or email review information to a stakeholder.

[0370] Granular dynamic information security (“infosec”) tags (e.g., 1506 and 1522, and the like) are an important but optional element of a digital documentation system and its associated GUI. Model splicing and the ID MP system enable such granular dynamic infosec tags. In some embodiments, the IDMP may use metadata of digital models or documents to cross-reference against authorizations, licenses, or regulations to update. In some embodiments, such granular dynamic infosec tags (e.g., 1506 and 1522) are dynamic, and are refreshed ahead of any document updates to confirm the right authenticated user has the right authorized access to the digital artifacts and data to perform or view the updates. In other words, user authorization for selective access may be implemented by cross comparing infosec levels of digital entities and infosec levels of the user.

[0371] For document organization and navigation, GUI 1500 features a document outline viewer 1530 on the left of Fig. 15, providing hyperlinked access to the document's headers and paragraphs and / or sections. Such document parts or subunits are obtained via document splice generation. Within outline viewer 1530 and under a selected document part (e.g., section 1.1 Purpose), an expanded mini viewer 1532 shows additional metadata on this document part, including but not limited to, documentation part locator (e.g., file name “Heading l Purpose.xml:), linked DE model(s) (e.g., “Derived from 1.4-InterfaceControl ...”), a source IT domain (e.g., “defense. airplane. istari.app”), and the last update timestamp (e.g., “Last Update Jan 28, 2024, 9:45AM”), some tagged with an appropriate security level (e.g., “LI”). In some examples, if sections of a document contain content requiring a higher security level for viewing, the user may be presented with an option to request access. Were the user to request such access, an authorized user with access at a higher security level may be notified for their review. In other examples, if sections of a document contain content requiring a higher security level for viewing, such sections may not be shown for display, nor provide the user with any prompt for requesting access.

[0372] At the center of Fig. 15, a viewer panel 1540 displays the content of the 1CD (e.g., a “clean” or “ready-to-print” version). Citation references or hyperlinks (e g. superscript 1545, “[2]”) are provided to reference individual data fields (e.g., 1546, “149.6kg”) with digital thread execution and transaction infomiation or metadata (e.g., 1555, “Digital Thread Info List”) shown in a digital thread metadata pane 1550 on the right of GUI 1500. As indicated by item 1552 in digital thread metadata pane 1550, a digitalDocket No. IST-03.012PCT

[0373] thread “Link” is utilized to generate and / or update the live ICD document shown in viewer pane 1540, by linking a document model “requirements .mdzip” and a digital model Airplane. CATPART. Data field 1546 refers to the weight of a drone under a current design, and was last updated on August 08, 2023 at 10:26AM by executing the digital thread, with the weight value originating from part model Airplane. CATPART, owned by Orville Wright, with version ID s98jn9vbc9jns. Data field 1547 refers to a current cost of the drone, redacted from view. The user may request access via a request 1557 to link, access, or execute a relevant cost model.

[0374] As discussed previously, the view of this ICD document shown in Fig. 15 is enabled by digital model splicing, document model splicing, and model splice linking via digital thread script execution. The text shown in viewer panel 1540 is a snapshot view of the document’s splice, which also provides the document outline and metadata shown in outline viewer 1530. Digital thread execution updates data fields in the live document or the document splice, to ensure that every document part is updated based on linked digital models with minimal manual intervention. Digital thread metadata as shown in metadata pane 1550 are added to the live document or the document splice to ensure the validity, legitimacy, or authenticity of the data values. Version tracking as disclosed in later parts of the disclosure may be implemented to capture immutable revisions of individual digital artifacts to ensure traceability, auditability, and consistent dependencies to source digital resources linked via digital threads.

[0375] Although not shown explicitly in Fig. 15, in various embodiments, live document updates may be completed in real-time, within a maximum delay threshold, or on-demand, in a push or a pull configuration. In a push configuration, a model splice may send any occurring relevant updates to trigger the digital thread script to update the linked document splice or live document immediately or within a specified maximum time delay. In a pull configuration, a model splice may flag recent modifications until the digital thread script queries relevant digital models (via the model splice) or other associated digital threads for flagged modification, periodically or upon user-request. The digital thread script may regularly check relevant digital models (via their model splices) or associated digital threads, for modified data fields, by comparing the data found in the live DE document with regularly extracted model and digital thread data. If a discrepancy is found, the digital thread script may use tire modified data to update the live digital document.

[0376] Furthermore, a change highlighting function as provided by the IDMP is shown with the dotted box 1501. In this particular example, a paragraph within subsection 1.1 Purpose is highlighted. When clicked, a linked annotation or comment on the highlighted subsection may appear. This comment could be the result of a reviewer’s feedback on the paragraph. If the reviewer has made direct edits to a document part, such edits may be applied to tire document splice using API endpoints of the document part.Docket No. IST-03.012PCT

[0377] When a reviewer adds a comment, the comment may be saved into the document splice used to generate the human-readable document, allowing the next reviewer to see the comment directly upon loading the document splice. Moreover, annotation comments may be automatically generated when digital model(s) and / or digital thread(s) linked to data within this paragraph are altered. For instance, the comment could indicate when a related digital model was last modified and by whom, complete with a hyperlink to tire digital model itself or an accessible model splice of the digital model. As disclosed in later parts of the disclosure, a comment may also be viewed as a digital resource on the platform, and versioned controlled accordingly.

[0378] To facilitate the identification of changes in documents, the IDMP may implement several change highlighting features. A color-coded highlights feature may use varied shades to pinpoint additions, modifications, or removals in the document. A side-by-side comparison feature may display the pre-edited and updated versions of the document side-by-side for convenient comparison. A track changes with annotations feature may log all changes made to the document and allow annotations or comments offering explanatory notes about the particular changes. In some embodiments, links to underlying digital models and digital threads may be provided in annotations or comments as well.

[0379] Furthermore, in some embodiments of the IDMP, selected highlighted changes may be provided for a sequential approval process. That is, each alteration may be targeted to individual reviewers, requiring approval from the relevant stakeholders in a set-order or set-sequence. Selected highlighted changes may be implemented with different colors, font formats and similar highlighting options. In a sequential approval process, only certain highlighted changes may be actionable to a specific user forthat step in the review sequence. This approach ensures a comprehensive review process for every change, affirming tire accuracy and pertinence of every modification, and is especially useful when changes affect multiple departments or job functions.

[0380] Overview of Versioning for Collaborative Workflows

[0381] As highlighted through the discussions of digital thread capabilities provided by the IMDP, traditional workflows in industries like aerospace are often manual, inefficient, and error-prone. For example, when a wing design changes, a project manager may save a new version of tire file on a shared drive or email it to relevant parties. Updates are tracked using spreadsheets, with follow-up actions such as testing scheduled via email communication. The results, often stored as email attachments, are manually linked back to the spreadsheet. This fragmented process lacks reliability and makes traceability nearly impossible.

[0382] Tire IDMP transforms this chaotic approach by replacing manual tracking with automated versioning and recursive linking, built upon a file primitive architecture. Every design change creates aDocket No. IST-03.012PCT

[0383] new immutable revision, tracked within the system. For instance, when a wing design revision is used for a wind tunnel simulation, the simulation results may be automatically linked to the design file's revision, creating an unbroken chain of provenance. Metadata captures key information such as the purpose of the revision, version name, responsible personnel, and follow-up requirements, eliminating reliance on emails or spreadsheets.

[0384] Accordingly, versioning is a fundamental capability of the IDMP as disclosed herein, enabling secure management and precise tracking of digital resources including digital artifacts in complex workflows. Tire IDMP implements zero-trust principles to enforce access without aggregation, where users can selectively share specific digital artifacts extracted from larger models without exposing the entirety of the model, and where decentralized management of digital threads across different models, security networks, and user permissions under the zero-trust principle ensures security across diverse environments. It is therefore critical to maintain the lineage of each artifact, ensuring its traceability to the source model. Furthermore, preserving contextual metadata, including the artifact’s relationships to other components, its functional role within the digital thread, and its version history, is essential for maintaining consistency, reliability, and validity of the digital thread.

[0385] Broadly, the present invention relates to methods and systems for a robust, unified, scalable versioning framework that tracks digital model and data artifact lineage, preserves comprehensive contextual relationships, and facilitates secure, decentralized sharing for collaborative workflows in model-based digital engineering. This framework ensures that digital artifacts extracted from digital models remain auditable, verifiable, and consistently aligned with their source, even as models and artifacts undergo updates and are utilized in distributed and collaborative environments. The present invention further provides a snapshot mechanism that captures a point-in-time state of a digital asset file system, capturing specific file revisions as tracked at the time of snapshot generation, thereby enabling deterministic resolution of system states for consistent versioning, revision-based data immutability, repeatable document rendering, historical comparison, and verifiable reconstruction of system states for audit, certification, and compliance purposes.

[0386] More specifically, embodiments of the present invention are directed to the implementation and utilization of a file primitive architecture within the IDMP to standardize versioning management of digital artifacts and other similar resources. A file primitive is a fundamental unit within the IDMP for managing digital artifacts in the IDMP’s versioning system. Each resource within the IDMP, including digital models, digital artifacts, comments, and collections of such, is associated with a file primitive, a “platform file” or a “File” object instance having one or more immutable revisions. For a digital artifact, its file primitive is associated with metadata that describes various attributes of the artifact and its revisions.Docket No. IST-03.012PCT

[0387] In what follows, the term “system” may be interchangeable with “file system”, and "resource file system,” and may refer to collections of files that define the state of all data sharing a particular context. That is, a digital resource file system is a collection of files, their revisions, and derivations that share a common context. In other words, the digital resource file system is a container of file objects. A system configuration defines the system by referencing and enumerating files and tracked file revisions contained within, and dependency relationships among the file revisions. Furthennore, systems of systems are collections of systems, where individual systems represent a unique sub-context within the overall context of the system of systems.

[0388] To facilitate the versioning process, a database or registry is configured to track metadata and relationships between file primitives and revisions to maintain consistent versioning, while a decentralized storage system is configured to store file primitives across distributed environments. This registry may be centralized or decentralized. A system configuration defines a dependency scope via one or more tracked files, where each tracked file establishes an explicit relational association between the configuration and a corresponding file entity. Tracked files may be configured to resolve dynamically to a latest revision or be pinned to a specific revision identifier. Here “resolution” refers to the process of determining which specific file revision a tracked file should be associated with at a given point in time.

[0389] Changes to a file of digital artifacts are tracked by creating new immutable revisions, while preserving the lineage infonnation in the registry. The registry may be configured to store cryptographic signatures for each file revision to ensure data integrity. The registry may be further configured to track timestamps and user identifiers associated with each file revision. Snapshots are generated to capture a point-in-time state of the configuration, with each snapshot comprising snapshot items that bind tracked files to specific file revision identifiers, thereby enabling detenninistic resolution of configuration state. In some embodiments, the system is implemented over the IDMP enclave -exclave architecture, where the registry operates within a secure enclave, and file management tasks are executed by agents operating within decentralized exclaves. The agents may be configured to retrieve specific file revisions based on instructions from the enclave, execute operations on the files, and update the registry with new revision infomration that may be captured in subsequent snapshots, all without the file revisions ever leaving the exclaves which may reside in secure, access-controlled customer environments.

[0390] Within a collaborative workflow, file primitives have dependency relationships to other file primitives, such as within a digital thread of linked digital models. For example, in a design project, a simulation result can be directly linked to the exact revision of the wing design file that was used, along with the timestamp, cryptographic signature, and the identity of the creator. This ensures traceability across the entire lifecycle, from initial design to final production, enabling compliance with industry standards and regulatory requirements.Docket No. IST-03.012PCT

[0391] Extending the setup of system configuration to systems of systems within the present disclosure, a system of systems or a system of sub-systems may be defined by a collection of interrelated sub-system configurations, where relationships may be established among these sub-system configurations through shared file revisions and / or digital thread linking, thus enabling data flow and dependency tracking across configuration boundaries while maintaining independent version control and snapshot capabilities within each constituent sub-system configuration.

[0392] On a more granular level, integration with the IDMP’s digital model splicing and document splicing capabilities allows tire IDMP’s versioning system to individually update and version artifacts linked to different digital models and / or digital threads. For example, a version 1.1 of a digital artifact a may be derived from a digital thread A version 1.1, a version 1.2 of a digital artifact b may be derived from a digital thread B version 2.2, but both artifacts a and b may be presented to a user as part of a same document having its own version 3.3. Tirus, the IDMP’s versioning system scales across models, artifacts, and even sub-systems, tracks conventional package-level versioning for individual, granular, artifact-level changes on the IDMP, and manages the versioning of different types of digital resources (e.g., models, artifacts, comments, and collections of these) in a unified manner.

[0393] Furthermore, a snapshot feature provides a point-in-time representation of a linked collection of file primitives, and may be generated from a system configuration as a set of references to specific revisions of file primitives that collectively represent a consistent state of the collaborative workflow. In addition to being a mechanism for capturing and preserving the relationships and dependencies between multiple file primitives at a given time, snapshots may facilitate the implementation of access control and selective sharing of specific versions of digital artifacts. Snapshots work in conjunction with the registry and decentralized storage system to provide a cohesive versioning mechanism across distributed collaborative environments.

[0394] In short, the IDMP’s versioning system supports collaboration, ensures data consistency and immutability, and guarantees data provenance throughout digital workflows. Each file or artifact is tracked as a unique revision, recorded with a cryptographic signature to maintain an immutable history of changes, thus eliminating version mismatches, and providing all collaborators with synchronized and verified file versions. Collaboration is enhanced through automated synchronization of file revisions across distributed teams. All contributors work on consistent, authenticated data without manual reconciliation. Consistency is ensured by tracking every file and artifact revision as immutable, linked to workflows through metadata-driven relationships. Finally, data provenance is achieved through an auditable chain of custody that ties each artifact to its inputs, tire personnel involved, and the tool and systems used. With these automated processes, the IDMP improves efficiency, reduces errors, and ensures reliable audit trails, critical for industries where compliance and accountability are essential.Docket No. IST-03.0f2PCT

[0395] In what follows, a file and resource primitive architecture is first discussed in the context of versioning, before processes and systems for digital artifact and digital model updates, versioning, and snapshot generation and consumption are discussed in further detail within the context of the IDMP.

[0396] File Primitive - Based Versioning Architecture Beyond Software Package Management Embodiments of the present invention enables a versioning architecture designed specifically for digital engineering data, where models, simulations, analyses, and derivative artifacts must remain interoperable across heterogeneous tools and environments. Instead of treating repositories or packages as the unit of version control, the IDMP as disclosed herein uses a file primitive as the fundamental versioning object. File primitives maintain immutable revisions, each anchored by cryptographically verifiable content and properties tokens. A database or registry tracks these revisions along with bidirectional lineage in the form of explicit source and product relationships, allowing the IDMP to represent and query complex engineering workflows that span multiple tools, datasets, and even edge or physical twin systems.

[0397] This lineage-centric approach enables the IDMP to automatically manage change propagation across the entire engineering ecosystem. When a source model is updated, the registry can identify all downstream artifacts derived from it. trigger their recalculation through agents operating in distributed exclaves, and validate the resulting outputs. Once the upstream and downstream artifacts reach a consistent state, the IDMP can create a snapshot that captures the entire connected set of revisions as a coherent, auditable system state. This ensures that design updates ripple through the workflow with traceable integrity, preserving provenance and compliance even as artifacts evolve across domains, tools, compute environments, and security networks.

[0398] By contrast, traditional package management systems such as npm or Go modules operate at the level of software packages, focusing on dependency resolution within software codebases rather than multi -tool engineering lineage. These systems do not natively model how individual engineering artifacts are derived from upstream inputs, nor do they orchestrate cross-tool recomputation or validation of downstream artifacts when a dependency changes; such behavior, if present, is typically implemented externally in Continuous Integration / Continuous Delivery or Deployment (CI / CD) pipelines and build scripts. In common usage, they integrate with Git-based workflows that converge changes onto a canonical ”main?’ code line, but their versioning semantics stop at packages and source code. The IDMP platform departs from this paradigm by treating the engineering process itself as a graph of interdependent artifacts, enabling granular, cross-domain versioning that maintains digital thread integrity in a way conventional package managers were never designed to support. Table 1 below highlights exemplary' differences between conventional package managers and the file primitive-based versioning frameworkDocket No. IST-03.012PCT

[0399] offered by the IDMP. Further details on the implementation of the file primitive-based versioning framework are provided next.

[0400] TABLE 1. Comparison Between Software Package Management and File Primitive-Based Versioning

[0401]

[0402] Resource Primitives and File Primitive Architecture to Support Versioning

[0403] Fig. 16 is a database schema diagram 1600 illustrating an exemplary data architecture comprising resource primitives and file primitives within the IDMP to support digital resource versioning and collaborative workflows, in accordance with some embodiments of the present invention.

[0404] Resource Primitives

[0405] Shown in the lower half of Fig. 16 is a resource class 1610, which is a generic representation of data entities, including but not limited to, models 1612, artifacts 1614, comments 1616, and collections 1618 thereof. Each resource is associated with a unique identifier (UUID), a timestamp (timestamp) marking its creation, and an optional hashed version string (version hash) that ensures integrity. A digital resource is a digital asset managed within the IDMP. For example, digital models, comments, metadata, artifacts such as simulation results, documents, images, datasets, and other digital contents managed by the IDMP may be viewed as different types of digital resources. A resource entity provides a semantic indirection layer or semantic layer over files, discussed later in tire present disclosure. That is, digital resources may be interpreted as models, artifacts, or other user-defined types without constrainting the underlying schema.Docket No. IST-03.012PCT

[0406] Each resource is linked to a corresponding file entity or instance of the file class 1660 as part of a file primitive 1650. A class is a blueprint for creating objects (e.g., resources or files) with attributes, methods, and relationships, encapsulating data and behavior. In what follows, we refer to the resource class 1610 and its instances interchangeably, and the file class 1610 and its instances interchangeably. A file instance linked to a resource instance may also be called a "resource file.” A file can have one or more immutable file revisions 1662, linked to other file revisions via derivations or relationships 1668, and containing contents and properties protected by cryptographic tokens such as 1664.

[0407] A resource primitive 1610 is a foundational entity or atomic element of data representation in the IDMP, and may be depicted as a generic node in a data architecture diagram. A resource is uniquely identified by a Universally Unique Identifier (UUID), which may also serve as the resource’s primary key (PK) in a database table. Resources may be categorized into various sub-classes, representing different types of data entities. Every resource has associated metadata or a linked file within the data architecture of the IDMP.

[0408] One exemplary subclass of resources is models 1612 shown in Fig. 16. Each model resource represents a digital model or a model-type file as discussed previously within the IDMP. Each model resource has a UUID, which may also function as a foreign key (FK) to link tire model resource to related resources such as artifacts derived from the model, or those for upstream and downstream models in a digital thread. Such dependency relationships may be visualized as connections between model resources and other related resources.

[0409] Another subclass of resources is artifacts 1614, each representing a digital data artifact that is extracted or derived from a digital model within the IDMP. Each artifact resource may be linked to a model resource through a model id field, establishing its relationship with the corresponding model resource. That is, an artifact resource may include a reference to its source model resource. This linkage may be represented as a directed edge from the model resource to the artifact resource, indicating the derivation or association.

[0410] In many implementations, the resource primitive supports back -referencing, so that a resource, such as an artifact resource, is linked to the digital model it is derived from. Consequently, a digital model can maintain a collection of artifact resources that are extracted from it, allowing for easy traceability and organization of related resources.

[0411] Yet another subclass of resources are comments 1618 from users. Comments may be associated with any resource type, whether it be a model, artifact, or collection. Each comment may include an id field (e.g., UUID «FK») and a resource id (e.g., UUID «FK»), linking it to a specific resource. A resource may have many comments to facilitate detailed discussions and feedback, and a comment mayDocket No. IST-03.012PCT

[0412] be made on another comment as a reply, enabling threaded conversations about a resource. This design allows comments to be systematically organized and referenced in relation to the resources they discuss.

[0413] Another subclass of resources is collections 1616 that contain multiple other resources. Each collection has an id (e.g., a UUID «FK» ), and the resources it contains may be visualized as a list or set of their respective resource ids. A resource may belong to multiple collections, facilitating complex data management and retrieval. Collections may be layered hierarchically, such that a collection may contain other collections. This hierarchical capability extends to system configurations as discussed later, where a system of systems may be defined as a collection of interrelated system configurations.

[0414] In some implementations, a folder or directory container of digital data entities may be conceptualized as a collection of resources, and is itself another resource. Comments on such data entities and containing folders may be implemented through this data architecture of resources. For example, a file may be implemented for any resource or its sub-class, and a folder may be implemented as a collection of files of the respective resources.

[0415] This Resource Primitive-based data architecture within the IDMP enables uniform resource management, comment association, and collection management to effectively handle commenting and collaboration among users. It also enables the file primitive architecture for versioning control. Uniform resource management ensures that all digital entities, whether they are models, artifacts, comments, or collections, are treated as IDMP resources with a consistent structure, identified by a Universal Unique Identifier (UUID). This uniformity ensures that the same methods and data structures can be applied regardless of the resource type. For example, comment association may be handled by linking each comment to the specific resource it pertains to through the resource id field, allowing users to provide feedback or start discussions directly on any resource. Hie hierarchical nature of comments supports nested replies, enabling threaded discussions that are easy to follow and organize. Collection management allows for the grouping of resources into collections (or folders), where each collection can contain multiple resources. For example, a document splice may be viewed as a collection of document artifacts in the form of document subunits. This facilitates organized collaboration by allowing users to manage related resources together, with the ability to comment on individual items within the collection or on the collection as a whole. The combination of these features in tire IDMP creates a cohesive and flexible system for managing collaboration and feedback, ensuring that discussions are logically structured and accessible across different types of resources.

[0416] Exemplary Comment Resources

[0417] As an illustrative example of resource primitive and resource linkage, this subsection considers a comment and a reply, stored as records in a relational database, each having multiple data fields. ThisDocket No. IST-03.012PCT

[0418] setup of maintaining comments in a table in a standalone relational database promotes data independence and easy management, as comments are not directly embedded within the files or folders they refer to. Similarly, in some exemplary embodiments, comment records and reply records may be stored in other appropriate data structures and be referenced with pointers or keys, possibly tailored for the underlying data entity being commented on.

[0419] For comments stored in a comment table in the database, each has its own Primary Key (PK) and may reference Foreign Keys (FK) from any possible parent data entities such as model, artifact, folder, file, or model splice / wrapper. A reply to a comment may be stored in a reply table in the database, which may use a UUID of the parent comment as a FK to link the reply to the comment. A primary key is a unique identifier (ID) for a record in a database table. It can be viewed as a unique ID for each row in the table. A foreign key is a column or a set of columns that refers to or references the PK in another table. The table with the foreign key may be called the child table, and the table being referred to may be called the referenced or the parent table. For example, a parent data entity table may identify each data entity being commented on with respective PKs, and child comment tables and grandchild reply tables may link to their respective parents with FKs.

[0420] An exemplary comment record may comprise the following data fields. Other additional data fields may be included in comment records implemented in different embodiments of the present invention.

[0421] • Primary Key (PK): a unique identifier for this record in the comment table (e.g., an 8-digit unique ID, rckq4n4!)

[0422] • Foreign Key (FK): column(s) in a child table referencing the PK of a parent table, for example, to identify what user, folder, or file this comment is referencing.

[0423] o FK1 (created by id): UUID linking to the user (e.g., a record in a user table) who created tire comment (e.g., hZ7vQSqk)

[0424] o FK2 (artifact id): UUID linking to the file / model / artifact (e.g., a record in a data entity table) this comment ties to (e.g., yufgkxxD)

[0425] o FK3 (foldcr id): UUID linking to the folder this comment tics to (e.g., a Folder table PK, 6UzM34AG). Note that FK3 and FK2 in this example are not implemented together. For example, if the comment is on a folder, the folder may be referenced in FK3, while FK2 is set to NULL

[0426] • comment type: a categorization of the comment (e.g., text-voice-video, folder-file-model-artifact, general-inContext, etc.)

[0427] • content: the actual content or text of tire commentDocket No. IST-03.012PCT

[0428] • position x, position_y. position z: spatial coordinates for placing the comment in-context within a 3D model / document when visualized through a viewer.

[0429] • page_num: the relevant page number, or a page number where the comment is found or related to • updated at: timestamp indicating when tire comment was last updated

[0430] • created at: timestamp indicating when the comment was created

[0431] • is resolved: a boolean flag indicating whether the issue or query raised by the comment has been resolved.

[0432] • is deleted: a boolean flag indicating whether the comment has been deleted (i.e., soft deletion)

[0433] Similarly, a reply to the comment may be stored as a record in a reply database table with a FK that relates the specific reply record with the corresponding parent comment record. An exemplary reply may comprise the data fields such as PK, FKl(comment id), FK2(created_by_id), content, updated at, create at, and is deleted.

[0434] The use of a standalone relational database with FKs that link comments to resources provides several benefits. First, it allows for a clear and direct connection between a comment and its relevant target data resource. Second, it enables tire system to manage comments independently of the data resource they refer to. Third, it facilitates efficient retrieval and display of comments, as the system can simply follow the FKs from a comment to its associated file or folder. Furthermore, data entity tables as used herein may be dynamic instead of static, and may be updated as the location of a file or a folder in memory changes, ensuring that the link between a comment and its associated file or folder remains accurate and reliable, even as files or folders arc moved, modified, or deleted within the system. Furthermore, when a file-level data entity is duplicated and copied over, associated prior comments may not be duplicated automatically unless authorized by the owner. When a file is duplicated with comments, comment records may be duplicated in the comment table but assigned new PKs, then linked to the duplicated file.

[0435] In some embodiments, each comment record may include various properties, attributes, or metadata for each comment. Such attributes include, but arc not limited to, the crcator / author / contributor of a comment (e.g., as represented by a user ID or user name), the data entity the comment refers to (e.g., as represented by file ID and / or folder ID), a timestamp (e.g.. date and time when a comment was created or last updated), a status (e.g., active, resolved, ‘waiting for response from Reviewer X,” etc.), urgency level (e.g., flagged for immediate attention), deadline for resolution (e.g., a target date and / or time), vote of confidence (e.g., options to “agree” or “accept this proposed alternative”; current vote distribution among all participating reviewers), the text of the comment itself, and the like. These additional attributesDocket No. IST-03.012PCT

[0436] add depth to the data tracked by the system, facilitating comprehensive comment management, user tracking, and interaction analysis.

[0437] File Primitives

[0438] Shown in the upper half of Fig. 16 is a file primitive 1650, a foundational unit for versioning digital resources within the IDMP. Within this exemplary implementation, every resource (e.g., an instance of a resource class 1610) has a corresponding file (e.g., an instance of a file class 1660), also called a “resource file,” and every file is associated with one or more file revisions (e.g., instances of the FileRevision class 1662), each incorporating one or more cry ptographically encry pted tokens (e.g., an instance of a Token class 1664). In some embodiments, each resource file corresponds to a single resource. In some embodiments, a single file may correspond to multiple resources (e.g., content of the file is a list of multiple numerical digital artifacts).

[0439] A file revision is a discrete version of a file, uniquely identified by a UUID and includes a timestamp for its creation or modification. Each change to a file revision may create a new immutable revision, ensuring indefinite preservation, and enabling snapshots to find specific revisions without the risk of alteration. A file revision may reference a content token and a propertie s_token that address external, secure storage of file content and metadata . Such tokens may be accessed using their unique IDs. Additionally, in some embodiments, file revisions may optionally store a hashed version string for integrity checks and auditability. In some embodiments, one or more file revisions may reference the same content token but with updated properties_token, such as when a file is renamed, causing the creation of a new revision. That is, each file revision is still an immutable reference to the raw data represented by the content token at a given moment in time, while allow ing for the easy creation of future revisions that represent, at a later point in time, a file that has been renamed or had other properties-only changes applied.

[0440] As shown in Fig. 16, each file revision is linked to a derivation entity 1668, which specifies dependencies on source resources and resulting product resources, thereby enabling dynamic lineage tracking across files and versions.

[0441] A file revision is a source for each of its product file revisions, and a product for each of its source file revisions. For example, a file revision may depend on prior versions from which this file revision has been modified from, and references to descending versions modified from this file revision. A file revision of a file for a comment resource may depend on a file revision of a file for a model resource on which the comment was made. .

[0442] Below is an exemplar}’ File schema and File Revision schema:

[0443] File Schema: File = {Docket No. IST-03.012PCT

[0444] id: string;

[0445] created: Date;

[0446] revisions: FileRevisionf];

[0447] archive Status I di sto ry : F ile Archive Status [] ;

[0448] resourceld? : string | null;

[0449] resourceType?: string | null:

[0450] createdByld?: string | null:

[0451] }

[0452] FileRevision Schema: FileRevision = {

[0453] id: string;

[0454] created: Date:

[0455] fdeld: string | null:

[0456] content Token: Token;

[0457] propertiesToken: Token;

[0458] archive StatusHistory: FileRevisionArchiveStatus[];

[0459] sources?: Source[];

[0460] products?: Product[];

[0461] createdByld?: string | null:

[0462] }

[0463] In some embodiments, a fde may optionally include tags for the associated resource type, the user who created the fde and an archive status history, in case the fde is archived, preventing future use. In some embodiments, the FileRevision may directly include the content token and properties token within them and optionally include a createdByld field and an archiveStatusHistory field.

[0464] Token class 1664 represents uniquely identified entities that encapsulate encrypted content, including a unique ID, timestamp, and hash strings representing the encrypted data. Both content tokens and property tokens are instances of the Token object class. For example, a content token may point to binary file data and a properties token may point to metadata on file properties such as size, name, and tire like. In various embodiments, the names and the content of a file may be tokenized independently. This approach enables the same tokenized content to be reused when a properties token of the file is updated and can assist with duplicate tokens for the same data content.

[0465] As shall be discussed in detail with reference to Figs. Figs. 17A to 22, Snapshot class 1680 represents point-in-timc captures of file system configurations. Each change (c.g., an update to a model) creates a new immutable revision of the resource file, and snapshots ensure indefinite preservation byDocket No. IST-03.012PCT

[0466] binding tracked files to specific file revision identifiers. In other words, a snapshot captures the state of all tracked files within a system configuration at a specific timepoint, and may be used for historical tracking, timeline visualization, rollbacks, and other similar operations. Snapshots provide a timeline-based view of the resource ecosystem within the IDMP and facilitate efficient querying and auditing of resource updates. While an individual file revision shows the state of a single file at a point in time, a snapshot shows the state of a system of digital resources.

[0467] In some embodiments, the File class 1660 may include methods for performing diff operations between file revisions, allowing users to easily visualize changes between versions. These diff operations may support various file formats, including text, binary, and structured data formats. In certain implementations, the File class may incorporate a locking mechanism to prevent concurrent modifications to the same file revision. This may include methods for acquiring and releasing locks, as well as handling scenarios where locks cannot be obtained. In some cases, the File class may include methods for generating and verifying digital signatures for each file revision, ensuring the authenticity and integrity of file contents throughout the versioning process. Similarly, snapshot may include a locking mechanism to prevent modifications to certain file revisions or creation of new file revisions based on a time duration, or based on respective sources.

[0468] In certain embodiments, the File class may incorporate compression techniques to minimize storage requirements for file revisions. This may include delta compression between revisions and content-aware compression based on file types (e.g., using gzip for text, PNG compression for images). A caching mechanism within the File class may be implemented to improve performance when accessing frequently used file revisions. This cache may be intelligently managed based on access patterns and available system resources (e.g. least recently used (LRU) eviction, predictive caching algorithms, or usage of heuristics). The File class may utilize a tagging system, allowing users to apply metadata tags to specific file revisions. These tags may be used for categorization, searching, and filtering of file revisions within the IDMP. Such metadata tags allow for ease of discoverability of file revisions and enhance reuse of them in different digital workflows.

[0469] Tire File class may implement a branching mechanism, allowing multiple parallel development paths to be created from a single revision. Based on timestamp for creation, each branch may offshoot a new revision, associated with the source File class. Uris branching functionality may include methods for comparing, creating, merging, and managing branches.

[0470] The system may implement a plugin architecture allowing custom file handlers to be developed for specific file types. These plugins may extend the FileRevision class to provide type-specific versioning behaviors, such as intelligent merging for CAD files or semantic versioning for software artifacts. The FileRevision class may implement a rollback mechanism, allowing users to revert toDocket No. IST-03.0I2PCT

[0471] previous versions easily. This may include methods for creating restore points (e.g., via snapshots) and managing tire rollback process across multiple dependent resources. In some implementations, the FileRevision class may include methods for handling large files efficiently, such as chunking and streaming capabilities for versioning and transferring large datasets.

[0472] Artificial Intelligence (AD-Assistance to File Management

[0473] In some embodiments, the IDMP may incorporate Al agents to enhance various aspects of file and resource management. These Al agents can be connected with the file primitive architecture to provide intelligent automation and decision support. Al agents may be employed to analyze file revision histories and predict (or even resolve) potential conflicts or integration issues before they occur. By examining patterns in past revisions and user behaviors, these agents can proactively notify users of high-risk changes or suggest optimal times for merging branches.

[0474] The system may utilize machine learning models to automatically classify and categorize new file revisions based on their content and metadata. This can help in organizing large repositories and improving searchability of resources within the IDMP. Natural language processing (NLP) agents, or local large language model (LLM) agents in a Retrieval-Augmented Generation (RAG) architecture, may be implemented to analyze and summarize changes between file revisions, generating human-readable descriptions of updates. This can be particularly useful for non-technical stakeholders who need to understand the evolution of resources without displaying technical details.

[0475] Al-powered code review agents may be integrated into the file revision process for software artifacts. These agents can analyze code changes, flag potential bugs or security vulnerabilities, and suggest improvements based on best practices and project-specific guidelines. Tire IDMP may incorporate reinforcement learning agents to optimize workflow processes over time. These agents can learn from user interactions and outcomes to suggest more efficient paths for resource development and collaboration.

[0476] Anomaly detection algorithms may be employed to identify unusual patterns in file access or modification, potentially flagging security risks or unintended system behaviors. Al agents may assist in intelligent version control by automatically determining when to create new branches or merge existing ones based on the nature of changes and project requirements. The system may use Al to predict resource dependencies and suggest updates to related files when changes are made to a particular resource. Such Al assistance can help maintain consistency across complex, interconnected projects. Machine learning models may be employed to analyze usage patterns and predict which file revisions are likely to be accessed frequently. This predictive analytics information can be used to optimize caching and storage strategies for improved system performance.Docket No. IST-03.012PCT

[0477] Al-driven data quality agents may be implemented to monitor and maintain the integrity of fde contents over time, automatically flagging potential data degradation or inconsistencies across revisions. The IDMP may incorporate generative Al capabilities to assist in creating new versions of resources based on specified parameters or goals, potentially accelerating the iterative design process in certain workflows.

[0478] Use of File Primitives and Resource Primitives across different types of digital assets standardizes versioning management on the IDMP, offering a unified approach that enables granular, cross-domain versioning that preserves digital thread integrity across heterogeneous tools and environments, while also maintaining tire simplicity of traditional file interactions. Below are exemplary features of the file primitive setup.

[0479] Simplified User Interaction

[0480] Users, including those using an SDK, may interact with versioned file primitives as they would with conventional files. The underlying complexities of tokenization, versioning, and storage are masked away. For example, when interacting with a local conventional file in Python, the following code may be used:

[0481] file = PathCfile.txt")

[0482] file.read_text()

[0483] # Output: 'The quick brown fox jumped over the lazy dog.\n'

[0484] When a corresponding file primitive is registered and managed by the IDMP, the interaction remains just as intuitive:

[0485] file = idmp-platform-name.Client().add_file("file.txt")

[0486] file.read_text()

[0487] # Output: 'The quick brown fox jumped over the lazy dog.\n'

[0488] Revision Tracking and Preservation

[0489] Unlike traditional local files, which offer limited tracking capabilities such as modification timestamps, IDMP file primitives are able to preserve a complete ongoing history of revisions. Each change creates anew immutable revision, ensuring indefinite preservation.

[0490] Example of accessing revisions:

[0491] file = client.get file(file.id)

[0492] filc.rcad_tcxt()

[0493] # Output: "The fox is also lazy and doesn't jump over the dog."Docket No. IST-03.012PCT

[0494] file.revisions

[0495] # Output: [

[0496] # Revision(id=UUID('eeedf4e4-adb6-4922-9caf-449a3118el52')),

[0497] # Revision(id=UUID('a6b7eb5d-4ad9-445b-b8fl-7af09a024c59'))

[0498] # ]

[0499] Reading and Comparing Revisions

[0500] Every revision’s content may be preserved, enabling users to read or compare changes across versions.

[0501] Example:

[0502] [revision.read text() for revision in file. revisions!

[0503] # Output: [

[0504] # 'The quick brown fox jumped over the lazy dog.\n',

[0505] # "The fox is also lazy and doesn't jump over the dog."

[0506] # ]

[0507] Metadata and Annotations

[0508] Each revision includes comprehensive metadata, such as timestamps, author identity, and optional descriptions for changes. This ensures complete context for every modification.

[0509] Example:

[0510] [revision.created.isofomiatO for revision in file.revisions]

[0511] # Output: ['2024-09-04T20:45:25.553465+00:00', '2024-10-04T21:30:49.860205+00:00']

[0512] [revision.created by id for revision in file.revisions]

[0513] # Output: [

[0514] # UUID('842aee49-8855-40d5-962f-6b81eb5f3747'),

[0515] # UUID('842aee49-8855-40d5-962f-6b81eb5f3747')

[0516] # ]

[0517] [revision.description for revision in file.revisions]

[0518] # Output: [

[0519] # None,Docket No. IST-03.012PCT

[0520] # 'Upon review of evidence, the dog was cleared of charges of being lazy. The video clearly shows the fox slept all day.'

[0521] # ]

[0522] In short, some exemplary features and attributes of the IDMP file primitive include, but are not limited to:

[0523] 1. Integrated Revision History: Ensures that every modification is recorded and accessible.

[0524] 2. Collaborative Editing: Supports multi-user environments with robust change tracking.

[0525] 3. Metadata-Driven Context: Captures detailed context for changes through metadata such as descriptions and timestamps.

[0526] 4. User-Friendliness: Masks complexity while retaining intuitive file interactions for users.

[0527] This exemplary architecture shown in Fig. 16 combines secure, cryptographically verifiable data management with dynamic dependency tracking and temporal snapshot functionality, providing a framework for version control in distributed environments that is robust against data loss or corruption, unauthorized modifications, version conflicts, or inconsistencies across distributed environments.

[0528] Consistent File Primitive Management with Decentralization

[0529] As part of the file primitive setup, the IDMP may employ a decentralized yet consistent approach to file primitive management, ensuring flexibility and scalability while maintaining integrity and traceability. In what follows, “file primitive” and “file” are sometimes used interchangeably. It would be understood by persons of ordinary skill in the art that within the present disclosure, references to files on the IDMP may refer to the file primitive structure, where each conventional file is versioned according to Figs. 16-22.

[0530] Unlike centralized storage systems, where all files reside in a single repository, the IDMP allows files to remain in their native environments, or be dynamically transferred to distributed environments, such as local devices or cloud storage. A database or registry, centralized or decentralized, facilitates this setup by tracking metadata such as file identifiers, version history, and relationships, serving as an authoritative source of truth. Exemplary entity relationship diagrams of data entities within a registry¬ service that supports resource file versioning in the IDMP are shown in Figs. 17A-18B.

[0531] For example, a design file might be stored locally by a team member while its simulation results are generated in a cloud environment. The IDMP registry may ensure both artifacts are consistently- tracked and linked, preserving their relationships without requiring file centralization. In addition,Docket No. IST-03.012PCT

[0532] recursive linking may be used within workflows to trace outputs, like test results, back to the exact versions of input files, maintaining traceability and auditability across distributed systems.

[0533] In some embodiments, a hybrid system architecture of decentralized storage with centralized metadata tracking ensures tire platform scales to meet the needs and challenges of large, complex workflows. With decentralized storage, files may remain in their original environments, avoiding unnecessary file movement, duplication, or latency. Bottlenecks associated with centralized storage are removed to enable scalability, efficiency, reduced overhead, and to ensure cryptographically secured file integrity. With the centralized registry, metadata, cryptographic signatures, and version history may all be concurrently tracked, ensuring consistent relationships and traceability, and enabling distributed teams to work on the same version of files without redundancy or overwriting work.

[0534] The file primitive architecture may support branching and merging of file collections, which are groups of files along with one or more associated fileRevisions. This allows multiple users to work on different branches of the same file collection simultaneously and later merge their changes. A file collection may represent a particular digital thread implementing a specific digital workflow w ithin the IDMP. That is, a common context built from digital thread data may be viewed as a file system, a state of which is defined by a system configuration that also delineates a dependency scope for the data. Tire dependency scope is a bounded set of dependencies among file revisions involved in the digital w orkflow- implemented as the digital thread. When updates are made, conflicts may be automatically detected and resolved during merges back into the digital thread. Additionally, techniques such as Continuous Compliance, can ensure that all changes adhere to overall validation and verification of the thread.

[0535] Tire IDMP may implement distributed version control, enabling offline work and synchronization of changes across multiple network nodes when connectivity is restored. Individual file revisions within a collection may be stored using a content-addressable storage system, where each revision is identified by a cryptographic hash of its contents. This facilitates efficient storage and transfer by ensuring that only the changed data between revisions is stored and transmitted.

[0536] The system may support partial file updates, w here only the changed portions of a file are stored in new- revisions rather than full copies. This can significantly reduce storage requirements for large files with minor changes between versions. File collections may include access control lists (ACLs) that define read, write, and execute pennissions for different users or groups. These ACLs can be version-controlled along with the file contents. Thus the file primitive along with versioning allows for secure access, traceability and clear lineage of the various digital artifacts linked in a digital thread

[0537] The IDMP may implement a publish-subscribe model for file updates. Users may subscribe to specific files, collections, or systems of files, and receive notifications when new revisions arc created. File primitives may support tagging and labeling of specific revisions. This allows for easy identificationDocket No. IST-03.0t2PCT

[0538] of important versions like releases or milestones. Snapshots of file collections or system configuration may be taken to capture the state of various files at specific points in time. These snapshots provide a stable reference for rollback, auditing, and historical analysis. In some embodiments, such snapshots must pass validation requirements to ensure any digital threads running on constituent data are not broken by underlying file updates.

[0539] The system may provide a visual diff tool that can compare file revisions and highlight changes, even for binary file formats like CAD models or images. File primitives may include built-in compression and encryption capabilities. Users can choose different compression algorithms based on file type and set encryption keys for sensitive data.

[0540] Tire IDMP may implement a federated system where file primitives can be synchronized across multiple organizations while maintaining local control and access restrictions. Federation ensures that collaborative work can occur seamlessly across different entities without compromising security or control. Federation may involve standardized protocols for synchronization, authentication mechanisms to verify organizational identities, and policies to enforce access restrictions across federated nodes.

[0541] Exemplary Enclave-Exclave Architecture

[0542] A hybrid setup of decentralized storage with centralized metadata tracking can integrate seamlessly into the IDMP’s system architecture (e.g., see Fig. 3), and may be implemented using a dual-layer enclave-exclave architecture that separates governance from execution.

[0543] For example, the enclave may act as a central authority, maintaining the registry that tracks metadata, cryptographic signatures, and versioning rules. It governs the provenance of files, ensuring consistency and traceability across workflows. For example, when a new revision of a wing design file is created, the enclave may record the metadata, including the file's unique identifier, cryptographic signature, and links to associated artifacts such as simulation results or test reports.

[0544] An exclave, operating in a decentralized environment, may execute file management tasks through agents. These agents may retrieve files based on enclave instructions, manage recursive linking, and generate new revisions in their native storage environments. For instance, when a simulation job is initiated, exclave agents may fetch the exact design file revision specified by the enclave, execute the simulation, and link the results back to the registry.

[0545] In an exemplary workflow, the enclave records the creation of a file revision and defines governance rules. Exclave agents retrieve a file revision for downstream tasks, such as simulations or tests, and results are recursively linked to the original file's revision and returned to the registry for tracking.Docket No. IST-03.012PCT

[0546] By leveraging this Enclave-Exclave architecture, the IDMP can achieve secure, scalable, and traceable versioning, tailored for the demands of complex engineering workflows. Furthermore, by leveraging a flexible, interoperable, and decentralized approach to workflow design and management centered around its innovative file primitive architecture, the IDMP distinguishes itself from traditional Product Lifecycle Management (PLM) systems. The rigid and closed ecosystems of PLM systems often make it difficult to extract data once ingested. By comparison, the IDMP enables seamless interaction across distributed environments by treating each file as a foundational unit with immutable revisions. These file primitives not only encapsulate digital artifacts but also maintain lineage, linking specific file revisions to their source models and associated workflows through cryptographic signatures and metadata.

[0547] Moreover, the IDMP code-first architecture allows users to programmatically define, adapt, and customize workflows with precision, addressing complex requirements that PLM systems cannot easily accommodate. This flexibility extends to tracking file revisions and consistently recursively linking outputs (e.g., simulation results) to their exact inputs (e.g., specific design revisions), ensuring traceability and consistency throughout the workflow. The IDMP is capable of supporting rapid design iteration by simplifying routine tasks (e.g., 80% of coding efforts) while providing tools for efficiently managing complex scenarios (e.g., 20%). These features, combined with decentralized file storage and artifact lineage tracking, facilitate auditable, secure, and interoperable workflows. By integrating file primitives and revisions at its core, the IDMP offers an innovative and comprehensive end-to-end solution, overcoming the limitations of traditional PLM systems.

[0548] Entirety Relationships for an Exemplary Registry Service

[0549] Having the file primitive and resource primitive as the foundational units, the IDMP may build upon these constructs to enable digital asset management, versioning, and state capture at a higher level of organization. While file primitives provide immutable revisions and lineage tracking for individual digital assets, and resource primitives provide semantic interpretation of those assets, practical engineering workflows require the ability to group related files, track their collective state, and capture point-in-time representations of entire systems. To address these needs, the IDMP implements file systems, system configurations, and snapshots, which together enable coordinated versioning, dependency management, and deterministic state reconstruction across collections of interrelated file primitives.

[0550] Specifically, Figs. 17A and 17B show an exemplary entity relationship diagram 1700 of data entities within a registry service that supports resource versioning in the IDMP, in accordance with some embodiments of the present invention. In particular, Figs. 17A and 17B shows an exemplary’ data model and relational schema for managing instances of system 1770, system configuration 1775, file 1760,Docket No. IST-03.012PCT

[0551] tracked file 1766, snapshot 1780, and revisioned digital resource 1710 within a registry service. The registry service operates as a control-plane component of the IDMP and is configured to allocate identifiers, enforce relational integrity, and deterministically resolve configuration state across distributed digital engineering operations.

[0552] As shown in Fig. 17A, system entity 1770 within the IDMP versioning setup represents a logical grouping or collection for one or more digital engineering operations within the IDMP. Each system is associated with one or more system configurations 1775, where each configuration defines a bounded and explicit relationship scope, or dependency scope, for a set of digital assets or resources 1710. The configuration boundary serves as a unit of version control, change management, and deterministic state capture.

[0553] Each configuration 1775 is associated with and references a set of tracked files such as 1766, where each tracked file 1766 establishes an explicit relational association between the configuration and a corresponding file entity 1760. Tracked files define the dependency surface of the configuration and specify resolution semantics indicating whether a file resolves dynamically to a latest revision 1762 oris pinned to a specific revision identifier. This enables the IDMP to support both mutable development workflows and immutable, reproducible system states.

[0554] In some embodiments, a tracked file is not a standalone digital file or a section of a standalone file like a model (e.g., CAD) or artifact (e.g., simulation results), but rather a metadata record stored in the registry to establish the association between system configuration and files. That is, a tracked file may not store digital engineering content, but association and resolution rules that determine which file revision should be used when the configuration is accessed or when a snapshot is generated or recorded. It may therefore contain a file id reference to the file being tracked, a configuration id to tire system configuration within which the file is being tracked, a timestamp indicating the time when the file started to be tracked, and a file revision ID to reference a specific revision to which the tracked file is pinned or locked to.

[0555] When a tracked file is pinned to a specific vision, it refers to the particular immutable revision under the particular system configuration, even as tire underlying file accumulates additional revisions over time. Alternatively, a tracked file may be configured to resolve dynamically to the latest revision of the corresponding resource file. If a tracked file is not pinned, the IDMP may automatically propagate updates to the corresponding resource file, such that when the system configuration is loaded, it will reflect the latest file revision. Conversely, if a tracked file is pinned to a specific revision, the system will not propagate updates for the corresponding resource file. For example, consider an aerospace engineering system where a system configuration represents an airplane having an engine and fasteners such as screws. A user may configure a tracked file for the engine to resolve dynamically to the latestDocket No. IST-03.012PCT

[0556] revision, such that any newly released version of the engine is automatically reflected in the system configuration. By comparison, a user may pin a tracked file for a set of screws to a specific revision, ensuring that even if the fastener team continues to refine the part or release new versions, the airplane configuration maintains the original screw revision without requiring manual updates throughout the system.

[0557] Each configuration 1775 is further associated with one or more snapshots 1780, where each snapshot 1780 represents a point-in-time capture of system state, or system configuration state. A snapshot references the configuration from which it was generated and records sufficient identifiers to deterministically resolve each tracked file to a specific file revision. In this manner, a snapshot functions as a configuration-scoped resolution table that binds tracked files to immutable revision identifiers, consistent with the snapshot semantics described with respect to Fig. 21. In some embodiments, a snapshot may include a subset of the tracked files for the system.

[0558] A file entity 1760, as discussed with reference to Fig. 16, represents a logical file object independent of its revisions and may be referenced by multiple configurations, tracked files, or higher-level abstractions.

[0559] A resource entity 1710, as discussed with reference to Fig. 16, provides a semantic indirection layer or simply semantic layer over files, allowing files to be interpreted as models, artifacts, or other user-defined resource types without constraining the underlying schema. This abstraction enables extensibility of asset semantics within the IDMP and supports interoperability across heterogeneous tools and environments. Resources within the same file system may originate from non-interoperable tools, such as different CAD systems, simulation and analysis software, or proprietary engineering applications, and this semantic layer enables the IDMP to manage diverse digital assets uniformly while preserving their functional meaning and relationships within digital threads.

[0560] In some embodiments, upon system initiation, the IDMP allocates memory and assigns pointers to establish the system entity within the registry. When a system configuration is created, the platform similarly allocates memory and establishes the configuration data structure, including references to tracked files and snapshots. At this initial stage, the configuration contains no tracked files and no snapshots. When a first file primitive is added to tire configuration as a tracked file, an initial snapshot may be generated, containing only that single tracked file, binding it to its corresponding file revision identifier. Subsequent additions of file primitives to the configuration expand the set of tracked files, and additional snapshots may be created to capture the evolving state of the configuration as resources are added, updated, or pinned to specific revisions.

[0561] In this data entity model example 1700, lineage modeling can be performed via derivation relationships 1768. A derivation is a directed link: there is an originating source, and a receiving product.Docket No. IST-03.012PCT

[0562] For example, a derivation may record a generational relationship between successive revisions of the same fde (e.g., revision 1 and revision 2 of a model file), a parent / child relationship betw een a source file and a derived file (e.g., a model and extracted artifacts), or a data flow relationship between files connected via digital threads, where data from one model file flows into another.

[0563] Through derivations, lineage relationships are recorded independently of revision creation, allowing derivation metadata to be declared explicitly after execution of a processing job or agent. This decoupling enables modeling of complex, multi-input and multi-output digital engineering workflows while preserving deterministic reconstruction of historical system state.

[0564] Derivations also enable maintenance of bi-directional relationships: a revision of a file may reference zero or more prior revisions of the same file or different files as sources, and may contribute to zero or more subsequent revisions of the same file or different files as products. This structure enables robust traceability and tracking of dependencies within the IDMP.

[0565] Primary Key - Foreign Key (PK-FK) Relationships

[0566] As shown in Figs. 17A and 17B, a primary key (PK) uniquely identifies an entity instance within the IDMP registry, while a foreign key (FK) stores a reference to a primary key of another entity, thereby- establishing an explicit relational association. PK-FK relationships enforce referential integrity, define dependency boundaries, and enable detenninistic traversal of configuration, snapshot, revision, and lineage data structures.

[0567] In the IDMP, PK-FK relationships may be relied upon to reconstruct configuration state, resolve snapshots to specific file revisions, and support repeatable rendering and auditability as described with respect to Fig. 21.

[0568] Following is an Exemplary PK-FK relationship structure:

[0569] system, id

[0570] | — sy stem configuration . sy stem id

[0571] | — tracked_file .configuration ^

[0572] |— snapshot.configuration id

[0573] | — snapshot item snapshot id

[0574] | - snapshot item tracked file id

[0575] | - snapshot item .file version id

[0576] file. id

[0577] | — trackcd filc . fi 1c > id

[0578] |— file_version.file_idDocket No. IST-03.012PCT

[0579] |- resource.file_id

[0580] |— file.parent id

[0581] file version.id

[0582] | - snapshot item .file version id

[0583] Other exemplary auxiliary relationships for systems configuration that complement Figs. 17A and 17B are:

[0584] product, id

[0585] |— file tag.product id

[0586] resource. id

[0587] |- file tag.source resource id

[0588] |— commit. resource id

[0589] file. id

[0590] |- file tag.file id

[0591] Through these PK-FK relationships:

[0592] • A system deterministically scopes its configurations.

[0593] • A configuration deterministically scopes tracked files and snapshots.

[0594] • A snapshot deterministically resolves tracked files to specific file revisions.

[0595] • A file serves as a stable identity across multiple revisions, configurations, and semantic interpretations.

[0596] • A file revision represents an immutable version suitable for snapshot binding.

[0597] • Resources, products, and commits participate in explicit lineage and operational context.

[0598] These relationships enable the IDMP to traverse sequentially from system to, configuration, tracked file, snapshot, and file revision without reliance on mutable external state, thereby supporting deterministic replay and compliance-grade auditability.

[0599] Snapshot-Item Binding Example

[0600] A snapshot is a point-in-time capture of a system state or system configuration that binds tracked files to specific file revisions. When a snapshot is created, the tracked files within the configuration mayDocket No. IST-03.012PCT

[0601] be enumerated and resolved to their corresponding file revision identifiers. The snapshot then stores snapshot items that bind the snapshot to these resolved file revisions, creating an immutable representation of the system state at the point of snapshot generation.

[0602] In other words, a snapshot such as 1780 may include one or more snapshot items that bind configuration-scoped files to specific file revisions. In some embodiments, each snapshot item stores a FK reference to a tracked file identifier, thereby explicitly associating the snapshot item with a configuration-scoped dependency.

[0603] In alternate embodiments, a snapshot item may record a file identifier instead of a tracked file identifier, such that the snapshot item directly references the underlying file identity. In such embodiments, tire relational bindings may be expressed as:

[0604] snapshot item.file id - > file. id

[0605] snapshot item. file version id - > file version. id

[0606] Either representation may be valid. The snapshot item establishes an immutable association between a snapshot and a specific file revision, such that the relational traversal from snapshot, snapshot_item, to file version exists and enables deterministic resolution of configuration state.

[0607] System of Systems

[0608] In some embodiments, a system of systems may be defined as a collection of interrelated system configurations, each defining its own bounded dependency scope via tracked files while maintaining relationships to other system configurations through shared files, revisions, or linked digital threads. This hierarchical architecture enables complex engineering projects to be decomposed into manageable subsystems while preserving traceability and audibility across the entire project.

[0609] Each constituent subsystem configuration within a system of systems may represent a unique sub-context within the overall data context of the system of systems. For example, in an aircraft design project, separate subsystem configurations may be established for the airframe (e.g., fuselage, wings, tail), propulsion system, avionics, and control systems, each with its own set of tracked files, snapshots, and digital threads. The system of systems then establishes relationships between these configurations, enabling data flow and dependency tracking across configuration boundaries.

[0610] Subsystem configurations within a system of systems may be connected through shared files or file revisions. For example, files representing parts of an interface specification may be tracked by multiple subsystem configurations, ensuring relevant changes to the specification are visible across all dependent subsystems. When a new revision of the specification file is created, each subsystem may independently determine whether to update its tracked files (e.g., when a tracked file references a part of the specification currently being updated) or remain pinned to a prior revision (e.g., when a tracked fileDocket No. IST-03.012PCT

[0611] references a part of the specification not currently being updated), enabling coordinated yet flexible change management.

[0612] Subsystem configurations within a system of systems may also be connected through digital threads. For example, a digital thread for aircraft compliance verification may span multiple subsystem configurations, tracing data flow from a source model in one subsystem through derived artifacts in another subsystem. This cross-configuration lineage enables continuous compliance, allowing the identification of all downstream artifacts across the system of systems that may be affected by an upstream change.

[0613] Furthermore, snapshots within a system of systems may be coordinated to capture a consistent state across multiple subsystem configurations at a time of snapshot generation. This enables verification that the entire system of systems maintains compliance and integrity, not just individual subsystems. Tire hierarchical snapshot capability supports audit, certification, and compliance requirements for complex projects where traceability and auditability must extend across technical, and organizational boundaries.

[0614] In an exemplary workflow built upon tire entities shown in Fig. 17, the IDMP manages versioned digital resources on the platform by updating a system configuration that defines system state through tracked files. Upon receiving a request to update a digital resource, a new file revision is generated, as well as a new tracked file referencing the new revision. The system configuration is updated to reference the new tracked file in place of a prior tracked file, and a snapshot is created or recorded to capture the updated configuration at a point in time, thereby encoding version changes directly within the configuration.

[0615] Alternate Embodiment

[0616] As an alternate embodiment. Figs. 18A and 18B show another exemplary entity relationship diagram 1800 of data entities within a registry service that supports resource versioning in the IDMP, in accordance with some embodiments of the present invention. Specifically, Figs. 18A and 18B illustrate an example resource, file revision, and content metadata schema that complements the configuration and snapshot model of Figs. 17A and 17B, and the snapshot resolution semantics of Fig. 21. Tire illustrated schema separates file identity, revision identity, content addressing, and metadata to enable fine-grained versioning and immutable state capture. Note that tracked file, system, system configuration and snapshot entities have been omitted from Figs. 18A and 18B for readability.

[0617] As shown in Fig. 18 A, a resource entity 1810 provides a semantic wrapper around a file 1860 and represents a logical unit of work or meaning within the IDMP, such as a model, artifact, or other digital product. Resources arc associated with files via PK-FK relationships and may be created, updated, and related independently of file identity.Docket No. IST-03.012PCT

[0618] A job entity 1830 records execution of a function or process operating on files or resources within the IDMP. Each job acts on an identified file, and is assigned a unique job identifier. It also identifies a function that performs the desired operation, such as a splice function that extracts digital artifacts or transforms model data from a file. A job may be assigned to a specific agent responsible for implementing the function within a customer’s environment. A tenant identifier associated with tire job may identify where the job is housed, enabling the IDMP to manage job execution across distributed and multi-tenant environments, and thereby providing operational traceability for revision creation.

[0619] A file revision entity 1862 represents an immutable revision of a file. Each file revision references a file identifier and a content token that addresses externally stored contents. Once created, file versions are not modified, enabling snapshots to bind tracked files to specific revision identifiers without the risk of mutation.

[0620] In this particular embodiment, instead of referencing a property token, a file revision is associated via PK-FK relationships with a file_properties entity 1863 that stores structured metadata for the file version, including descriptive attributes and schema versioning information. By associating file properties with file versions through PK-FK relationships, the IDMP enables snapshot-consistent retrieval of both content and metadata.

[0621] Instead of the derivation entity 1768 shown in exemplary embodiment 1700, a relationship entity 1868 in Fig. 18 associates file versions and resources with operational context and lineage. These relationships may reference file versions that are subsequently incorporated into snapshots, allowing a snapshot to represent not only configuration state but also derived dependency graphs at a specific point in time.

[0622] In an exemplary workflow built upon the entities shown in Fig. 18, the IDMP receives a user request to update an artifact. Tire IDMP identifies the appropriate model and identifies a splice function that acts on the model to create the update. Upon execution of the splice function, a new file revision is created for the artifact. This change is then reflected in the tracked file records for both the model and the artifact within the system configuration. The system configuration is updated with a timestamp recording when the change occurred, and a snapshot is created to capture the state of the artifact and the system configuration at that point in time.

[0623] Collectively, Figs. 18A and 18B illustrate a revision-centric, content-addressed architecture that supports immutable versioning, explicit lineage tracking, and deterministic snapshot resolution as consumed by document rendering and system views described with respect to Fig. 21.

[0624] Exemplary' Resource Update ProcessesDocket No. IST-03.012PCT

[0625] As other illustrations of versioning management workflows built upon data entities as disclosed herein, Fig. 19 shows an exemplar} process 1900 for checking whether a digital artifact is up-to-date, and Fig. 20 shows an exemplary process 2000 for updating a source model and resolving model and artifact dependencies to ensure consistency across downstream artifacts or models, both in accordance with some embodiments of the present invention. While discussions of Figs. 19 and 20 refer to digital resources (e.g., artifacts, models) directly, it would be understood by persons of ordinary skill in the art that these illustrative examples may be implemented using the file primitive and system configuration frameworks as disclosed herein.

[0626] Specifically, whether a digital artifact is up-to-date may be verified by evaluating its dependency lineage. The process begins with initiating an artifact update check at a step 1910. At a step 1912, the IDMP detennines whether the artifact depends on any sources. If no dependencies are identified, the process confirms that the artifact indeed originates from the current version of the source at a step 1920 and concludes at a step 1926 as the artifact is independent and does not require further verification.

[0627] If dependencies do exist, a step 1914 is carried out, where the IDMP recursively retrieves all sources and their respective dependencies, forming a complete lineage tree. At step 1916, the IDMP evaluates whether all sources within the lineage are up-to-date by comparing their version identifiers and timestamps against the latest recorded versions in a version-controlled database or registry. If any sources are outdated, the IDMP logs the issue in the database and notifies the user through the IDMP interface or an external API at a step 1918.

[0628] If all sources are verified as current, the IDMP confirms that the artifact is derived from the latest versions of its sources at a step 1920. This confinnation is recorded, along with a cryptographically verifiable token that links tire artifact to its source lineage. Hie process then concludes at a step 1926. This exemplary process ensures traceability, auditability, and consistency within tire IDMP by dynamically evaluating artifact dependencies and enabling proactive management of outdated components.

[0629] Fig. 20 shows an exemplary process 2000 for updating a source model and resolving model and artifact dependencies to ensure consistency across downstream artifacts or models, in accordance with some embodiments of the present invention.

[0630] The process begins with initiating an update to a source model at a step 2010. For example, a Model 1 Revision A may be transitioned into a Model I Revision B. This update triggers a dependency resolution process at a step 2012 in which the IDMP identifies all artifacts and models directly or indirectly dependent on the updated source. Dependencies are resolved dynamically by querying dependency relationships maintained by the version-controlled database or registry.Docket No. IST-03.012PCT

[0631] At a step 2018, the IDMP initiates updates for the dependent artifacts or models. Updates may be executed automatically based on predefined policies, which may include conditions such as version compatibility or lineage tracing, or they may be triggered manually through user input. In cases of update failure, such as due to some components being temporarily offline, the IDMP may provide rollback or retry options, ensuring robust error handling and system stability.

[0632] After updates are completed, the IDMP performs validation at a step 2020 to confirm that updated artifacts or models meet predefined criteria, such as compliance with cryptographic integrity checks, dependency consistency, or functional tests. At a step 2022, the IDMP records updated dependency relationships in the database, maintaining a traceable lineage for all entities. At a step 2024, the IDMP creates a snapshot capturing the state of tire updated source model and its dependencies. This snapshot may include metadata, version history, and dependency mappings, enabling a temporal view of the IDMP and supporting rollback or audit operations.

[0633] The process concludes at a step 2026, ensuring the source model, its dependent entities, and their relationships are updated, validated, and securely traceable within the IDMP. This exemplary process integrates advanced dependency resolution, dynamic policy-based updates, and cryptographically verifiable snapshots to enhance the scalability, reliability, auditability, and traceability of updates in distributed environments.

[0634] Document Rendering from System Snapshots

[0635] As discussed previously, snapshots provide immutable point-in-time captures of system configurations, and enable the IDMP to deterministically reconstruct prior system states, to compare configurations across time, and to generate consistent views of digital resources for audit and compliant purposes. Fig. 21 illustrates an exemplary system snapshot and document-rendering architecture for managing versioned digital assets in a configuration-scoped manner, in accordance with some embodiments of the present invention.

[0636] In particular, Fig. 21 shows the generation or rendering of specific documents (e.g., 2136), each featuring a specific snapshot (e.g., 2122). Documents are a subclass of the file class shown in Fig. 16, inheriting file functionalities. A system configuration (e.g., 2106) can be used to generate multiple documents (e.g., 2134). Each document (e.g.. 2134) can have multiple revisions (e.g., 2132). A document revision (e.g.. 2132) contains links (e.g., 2138) to tracked files (e.g., 21 A snapshot (e.g., 2122) contains snapshot items (e.g., 21). A rendered document (e.g., 2136) may be created by swapping each tracked file (e.g., 2112) for the corresponding snapshot item (e.g., 2124) in a selected snapshot (e.g., 2122).Docket No. IST-03.012PCT

[0637] More specifically, in Fig. 21, a system 2102 is a collection of data files which collectively provide a common context for all data involved. A system is defined by a system configuration that indicates all the files contained within, and how these are configured and related. Thus, system 2102 can have one or more system configurations. Each configuration such as 2106 is configured to define and maintain a bounded and stable set of tracked files 2110. Each tracked file such as 2112 represents a reference to a file tracked over time within the scope of the configuration 2106, such as a model, artifact, image, dataset, or other digital resource. Each tracked file may be pinned to a specific file revision (not shown in Fig.

[0638] 21). The set 2110 of tracked files is configuration-scoped such that modifications to the set of tracked files is effected by the creation of a new configuration 2106, thereby establishing a stable dependency boundary for versioning, auditability, and reproducible system state reconstruction. A dependency boundary established by a system configuration refers to the explicit scope that defines which files are tracked and managed together as a group for versioning, change management, and state capture.

[0639] Snapshots represent the system configuration and all tracked files it contains at a particular time instant. Thus, system configuration 2106 may further have a collection of snapshots (e.g., 2122, 2023, etc.), wherein each snapshot such as 2122 captures a point-in-time state of configuration 2106 of system 2102. Each snapshot 2122 comprises multiple snapshot items such 2124, and system 2102 may enforce a one-to-one correspondence between tracked files (e.g, Tracked File 1, Tracked File 2, etc.) and snapshot items (e.g., Snapshot Item 1, Snapshot Item 2, etc.) for a given snapshot 2122. Each snapshot item 2124 may store an immutable binding that associates a respective tracked file 2112 with a specific file revision identifier, thereby locking the tracked file to that revision at the time the snapshot is generated. As a result, each snapshot 2122 provides a deterministic resolution table mapping all tracked files of the configuration to their associated revision identifiers, enabling repeatable reconstruction of system state.

[0640] Fig. 21 further shows documents such as 2134 associated with configuration 2106. For example, different types of documents such as requirement specifications, technical drawings and schematics, test plans and results, and bills of materials can be generated from the same set of tracked files 2110, based on corresponding document templates. A document such as 2134 may have one or more document revisions such as 2132. Each document revision such as 2132 may be rendered into a rendered document such as 2136. Each document revision such as 2132 may include document text and one or more tracked file links such as 2138. Each tracked file link may reference a tracked file within the same configuration. In addition, each tracked file link field may be associated with an externally addressable document endpoint as discussed in the context of document splicing shown in Fig. 14. Such an externally addressable document endpoint may be an API endpoint, and may include an identifier for the document revision, and an identifier to the tracked file link field, so that the link can be directly edited as needed.Docket No. IST-03.0t2PCT

[0641] Document revisions 2132 are versioned independently of the snapshots, such that a single document revision may be rendered against multiple snapshots without modification.

[0642] One example of a document revision (e.g., 2132) that can be rendered against a snapshot is a live document or Magic document as discussed in reference to Figs. 1 and 15. A magic document contains references or links to versioned digital artifacts, which in Fig. 21 are tracked file links (e g., 2138). A rendered document (e.g., 2136) such as the one shown in Fig. 15 may be rendered or generated by resolving a document revision (e.g., 2132) against a selected snapshot (e.g., 2122), where snapshot data items in the snapshot are resolved to respective file revisions identified by tracked files linked in the document revision.

[0643] During rendering, each tracked file link (e.g., 2138) may be resolved by dereferencing a corresponding snapshot item link (e.g.. 2140), which references a snapshot item (e.g., 2124) associated with the selected snapshot (e.g., 2122). Through this resolution process, each embedded reference in the rendered document (e.g., 2136) is bound to the specific file revision identifier recorded in the snapshot, ensuring that the rendered document reflects a consistent and immutable system state corresponding to the selected snapshot.

[0644] In operation, selection of a different snapshot (e.g., 2123) causes the system (e.g., 2102) to regenerate the rendered document (e.g.. 2136) using the revision bindings recorded in the newly selected snapshot, without requiring modification to the underlying document revision (e.g., 2132). In some embodiments, an initial snapshot (e.g., 2122) is generated automatically upon creation of the configuration (e.g, 2106), thereby ensuring snapshot-consistent rendering is available immediately.

[0645] In various embodiments, each snapshot item (e.g., 2124) may be stored and managed as a discrete data object including an item identifier, creation metadata, a reference to the associated snapshot (e.g., 2122). and a reference to the bound file revision identifier. The architecture illustrated in Fig. 21 supports repeatable rendering, historical comparison of system states, and verifiable reconstruction of configuration states for audit, certification, and compliance purposes within the system 2102.

[0646] Documents are a subset of the resources managed within a system configuration, such that each configuration may have an associated set of system documents. A document may also reference two separate systems and may be rendered against two separate snapshots of the two separate systems. In such cases, each sub-portion of tire document may correspond to one system versus the other, and the rendered document may compile these portions together. For example, one section of the document may be related to a particular system under a particular system configuration, while another section references a different system configuration. The relationship between a snapshot and a rendered document is not onc-to-onc either: a rendered document may incorporate artifacts from different snapshots (of tire same orDocket No. IST-03.012PCT

[0647] different systems), enabling users to compose documents that draw from multiple point-in-time captures across different system configurations.

[0648] A system document associated with a system may represent a digital thread that defines a sequence of operations and data relationships across files within the system. In this context, the system document may specify which files serve as inputs, which splice functions or IDMP platform functions are applied, which files are produced as outputs, and dependencies among relevant files. Each document revision may represent a version of the digital thread, enabling users to track how the workflow itself evolved overtime.

[0649] In one exemplary implementation, a user may first define a system and establish a system configuration to specify tracked files that represent digital artifacts to be managed. With an established dependency boundary, the user may then write or create a digital thread within this configuration, knowing which artifacts are available for inclusion in the workflow. Tire digital thread may be created in a document fashion, where the user composes the workflow as a document with embedded references to the tracked files, or in a code-first fashion, where sequences of operations and data relationships are defined programmatically. When the digital thread is executed, relevant files in the system are processed through the defined operations, generating new file revisions and a new system configuration recording new derivation relationships.

[0650] Once the digital thread is executed, verification may be performed to confirm that the digital thread has executed correctly, and that the resulting system state as defined by the new system configuration maintains compliance with defined requirements. Such a verification result is associated with the resulting system state as captured by the post-execution snapshot, effectively labeling the snapshot as valid or invalid. If tire snapshot passes verification, it may be marked as a good snapshot, and documents may be rendered from it. If the snapshot does not pass verification, thus breaking the integrity of the broader system, the user may be notified of the incorrect result, and document rendering may be prevented by the IDMP. This verification mechanism ensures that only valid or compliant snapshots are used fordownstream documentation, audit, and certification purposes.

[0651] To verify’ that a digital thread has executed correctly and that a snapshot is valid, the IDMP checks if the resulting system state passes one or more checks on consistency, functionality, compliance and the like. For example, resource update processes discussed in reference to Figs. 19 and Fig. 20 may¬ be carried out to verify data dependencies among affected digital artifacts, and to confirm that all file revisions are up-to-date or appropriately pinned. In another example, data integrity checks may be performed as part of the verification process to ensure newly generated file revisions have valid content tokens. In yet another example, the resulting system state may be validated against regulatory- requirements.Docket No. IST-03.012PCT

[0652] Exemplary Snapshot Generation and Consumption Workflow

[0653] Fig. 22 shows an exemplary workflow 2200 for rendering a snapshot-consistent document or system view, in accordance with some embodiments of the present invention.

[0654] Configuration Identification and Update (Pre-Snapshot)

[0655] In this illustrative example, at a step 2210, a system configuration (e.g., 2106) may be identified within a system (e.g., 2102), the system configuration defining a dependency scope via one or more tracked files (e.g., 2112). In one example, the system contains one or more resource files, and the system configuration contains or references corresponding tracked files. Each tracked file identifies a revision of a resource file in the system. Accordingly, the system configuration defines a state of the system.

[0656] At a step 2212. an update to a digital resource associated with a file referenced by at least one tracked file (e.g., 2112) may be received. In one example, such an update is a modification to an existing digital resource by a user. For instance, the user may update parameter value, revise documentation content, or edit a model file. In another example, such an update may occur automatically as a result of digital thread execution, where a function may act on a source file to produce a derived artifact.

[0657] At a step 2214, a new immutable file revision may be generated for the file corresponding to the updated digital resource.

[0658] At a step 2216, the system configuration (e.g., 2106) may be maintained to reference the tracked files (e.g., 2112) defining the dependency scope.

[0659] Snapshot Generation

[0660] At a step 2218, a request to create a new snapshot (e.g., 2122) of the system configuration (e.g., 2106) may be received. For example, such a request may originate from a user, to capture the current state of the system configuration at a known time instant, such as prior to initiating a significant change, upon completion of a design milestone, or at scheduled intervals. Alternatively, the request may be triggered automatically by the execution of a digital thread, to ensure that the results of the execution are preserved. Other rules may be implemented to govern when snapshots are taken automatically, to balance the granularity of state capture against storage considerations, while ensuring that critical states are preserved for audit, rollback and compliance checks.

[0661] At a step 2220, the tracked files (e.g., 21 10) referenced by the system configuration (e.g., 2106) may be enumerated. Enumeration may involve traversing the system configuration to identify all tracked file records that fall within the dependency scope as specified by tire system configuration. The resultingDocket No. IST-03.012PCT

[0662] enumerated list of tracked files may serve as the basis for subsequent process steps where each tracked file is resolved to a specific file revision.

[0663] At a step 2222, for each tracked file (e.g., 2112), a corresponding file revision to be bound to the snapshot (e.g., 2122) may be resolved. In some embodiments, a tracked file is pimied to a specific file revision, and a pinned revision identifier may be retrieved directly from the tracked file record. In some embodiments, the tracked file is configured to resolve dynamically to the latest file revision.

[0664] At a step 2224, snapshot items (e.g., 2124) may be generated, each snapshot item binding the snapshot (e.g., 2122) to a resolved file revision. In some embodiments, a snapshot item of a snapshot is a data object or record that establishes an immutable association between the snapshot and a specific file revision identifier from a corresponding tracked file.

[0665] At a step 2226, the snapshot (e.g., 2122) with constituent snapshot items (e g., 2124) may be stored as an immutable representation of the system state.

[0666] In some embodiments, a tracked file (e.g., 2112) may be configured to resolve to a latest file revision or to be locked to a specific file revision. In some embodiments, when a configuration (e.g., 2106) contains only tracked files that are locked to specific file revisions, no new snapshots may become available after an initial snapshot is created. In some embodiments, when the configuration (e.g., 2106) contains at least one tracked file configured to resolve to a latest file revision, additional snapshots may be created overtime as file revisions change.

[0667] Snapshot Consumption

[0668] At a step 2228, the snapshot (e.g., 2122) may be selected for rendering or system-state consumption. Such a snapshot provides access to a specific point-in-time capture of the system configuration. In document rendering, the IDMP may use the snapshot as the basis for resolving or dereferencing tracked file links within a document revision. For system-state consumption, the IDMP may reconstruct the system state or system configuration state as it existed at the time of snapshot creation. This reconstruction may be used for various purposes, such as reviewing historical states, comparing changes, rolling -back to a known good state, or providing a baseline for further changes.

[0669] As an example of snapshot consumption, at a step 2230, a snapshot-consistent document or system view (e.g.. 2136) may be rendered by resolving tracked file links (e.g.. 2138) to file revisions via the snapshot items (e.g., 2124).

[0670] Exemplary Implementations

[0671] Fig. 23 shows illustrative examples of system configuration records for an aerospace engineering project, in accordance with some embodiments of the present invention. Specifically, a screen captureDocket No. IST-03.012PCT

[0672] 2300 shows a system configuration state reconstructed from a snapshot taken on October 9 at 12:22pm. A configuration state or snapshot may be tagged (e.g., baseline, new, latest, CDR, PDR, etc.) to show where in a collaborative workflow or review pipeline tire configuration state is situated. In this example, the system under this configuration contains files for an airplane, including a front view of a CAD model shown on the right of screen capture 2300.

[0673] Fig. 24 shows an illustrative comparison between two versions of a Magic Doc, in accordance with some embodiments of the present invention. Specifically, a screen capture 2400 shows rendered views of a current version and a new version of an “Airw orthiness Plan for Unmanned Aerial Vehicle” document file side-by-side, with changes tracked and highlighted. The user can accept or reject tracked changes to update the new’ version of the Magic Doc. Recall from the discussion of Fig. 15 that a magic doc is enabled by digital model splicing, document model splicing, and model splice linking via digital thread script execution. Each artifact shown may be linked to a different digital thread having different versioning information (e.g., a version 1.1 of a digital artifact a may be derived from a digital thread A version 1.1, a version 1.2 of a digital artifact b may be derived from a digital thread B version 2.2, both artifacts a and b may be presented as part of the same Magic Doc having its own version 3.3). Also recall from tire discussion of Fig. 21 that the two document views in 2400 may be rendered from snapshots taken at different points in time. The IDMP's versioning approach scales across models and artifacts, tracks conventional package-level versioning for individual, granular, artifact-level changes on the ID MP and manages versioning of models, artifacts, comments, and collections of those in a unified manner. In simpler terms, unlike conventional online file editing software, the IDMP allows digital artifacts to be versioned individually, while tracking data artifact lineage, preserving comprehensive contextual relationships, and at the same time retaining source models at their distributed locations.

[0674] Similarly, Fig. 25 shows an illustrative comparison between two versions or revisions of an exemplary systems requirement document, in accordance with some embodiments of the present invention. Specially, a screen capture 2500 shows two time-stamped revisions of the document side-by-side, where changes (e.g., insertions, deletions) are tracked and highlighted, with options to accept or reject by the user. Individual parts or sections of the document may be separately versioned and tracked.

[0675] Machine Learning (ML) and Neural Networks

[0676] Machine learning (ML) algorithms are characterized by the ability to improve their performance at a task over time without being explicitly programmed with the rules to perform that task (i.e., leam). An ML model is the output generated when a ML algorithm is trained on data. As described herein, embodiments of the present invention may use one or more artificial intelligence (Al) and ML algorithms.Docket No. IST-03.012PCT

[0677] Various exemplary ML algorithms are within the scope of the present invention. The following description describes illustrative ML techniques for implementing various embodiments of the present invention.

[0678] Neural Networks

[0679] A neural network is a computational model including interconnected units called "‘neurons” that work together to process information. It is a type of ML algorithm that is particularly effective for recognizing patterns and making predictions based on complex data. Neural networks are widely used in various applications such as image and speech recognition and natural language processing, due to their ability to learn from large amounts of data and improve their performance over time. Fig. 26 describes neural network operation fundamentals, according to exemplary embodiments of the present invention.

[0680] Fig. 26 shows a single-layered neural network, also known as a single-layer perceptron. The operation of a single-layered neural network involves the following steps:

[0681] 1. Input: Receiving a DE input vector v 2604 with elements v with j 6 [1, n] representing the ythDE input, and where each element of the vector corresponds to an element 2606 in the input layer. A DE input can be a user prompt, a DE document, a DE model, DE program code, system data from the IDMP, and / or any useful form of data in digital engineering.

[0682] 2. Transfer Function: Multiplying each element of the DE input vector by a corresponding weight w 2608. These weighted inputs are then summed together as the transfer function, yielding the net input to the activation function fl R ■wj 2610.

[0683] Each neuron in a neural network may have a bias value 2612, which is added to the weighted sum of the inputs to that neuron. Both the weights and bias values are learned during the training process. The purpose of the bias is to provide every neuron with a trainable constant value that can help the model fit tire data better. With biases, the net input to the activation function is ^=dVj-wP+ b- 3. Activation Function: Passing the net input through an activation function 2614. The activation function o determines the activation value o 2618, which is the output of the neuron. It is typically a non-linear function such as a sigmoid or ReLU (Rectified Linear Unit) function. The threshold 02616 of the activation function is a value that determines whether a neuron is activated or not. In some activation functions, such as the step function, the threshold is a specific value. If the netDocket No. IST-03.012PCT

[0684] input is above the threshold, the neuron outputs a constant value, and if it's below the threshold, it outputs a zero value. In other activation functions, such as the sigmoid or ReLU (Rectified Linear Unit) functions, the threshold is not a specific value but rather a point of transition in the function's curve.

[0685] 4. Output: The activation value o 2618 is the output of the activation function. This value is what gets passed on to the next layer in the network or becomes the final DE output in the case of the last layer. A DE output can also be an updated twin configuration, digital twin, physical t in, DE document, DE model, DE program code, or any useful fonn of data in digital engineering.

[0686] Fig. 27 shows an overview of an IDMP neural network training process, according to exemplary embodiments of the present invention. The training of the IDMP neural network involves repeatedly updating the weights and biases 2710 of the network to minimize the difference between the predicted output 2704 and the true or target output 2706, where tire predicted output 2704 is the result produced by the network when a set of inputs from a dataset is passed through it. The predicted output 2704 of an IDMP neural network 2702 corresponds to the DE output 2618 of the final layer of the neural network. The true or target output 2706 is the true desired result. The difference betw een the predicted output and the true output is calculated using a loss function 2708, which quantifies the error made by the network in its predictions.

[0687] The loss function is a part of the cost function 2708, which is a measure of how well the network is performing over the whole dataset. The training goal is to minimize cost function 2708. This is achieved by iteratively adjusting the weights and biases 2710 of the network in the direction that leads to the steepest descent in the cost function. The size of these adjustments is determined by the learning rate 2708, a hyperparameter that controls how much the weights and biases change in each iteration. A smaller learning rate means smaller changes and a slow er convergence towards the minimum of the cost function, while a larger learning rate means larger changes and a faster convergence, but with the risk of overshooting the minimum.

[0688] Neural network training combines the processes of forward propagation and backpropagation. Forward propagation is the process where the input data is passed through the network from the input layer to the output layer. During forward propagation, the weights and biases of the network are used to calculate the output for a given input. Backpropagation, on the other hand, is the process used to update the weights and biases 2710 of the network based on the error (e.g., cost function) 2708 of tire output. After forward propagation through the IDMP neural network 2702. the output 2704 of the netw ork is compared with true output 2706, and the error 2708 is calculated. This error is then propagated back through the network, starting from the output layer and moving towards the input layer. Tire weights andDocket No. IST-03.012PCT

[0689] biases 2710 are adjusted to minimize this error. This process is repeated for multiple iterations or epochs until the network is able to make accurate predictions.

[0690] Tire neural network training method described above, in which the network is trained on a labeled dataset (e.g., sample pairs of input user prompts and corresponding output recommendations), where the true outputs are known, is called supervised learning. In unsupervised learning, the network is trained on an unlabeled dataset, and the goal is to discover hidden patterns or structures in the data. The network is not provided with the true outputs, and the training is based on the intrinsic properties of the data. Furthermore, reinforcement learning is a type of learning where an agent learns to make decisions from the rewards or punishments it receives based on its actions. Although reinforcement learning does not typically rely on a pre-existing dataset, some fonns of reinforcement learning can use a database of past actions, states, and rewards during the learning process. Any neural network training method that uses a labeled dataset is within the scope of the methods and systems described herein, as is clear from the overview below.

[0691] Fig. 28 provides additional details on the training process or an IDMP machine learning model, according to exemplary embodiments of tire present invention.

[0692] Transfonner Model Architecture

[0693] The transformer architecture is a neural network design that was introduced in the paper “Attention is All You Need” by Vaswani et al. published in June 2017 (available at arxiv.org / abs / 1706.03762), and incorporated herein by reference as if fully set forth herein. Large Language Models (LLMs) heavily rely on the transformer architecture.

[0694] The architecture (see Fig. 1 in Vaswani et al.) is based on the concept of ‘‘attention'’, allowing the model to focus on different parts of the input sequence when producing an output. Transformers consist of an encoder and a decoder. The encoder processes the input data and the decoder generates the output. Each of these components is made up of multiple layers of self-attention and point-wise, fully connected layers.

[0695] Tire layers of self-attention in the transformer model allow it to weigh tire relevance of different parts of the input sequence when generating an output, thereby enabling it to capture long-range dependencies in the data. On the other hand, the fully connected layers are used for transforming the output of the self-attention layers, adding complexity and depth to the model's learning capability.

[0696] The transformer model is known for its ability to handle long sequences of data, making it particularly effective for tasks such as machine translation and text summarization. In the transformer architecture, positional encoding is used to give the model information about the relative positions of the words in tire input sequence. Since the model itself does not have any inherent sense of order or sequence,Docket No. IST-03.012PCT

[0697] posi...

Claims

Docket No. IST-03.012PCTClaimsWhat is claimed is:

1. A non-transitory storage medium for recording a snapshot of a system configuration, the non-transitory storage medium comprising program code executable by a hardware processor, the program code when executed by tire hardware processor, causes the hardware processor to:receive a request to generate the snapshot of the system configuration that defines a state of a file system, wherein the file system comprises a plurality of resource files, wherein the system configuration references a plurality of tracked files, and wherein each tracked file identifies a given revision of a given resource file in the file system;identify, for each tracked file referenced by the system configuration, a corresponding file revision of a corresponding resource file;generate a plurality of snapshot data items at a time of a snapshot generation, wherein a snapshot data item is generated for each identified file revision to represent a binding of the identified file revision to the snapshot; andrecord, at the time of the snapshot generation, the plurality of snapshot data items as the snapshot of the system configuration, wherein the snapshot represents the state of the file system at the time of the snapshot generation.

2. The non-transitory storage medium of claim 1, wherein the program code further causes the processor to:identify the plurality of tracked files referenced by the system configuration.

3. The non-transitory storage medium of claim 1, wherein the file system comprises a first resource file corresponding to a first digital resource generated using a first digital tool, and a second resource file corresponding to a second digital resource generated using a second digital tool, and wherein the first digital tool and the second digital tool are non-interoperable.

4. The non-transitory storage medium of claim 1, wherein the system configuration defines a dependency scope, wherein the dependency scope is a bounded set of dependencies among file revisions identified by the plurality of tracked files.Docket No. fST-03.0t2PCT5. The non-transitory storage medium of claim 4, wherein the program code further causes the processor to:identify a digital thread executable within the dependency scope, wherein the digital thread comprises one or more functions executable on fde revisions within the dependency scope; and execute the digital thread, wherein the program code to record tire snapshot comprises program code to determine the digital thread has executed correctly.

6. The non-transitory storage medium of claim 1, wherein each fde revision has a unique fde revision identifier, and wherein each snapshot item binds a corresponding fde revision identifier to the snapshot.

7. The non-transitory storage medium of claim 1. wherein for each given fde revision, a content of the given fde revision is associated with a first cryptographic token comprising a first cryptographic hash value, and a fde property of the given fde revision is associated with a second cryptographic token comprising a second cryptographic hash value.

8. The non-transitory storage medium of claim 7, wherein the program code further causes the processor to verify an immutability of the given fde revision by checking the first cryptographic hash value and the second cry ptographic hash value.

9. Tire non-transitory storage medium of claim 1, wherein each resource fde represents a digital engineering resource selected from the group consisting of a digital model, a digital artifact, and a user comment.

10. The non-transitory storage medium of claim 1, wherein the program code further causes the processor to:receive an update to a given digital resource associated w ith a resource fde identified by at least one tracked fde;generate a new revision of the resource fde based on the update; andupdate tire system configuration to identify the new revision of the resource fde.Docket No. IST-03.012PCT11. The non-transitory storage medium of claim 10, wherein the program code to record the snapshot further causes the processor to:identify a source resource file in the file system, based on dependency data in the system configuration, wherein the source resource file corresponds to a source digital resource that the given digital resource depends upon; anddetermine whether the source digital resource is up-to-date, wherein the recording of the snapshot of the system configuration is in response to detenuining that the source digital resource is up-to-date.

12. Tire non-transitory storage medium of claim 10, wherein the program code to record the snapshot further causes the processor to:identify a product resource file in the file system based on dependency data in the system configuration, wherein the product resource file corresponds to a product digital resource that depends on the given digital resource;generate an updated product file revision based on the new file revision; andupdate the system configuration to identify the updated product file revision.

13. The non-transitory storage medium of claim 1, wherein the program code further causes the processor to:generate a document revision from a document template and the system configuration, wherein the document revision comprises references to one or more of the plurality of the tracked files.

14. The non-transitory storage medium of claim 13, wherein the program code further causes the processor to:select the snapshot for document rendering; andgenerate a rendered document from the document revision and the snapshot, by resolving the snapshot data items in tire snapshot to respective file revisions identified by tracked files referenced in the document revision.

15. The non-transitory storage medium of claim 13, wherein each reference in the document revision to a tracked file is associated with an externally addressable document endpoint, and wherein the externally addressable document endpoint comprises an identifier to the document revision, and an identifier for the reference to the tracked file.Docket No. IST-03.012PCT16. The non-transitory storage medium of claim 13, wherein the file system is a first file system, wherein the system configuration is a first system configuration of the first file system, and wherein the document revision is generated based on the first system configuration of the first file system and on a second system configuration of a second file system.

17. The non-transitory storage medium of claim 13, wherein the snapshot is a first snapshot of a first system configuration of a first file system, and wherein the rendered document is generated from the first snapshot of the first system configuration of the first file system, and a second snapshot of a second system configuration of a second file system.

18. A method for recording a snapshot of a system configuration, comprising:receiving a request to generate the snapshot of the system configuration that defines a state of a file system, wherein the file system comprises a plurality of resource files, wherein the system configuration references a plurality of tracked files, and wherein each tracked file identifies a given revision of a given resource file in tire file system,identifying, for each tracked file referenced by the system configuration, a corresponding file revision of a corresponding resource file;generating a plurality of snapshot data items at a time of a snapshot generation, wherein a snapshot data item is generated for each identified file revision to represent a binding of the identified file revision to the snapshot; andrecording, at the time of the snapshot generation, the plurality of snapshot data items as the snapshot of the system configuration, wherein the snapshot represents the state of the file system at the time of the snapshot generation.

19. A non-transitory storage medium for recording a snapshot of a file system on a digital model platform, the non-transitory storage medium comprising program code executable by a hardware processor, the program code when executed by the hardware processor, causes the hardware processor to:receive a user request to update a given digital resource in a file system on the digital model platform, wherein the file system comprises one or more resource files, wherein each resource file is associated with a tracked file tracking a given revision of the resource file, and wherein a state of the file system is defined by a system configuration referencing one or more tracked files;identify a given resource file corresponding to the given digital resource in the file system; identify, from a current system configuration defining a current state of the file system, a current tracked file for a current file revision of the given resource file;Docket No. IST-03.012PCTgenerate a new file revision of the given resource file, based on the user request;generate a new tracked file for the new file revision, wherein the new tracked file comprises an identifier of the new file revision;generate an updated system configuration by updating tire current system configuration to identify the new tracked file in place of tire current tracked file; andrecord a snapshot of the file system, wherein the snapshot comprises the updated system configuration at a time of the snapshot, and one or more tracked files referenced by the updated system configuration.

20. Tire non-transitory storage medium of claim 19, wherein the file system comprises a first resource file corresponding to a first digital resource generated using a first digital tool, and a second resource file corresponding to a second digital resource generated using a second digital took and wherein the first digital tool and the second digital tool are non -interoperable.

Images