Discontinuous access and latency-tolerant coordination across decentralized digital model platforms

Abstract

Systems and methods for managing discontinuous access to an Integrated Digital Model Platform (IDMP) implements zero-trust and zero-knowledge security principles with client-side caching. Hie systems enable real-time data backup, efficient synchronization, and conflict resolution between local and cloud storage while maintaining data integrity and user control. An offline-first application supports intermittent connectivity environments, optimizing performance and security. Cache invalidation utilizes cryptographic techniques, including Elliptic Curve Diffie -Hellman, to create time-bound shared secrets between client and enclave for secure data encryption and session management. A token management system orchestrates data operations using fungible and non-fungible idempotent tokens for change detection across multiple tenant environments. The system coordinates between control plane and data plane components to ensure seamless user experience and data consistency during disconnected operations.

Description

[0001] Discontinuous Access and Latency- Tolerant Coordination Across Decentralized Digital Model Platforms

[0002] Reference to Related Applications

[0003] If an Application Data Sheet (‘‘ADS’’) 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.

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

[0005] U.S. Non-Provisional Applications and Patents

[0006] • U.S. non-provisional patent application No. 19 / 197,754 (Docket No. IST-01.001), filed on May 2, 2025, entitled "Artificial Intelligence (Al) Assisted Digital Documentation for Digital Engineering,” describes Al-assistance tools for digital engineering.

[0007] • U.S. non-provisional patent application No. 18 / 730,782 (Docket No. IST-01.002), filed on July 21, 2024, entitled "Software -Code -Defined Digital Threads in Digital Engineering Systems with Artificial Intelligence (Al) Assistance.”

[0008] • U.S. non-provisional patent application No. 19 / 177.561 (Docket No. IST-01.002B). filed on April 12, 2025, entitled ‘'Software-Code-Defined Digital Threads in Digital Engineering Systems with Artificial Intelligence (Al) Assistance ”

[0009] • U.S. non-provisional patent application No. 19 / 067,972 (Docket No. IST-02.001), filed on March 2, 2025, entitled “Secure and Scalable Model Splicing of Digital Engineering Models for Software-Code-Defined Digital Threads,” describes model splicing for digital engineering platforms.

[0010] • U.S. non-provisional patent application No. 19 / 202,955 (Docket No. IST-02.001B), filed on May 8, 2025, entitled “Secure and Scalable Model Splicing of Digital Engineering Models for Software-Code-Defined Digital Threads.” describes model splicing for digital engineering platforms.

[0011] • U.S. non-provisional patent application No. 19 / 067,902 (Docket No. IST-03.003), filed on March 2, 2025, entitled “Machine Learning Engine for Workflow Enhancement in Digital Workflows,” describes workflow enhancement for digital software platforms. • U.S. non-provisional patent application No. 19 / 067,938 (Docket No. IST-03.006), filed on March 2, 2025, entitled ‘’Multimodal Digital Document Interfaces for Dynamic and Collaborative Reviews,” describes interface enhancement for digital software platforms.

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

[0013] • U.S. Patent No. 12,105.826 (Docket No. 54332-0063001), filed on March 8, 2024. entitled "'Security Architecture for Interconnected Digital Engineering and Certification Ecosystem. ” non-provisional patent application No. 63 / 489,401, filed on March 9, 2023, entitled

[0014] • U.S. Patent No. 12,259,995 (Docket No. 54332-0069001), filed on August 2, 2024, entitled “Securing an Interconnected Digital Engineering and Certification System. ”

[0015] • U.S. non-provisional patent application No. 18 / 899,772 (Docket No. 54332-0074001), filed on September 27. 2024, entitled “Token Management in a Digital Engineering Platform. ’’

[0016] PCT International Applications

[0017] • PCT application No. PCT / US25 / 30345 (Docket No. IST-05.001PCT), filed on May 21, 2025, entitled ""Distributed Digital Threading Platform for Trusted Data Sources,” describes the role of digital platforms in enabling the distributed digital threading of trusted data sources.

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

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

[0020] • 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.

[0021] • 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.

[0022] • 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. • 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 software platforms.

[0023] • 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 fl describes workflow integration with Al-assistance.

[0024] • 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 Platformfl describes digital and physical twin management and the integration of external feedback within a DE platform.

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

[0026] • 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 Workflowsfl describes workflow enhancement for digital software platforms.

[0027] • 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 Filesfl describes multimodal user interfaces for digital software platforms.

[0028] • 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.

[0029] • 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 fl relates to the enhancement of workflows by providing alternative digital tools to perform user-requested digital tasks.

[0030] • PCT application No. PCT / US24 / 47434 (Docket No. IST-03.010PCT), filed on September 19, 2024, entitled “Platform-Enabled Orchestration and Optimization of Digital Workflowsfl describes digital workflow optimization.

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

[0032] • U.S. provisional patent application No. 63 / 442,659 (Docket No. IST-01.001P), filed on February

[0033] I, 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.

[0034] • 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 Al- Assisted Digital Thread Generation f describes model splicer and digital threading technology.

[0035] • U.S. provisional patent application No. 63 / 451,577 (Docket No. IST-02.001P1), filed on March

[0036] II, 2023, entitled "Model Splicer and Microservice Architecture for Digital Engineeringf describes model splicer technology.

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

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

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

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

[0041] • 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 Platfor f describes collaborative capabilities.

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

[0043] • 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 f describes digital and physical twin management and the integration of external feedback within a DE platfonn. • 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.

[0044] • 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.

[0045] • 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.

[0046] • 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.

[0047] • 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.

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

[0049] • U.S. provisional patent application No. 63 / 747,019 (Docket No. IST-03.012P), filed on January' 19, 2025, entitled “Versioning of Digital Artifacts for Collaborative Workflows in Digital Model Platforms,” describes a robust, unified, scalable versioning framework for model-based digital engineering.

[0050] • U.S. provisional patent application No. 63 / 769,490 (Docket No. IST-03.013P), filed on March 10, 2025, entitled “Incentivizing Trust for Digital Models Through Smart Contracts, Incentives Management, and Blockchain Tokens.”

[0051] • 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.

[0052] • 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.

[0053] • 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.”

[0054] • 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. ”

[0055] Notice of Copyrights and Tradedress

[0056] 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 the 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.

[0057] 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 the present invention. The terms ISTARI and ISTARI DIGITAL may be used in this specification to describe the present invention, as well as the company providing said invention.

[0058] FYBER is another trade name that embodies the invention. Hence, the aforementioned trademark name may also be interchangeably used in the specification and drawings to refer to the products / process offered by embodiments of the present invention.

[0059] Field of the Invention

[0060] This invention relates to digital model platforms, and more specifically to the facilitation of discontinuous and / or high latency workflows within said digital model platfonns.

[0061] Background of the Invention

[0062] 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.

[0063] Interconnected digital model platfonns allow decentralized access and sharing of data from various types of digital models and data sources while maintaining trust. Users connecting to such data platforms may face latency issues or network connectivity issues. Maintaining data synchronization and provenance when a user has discontinuous access to a data platform, as well as invalidating data caches when users are no longer authorized, are critical functions that should ideally satisfy zero-trust and zero-knowledge security requirements while maintaining a seamless user experience. However, such security and performance requirements pose stringent constraints which traditional client-side caching and cache management approaches to handling offline access to platforms cannot satisfy. ft is against this background that various embodiments of the present invention were developed.

[0064] Brief Summary of the Invention

[0065] 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.

[0066] Various systems and methods for discontinuous access and latency-tolerant coordination across decentralized digital model platforms are described herein. Specifically, systems and methods for managing discontinuous access to an Integrated Digital Model Platform (ID MP) implementing zero-trust and zero-knowledge security principles with client-side caching are disclosed. The systems enable real-time data backup, efficient synchronization, and conflict resolution between local and cloud storage while maintaining data integrity and user control. An offline-first process is also disclosed, supporting intermittent connectivity environments, thus optimizing performance and security. A cache invalidation process is also disclosed, utilizing cryptographic techniques, including Elliptic Curve Diffie-Hellman, to create time-bound shared secrets between client and enclave for secure data encryption and session management. A token management system is also disclosed, orchestrating data operations using fungible and non-fungible idempotent tokens for change detection across multiple tenant environments. Tire described systems and methods coordinate between platform control plane and customer data plane components to ensure seamless user experience and data consistency during disconnected operations.

[0067] Accordingly, in a first aspect, one embodiment of the present invention, is one or more non-transitory physical storage media storing program code for data storage with real-time synchronization between a first customer data plane and a second customer data plane, both the first customer data plane and the second customer data plane accessible to an interconnected digital model platform (IDMP). The program code is executable by a hardware processor.

[0068] The hardware processor, when executing the program code, causes the hardware processor to detect a connection establishment of a network connectivity between the first customer data plane and the second customer data plane, where the first customer data plane stores a first version of a digital artifact, where tire second customer data plane stores a second version of tire digital artifact, where the digital artifact was extracted from a source model file, and where the digital artifact includes a particular data subunit and a particular artifact metadata. The hardware processor, when executing the program code, causes the hardware processor to also receive a first signature chain, the first signature chain including a first chain of blocks, each block including a first artifact pointer to the first version of the digital artifact, a first hash of a first data subunit of tire first version of the digital artifact, and a first-block cryptographic signature including a second hash of a plurality of first data operations performed on the first version of the digital artifact, the first artifact pointer, and a plurality of first timestamps corresponding to the plurality of first data operations.

[0069] The hardware processor, when executing the program code, causes the hardware processor to also receive a second signature chain, the second signature chain including a second chain of blocks, each block including a second artifact pointer to the second version of the digital artifact, a third hash of a second data subunit of the second version of the digital artifact, and a second-block cryptographic signature including a fourth hash of a plurality of second data operations performed on the second version of the digital artifact, the second artifact pointer, and a plurality of second timestamps corresponding to the plurality of second data operations.

[0070] The hardware processor, when executing the program code, causes the hardware processor to also trigger a detection of a data divergence event related to the digital artifact, the data divergence event corresponding to a difference between the first signature chain and the second signature chain.

[0071] The hardware processor, when executing the program code, causes the hardware processor to also trigger an execution of a data deconfliction process based on the data divergence event, to identify a trusted source for an artifact update of the digital artifact corresponding to the difference between the first signature chain and the second signature chain, where the trusted source is selected from the group consisting of the first version and the second version of the digital artifact.

[0072] Finally, the hardware processor, when executing the program code, causes the hardware processor to trigger a chain update of the first signature chain and the second signature chain based on the identification of the trusted source for the artifact update.

[0073] In one embodiment, the program code further includes code to trigger a merge of at least one of the first version and the second version of the digital artifact to match the trusted source, and trigger a recording of a successful completion of the merge in the first signature chain and the second signature chain.

[0074] In one embodiment, the detection of the data divergence event, tire execution of the data deconfliction process, and the merge, are carried out by a synchronization agent of the first customer data plane.

[0075] In one embodiment, the program code further includes code to trigger a data caching processor of one of the first customer data plane and the second customer data plane to update a local cache storage with a data change associated with the merge. In one embodiment, the difference between the first signature chain and the second signature chain is based on a mismatch between a first given hash of a first given data subunit from a first block of the first signature chain and a second given hash of the first given data subunit from a second block of the second signature chain.

[0076] In one embodiment, the difference between the first signature chain and tire second signature chain is based on a mismatch between a first given timestamp of a given data operation from a first block of the first signature chain and a second given time stamp of the given data operation from a second block of the second signature chain.

[0077] In one embodiment, the difference between the first signature chain and the second signature chain is based on a mismatch between a first artifact metadata of a given version of the digital artifact from a first block of the first signature chain and a second artifact metadata of the given version of the digital artifact from a second block of the second signature chain.

[0078] In one embodiment, the first customer data plane is located at a customer cloud storage instance and the second customer data plane is located at a customer client edge instance.

[0079] In one embodiment, the source model file is stored in the customer cloud storage instance.

[0080] In one embodiment, the first customer data plane is located at a first customer client edge instance and the second customer data plane is located at a second customer client edge instance.

[0081] In one embodiment, tire code to detect the connection establishment of the network connectivity further includes code to compare a first logical clock of the first customer data plane and a second logical clock of the second customer data plane based on a reference timestamp issued by the IDMP based on a trusted time stamp authority (TSA).

[0082] In one embodiment, a given first block cryptographic signature of a given block of the first signature chain is a trusted data envelope (TDE).

[0083] In one embodiment, the digital artifact is accessible through an external, commonly-accessible function script, where the external, commonly-accessible function script provides one or more addressable Application Programming Interface (API) or Software Development Kit (SDK) endpoints that are accessible by third-party applications and users, and where the addressable API or SDK endpoints enable access to the digital artifact without access to an entirety of the source model file.

[0084] In one embodiment, a sharable model representation provides access to a selective portion of tire digital artifact, where the sharable model representation includes the external, commonly-accessible function script, and where the sharable model representation is accessible via the addressable API or SDK endpoints from the first customer data plane and the second customer data plane.

[0085] In one embodiment, tire external, commonly-accessible function script is associated with an action token issued by a token management system of the IDMP, where the external, commonly-accessible function script can only be accessed in the first customer data plane using an access token associated with the action token and provided by the token management system of the IDMP, and where the IDMP detects a data change associated with a function execution of the external, commonly-accessible function script in the first customer data plane based on receiving the access token.

[0086] In one embodiment, tire action token is a non-fimgible idempotent tokens (NFIT) and the access token is a fungible idempotent tokens (FIT).

[0087] In one embodiment, the source model file is stored at a third customer data plane distinct from the first customer data plane and the second customer data plane, and accessible from the IDMP.

[0088] In another aspect or embodiment of the present invention, one or more non-transitory physical storage media storing program code for secure cache invalidation in a customer data plane comiected to an interconnected digital model platform (IDMP) are provided. The program code is executable by a hardware processor. The hardware processor, when executing the program code, causes the hardware processor to determine a session time-to-live (TTL) based on a security policy of the IDMP; generate a time-bound shared secret key (SSK) based on the session TTL; and assign a version identifier to the time-bound SSK.

[0089] The hardware processor, when executing tire program code, causes the hardware processor to also transmit the time-bound SSK. the session TTL, and a signed timestamp of the IDMP, to the customer data plane; trigger, at the customer data plane, a binding of the time-bound SSK to a digital artifact using a trusted data envelope (TDE), upon receipt of the time-bound SSK, the session TTL, and the signed timestamp; and trigger, at the customer data plane, an appending of the TDE to a signature chain associated with the digital artifact.

[0090] The hardware processor, when executing tire program code, causes the hardware processor to also receive, at the customer data plane, an access request to access the digital artifact, the access request including an access permission, an artifact pointer to the digital artifact in the customer data plane, and a local timestamp of the customer data plane.

[0091] Finally, the hardware processor, when executing the program code, causes the hardware processor to trigger, at the customer data plane, a verification of the access permission; trigger, at the customer data plane, a cryptographic determination of a validity of the time-bound SSK, based on the signed timestamp, the local timestamp, and the TDE; and trigger, at the customer data plane, a session validation process based on the verification of the access permission and the cryptographic determination of the validity of the time-bound SSK.

[0092] In one embodiment, the program code further includes code to determine, at the customer data plane, an invalidity of the time-bound SSK, based on the cryptographic determination of the validity of the time-bound SSK; reject, at the customer data plane, the access request, based on the invalidity of the time-bound SSK; and mark as expired, at the customer data plane, all previous versions of the time-bound SSK, based on the version identifier of the time-bound SSK.

[0093] In this embodiment, the program code also includes code to transmit, from the customer data plane, an expired SSK alert to the IDMP; receive, at tire customer data plane, a forgetting instruction including the artifact pointer and a revocation scope; and delete, at tire customer data plane, one or more cached versions of the digital artifact based on the revocation scope.

[0094] Finally, in this embodiment, the program code also includes code to transmit, from the customer data plane, a signed confirmation of cache invalidation to the IDMP, based on the invalidity of the time-bound SSK; and execute, at the customer data plane, one or more cascading revocations to invalidate one or more digital artifacts derived from the digital artifact, based on the revocation scope.

[0095] In one embodiment, the code to generate the time-bound SSK includes code to carry out an elliptic curve Diffie Hellman (ECDH) key exchange.

[0096] In various aspects and embodiments, a computer-implemented method is provided, the computer-implemented method including the steps described herein.

[0097] In various aspects and embodiments, a computer program product is provided. The computer program may include a computer-readable storage medium having program instructions, or program code, embodied therewith, the program instructions executable by a processor to cause the processor to perform the steps described herein.

[0098] In various aspects and embodiments, a non-transitory, computer-readable storage medium is provided. The non-transitory, computer-readable storage medium stores executable instructions which, when executed by a processor, cause the processor to perform the steps described herein.

[0099] In various aspects and embodiments, a system 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 steps described herein.

[0100] In various aspects and embodiments, a system is provided, tire system including a user device having a processor, a display, a first memow; 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.

[0101] In various aspects and embodiments, 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.

[0102] In various aspects and embodiments, 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 steps described herein.

[0103] Other aspects and embodiments of the present invention include the methods, processes, and algorithms comprising the steps described herein, and also include the processes and modes of operation of tire systems and servers described herein.

[0104] 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.

[0105] 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 model system and / or method and / or system, or vice versa, and these embodiments are specifically envisaged.

[0106] Brief Description of the Drawings

[0107] 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.

[0108] 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:

[0109] Interconnected Digital Model Platform ilDMP)

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

[0111] Fig. 3 shows another exemplary- implementation of the IDMP illustrating its offered services and features, in accordance with some embodiments of the present invention.

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

[0113] Fig. 5 shows exemplary- multimodal interface designs for integration of feedback in an IDMP, in accordance with some embodiments of the present invention.

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

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

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

[0117] 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.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] Fyber Platform: A Trust-Enabled IDMP for Digital Threading

[0122] Fig. 13 shows an overview of an interconnected digital model platform (IDMP), in accordance with some embodiments of the present invention.

[0123] Fig. 14 is an exemplary system diagram showing a process for generating and executing a digital thread script extracting data from a trusted data source within an IDMP / Fyber platform, in accordance with some embodiments of the present invention.

[0124] Discontinuous Access to the IDMP / Fyber Platforms

[0125] Fig. 15 shows a system architecture for implementing and managing discontinuous access to the IDMP with client-side data caching, in accordance with some embodiments of die present invention. Fig. 16 shows the use of tokenization for detection of changes in a zero-trust environment, according to one embodiment of the invention.

[0126] Fig. 17 shows yet another system architecture for implementing and managing discontinuous access to the IDMP, in accordance with some embodiments of the present invention.

[0127] Fig. 18 shows a flowchart of an exemplary process for data storage with real-time synchronization between a customer cloud storage instance and a customer client edge instance, both accessible to the IDMP, in accordance with some embodiments of the present invention.

[0128] Machine Learning Implementation Architecture for IDMP / Fvber Operations

[0129] Fig. 19 describes neural network operation fundamentals, in accordance with some embodiments of the present invention.

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

[0131] Fig. 21 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.

[0132] Hardware and Software Architecture for IDMP / Fyber Operations

[0133] Fig. 22 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 tire present invention.

[0134] Detailed Description of the Invention

[0135] 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 tire 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 the 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. Broadly, the present invention relates to methods and systems for discontinuous access and latency-tolerant coordination across decentralized digital model platforms. Specifically, embodiments of the present invention are directed to systems and methods for managing discontinuous access to an Integrated Digital Model Platform (IDMP) implementing zero-trust and zero-knowledge security principles with client-side caching are disclosed. Tire systems enable real-time data backup, efficient synchronization, and conflict resolution between local and cloud storage while maintaining data integrity and user control. An offline-first process is also disclosed, supporting intermittent connectivity environments, thus optimizing performance and security. A cache invalidation process is also disclosed, utilizing cryptographic techniques, including Elliptic Curve Diffie-Hellman, to create time-bound shared secrets between client and enclave for secure data encryption and session management. A token management system is also disclosed, orchestrating data operations using fungible and non-fungible idempotent tokens for change detection across multiple tenant environments. The described systems and methods coordinate between platform control plane and customer data plane components to ensure seamless user experience and data consistency during disconnected operations.

[0136] 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 described in detail in Figs. 1-12, including digital model splicing and threading operations. Second, the Fyber Platform, generalizing IDMP for use with any trusted data sources, is introduced in Figs. 13-14. Third, discontinuous and high-latency processes are detailed in Figs. 15-18, within the framework of model splicing, threading, and secure collaborative workflows on the IDMP and Fyber platforms. Finally, machine learning, hardware and software architectures IDMP / Fyber platfomr operations are described in Figs. 19-22.

[0137] Introduction

[0138] The IDMP / Fyber platform as disclosed herein is a trust layer that provides for linking securely a specific data resource (e.g., a document, a model) with different various trusted sources. Specifically, IDMP / Fyber enables the secure linking of a given document to digital artifacts from different trusted sources. Uris ensures that content not only adheres to high standards of accuracy but is also verifiable against credible references.

[0139] Trusted data sources are required by users within an organization to design and maintain real-world products, systems, and processes. The term "model" applies to any data source such as a digital engineering model file (e.g., CAM, CAD, etc.). More generally, the term “model” applies herein to any data source, and is interchangeable herein with the terms “data source” and “document”. A model that is used by a user as a trusted data source may be alternatively termed herein a “source of truth”, a “trusted source”, or an ‘'authoritative source”. The underlying data emanating from the models is termed “raw files” or “raw data”, or a '‘digital artifact” and may be converted by the platform to an identifiable, traceable, and access-controlled “trusted digital artifact”.

[0140] Multiple distinct software tools are required to build and update the different models. There are usually large teams of professionals dedicated to connecting the models, using careful versioning to make sure work is performed on the right model versions. The Interconnected Digital Model Platform (IDMP) enables extracting data from models without moving them from their network locations. Specifically, it enables the extraction of only the data that is needed, accessible only to users that need it, without any need for the users to trust any participant in the value chain, including tire platform itself. Such a data operation can be regarded as meeting zero-trust principles for access to the data.

[0141] The integration platform is configured to offer application programming interfaces (APIs) and collaboration user interfaces (UIs) connecting tire user’s trusted models into one or more digital threads. Beyond automation, APIs allow the scripting of tasks related to product, system, or process managed by the user.

[0142] Decentralization allows the sharing of model data and enables the large-scale collaboration required to speed up massive projects. Although tire creation of a centralized platform over a centralized network is viable in certain industries, the IDMP / Fyber needs to be a distributed platfonn to enable effective collaboration. The integration platform therefore allows select access to information from disparate trusted data sources, thus enabling decentralized digital threads.

[0143] Digital threading (i.e., the generation and use of a digital thread) is a trust mechanism allowing the user to know that the data they are using comes from the trusted sources that they have selected. Digital threads need to be distributed in order to be effective.

[0144] The methods and systems herein enable zero-trust and zero-knowledge hyper-scalable distributed digital threading that is configured to provide assurances to the user that the data they are using comes from user-trusted sources. Digitally threading portions of a shared network infrastructure would enable a network providing assurances to a user or to an organization that the source of truth (e.g., data source) is trusted, such that the user is able to operate with data emanating from their designated sources of truth. Distributed digital threads also enable powerful tools such as magic docs.

[0145] Correspondence tools such as desktop office software suites are ubiquitous and remain the most common tools even in specialized environments such as engineering and design teams. For almost any project, most organizations need to generate descriptions using correspondence tools. Any document generated or updated using a copy-paste operation may benefit from an integrated interconnected platform able to thread its trusted sources with its generated documents and models. The interconnected platfonn is configured so that any workforce that requires copy and paste may swiftly adopt it to avoid versioning and similar maintenance operations that are necessary when sources of truth are always evolving.

[0146] Enabled by distributed digital threading as disclosed herein, magic docs provide a definitive tool to establish accuracy in organizational decision making. The value of magic docs increases when they are implemented across the organization rather than within a single division (e.g., engineering), in support of correspondence tools, and perhaps across organizations that engage in business collaborations.

[0147] In summan. the IDMP / Fyber allows the processing of an organization’s trusted information sources into one or more digital threads. No matter what derivatives are generated from those trusted sources, tire organization may use them via UI or API, with the knowledge that they come from those original trusted information sources. Furthermore, the data elements (e.g., digital artifacts) originating within the derivatives remain indefinitely and reliably identifiable, traceable, and access-controlled.

[0148] IDMP / Fyber hence provides an auditable trusted network (e.g., Internet) for connecting disparate digital models or any trusted data source through secure digital threads linking digital artifacts and data under zero-trust principles, where magic docs (described below) make the aggregated and / or generated data human-readable.

[0149] IDMP as ‘Mortar’ Linking Generic Digital Artifacts as ‘Bricks’

[0150] The present disclosure relates to the Interconnected Digital Model Platform (IDMP). specifically engineered to enable the integration of digital models, documents, and data from various trusted sources that are inherently non-interoperable and quite often disconnected. This platform addresses the challenges associated with connecting and managing diverse digital artifacts by utilizing API endpoints associated with their respective digital models and software tools, thereby offering an efficient solution for data aggregation and manipulation in trusted environments.

[0151] Functionally, the IDMP serves as the integrating mortar in a conceptual brick-and-mortar analogy, where the “bricks” symbolize various digital artifacts, including data points, software components, or complete digital models. Tire platform ensures that these bricks are not merely connected but are also optimally aligned and securely integrated. It dynamically adapts to the unique characteristics of each artifact to maintain system integrity and functional coherence.

[0152] API endpoints act as critical connective joints within this framework, enabling essential interactions and facilitating data exchanges among the disparate elements. The secure digital threads of the IDMP play a pivotal role, akin to an architectural blueprint and an active construction process. These threads meticulously guide the systematic and precise assembly of the system components. This ensures that the business logic of the entire structure is implemented with accuracy, efficiency, and security. Moreover, the secure digital thread is designed to be auditable, mirroring the rigor and scrutiny applied to the review of architectural blueprints in physical construction.

[0153] Through these advanced mechanisms, the IDMP fosters the creation of a cohesive and functional digital ecosystem. This ecosystem supports an auditable, trusted layer for digital information management across the internet, enhancing the reliability and accessibility of digital services in various sectors.

[0154] To further illustrate the details, consider documents as bricks that are spliced within the IDMP. The IDMP facilitates the manipulation of these documents through various input and output functions, forming an integral part of the digital mortar. A digital thread within IDMP might utilize one or more of the following input function types to splice a document:

[0155] 1. Dropdown for paragraph selection, listing available paragraphs

[0156] 2. Number input for identifying paragraph ID

[0157] 3. Text input for editing paragraph content

[0158] 4. Checkbox options to add, delete, or hide paragraphs

[0159] Corresponding outputs from these inputs include:

[0160] 1. Tire text content of paragraphs

[0161] 2. JSON files detailing the document's hierarchical structure

[0162] 3. The total paragraph count

[0163] 4. Options to download the document as a .docx file

[0164] 5. Extracted numeric, text, or media artifacts

[0165] 6. Capabilities to export the document in other formats, such as .txt and .pdf

[0166] These input and output functionalities enable IDMP to robustly handle the integration and manipulation of digital artifacts, thereby constructing a secure and efficient system. This metaphor of constructing a building with diverse bricks (digital artifacts) linked through a meticulously planned and executed mortar (digital threads and API endpoints) effectively captures the essence of how IDMP integrates disparate digital artifacts into a functional, coherent system executing digital threads.

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

[0168] 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), 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 arc 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 platform (IDEP) is a representative type ofIDMPs.

[0169] 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. The engineering team from the manufacturer may create or instantiate digital twin (DTw) 122 of the 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 perfomrance 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 tire 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.

[0170] 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.

[0171] 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 by 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.

[0172] 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 tire splice plane 170 enable autonomous data linkages and digital thread generation, ensuring DTw 122 accurately represents the product’s real -world performance and characteristics.

[0173] 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.

[0174] 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.

[0175] 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.

[0176] 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 comprise 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.

[0177] 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.

[0178] Virtual and Physical Feedback Loons

[0179] 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. Tire 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 the digital thread.

[0180] 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. Perfonnance 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.

[0181] 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 are associated with an applied twin configuration from the twin configuration set 156. PTw 132 and / or 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.

[0182] 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.

[0183] 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”. Tire 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.

[0184] 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 or a PTw, tire platfonn 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.

[0185] 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.

[0186] 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 model splicing, along with the feedback architecture shown in Fig. 1 , improves the efficiency of the overall product innovation process. Interconnected DE Platform and Product Lifecycle

[0187] 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:

[0188] 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.

[0189] 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 platform, as described in detail with reference to Figs. 7 to 9.

[0190] C. Link threads as needed among model splices: to implement a product, model splices are linked through scripts within application plane 160. A digital twin (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 twin configuration set 156 located at the analysis & control plane (A CP) 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.

[0191] D. Finalize “As-designed”: performance 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 tire 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 run on the various DTw iterations.

[0192] E. Finalize “As-manufactured”: 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 data 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.

[0193] 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 the assembled configuration. This involves creating a digital representation of the assembly to ensure it meets the specified requirements. The 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 the 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 tire physical assembly process and ensure accurate replication. IDMP 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.

[0194] G. Finalize “As-operated”: to assess the performance 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 performance metrics and serve as virtual replicas of the physical system. Digital twins 122 are continuously updated and refined in real-time using tire 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.

[0195] H. Predictive analvtics / 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 the 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. The 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 perfonnance metrics to enhance their predictive accuracy. This iterative process ensures that the digital twins (e.g., 122, 156) provide reliable predictions of future perfonnance and assist in making informed decisions.

[0196] 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.

[0197] Digital Documentation through Live Digital Objects

[0198] 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. Live digital objects may be referred to as "‘live digital resources"’ in the context of the Fyber platform.

[0199] 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 predetennined delay. In various embodiments, the updates are effectively real-time or near real-time.

[0200] 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. 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 files 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.

[0201] Finally, a live digital object may take tire 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.

[0202] Live digital objects may be stored and accessed through an IDMP Specifically, live digital objects may be used to provide the 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.

[0203] 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.

[0204] Given the 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 subset of model files within a DTw or a system, thus reflecting changes only to key parameters and configurations of the DTw or the system. The “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.

[0205] 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 the 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.

[0206] 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”.

[0207] 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, the 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 tire 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.

[0208] 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 IDMP digital threads and documents. In addition to generating a digital thread (with orchestration scripts and 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. 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 IDMP 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 IDMP script queries relevant DE models (via their model splices) or associated digital threads, for flagged modification. In these embodiments, the IDMP 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 IDMP 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 IDMP script may use the modified data to update the live DE document.

[0209] Dynamic Document Updates

[0210] 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 IDMP platform and the accompanying documentation.

[0211] 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. The 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 are updated based on a subset of a system’s DE models and within a maximum time delay may therefore be more efficient. Interconnected Digital Engineering and Certification Ecosystem

[0212] Fig. 2 shows an exemplary implementation of the IDMP 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 IDMP 100 shown in Fig. 1. The IDMP may also be referred to as a “DE Metaverse.”

[0213] 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 regulatory' 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.

[0214] More specifically, Fig. 2 shows 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 drug 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 can 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 tire 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.”

[0215] 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). 1ECEE 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, ISO 10204, EN 1090, ISO 14004, etc.), and manufacturing certification regulation 210J (e.g.. General Certification of Conformity (GCC), etc.), etc.

[0216] 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.

[0217] 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 useful 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. Similarly, any analysis and control functions performed via computing system 208 may be tracked for auditability and traceability considerations.

[0218] 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.

[0219] 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 21 OH), 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).

[0220] 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 tire 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 information 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).

[0221] In any of tire aforementioned examples, computing system 208 can receive the 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 the repository of common V&V products 210 via the API / SDK 216 to retrieve the relevant common V&V product of interest and processing the 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, tire 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).

[0222] 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.

[0223] Not all DE tools 202 are necessarily required for tire 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 only 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.

[0224] 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 the 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).

[0225] 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 beyond 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.

[0226] 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).

[0227] While the examples described above focus on the use of the 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.

[0228] Indeed, in some implementations, user credentials for user 204 can be indicative of tire skill level of user 204, and can control the amount of automated assistance the user is provided. For example, non-subject matter experts may only be allowed to utilize tire ecosystem to browse pre-made designs and / or solutions, to use DE tools 202 with certain default parameters, and / or to follow a predetermined 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.

[0229] 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).

[0230] 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.

[0231] This training dataset can then be used to train ML models (e.g.. using ML engine 220) to leam 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, predictively estimating the results of sensitivity analyses, and even suggesting design changes, original designs or design alternatives (e.g., via 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.

[0232] 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 carry 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 models / analysis 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 platform.

[0233] 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 representations 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 detennine 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.

[0234] Fig. 9 in PCT application No. PCT / US25 / 30345 (Docket No. IST-05.001PCT) shows how Fyber may handle two major scenarios common in dealing with trusted sources: authenticated and / or ephemerally authenticated access. PCT application No. PCT / US25 / 30345 (Docket No. IST-05.001PCT) also describes various architectures, use cases, and exemplary graphical user interfaces (GUIs) related to the Fyber platform.

[0235] Secure Digital Thread Execution Across Diverse Networks Through Multi-tenant Enclaves

[0236] Fyber involves a sophisticated method and system for the orchestrated execution of digital threads encapsulating operations and data transactions throughout distributed and heterogeneous networks. Fyber is specifically engineered to ensure the integrity and referential consistency of data as it navigates through networks with varying security classifications, and across different disjointed data storages. This is achieved by safeguarding data against alterations or inconsistencies that could arise due to tire complexity of the network infrastructure. Fyber thereby facilitates a reliable management of data-driven processes, ensuring data integrity and consistency across multifaceted security and network domains.

[0237] The architecture of Fyber is distinguished by the implementation of multi-tenant enclaves. These enclaves represent secure operational domains within which digital threads are executed and managed, while preserving the data sovereignty within the individual enclaves. Integral to these enclaves are robust authentication (AuthN) and authorization (AuthZ) systems designed to enforce secure access to and control over resources within the system. Fig. 3 shows an exemplary implementation of the IDMP illustrating its offered services and features using multi-tenant enclaves, in accordance with some embodiments of the present invention. In particular, Fig. 3 shows an architecture of multi-tenancy enclaves that allows secure digital thread orchestration. For each enclave, the identity service and permission service authenticates users and authorizes them to perform the requested actions. The platform authenticates users and authorizes them using the identity service and pemrission service, to access the different tenants and perform tire requested tasks.

[0238] Specifically, an exemplary implementation architecture diagram 300 is shown in Fig. 3 to include multiple illustrative components: an IDMP enclave 302, cloud services 304, and a customer environment 310 which optionally includes an IDMP exclave 316. This exemplary architecture 300 for the IDMP is designed in accordance with zero-trust security principles and is further designed to support scalability as well as robust and resilient operations. IDMP enclave 302 and IDMP exclave 316 together instantiate IDMP 100 shown in Fig. 1, with IDMP 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 IDMP, to perform work for individual customers. Examples of exclaves include virtual machines (VMs) and / or servers that the IDMP maintains to run tools for customers who need such services.

[0239] In particular, IDMP enclave or platform enclave 302 may serve as a starting point for sendees rendered by the IDMP, and may be visualized as a central command and control hub responsible for the management and orchestration of all platfonn operations. For example, enclave 302 may be implemented using computer system 208 of the interconnected ecosystem shown in Fig. 2. 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, 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. Platform enclave 302 may also include one or more of the features described below.

[0240] First, IDMP enclave 302 may be designed in accordance with zero-trust security principles. In particular, platform enclave 302 may employ zero-trust principles to ensure that no implicit trust is assumed between any elements, such as digital models, platfonn agents or individual users (c.g., users 204) or their actions, within the system. That is, no agent may be inherently trusted and the 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.

[0241] IDMP 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. Enclave 302 disallows cryptographic dependencies from external enclaves and enforces strong isolation policies. The 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, enclave 302 is designed with decoupled resource sets, minimizing interdependencies and thereby promoting system efficiency and autonomy.

[0242] IDMP 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.

[0243] IDMP enclave 302 can further be designed for workflow adaptability, accommodating varying customer workflows and 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. Platform 300’s adaptability makes it highly versatile for a multitude of use-cases, while ensuring consistent performance and robust security.

[0244] IDMP enclave 302 can further be designed to enable analytics for robust platform 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 operational 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.

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

[0246] 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 platfonn 300, adding to its overall functionality. A “Logging Service Cell” and a “Control Plane Service Cell” provides ‘'Logging Service,” '‘File Service”, and “Job Service” to record and manage operational events and information flow within platform 300, and 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 platfonn 300. An “API Gateway Sendee Cell” provides “API Gateway Service,” and may provide platfonn API(s) and act as a mediator for requests between the client applications and the platfonn sendees. In some embodiments, the API gateway service cell may receive and respond to requests from agents such as platform exclave 316 to provide splice functions for model splicing purposes.

[0247] As shown in Fig. 3, the architecture of platfonn 300 may also include a cloud services 304 that provide services which cannot interact with customer data but can modify the software for the orchestration of platform operations. In example implementations, several cloud resources provide support and foundational services to the platform. For example, in the embodiment of the 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. Cloud services 304 may also include an “Orchestration Service” that controls and manages the lifecycle of containers on the platfonn 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.

[0248] As shown in Fig. 3, the architecture of platform 300 may also include a customer environment 310 with an “Authoritative Source of Truth” 312, customer tools 314, and an optional platform exclave 316. Customer environment 310 is where customer data resides and is processed in a zero-trust manner by platform 300. As described previously, platfonn 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, platform exclave 316 may be situated within customer environment 310 in order to assist the customer(s) 306 with their tasks and operations, including model splicing and digital threading.

[0249] When a customer 306 (e.g., user 204) intends to perform a task using platform 300 (e.g., IDMP 100), typical operations may include secure data ingestion and controlled data retrieval. Derivative data generated through the operations, such as updated digital model files or revisions to digital model parameters, may be stored only within customer environment 310, and platform 300 may provide tools to access the metadata of tire 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 platfomr tool referred to as a “tokenizer” is deployed within customer environment 310 for secure management of derivative metadata, conforming to zero-trust guidelines.

[0250] Customer environment 310 may interact with other elements of secure 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. Uris setup ensures uncompromising data security within customer environment 310 while providing smooth interactions with other elements of platform 300.

[0251] 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 “Tool Host” component may handle necessary applications for working with customer data. It may include a Tools Command-Line Interface (DET CLI), enabling user-friendly command-line operation of tools (e.g., tools 102). A “Platform Agent” ensures smooth communication and management between customer environment 310 and elements of platform 300. Furthermore, there can be another set of optional tools designed to assist customer-specific workflows. Native tools are typically access-restricted by proprietary licenses and end-user license agreements paid for by the customer. ID MP platform functions call upon native tools that are executed within customer environment 310, therefore closely adhering to the zero-trust principle of the system design. Exemplary digital engineering (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.

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

[0253] 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 IDMP (see Fig. 4) and the availability of training data. In an example, a pre-trained ML or Al model (e.g., within the IDMP 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 agents and tools in the customer environment (e.g., within IDMP 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 IDMP enclave.

[0254] Identity service and Permission service

[0255] Fig. 3 shows an example architecture of Fyber, w hich includes the addition of an Identity service and Permission service in addition to IDMP, and makes multi-tenancy within the enclave possible. Multi-tenancy means that the Fyber platform can orchestrate digital threads across multiple tenants in a zero-trust and zero-knowledge fashion thus. There are 3 essential elements to multi-tenancy that Fig. 3 makes possible: 1) there is an internal identity service, 2) there is an internal permission service and 3) all resource mutations are first authenticated by the identity service and authorized by the permission service.

[0256] Authentication is achieved through OpenlD Connect protocols, with Zitadel serving as an exemplary identity service to verify the credentials of users and systems. Authorization is managed by a permissions service, exemplified by SpiceDB, which utilizes the Zanzibar framework or Relationship-Based Access Control (ReBAC). This design enables precise access control, ensuring operations within the digital threads are securely managed in accordance wdth established security policies.

[0257] Tire security’ model underpinning Fyber adheres to zero-trust and zero-knowledge principles, mandating the verification of all access requests without assuming any inherent trust within or across network boundaries. This model necessitates that each request for data access or operational execution undergo stringent authentication and authorization checks, significantly mitigating the risk of unauthorized access and data breaches. The adoption of ReBAC, facilitated by services such as SpiceDB, empowers Fyber with dynamic and context-sensitive access control capabilities. This advanced authorization mechanism allows for real-time decision-making based on the relationship between the requester and the resources, enhancing the system’s ability to manage access in complex, shared environments.

[0258] Implementation of multiple ASOTs in a multi-tenant enclave will repeat a similar set of steps as adding a single ASOT to an enclave, including the additional step that a service performing a requested operation within the enclave asks the Permission service, e.g., SpiceDB's permission first each time, before access is granted to the sendee for the requested operation.

[0259] The system employs an infinite recursion model for tracking the lineage and dependencies of data within a digital thread, ensuring the execution integrity of said thread amidst varied security environs. Fig. 7 in PCT application No. PCT / US25 / 30345 (Docket No. IST-05.001PCT) presents a simple example of the recursion method necessary and a key invention of Fyber is the secure scalable orchestration of these recursions to execute the digital threads. Through leveraging authoritative sources of truth (ASOTs) for validation and integrity checks, the process enforces stringent security across inter-network operations.

[0260] This technical description outlines an integrated system for the secure execution of digital threads and the linkage of digital artifacts, leveraging operations and data transactions across distributed and heterogeneous networks. This system is designed to maintain the integrity, referential consistency of data across varying security classifications and network environments, and ensure coherent access and manipulation of digital artifacts from diverse ASOTs within a controlled security model.

[0261] In summary, secure digital thread execution with generic ASOTs (Fyber) must have zero-trust security for auditability; zero-knowledge orchestration can be done optionally. The zero-trust implementation of multi-tenant enclaves is necessary' for authenticating that specific digital artifacts are either source data or derivative data. And, in the event the data is derivative, to be able to trace back to the source for verification. Zero-knowledge implementation further allows Fyber to securely handle more than one customer (or their sub-customers) per enclave. However, in some implementations, tire zero-knowledge assumption may be relaxed in the implementation where the individual tenants identify a business value for permissioned access to underlying data, e.g.. when the metadata and contents of the digital artifacts could be used to train machine learning models that assist users in aggregating ASOTs. IDMP Deployment Scenarios

[0262] Fig. 4 shows potential scenarios for instantiating an IDMP 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 IDMP 402 in connection to a customer's IT environment and physical system 404. Note that the IDMP is also referred to as the IDMP / Fyber platform, or “Fyber platform” herein, as further discussed in Fig. 13.

[0263] The IT environment may be located on a virtual private cloud (VPC) protected by a firewall. The physical system may refer to a client system or a physical twin. In some embodiments, IDMP 402 may be instanced as an enclave such as 302 shown in Fig. 3. For example, IDMP 402 may be instanced on the cloud, possibly in a software-as-a-service (SaaS) configuration. Tire platform instances in these embodiments include software and algorithms, and may be described as follows:

[0264] 1. External Platform Instance 410: This option showcases the IDMP as a separate platform instance. 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.

[0265] 2. External Platfomr Instance with Internal Agent 420: The IDMP is instantiated as a separate platform, connected to an internal IDMP agent (also called “Fyber Agent”. “FyberAgent” or “Fyberagent” herein) wholly instanced within the Customer VPC. For example, the IDMP may be instantiated as enclave 302. and a Fyberagent may be instantiated as exclave 316 within the Customer VPC linked to the physical system.

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

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

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

[0269] 6. Air-Gapped Platfonn Instance 460: This scenario illustrates tire IDMP being completely instanced on an air-gapped, or isolated, physical system as a IDMP agent. Tire 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 platform in this context would occur directly on the physical system, with any data exchange outside the physical system being controlled following strict security protocols to maintain the air-gapped environment.

[0270] Across these deployment scenarios, the IDMP plays an important role in bridging the gap between digital artifacts established through the IDMP and their data sources. Regardless of how the IDMP is instantiated, it interacts with the physical system, directly or through the customer's virtual environment. Tire 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. In certain deployment scenarios, the edge instance of the IDMP / Fyber platform may face latency issues or network connectivity issues (interruption in connectivity indicated by lightning symbols 432 and 442). To manage latency, exemplary edge instances can utilize content delivery networks (CDNs) or perform edge computing for essential functionalities. To address network connectivity issues, these edge instances can implement an offline mode with features such as local data storage, network connected storage nodes for background synchronization, application caching, and resilient APIs. In some embodiments, the IDMP / Fyber platform edge instance may also be deployed with progressive enhancement of functionality to manage network connectivity' issues. In some cases, air-gapped deployment nodes 460 and edge instances 440 act as local nodes of the platform but with varying latency issues - prohibitively high latency in air-gapped installations and sporadic latency in edge instances. These embodiments can occasionally connect with a network connected storage node to maintain their platfonn state and synchronize, mitigating latency impacts. Across these scenarios, the nodes for the IDMP agents perform similarly. Consistent with security requirements, these agent nodes operate in a pinging mode rather than a pushing mode. When edge instances come back online, they retry' back-off and lean-in with a network connected storage node, to reestablish the state and perform operations continuously. Furthermore, the ability of the platform to connect directly to the physical system through API calls underscores the importance of interoperability in facilitating efficient data exchange. In all cases, the IDMP / Fyber platform operates with robust security measures.

[0271] In some embodiments, the IDMP 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 IDMP / Fyber platform (direct API connection scenario 450), while other physical systems may have an edge instance connection (edge instance connection scenario 440). Multimodal User Interfaces

[0272] Fig. 5 illustrates the use of multimodal user interfaces 590 for the interconnected 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. Alternatively, the analysis module 154 of the ACP 150 may process inputs in order to update a user’s data sources in a trusted source database of the ACP (see PCT application No. PCT / US25 / 30345 (Docket No. IST-05.001PCT)).

[0273] The 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 the 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.

[0274] Dashboard-sty le 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.

[0275] 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 tire overall workflow.

[0276] 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 platform workflow. Outputs from the platform may undergo the reverse process. This enables interoperability with the platfonn, 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, information, or events, and using auditory cues or patterns to communicate important information to users, operators, or reviewers. Sonified alerts (e.g., alerts sent via sound, e.g., via a speaker) are especially usefi.il 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 or breaches.

[0277] 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 platfonns, 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 information, or control devices through natural dialogue without requiring specialized knowledge of complex commands or navigation structures.

[0278] 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 allow 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.

[0279] 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.

[0280] 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 pscudo-3D effect, without fully rendering a complete 3D environment. Hie 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.

[0281] Digital Threads and Autonomous Data Linkages

[0282] 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.

[0283] 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 exemplar}' 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 any 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).

[0284] 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.

[0285] A major issue with dealing with interdependent DE models is that graph consistencies can be polynomial, and potentially exponential, in complexity. Hcncc, 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.

[0286] 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 the dynamic updates of live or magic documents discussed in the context of Fig. 1. Here, the logic to connect tire 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 tire 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 the 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 ID MP may provide a GUI-based interface to the user to connect the models and execute the digital threads. For complex threads such as 606, a code-based interface may be necessary.

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

[0288] 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 file without exposing the entire DE model file, with access control to the encapsulated model data based on user access pennissions. 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. Tire 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.

[0289] 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 the flow of information 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.

[0290] 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 DE 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.

[0291] 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 IDMP as disclosed herein.

[0292] 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.

[0293] Exemplary Model Splicing Setup

[0294] 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.

[0295] 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 form 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 tire DE model data. The DE model data are model-type-specific, and a model splice is associated with model-type-specific input and output schemas. 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.

[0296] 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.

[0297] Tirus, a DE model typc-spccific 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.

[0298] 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 tire 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.

[0299] In the CAD model splicing example shown in Fig. 7, a CAD model file diesel-engine. pit 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 .pit 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. Thi s 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 acccss-rcstrictcd 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.

[0300] Tire 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 list), Generate2DView(), 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 IDMP, and orchestration scripts that link multiple model splices, constitutes a Platform API. This platform API is a common, universal, and extemally-accessible platform interface that masks native API 702 of any native DE tool integrated into the IDMP, thus enabling engineers from different disciplines to interact with unfamiliar DE tools, and previously non-interoperable DE tools to interoperate freely.

[0301] 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 model 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 permutation. 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 platform applications that act on multiple DE models.

[0302] 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.

[0303] One advantage of model splicing is its inherent minimal privileged access control capabilities for zero-trust implementations of the IDMP as disclosed herein. In various deployment scenarios discussed with reference to Fig. 4, and within the context of IDMP 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. Tire 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. Thus, 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, purposeful, and auditable interactions with subsets of the model-type files built from component parts or atomic units that assemble to parts.

[0304] Digital Threading of DE Models via Model Splicing

[0305] 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.

[0306] 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.

[0307] Tirus, 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 IDMP 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. The 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.

[0308] 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 platfomr API 890. Platform API 890 comprises not only splice functions but also platform scripts or orchestration scripts such as 894 itself.

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

[0310] 1. Get Data From a CAD Model Splice: A POST request may be sent via the IDMP platform API to execute a computer-aided design (CAD) model splice 871. This model splice provides a uniform interface to modify and retrieve infomiation about a CAD model 881. Hie parameters for the CAD model, such as hole diameter, notch opening, flange thickness, etc., may be sent in the 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. The response may further comprise a URL for an image of the CAD model.

[0311] 2. Get Data From a SysML Model Splice: Another POST request may be sent via the IDMP 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 platfonn API includes the total mass requirement for the system.

[0312] 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.

[0313] In short, orchestration script 894, which may be implemented in application plane 160 of IDMP

[0314] 100 shown in Fig. 1, links digital models 881 and 882 via model splice API calls. Orchestration script 894 is a scripted platform 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 IDMP 100 utilizes sets of functions to act upon more than one DE model.

[0315] Model Splice Plane

[0316] 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. The central platform 910 comprises program code that is able to interpret and manipulate original DE models of distinct model types. For example, platform 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 platfonn 910 so that data from digital model 984 are converted into fomrats that can be accessed by digital model 982 via digital model 982’s native APIs. This hub-and-spoke 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.

[0317] 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 tire 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 IDMP 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 platfonn 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.

[0318] 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.

[0319] 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.

[0320] Supported by model splicing, digital threading, and digital twinning capabilities, the IDMP as disclosed herein connects DE models and DE tools to enable simple and secure collaboration on digital 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 IDMP 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 IDMP 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 IDMP 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 IDMP also provides simple data access and digital threading options via secure web applications or secure APIs. DAG Representation of Threaded Tasks

[0321] 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 perfonned 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.

[0322] 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.

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

[0324] 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.

[0325] 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 the 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, the 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).

[0326] In the 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:

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

[0328] • Fetch data artifacts from a model.

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

[0330] 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 service cell, coordinated with platform 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.

[0331] 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.

[0332] Inner Loop 11 16, by contrast, is responsible for localized operations related to individual digital models, including:

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

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

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

[0336] • Analyzing data, providing insights and validation for digital workflow improvements.

[0337] 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.

[0338] 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 IDMP, 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. Decentralized Digital Threads in the IDMP

[0339] 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).

[0340] 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 the same security framework, allowing collaboration while maintaining security.

[0341] 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. When discontinuous access is experienced by different nodes accessing the same artifact, model, or digital object, updates to the artifact, model, or digital object (i.e., so called “data events” or “data divergence events”) are synchronized and resolved using the methods described herein (see Figs. 15-17).

[0342] In various implementations, 1122 and 1132 can be regarded as different instances of the Customer environment 310 shown in Fig. 3.

[0343] 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.

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

[0345] The IDMP links different types of digital model fdes in a decentralized fashion with zero-trust security. When a user requests a data operation on a digital model fde 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.

[0346] 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 tire relevant data artifacts, and store it securely.

[0347] 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). This digital workflow of user actions and data relationships is stored in a non-proprietary format within the customer’s environment.

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

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

[0350] 2. Parent / Child - (The Model and Derived information from a model)

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

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

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

[0354] 6. Data Flow (Connected via digital threads - data from one model into another)

[0355] Such data relationships can vary from one user to another even for the same overall digital workflow task.

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

[0357] 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 tire aerospace industry. Tire digital platfonn 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 the inner or outer loops, as depicted in Fig. 11. For completeness and compliance, the digital platform may further add tests for the key steps and tasks of the digitized workflows in tire 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 platform may hence generate dynamic reports 1208 (e.g., Magic Docs) linked to tire inner-loop models used by the 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.

[0358] Fyber: IDMP Platform as a Trust Architecture

[0359] One embodiment of the present invention generalizes the IDMP to any trusted data source over the public Internet. Accordingly, Fig. 13 shows an overview of an interconnected digital model platform (IDMP), or Fyber platfonn, in accordance with some embodiments of the present invention. Specifically, Fig. 13 shows an overview of a Fyber platform (sometimes referred to simply as ‘platfonn’, ‘software platform’, or ‘digital platform’), in accordance with some embodiments of the present invention. An IDMP. referred to later in this disclosure, may be considered one embodiment of a Fyber platform applied to models and simulations.

[0360] Trusted data sources 1320 are required by users within an organization to design and maintain real-world products, systems, and processes. In Fig. 13, the tenn “model'’ applies to any data source such as a digital engineering model file (e.g., CAM, CAD, etc.). More generally, the term “model'’ applies herein to any data source, and is interchangeable herein with the terms “data source” and “document”. A model that is used by a user as a trusted data source may be alternatively termed herein a “source of truth”, a “trusted source”, or an “authoritative source”. The underlying data emanating from the models is termed “raw files”, “raw data”, or “digital artifact” 1330 and may be converted by the platform to an identifiable, traceable, and access-controlled “trusted digital artifact”.

[0361] Multiple distinct software tools are required to build and update the different models. There are usually large teams of professionals dedicated to connecting the models, using careful versioning to make sure work is performed on the right model versions. The platform 1302 enables extracting data from models without moving them from their network locations. Specifically, it enables the extraction of only the data that is needed, accessible only to users that need it, without any need for the users to trust any participant in the value chain, including the platform itself. Fig. 13 shows an extracted artifact 1332 at its location within a raw file. For every user request to bring forth an extracted artifact, the user’s request is authorized to bring the extracted artifact within a secure digital thread 1308 or a magic doc 1310. While the user authorization for each request conforms with zero-trust security, in some embodiments, the Fyber platform can additionally perform the orchestration of the extracted artifact within the digital thread or magic doc in a zero-knowledge fashion. In some embodiments, this may be carried out by working with the location information of the extracted artifact and without having access to the extracted artifact itself.

[0362] The integration platfomr 1302 shown in Fig. 13 is configured to offer application programming interfaces (APIs) 1304 and collaboration user interfaces (UIs) 1306 connecting the user’s trusted models into one or more digital threads 1308. Beyond automation, APIs allow the scripting of tasks related to product, system, or process managed by the user.

[0363] Decentralization allows the sharing of model data and enables the large-scale collaboration required to speed up massive projects. Although the creation of a centralized platfonn over a centralized network is viable in certain industries, the platform needs to be a distributed platform to enable effective collaboration. The integration platform 1302 therefore allows select access to information from disparate trusted data sources 1322, thus enabling decentralized digital threads.

[0364] Digital threading (i.e., the generation and use of a digital thread) is a trust mechanism allowing the user to know that the data they are using comes from tire sources that they have selected. Digital threads need to be distributed in order to be effective.

[0365] The methods and systems herein enable zero-trust, zero-knowledge hyper-scalable distributed digital threading that is configured to provide assurances to the user that the data they are using comes from user-trusted sources (e.g., 1324). Digitally threading portions of a shared network infrastructure would enable a network providing assurances to a user or to an organization that the source of truth (e.g., the data source 1324) is trusted, such that tire user is able to operate with data emanating from their designated sources of truth / trust. Distributed digital threads also enable powerful tools such as magic docs. (See, for example. PCT application No. PCT / US25 / 30345 (Docket No. IST-05.001PCT).)

[0366] Correspondence tools such as desktop office software suites are ubiquitous and remain the most common tools, even in specialized environments such as engineering and design teams. For almost any project, most organizations need to generate descriptions using correspondence tools. In one embodiment, any document generated or updated using a copy-paste operation may benefit from an integrated interconnected platfonn 1302 able to thread its trusted sources 1320 with its generated documents (e.g., 1310) and models. The interconnected platform 1302 is configured so that any workforce that requires copy and paste operations may swiftly adopt it to avoid versioning and similar maintenance operations that are necessary when sources of truth / trust are always evolving.

[0367] Enabled by distributed digital threading as disclosed herein, magic docs 1310 provide a definitive tool to establish accuracy in organizational decision making. The value of magic docs increases when they are implemented across the organization rather than within a single division (e.g., engineering), in support of correspondence tools.

[0368] In summary, the Fyber platform allows the processing of an organization’s trusted information sources into one or more digital threads. No matter what derivatives are generated from those trusted sources, the organization may use them via UI or API, with the knowledge that they come from those original trusted information sources. Furthermore, the data elements (e.g., digital artifacts 1332) originating within the derivatives remain indefinitely and reliably identifiable, traceable, and access-controlled.

[0369] Fyber hence provides an auditable trusted network (e.g., Internet) for connecting disparate digital models or any trusted data source through secure digital threads linking digital artifacts and data under zero-trust principles, where live documents, sometimes called magic docs (see, for example, PCT application No. PCT / US25 / 30345 (Docket No. IST-05.001PCT)), make the aggregated and / or generated data human-readable.

[0370] Fyber Enables a “Trust Laver”

[0371] Fyber introduces a trust layer to any network infrastructure, addressing the issue of verifying the accuracy of derivative data in addition to the source data. In tire digital environment, where the authenticity of content is often under scrutiny, Fyber provides a mechanism for tracing any piece of information (e.g., digital artifact) back to its original source efficiently. This system enables users and platforms to interact with derivative data with assurance, supported by a verifiable link to its origins. Fyber enhances the tracking and authentication of derivative relationships, which could significantly reduce misinformation and increase the transparency and reliability of digital content across various sectors, including media, education, and others.

[0372] Following are some of the important principles that shape a trust layer to ensure robust interoperability and security:

[0373] 1. All data is accessed directly from up-to-date authoritative trusted sources.

[0374] 2. All previously linked authoritative data stays immutably stored and linked to the present.

[0375] 3. Data from all authoritative trusted sources may be integrated without being aggregated.

[0376] 4. All data access orchestration must follow zero-trust and zero-knowledge principles.

[0377] Further, the following additional principles shape and enhance human centricity in the trust layer, in addition to upholding data sovereignty:

[0378] 5. Tire Fyber platform orchestrates linked data so they automatically update as authoritative sources update. 6. Data access can be user- or organization-specific, or selectively made available to the public at large.

[0379] 7. Select adjudication (e.g., validation or verification, reviews) of both authoritative and integrated data sources is also immutably linked to the source.

[0380] In summary, interoperability, security, and human-centricity are foundational to building a trust layer in any network infrastructure. By ensuring seamless integration of up-to-date authoritative sources, maintaining immutable records, and implementing zero-trust principles, Fyber enhances the reliability and security of data interactions. Additionally, user-specific access and automatic updates reinforce the human-centric approach, ensuring that tire data ecosystem is both robust and adaptable to individual needs.

[0381] Furthermore, Fyber is configured to address the challenges posed by Al -generated content, which is becoming increasingly sophisticated and widespread. As the distinction between human-generated and machine-generated content becomes more critical, Fyber's architecture, potentially utilizing smart contracts or analogous technologies for authentication, ensures that all Al-generated data on the platform remains reliably linked back to trusted digital artifacts from credible and traceable trusted sources. This functionality is crucial for maintaining the integrity of information and public trust, as Al technologies become more integrated into everyday digital interactions. By providing a secure environment where the lineage of digital content is transparent, regardless of its origin. Fyber establishes a framework for a more secure and trustworthy Internet.

[0382] Generating and / or Executing a Digital Thread over the IDMP / Fyber Platform

[0383] Fig. 14 is an exemplary system diagram showing a process for generating and executing a digital thread script extracting data from a trusted data source within an IDMP / Fyber platform, in accordance with some embodiments of the present invention. Specifically. Fig. 14 provides an exemplary schematic representation of the modules and data 1470 that may be used for the generation and / or execution of a digital thread script 1452 (e.g., a platform orchestration script) within an IDMP / Fyber platform application 1460, based on a received resource identifier 1406 from a user (not shown in Fig. 14), according to exemplary embodiments of the invention. A detailed description of Fyber-related terminology can be found in PCT application No. PCT / US25 / 30345 (Docket No. IST-05.001PCT).

[0384] The system may include access to at least one hardware processor 1494 responsible for executing program code 1492 to implement the modules 1470 described below. The system may include access to at least one non -transitor physical storage medium 1490, accessible by the at least one hardware processor 1494, which stores the program code 1492 that is executable by the hardware processor 1494. The program code may be stored and distributed among two or more non-transitory physical storage media, and may be executed by two or more processors.

[0385] Tire system may include a digital artificial storage environment 1426. The Fyber platform application 1460 and the digital artificial storage environment 1426 may both be connected to a training module (not shown in Fig. 14) that may carry out training, fine tuning, and / or validation of various machine learning (ML) subcomponents. In one embodiment, the Fyber platform application 1460 may include dedicated ML models for script-generation, script-updating, and / or resource representation (e.g., model splice) generation and / or updating. To train such models, the training module may use training data including sample digital threads, sample resource identifiers, sample data sources (e.g., model files), sample digital artifacts, and / or sample resource representations (e.g., model splices).

[0386] At run time, the user may provide a resource identifier 1406 pointing to a data source 1408 (e.g., a model file) as a trusted data source (“Trusted Data Source A7’), as shown by the dotted line in Fig. 14. The user may provide the resource identifier 1406 through a user interface (UI) (not shown in Fig. 14). In one embodiment, the user may provide the trusted data source 1408 directly.

[0387] Tire trusted data source 1408 may be located in a first security environment 1410 that is external to the Fyber platform.

[0388] The Fyber platfonn application 1460 may then extract resource data 1420 (e.g., model data) from the trusted data source 1408 to generate a digital artifact 1422 that is based on the resource data 1420. The artifact metadata (not shown) may include the resource identifier 1406. Therefore, the digital artifact 1422 may point to the trusted data source 1408, as shown by the dashed lines in Fig. 14. The Fyber platform application 1460 may then store the digital artifact 1422 in a digital artifact storage environment 1426 accessible by the Fyber platfonn.

[0389] The Fyber platform application 1460 may then generate a function script 1430 that enables external access to the digital artifact 1422 through addressable Application Programming Interface (API) 1432 (or Software Development Kit (SDK)) endpoints, as shown by the double-dashed line in Fig. 14. The addressable API 1432 endpoints may enable access to the digital artifact 1422 without access to the entire trusted data source 1408.

[0390] The Fyber platfonn application 1460 may then generate a resource representation (“Source A Rep.”) 1434 of the trusted data source 1408 that is accessible to third-party applications and users via the addressable API 1432 (or SDK) endpoints. The resource representation 1434 (e.g.. model splice) may include the function script 1430 and may enable access to a selective portion of the digital artifact 1422.

[0391] The Fyber platform application 1460 may then generate a trusted data envelope 1440 enabling zero-trust (and optionally zero-knowledge) access to the digital artifact 1422 from a second security environment 1450 that is distinct from the first security environment 1410 of the trusted data source 1408. Access to the selective portion of the digital artifact 1422 may require the verification of the trusted data envelope 1440 by the Fyber platform application 1460, as illustrated by a white arrow linking the access command in the digital thread script 1452 with the TDE 1440 in Fig. 14. Furthermore, tire “data hash” field of the TDE 1440 may be based on the resource data 1420 extracted from the trusted data source 1408, as illustrated by a white arrow linking resource data 1420 with the TDE 1440 in Fig. 14.

[0392] The Fyber platfonn application 1460 may then generate a digital thread script 1452 that generates a live digital resource 1454 (e.g., a live document) in the second security environment 1450. The generated live digital resource 1454 may be configured to access the digital artifact 1422 by invoking the resource representation 1434 using the API 1432 (or SDK) endpoints. This is illustrated in Fig. 14 by a white arrow linking a “display” script line in tire digital thread script 1452 and artifact data displayed in the live digital resource 1454.

[0393] Finally, the Fyber platfonn application 1460 may execute the digital thread script 1452 on the Fyber platform to generate the live digital resource 1454, where a notification of a modification of the trusted data source 1408 may appear in the live digital resource 1454 within a predetermined delay.

[0394] In Fig. 14, the locks displayed over artifact data in both the digital artifact 1424 and the live digital resource 1454, and the corresponding key displayed over the trusted data envelope 1440, indicate that access to the digital artifact 1422 may require a verification of the trusted data envelope 1440. In some embodiments, the resource data 1420 may be linked to an associated trusted data envelope 1440. as indicated by the white arrow between the resource data 1420 and the trusted data envelope 1440. This link indicates that access to the resource data 1420, to the digital artifact 1422 extracted from the resource data 1420, or to the live digital resource 1454 linking to the digital artifact 1422 and / or the resource data 1420, all may require a verification of the trusted data envelope 1440.

[0395] Discontinuous Access to the IDMP / Fyber Platforms

[0396] In some embodiments, customers may face situations where they may lose access to the Integrated Digital Model Platform (IDMP) and the system would benefit from offline access solutions to maintain data synchronization and provenance, or to invalidate data caches when a user is no longer authorized. Client-side caching and cache management is a well-known approach in distributed systems for handling the problems faced across some cases. However, implementing a zero-trust and zero-knowledge approach to traditional client-side caching presents several challenges. For zero-trust, all cache interactions must be client-initiated since the server cannot directly push data changes, or trigger cache invalidations, complicating real-time data consistency. Additionally, ensuring that client sessions arc ephemeral and securely managed is critical, as cached data must become inaccessible once sessions expire or are revoked, without any direct server intervention. Adherence to zero-knowledge constraints severely limit the server’s ability to manage cache states or access sensitive data, complicating traditional cache invalidation techniques. Despite these stringent zero-trust and zero-knowledge security requirements, the implementation must still offer a seamless user experience, ensuring that tire security measures do not disrupt the user's nonnal workflow.

[0397] Case 1: Offline Access with Optional Cloud Storage

[0398] In a first case, consider offline access with optional cloud storage, where users working with local models on the IDMP risk losing their work if their computer loses power. There may be no specific cloud storage for some models, which may result in data loss mid-session. An alternative solution is needed to safeguard user progress. Tire primary challenges involve ensuring real-time data backup to prevent loss during local machine failures while minimizing perfonnance impact. Efficiently capturing only relevant data and synchronizing it with cloud storage without interrupting the user’s workflow is critical. Additionally, the system must handle secure storage and deletion of cached data to comply with privacy regulations. Implementing robust data versioning and conflict resolution mechanisms is necessary to maintain data integrity between local and cloud versions, and providing user control over data backup and purge operations is essential for flexibility and user satisfaction. In summary, the challenges are: real-time data backup to prevent data loss, efficient data capture and minimal performance impact, secure storage and deletion of expired cached data, versioning and conflict resolution between local and cloud data, and user control over data backup and purge operations.

[0399] An overview of a solution and technical implementation for the first case is as follows. First, the system designer implements a real-time data caching mechanism to continuously back up user data to commercial-off-the-shelf (COTS) cloud storage during active sessions. This provides a safety net, ensuring progress is not lost due to local machine failures. Users must accept and acknowledge data caching, and the system must manage regular cache clearing to prevent excessive storage costs. Then, the system designer creates a duplicate cache involving capturing relevant data changes and storing them in a temporary local cache. This ensures that any modifications made by the user are immediately recorded. Concurrently, using a COTS cloud storage API, these data changes are uploaded to cloud storage in real-time, providing an additional layer of security. At the end of the session, users are provided with UI options to either expunge or archive their data. Implementing versioning mechanisms allows users to manage historical data efficiently, enabling them to revert to previous versions if necessary.

[0400] Case 2: Offline-First Application

[0401] In a second case, consider an offline-first application, where users working in environments with intennittent or no connectivity (e.g., edge or air-gapped environments) face disruptions in their work, risking data integrity and productivity. A solution is needed to maintain data usability and integrity during offline periods. The key challenges are to maintain data availability and functionality in offline environments, ensuring that users can continue their work seamlessly even without connectivity. Developing a robust synchronization mechanism that updates local data with remote storage when connectivity is restored is crucial for data integrity. The system must also support smooth transitions between online and offline modes, optimize performance to ensure a responsive user experience offline, and maintain data security during offline storage and transmission. Additionally, it must resolve potential data conflicts between local and remote versions to ensure consistency and reliability. In summary, the challenges are: ensure data availability and functionality offline, develop robust data synchronization when connectivity is restored, seamless transition between online and offline modes, optimize offline perfonnance and maintain data security, and resolve potential data conflicts between local and remote versions.

[0402] An overview of a solution and technical implementation for the second case is as follows. First, the system designer implements offline-first principles in the client application to allow users to work offline with local data caching. Then, the system designer synchronizes cached data with remote storage when connectivity is restored, ensuring data integrity and seamless user experience.

[0403] Case 3: Cache Invalidation

[0404] Finally, in a third case, consider cache invalidation. In the context of a zero-trust and zero-knowledge environment, ensuring that cached data on client devices remains valid and secure is a critical challenge. When circumstances change — such as when a user is revoked access, a device is lost, or data is updated — the cached data must be invalidated to prevent unauthorized access to potentially sensitive information. Conventional cache invalidation methods, which often rely on server-side commands to delete or invalidate cache data, are not viable in a zero-trust architecture where the server cannot unilaterally initiate communication with the client. Therefore, we need a robust mechanism that allows for secure, client-initiated cache invalidation to uphold the security and integrity of the data. Cache invalidation is inherently challenging because it requires accurately determining when and what data has become outdated to ensure consistency and reliability of information. Uris process becomes even more complex in a distributed environment where numerous clients and servers interact. Implementing this in a zero-trust and zero-knowledge architecture compounds the difficulties. In such systems, the server cannot directly access or modify client caches due to strict privacy and security policies, thus eliminating traditional cache invalidation methods that rely on server signals. Furthermore, maintaining the principle of zcro-knowlcdgc means the server holds no sensitive information that could inform dynamic cache management decisions, leaving clients to manage cache invalidation independently. This places a significant burden on client-side logic and security measures, requiring sophisticated mechanisms to ensure data integrity and confidentiality without any direct intervention from the server.

[0405] An overview of a solution and technical implementation for the third case is as follows. The solution implements cryptographic techniques, notably Elliptic Curve Diffie-Hellman (ECDH), to securely exchange keys and manage client-side cached data. Tire ECDH mechanism creates a shared secret between the client and enclave during user authentication. This secret is used to encrypt cached data, ensuring its security throughout the session. To maintain data integrity, sessions are managed with strict timeouts and a re-authentication process, rendering the cached data inaccessible and effectively invalidated once the shared secret expires or is revoked.

[0406] Hrus, a unified solution to discontinuous (e.g., offline) access requires caching, data synchronization, and conflict resolution. Tire IDMP must perform three main actions whether it be for real-time caching of data (as in Case 1), or for offline access to platform applications (as in Case 2), as described below. Caching is a technique used to temporarily store frequently accessed data in a high-speed storage area to enhance data retrieval speed and overall system performance. Caching can be implemented using various options, including in-memory caches, which store data in RAM for the fastest access; local storage caches, which utilize local disks or SSDs; and remote storage caches, which leverage networked storage systems or distributed caches. Techniques for maintaining data consistency and efficiency in caching include write -through, where updates are made simultaneously to the cache and main memory; and write-back, where updates are first made to the cache and later written to main memory; Additionally, cache replacement policies such as Least Recently Used (LRU) and First In, First Out (FIFO) are employed to manage data eviction when tire cache is full. Data synchronization in caching ensures that the cached data remains consistent with the main memory or tire data source. This involves updating the cache whenever changes occur in the main memory. Techniques include write-through caching, where every change is written to both the cache and main memory' simultaneously, and write-back caching, where changes are first written to the cache and then periodically updated in the main memory; Effective synchronization is crucial for maintaining data integrity and consistency across different storage layers. For edge instances of the IDMP with offline access or sporadic network connectivity, synchronization can be handled by local caches storing updates and syncing with the central data source once connectivity is re-established, ensuring that data remains consistent across the system. Conflict resolution in caching deals with handling simultaneous read and write operations on the same data by multiple processes or nodes. This is important in distributed systems where data might be cached in multiple locations. Techniques include versioning, which tracks changes using version numbers, and consensus algorithms like Paxos or Raft, which ensure agreement on the data state among nodes. Conflict detection methods, such as timestamps, help identify and resolve inconsistencies by merging changes or prioritizing the latest updates. Effective conflict resolution is essential for maintaining data consistency and reliability in caching systems. For edge systems, this might involve local conflict resolution strategies that merge changes made offline with the central data source once network connectivity is restored, ensuring data integrity across all nodes.

[0407] Discontinuous Access in a Zero-Trust and Zero-Knowledge Environment

[0408] In an Integrated Digital Model Platform (IDMP), managing data operations without directly accessing the data presents several challenges for data synchronization and conflict resolution. The platform enclave’s (control plane's) Jobs service, comprising the orchestration engine, token management system, and the logging service, must coordinate precisely with the data plane’s agents to maintain data consistency and manage access during offline or low-latency connectivity. For enabling discontinuous access to the platform, the enclave must coordinate data operations across multiple data planes - at the minimum a customer client data plane, that hosts in-memory cache and local caches, and a customer cloud data plane, that hosts cloud backups. In exemplary implementations when the IDMP manages multi-tenancy, coordinating data operations across multiple tenants, there can be multiple customer client data planes and multiple customer cloud data planes. The customer client data plane includes the client UI to receive user input, various storage options such as in-memory cache, and local cache (e.g., browser cache. RAM, or temporary local storage), managed by a data caching agent that includes a storage processor, storage provider, and storage listener, and a synchronization agent which updates from the control plane to the local data store and includes a Merge Handler to resolve inconsistencies using predefined rules or with user input. Additionally, the data caching agent can also link with tire cloud storage backups in a customer cloud data plane. These components utilize an authorized user input to determine where to store data, which data store to access, and alert to conflicts in data storage or versions. Ensuring synchronized data across these storage options is complex due to potential latency, network disconnect and other situations that lead to discontinuous access (e.g., a user is no longer authorized to access tire platform). The storage listener’s version control system must effectively track data versions to detect and manage conflicts. These components must work together to handle the scalability of multiple enclaves and exclaves, ensuring robust synchronization and conflict resolution even with sporadic network connectivity, while maintaining data integrity and performance.

[0409] Implementing discontinuous access with client-side caching within a zero-trust and zero-knowledge framework presents significant challenges that stem from the stringent security requirements inherent to these paradigms. The primary difficulty lies in maintaining data confidentiality and integrity while ensuring rapid, offline access for clients. In a zero-trust environment, all actions must be initiated by the client (e.g.. user actions through tire UI), which complicates conventional caching strategies that often rely on server push mechanisms for updates and invalidations. Moreover, zero-knowledge principles necessitate tokenization and encryption of data, ensuring that the server does not retain or handle sensitive information directly. This requires sophisticated key management and secure, ephemeral session handling to prevent unauthorized access. Additionally, enforcing cache invalidation without direct server intervention demands advanced cryptographic techniques like elliptic curve Diffie-Hellman (ECDH) to ensure that cached data becomes useless if a client's access is revoked. Balancing the need for seamless user experience with these stringent security measures creates a complex landscape, where effective solutions must be both secure and efficient in managing client-side data caches.

[0410] Fig. 15 shows a system architecture for implementing and managing discontinuous access to the IDMP with client-side data caching, in accordance with some embodiments of tire present invention.

[0411] The IDMP enclave 1502 is the platform’s control plane and performs the data orchestration steps for data caching and managing offline access, without accessing the actual data. The IDMP enclave 1502 includes all the elements indicated within the enclave 302 (see Fig. 3). For implementing the offline access in particular, as shown in Fig. 15, the IDMP enclave 1502 includes the jobs service 1510 and tire logging service cell 1512. The jobs service 1510 manages and coordinates operations across the data plane, ensuring that commands are accurately dispatched and tracked. Such tasks may further require a token management system that manages metadata for data states, session tokens and version history, thus supporting synchronization, conflict resolution and cache-invalidation workflows carried out by the jobs service 1510. The logging service cell 1512 is for monitoring the changes and events in the data plane, logging operations to provide an auditable basis for conflict detection, resolution, provenance and regulatory reporting.

[0412] The customer cloud data plane 1504 includes a customer cloud data storage 1520 and a cloud-based digital tool agent 1570. In various embodiments, the cloud-based digital tool agent 1570 is operated by an IDMP exclave 1572. Tire customer cloud data storage 1520 comprises options for cloud storage and cloud backups to hold the actual data. The cloud-based digital tool agent 1570 provides splicers with functions to operate on the data.

[0413] Customer client data plane 1506 includes a customer local data storage 1528, a data caching agent 1530, a synchronization agent 1550, and a user interface 1580. In various embodiments, the synchronization agent 1550 is operated by an IDMP exclave 1552. The customer local data storage 1528 comprises options for client-side caches such as in-memory storage 1522 (e.g., on client browser, RAM) or local cache storage 1524. In various implementations of the IDMP, only the pointers to the data within digital models are cached within the customer local data storage 1528, and not the actual data artifacts themselves. In various embodiments, the data payload within digital models or data artifacts are deemed sensitive and are thus never cached. However, pointers may be, thus allowing access for authorized users. In various embodiments, a pointer-only strategy enforces zero-trust access by preventing local exfiltration of raw data. This approach ensures the zero-trust security for the digital models, so that only authorized users are able to interact and perfonn tasks on digital models, ensuring no alternative access methods to the local cache compromise the security of trusted source data or artifacts. The data caching agent 1530 includes a storage processor 1532, a storage provider 1540, a storage listener agent 1560 and a storage allocator agent 1534.

[0414] In various embodiments, data approved for offline access by the data owner is stored in a secure container managed by the data caching agent (1530). Access to the cached data is restricted to the authorized client, with optional limitations on how long the data can be accessed or how many times it can be retrieved. The data cannot be accessed directly from local storage; instead, it must be retrieved through the authorized client using a secure access protocol. The storage processor 1532 manages the data store and handles the storage and retrieval of data. The storage provider 1540 assigns specific actions to the appropriate data store, ensuring efficient data management. Tire storage listener 1560 includes a version control system (agent) to manage the versioning of data within the data stores. The storage action agent 1534 instructs the storage processor to allocate or remove data storage options in the cloud data store 1520 or local data store 1528. In some implementations the caching agent 1530 comprises a secure storage 1590, managed by a secure data storage manager 1540 that holds only data explicitly approved for offline use, governed by enclave-issued tokens that limit duration and frequency of access. This secure data store is either integrated within the data caching agent or is securely connected to it, with no alternative methods for bypassing access controls. Data approved for offline use by the data owner is stored securely and is accessible exclusively through the IDMP platfonn, orchestrated in the enclave and linked with agents. This access is subject to strict conditions, including limitations on the duration and frequency of access to ensure security. Notably, the data cannot be accessed simply by using administrator access to open a cache store or a folder on an individual's laptop. The synchronization agent 1550 receives instructions from tire control plane's Jobs service, and applies updates and changes to ensure data consistency in the local data store, lire synchronization agent 1550 may also include a merge handler, which applies rules from tire control plane to resolve inconsistencies, ensuring that conflicts are efficiently managed and data integrity is maintained. Finally, the user interface (Ul) 1580 provides an interface for users to interact with the system, including enabling data caching, monitoring connectivity status, and controlling data backup or purge actions. Alternative interaction tools may include a command -line interface (CLI) 1582 and / or a software development kit (SDK) 1584. The cases outlined above may be implemented with additional elements. For case 1 (offline access with optional cloud storage using real-time synchronization), the cloud data storage 1520 may include Backup Cloud Storage 1526, which is dedicated to real-time backup purposes. This ensures that user data is continuously synced to the cloud, preventing data loss during sessions. The Sync Engine agent 1550 is responsible for real-time synchronization, continuously syncing local Cache Storage 1524 with Cloud Storage 1526 to provide a safety net against local machine failures. For case 2 (offline-first application access), the primary focus is on local caching using local data storage 1528, with optional cloud data storage 1520, and synchronization upon connectivity restoration. The Sync Engine agent 1550 performs deferred synchronization, synchronizing local data with remote storage once connectivity is restored. This ensures that data integrity is maintained and conflicts are resolved. In particular, case 3 (cache invalidation), along with the other cases, relies on the token-management system described above, which stores tokenised state in a trusted data storage (e.g.. a secure cloud storage bucket) so that customers 306 (or client UIs 1580) access data through enclave-issued tokens under zero-trust, zero-knowledge constraints. In other implementations, there may be additional customer network data planes on a customer’s local network, with associated customer data storages. In yet other implementations, enterprises may deploy additional customer-network data planes inside private networks, each with its own storage pools. Token-centric orchestration ensures all such planes remain compliant with the same zero-trust, zero-knowledge principles. Examples can be seen when a user uses their work desktop computer (customer client data plane), to access digital models on their company network (customer network data plane), and additionally on their company’s cloud network (customer cloud network data plane), and further to other cloud networks where they have dedicated secure password-based or token-based access. In exemplary embodiments, a user may use tire UI 1580 and the SDK 1584, for managing case 1, for the selection of the cloud storage for synchronization. In other embodiments, a user may use the CLI 1582 and the SDK 1584 for managing case 2 owing to various repeated steps for resolving offline nodes, In various embodiments of the IDMP, the cache invalidation steps are automatically performed by the platform using the SDK 1584.

[0415] Implementing cache invalidation using cryptographically shared secrets leverages several key system elements to ensure security and efficiency. In one embodiment, at the core, the Elliptic Curve Diffie -Hellman (ECDH) protocol may be used to establish a shared secret between the client and tire enclave during authentication. This shared secret is crucial for the data cncryption / dccryption mechanism, ensuring that all cached data remains protected. In many embodiments, the client-side synchronization agent periodically validates session status and initiates cache invalidation whenever the secret expires or access is revoked. To maintain data integrity, timestamps and validation tokens arc associated with the cached data, verifying its freshness and validity. When the session expires or access is revoked, the cache invalidation logic ensures that the shared secret is invalidated, rendering the cached data inaccessible.

[0416] In various implementations, examples of different types of cross-plane interactions are presented.

[0417] • For case 1 (Offline Access with Optional Cloud Storage using real-time synchronization, a real-time “cloud-in-a-box” example), the synchronization agent 1550 continuously mirrors cache storage 1524 to cloud backup 1526, providing fault tolerance for edge hardware failures.

[0418] • For case 2 (offline-first application), the synchronization agent 1550 perfonns deferred reconciliation, pushing accumulated changes to the cloud only after connectivity is restored.

[0419] • For case 3 (cache invalidation), the token management system issues per-session secrets (via Elliptic-Curve Diffie-Hellman) that encrypt cached data. Expiry, revocation or time-based rules cause the sync engine to invalidate the cache once the shared secret is retired.

[0420] In various implementations, we present examples of different types of multi-plane extensions: An enterprise may operate additional customer network data planes inside a private network, each with its own data storage units. The token-based orchestration ensures that every plane, cache and replica upholds zero-trust, zero-knowledge principles while remaining subject to the same audit trail in the enclave.

[0421] The logging service cell 1512 maintains a single audit trail, allowing regulators or administrators to trace every cache event and carry out conflict resolution or invalidation across planes.

[0422] For each of the envisaged cases introduced above, exemplary sequences of steps are listed below, followed by an exemplary event flowchart description.

[0423] Case 1: Offline Access with Optional Cloud Storage using real-time synchronization

[0424] 1. User logs into the platform and enables data caching via the UI.

[0425] 2. User works with local model files.

[0426] 3. Jobs Service captures data changes (for example, using Webhooks) and sends them to the Data Caching Processor (e.g., data caching agent 1530).

[0427] 4. Storage Processor updates Cache Storage and In-Memory Storage.

[0428] 5. Storage Provider checks network status and decides on the storage mechanism (cache or in-memory).

[0429] 6. Sync Engine continuously syncs Cache Storage with cloud storage (e.g., cloud backup 1526) in real-time.

[0430] 7. Storage Listener triggers data sync (e.g., syn engine agent 1550) when changes are detected.

[0431] 8. UI allows the user to purge or archive data at the end of the session.

[0432] 9. Sync Engine handles API calls with cloud storage for data backups. In various embodiments of the IDMP, a self-contained edge node 1506 — configured as a ‘'cloud-in-a-box” — is deployed in a disconnected environment and initialized with a cryptographically signed model snapshot and seed keys obtained from an authoritative source of truth (ASOT), or trusted source, where the ASOT resides within the system’s data storage layer (for example, in customer-cloud storage 1504, customer-client storage 1506, or secure storage 1590, depending on deployment). Tire enclave 1502 transmits a signed model state of the ASOT and root key that the edge instance uses to seed a local trusted signature chain maintained by the data-caching agent 1530, as discussed below. In alternate embodiments, the signed payload is enclosed within a trusted-data envelope for an additional integrity check, or is accepted only if a time-based-access policy confirms the root key is still within its validity window. While offline, each machine-generated event is reduced to a pointer or cryptographic hash, signed, and appended to tire immutable log stored inside the caching agent 1530 (which encompasses the local signature chain). In an alternate embodiment, each event record itself is wrapped in a trusted-data envelope prior to signing. Upon restoration of connectivity, the edge securely transmits its accumulated chain segment to the IDMP exclave with the ASOT via the sync-engine agent 1550 and requests any upstream deltas (i.e. any changes to the ASOT data storage since last disconnect). The IDMP enclave uses the keys of the ASOT and verifies every signature, applies any outstanding time-based-access constraints, merges the edge segment into the global signature chain (which may be persisted in secure storage 1590), and returns authoritative updates to the edge node. The edge then refreshes its local state and resumes operation from a consistent, non-repudiable baseline.

[0433] Exemplary Flowchart for Case 1

[0434] Offline Access with Optional Cloud Storage using real-time synchronization, or Cloud-in-a-box edge instance with real-time synchronisation, may include the following steps:

[0435] 1. User-initiated caching session: The operator selects a data-caching mode via the user interface 1580 (or CUI 1582), that further invokes the SDK 1584, whereupon the jobs service 1510 issues a session token and initial orchestration commands to the edge instance.

[0436] 2. Edge instance bootstrap and trust anchoring: The edge node 1506 is provisioned with an encrypted model snapshot (e.g., hash of data component of digital artifact) and seed keys signed by the IDMP enclave 1502. The sync -engine agent 1550 stores the signed state and root key, thereby establishing the first block of a local trusted signature chain in the data caching agent 1530. (See similar features in PCT application No. PCT / US25 / 30345, Docket No. IST-05.001PCT.) In an alternate embodiment, the signed snapshot is enclosed within a trusted-data envelope affording an additional integrity-verification layer. In another embodiment, the edge verifies that the supplied root key remains within a prescribed time-based-access validity window before accepting the anchor. Pointer-only event capture and local chain extension: As the IDMP executes the data operations, each data event is reduced to a pointer or cryptographic hash. Tire storage processor 1532 writes the pointer to in-memory cache 1522 or cache storage 1524 and appends a locally signed record to the signature chain in 1530. In an alternate embodiment, each event record is itself sealed in a trusted-data envelope prior to signing. Adaptive storage selection: The storage provider 1540 dynamically selects among the in-memory cache 1522, the persistent cache 1524, or the secure storage 1590, according to current network connectivity and the scope of the governing session token. Continuous mirroring to cloud backup: During periods of connectivity, the sync -engine 1550 streams newly created chain entries to backup cloud storage 1526 and forwards transaction metadata to the jobs service 1510. The logging service cell 1512 contemporaneously records each mirrored event for audit purposes. Offline queueing of signed transactions: Upon loss of connectivity, the sync -engine 1550 queues subsequent signed (and, where used, TDE-enveloped) transactions locally, while the edge-resident logging service stamps each queued record with a monotonic timestamp for later reconciliation. Reconnection handshake and queued-data submission: When connectivity is re-established, the sync-engine 1550 negotiates a mutually authenticated TLS session with the enclave 1502, submits its queued chain segment, and requests any upstream model deltas (i.e., data changes from previously disconnected different data planes or data stores). Enclave verification and global chain merge: The IDMP enclave 1502 validates each submitted signature, applies any outstanding time-based-access constraints, merges the edge segment into the authoritative trusted signature chain (in 1530), and logs the merge event in the logging service cell 1512. Edge state refresh and resumption: Tire sync-engine 1550 receives the authoritative delta (i.e., data changes in a trusted / authoritative source during a disconnected phase), instructs tire storage processor 1532 to reconcile the caches 1522 and 1524, purges processed queue entries, and returns the edge node to normal operation (i.e., connected operation). Session termination and cache purge: At the conclusion of the session, the operator may invoke a purge or archival command via the user interface 1580. The storage allocator 1534 removes or relocates the cached pointers, and the logging service cell 1512 records the purge to preserve an auditable record of data disposition. Case 2: Offline-First ADD

[0437] 1. User opts-in for offline access (if required) via the UI.

[0438] 2. User works offline with a local cache.

[0439] 3. Jobs Service captures data changes (for example, using Webhooks) and sends them to the Data Caching Processor.

[0440] 4. Storage Processor updates Cache Storage and In-Memory Storage.

[0441] 5. Storage Provider monitors network status and provides either cache or in-memory storage.

[0442] 6. Sync Engine detects network connectivity restoration and synchronizes local cache with remote storage.

[0443] 7. Storage Listener triggers data sync when changes are detected or when connectivity is restored.

[0444] 8. UI shows connectivity status and allows users to work offline seamlessly.

[0445] 9. Sync Engine handles API calls to interface with remote storage for synchronization.

[0446] In this embodiment tire IDMP enables offline-first collaboration among multiple computer workstation-like edge clients (each a customer-client data plane 1506). Each client receives a cryptographically signed snapshot of the shared digital model together with a root key issued by an authoritative source of truth (ASOT) that resides in the system's storage tier (1504 / 1506 / 1590, depending on deployment). The snapshot seeds a bidirectional signature chain held inside the local data-caching agent 1530, while the jobs service 1510 primes a vector clock so edits from different clients can be globally ordered. During disconnected operation, users edit the model: every change is reduced to a pointer or hash, signed, and appended to tire client’s local chain. On reconnection, each sync-engine 1550 submits its signed change set (bearing vector-clock timestamps) to the jobs service. The platform detects collisions by analysing chain ancestry and vector-clock order, resolves conflicts by a policy-controlled merge routine as discussed above (e.g., last-writer-wins, domain-specific merge, or manual review), verifies all signatures, and merges the reconciled result into the authoritative trusted signature chain. The reconciled result of a trusted data source is used as the authoritative trusted data source, and its accompanying signature chain is used as the authoritative trusted signature chain. The reconciled delta is then disseminated to all clients, ensuring that every workstation resumes from a single, verifiably consistent state. Optional trusted-data envelopes and time-based-access checks can be applied at any stage without altering the core flow.

[0447] Exemplary' Flowchart for Case 2

[0448] Offline-first application with deferred synchronisation may include the following steps: User enrollment for offline mode: Through the CLI 1582, that further invokes the SDK 1582, a collaborator enables offline access. The jobs service 1510 issues a session token, a vector-clock seed, and startup instructions to that client device. Edge-client bootstrap and cache initialisation: Each collaborating workstation (e.g., multiple instances of the customer client data plane 1506, also called edge instances...) receives a cryptographically signed model snapshot and root key from the ASOT-backed storage layer (1504 / 1506 / 1590). The sync-engine 1550 stores these values in the local data-caching agent 1530, thereby creating an initial bidirectional signature chain and recording the current vector-clock value. In an alternate embodiment, the snapshot is wrapped in a trusted-data envelope. Note that bidirectionality here is meant in a cryptographic sense: since the signature chain is encrypted with a shared secret key, both enclave and exclave may decrypt the chain to access underlying data. In another embodiment, the root key is accepted only if a time-based-access rule confirms its validity window. Offline editing and local chain growth: While disconnected, each user modifies digital models (e.g., through modifying associated digital artifacts). The storage processor 1532 writes pointers or hashes for every change to in-memory cache 1522 or cache storage 1524 and appends a locally signed entry to the user’s chain in 1530. In an alternate embodiment, each change record is sealed in a trusted-data envelope prior to signing. Adaptive storage management: The storage provider 1540 monitors connectivity and token scope (e.g., see “revocation scope”), routing data between memory, cache storage, or secure storage 1590 as appropriate. Sync trigger on connectivity restoration: When a client detects renewed connectivity — either to the ASOT or to a peer — the sync -engine 1550 sends its signed change set, including vector-clock timestamps, to tire jobs service 1510 for reconciliation and requests incoming deltas. Collision detection and ordering: The jobs service, working with the logging service cell 1512, compares incoming vector-clock values against the authoritative ledger and flags any divergent edits to the same artefact. Conflict resolution: If divergence exists, the IDMP platform applies a predefined merge strategy (for example, last-writer-wins, domain-specific merge rules, or manual review). In an alternate embodiment, time-based-access constraints govern which branch may prevail. Global chain merge and signature verification: The ASOT verifies every signature (and envelope, if present), merges the reconciled change set into the authoritative trusted signature chain 1530, and logs the event in 1512. 9. Update dissemination to collaborators: The jobs service returns the merged delta to all participating clients. Each sync-engine 1550 applies the update, reconciles its cache via the storage processor 1532 and resets its vector-clock baseline.

[0449] 10. Session continuity and audit: Users continue offline work as needed. Tire logging service cell maintains a complete, auditable history of edits, conflicts, and resolutions. At any point in the process, the UI 1580 may display connectivity status, allow manual synchronisation, or permit the user to purge cached pointers in accordance with token policy.

[0450] Case 3: Cache invalidation

[0451] Tire cache invalidation process, while meeting zero-trust and zero-knowledge security principles, may include creation of session-specific shared secret between enclave and client, encryption of client-cached data with such secrets, and periodic session management, including time-outs and refreshes, cache invalidation upon session expiry, and subsequent data deletion. One exemplary process may include the following events:

[0452] 1. Upon user authentication, the client and enclave execute an ECDH key exchange to generate a session-specific, ephemeral shared secret.

[0453] 2. All client-side cached data is encrypted using the shared secret, with each piece of data timestamped and appended with validation tokens to ensure its freshness and integrity.

[0454] 3. In exemplary implementations, sessions are set to expire every 15 minutes, requiring refreshment through continuous interaction with the server or re-authentication.

[0455] 4. If the session is not refreshed, or if access is revoked, the shared secret becomes invalidated.

[0456] 5. During new data requests, the enclave checks for ongoing session validity and tire integrity of the shared secret.

[0457] 6. If the session has expired, or access is revoked, the enclave denies further requests, signaling the client to recognize that the cached data must be invalidated.

[0458] 7. Without a valid shared secret, the encrypted data on the client side becomes unusable.

[0459] 8. Clients periodically attempt to refresh their session to verify the validity of their cached data.

[0460] 9. On detecting session expiration or revocation, the client automatically clears the cached data or marks the cached data as invalid.

[0461] This framework ensures that cache invalidation is securely managed on the client side, adhering to zero-trust and zero-knowledge principles, thus keeping the data secure and updated, and protecting against unauthorized access. In this embodiment, the IDMP provides collaborative forgetting by revoking cached or shared data on a strict time schedule (for example, a 15-minute revocation window), or in response to an explicit trigger such as a role change. When a user authenticates, the client device 1506 and the enclave-orchestrated jobs service 1510 perform an ECDH key exchange that yields a session-specific shared secret. All client-side cache entries (e.g., 1522. 1524) are encrypted with this secret and tagged with validation tokens and timestamps. The jobs service embeds an expiry value in the session token and monitors refresh requests. If the session lapses or a policy event demands deletion, the job service 1510 may trigger the data caching agent 1530 storing the Authoritative Source of Truth (ASOT) to sign an invalidation record, commit it to the immutable IDMP / Fyber signature chain, and broadcast an invalidation notice. Online clients immediately purge their encrypted cache. Offline clients receive the chain entry upon reconnection and delete the cache before further use. Because the shared secret is also invalidated, any residual encrypted ciphertext becomes unusable, thereby upholding zero-trust and zero-knowledge principles. Note that ‘'encrypted ciphertext” may, for example, refer to the hash of a digital artifact and the corresponding TDE / block (without valid SSK yet), as discussed below. All invalidation artifacts (e.g., session tokens, validation tokens, purge logs) are tenant-scoped, in the customer data plane, and the logging service cell 1512 keeps an auditable chronology of key exchanges, refreshes, invalidations and purges. Note that, the term “invalidation artefacts” denotes records associated with invalidated data, as described below. In various embodiments, the auditable chronology also comprises a secure, immutable signature chain.

[0462] Exemplary Flowchart for Case 3

[0463] Secure cache invalidation under zero-trust, zero-knowledge, may include the following steps:

[0464] 1. Session establishment and key agreement: Upon successful authentication by the platform through the SDK 1584, the client device 1506 performs an Elliptic-Curve Diffie-Hellman (ECDH) exchange with the enclave-orchestrated jobs service 1510. The exchange yields an ephemeral, session-specific shared secret. In an alternate embodiment, the key agreement employs a post-quantum algorithm or includes an additional trusted-data envelope for integrity attestation.

[0465] 2. Encryption of local cache: The storage processor 1532 encrypts all cache entries written to in-memory cache 1522 and / or cache storage 1524 using the shared secret. Each encrypted item is time-stamped and coupled with a validation token that binds the item to the current session context.

[0466] 3. Session-lifetime management: The jobs service 1510 embeds an expiry value (e.g., fifteen minutes) in the session token. Hie sync -engine 1550 must present a refresh request before the expiry elapses; otherwise, the shared secret is deemed invalid. In an alternate embodiment, the timeout interval is policy-driven or tier-specific.

[0467] 4. Validation on data request: For every new data operation, the enclave -resident validation logic checks the presented session token and verifies that the shared secret remains valid. If valid, the request proceeds; if invalid, the request is denied and the client is instructed to purge its cache.

[0468] 5. Secret invalidation events: A shared secret becomes invalid when (a) the session timeout elapses without a successful refresh, or (b) the control plane policy applied at the ASOT data storage using a corresponding exclave (ASOT-tied policy layer) revokes access (for example, upon role change or regulatory mandate). The jobs service 1510 logs the invalidation in the logging service cell 1512 and broadcasts an invalidation notice to the affected client 1506.

[0469] 6. Client-side cache purge: Upon receiving (or inferring from a failed refresh) an invalidation notice, the sync -engine 1550 instructs the storage allocator 1534 to erase or cryptographically shred all encrypted cache entries. Because the shared secret is no longer available, any residual ciphertext becomes computationally unusable.

[0470] 7. Audit trail completion: Tire logging service cell 1512 records the purge action, ensuring a verifiable chronology of authentication, key exchange, refreshes, invalidation triggers and data deletions. In an alternate embodiment, the purge event is also appended to a tenant-scoped (e.g., customer environment) section of secure storage 1590 to satisfy regulatory evidence requirements.

[0471] 8. Multi-tenant isolation: All invalidation artifacts (e.g., session tokens, validation tokens, purge logs) are tagged with a tenant identifier; thus, revoking one tenant’s cache access has no effect on any other tenant’s data plane or cache holdings.

[0472] These exemplary steps implement cache invalidation in strict adherence to zero-trust and zero-knowledge principles, guaranteeing that cached data becomes irrecoverable the moment a session lapses or is revoked, while maintaining a full, cryptographically auditable record of the lifecycle of each session and its associated data.

[0473] Crytographically Linked Signature Chains and Data Deconfliction

[0474] In one embodiment of the interconnected digital model platform (IDMP), an enclave-resident control plane coordinates synchronization, conflict detection, and reconciliation across at least two data planes. The first data plane may correspond to a client-managed edge exclave that maintains a local copy of a digital artifact, while the second data plane may operate in a cloud-based environment containing an independent version of the same artifact. Each data plane may maintain a cryptographically linked signature chain, including trusted data envelopes (TDEs), which are used to record authenticated updates to a versioned artifact.

[0475] Each TDE may include:

[0476] • a cry ptographic hash of tire data update (for data integrity of the data update record)

[0477] • a vector clock or hybrid logical clock (HLC), or a trusted timestamp issued by a time-stamp authority in the IDMP enclave (to resolve trusted time-based sequence of actions),

[0478] • an origin identifier and digital signature of the source digital model or artifact (for lineage), and

[0479] • optional coordination metadata such as trust weights or precedence indicators.

[0480] In various embodiments, cry ptographically linked signature chains, or “signature chains”, are thus maintained by the customer data plane and are used to detect and record data divergence events (e.g., authenticated updates to different versions of a digital artifact). In various embodiments, they are immutable, hash-linked chains of trusted data envelopes (TDEs). where each TDE may include a cryptographic hash of a data update (for data integrity of the data update record), a vector clock or hybrid logical clock (EILC), or a trusted timestamp issued by a time-stamp authority in the IDMP enclave (to resolve trusted time-based sequence of actions), an origin identifier and digital signature of the source digital model or artifact (for lineage), and optional coordination metadata such as trust or precedence indicators.

[0481] In the context of signature chains. TDEs may also be referred to as “TDE blocks”, or “blocks” herein. These TDEs may thus be appended sequentially to an immutable, hash-linked signature chain on each data plane. Upon detecting application-layer connectivity betyveen each of the tyvo data planes and the platform enclave, the enclave may receive the local and cloud signature chains and authenticate them by:

[0482] • verifying digital signatures for each TDE,

[0483] • validating hash linkage for chain integrity, and

[0484] • analyzing clock values to establish relative update ordering (as well as resolving potential time-drift against a time-stamp authority).

[0485] When mismatched data hashes, non-dominant vector clocks, or conflicting authorization metadata are detected across parallel chains, the platfonn enclave determines a data update event has occurred on one of tire data planes, but not correspondingly on the other (i.e., data divergence event, or “divergence event”). The jobs service within the platform enclave may then create a unique data divergence event record containing:

[0486] • references to the conflicting TDE blocks,

[0487] • source identity and timestamps, and

[0488] • hash values of the conflicting artifacts. This divergence event is immutably logged in a conflict resolution ledger (e.g., by the logging service) for downstream auditing, rollback, or replay. In some embodiments, the divergence event is further recorded in the individual signature chains within the respective data planes.

[0489] Data deconfliction methods

[0490] Upon detection of a data divergence event, the IDMP enclave may invoke a deconfliction manager service (by an agent in a IDMP exclave) to evaluate and apply a suitable policy for resolving the conflict. The manager examines embedded metadata in the conflicting TDEs — such as trust levels, source roles, vector clocks, and system configuration — and selects one of several supported coordination modes:

[0491] • Synchronous coordination: Both data planes are online. A quorum-based or consensus protocol is executed prior to accepting updates, ensuring consistency through preemptive agreement. This mode is well suited for high -integrity or safety-critical environments.

[0492] • Asynchronous coordination: Each data plane operates independently and reconciles updates only when reconnected to the platform enclave. The enclave resolves conflicts using metadata such as timestamps or trust scores, applying detenninistic strategies like last-writer-wins (LWW) or earliest-signed-wins (EWW).

[0493] • Federated coordination: Data planes are grouped into trust domains or tiers (e.g., edge, regional, global). Conflicts are resolved within the local tier first; unresolved cases are escalated to higher tiers based on scope and authority.

[0494] • Deferred or manual coordination: When automatic strategies fail — such as equal-precedence conflicts or semantically incompatible updates — the event is flagged for human or Al-assisted arbitration. This mode is critical for regulated or exception-driven domains.

[0495] The outcome of the data deconfliction method is the identification of the trusted data artifact that other conflicting data artifacts must conform to. Each deconfliction decision is recorded (by the logging service) along with its policy rationale and associated metadata, allowing deterministic replay and traceability across synchronization events. In some embodiments, the outcome of the data deconfliction method (i.e., the new trusted source for the particular artifact) is further recorded in the individual signature chains within the respective data planes.

[0496] Data Merging Methods

[0497] Once a deconfliction policy is selected, the IDMP enclave’s jobs service initiates a merge operation to resolve the conflict and produce a unified version of the artifact. All merge operations are implemented to be idempotent and deterministic, utilizing idempotent fungible tokens in the IDMP enclave and non-fungible idempotent tokens in each of the IDMP exclaves. Idempotent and deterministic updates mean:

[0498] • Tire same set of inputs always yields the same output; and

[0499] • Repeated or retry invocations do not alter committed state.

[0500] The IDMP may thus support multiple merge strategies, selected based on artifact type, policy rules, and coordination context, such as:

[0501] • Last-writer-wins (LWW): The artifact with the most recent trusted timestamp or dominant clock is retained.

[0502] • Earliest-signcd-wins (EWW): Tire artifact with the earliest valid signature and timestamp is selected.

[0503] • User-defined precedence: Declarative rules prioritize specific data sources or roles (e.g., controller > operator > simulation).

[0504] • Domain-specific deterministic merge: Schema-aware logic such as CRDTs, merge-patch (RFC 7396), or field-by-field table merges are used to reconcile complex data structures.

[0505] • Manual or Al-assistcd resolution: Unrcsolvablc conflicts arc escalated to external actors or machine learning agents for context-aware decision making.

[0506] Upon completion of the merge, the platform enclave generates a new TDE block that may contain:

[0507] • the reconciled data hash,

[0508] • the applied merge strategy and resolution metadata, and

[0509] • an enclave -issued timestamp and digital signature.

[0510] This block is appended to both tire local and cloud signature chains, and the successful merge outcome is immutably recorded in the conflict ledger (by tire logging service) with a reference to the originating divergence event. In some embodiments, the data merge event is further recorded in the individual signature chains within the respective data planes.

[0511] Idempotency and Detenninistic Replay

[0512] In various embodiments, the IDMP platform ensures that all deconfliction and merge processes are idempotent — identical operations do not repeat or mutate state — and deterministic — replay of the same TDE inputs always results in the same resolution. This property guarantees strong eventual consistency across all participating data planes and supports secure audit, rollback, and forensic validation. Once a divergence event is logged and resolved, additional attempts to resubmit the same TDE set have no effect on system state. Further, the deconfliction manager may access a policy registry that maps: a) artifact types, b) source roles, and c) coordination scopes to specific resolution policies and merge strategies. The registry is extensible and supports dynamic updates by administrators or system integrators without modifying the control plane codebase. Additionally, merge strategies may be implemented as modular plug-ins that can be declared in TDE metadata and loaded at runtime, enabling:

[0513] • support for domain-specific data types,

[0514] • integration with evolving coordination requirements, and

[0515] • backward-compatible enhancements to policy logic.

[0516] Such extensibility for discontinuous access and high-latency settings allows the IDMP platform to adapt to new operational contexts, customer workflows, and evolving security or governance requirements without sacrificing verifiability or convergence guarantees.

[0517] Tokens as an Offline Access and High Latency Enabler

[0518] Fig. 16 shows the use of tokenization for detection of changes in a zero-trust environment, according to one embodiment of the invention. Specifically, Fig. 16 is a diagram illustrating examples of fungible idempotent tokens (FIT) paired with one or more non-fungible idempotent tokens (NFIT). In some implementations, in 1601, the digital platfonn may create an FIT in the control plane and a corresponding NFIT in the data plane. In some implementations, in 1602, the digital platform may create an FIT in the control plane and one or more NFITs in the data plane. Each time the digital platform receives a request, the jobs service layer of the digital platform can create an FIT, create one or more corresponding NFITs, store the FIT and the one or more NFITs in memory, and track the usage of the idempotent tokens. Here, API requests that wrap a single function can create FITs and NFITs in pairs, which have a one-to-one connection. However, API requests that result in more than one function running on a digital tool can result in a single FIT and multiple NFITs. as shown in 1602. with a one-to-many connection.

[0519] In exemplary implementations of discontinuous access to the platfonn, the jobs service of the digital platform can implement token management as in 1601 to detect changes in customer data in the data plane without actually touching tire data. The FIT in 1601 indicates the task to be perfonned and the model type file, while the associated NFIT in 1601 has customer-sensitive details such as pointers to the digital model, the digital tool agent to use, and user authorization. The NFIT tokens in 1601 could be cached in trust buckets within the customer client data storage 1528. Once the task is performed, the NFIT reports back on status (e.g., success or incomplete) and thus the job service, through the FIT, is able to detect that a piece of data (c.g., a digital artifact) has changed in the customer client data plane. In other implementations, the jobs service can implement token management as in 1602 to assess data stores across different storages - whether in local data storage or cloud data storage. Each of the three different NFIT tokens in 1602 for a task on a digital model or digital artifact are cached in different places within a local data storage 1528, or a cloud storage 1526. The sync agent of the digital platform may thus assess the NFIT token details such as time stamps or the digital model versions, in order to assign the right source of truth. Hie control plane in Fig. 16 is similar to the IDMP enclave 302 while the data plane in Fig. 16 is similar to the Customer environment 310.

[0520] In other embodiments, such as Fig. 1, or Figs. 10 and 11 of PCT application No. PCT / US25 / 30345 (Docket No. IST-05.001PCT), the links between the splice plane and the model / data source plane include tokenized implementations with idempotent tokens (FIT / NFIT groups). More detail on the use of data tokenization as an IDMP access control measure can be found in Fig. 11A of U.S. non-provisional patent application No. 18 / 899,772 (Docket No. 54332-0074001).

[0521] Exemplary Embodiments of Collaborative Forgetting for Discontinuous Access

[0522] Exemplary embodiments of collaborative forgetting for discontinuous access provide a comprehensive framework by which the IDMP enclave and its associated exclave agents enforce secure, time-bound access to locally cached data. Details include:

[0523] • a flowchart description of discrete steps — from generating and distributing a per-artifact shared secret through revocation and cache invalidation — executed by the IDMP enclave’s Jobs Service and enforcement agents;

[0524] • a security rationale for extending session confidentiality to cached tokens;

[0525] • an overview of how tire shared secret is created, versioned, wrapped, refreshed, and zeroized;

[0526] • the technical advantages of this discontinuous-access approach; and

[0527] • example logical-clock options that underpin the timing and causal checks used throughout the flow.

[0528] Example Flowchart Description

[0529] Tire flowchart description represents one embodiment of a discontinuous-access method executed by an interconnected digital model platform (IDMP). Control logic runs in an enclave-resident Jobs Service, while enforcement agents execute in one or more IDMP exclaves.

[0530] 1. Generate time-bound shared secret key (SSK): The enclave’s Jobs service generates a shared secret key (SSK) specific to a digital artifact. The SSK is digitally signed, assigned atime-to-live (TTL) based on policy, embedded with a monotonic version_id, and optionally encrypted using a key-encryption key (KEK) retained within the enclave. This ensures ephemeral, traceable control over access. Transmit SSK and signed time beacon to agents: The enclave transmits the SSK, its TTL metadata, and a signed time beacon (authenticated enclave time ± allowable skew) to authorized exclave agents via a secure transport (e.g., TLS 1.3, mTLS, QUIC). In some alternate embodiments (Alternate A, referred to below), the SSK is published via a pub-sub channel gated by agent-specific authentication tokens. Bind SSK to artifact via trusted data envelope (TDE): The enclave appends a new trusted data envelope (TDE) block to the artifact’s signature chain. This TDE references the SSK by identifier and logs its issuance, serving as immutable provenance without exposing the key itself. Store SSK in secure vault (agent-side): Each agent decrypts the SSK (if KEK-wrapped) and stores it in a local secure container alongside the time beacon received from the enclave. This vault is isolated from other application contexts to prevent unauthorized access. Receive function-session request: A client UI (or CLI / SDK) sends a request to the agent to access a specific artifact. The request includes a pointer to the artifact, a local timestamp, access credentials, and optionally a declared operation type (e.g., read, transform, derive). Validate session (decision): Tire agent performs access checks in the following order:

[0531] • Verifies access permission for the requester.

[0532] • Confirms integrity of the artifact’s TDE chain and its signature.

[0533] • Confirms SSK presence and compares TTL, version_id, and enclave-issued timestamp. If valid, tire session proceeds and access is logged. If expired or missing, the agent blocks the session and raises an alert. Expired-key alert to enclave: If access is denied due to SSK expiration or absence, the agent generates a signed alert including the artifact hash, pointer, expired SSK version_id. and a cryptographic nonce. This alert is sent to the enclave to initiate revocation. Enclave issues forget instruction: Upon receiving an alert, the enclave issues a signed forget instruction. This directive includes the artifact’s hash, SSK identifier, revocation scope (e.g., artifact, keys, derivatives), a fresh nonce, and a TTL for execution. Send forget instruction to the agent: The forget instruction is securely delivered to each agent. In some alternate embodiments (Alternate A. referred to above), the instruction may also be published via pub-sub, secured with access control policies. Verify instruction and perform forgetting: Each agent verifies the enclave’s signature and the onc-timc nonce. If valid, the agent zeroizes the SSK, deletes cached instances of the artifact, and revokes all local file references. In some instances, the agent further flags all lower version ids as stale in its local vault upon SSK expiration. In some alternate embodiments (Alternate B). if derivative-cascade is enabled (i.e., a revocation scope option requiring a purge of linked artifacts), agents may traverse and revoke any artifacts cryptographically linked to the original source hash.

[0534] 11. Send forgetting receipt with idempotent token: Upon successful forgetting, each agent returns a signed receipt. Tire receipt includes pre- and post-forgetting hash digests and a non-fungible idempotency token (NFIT), ensuring the operation cannot be duplicated and may be audited.

[0535] 12. Quorum check (optional): The enclave collects agent receipts and, if a quorum threshold (Q) is met, marks the forget operation as complete. Agents that did not respond may be re-polled upon reestablishing connectivity.

[0536] 13. Ledger commit: A cryptographically notarized record of the forget instruction, agent responses, quorum status, and any derivative revocations is committed to the IDMP’s immutable ledger. This ledger supports full traceability and audit compliance.

[0537] 14. Periodic SSK refresh (timer event): Before TTL expiration, the enclave may proactively refresh the SSK. It generates a new SSK with an incremented version_id, signs and distributes it. Agents replace their stored SSKs atomically. In some alternate embodiments (Alternate C), in permissive settings, a grace period (A_grace) may allow limited use of the old SSK during refresh.

[0538] 15. End of process: The system loops back to session handling (Step 5) for new access requests using the latest valid SSK. The discontinuous access cycle continues until the next session expiration or policy-driven update.

[0539] Rationale for Shared-Secret Enforcement

[0540] In one embodiment, the IDMP enclave and each authorized exclave agent establish an Elliptic-Curve Diffie-Hellman (ECDH)-derived shared secret to extend the confidentiality guarantees of the network session to locally cached data tokens. TLS w ith AES-GCM protects the integrity of messages in transit, and SHA-based fingerprints preserve tire integrity of stored tokens. Those mechanisms alone do not prevent an attacker from extracting sensitive data once a session ends. By encrypting cache tokens under a per-session shared secret, revocation of the session key immediately renders cached data inaccessible. This cross-resource confidentiality enforcement supports a Multiple Independent Levels of Security (MILS) posture and achieves zero-trust, zero-knowledge guarantees, where the enclave does not retain access to decrypt cached content outside of an active session.

[0541] Unlike conventional cache-encryption schemes that rely solely on static keys or integrity-only mechanisms, this approach extends session-key confidentiality to cached tokens, thereby ensuring that cache contents become inaccessible upon session termination. Thus, the confidentiality guarantee is extended from one kind of resource in the system (the session between the UI / CLI / SDK and IDMP) to another kind of resource (tokens of data stored in a local cache), which traditionally serve different roles in distributed systems — namely, ensuring availability and sometimes integrity, but not typically confidentiality.

[0542] Ephemeral and time-bound shared secret key creation

[0543] In various embodiments, upon session initiation, the Jobs Service generates an ephemeral ECDH key pair within the enclave and securely transmits its public key to the client agent. In some embodiments, the ECDH parameters (such as the elliptic-curve type and key length) are fixed. In other embodiments, they are configurable by policy. For example, the policy may specify NIST P-256 for high-security deployments or Curve25519 for resource-constrained devices.

[0544] The client agent likewise generates an ECDH key pair and returns its public key. Both parties compute the shared secret key (SSK) via scalar multiplication of their private key with the other's public key. The enclave assigns a policy-driven time-to-live (TTL) and version identifier to the SSK, and may wrap the SSK under a long-term key-encryption key (KEK) held solely within the enclave.

[0545] To refresh the SSK before expiration, the enclave either performs a new ECDH exchange or encrypts a newly generated key under the existing SSK. In the latter case, the new key is symmetrically encrypted using the old SSK as an AES key, producing a wrapped-key blob that agents unwrap to obtain the fresh SSK. Upon TTL lapse or explicit session termination, both the enclave and the agent securely delete (zeroize) the SSK from memory and any transient storage, ensuring cached tokens can no longer be decrypted.

[0546] The assigned TTL is written into the TDE metadata and incorporated as an input to the key-derivation function (KDF). During each session-validation step, the agent compares the stored TTL against the enclave -signed time beacon, thereby invalidating the SSK when the TTL window has elapsed.

[0547] Technical Advantages of Shared-Secret Enforcement

[0548] This shared-secret enforcement mechanism prevents unauthorized post-session access to cached data without requiring complex cache scans or full data erasure routines. It provides cryptographic assurance that only actively authenticated sessions can decrypt and use cached tokens. It supports seamless key rotation and renewal — either by new ECDH exchanges or wrapped-key refresh — without disrupting ongoing workflows. It also enables efficient audit and rollback by coupling key lifecycle events with immutable, timestamped entries in the enclave’s ledger. The described mechanism provides a technical improvement to cache confidentiality enforcement in distributed systems by tying session lifecycle to local data access, thereby reducing attack surfaces without increasing computational overhead. Together, these advantages deliver robust, scalable confidentiality enforcement across distributed enclaves and exclaves in high-security, latency-tolerant environments.

[0549] Logical Clock Options

[0550] In various embodiments, the IDMP employs a logical clock to represent the temporal ordering of data events, function sessions, or synchronization actions in a distributed environment. Logical clocks may be used in place of, or in conjunction with, physical wall-clock time to enforce causal consistency, expiration, and replay protection. Suitable logical clock embodiments include, but are not limited to, the following:

[0551] 1. Vector clock: In one embodiment, tire interconnected digital model platfomi (IDMP) employs a vector clock to record the causal ordering of events. A vector clock comprises an array of counters, one counter per agent or node. Upon each local event, an agent increments its own counter. When two agents synchronize, each merges its vector by computing the element-wise maximum of its counter array and the received counter array. By examining the resulting arrays, the system can determine whether one event causally precedes another or whether updates occurred concurrently. Vector clocks thus enable partial ordering of distributed updates without reliance on physical time.

[0552] 2. Hybrid logical lock (HLC): In another embodiment, the platform employs a hybrid logical clock (HLC) that combines a physical timestamp with a logical counter. Each HLC timestamp includes (i) a physical time component sourced from a wall-clock or enclave-signed time beacon, and (ii) a logical counter. Upon generation of a new event, the HLC is updated to the greater of the local physical time or the last-recorded HLC physical component. If the physical components are equal, tire logical counter is incremented. For example, upon event occurrence, the HLC timestamp may be updated using the expression (max (physical_time , last_HLC_physical ) ; if tie then counter+1 ) , to preserve causality under clock skew. This mechanism preserves causality in the presence of clock skew while providing a real-time anchor for coordination and expiration checks.

[0553] 3. Trusted, time-stamped authority anchored time: In a further embodiment, the platfomi employs trusted time-stamp authority (TSA)-anchored time. The IDMP enclave acts as, or interfaces with, a TSA that issues cryptographically signed timestamps — termed time-beacon messages — to authorized agents. Agents calibrate their local clocks against these time beacons within an allowed skew tolerance and record the TSA-anchored timestamp in each trusted data envelope (TDE). TSA-anchored time provides a global reference for comparing event times, enforcing session time-to-live (TTL) rules, and preventing replay or premature expiration across loosely connected or offline agents.

[0554] Each logical clock value — whether vector clock, HLC, or TSA-anchored time — is recorded in the metadata of the trusted data envelope (TDE). The Jobs Service and data-plane agents consult these logical clock values during conflict detection, session validation, cache invalidation, and audit-log sequencing. In further embodiments, the system may support multiple clock types concurrently or dynamically select a clock embodiment based on deployment policy, artifact-specific coordination rules, or prevailing network connectivity conditions.

[0555] Further Exemplary Embodiments of Discontinuous Access

[0556] Fig. 17 shows yet another system architecture for implementing and managing discontinuous access to the IDMP, in accordance with some embodiments of the present invention. Specifically, Fig. 17 illustrates three distinct embodiments of discontinuous access capabilities between two logically independent instances of the Integrated Digital Model Platform (IDMP), designated as system A and system B. Each of A and B may represent separate customer data planes, such as a cloud instance (1704) or edge instance (1706), deployed independently yet maintaining logical or asynchronous connectivity to a shared IDMP control plane (1702). where core services such as the job processor ( 1710) and logging cell (1712) reside. Note that the methods and systems described herein may be applied in cases where there are two data stores (cloud vs. edge) within a single customer data plane (e.g., Fig. 15), or cases where there are two different customer data planes (e.g., Fig. 17), as described below.

[0557] The three cases differ in tenns of interface modality, direction of trust and data flow, and degree of automation, as detailed below:

[0558] Case I - UI + SDK (A B): Online-first caching with reconciliation ( 1724)

[0559] Signed and structured API calls are generated via the SDK, following human user input in the UI, and forwarded to the control plane enclave (1702) and the data store for system A (1730) and system B (1760). Updates from system A are propagated to system B (e.g., edge data plane 1706) via synchronization performed by the Sync Engine Agent (1740, 1770). In various embodiments, the Sync Engine Agents (1740, 1770) are operated by IDMP exclaves (1720. 1750) within their respective customer data planes (1704, 1706). If network connectivity is lost, updates are cached at the edge and resolved upon reestablishment of the A — > B link. The data flow is thus push-oriented, initiated by system A, with reconciliation downstream toward B using immutable records and signature validation. Case 2 - CLI + SDK (B A): Offline-first collaboration and conflict resolution (1754)

[0560] In this embodiment, technical users interact with system B through a command-line interface (CLI) (1782), backed by the SDK (1784). This pattern allows for disconnected operation where an edge node (1706) acts as the provisional source of truth. All actions are signed and logged locally. When synchronization resumes, the control plane and / or system A validate the lineage through signed vector clocks and execute deterministic conflict resolution via the merge handler in the Sync Engine Agent. This enables B A trust transfer and reconciliation, particularly useful in multi-agent or multi-edge-node environments (e.g., B1;B2, B3...), each operating autonomously before reconnection.

[0561] Case 3 - SDK Only (A A ,,,): Bidirectional, automated synchronization and invalidation (1714)

[0562] In this fully automated embodiment, machine agents on both systems A and B invoke the SDK directly without human interaction. In one embodiment, each data operation is encapsulated in a signed envelope that may include time-based access limits, policy metadata, or smart-contract predicates. The agents on A and B alternate execution in a bidirectional exchange (A — > B — > A — > B ...), processing updates, validating signatures, and handling cache invalidation triggers — such as wall-clock timers, on-chain events, or external job service inputs. This flow supports continuous, verifiable synchronization even across long periods of disconnection, leveraging vector clocks and immutable ledgers to preserve global consistency. Table 1 provides a summary of the various discontinuous access embodiments described above.

[0563] Table 1: Summary of Exemplary Discontinuous Access Embodiments Distinctions with Distributed Storage and Cloud Synchronization Solutions

[0564] The present invention introduces an approach for enabling secure, deterministic, and auditable discontinuous access between decentralized, and potentially disconnected, instances of an Integrated Digital Model Platform (IDMP). Unlike conventional distributed storage or cloud synchronization systems, the invention concurrently provides three features:

[0565] 1. Immutable signature chain for enforcing concurrent non-repudiation and tenant isolation,

[0566] 2. Offline-first, multi-party collaboration operation with deterministic collision resolution (e.g., vector-clock-based), and

[0567] 3. Cryptographically enforced data invalidation, allowing coordinated revocation of access under shared policies (“Collaborative forgetting”).

[0568] 1 , Immutable signature chain for concurrent non-repudiation and multi-tenancy

[0569] In some embodiments, even' operation executed within the Integrated Digital Model Platform (“IDMP”) is recorded in an append-only authority-of-source-of-truth (“ASOT”) ledger. Each record includes a cryptographic signature that (i) binds the payload to its originator and (ii) links the record to the immediately previous entry, thereby forming an unbroken signature chain. Because the ASOT ledger is immutable - e.g., new entries may be appended but existing entries cannot be modified or deleted, this mechanism simultaneously (a) prohibits an actor from repudiating a previously executed action and (b) serves as an intrinsic mutual-exclusion (“mutex”) scheme that isolates tenants while sharing the same storage substrate. Conventional edge-deployment solutions such as cloud-in-a-box like solutions fail to provide these two guarantees in combination; they require external audit controls or custom application logic to achieve equivalent functionality.

[0570] 2, Offline-first operation with deterministic collision resolution

[0571] In further embodiments, each disconnected node maintains a local instance of the ASOT ledger and applies a vector-clock-based timestamp to every transaction. In a multi-tenant setting, each disconnected node can be a data plane that is linked with the IDMP enclave and the IDMP enclave maintains a vector-clock reference for the disconnected nodes. In other embodiments, in a multi-control plane setting, one or more disconnected nodes could each be a control plane that is linked with the IDMP enclave. Upon re-establishing connectivity, nodes exchange their signed ledgers. The IDMP platform reconciles divergent histories by comparing vector-clock order, validating each signature, and applying a deterministic conflict- resolution policy used in the data deconfliction algorithm (e.g., carlicst-signcd-wins, quorum -majority, or user-defined precedence). Because all entries arc idempotent, duplicate submissions are cryptographically identical, replays do not alter results. In various embodiments, the IDMP implements idempotent token management using fungible idempotent tokens to track the work (data operation) requested in the IDMP control planes and associated non-fungible tokens to track the work (data operation) performed in individual data planes. As collision resolution is performed, the corresponding non-fungible idempotent tokens reflect tire outcome of the collision resolution and identify the node that is resolved to be the authoritative source. Hie fungible token in the IDMP enclave tracks which non-fungible token corresponds to the authoritative source and is able to perfonn offline collaborations. This capability permits controlled, auditable collaboration in air-gapped or intermittent-network environments, a use case inadequately addressed by prior art that relies on continuous connectivity or manual merge procedures.

[0572] 3 , Cryptographically enforced collaborative invalidation ("‘Collaborative forgetting'’)

[0573] The IDMP platform additionally supports policy-driven invalidation of previously authorized data. In some embodiments, each data object is encapsulated in a time-limited or condition-limited envelope (e.g., OpenTDF for deployments in government or regulated settings, SAML-chained JSON Web Tokens for deployments in tire commercial industry). When an envelope expires or a revocation policy triggers, the platform appends a signed “invalidate” entry to the ASOT node. Because downstream access checks consult the ASOT, revoked objects become inaccessible within a bounded interval (for example, fifteen minutes, in accordance with U.S. Department of Defense requirements). This “collaborative forgetting” mechanism is not trivially achievable in traditional zero-trust architectures, which typically emphasize data retention rather than controlled erasure. In various embodiments, a non-fungible idempotent token previously assigned to an ASOT node, may subsequently be signed ‘invalidate’, and thus future work requests from the corresponding fungible idempotent token will not direct any future data operations to a revoked object.

[0574] Overall Technical Differentiation

[0575] Unlike conventional platforms that pennit silent overw rites or soft deletes, the IDMP enforces an irrevocable signature regime: even' request, envelope, cache entry, invalidation, or conflict-resolution decision is cryptographically signed at the point of origin and thereafter retained in an append-only ledger. Because signatures bind both payload and temporal context (via vector clocks or token IDs), any later attempt to alter, erase, or reorder history is cryptographically impossible to validate and is therefore rejected by the platform. This “write-once, prove -forever” model provides tamper-evident provenance, audit-grade traceability, and the categorical assurance that there are, quite literally, no “takesy-backsies” once an action has been committed. Multi-Tenancy and Multi-Control-Plane Operation

[0576] The IDMP isolates each tenant within a logically separate data plane whose artifacts, metadata chains, and vector clocks are independently signed. Multiple control planes can safely coexist because every state transition is thread-safe by construction: the system writes only immutable, signed objects to shared storage, and reconciliation relies solely on the cryptographic order established by those signatures (rather than on mutable locks or central coordinators). This guarantees deterministic conflict resolution even when tenants or control planes reconnect out-of-order or operate under intermittent connectivity.

[0577] Enabling Offline Access and High Latency Workflows

[0578] Fig. 18 shows a flowchart of an exemplary process for data storage with real-time synchronization between a customer cloud storage instance and a customer client edge instance, both accessible to the IDMP, in accordance with some embodiments of the present invention.

[0579] At step 1810, the platform detects a connection establishment between a customer cloud storage instance and a customer client edge instance, where the customer cloud storage instance stores a cloud version of a digital artifact, where the customer client edge instance stores an edge version of the digital artifact, and where the digital artifact was extracted from a source model fde and includes a data subunit and artifact metadata.

[0580] At step 1820. the platform receives a cloud signature chain including a chain of blocks, each block including a cloud artifact pointer to the cloud version of the digital artifact, a hash of a data subunit of the cloud version of the digital artifact, and a cryptographic signature including a hash of cloud data operations performed on the cloud version of the digital artifact, the cloud artifact pointer, and time stamps corresponding to the cloud data operations.

[0581] At step 1830. the platform receives an edge signature chain including a chain of blocks, each block including an edge artifact pointer to the edge version of the digital artifact, a hash of a data subunit of the edge version of the digital artifact, and a cryptographic signature including a hash of edge data operations performed on the edge version of the digital artifact, the edge artifact pointer, and timestamps corresponding to the edge data operations.

[0582] At step 1840, the platform triggers a detection of a data divergence event related to the digital artifact, the data divergence event corresponding to a difference between the cloud and the edge signature chains.

[0583] At step 1850, the platform triggers an execution of a data deconfliction algorithm based on the data divergence event, to identify a trusted source for an artifact update of the digital artifact, where the trusted source is one of the cloud version and the edge version of the digital artifact. At step 1860, the platform triggers a chain update of the cloud and the edge signature chains based on the identifying of the trusted source for the artifact update.

[0584] At step 1870, the platform triggers a merge of at least one of the cloud and the edge versions of the digital artifact to match the trusted source.

[0585] At step 1880, the platform triggers a recording of a successful completion of the merge in the cloud and the edge signature chains.

[0586] Finally, at step 1890, the platform triggers a data caching processor at one of the customer cloud storage instance and the customer client edge instance, to update a local cache storage with a data change associated with the merge.

[0587] In another aspect or embodiment of the present invention, one or more non-transitory physical storage media storing program code for secure cache invalidation in a customer data plane connected to an interconnected digital model platform (IDMP) are provided. The program code is executable by a hardware processor. The hardware processor, when executing the program code, causes the hardware processor to determine a session time-to-live (TTL) based on a security policy of the IDMP; generate a time-bound shared secret key (SSK) based on the session TTL; and assign a version identifier to tire time-bound SSK.

[0588] The hardware processor, when executing the program code, causes the hardware processor to also transmit the time-bound SSK, the session TTL, and a signed timestamp of the IDMP, to the customer data plane; trigger, at the customer data plane, a binding of the time-bound SSK to a digital artifact using a trusted data envelope (TDE), upon receipt of tire time-bound SSK, the session TTL, and the signed timestamp; and trigger, at the customer data plane, an appending of the TDE to a signature chain associated with the digital artifact.

[0589] The hardware processor, when executing the program code, causes the hardware processor to also receive, at the customer data plane, an access request to access the digital artifact, the access request including an access permission, an artifact pointer to the digital artifact in the customer data plane, and a local timestamp of the customer data plane.

[0590] Finally, the hardware processor, when executing the program code, causes the hardware processor to trigger, at the customer data plane, a verification of the access permission; trigger, at the customer data plane, a cryptographic determination of a validity of the time-bound SSK, based on the signed timestamp, the local timestamp, and the TDE; and trigger, at the customer data plane, a session validation process based on the verification of the access permission and the cryptographic determination of the validity of the time-bound SSK. In one embodiment, the program code further includes code to determine, at the customer data plane, an invalidity of the time-bound SSK, based on the cryptographic determination of the validity of the time-bound SSK; reject, at the customer data plane, the access request, based on the invalidity of the time-bound SSK; and mark as expired, at the customer data plane, all previous versions of the time-bound SSK, based on the version identifier of tire time-bound SSK.

[0591] In this embodiment, the program code also includes code to transmit, from the customer data plane, an expired SSK alert to the IDMP; receive, at the customer data plane, a forgetting instruction including the artifact pointer and a revocation scope; and delete, at the customer data plane, one or more cached versions of the digital artifact based on the revocation scope.

[0592] Finally, in this embodiment, the program code also includes code to transmit, from the customer data plane, a signed confinnation of cache invalidation to the IDMP, based on the invalidity of the time-bound SSK; and execute, at the customer data plane, one or more cascading revocations to invalidate one or more digital artifacts derived from the digital artifact, based on the revocation scope.

[0593] In one embodiment, the code to generate the time-bound SSK includes code to carry out an elliptic curve Diffie Hellman (ECDH) key exchange.

[0594] Machine Learning (ML) and Neural Networks

[0595] 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., learn). An ML model is the output generated when a ML algorithm is trained on data. As described herein, embodiments of the present invention use one or more artificial intelligence (Al) and ML algorithms to enable zero-trust and zero-knowledge hyper-scalable distributed digital threading that is configured to provide assurances to the user that the data they are using comes from user-trusted sources. 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.

[0596] Neural Networks

[0597] A neural network is a computational model comprising 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. 19 describes neural network operation fundamentals, according to exemplary embodiments of tire present invention. While the example below describes an ML model suitable for digital engineering, similar approaches for ML models are equally applicable within the Fyber platform for other use cases.

[0598] Fig. 19 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:

[0599] 1. Input: Receiving an input vector v 1904 with elements v with j G [1, n] representing the f1input, and where each element of the vector corresponds to an element 1906 in tire input layer. For an exemplary' neural network model trained to update a platform script, the input vector v 1904 may take the form of a user prompt. An input can be a user prompt, a document, a model, program code, system data from the Fyber platfonn, and / or any useful form of data.

[0600] 2. Transfer Function: Multiplying each element of the input vector by a corresponding weight w 1908. These weighted inputs are then summed together as the transfer function, yielding the net

[0601] Tl input to the activation function S._1v. . w 1910.

[0602] Each neuron in a neural network may have a bias value 1912. 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 the data better. With biases, the net input to the activation function is S j"=i (1v j . w j }J+ b.

[0603] In the exemplary neural network model described above (e.g., to implement a script-updating ML model), the value of the transfer function 1910 may represent the probability that a given script update will be output.

[0604] 3. Activation Function: Passing the net input through an activation function 1914. The activation function o determines the activation value o 1918, 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 0 1916 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 net 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. In the exemplary neural network model described above (e.g., to implement a script-updating ML model), the activation function o 1914 may be a ReLU that is activated at a threshold 6 1916 representing the minimum probability for a given script update to be implemented. Hence, the activation function 1914 will yield the given script update when the implementation likelihood exceeds the threshold 6 1916.

[0605] 4. Output: The...

Claims

ClaimsWhat is claimed is:

1. A non-transitory physical storage medium storing program code, the program code executable by a hardware processor to cause the hardware processor to execute a computer-implemented process for data storage with real-time synchronization between a first customer data plane and a second customer data plane, both the first customer data plane and the second customer data plane accessible to an interconnected digital model platform (IDMP), the program code comprising code to: detect a connection establishment of a network connectivity between tire first customer data plane and the second customer data plane, w herein the first customer data plane stores a first version of a digital artifact, wherein the second customer data plane stores a second version of the digital artifact, wherein the digital artifact was extracted from a source model file, and wherein the digital artifact comprises a particular data subunit and a particular artifact metadata; receive a first signature chain, the first signature chain comprising a first chain of blocks, each block comprising a first artifact pointer to the first version of the digital artifact, a first hash of a first data subunit of the first version of the digital artifact, and a first-block cryptographic signature comprising a second hash of a plurality of first data operations performed on tire first version of the digital artifact, the first artifact pointer, and a plurality of first timestamps corresponding to the plurality of first data operations; receive a second signature chain, the second signature chain comprising a second chain of blocks, each block comprising a second artifact pointer to the second version of the digital artifact, a third hash of a second data subunit of the second version of tire digital artifact, and a second-block cryptographic signature comprising a fourth hash of a plurality of second data operations performed on the second version of the digital artifact, the second artifact pointer, and a plurality of second timestamps corresponding to the plurality of second data operations; trigger a detection of a data divergence event related to the digital artifact, tire data divergence event corresponding to a difference betw een the first signature chain and tire second signature chain; trigger an execution of a data deconfliction process based on the data divergence event, to identify a trusted source for an artifact update of the digital artifact corresponding to the difference between the first signature chain and the second signature chain, wherein the trusted source is selected from the group consisting of the first version and the second version of the digital artifact; and trigger a chain update of the first signature chain and the second signature chain based on the identification of the trusted source for the artifact update.

2. The non-transitory physical storage medium of claim 1, wherein the program code further comprises code to: trigger a merge of at least one of the first version and the second version of the digital artifact to match the trusted source; and trigger a recording of a successful completion of the merge in the first signature chain and the second signature chain.

3. The non-transitory physical storage medium of claim 2, wherein the detection of the data divergence event, the execution of tire data deconfliction process, and the merge, are carried out by a synchronization agent of the first customer data plane.

4. The non-transitory physical storage medium of claim 2, wherein the program code further comprises code to: trigger a data caching processor of one of the first customer data plane and the second customer data plane to update a local cache storage with a data change associated with the merge.

5. The non-transitory physical storage medium of claim 1, wherein the difference between the first signature chain and the second signature chain is based on a mismatch between a first given hash of a first given data subunit from a first block of the first signature chain and a second given hash of the first given data subunit from a second block of the second signature chain.

6. The non-transitory physical storage medium of claim 1, wherein the difference between the first signature chain and the second signature chain is based on a mismatch between a first given timestamp of a given data operation from a first block of the first signature chain and a second given timestamp of the given data operation from a second block of the second signature chain.

7. Tire non-transitory physical storage medium of claim 1, wherein the difference between the first signature chain and the second signature chain is based on a mismatch between a first artifact metadata of a given version of the digital artifact from a first block of the first signature chain and a second artifact metadata of the given version of the digital artifact from a second block of the second signature chain.

8. The non-transitory physical storage medium of claim 1, wherein the first customer data plane is located at a customer cloud storage instance and the second customer data plane is located at a customer client edge instance.

9. The non-transitory physical storage medium of claim 8, wherein the source model file is stored in the customer cloud storage instance.

10. The non-transitory physical storage medium of claim 1, wherein the first customer data plane is located at a first customer client edge instance and the second customer data plane is located at a second customer client edge instance.

11. The non-transitory physical storage medium of claim 1, wherein the program code to detect the connection establishment of the network connectivity further comprises code to compare a first logical clock of tire first customer data plane and a second logical clock of the second customer data plane based on a reference timestamp issued by the IDMP based on a trusted time stamp authority (TSA).

12. The non-transitory physical storage medium of claim 1, wherein a given first block cryptographic signature of a given block of the first signature chain is a trusted data envelope (TDE).

13. The non-transitory physical storage medium of claim 1, wherein the digital artifact is accessible through an external, commonly-accessible function script, wherein the external, commonly-accessible function script provides one or more addressable Application Programming Interface (API) or Software Development Kit (SDK) endpoints that are accessible by third-party applications and users, and wherein the addressable API or SDK endpoints enable access to the digital artifact without access to an entirety of the source model file.

14. The non-transitory physical storage medium of claim 13, wherein a sharable model representation provides access to a selective portion of the digital artifact, wherein the sharable model representation comprises the external, commonly-accessible function script, and wherein the sharable model representation is accessible via the addressable API or SDK endpoints from the first customer data plane and the second customer data plane.

15. The non-transitory physical storage medium of claim 13, wherein the external, commonly-accessible function script is associated with an action token issued by a token management system of the IDMP, wherein the external, commonly-accessible function script can only be accessed in the first customer data plane using an access token associated with the action token and provided by tire token management system of the IDMP, andwherein the IDMP detects a data change associated with a function execution of the external, commonly-accessible function script in the first customer data plane based on receiving the access token.

16. Tire non-transitory physical storage medium of claim 15, wherein the action token is a non-fungible idempotent tokens (NFIT) and the access token is a fungible idempotent tokens (FIT).

17. The non-transitory physical storage medium of claim 1, wherein the source model file is stored at a third customer data plane distinct from the first customer data plane and the second customer data plane, and accessible from the IDMP.

18. A non-transitory physical storage medium storing program code, the program code executable by a hardware processor to cause the hardware processor to execute a computer-implemented process for secure cache invalidation in a customer data plane connected to an interconnected digital model platform (IDMP), the program code comprising code to: determine a session time-to-live (TTL) based on a security policy of the IDMP; generate a time-bound shared secret key (SSK) based on the session TTL; assign a version identifier to the time-bound SSK; transmit the time-bound SSK, the session TTL, and a signed timestamp of the IDMP, to the customer data plane; trigger, at the customer data plane, a binding of the time-bound SSK to a digital artifact using a trusted data envelope (TDE), upon receipt of the time-bound SSK, the session TTL, and the signed timestamp; trigger, at the customer data plane, an appending of the TDE to a signature chain associated with the digital artifact; receive, at the customer data plane, an access request to access the digital artifact, the access request comprising an access permission, an artifact pointer to the digital artifact in the customer data plane, and a local timestamp of the customer data plane; trigger, at the customer data plane, a verification of the access permission; trigger, at the customer data plane, a cryptographic determination of a validity of the time-bound SSK, based on the signed timestamp, the local timestamp, and the TDE; and trigger, at the customer data plane, a session validation process based on the verification of the access permission and the cryptographic determination of the validity of the time-bound SSK.

19. The non-transitory physical storage medium of claim 18, wherein the program code further comprises code to: determine, at tire customer data plane, an invalidity of the time-bound SSK, based on the cryptographic determination of the validity of the time-bound SSK; reject, at the customer data plane, the access request, based on the invalidity of the time-bound SSK; mark as expired, at the customer data plane, all previous versions of the time-bound SSK, based on the version identifier of the time-bound SSK; transmit, from tire customer data plane, an expired SSK alert to the IDMP; receive, at the customer data plane, a forgetting instruction comprising the artifact pointer and a revocation scope; delete, at the customer data plane, one or more cached versions of the digital artifact based on the revocation scope; transmit, from the customer data plane, a signed confirmation of cache invalidation to the IDMP, based on the invalidity of the time-bound SSK; and execute, at tire customer data plane, one or more cascading revocations to invalidate one or more digital artifacts derived from the digital artifact, based on the revocation scope.

20. The non-transitory physical storage medium of claim 18, wherein the code to generate the time-bound SSK comprises code to carry out an elliptic curve Diffie Hellman (ECDH) key exchange.

Images