Distributed digital threading platform for trusted data sources

Abstract

The Fyber platform, or "'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 the 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. Ulis 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, law, science, medicine, engineering, and others.

Description

[0001] Distributed Digital Threading Platform for Trusted Data Sources

[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 Hilly 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 softw are 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] PCT International Applications

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

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

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

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

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

[0021] • 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. • 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,” describes workflow integration with Al-assistance.

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

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

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

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

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

[0027] • PCT application No. PCT / US24 / 61606 (Docket No. IST-03.008PCT), filed on December 21, 2024, entitled “Alternative Digital Tool Selection and Optimization in Digital Model Platforms,” relates to the enhancement of workflows by providing alternative digital tools to perform user-requested digital tasks.

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

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

[0030] U.S. Provisional Applications

[0031] • U.S. provisional patent application No. 63 / 442,659 (Docket No. IST-01.001P), filed on February 1, 2023, entitled “AI-Assisted Digital Documentation for Digital Engineering with Supporting Systems and Methods,” describes Al-assistance tools for digital engineering (DE), including modeling and simulation applications, and tire certification of digitally engineered products. • U.S. provisional patent application No. 63 / 451,545 (Docket No. IST-01 .002P), filed on March 10, 2023, entitled “Digital Threads in Digital Engineering Systems, and Supporting AI-Assisted Digital Thread Generation,” describes model splicer and digital threading technology.

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

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

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

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

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

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

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

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

[0040] • 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 Engineeringf describes an Al-enabled digital engineering task fulfillment process within a DE software platform. • 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.

[0041] • U.S. provisional patent application No. 63 / 516,891 (Docket No. IST-03.004P), filed on August 1,

[0042] 2023, entitled '"Multimodal User Interfaces for Digital Engineering,” describes multimodal user interfaces for DE systems.

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

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

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

[0046] • 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 Plaforms.” describes a robust, unified, scalable versioning framework for model-based digital engineering.

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

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

[0049] • 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 (AT) Models.” further details data sovereignty assurances during Al model training and evaluation.

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

[0051] • U.S. provisional patent application No. 63 / 650,498 (Docket No. IST-05.001P), filed on May 22,

[0052] 2024, entitled “Fyber: Distributed Digital Threading Platform for Trusted Data Sources.” • U.S. provisional patent application No. 63 / 664,676 (Docket No. IST-05.002P), filed on June 26,

[0053] 2024, entitled “Discontinuous Access to Interconnected Digital Model Platforms. ”

[0054] Notice of Copyrights and Tradedress

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

[0056] ISTARI DIGITAL is a trademark name carry ing embodiments of the present invention. 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, and the company providing said invention.

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

[0058] Field of the Invention

[0059] This disclosure relates to tools for data representation and manipulation within a networked environment. Specifically, this disclosure relates to methods and systems for the linking, certification, and management of data resources and trusted data sources.

[0060] Background of the Invention

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

[0062] Hie credibility of source data has always been a challenge for organizations designing and maintaining real -world products, systems, and processes in various industries. The challenge of authenticating trustworthy content will be compounded in an Al-generated era. For example, trustworthy content on the Internet is an area of active effort, where the gathering and citing of sources, data provenance and the ability to track or demonstrate provenance are generating tremendous interest. The generation and maintenance of data, whether it is on the Internet or on any other network, relies on gathering and self-reporting of sources. The need for generating and maintaining data provenance is highlighted in academic work. There are some industry collaborative actions, such as the Content Authenticity Initiative that provides an approach for tracking content source or derivative actions. The Coalition for Content Provenance and Authenticity (C2PA) also seeks to provide technical standards for metadata to tag information sources.

[0063] Tire provenance of content, or data, is presented through metadata and may be verified by cryptographically hashing a source article or image with its metadata. The generated hashcode may be used to verify data integrity and / or provenance. This approach works well for content providers such as newspaper companies or visual media companies that can maintain a central database of source content.

[0064] Content verification, source credibility, and provenance are highlighted as major challenges in gathering and analyzing content sources. Although this is required to enable trustworthy journalism in the Al era, it is true in any data-related process within any organization. In the contemporary landscape of digital information, the rapid dissemination of misinformation underscores the critical need for mechanisms that verify the authenticity and reliability of content. Centralized efforts such as the Content Authenticity Initiative and the Coalition for Content Provenance and Authenticity (C2PA) embed cryptographic hashes into content metadata, establishing a verifiable trail from source materials to their derivatives. Such voluntary efforts for a common technical framework seek to foster trust by ensuring that each piece of digital media can be traced back to its original monolithic source (e.g., source document or image) using metadata to capture every derivative action, providing a linkage that supports the authenticity of the information.

[0065] These approaches can support a single organization providing a mechanism to share trusted documents, images etc. Key attributes in this approach can also be limitations for scaling to include more content or diversify access across several trusted sources. The use of a central repository of all trusted source content and the requirement of cryptographic hashes of source content that must be included in every metadata of derivatives in the chain of provenance, require dedicated centralized data storage.

[0066] Conventional approaches thus still rely on a central database of "source7’ content with data provenance shown by a set of linked credentials as metadata. Faced with the onslaught of derivative content, data, and documents, often using derivative, intertwined, or unintelligible sources, centralized approaches for verifying original data sources do not scale.

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

[0068] Brief Summary of the Invention

[0069] This summary of the invention provides a broad overview of the invention, its application, and uses. It is not intended to limit the scope of the present invention, which will be apparent from tire detailed description when read along with the drawings. The Fyber platform, or '‘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 the 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, law, science, medicine, engineering, and others.

[0070] Various methods, processes, systems, and non-transitory storage medium storing program code for generating a digital thread script operating on data from a trusted data source within a digital platfomr are provided.

[0071] According to a first aspect or in one embodiment, a non-transitory physical storage medium storing program code is provided. The program code is executable by a hardware processor. The hardware processor when executing the program code causes the hardware processor to execute a computer-implemented process for generating a digital thread script operating on data from a trusted data source within a digital platfomr.

[0072] The program code may include code that may receive a data source as the trusted data source, where the trusted data source may be located in an external security environment external to the digital platform. The program code may also include code that may derive a digital artifact from the data source, the digital artifact including a data subunit and artifact metadata derived from the data source. The program code may also include code that may store the digital artifact in a digital artifact storage environment accessible by the digital platform. The program code may also include code that may generate an external, commonly-accessible function script that may enable external access to the digital artifact, where the external, commonly-accessible function script may provide one or more addressable Application Programming Interface (API) or Software Development Kit (SDK) endpoints that may be accessible by third-party applications and users, and where the addressable API or SDK endpoints may enable access to the digital artifact without access to an entirety of the data source. The program code may also include code that may generate a sharable resource representation of the data source, where the sharable resource representation may include access to a selective portion of the digital artifact, where the sharable resource representation may include tire external, commonly-accessible function script, and where the sharable resource representation may be accessible via the addressable API or SDK endpoints by the third-party applications and users. The program code may also include code that may generate a digital thread script based on the sharablc resource representation using tire addressable API or SDK endpoints in the sharable resource representation. Finally, the program code may also include code that may execute the digital thread script on tire digital platform to generate a live digital resource, where the live digital resource may be configured through the digital thread script to access the digital artifact, and where a notification of a modification of the data source may appear in the live digital resource within a predetermined delay.

[0073] In one embodiment, the data source may be identified by a resource identifier, where the program code to receive the data source may further include program code to receive the resource identifier, and where the program code to derive the digital artifact from the data source may further include program code to extract resource data from the data source identified by the resource identifier.

[0074] In one embodiment, the live digital resource may be configured through tire digital thread script to store the artifact metadata, where the artifact metadata may include the resource identifier.

[0075] In one embodiment, the program code may include code that may generate a trusted data envelope associated with the digital artifact, where the trusted data envelope may include a cryptographically verifiable structure that encapsulates access policies, a metadata block, and a reference to the digital artifact, and where the access to the selective portion of tire digital artifact may further invoke program code to verify tire trusted data envelope.

[0076] In one embodiment, the trusted data envelope may include a data pointer field indicating a location of the digital artifact, a data hash field including a cryptographic digest of a data component of the digital artifact, the metadata block, and one or more digital signatures.

[0077] In one embodiment, the metadata block may include an issuer identity, a subject identifier, a timestamp, and one or more permitted operations.

[0078] In one embodiment, the one or more permitted operations may include an access policy.

[0079] In one embodiment, the one or more digital signatures may include an issuer signature, a recipient signature, and a signature from a Timestamp Authority (TSA).

[0080] In one embodiment, the trusted data envelope may depend on a parent trusted data envelope associated with a parent digital artifact, where access to the digital artifact may require access to the parent digital artifact.

[0081] In one embodiment, the program code may include code that may receive a security network identifier associated with the data source, where the metadata block may include the security network identifier associated with the data source.

[0082] In one embodiment, the program code may include code that may receive a security network identifier associated with the digital artifact, where the artifact metadata may include the security network identifier associated with the digital artifact.

[0083] In one embodiment, the program code to generate the live digital resource may include program code to update the live digital resource. In one embodiment, the program code may include code that may output, for display, the live digital resource to a user on a user interface.

[0084] In one embodiment, the data source may have a data source type and may be in a native fde fomiat, where the addressable API or SDK endpoints may enable access to the digital artifact without access to the entirety of the data source and without requiring direct engagement by the third-party applications and users with a software tool associated with the data source type, and where the addressable API or SDK endpoints may provide a unified programming interface to sharable resource representations generated from data sources having the data source type.

[0085] In one embodiment, the digital artifact storage environment may be located within the external security environment of the trusted data source.

[0086] In one embodiment, the digital artifact storage environment may be distinct from the external security environment of the trusted data source.

[0087] In one embodiment, the access to the selective portion of the digital artifact may be limited in time.

[0088] In a second aspect or in yet another embodiment, a computer-implemented method for generating a digital thread script operating on data from a trusted data source within a digital platform is disclosed.

[0089] The method may include receiving a data source as the trusted data source, where the trusted data source may be located in an external security environment external to the digital platform. The method may also include deriving a digital artifact from the data source, the digital artifact including a data subunit and artifact metadata derived from the data source. The method may also include storing the digital artifact in a digital artifact storage environment accessible by the digital platfonn. The method may also include generating an external, commonly-accessible function script that may enable external access to the digital artifact, where the external, commonly-accessible function script may provide one or more addressable Application Programming Interface (API) or Software Development Kit (SDK) endpoints that may be accessible by third-party applications and users, and where the addressable API or SDK endpoints may enable access to the digital artifact without access to an entirety of the data source. The method may also include generating a sharable resource representation of the data source, where tire sharable resource representation may include access to a selective portion of the digital artifact, where the sharable resource representation may include tire external, commonly-accessible function script, and where the sharable resource representation may be accessible via the addressable API or SDK endpoints by the third-party applications and users. The method may also include generating a digital thread script based on the sharablc resource representation using the addressable API or SDK endpoints in the sharablc resource representation. Finally, the method may include executing the digital thread script on the digital platform to generate a live digital resource, where the live digital resource may be configured through the digital thread script to access the digital artifact, and where a notification of a modification of the data source may appear in the live digital resource w ithin a predetermined delay.

[0090] In one embodiment, the method may include generating a trusted data envelope associated with the digital artifact, where the trusted data envelope may include a cryptographically verifiable structure that encapsulates access policies, a metadata block, and a reference to the digital artifact, and where the access to the selective portion of the digital artifact may invoke verifying the trusted data envelope.

[0091] In one embodiment, the trusted data envelope may include a data pointer field indicating a location of the digital artifact, a data hash field including a cryptographic digest of a data component of the digital artifact, the metadata block, and one or more digital signatures.

[0092] Embodiments as set out for the first aspect may apply equally to the second aspect.

[0093] In various aspects and embodiments, a computer program product is provided. The computer program may be used for generating a digital thread script operating on data from a trusted data source within a digital platform, and may include a computer-readable storage medium having program instructions, or program code, embodied therew ith, the program instructions executable by a processor to cause the processor to perform tire aforementioned steps.

[0094] In various aspects and embodiments, a system for generating a digital thread script operating on data from a trusted data source within a digital platform is provided, the system including a memory that stores computer-executable components, and a hardw are processor, operably coupled to the memory, and that executes the computer-executable components stored in the memory, w here the computer-executable components may include components communicatively coupled with the processor that execute tire aforementioned steps.

[0095] In various aspects and embodiments, a system for generating a digital thread script operating on data from a trusted data source w ithin a digital platform is provided, the system including a user device having a processor, a display, a first memory; a server including a second memory' and a data repository'; a communications link between said user device and said server; and a plurality of computer codes embodied on said first and second memory of said user device and said server, said plurality of computer codes which when executed causes said server and said user device to execute a process including the steps described herein.

[0096] 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. Other aspects and embodiments of the present invention include the methods, processes, and algorithms including the steps described herein, and also include the processes and modes of operation of the systems and servers described herein.

[0097] 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 aforementioned steps.

[0098] 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 the systems and servers described herein.

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

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

[0101] Brief Description of the Drawings

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

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

[0104] Fyber Platform Architecture and Examples

[0105] Fig. 1 show s an overview of the Fyber platform, in accordance with some embodiments of the present invention. Fig. 2 shows an ovendew of the Fyber platform, illustrating the use of cryptographic tokens, for example based on a blockchain, in accordance with some embodiments of the present invention.

[0106] Fig. 3 shows an exemplary graphical user interface (GUI) for a secure digital thread over the Fyber platform, according to one embodiment of the present invention.

[0107] Fig. 4 shows a digital thread example with a data provenance auditable report, according to one embodiment of the present invention.

[0108] Fig. 5 shows another exemplary graphical user interface (GUI) for a secure digital thread over the Fyber platform, according to one embodiment of the present invention.

[0109] Fig. 6 shows an exemplary platform use case for a law review document, in accordance with some embodiments of the present invention.

[0110] Fig. 7 shows an illustrative process flow where a digital thread checks and updates digital artifacts from different data sources, in accordance with one embodiment of the present invention.

[0111] Fig. 8 shows an illustrative process flow where the Fyber platform processes third party access to data using Trusted Data Envelopes, in accordance with one embodiment of the present invention.

[0112] Fig. 9 shows an exemplary implementation of the Fyber platform and exemplary' platform scenarios, in accordance with some embodiments of the present invention.

[0113] Fig. 10 shows an exemplary Fyber platform architecture, in accordance with some embodiments of the present invention.

[0114] Fig. 11 shows another exemplary Fyber platform architecture, in accordance with some embodiments of the present invention.

[0115] Fig. 12 shows exemplary Fyber system-level architectures, in accordance with some embodiments of the present invention.

[0116] Exemplary Fyber Process and System Diagram

[0117] Fig. 13 is an exemplary flow chart showing a process for generating and executing a digital thread script extracting data from a trusted data source within a Fyber platform, in accordance with some embodiments of the present invention.

[0118] 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 a Fyber platfonn, in accordance with some embodiments of the present invention.

[0119] Fyber Platfonn Links Resource Representations into Digital Threads

[0120] Fig. 15 shows an exemplary implementation illustrating the platform’s offered services and features using multi-tenant enclaves, in accordance with some embodiments of the present invention.

[0121] Fig. 16 shows potential scenarios for instantiating the platfonn in connection to a customer's physical system and IT environment, in accordance with some embodiments of the present invention. Fig. 17 shows exemplary multimodal interface designs, in accordance with some embodiments of the present invention.

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

[0123] Fig. 19 is a schematic showing an exemplary splicing setup, in accordance with some embodiments of the present invention.

[0124] Fig. 20 is a schematic showing digital threading via splicing, in accordance with some embodiments of the present invention.

[0125] Fig. 21 is a schematic illustrating the linking of splices in a splice plane and comparing digital threading with and without model splicing, in accordance with some embodiments of the present invention.

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

[0127] Generating and Executing a Digital Thread

[0128] Fig. 23 shows an exemplary graphical user interface (GUI) used to operate a digital thread, according to one embodiment of the present invention.

[0129] Fig. 24 shows another exemplary graphical user interface (GUI) used to operate a digital thread, according to one embodiment of the present invention.

[0130] Fig. 25 shows an exemplary graphical user interface (GUI) used to generate and / or update a live document, according to one embodiment of the present invention.

[0131] Fig. 26 shows an exemplary' graphical user interface (GUI) used to generate or update a live suite or collaboration board, according to one embodiment of the present invention.

[0132] Fig. 27 shows an illustrative process flow where the platform updates a live document, in accordance with one embodiment of the present invention.

[0133] Machine Teaming Implementation Architectures

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

[0135] Fig. 29 shows an overview of a neural network training process, in accordance with some embodiments of the present invention.

[0136] Fig. 30 is an illustrative flow diagram showing the different phases and datasets involved in training a machine learning model, in accordance with some embodiments of the present invention. Hardware and Software Architecture

[0137] Fig. 31 provides illustrative schematics of a server (management computing entity) and a client (user computing entity) used within a Fyber platform, in accordance with some embodiments of the present invention.

[0138] Detailed Description of the Invention

[0139] In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these specific details. In other instances, structures, devices, activities, methods, and processes are shown using schematics, use cases, and / or diagrams to avoid obscuring the invention. Although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and / or alterations to suggested details are within the scope of the present invention. Similarly, although many of the features of the present invention are described in terms of each other, or along 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.

[0140] Terminology

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

[0142] Introduction / Overview

[0143] The 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, Fyber enables the secure linking of a given document to digital artifacts from different trusted sources. This ensures that content not only adheres to high standards of accuracy but is also verifiable against credible references.

[0144] 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, tire temi “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”.

[0145] 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 Fyber Platform 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. Such a data operation can be regarded as meeting zero trust principles for access to the data.

[0146] The integration platform is configured to offer application programming interfaces (APIs) and collaboration user interfaces (UIs) connecting the 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.

[0147] 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 Fyber platform needs to be a distributed platform to enable effective collaboration. The integration platform therefore allows select access to information from disparate trusted data sources, thus enabling decentralized digital threads.

[0148] 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 must be distributed to be effective.

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

[0150] 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 platfomr 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.

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

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

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

[0154] Fyber Platform as ‘Mortar’ Linking Generic Digital Artifacts as ‘Bricks’

[0155] The present disclosure relates to the Fyber platform, 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.

[0156] Functionally, the Fyber platform 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.

[0157] 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 Fyber platform 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.

[0158] Through these advanced mechanisms, the Fyber platform promotes 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.

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

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

[0161] 2. Number input for identifying paragraph ID

[0162] 3. Text input for editing paragraph content

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

[0164] Corresponding outputs from these inputs include:

[0165] 1. The text content of paragraphs

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

[0167] 3. The total paragraph count

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

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

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

[0171] These input and output functionalities enable the Fyber platform 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 the Fyber platform integrates disparate digital artifacts into a functional, coherent system executing digital threads.

[0172] Advantages of the Fyber Platform

[0173] Fyber introduces a systematic approach to data sharing and provenance verification, emphasizing auditable trust without the necessity’ to reveal the data itself or identify the data recipient. This invention departs from traditional models where authorization processes are heavily reliant on identity verification to establish trust. Fyber's architecture is built on a zero-trust zero-know ledge foundation, allow ing for the certification of data authenticity received from users and agents w ithout requiring access to or know ledge of the actual data. This system uniquely supports ephemeral identities for data access, enabling public access to audit reports on models without the need for user login or direct data exposure.

[0174] One advantage of Fyber lies not in the aggregation of multiple Authoritative Sources of Truth (ASoTs) or multiple trusted sources but in enabling ephemeral authorization for audit data on resources while preserving the confidentiality of the data content. Moreover, Fyber facilitates trusted zero-knowledge audits of model data, ensuring that all system components operate independently without mutual trust, and even' alteration to model data is meticulously logged, separate from the actual data residing in the customer's domain. This architecture contrasts sharply with non-zero-trust and non-zero-knowledge platforms, which cannot offer provably accurate audits or any form of audit for data that cannot be publicly disclosed.

[0175] Operating Across Multiple Domains

[0176] Existing data exchange systems face significant limitations when operating across multiple independent control planes and isolated data planes, particularly in classified or high-security environments. These data planes often span distinct domains (or networks) - each comprising proprietary software, unique data fomiats, and varying security policies - which renders interoperability challenging, especially when little or no prior infonnation is available about remote systems prior to initiating data exchange.

[0177] Efforts to establish digital threads — persistent links between distributed, related data artifacts — are frequently fragile and prone to failure. Such fragility typically results from unannounced changes to a participating domain’s configuration, software stack, or data models. These uncoordinated changes can disrupt the integrity of tire data exchange process, leading to inconsistent, incompatible, or untrusted data flows.

[0178] To address these limitations, the present invention provides a system and method for trusted, resilient data exchange, based on three foundational pillars:

[0179] 1. Use of Open. Machine-Readable Data Fomiats

[0180] Isolated domains frequently utilize domain-specific or proprietary fomiats for digital models or artifacts. The invention requires each data plane to export data intended for exchange in open, machine-readable fomiats, irrespective of the internal tools used. In certain embodiments, the data may be cryptographically hashed to ensure integrity and enable non-repudiation. 2, Disclosure of Domain and Network Configuration Metadata

[0181] To support reliable orchestration, each domain shares detailed configuration information and metadata describing its operational environment, comprising:

[0182] • Security policies,

[0183] • Cloud provider configurations,

[0184] • Operating system types and versions,

[0185] • Domain-specific tools and corresponding model versions, and

[0186] • Descriptive metadata for available data artifacts.

[0187] 3 , Proactive Announcement of State Changes

[0188] In contrast to reactive mechanisms in the prior art, the invention introduces a proactive system in which each control or data plane announces changes to its state, such as updates to models, tools, or configurations. These announcements enable timely coordination and compatibility checks across domains, reducing the risk of silent failures.

[0189] In various embodiments, these three pillars enable the Fyber platform to orchestrate trusted and dynamic interoperability across distributed, heterogeneous environments. By enforcing transparency in data formats, system configurations, and operational state, the invention maintains data integrity, continuity, and compatibility — even as underlying systems evolve — thereby overcoming critical challenges present in conventional approaches.

[0190] Fyber Architecture Overview

[0191] Fig. 1 shows an overview of a Fyber platfonn (sometimes referred to simply as 'platform', 'software platform’, or ‘digital platform’), in accordance with some embodiments of the present invention. An interconnected digital model platform (IDMP), referred to later in this disclosure, may be considered one embodiment of a Fyber platform applied to models and simulations.

[0192] Trusted data sources 120 are required by users within an organization to design and maintain real-world products, systems, and processes. In Fig. 1, the temr “model” applies to any data source such as a digital engineering model fde (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” 130 and may be converted by the platform to an identifiable, traceable, and access-controlled “trusted digital artifact”. 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 102 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. 1 shows an extracted artifact 132 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 108 or a magic doc 110 (also denoted “live digital resource” herein - see, for example, Fig. 25). While the user authorization for each request conforms with zero-trust security, in some embodiments, the Fyber platform can additionally perform tire 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.

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

[0194] 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 platform over a centralized network is viable in certain industries, the platform needs to be a distributed platform to enable effective collaboration. The integration platform 102 therefore allows select access to information from disparate trusted data sources 122, thus enabling decentralized digital threads.

[0195] 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 sources that they have selected. Digital threads must be distributed to be effective.

[0196] The methods and systems herein enable zero-trust, zero-knowledge hyper-scalable distributed digital threading that is configured to provide assurances to tire user that the data they are using comes from user-trusted sources (e g., 124). 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 124) is trusted, such that the user is able to operate with data emanating from their designated sources of truth / trust. Distributed digital threads also enable powerfill tools such as magic docs, as described below.

[0197] Correspondence tools such as desktop office software suites arc 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 platform 102 able to thread its trusted sources 120 with its generated documents (e.g., 110) and models. The interconnected platform 102 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.

[0198] Enabled by distributed digital threading as disclosed herein, magic docs 110 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.

[0199] 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 132) originating within tire derivatives remain indefinitely and reliably identifiable, traceable, and access-controlled.

[0200] 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 (described below), make the aggregated and / or generated data human-readable.

[0201] Fyber Enables a “Trust Layer”

[0202] Fyber introduces a trust layer to any network infrastructure, addressing tire issue of verifying the accuracy of derivative data in addition to the source data. In the 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.

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

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

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

[0206] 3. Data from all authoritative trusted sources may be integrated without being aggregated. 4. All data access orchestration must follow zero-trust and zero-knowledge principles.

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

[0208] 5. Tire Fyber platform orchestrates linked data so they automatically update as authoritative sources update.

[0209] 6. Data access can be user- or organization-specific, or selectively made available to the public at large.

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

[0211] 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 the data ecosystem is both robust and adaptable to individual needs.

[0212] 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. Uris 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.

[0213] Illustrative Use of Cryptographic Tokens in Fyber

[0214] Fig. 2 shows an overview of tire Fyber platform, illustrating the use of cryptographic tokens, in accordance with some embodiments of the present invention. In some embodiments, the cryptographic tokens may be based on a blockchain. As discussed in tire context of Fig. 1. Fig. 2 illustrates the ability of a Fyber platform 202 to allow users and agents to collaborate 206 in order to verify data source 224 authenticity, extract trusted digital artifacts 232, generate new trusted digital documents and models 210 that connect the extracted digital artifacts 232 with existing trusted models (e.g., 222), using secure digital threads 208 that accesses sources, artifacts, and digital resources (e.g., documents) via the platform’s API layer 204. Digital Resource Processing and Transactions

[0215] As shown in Fig. 2, various Fyber-enabled digital resources such as magic docs 210 (but also digital threads 208, models 222, etc.) may be accessed and modified via the Fyber platform 202 (see Figs. 10 and 11), thus generating new or updated digital resources.

[0216] In some embodiments, digital resources (e.g., 210) may be exchanged over a transaction ledger such as a blockchain 240. In one embodiment, the transaction ledger 240 may be maintained by a network of distributed nodes and may be accessible via a transaction ledger interface 244 enabling a bidirectional token interface 242.

[0217] In one embodiment, the transaction ledger 240 may be a private transaction ledger facilitating internal transactions within Fyber, where the transaction ledger interface 244 includes an internal payment processor. In another embodiment, the transaction ledger 240 may be a public transaction ledger that may include a public blockchain, accessible via an external payment processor included within the transaction ledger interface 244. The private transaction ledger and the public transaction ledger may enable transactions wherein digital resources are exchanged for local or global token rewards.

[0218] Smart contracts and blockchain integration

[0219] In some embodiments, the bidirectional interface 242 may allow the platform 202 to:

[0220] • Trigger public smart contracts 246, enabling decentralized execution of predefined contractual agreements.

[0221] • Retrieve public data, such as certifications, from trusted third-party sources.

[0222] Further, a smart contract interface 248 is intended to serve as a trusted interface that enables interaction between Fyber 202 and trusted external sources. These sources may include regulatory entities, certification authorities, or other credentialing institutions.

[0223] To facilitate transactions, internal tokens within Fyber 202 may be funded from external sources via a central payment gateway or the public transaction ledger. U.S. provisional patent application No. 63 / 769,490 (Docket No. IST-03.013P) provides further detail and embodiments for tire use of cry ptographic tokens in Fyber, and is incorporated by reference as if fully set forth herein.

[0224] Fyber Platform Examples and Use Cases

[0225] Fig. 3 shows an exemplary graphical user interface (GUI) for a secure digital thread over the Fyber platform, according to one embodiment of the present invention. Fig. 3 shows a data format and workflow view 310 and an auditable summary view 320. In some embodiments, a user may utilize the workflow view to design the digital thread of a complex digital workflow (e.g. digital engineering modeling and simulations) task where one may need to ensure that the right digital artifacts are exchanged between specific actions, in the correct formats so the thread is executed correctly. In some embodiments, a user may utilize the workflow view to assess the complexity of their digital thread and look for options to simplify, or to add descriptive text explaining the steps.

[0226] Specifically. Fyber, as shown in Fig. 3, an auditable summary view 2320 may interface signed digital threads similar to smart contracts, where the GUI displays a mockup of the digital thread visualized with e-signed actions. In contemporary examples, smart contracts may be executable pieces of code in a decentralized ledger such as blockchain, whereupon the validation of specific criteria or triggers, the code is executed and the confirmation as a smart contract is tokenized on the blockchain. Fyber’s implementation of secure digital threads in a zero-trust fashion provides an auditable log that is cryptographically signed for each action on the digital thread. Examples such as an auditable summaryview 320 or a data provenance report 410 or a data provenance credential 420 (see Fig. 4), present an option to centrally create smart contracts while verification of the individual data operations steps may occur decentralized within specific digital artifacts linked from different trusted data sources. In some embodiments, any single line item of an auditable log of a digital thread in Fyber platform may be regarded as a smart contract. In other embodiments, a group of one or more line items from an auditable log can be regarded as a smart contract reflecting the successful completion of the trusted data operations defined in the digital thread.

[0227] Fig. 4 shows a digital thread example with a data provenance auditable report 410, according to one embodiment of the present invention. In particular, Fig. 4 shows a credential example 420 with provenance verification across decentralized artifacts. As shown in Fig. 4, the Fyber GUI may display an auditable report of data from a trusted source, and may represent a credential badge on a given data source (e.g., a website). The data provenance report 410 or data provenance credential 420 may reflect different steps depending on the scenario for the Fyber platform - secure authorized access to trusted sources 930, or ephemerally authenticated access to trusted sources 940 (see Fig. 9). In either scenario, the individual actions performed by the platform upholding zero trust security principles and the optional use of trusted data envelopes are cryptographically signed on the digital thread. In some embodiments of the Fyber platform, users may need to login into the platfonn to verify the data provenance reports. In other embodiments of the Fyber platform, users may not need to login to the platfonn, but may instead rely on data provenance credential 420 publicly for any digital artifact linked through the Fyber platform. In such embodiments, users may create digital content including links to digital artifacts from trusted sources within tire Fyber platform, where such digital artifacts arc made available with broader data use guidance such as public use or creative commons licensed use. Fig. 5 shows another exemplary graphical user interface (GUI) for a secure digital thread over the Fyber platform, according to one embodiment of the present invention. In Fig. 5, the GUI shows various options for data flow and linkages across the digital thread. In Fig. 5, two alternative illustrative digital thread GUI configurations showing digital artifacts, functions, and live digital resources (e.g., magic doc) associated with a digital thread are depicted. In the left-side GUI configuration 510. the data linkages (e.g., 512) between the digital artifacts (e.g., 514), functions (e.g., 516), and digital resources (e.g., 518) are apparent, whereas function scripts are hidden. However, available functions may be selected from a drop-down menu 520 within the digital resource to be executed. In the right-side GUI configuration 530, the data linkages between tire digital artifacts (e.g., 532), functions (e.g., 534) and digital resources (e.g., 536) are hidden, whereas function scripts are shown (e.g., 534). In addition, available functions may be selected from a drop-down menu 538 to be edited.

[0228] Alternative Embodiments to Handle Inference Articles

[0229] When users are able to digitally thread artifacts from different trusted sources, they may present these as a collage. Often, the author may add their own inference or commentary on top of such references linked from trusted sources. Inferences may or may not be correct and inferences may or may not have ill intent to mislead the audiences. To address this, Fyber must incorporate specialized treatment for inference articles that are generated using secure digital threads linking to trusted sources and references, ensuring a clear, traceable link to verifiable data.

[0230] To enhance the trustworthiness of user-generated content within Fyber, a social-proof mechanism underpinned by community interaction is implemented in an exemplary embodiment. This system leverages a voting process where users rate content based on its perceived relevance, accuracy, and quality. The collective assessment, or the "wisdom of the crowd," determines the content's prominence and perceived credibility. Further refining this process, Fyber incorporates a dynamic reputation system, where tire influence of each vote is calibrated according to the voter's accrued reputation, rewarding consistent contributions of high-quality information and encouraging adherence to community standards.

[0231] In an alternative embodiment, Fyber integrates a layered content moderation strategy to ensure rigorous quality control. Automated tools initially scan submissions to identify potential violations, such as spam or unlicensed content, flagging them for further evaluation. Human moderators, equipped with the necessary expertise, then meticulously assess these flagged items to determine their compliance with community standards and contextual appropriateness. This combination of automated and manual review processes ensures that the content not only meets quality benchmarks but also aligns with tire contextual nuances required for nuanced judgments. Additionally, a feedback mechanism informs users of the outcomes of these moderation decisions, promoting transparency and understanding within the community.

[0232] Tire platform could further include machine learning algorithms that learn from moderation patterns and community feedback to continuously improve tire screening algorithms and reputation system criteria.

[0233] These embodiments illustrate how Fyber is uniquely positioned to support generative Al and Al-generated content, utilizing secure, verified digital threads linked to trusted sources. In various embodiments, Fyber can potentially include in the data provenance credential whether a particular content is Al-generated and in other exemplary embodiments, Al-generated content could include the input context as a list of cited references to digital artifacts securely linked to trusted sources. This innovative approach ensures that the platform not only facilitates the creation of enriched, multi-source narratives but also maintains the authenticity and trustworthiness of the information being disseminated.

[0234] Fig. 6 shows an exemplary7platform use case for a law review article, in accordance with some embodiments of the present invention. In particular, Fig. 6 illustrates how granular tagging with trusted source data references may be used throughout a legal text, an academic journal, a medical document, etc. Fig. 3 illustrates a contemporary example of a law article (similar to an academic journal article in a portal) where specific references may include a URL for the citation. In certain examples of current law review articles, when cited case law is updated, a data tag indicates the update and provides a link to the updated legal decisions or opinions. These current approaches rely on having access to all references and data sources within a single repository (e.g., a digital legal repository or database). If links or URLs are included for references, they typically link to the entire article.

[0235] In contrast, Fyber’s implementation introduces two key aspects of technical differentiation:

[0236] 1. Cited references will involve identified, trusted, and shareable granular data references (e.g., citing data or digital artifacts such as a data table, a figure reference, or a sub-section).

[0237] 2. Trusted references can be decentralized, rather than being available in a single central repository.

[0238] As an additional exemplary embodiment on the Fyber platform, when a user accesses a document digitally threaded within the system, the platform increases user engagement by integrating digital artifacts linked from trusted sources. Each link within a document or webpage undergoes scrutiny in a zero-trust environment to ensure the security and verification of connections. To enhance data interaction, Fyber uses granular data tags on links to reflect the current status and credentials of each source. Key features include:

[0239] 1. Display Changes: When a user opens a digital document on the Fyber platform, there can be data tags indicating any modifications to the source data, providing a visual history of updates directly within the document.

[0240] 2. Summary of Modifications: Upon detecting changes to the linked artifacts, the platform can offer concise summaries (e.g. timestamp of change, instructions or related user credentials related to the change), allowing users to quickly grasp update details without revisiting the entire source.

[0241] 3. Recommend Credible Alternatives: Fyber suggests vetted alternative sources, verified through provenance tools and Al-driven analytics, serving as supplementary or alternative references.

[0242] 4. Links to Archived Data: If original data linked has changed, Fyber provides links to archived history of data changes, ensuring access to essential historical and contextual information on the digital thread.

[0243] 5. Recommend Similar Content: The platform guides users to similar or relevant content, expanding their understanding and insight into the topic.

[0244] 6. Multi-dimensional data graphs: Through a combination of one or more of the above features associated with a link within a digital document, the platform could present multi-dimensional data graphs that both present the digital thread for a particular artifact's current use in a document, the thread related to its data provenance along with related threads based on context.

[0245] For exemplary' features such as summarizing modifications, recommending credible alternatives, and presenting similar content, tire Fyber platform leverages machine learning models to enrich the user experience. These models are trained on comprehensive datasets that include document summaries, digital thread artifact tags, trusted source tags in documents, and metadata from digital threads. By utilizing these machine learning capabilities, Fyber significantly enhances both the user experience and trust in document accuracy and source credibility.

[0246] In various embodiments of the Fyber platform, "the link is the interface" concept transforms traditional hyperlink usage by providing dynamic, interactive links that ensure security with user authorization, verify content authenticity, and enrich user interactions within a zero-trust environment. In alternative embodiments, the security for a link as an interface can be implemented without strict zero-trust requirements. In the Fyber platform, links to digital artifacts can additionally display real-time changes, offer detailed summaries, offer threads of links that go one or more layers deep to link with source data or related contextual data, and connect users to archived data for comprehensive historical insights. Moreover, the links can leverage ML models to recommend credible alternatives and similar content, enhancing user understanding and interaction. Tire platform uses granular data tags to reflect the status and credentials of each source, supported by multi-dimensional data graphs that illustrate the complex relationships and provenance of digital artifacts. This integration of machine learning models, trained on diverse datasets, significantly boosts both user experience and trust in document accuracy across various digital formats like magic docs and secure digital threads. Thus, The link is the interface’ for trusted data sources that then evolve the context to suit the user’s interests and requirements within digital content on the internet.

[0247] While these exemplary embodiments are presented for a digital document on the Fyber platform, they are equally applicable for links threaded on the Fyber platform for other embodiments such as magic docs, secure digital threads, magic chips, and collaboration boards.

[0248] Digital Artifact Processing

[0249] Fig. 7 shows an illustrative process flow where a digital thread checks and updates digital artifacts from different data sources, in accordance with one embodiment of the present invention. In particular, Fig. 7 shows steps for data source threading, where two disjoint data sources are linked in a secure digital thread under zero trust principles.

[0250] The Fyber platfonn implements secure digital thread execution across multiple ASOTs in diverse networks. Digital threads are sequences of operations on files that are distributed across multiple computers, networks, and tools. Fyber platform’s digital threads automate work on files across many tools, networks, and sources of truth. For successful execution, secure digital threads are orchestrated in a back-to-front fashion (referred as recursion). This is so that even' digital artifact that is linked and orchestrated by the digital thread could likely have been updated and a recursive approach ensures that each digital artifact is traced back to the corresponding source data in the respective ASOT, beginning with the last digital artifact in the digital thread and step by step proceeding to each preceding digital artifact linked in the digital thread. An illustrative example shown in Figure 5 presents a digital thread with 2 actions implemented on two different digital artifacts - digital artifact (1) and digital artifact (2), which may have been updated from their source - digital artifact (1) source and digital artifact (2) source - in two different ASOTs - ASOT-1 and ASOT-2. For zero trust secure digital thread execution in Fyber, each action requested on a digital artifact is authorized before the corresponding software tool or digital artifact is allowed access. Such secure digital threads can be used for many automated sequences of operations on files that need to be securely distributed across multiple data processing resources (e.g., factory automation, pharmaceutical research, pollinator mapping, financial analysis, power grid balancing, etc). Ephemerally Authenticated Third-Party Access Over Insecure Channels to Verify ASOTs

[0251] Fyber provides a secure means to authorize updates to authoritative sources of truth and track data provenance. As shown in Fig. 9, a second scenario of Fyber's application will be for ephemerally authenticated third party access to authentic sources of data. In these scenarios, a third party will be provided ephemeral authentication to perform their data operation to access authentic sources of data. These include scenarios such as:

[0252] • journalistic integrity, in which third parties can confirm the provenance of photos, videos, and recordings, and

[0253] • scientific peer review, in which third parties can confirm that the data they’re accessing was actually produced by one of our digital threads.

[0254] • election reporting, in which third parties need to know the validated results of tallies without knowing which people voted which ways on a ballot.

[0255] For sharing ASOT data with ephemerally authenticated third parties while maintaining data integrity and authenticity, Fyber implements a solution that leverages ephemeral trust and Trusted Data Formats (TDF) for secure data sharing. Hie technical implementation encompasses three primary components: the enclave, the agent, and the client, each undergoing specific updates to facilitate the process.

[0256] Trusted Data Envelope (TDE)

[0257] Trusted Data Envelopes (TDEs) are cryptographically verifiable containers that function as ephemeral, self-validating trust carriers, allowing for autonomous verification and enabling secure access even in zero-trust or air-gapped domains. TDEs may be generated for digital artifacts, digital models, data sources, or model / resource representations including splices. TDEs may combine features such as cryptographic hashes of data artifacts, access metadata, and multi-party digital signatures. The TDE may embed or reference selected metadata fields from the associated artifact to support access control and provenance validation. In some embodiments, the TDE includes a target artifact ID or link referencing the artifact, and may incorporate cryptographic binding of that reference (e.g., via hash). A TDE may also include a digitally signed timestamp and require co-signature from multiple authorities (e.g., issuer, recipient, timestamp sendee) to enforce distributed trust in a tamper-evident and partition-tolerant manner.

[0258] In addition to these features, TDEs may incorporate several other characteristics, which may enhance tire flexibility, security, and utility of TDEs in various scenarios, from highly regulated industries to distributed, collaborative environments: • Granular access control: TDEs may include fine-granted access policies that specify not only who can access the data, but also under what conditions and for what purposes. This may include time-based restrictions, geographical limitations, or context-dependent permissions.

[0259] • Version control: TDEs may contain version information for tire associated artifact, allowing for tracking for data lineage and enabling rollback to previous states if desired.

[0260] • Audit trail: Each TDE may maintain a comprehensive log of all access attempts, and verifications, providing a detailed audit trail for compliance and security purposes.

[0261] • Encry ption capabilities: In some implementations, TDEs may include encryption mechanisms to protect the confidentiality of sensitive metadata or even the referenced data itself.

[0262] • Policy enforcement: TDEs may incorporate executable policy logic that can be evaluated in real-time to enforce complex access rules based on current conditions or system state.

[0263] • Interoperability: TDEs may be designed to be interoperable across different systems and platforms, potentially using standardized formats or protocols to ensure wide compatibility.

[0264] • Revocation mechanisms: TDEs may include mechanisms for rapid revocation of access rights, allowing for quick response to security incidents or changes in data governance policies.

[0265] • Scalability features: Tire design of TDEs may incorporate features that allow for efficient scaling, such as hierarchical structures or delegation mechanisms, to handle large volumes of data and complex organizational structures.

[0266] • Dynamic updates: TDEs may support dynamic updates to their contents, allowing for modification of access policies or metadata without requiring regeneration of the entire envelope.

[0267] • Cryptographic agility: Tire TDE structure may be designed to accommodate different cryptographic algorithms, allowing for updates to more secure methods as older ones become vulnerable.

[0268] • Partial data access: In some cases, TDEs may enable partial or selective access to the referenced data, allowing for granular control over which portions of a dataset are accessible under different circumstances.

[0269] • Integration with identity management: TDEs may be tightly integrated with identity and access management systems, leveraging existing authentication mechanisms and user attributes for access decisions.

[0270] Distinction from Trusted Data Formats (TDF)

[0271] While Trusted Data Formats (TDF) focus primarily on securing data at rest or in motion using encryption and embedded static access control metadata, Trusted Data Envelopes (TDEs) as used herein are distinguished by their dynamic, policy-driven architecture and support for disconnected validation and lifecycle orchestration. Unlike TDFs, which tightly bind encrypted payloads and metadata for confidentiality, TDEs often operate in zero-trust workflows, where data may be referenced rather than embedded, and trust is derived through multi-party signatures and time-based cry ptographic primitives. Furthermore, TDEs are explicitly designed for use in digital thread orchestration, allowing access to be conditional on upstream or external validation events, making them suitable for secure, auditable automation across decentralized or air-gapped systems.

[0272] Fig. 8 shows an illustrative process flow where the Fyber platform processes third party access to data using Trusted Data Envelopes (TDEs), in accordance with one embodiment of the present invention. In particular, Fig. 8 illustrates tire handling of third party (e.g., client 810) access. In one embodiment, as shown in Fig. 9 under 940, ephemeral authenticated access of a client 810 to ASOT data 832 (also denoted "raw data"’, or simply “data”) located within an ASOT (i.e., trusted) network 830 is implemented within the Fyber platform using a trusted data envelope 834. Note that the terms “trusted data envelope (TDE)”, “trusted envelope (TE)”, “data envelope”, “trusted envelope”, “envelope" and their equivalents are used interchangeably herein.

[0273] In Fig. 8, tire implementation steps are indicated in order using circled numbers. As shown in Fig. 8, the implementation begins with updating the enclave 820 to manage ephemeral trust for read-only- access to model data intended for public sharing. This update allows the enclave 820 to process requests for public data access by:

[0274] 1. Receiving requests from clients (e.g., 810) for public data sharing.

[0275] 2. Securely relaying these requests to the agent (e.g., 836).

[0276] Following this, the agent 836 is updated to handle tire creation of a Trusted Data Envelope (TDE) 834. Trusted Envelopes are essentially Trusted Data Collections (TDCs) of Trusted Data Objects (TDOs) that can be accessed by any receiver compatible with, for example, the Trusted Data Format (TDF), a specification used for secure data tagging, encoding, and delivery. The agent's responsibilities include:

[0277] 1. Receiving encry ption requests for public data from the enclave 820.

[0278] 2. Encrypting, signing, and delivering the Trusted Envelope 834 to the client 810.

[0279] Finally, the client 810 is updated to manage the reception and decryption of the Trusted Envelope 834. ensuring that the data 832 can be securely displayed to the reader. This involves:

[0280] 1. Receiving the Trusted Envelope 834 from the agent 836.

[0281] 2. Decrypting and presenting the data 832 within a browser or command-line interface, ensuring secure delivery to the end-user.

[0282] In one embodiment, during each ASOT data 832 (e.g., digital artifact) access, a corresponding TDE (e.g., 834) will be cryptographically linked with the ASOT data 832 (e.g., artifact data or resource data) so as to be made available to the client 810. Such actions may be performed by the agent 836 in the ASOT data plane, within the ASOT network 830. This method prevents direct public access to the raw model data 832, thereby safeguarding the data's provenance. By utilizing Trusted Envelopes, the Fyber platform allows customers to distribute model data publicly without compromising on security, ensuring that even though the data becomes accessible, its integrity and the control over its content remain intact. This solution stands as a robust framework for secure, transparent data sharing in scenarios where authentication credentials are not available or applicable.

[0283] Exemplary Fyber Scenarios

[0284] Tire Fyber platfomr links generic information sources in ASOTs with their associated domain software tools for performing specific data operations. A special case is shown in Fig. 2 of PCT patent application No. PCT / US24 / 27898 (Docket No. IST-03.001PCT). showing an exemplary implementation of the IDMP as an interconnected digital engineering (DE) and certification ecosystem, and exemplary digitally certified products, in accordance with some embodiments of the present invention.

[0285] Fig. 9 shows an exemplary implementation of the Fyber platform and exemplary' platform scenarios, in accordance with some embodiments of the present invention. Fig. 2 of PCT patent application No. PCT / US24 / 27898 (Docket No. IST-03.001PCT) introduces the roles and interactions of the user 904. the user interface 906A, the API 906B, the computing and control system 908. the applications and services 922, the artificial intelligence engine 920, and the storage unit 918 within the Fyber platform.

[0286] Fyber can handle two major scenarios common in dealing with trusted sources: authenticated or ephemerally authenticated access. Fyber presents a versatile framework designed to secure and authenticate Authoritative Source of Truth (ASOT) data (i.e., trusted data from trusted data sources) across two distinct scenarios: secure authorized access 930 for confidentiality within organizations and networks, and ephemerally authenticated third-party access 940 for verifying data integrity in public-interest domains. Fig. 9 presents these two scenarios and how they are made possible to both human and computerized access through the Fyber platform’s GUI and API interfaces.

[0287] In the first scenario 930, Fyber is instrumental in protecting business-sensitive information within corporate networks, safeguarding data across various secure and authorized domains, and enabling confidential exchanges between specific entities. This ensures that access to sensitive information is tightly controlled and only available to individuals with the proper authorization, thereby preserving the integrity' and confidentiality' of the data within private and corporate environments.

[0288] In tire second scenario 940, Fyber supports the integrity of public-interest information by enabling ephemerally authenticated third parties, such as journalists, academic researchers, and election monitors, to verify ASOT data. Such an exemplary scenario involves tracking user access to a public-facing component of our system, rather than users logging in. Unlike conventional authentication systems that require users to present identification to gain access (as described in the first scenario), the Fyber platform assigns an authentication ID to users based on their interactions with the system if they do not provide one already. In this scenario, the Fyber platform may know some traits of those accessing the public-facing trusted sources, with a unique attribute of the scenario being that tire platform does not have to know these user traits. In some embodiments, enabling ephemerally authenticated access for third parties may include examples of enabling ephemerally authenticated access for third parties to trusted sources. This application is crucial for upholding journalistic standards, facilitating transparent academic and medical peer reviews, and ensuring accurate and reliable election reporting. By allowing for the secure verification of data by individuals or entities without direct access privileges, Fyber contributes to the transparency, reliability, and trustworthiness of information in the public sphere.

[0289] Fyber Platform Architectures

[0290] Fig. 10 shows an exemplary Fyber platform 1000 architecture, in accordance with some embodiments of the present invention. Tire architecture of Fig. 10 represents one embodiment of a functional platform architecture. Some embodiments showing the physical location of the platform's components are discussed in Figs. 15 and 16 below. The architecture of Fig. 10 shows a data source plane 1080, linked by the Fyber platform’s splice plane 1070, application plane 1060, and analysis / control plane 1050. In Fig. 10, identifiers (e.g., pointers, URIs, or URLs) for user- or organization-defined trusted sources (e.g., 1082, 1084, 1086, or 1088) may be stored in a trusted source database 1056 in the analysis / control plane 1050. The data sources (e.g., 1082, 1084, 1086, or 1088), located on tire data source plane 1080, are spliced and threaded using scripts in the application plane 1050. Their splices (e.g., 1071, 1072, or 1073). or "‘resource representations”, located on the splice plane 1070, provide access to the required digital artifacts, as well as each digital artifact’s associated metadata. In some exemplary' embodiments, the trusted source database 1056 can be accompanied by a trusted data storage database for digitally-signed trusted data that has been securely spliced from the data source plane 1080 by digital threads (e.g., 1062, or 1063) in the application plane 1050, and may be necessary for subsequent actions within a specific digital thread. For example, the trusted data storage database 1056 may include a digital artifact storage environment, as also shown in Fig. 14. As discussed in Fig. 22, digital threads (e.g.. 1062) may give rise to digital task workflows that are arranged as directed acyclic graphs (DAGs) (e.g., 1024) on the application plane 1050.

[0291] Scripts on the application plane may be used to: 1. generate and / or update resources (e.g., models, documents, etc.) located in the data source plane 1080 through the splicing plane 1070,

[0292] 2. generate and / or update generic sources (e.g., 1088) that are not spliced, or

[0293] 3. generate / update platform resources 1020 such as magic docs 1024, digital twins 1022, smart contracts 1026, simulation fdes 1028, digital documents 1030, collaboration boards 1032, or any live or static digital resource.

[0294] In a so-called Fyber feedback loop 1004, Feedback data 1026 emanating from the data sources of the data source plane 1080 may be directed to tire analysis / control plane 1050 (via splices) for analysis 1054. Resources 1020 on the platform may also generate feedback data 1026. Feedback data 1026, along with external expert feedback 1014, may be used to analyze 1054 and update the various data sources linked through the Fyber platform, where users 1002, agents, and external experts 1026 may provide their feedback and / or input via various user interfaces 1052.

[0295] The components described in Fig. 10 provide a conceptual overview and the related actions can be performed by specific technical architecture elements. For example, some actions of the Analysis / Control plane 1050 can be performed by the File Service within the platform enclave 1502; some actions of the application plane 1060 can be performed by job sendee within the platfonn enclave 1502, and the data source plane 1080 actions can be performed by the Agents within the customer environment 1510. In some embodiments, the splicing plane 1070 actions can be performed by the Agents within the platform exclave 1516 within the customer environment 1510.

[0296] Fig. 11 shows another exemplary' Fyber platfonn architecture, in accordance with some embodiments of the present invention. In particular, Fig. 11 shows an example of linking with trusted sources (e.g., 1182, 1184) where digital threads (e.g.. 1162, 1164) iterate and update according to source data, and vice versa.

[0297] As shown in Fig. 11, the Fyber platform 1100 aggregates diverse authoritative sources of tmth and presents human-readable documents to users to verify. Fig. 11 shows the conceptual view of the Fyber platfonn linking with generic digital artifacts (e.g., 1136) from multiple authoritative sources of truth (ASOTs) (e.g., 1130). The digital artifacts are linked in the digital artifact plane (analogously called the data source plane 1180 or the model plane in the IDMP). The digital artifacts can include generic digital artifacts such as text, data, images, code, audio, video, multimedia content, etc. in the artifact plane 1180. Tire data sources (e.g., 1 182, 1 184) are spliced in the splice plane 1 170 using applicable software tools so that the underlying artifact is available for further analysis and processing. The generated splices (e.g., 1171, 1172, 1173) arc linked into digital threads (e.g., 1162, 1163) in the application plane 1160. As discussed in Fig. 22, digital threads (e.g., 1162) may give rise to digital task workflows that are arranged as directed acyclic graphs (DAGs) (e.g., 1124) on the application plane 1160.

[0298] To make the various machine-readable digital artifacts accessible to human users, an accompanying magic document (e.g., 1128) can be linked to the digital thread (e.g., 1162, 1163). In some implementations, the secure digital thread linking tire various digital artifacts can also be presented as a smart contract (e.g., 1128) to a user, which once executed, can be digitally signed and presented as a central verification of certain business logic.

[0299] In the implementation example shown above, when the source data 1136 in tire ASOTs (e.g., 1130) are updated, then potentially an update of related magic documents (e.g., 1128) can be initiated through the analysis / control plane 1150. For example, a certification document created as a magic document 1128 may need an update if the underlying models (e.g.. 1182, 1184) connected through the digital thread (e.g., 1162, 1163) are updated, thus requiring a revised comparison 1152 against applicable requirements using a comparison engine, potentially represented by processed data 1144 emanating from external data bases 1142. In a so-called digital thread iteration loop 1104, simulation and performance data 1174 emanating from the data sources of the data source plane 1080 may be directed to the analysis / control plane 1150 (via splices, or any fonn of resource representation) for analysis 1154. Hie digital thread iteration loop 1104 also integrates digital twin ("DTw") perfonnance data 1126 emanating from digital twins (‘T)Tw”) 1122 operated within one or more virtual environments (“Metaverse”) 1120, as well as feedback from digital resources such as magic documents and / or smart contracts 1128.

[0300] When digital artifacts 1136 in the ASOTs 1130 are updated, there are potential mechanisms available to track and note that the artifact has been updated. An example could be the use of a knowledge graph 1138 or a citation history that accompanies an ASOT, and that tire Fyber platform can refer to in order to identify any digital artifacts that may have been updated. Another technical example of alerting mechanisms would be shaped like Webhook APIs that alert to changes in the underlying digital artifacts.

[0301] In a so-called ASOT update feedback loop 1102, processed data 1144 emanating from external databases 1142 may be combined with updates from ASOTs 1130, and may be directed to the analysis / control plane 1150 for comparison 1152 with feedback from the digital thread iteration loop 1104, and for analysis 1154. Based on tire analysis 1154, Fyber platform users or agents may take action 1106 by aggregating analysis data at the application plane 1160 where it is available to digital threads (e.g., 1162). or by creating / updating ASOT 1130 data (e.g.. by instantiating generic digital artifacts 1136).

[0302] Similarly, based on a review of the magic documents (e.g., 1128), carried out in the analysis / control plane 1150, external expert feedback 1114 may cause specific updates or actions initiated on the underlying models and digital artifacts. For example, a magic document presenting customer feedback analysis based on customer surveys may call out a specific source survey to be out-dated, prompting the providers of ASOT survey data corpus to initiate new surveys or the reader to look for more recent analyses. Across all these examples, Fyber does not serve as an ASOT but only as an aggregator of ASOTs providing guarantees that the source data is authentic and trusted by authorized users.

[0303] Trusted and Authoritative References and Sources

[0304] In Fig. 11, a user may label a data source as the current reference (e.g., design reference, data reference), herein described as the “trusted source”, the “authoritative source of truth”, or the “authoritative reference”. The authoritative reference may represent, for example, the design configuration that best responds to the actual conditions on tire ground (i.e., the ground truth).

[0305] In some embodiments, the Fyber platform manages a remote data source over a remote IT infrastructure, with access to local models, data, computational power, and select real-time sensor data. A user might also install an edge instance of the Fyber platform nearer their operations (e.g., at a factory) to optimize operations without the long-haul data routing penalties. Embodiments of tire Fyber platform may therefore be configured to run on (i) a remote IT platfonn only, with few effective compute / store / AI limitations, (ii) edge devices only, with more limitations on computational capabilities (e.g., Al), and (iii) on a hybrid remote + edge architecture, where multiple remote or edge instances presenting varying technical capabilities (e.g., computation, speed, or feedback capabilities) may be operated simultaneously. The Fyber platform provides configurable mechanisms (e.g., policies, algorithms, voting schema, statistical processes) whereby agents (e.g., users, platform modules) may designate a new data source as the authoritative or trusted reference.

[0306] Live (“Magic”) Digital Resources

[0307] The methods and systems described herein enable the updating and generation of digital resources (e.g., DE documents) using the frill functionality of the Fyber platform, as shown in Fig. 11. In Fig. 11, the digital thread iteration loop 1104 allows tire scripting of program code within a digital thread 1162 for the generation, storing, and updating of digital resources (e.g., documents) in the data source plane 1180 as well as on the Fyber platform (e.g., digital twins 1126). Tire digital thread iteration loop 1104 enables the creation and maintenance of so-called live digital resources 1128, also sometimes known as “magic” digital resources.

[0308] Live digital resources are more akin to a digital twin than a conventional static data source in that they arc configured, through a digital thread, to be continuously updated to reflect the most current changes within a given resource. In particular, an authoritative / trusted live digital resource is configured to reflect the latest authoritative data.

[0309] Specifically, live digital resources are digital resources 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 resources within a predetennined delay. In various embodiments, the updates are effectively real-time or near real-time.

[0310] Live digital resources 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.

[0311] Live digital resources 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.

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

[0313] Live digital resources may be stored and accessed through a Fyber platform. Specifically, live digital resources 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.

[0314] Live digital resources may hence be known as magic resources (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 trusted data source may appear instantaneously within the relevant data fields of tire live digital resources. Similarly, authoritative / trusted live digital resources may also be known as authoritative / trusted magic resources as they continuously reflect data from the authoritative twin, thus always representing the authoritative source of truth. Given the massive quantities of data and potential modifications that are carried out during a product's lifecycle, the scripts implementing / maintaining live digital resources may be configured to allow for a predefined maximum delay between the modification of a data source and tire execution of the corresponding changes within a live digital resource. Moreover, for similar reasons, the scripts implementing / maintaining live digital resources may be restricted to operate over a specified subset of data sources, thus reflecting changes only to key parameters and configurations.

[0315] The "printing" of a live digital resource, document, or board corresponds to the generation of a frozen (i.e., static) time-stamped version of a live digital resource, document, or board. Therefore, “printing” - for a live digital resource, 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.

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

[0317] In another embodiment of the present invention, a Fyber script may instantiate (i .e ., "print") a live digital resource specifying an updated data source upon detecting the update. In such an embodiment, the Fyber script may detect a modification of a model or an associated digital thread. In response to detecting the modification, the Fyber script may update relevant data fields and / or sections of the live digital resource based on the detected modification, and generate an updated instance (e g., printed document) with the updated relevant data fields and / or sections based on the always-updated live digital resource.

[0318] In some embodiments, receiving user interactions with a model, modifications to a 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 Fyber script immediately or within a specified maximum time delay. In other embodiments, receiving user interactions with a model, modifications of a 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 Fyber script queries relevant models (via their model splices) or associated digital threads, for flagged modification. In these embodiments, the Fyber script may extract the modified infomiation from the modified models (via their model splices) or the modified digital threads, to update a live document or digital resource. In yet other embodiments, receiving user interactions with a model, modifications of a model, or modifications of an associated digital thread, may be carried out through a pull configuration, where the Fyber script regularly checks relevant models (via their model splices) or associated digital threads, for modified data fields, by comparing the data found in the live document with regularly extracted model and digital thread data. In these embodiments, the Fyber script may use the modified data to update the live document or digital resource.

[0319] Dynamic Document Updates

[0320] 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 Fyber platfonn and tire accompanying documentation.

[0321] 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 model platform interacts dynamically with the user. As the user interacts with the system and updates data for a model or a specific parameter setting, these changes may be propagated through the corresponding digital threads and to the associated documentation. Tire Al architectures involved include locally-instanced large language model (LLMs. for data security reasons) as well as non-LLM approaches (e.g., NLP-based), in order to create, update, or predict documentation in the form of sentences, paragraphs, and whole documents. At the same time, trying to update the entire system of digital threads for every update may be prohibitively slow and may present security risks to the system. Generating live documents and live digital resources that are updated based on a subset of a system’s models and within a maximum time delay may therefore be more efficient.

[0322] System-Level Architectural Embodiments of Fyber

[0323] Fig. 12 shows exemplary Fyber system -level architectures, in accordance with some embodiments of the present invention.

[0324] Tire systems and methods disclosed herein relate to the decentralized digital threading of trusted data sources, using a platform referred to herein as Fyber. Fyber is designed to enable secure, scalable, and partition-tolerant data workflows across heterogeneous control and data environments. The system leverages cryptographically verifiable constructs referred to as Trusted Data Envelopes (TDEs), decentralized metadata governance, and time as a cryptographic primitive to enforce policy-constrained data access in both connected and disconnected domains. Fig. 12 specifically shows exemplary' embodiments for multi -control plane cooperation across networks. Exemplary Embodiment 1 : Single Control Plane / Single Data Plane

[0325] In this exemplary embodiment 1202, the platform is deployed in a unified network environment comprising a single control plane 1206 and a single data plane 1204. The control plane governs all metadata issuance, access policy enforcement, and artifact retrieval processes, while the data plane stores or processes the associated digital artifacts. Trusted Data Envelopes (TDEs) are employed to encapsulate access rules, metadata, and cryptographic integrity markers, even though all validation occurs within a centrally managed trust boundary. Temporal constraints may be enforced using synchronized system clocks.

[0326] This configuration is suitable for enterprise deployments with full-stack ownership and low network latency, where centralized governance is acceptable.

[0327] Exemplary Embodiment 2: Single Control Plane / Multiple Data Planes

[0328] In this embodiment 1214, Fyber is configured such that a single control plane 1210 governs two or more logically or geographically distributed data planes (1208 and 1212). Each data plane may independently store artifacts, but policy orchestration and digital thread governance are centralized. Trusted Data Envelopes issued by the control plane encapsulate data pointers, cryptographic hashes, decentralized metadata, and time-bounded access constraints.

[0329] Digital threads are orchestrated across the data planes using dependency-aware execution, preventing race conditions or premature access. Temporal access enforcement can proceed even in semi-connected environments through the inclusion of timestamp-based validity fields in each TDE.

[0330] This embodiment is well-suited to hybrid cloud environments, enterprise subdivisions, or distributed manufacturing systems requiring centralized policy and federated enforcement.

[0331] Exemplary Embodiment 3: Multiple Control Planes / Interoperable Data Planes

[0332] In this embodiment 1216, multiple independent control planes (e g., 1218, 1220) manage their respective data planes (e.g., 1222, 1224), but interoperability is enabled within a unified classification domain 1226 (alternatively “domain” or “network” or “infosec network”) through shared schemas, metadata standards, and TDE formats. Each domain, or network, retains autonomy over its governance, yet can issue and accept TDEs from trusted federated peers. Metadata included in the TDEs encodes domain-specific policies, issuance authorities, and expiration criteria.

[0333] Policy enforcement is achieved through consistency -driven validation, wherein each domain independently verifies the structural and cryptographic validity of the TDEs without requiring a global source of truth. Time is used as a bounded access primitive, enabling each domain to enforce local revocation or expiration. This embodiment is suited for inter-agency collaborations, multinational industrial consortia, or data mesh architectures wherein autonomous domains require secure, interoperable access mechanisms.

[0334] Exemplary Embodiment 4: Multiple Control Planes / Isolated Data Planes

[0335] In the most partition-tolerant and secure embodiment 1236, each control plane (e.g., 1230, or 1238) and its associated data plane (e.g., 1232. or 1240) are isolated within separate network or classification domains (e.g., 1228, or 1234). There exists no direct interconnectivity between control planes or data stores. Fyber enables secure coordination across these domains via metadata synchronization and boundary enforcement using TDEs.

[0336] Each TDE in this embodiment includes cryptographically bound metadata, access conditions, and three independent digital signatures: one from the data issuer, one from the intended recipient, and one from a timestamp authority. Timestamps function as cryptographically anchored expiration markers that do not require clock synchronization between domains. Validation can occur asynchronously, and updates may be propagated through physical transfer, snapshot replication, or boundary gateway services.

[0337] This embodiment is applicable to air-gapped military systems, nuclear certification environments, and cross-domain security contexts where zero trust and zero knowledge principles are paramount.

[0338] Subsystem Mechanisms and Technical Innovations

[0339] Various Fyber embodiments include specific technical components that work to deliver distributed digital threading with trusted data sources. The following technical details describe exemplary implementations of these components, including Trusted Data Envelopes (TDEs) for encapsulating cryptographically verifiable metadata and access policies, time as a cryptographic primitive to enable decentralized temporal enforcement, consistency-based metadata governance across autonomous domains, orchestration of dependency-aware digital threads, partition-tolerant synchronization methods for disconnected operation, and a three-party signature fabric for decentralized trust validation. These subsystems collectively enable secure, scalable, and auditable workflows in both connected and air-gapped environments.

[0340] Trusted Data Envelope (TDE)

[0341] Each Trusted Data Envelope (TDE) comprises a cryptographically verifiable structure that encapsulates access policies, metadata, and references to an associated data artifact. A TDE may be implemented, for example, as a structured JSON or binary-encoded object containing:

[0342] • A data_pointer field indicating the network or file location of the target artifact; • A data_hash field comprising a cryptographic digest (e.g., SHA-256) of the data payload to ensure immutability;

[0343] • A metadata block containing information such as issuer identity, subject ID, timestamps, and permitted operations;

[0344] • One or more digital signatures validating the envelope’s integrity and provenance.

[0345] In one embodiment, the TDE may appear as follows (in JSON-like pseudocode): {

[0346] "data_pointer" : "https : / / example . com / artifact / 12345" , "data_hash" : " abcl23 . . . def" , "metadata" : { " issuer" : " trusted- journal . org" , " subject" : " dataset-42" , "Additional" : [public , unclassified] , "valid_until" : " 2025-05-06T12 : 00 : OOZ" } , " signatures" : [

[0347] " sig_issuer" , " sig_recipient" , " sig_timestamp" ] }

[0348] Note that the hash field in a TDE, alternatively termed “data hash” and “data hash”, may include a hash of the entire data content of a data source, a subset of its resource data, or the subset of the resource data that is located within the digital artifact with which the TDE is associated (i.e., the “artifact data”).

[0349] TDEs may therefore be verified independently of the control plane, enabling decentralized and policy-constrained access even in partitioned environments.

[0350] Time as a Cryptographic Primitive

[0351] Fyber utilizes time as a non-reversible, entropy-driven cryptographic primitive rather than as a passive synchronization mechanism. In exemplary embodiments, timestamp values are derived from physical entropy sources such as quartz harmonic oscillators or atomic clock drift sequences, and then digitally signed by a Timestamp Authority (TSA). Each TDE includes a valid until or equivalent field, which encodes the expiration condition of the envelope. This enables enforcement of access policies based solely on locally verifiable time information, without requiring real-time synchronization.

[0352] Tire TSA may be implemented using a hardware security module (HSM) or an air-gapped oracle that signs timestamp assertions in the format:

[0353] {

[0354] "timestamp" : " 2025-05-06T12 : 00 : 00Z" ,

[0355] "entropy_source" : "oscillator_id_07" ,

[0356] "signature" : " sig tsa"

[0357] }

[0358] This construction allows for policy revocation and temporal scoping of access, even in environments with no external connectivity.

[0359] Consistency-Driven Metadata Governance

[0360] Fyber permits decentralized metadata authorities to issue assertions without global correctness enforcement. Validation is performed based on structural consistency, trust anchors, and schema compliance, rather than on centralized adjudication.

[0361] In one embodiment, metadata may conform to domain-specific formats, such as:

[0362] • OpenTDF for defense or classified networks;

[0363] • JSON Web Tokens (JWTs) in commercial contexts;

[0364] • SAML assertions for federated identity systems.

[0365] An exemplary JWT-based metadata payload may include:

[0366] {

[0367] "iss" : "medical- journal . org" ,

[0368] "sub" : " clinical-trial-123" ,

[0369] "exp" : 1746456000

[0370] }

[0371] Schemas may be published via registries, referenced by URI, or hardcoded into policy engines. Fyber nodes enforce agreement on metadata structure and source, enabling access decisions that are partition-tolerant but structurally verifiable. Digital Thread Orchestration via TDEs

[0372] Digital threads in Fyber are composed of chained or recursive sequences of TDEs, each referencing a data artifact and defining its dependencies, conditions, and validation context.

[0373] In one embodiment, digital threads are represented as a directed acyclic graph (DAG) where each node corresponds to a TDE and each edge defines a dependency (e.g., simulation depends on validated CAD model). Access to a node is contingent on successful validation of all upstream nodes.

[0374] TDEs may be mutually dependent in the sense that their associated artifacts / models are mutually dependent. For example, in a simulation scenario, there camrot be a simulation result without a verified design spec and a verified simulation input.

[0375] Execution therefore proceeds deterministically by validating TDEs in dependency order, for example:

[0376] 1. Verify TDE l (design spec)

[0377] 2. Verify TDE 2 (simulation input) depends on TDE l

[0378] 3. Unlock (appro ve / authorize / confirm) TDE 3 (simulation results) only if prior validations pass

[0379] In the example above, the verification of unlocking of TDE 3 signifies that TDE 3 and its associated digital artifact (i.e., the simulation result) is only accessible once TDE l and TDE 2 are both verified. Accordingly, a “child” TDE may cany; within its metadata, dependence on one or more “parent” TDEs.

[0380] Such sequencing prevents race conditions and ensures reproducibility across multi-stage workflows.

[0381] Partition-Tolerant Synchronization and Logging

[0382] Fyber supports operation in disconnected environments through asynchronous and append-only mechanisms, including:

[0383] • Immutable logging: Updates are written to append-only logs (e.g., hash-linked chains or Merkle trees) that resist tampering and support auditability.

[0384] • Asynchronous polling: Nodes (control planes or data plane agents) periodically query for policy or metadata updates rather than relying on push-based communication.

[0385] • Snapshot propagation: Policy and metadata updates may be exported and imported using signed packages or offline transfer media. In one embodiment, a node checks for updates every N minutes and applies diffs validated by cryptographic signatures and timestamp authorities. Conflicts are resolved based on domain-specific priority rules encoded in the metadata (e.g., later signatures supersede earlier ones if from the same issuer).

[0386] Three-Partv Signature Fabric

[0387] To prevent unilateral or collusive access grants, each sensitive TDE is cryptographically co-signed by three independent authorities:

[0388] 1. Issuer: Tire original source of the data artifact (e.g., research journal, CAD provider);

[0389] 2. Recipient: Tire intended data consumer (e.g., analyst, reviewer);

[0390] 3. Timestamp Authority (TSA): A domain-trusted service that certifies the validity interval.

[0391] The three signatures may be validated in any order but must all be present and verifiable using known public keys. In one implementation, the signature chain is as follows:

[0392] 1. Issuer signs the TDE over { data_hash , metadata }

[0393] 2. Recipient signs over the issuer’s signature and subject reference

[0394] 3. TSA signs over { issuer_sig, recipient t_sig, timestamp}

[0395] This process produces a cryptographically enforceable access token whose authority derives from multi-party agreement, thereby mitigating tire risk of unilateral privilege assertion or rollback attacks.

[0396] Advantages Over Related Art

[0397] The system and methods described herein offer multiple technical advantages over existing solutions for distributed data access control, metadata governance, and secure workflow orchestration. In contrast to prior approaches, Fyber introduces a novel integration of cryptographically enforced access envelopes, decentralized metadata validation, and partition-tolerant synchronization mechanisms to enable secure digital threading in both connected and disconnected environments.

[0398] Trusted Data Envelopes (TDEs)

[0399] Unlike traditional access control tokens such as JSON Web Tokens (JWTs) or SAML assertions, which rely on centralized identity providers and lack direct coupling to data artifacts, TDEs bind cryptographic hashes of data artifacts with access metadata and multi-party digital signatures. TDEs function as ephemeral, self-validating trust carriers that allow for autonomous verification, enabling secure access even in zero-trust or air-gapped domains. Time as a Cryptographic Primitive

[0400] Co ventional systems use synchronized clocks or time servers for session management or revocation. Fyber departs from this model by treating time itself as a cryptographic primitive derived from entropy sources such as physical oscillators. Uris innovation enables enforcement of time-bound access without requiring continuous connectivity or consensus on current time, making it particularly suitable for disconnected or classified network environments.

[0401] Decentralized Metadata Governance

[0402] While blockchain systems or distributed ledgers offer global consensus on transaction history, they suffer from performance overhead and often require full-network validation. Fyber instead implements a consistency-based metadata model, in which domains independently validate structural and cryptographic integrity of metadata using domain-trusted authorities and schema registries. This enables high scalability and local autonomy without compromising verifiability.

[0403] Digital Thread Orchestration

[0404] Conventional version control systems (e.g.. Git) or event stream processors (e.g., Apache Kafka) support data lineage or message tracking but do not natively enforce access dependencies or cryptographic validation of access policies. Fyber constructs digital threads using dependency -aware sequences of TDEs, each enforcing access conditions recursively. This ensures that data workflows comply with integrity, authorization, and timing constraints across multi-party, multi-stage pipelines.

[0405] Partition-Tolerant Synchronization

[0406] Most access control frameworks assume real-time connectivity and fail to support asynchronous or out-of-band policy propagation. Fyber introduces append-only logging, offline snapshot transfers, and polling-based update models to allow consistent policy synchronization across disconnected systems. This enables secure cooperation in degraded network conditions and supports compliance with air-gap security policies.

[0407] Three-Party Signature Fabric

[0408] Conventional systems rely on bilateral trust models (e.g., issuer and recipient) which can be vulnerable to collusion or privilege escalation. Fyber introduces a mandatory three-party signature mechanism — including the data issuer, the recipient, and a timestamp authority — which ensures that access privileges cannot be asserted or modified unilaterally. This enforces a cryptographically verifiable consensus model suitable for high-assurance environments.

[0409] Comparison Summary

[0410] Table 1. Comparison Summary

[0411] Accordingly, Fyber provides a comprehensive platform that addresses the limitations of the prior art while enabling new use cases for decentralized, time-bound, and policy-constrained digital threading across both connected and isolated environments.

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

[0413] Fig. 13 is an exemplary flow chart showing a process for generating and executing a digital thread script extracting data from a trusted data source within a Fyber platform, in accordance with some embodiments of the present invention.

[0414] At step 1310, a resource identifier pointing to a data source identified as a trusted data source is received. The data source is located in a first security environment that is external to the Fyber platform.

[0415] At step 1320, resource data is extracted from the data source to generate a data artifact, where the artifact data is based on the resource data, and where the artifact metadata includes the resource identifier. In some embodiments, a trusted data envelope is generated for the data artifact at this step, the trusted data envelope including a time-stamp for extraction (validated by a TSA), metadata for lineage to data source and a cryptographic hash of the artifact data.

[0416] At step 1330, tire digital artifact is stored in a digital artifact storage environment accessible by the Fyber platform.

[0417] At step 1340, a function script that enables external access to the digital artifact through addressable Application Programming Interface (API) or Software Development Kit (SDK) endpoints is generated. The addressable API or SDK endpoints enable access to the digital artifact without access to the entire data source.

[0418] At step 1350, a resource representation of the data source that is accessible to third-party applications and users via the addressable API or SDK endpoints is generated. The resource representation includes the function script and enables access to a selective portion of the digital artifact.

[0419] At step 1360, a trusted data envelope that enables access to the digital artifact from a second security environment that is distinct from the first security environment of the data source is generated, where the access to the selective portion of tire digital artifact requires the verification of the trusted data envelope. In some embodiments, a trusted data envelope previously generated at the time of extraction of the digital artifact data in 1320 is sent, and access to the selective portion of the digital artifact requires the verification of the trusted data envelope.

[0420] At step 1370. a digital thread script that generates a live digital resource in the second security environment is generated. In some embodiments, the digital thread script is configured to generate the live digital resource on a secure database, accessible by the Fyber platform. In various embodiments, the digital thread script that generates tire live digital resource is created and stored in a secure database, accessible by the Fyber platform, or within a Fyber agent at the second security environment. The live digital resource is configured to access the digital artifact by invoking the resource representation using the API or SDK endpoints. In some embodiments, the second security environment is external to the Fyber platform.

[0421] At step 1380, the digital thread script is executed on the Fyber platform to generate the live digital resource, where a notification of a modification of the data source appears in the live digital resource within a predetermined delay.

[0422] 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 a Fyber platform, in accordance with some embodiments of tire 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 a 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.

[0423] Tire system may include access to at least one hardware processor 1494 responsible for executing program code 1492 to implement the modules 1470 described below. Tire system may include access to at least one non-transitory physical storage medium 1490, accessible by the at least one hardware processor 1494, which stores tire 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.

[0424] 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 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, sample digital artifacts, and / or sample resource representations.

[0425] At run time, the user may provide a resource identifier 1406 pointing to a data source 1408 as a trusted data source (“Trusted Data Source A”), 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.

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

[0427] The Fyber platform application 1460 may then extract resource data 1420 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 dotted 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 platform.

[0428] 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 dotted 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. The Fyber platform 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 may include the function script 1430 and may enable access to a selective portion of the digital artifact 1422.

[0429] 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, the “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.

[0430] The Fyber platform application 1460 may then generate a digital thread script 1452 that generates a live digital resource 1454 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 the digital thread script 1452 and artifact data displayed in the live digital resource 1454.

[0431] Finally, the Fyber platform 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.

[0432] In Fig. 14, the locks displayed over artifact data in both tire digital artifact 1422 and tire 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.

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

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

[0435] Tire Fyber architecture 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 (AutlrN) and authorization (AuthZ) systems designed to enforce secure access to and control over resources within the system.

[0436] Fig. 15 shows an exemplar) implementation illustrating the platform’s offered services and features using multi-tenant enclaves, in accordance with some embodiments of the present invention. In particular, Fig. 15 shows an architecture of multi-tenancy enclaves that allows secure digital thread orchestration. For each enclave, the identity sendee 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 permission service, to access the different tenants and perform the requested tasks.

[0437] Specifically, an exemplary implementation architecture diagram 1500 is shown in Fig. 15 to include multiple illustrative components: a Fyber platform enclave 1502, cloud services 1504, and a customer environment 1510 which optionally includes a Fyber platform exclave 1516. This exemplar)' architecture 1500 for the Fyber platform is designed in accordance with zero-trust security principles and is further designed to support scalability as well as robust and resilient operations. Fyber platform enclave 1502 and Fyber platform exclave 1516 together instantiate Fyber platform 1100 shown in Fig. 11, with Fyber platform exclave 1516 implementing model splicing and splice plane 1170 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 Fyber platform, to perform work for individual customers. Examples of exclaves include virtual machines (VMs) and / or servers that the Fyber platform maintains to run tools for customers who need such services.

[0438] In particular, Fyber platform enclave or platform enclave 1502 may serve as a starting point for services rendered by the Fyber platform, and may be visualized as a central command and control hub responsible for the management and orchestration of all platform operations. For example, enclave 1502 may be implemented using computer system 908 of the interconnected ecosystem shown in Fig. 9. platform enclave 1502 is designed to integrate both zero-trust security models and hypcrscalc 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 1502 also supports an ML engine such as 920 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 1502 may also include one or more of the features described below.

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

[0440] Fyber platform enclave 1502 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 1502 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 1506 (e.g., users 904). Additionally, enclave 1502 is designed with decoupled resource sets, minimizing interdependencies and thereby promoting system efficiency and autonomy.

[0441] Fyber platform enclave 1502 can further be designed for scalability and adaptability, aligning well with varying operational requirements. For example, the enclave 1502 can incorporate hyperscale-like properties along with zero-trust principles to enable scalable growth and to handle high-performance workloads effectively.

[0442] Fyber platform enclave 1502 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 1500’s adaptability makes it highly versatile for a multitude of use-cases, while ensuring consistent performance and robust security.

[0443] Fyber platform enclave 1502 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 920) capable of performing real-time analytics. This enhances decision-making and operational efficiency across platform 1500. Auto-scaling mechanisms can also be included to enable dynamic resource allocation based on workload demand, further adding to tire platform’s responsiveness and efficiency.

[0444] In the exemplary embodiment shown in Fig. 15, Fyber platform enclave 1502 includes several components as described in further detail herein.

[0445] 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 1500 to ensure good service deliver}’, 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 platform 1500, 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 1500, and instrumental in tire functioning of platform 1500. A“Static Assets Service Cell,” provides “Statics Service”, and may house user interface, SDKs, command line interface (CLI), and documentation for platform 1500. An “API Gateway Service Cell” provides “API Gateway Service,” and may provide platfonn API(s) and act as a mediator for requests between the client applications and the platform services. In some embodiments, the API gateway service cell may receive and respond to requests from agents such as platfonn exclave 1516 to provide splice functions for model splicing purposes.

[0446] As shown in Fig. 15, the architecture of platfonn 1500 may also include a cloud services 1504 that provide services which cannot interact with customer data but can modify tire 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 1500 shown in Fig. 15, cloud services 1504 includes a “Customer Identity and Access Management (IAM) Service” that ensures secure and controlled access to platform 1500. Cloud services 1504 also includes a “Test Service” that tests tools to validate platform operations. Cloud services 1504 may also include an “Orchestration Service” that controls and manages the lifecycle of containers on the platform 1500. Cloud services 1504 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.

[0447] As shown in Fig. 15, the architecture of platform 1500 may also include a customer environment 1510 with an “Authoritative Source of Truth” 1512, customer tools 1514, and an optional platform exclave 1516. Customer environment 1510 is where customer data resides and is processed in a zero-trust manner by platform 1500. As described previously, platform enclave 1502, 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 1516 may be situated within customer environment 1510 to assist the customer(s) 1506 with their tasks and operations, including model splicing and digital threading.

[0448] When a customer 1506 (e.g., user 904) intends to perform a task using platform 1500 (e.g.. Fyber platform), 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 1510, and platform 1500 may provide tools to access the metadata of the derivative data. Here metadata refers to data that can be viewed without opening tire original data, and may comprise versioning infonnation, 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 1510 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 1510. 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 1510 while adhering to zero-trust security protocols. Example implementations may also include tokenization utility, in which a specialized platfonn tool referred to as a “tokenizer” is deployed within customer environment 1510 for secure management of derivative metadata, conforming to zero-trust guidelines.

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

[0450] Customer environment 1510 may also include additional software tools such as customer tools 1514 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 1102). A ‘'Platform Agent” ensures smooth communication and management between customer environment 1510 and elements of platform 1500. 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. Fyber platfonn functions call upon native tools that are executed within customer environment 1510, 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.

[0451] In some cases, an optional “Fyber Platform Exclave” or “Fyber Exclave” 1516 may be employed within customer environment 1510 to assist with customer tasks and operations, supervise data processing, and rigorously adhering to zero-trust principles while delivering hyperscale-like platfonn perfonnance. Fyber platfomr exclave 1516 is maintained by the Fyber platfonn to run tools for customers who need such services. Fyber platform exclave 1516 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. Fyber platform exclave 1516 utilities and manages proprietary tools hosted with customer environment 1510, for example, to implement model splicing and digital threading functionalities.

[0452] 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 Fyber platform (see Fig. 16) and the availability of training data. In an example, a pre-trained ML or Al model (e.g., within the Fyber platform enclave 1502) 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 Fyber platform exclave 1516). 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 Fyber platform enclave.

[0453] Identity service and Permission service Fig. 15 shows an example architecture of Fyber, which includes the addition of an Identity service and Permission service to the Fyber platform, 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. 15 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 tire permission service.

[0454] Authentication is achieved through OpenlD Connect protocols, with Zitadel serving as an exemplary7identity service to verify tire 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 with established security policies.

[0455] The 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 tire risk of unauthorized access and data breaches. Hie 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.

[0456] 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 service for the requested operation.

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

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

[0459] In summary, secure digital thread execution with generic ASOTs (Fyber) must have ZT security for auditability; ZK orchestration can be done optionally. Tire 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, the 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.

[0460] Fyber Deployment Scenarios

[0461] Fig. 16 shows potential scenarios for instantiating the platform in connection to a customer's physical system and IT environment, in accordance with some embodiments of the present invention. Specifically, Fig. 16 illustrates various potential configurations for instancing or instantiating an IDMP (“Fyber platform") 1602 in connection to a customer's IT environment and physical system 1604. 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, the platform 1602 may be instanced as an enclave such as 1502 shown in Fig. 15. For example, the platform 1602 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:

[0462] 1. External Platform Instance 1610: This option showcases the platfonn 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.

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

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

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

[0466] 5. Direct API Connection 1650: This deployment scenario shows the 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.

[0467] 6. Air-Gapped Platform Instance 1660: This scenario illustrates tire platform being completely instanced on an air-gapped, or isolated, physical system as a Fyber 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.

[0468] Across these deployment scenarios, the platform plays an important role in bridging the gap between digital artifacts established through the platform and their data sources. Regardless of how the platform is instantiated, it interacts with the physical system, directly or through the customer's virtual environment. The use of edge computing instances in some scenarios demonstrates tire 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 Fyber platform may face latency issues or network connectivity issues (interruption in connectivity indicated bylightning symbols 1632 and 1642). 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 Fyber platfomi edge instance may also be deployed with progressive enhancement of functionality to manage network connectivity issues. In some cases, air-gapped deployment nodes 1660 and edge instances 1640 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 platform state and synchronize, mitigating latency impacts. Across these scenarios, the nodes for the Fyber agents perform similarly. Consistent with security requirements, these agent nodes operate in ping mode, not push mode. When edge instances come back online, 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 tire importance of interoperability in facilitating efficient data exchange. In all cases, the Fyber platform operates with robust security measures.

[0469] In some embodiments, the platform deployment for tire 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 Fyber platform (scenario 5), while other physical systems may have an edge instance connection (scenario 4).

[0470] Multimodal User Interfaces

[0471] Fig. 17 illustrates the use of multimodal user interfaces 1790 for the interconnected Fyber 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, feedback data 1726 is processed in tire Analysis & Control Plane (ACP) 1750. Hie user interface may receive user inputs 1702 and external expert feedback 1714. The analysis module 1754 processes inputs to update a user’s data sources in a trusted source database 1756 of ACP 1750.

[0472] The multimodal interfaces illustrated in Fig. 17 are configured to carry out all the tasks and actions described in the context of Fig. 11, 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 1794, a workflow-based interface 1796, conversational interfaces 1798, spatial computer interfaces 1792, and code interfaces 1799.

[0473] Dashboard-style interface 1794 offers a customizable overview of data visualizations, perfonnance 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.

[0474] Workflow -based interface 1796 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 or mobile app. In tire context of alternative tool selection, workflow-based interface 1796 may provide options on individual tools at each stage, or provide combinations of tool selections through various stages to achieve better accuracy or efficiency for the overall workflow.

[0475] Conversational interfaces 1798 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 Fyber platfonn workflow. Outputs from the Fyber platfonn may undergo the reverse process. This enables interoperability with the Fyber platform, and specifically the manipulation of model splices. In tire broad context of audio-visual inputs, the conversational interfaces may comprise data sonification, 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 useful when individuals need to process information quickly without having to visually focus on a screen. For example, sonified alerts can be used to notify security analysts of potential threats or breaches.

[0476] Fig. 17 also illustrates the use of spatial computing interfaces 1792 and code interfaces 1799 in the management of data sources. Spatial computing interfaces allow for more immersive and intuitive user experiences, and enable real-time synchronization between data sources and digital artifacts. Code interfaces allow bots and users to interact with tire Fyber platform through scripting and code. It also allows the collection of user preference, task history, and tool usage patterns for alternative tool selection purposes.

[0477] Digital Threads and Autonomous Data Linkages

[0478] As discussed previously, a “digital thread’" is intended to connect two or more data sources or models for traceability, and collaboration and sharing among individuals perfonning 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.

[0479] Fig. 18 describes the architecture and inherent complexity of digital threads, in accordance with the examples disclosed herein. Specifically, Fig. 18 is a schematic diagram comparing exemplary digital threads 1800 of various complexities that manipulate and / or connect data sources (e.g., models), in accordance with some embodiments of the present invention. In the most basic sense, a digital thread may “thread” together models into a simple daisy-chain architecture 1802 where modifications in any upstream model will affect all models downstream from the modified model. For example, a modification of any parameter or process of a model B will cause changes in model C, which in turn will cause changes in model D. Cause-and-effect changes will therefore cascade downstream. As another example, diagram 1804 represents a more complex digital thread where a change in one model may affect more than one downstream model. In both 1802 and 1804, digital threads are represented by a directed acyclic graph (DAG).

[0480] DAGs are frequently used in many kinds of data processing and structuring tasks, such as scheduling tasks, data compression algorithms, and more. In tire 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 1804, 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.

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

[0482] Fig. 18 further shows special cases 1803, 1805, 1807, 1808, and 1809 of exemplary simple digital threads. Diagram 1807 represents a degenerate digital thread where data is shared from a single model. Diagram 1808 represents a model-to-document digital thread where data (e.g., system attributes, perfonnance attributes) extracted from a single model may be used to generate or update a text-based document (e.g., a Capability Development Document (CDD)). Diagrams 1803 and 1805 are generalized from 1808 to represent cases where data extracted from a single model may be used to update multiple models, or vice versa. Specifically, diagram 1805 may represent the dynamic updates of live or magic documents discussed in the context of Fig. 11. Here, the logic to connect the models shown is clear: data are extracted from multiple models A, B, and C to update a document model D. There are no interactions between the extracted data. Furthermore, diagram 1809 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. 19 next, input splice functions of the model A shown in 1809 may be executed to update the model, and output splice functions of model A shown in 1809 may be executed to produce digital artifacts for sharing. For these special simple threads, the platfomi may provide a GUI-based interface to tire user to connect the models and execute the digital threads. For complex threads like 1806, a code-based interface may be necessary.

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

[0484] As disclosed herein, model splicing encapsulates and compartmentalizes model data and model data manipulation and access functionalities. As such, model splices provide access to selective model data within a model file without exposing the entire model file, with access control to the encapsulated model data based on user access permissions. Model splicing also provides the model with a common, extemally-accessible Application Programming Interface (API) for the programmatic execution of models. Model splices thus generated may be shared, executed, revised, or further spliced independently of the native tool and development platform used to generate the input digital model. Tire standardization of model data and the generalization of API interfaces and functions allow the access of model type files outside of their native software environments, and enable the linking of different model type files that may not previously be interoperable. Model splicing further enables the scripting and codification of operations encompassing disparate 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 models through various tools across different stages of a digital process, workflow, a product life cycle, etc.

[0485] Digital threads are created through user-directed and / or autonomous linking of model splices. A digital thread is intended to connect two or more models for traceability, collaboration, and sharing among individuals performing 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 models and tools enables the scaling and generalization of digital threads.

[0486] 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 model files into executable splices that can be autonomously and securely linked, thus enabling the management of a large number of models as a unified digital thread. Such a capability extends to link previously non-interoperable models to create digital threads, receive external performance and sensor data streams (e.g., data that is aggregated from models) and receive expert feedback that provides opportunity to refine simulations and model parameters. Exemplary Model Splicing Setup

[0487] Fig. 19 is a schematic showing an exemplary splicing setup, according to some embodiments of the present invention. Specifically, Fig. 19 is a schematic showing an embedded CAD model splicing example. In Fig. 19, model splicing as applied in digital engineering is presented as an example of data source splicing.

[0488] 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 the fonn of a digital file or a group of digital files. A locator refers to links, addresses, pointers, indexes, access keys. Unifonn Resource Locators (URL) or similar references to the aforementioned DE digital artifacts and splice functions, which themselves may be stored in access-controlled databases, cloud-based storage buckets, or other types of secure storage environments. The splice functions provide unified and standardized input and output API or SDK endpoints for accessing and manipulating the DE model data. The DE model data are model-typc-spccific. 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.

[0489] 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 perfonn 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.

[0490] Thus, a DE model type-specific model splicer extracts or derives model data from a DE model file and / or stores such model data in a model type-specific data structure. A DE model splicer further generates or enumerates splice functions that may call upon native DE tools and API functions for application on DE model data. A DE model splice for a given user application contains or wraps DE model data and splice functions that are specific to tire 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.

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

[0492] In the CAD model splicing example shown in Fig. 19, a CAD model file diesel-engine. prt 1904 proceeds through a model splicing process 1910 that comprises a data extraction step 1920 and a splice function generation step 1930. This input DE model 1904 is in a file format (.prt) native to certain DE tools. Data extraction may be performed via a DE model crawling agent implemented as model crawling scripts within a model splicer to crawl through the input DE model file and to distill model data with metadata 1922. 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 1906. 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 determines how model data may be organized and accessed, as fundamentally defined by a DE tool 1902 that is being used in splicing the DE model, and establishes a model data schema. This data schema describes the structure and fonnat 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 1922 may be stored in an access-restricted storage 1926, such as the “customer buckets” 1512 within customer environment 1510 in Fig. 15, so that model splices such as 1942, 1944, and 1946 may be generated on-demand once an input DE model 1904 has been crawled through. The model splicer further generates splice functions (e.g., API function scripts) 1932 from native APIs 1902 associated with the input CAD model. In the present disclosure, "native" and “primal” refer to existing DE model fdes, functions, and API libraries associated with specific third-party DE tools, including both proprietary and open-source ones. Native API 1902 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: HIDMParts(pcirts list). Generate 2DView(), etc. These model-type-specific splice functions may be stored in a splice function database 1936, 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 / Fyber, and orchestration scripts that link multiple model splices, constitutes a Platform API. This platform API is a common, universal, and extemally-accessible platfonn interface that masks native API 1902 of any native DE tool integrated into the IDMP / Fyber, thus enabling engineers from different disciplines to interact with unfamiliar DE tools, and previously non-interoperable DE tools to interoperate freely.

[0493] Next, based on user input or desired user application 1906, one or more model splices or w rappers 1942, 1944, and 1946 may be generated, w rapping 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 1922 and the API function scripts such as 1932. 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.

[0494] 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 1933 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” 1934 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 1926, or other similar access-restricted customer buckets.

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

[0496] Digital Threading of DE Models via Model Splicing

[0497] Fig. 20 is a schematic showing digital threading via splicing, according to some embodiments of the present invention. In Fig. 20. the threading of DE models is presented as an example of data source threading.

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

[0499] 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 / Fyber 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.

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

[0501] Orchestration script 2094 is divided into three main steps:

[0502] 1. Get Data From a CAD Model Splice: A POST request may be sent via the IDMP / Fyber platform API to execute a computer-aided design (CAD) model splice 2071. This model splice provides a unifonn interface to modify and retrieve infomiation about a CAD model 2081. Tire 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 2081, and a Unifonn Resource Identifier / Locator (URL) for the CAD model. The response may further comprise a URL for an image of the CAD model.

[0503] 2. Get Data From a SysML Model Splice: Another POST request may be sent via the IDMP / Fyber platform API to execute a Systems Modeling Language (SysML) model splice 2072. SysML is a general-purpose modeling language used for systems engineering. Output function 2092 of model splice 2072 retrieves the total mass requirements for the system from a SysML model 2082. The platfomi API response includes the system's total mass requirement.

[0504] 3. Align the Variables and Check If Requirement Met: The total mass from CAD model 2081 is compared with the total mass requirement from SysML model 2082. 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.

[0505] In short, orchestration script 2094, which may be implemented in application plane 1160 of IDMP / Fyber 1100 shown in Fig. 11, links digital models 2081 and 2082 via model splice API calls. Orchestration script 2094 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 / Fyber utilizes sets of functions to act upon more than one DE model.

[0506] Model Splice Plane

[0507] Fig. 21 is a schematic illustrating the linking of splices in a splice plane and comparing digital threading with and without model splicing, according to some embodiments of the present invention.

[0508] The bottom data source plane 2180 demonstrates current digital threading practices, where each small oval represents a model. The linking between any two models, such as models 2182 and 2184, requires respective connections to a central platform 2110, and potential additional linkages from every model to every other model. The central platform 2110 comprises program code that is able to interpret and manipulate original models of distinct model types. For example, platform 2110 under the control of a subject matter expert may prepare data from digital model 2182 into formats that can be accessed by digital model 2184 via digital model 2184’s native APIs, thus allowing modifications of digital model 2182 to be propagated to digital model 2184. Any feedback from digital model 2184 to digital model 2182 would require similar processing via platform 2110 so that data from digital model 2184 are converted into fonnats that can be accessed by digital model 2182 via digital model 2182’s native APIs. This hub-and-spoke architecture 2134 is not scalable to the sheer number (e.g.. hundreds or thousands) of digital models involved within typical large-scale projects, as model updates and feedback are only possible through central platform 2110.

[0509] In contrast, once the models are spliced, each original model is represented by a model splice including relevant model data, unified and standardized API endpoints for input / output, as shown in the upper splice plane 1170. Splices within splice plane 1170 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. 11 and Fig. 18. Note that in Fig. 11, only a set of generated splices is shown within splice plane 1170, while in Fig. 21, scripts that link model splices are also shown for illustrative purposes within the splice plane. Such scripts are referred to as orchestration scripts or platfonn scripts in this disclosure, as they orchestrate workflow through a digital thread built upon interconnected model splices. Further note that while splice plane 1170 is shown in Fig. 11 as part of Fyber for illustrative purposes, in some embodiments, splice plane 1170 may be implemented behind a customer firewall and be part of an agent of the platform, as discussed in various deployment scenarios shown in Fig. 16. That is, individual API function scripts generated via model splicing by a platform agent may be tailored to call upon proprietary tools the customer has access to in its private environment. No centralized platform 2110 with proprietary access to all native tools associated with all individual digital models shown in Fig. 21 is needed. Instead, orchestration scripts call upon platform API function scripts that may be implemented differently in different customer environments.

[0510] Hence, model splicing allows model splices such as model splice 2172 from digital model 2182 and model splice 2174 from digital model 2184 to access each other’s data purposefully and directly, thus enabling the creation of a model-based "‘digital mesh” 2144 via platform scripts and allowing autonomous linking without input from subject matter experts.

[0511] An added advantage of moving from the data source plane 1180 to the splice plane 1170 is that the platform enables the creation of multiple splices per native model (e.g., see Fig. 19), 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 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.

[0512] Supported by model splicing, digital threading, and digital twinning capabilities, the Fyber as disclosed herein connects models and 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 2150 for the platfomr is shown on the right side of Fig. 21, illustrating how data from many different organizations may be integrated to enable cross-domain collaboration while maintaining data security’, traceability, and auditability. Here models from multiple vendors or component constructors are spliced or wrapped by platform agents, and data artifacts are extracted with data protection. Turning 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 models using their existing security and IT stack, continue to use tools that best fit their purposes, and also preserve the same modeling schema / ontology / profile that best fit their purposes. The platform turns models into micro-services to provide minimally privileged data bits that traverse to relevant stakeholders without the models ever leaving their home servers or being duplicated or surrogate. Tire platfonn also provides simple data access and digital threading options via secure web applications or secure APIs.

[0513] Fig. 21 shows that digital artifact splicing across a generic set of information sources across diverse networks is at the core of the Fyber platform’s aggregation and orchestration of ASOTs. The splices of these digital artifacts include additional metadata at a granular level to cover further context such as the infosec level for their access, source ASOT, pertinent software tools needed to splice the artifact from the source data etc. Further, orchestration of such digital artifact splices across multiple different ASOTs requires multi-tenant enclaves as part of Fyber’s architecture.

[0514] DAG Representation of Threaded Tasks

[0515] Model splicing provides a unified interface among models, allowing model and system updates to be represented by interconnected and pipelined tasks. Fig. 22 shows an exemplary directed acyclic graph (DAG) representation of 2200 of pipelined digital tasks related to digital threads, in accordance with some embodiments of the present invention. The DE requirement verification DAG workflow of Fig. 22 is exemplary of any threaded DAG workflow.

[0516] In diagram 2200, tasks performed through a digital thread orchestration script (e.g., 2094) 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.

[0517] Referring to Figs. 11 and 20, DAGs of threaded tasks are built from digital threads and are part of the DE platform's application plane 1160. Different DAGs may target different DE actions. For example, in Fig. 11, building or updating a digital twin 1122 in the virtual environment 1120 has its own DAG 1124. Model splicing turns models into data structures that can be accessed via API, thus enabling the use of softw are development tools, from simple python scripts to complex DAGs, in order to execute actions. A digital thread of model splices eliminates the scalability issue of digital thread management, and speeds up the digital design process.

[0518] Exemplary Fyber Graphical User Interfaces

[0519] Exemplary GUI for Digital Artifacts in a Digital Thread

[0520] Fig. 23 shows a screenshot of an exemplary graphical user interface (GUI) used to operate a digital thread over the platform, according to one embodiment of the present invention. In Fig. 23, the GUI operating a DE digital thread is exemplary of a GUI operating a digital thread connecting multiple trusted data sources. The GUI provides the platform user with the ability to select and view digital artifacts that they are authorized to access, including the initial version, most recent version, and any intermediate versions. Fig. 23 shows a browser window header 2302 which includes a digital thread link for easy navigation. Below the header, a domain and security level banner 2304 displays the domain, platform software version, and security level, ensuring that users arc aware of the domain they arc operating in and the security protocols in place. It is important to note that in Figs. 23-26 (e.g., in tire browser window header 2302), the platform software version refers to a conventional softw are package version, and is distinct from the digital artifact version. The security level indicator 2306 displays the user's maximum security access level within the platform (e.g., “Level 1”). The security level indicator is interchangeably referred to as “info security tag”, “infosec tag” or “info sec tag”, herein.

[0521] The interface also includes a search bar 2312, allowing the user to carry out comprehensive cross-platform searches through the platform for digital engineering models, files, and documents, thus facilitating efficient retrieval of information across the platform. Adjacent to this, the user & domain field 2310 provides information on tire user’s domain (e.g., client name). The user and domain field may allow the user to login and to access user profile and subscription information.

[0522] Tire top menu of the GUI offers additional functionalities. For example, the digital artifact name field 2320 displays the digital model or document’s name, and may include its version. In addition, the digital thread artifact field 2326 displays the digital artifact name. The digital artifact security level indicator 2322 displays the security level (e.g., “Level 1”) of the digital artifact being accessed. In one embodiment, using an expandable security level menu adjacent to the digital artifact security level indicator 2322, the user may select the digital artifact’s target security access level “view”, thus filtering only the parts of the digital artifact accessible through a given security level. In other embodiments, the user may also use the digital artifact security level indicator 2322 to down-select the security level while sharing the digital artifact, thus sharing portions of the digital artifact that correspond to the specified security level. Only security access levels below7the user's security level (e.g., “Level 1” in Fig. 23) would be available for the user to view and share. The user interface buttons 2324 include options to copy the digital artifact link, open a comment section, access digital artifact information, manage sharing access, and export the digital artifact.

[0523] In some embodiments, the granular dynamic info security tags (e.g., 2306 and 2322, and the like), are important elements of the digital thread and magic system and its associated GUL The model splicer and Fyber system enable granular dynamic information security tags 2306 and 2322. In some embodiments, the digital thread system in the platform uses metadata of DE models or documents to cross-reference against authorizations, licenses, or regulations to update. In some embodiments, the granular dynamic information security tags 2306 and 2322 are dynamic, and are refreshed ahead of any digital thread updates to confirm the right authenticated user has the right authorized access to the digital artifacts and data to perform or view the updates.

[0524] At the center of Fig. 23, the digital artifact view er 2340 displays the digital artifact that the user is authorized to access at the right info sec level. Lastly, on the right of Fig. 23, the version pane 2350 exhibits the version history of the digital artifact within the digital thread. In the exemplary GUI of Fig. 23, the version card 2352 show s that the user is viewing the 'Most Recent' version of a digital artifact shown in the viewer. The version card 2354 shows the option to select the ‘Initial’ version of the digital artifact. In some embodiments, all versions of the artifact that the user is allowed to view at their infosec level are accessible through a versions menu in the version pane 2350.

[0525] Revisions of digital artifacts are highly likely during the course of execution of a digital thread associated with complex DE tasks. The Versioning GUI illustrated in Fig. 23 presents an example of how the platform can provide users with the ability’ to track versions with the right security controls and access controls.

[0526] Example Implementation Steps for Granular Data Tagging

[0527] Granular data tagging for infosec levels of digital artifacts shown in magic docs can be accomplished using human experts and automated following a set of rules. Following is an example sequence of steps for granular data tagging with a Privileged User (i.e., Customer Admin). As shown in Table 2, in a first step, a Privileged User uploads authorizing document associated with controls for particular data classification (i.e., ITAR, EAR, CUI, Proprietary; etc.). In the second step, the platform (Fyber) Platform presents system recommendations to categorize data. The platfonn internally implements the scanning of content to identify possible data protection controls considering known data classifications and controls available. In the third step, a Privileged User confirms, denies, or amends system recommendations for both classification and available controls. Following is an example sequence of steps for granular data tagging with a standard User. In the first step, a User in the platform creates or uploads a project or model in the platform. In the second step, the Istari Platform presents a User with a confirmation of the data classification (i.e., ITAR, EAR, CUI, Proprietary; etc.) along with the options to confirm, deny, or amend the recommended classification. The platfonn internally implements the scanning of content to classify the data considering various criteria including but not limited to: keywords. location of project, and categorization of similar content. In the third step, a User makes a selection based on the observations of the system. In the fourth step, the platform displays a screen in response to the User selection. If the User has confirmed the recommended classification, the screen displays notification that content is now accessible and shareable according to the rules consistent with the associated data classification. Tire platform internally implements the submission of data with metadata tags associated with tire appropriate data classification. If the User has denied or amended the recommended classification, the screen displays notification that content has been submitted for approval. The platform internally? implements the initiation of the approval process by notifying the designated authorizing official.

[0528] Table 2. Example sequence of steps for granular data tagging

[0529] Exemplar GUI for Orchestration Scripts in Digital Threads

[0530] Fig. 24 shows a screenshot of another exemplary graphical user interface (GUI) used to operate a digital thread, according to one embodiment of the present invention. In Fig. 24, the GUI operating a DE digital thread is exemplary of a GUI operating a digital thread connecting multiple trusted data sources with blocks of different types of data (e.g., text and code).

[0531] Tire GUI provides the platform user with tire digital thread creation capabilities described herein. Fig. 24 shows a browser window header 2402 which includes a digital thread link for easy navigation. Below the header, a domain and security level banner 2404 displays the domain, platform software version, and security level, ensuring that users are aw are of the domain they are operating in and the security protocols in place. The security level indicator 2406 displays the user's maximum security access level within the platform (e.g., “Level 1”).

[0532] Tire interface also includes a search bar 2412, allowing the user to carry out comprehensive cross-platfonn searches through the platform for digital engineering models, files, digital threads and documents, thus facilitating efficient retrieval of information across the platform. Adjacent to this, the user & domain field 2410 provides information on the user’s domain (e.g., client name). The user and domain field may allow the user to login and to access user profile and subscription information.

[0533] Tire top menu of the GUI offers additional functionalities. For example, tire digital thread name field 2420 displays the digital thread’s name, and may include its version. The digital thread security level indicator 2422 displays the security level (e.g., “Level 1”) of the digital thread being accessed. In one embodiment, using an expandable security level menu adjacent to the digital thread security level indicator 2422, the user may select the digital thread’s target security access level “view”, thus filtering only the parts of the digital thread accessible through a given security level. In other embodiments, the user may also use the digital thread security level indicator 2422 to down-select the security level while sharing the digital thread or an associated magic document for the digital thread, thus sharing portions of the digital thread that correspond to the specified security level. Only security access levels below the user's security level (e.g., ‘"Level 1” in Fig. 24) would be available for the user to view and share. Tire user interface buttons 2424 include options to copy the digital thread link, open a comment section, access digital thread information, manage sharing access, and export the digital thread.

[0534] In some embodiments, the granular dynamic info security tags (e.g., 2406 and 2422, and the like) are an important element of the digital thread and magic doc system, and its associated GUI. The model splicer and Fyber system enable the granular dynamic information security tags 2406 and 2422. In various embodiments, the digital thread system in the platfonn uses metadata of DE models or documents to cross-reference against authorizations, licenses, or regulations to update. In some embodiments, the granular dynamic information security tags 2406 and 2422 are dynamic, and are refreshed ahead of any digital thread updates to confirm the right authenticated user has the right authorized access to the digital artifacts and data to perform or view the updates.

[0535] As discussed above, digital threads are a set of orchestration scripts to orchestrate the selective exchange of data among documents and DE model files. Digital threads therefore link all the resources relevant to accomplishing a given DE task, including the various sections of an orchestration script, the relevant DE models, and relevant context information and metadata.

[0536] For a secure digital thread organization and navigation, the illustrative GUI of Fig. 24 features a digital thread outline viewer 2430 on the left of Fig. 24, providing links to the digital thread’s individual sections, including code blocks that may carry out individual subtasks within the orchestration script, text blocks that may provide contextual, parametric, requirement-related, and / or certification-related information on linked DE models. Text blocks may also include text paragraphs and / or orchestration code comments and data sources. Within the digital thread outline viewer 2430, a digital thread detailed viewer 2432 shows sections of the secure digital thread along with the linked digital engineering (DE) model(s), the associated magic documents, the source IT domain, and the last update timestamp, each tagged with the appropriate information security level (e.g., "‘LI" or “Level 1"). In some embodiments, the information security tag on a code block indicates a restriction on executing the code block. That is, a code block may only be run by an user entity with an equal or higher information security level. In some embodiments, the information security tag may indicate a viewing privilege, so the code block is only presented and viewable by an user entity' with an equal or higher information security level.

[0537] In some embodiments, if sections of a secure digital thread contain content requiring a higher security level for viewing, the user may be presented with an option to request access. Were the user to request such access, an authorized user with access at a higher security level is notified for their review. In other embodiments, if sections of a digital thread contain content requiring a higher security level for viewing, such sections will not be shown for display, nor will the user be provided with any prompt for requesting access.

[0538] At the center of Fig. 24, tire section viewer 2440 displays the content of each secure digital thread section and ensures that even’ orchestration script code, code comment, and text block is updated based on the data of the DE models that are linked to it. The model data and associated security access may be provided through model splicing, as discussed previously. Lastly, on the right of Fig. 24, the comment pane 2450 exhibits the digital thread comments and may include functionalities for comment sharing and resolution.

[0539] In the Fyber architecture, secure digital threads (as shown in Fig. 24) and their audit logs play a pivotal role in establishing a robust mechanism for centralized auditability and verification amidst a decentralized set of actions, particularly exemplified in the transformation of these threads into digitally signed smart contracts. This process underscores the innovative approach Fyber adopts, marrying the integrity of decentralized data transactions with the efficiency and coherence of centralized contract formation.

[0540] Secure digital threads act as the backbone of this architecture, creating unalterable links between disparate sources of truth. This ensures that the provenance and authenticity of data can be traced back to its origin, establishing a firm foundation of trust. By leveraging digital threads, Fyber abstracts parts of the data association process, allowing for tire crafting of smart contracts that not only automate transactions based on predefined conditions but also certify the authenticity and accuracy of the underlying data.

[0541] In essence, a secure digital thread, when accompanied by a comprehensive audit log, can evolve into a digitally signed smart contract. This contract acts as a testament to the source of truth at a given moment, underpinned by the decentralized verification of data's authenticity and centralized expertise in contract formulation. This innovative approach underscores Fyber's capability to navigate the complexities of modem data transactions, offering a reliable, transparent, and efficient solution for digital contract management across various diverse authoritative sources of truth..

[0542] The hybrid model proposed for decentralized verification alongside centralized contract writing addresses the dual needs of trust and efficiency. While the decentralized nature of verification ensures that the data's integrity is maintained across multiple, independent validators, the centralized approach to contract writing allows for the leveraging of specialized expertise, thus optimizing the process. This duality ensures that smart contracts generated within the Fyber architecture arc not only efficient and scalable but also maintain the highest standards of trust and security. Exemplary Magic Doc Operations

[0543] Fig. 25 shows an exemplary graphical user interface (GUI) used to generate and / or update a live document, according to one embodiment of the present invention. The live document, or “magic doc”, as shown in Fig. 25. is a human readable interface for data source threading showing data tagging. Magic docs may be used as a user interface for ASOT aggregation.

[0544] The GUI provides the platform user with the digital documentation capabilities described herein. Fig. 25 shows a browser window header 2502 which includes a document link for easy navigation. Below the header, a domain and security level banner 2504 displays the domain, platform software version, and security level, ensuring that users are aware of the domain they are operating in and the security protocols in place. The security level indicator 2506 displays the user's maximum security’ access level within the platform (e.g.. “Level 1”).

[0545] The interface also includes a search bar 2512, allowing the user to earn' out comprehensive cross-platform searches through the platform for models, files, and documents, thus facilitating efficient retrieval of information across tire platform. Adjacent to this, the user & domain field 2510 provides information on the user’s domain (e.g., client name). The user and domain field may allow the user to login and to access user profile and subscription information.

[0546] The top menu of the GUI offers additional functionalities. For example, the document name field 2520 displays the document’s name, and may include its version. The document security level indicator 2522 displays the security level (e.g., “Level 1”) of the document being accessed. In one embodiment, using an expandable security level menu adjacent to the document security’ level indicator 2522, the user may select the document’s target security’ access level “view”, thus filtering only the parts of the document accessible through a given security level. In other embodiments, the user may also use the document security level indicator 2522 to down-select the security level while sharing the document, thus sharing portions of the document that correspond to the specified security level. Only security access levels below the user's security level (e.g., “Level 1” in Fig. 25) would be available for the user to view and share. The user interface buttons 2524 include options to copy the document link, open a comment section, access document information, manage sharing access, and export the document.

[0547] The granular dynamic info security tags (e.g., 2506 and 2522, and the like) may be implemented within the Fyber platform and its associated GUL The model splicer and Fyber system enable the granular dynamic information security tags 2506 and 2522. In various embodiments, the platform uses metadata of models or documents to cross-reference against authorizations, licenses, or regulations to update. In some embodiments, the granular dynamic information security tags 2506 and 2522 arc dynamic, and arc refreshed ahead of any document updates to confirm the right authenticated user has the right authorized access to the digital artifacts and data to perform or view the updates.

[0548] For document organization and navigation, the GUI features a document outline viewer 2530 on the left of Fig. 25, providing links to the document's headers and paragraphs and / or sections. Within the outline viewer 2530, a digital thread viewer 2532 shows sections of the document along with the linked model(s), the source IT domain, and the last update timestamp, each tagged with the appropriate security level (e.g., “LI”). In some examples, if sections of a document contain content requiring a higher security level for viewing, the user may be presented with an option to request access. Were the user to request such access, an authorized user with access at a higher security level is notified for their review. In other examples, if sections of a document contain content requiring a higher security level for viewing, such sections will not be shown for display, nor provide the user with any prompt for requesting access.

[0549] At the center of Fig. 25, the section viewer 2540 displays the content of each document section and ensures that every paragraph is updated based on the data of the models that are linked to it. The model data and associated security? access may be provided through model splicing, as discussed previously. Lastly, on the right of Fig. 25, the comment pane 2550 exhibits the document comments and may include functionalities for comment sharing and resolution.

[0550] Fig. 26 shows an exemplary graphical user interface (GUI) used to generate or update a live suite (“magic suite”) or collaboration board, according to one embodiment of the present invention. Within an exemplary magic suite or collaboration board, or within a magic doc, a magic link refers to a hyperlink that points to an artifact. In Magic Docs, links are used to dynamically connect artifacts inside the document. In a collaboration board, one or more magic links can be used as live links to digital artifacts within the customer data storage. These links enable updates, and contextual infonnation to be displayed directly in the document, ensuring that users always access the most current information. Hence, Magic Chips may also be called from other 3rd party software tools such as Google Suite, Slack, etc.

[0551] When the live links are executed, they can be presented in a tiled format, called magic chips as shown in Fig. 26. Fig. 26 shows a magic chip for a vehicle performance artifact 2640, a body block diagram 2642, and an isometric view 2644.

[0552] Magic Links are also represented as blocks inside of Magic Docs or within a Magic Suite collaboration board. Through a magic link in the platform, the actual content of the artifact is not saved but rather a link to the digital artifact itself is provided so that security, access and content are updated whenever the document or collaboration board is loaded. An example representation of Magic Link data inside of the Magic Doc is shown in Tabic 3. Table 3. Example Representation of Magic Link Data Inside of Magic Doc

[0553] In a related embodiment, magic chips can be implemented as portable components that authenticates the user and renders artifacts, similar to magic link, within a 3rd party software such as Google suite, Slack, JIRA, etc. Magic Chips can operate outside of the Fyber / IDMP platform and inside of other platforms only if there is authentication of the user on both ends (within 3rd party software and seamlessly linked to Fyber) to access the data.

[0554] In related embodiments, the Fyber platform can connect seamlessly with other online platforms (e.g., Google Suite, Slack) using 3-legged OAuth (OAuth 2.0) authentication. This method allows users to grant tire Fyber platform access to their data on other platforms without sharing their credentials, and vice versa. Additionally, users may authorize other platforms to access some of their data or functions through the Fyber platform.

[0555] Here's a simplified overview of the process for linking Fyber with other platforms and allowing Fyber to access user’s data on other platforms. It will be apparent that reversing the process steps would allow the user to grant 3rd party platfonns the ability to access their data on Fyber platfonn:

[0556] A. Registration: The Fyber platform registers with the OAuth provider (e.g., Google) to get a client ID and secret.

[0557] B. Authorization Request: The Fyber platform directs the user to the OAuth provider’s authorization page to grant access.

[0558] C. Authorization Code Exchange: After the user grants access, the OAuth provider redirects them back to the Fyber platfonn with an authorization code. Tire Fyber platform then exchanges this code for an access token.

[0559] D. API Requests: Tire Fyber platform uses the access token to request and perform data operations (consistent with the permissions of the access token) from the OAuth provider on behalf of tire user.

[0560] In some embodiments, such a process can be implemented within a plugin (e.g. a browser plugin), handling the OAuth flow, token management, and API requests. This integration allows seamless and secure data access linked to trusted sources using the Fyber platform across multiple platfonns.

[0561] Fig. 27 shows an illustrative process flow where the platform updates a live document (“magic doc”), in accordance with one embodiment of the present invention. Example implementation steps are described below:

[0562] 1. Start: Tire process begins with the user creating a new magic document or selecting an existing magic document to update. Tire user inputs elements such as headlines, text, data, or magic links of interest. Tire system then updates the magic document data fields with linked information, including user data, prompts for headlines, text, data, and links, as well as modeling and simulation parameters and outputs.

[0563] 2. Criteria Check: The system checks if the user input data matches predefined criteria (e.g. user requests a magic doc suitable for a design review). Manual Update of Magic Doc: a. If the requested magic document data does not match the predefined criteria, the user manually updates the magic document. This involves updating the headline, adding a text block, or inserting a magic link, referring to data from the digital model platform. b. In some embodiments, magic links take a URL of an artifact on the platfonn and if user permissions are authorized, it would fetch that artifact and display it inside of the magic docs. Magic links can render images, text, JSON, HTML, tables, and 3D content fetched from an artifact. c. Based on the review, tire user can update additional metadata about the magic document or any artifacts. Once these updates are completed, the magic document is ready for submission review by the requester user. AI-Assisted Update of Magic Doc: a. If the requested magic document data matches the predefined criteria, the system suggests related data fields from the platform, such as text, magic links, and related artifacts for the user to include. b. The user selects or rejects the recommended text, links, or artifacts, with both the recommended data and user feedback being input to a training data set to train a machine learning (ML) model. c. User data prompts and magic document fields are then input to the ML model. An NLP / LLM model assists in document text generation by recommending additional text descriptions within specific sections of the magic document based on linked artifacts, artifact metadata, and user inputs. d. The user selects or rejects the recommended text, with both the recommended data and user feedback further input to a training data set to train the ML model. Including the ML model recommended text and tire magic links that fetch related artifacts, the magic document is completed. e. Based on the review, tire user can update additional metadata about the magic document or any artifacts. The magic document is now ready for submission review by the requester user. The magic document creation and update process can be iterative as the user builds additional content linking various digital artifacts securely within the digital thread for the magic document. The iterative process concludes when the magic document is ready for submission review. In exemplary embodiments, magic documents are auto-saved upon changes. The magic documents can be represented in JSON format or other uscr-prcfcrrcd document formats. Additionally, magic documents can be exported to PDF and Jupyter notebooks (.ipynb). Machine Learning (ML) and Neural Networks

[0564] Machine learning (ML) algorithms are characterized by the ability to improve their performance at a task over time without being explicitly programmed with the rules to perform that task (i.e., leam). An ML model is the output generated when a ML algorithm is trained on data. As described herein, embodiments of the present invention use one or more artificial intelligence (Al) and ML algorithms to perform external feedback integration, including script, twin, or model updates. 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.

[0565] Neural Networks

[0566] A neural netw ork 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 leam from large amounts of data and improve their performance over time. Fig. 28 describes neural network operation fundamentals, according to exemplary embodiments of the 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.

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

[0568] 1. Input: Receiving an input vector v 2804 with elements v with j G [1, n] representing the / '1' input, and where each element of the vector corresponds to an element 2806 in the input layer. For an exemplary neural network model trained to update a platform script, the input vector v 2804 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 platform, and / or any useful fonn of data.

[0569] 2. Transfer Function: Multiplying each element of the input vector by a corresponding weight w

[0570] 2808. These weighted inputs are then summed together as the transfer function, yielding the net n input to the activation function v . w 2810.

[0571] Each neuron in a neural network may have a bias value 2812. which is added to the weighted sum of the inputs to that neuron. Both the weights and bias values are learned during the training process. The purpose of the bias is to provide every neuron with a trainable constant value that can help the model fit tire data better. With biases, the net input to the activation function is X" fv . w } + b. j= i iJ

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

[0573] 3. Activation Function: Passing the net input through an activation function 2814. The activation function cr determines the activation value o 2818, 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 9 2816 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.

[0574] In the exemplary neural network model described above (e.g., to implement a script-updating ML model), the activation function r> 2814 may be a ReLU that is activated at a threshold 9 2816 representing the minimum probability for a given script update to be implemented. Hence, the activation function 2814 will yield the given script update when the implementation likelihood exceeds the threshold 92816.

[0575] 4. Output: The activation value o 2818 is the output of the activation function. This value is what gets passed on to the next layer in the network or becomes the final output in the case of the last layer. In the exemplary neural network model described above (e.g., to implement a script-updating ML model), multiple activation values o 2818 from multiple layers of a neural network may be combined to generate a text variable representing the script update that has the highest likelihood of satisfying a given external feedback input 2804. An output can also be an updated twin configuration, DTw, PTw, document, model, program code, or any useful form of data.

[0576] In the exemplary neural network discussions of Fig. 28, examples are provided with respect to a particular script-updating ML model implementation using neural networks. Analogous approaches can be used to implement model-updating ML models, feedback ML models, and any other NN-based components of the systems and subsystems described herein.

[0577] Fig. 29 shows an ovendew of a neural network training process, according to exemplary embodiments of the present invention.

[0578] The training of the neural network involves repeatedly updating the weights and biases 2910 of the network to minimize the difference between the predicted output 2904 and the true or target output 2906, where the predicted output 2904 is the result produced by the network when a set of inputs from a dataset is passed through it. The predicted output 2904 of a neural network 2902 corresponds to the output 2818 of the final layer of the neural network. The true or target output 2906 is the true desired result. The difference between the predicted output and tire true output is calculated using a loss function 2908, which quantifies the error made by the network in its predictions.

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

[0580] For a neural network model 2902 based on the exemplary neural network model (e.g., to implement a script-updating ML model) discussed above in the context of Fig. 28, and trained to determine whether a given script update is to be implemented based on external feedback input:

[0581] • the weights and biases 2910 are the neural network’s hyperparameters that get updated at each iteration of the training process, as discussed in the context of Fig. 28.

[0582] • the predicted output 2904 is the binary prediction on whether a given script update is to be implemented based on a sample external feedback, (or a normalized score ranking prioritizing the order of script updates to be displayed to the user),

[0583] • the true / target output 2906 is the correct decision (i.e., sample ground truth output) on whether to implement the given script update based on the sample external feedback.

[0584] • the loss function 2908 is the difference between the evaluation and the true output (e.g., a binary error indicating whether the neural network's decision was correct),

[0585] • the cost function 2908 is the average of all errors over a training dataset including sample external feedbacks and corresponding implementations of the given script update, and • the learning rate 2908 is the rate at which the cost function 2908 in consecutive training epochs approaches a pre-specified tolerable cost function.

[0586] Neural network training combines forward and backpropagation processes. Forward propagation is the process where the input data is passed through the network from the input layer to the output layer. During forward propagation, the weights and biases of the network are used to calculate the output for a given input. Backpropagation, on the other hand, is the process used to update tire weights and biases 2910 of the network based on the error (e.g., cost function) 2908 ofthe output. After forward propagation through the neural network 2902, the output 2904 of the network is compared with true output 2906, and the error 2908 is calculated. This error is then propagated back through the network, starting from the output layer and moving towards tire input layer. The weights and biases 2910 are adjusted to minimize this error. This process is repeated for multiple iterations or epochs until the network is able to make accurate predictions.

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

[0588] Fig. 30 provides additional details on the training process or a machine learning model, according to exemplary embodiments of the present invention, described in detail below.

[0589] Transformer Model Architecture

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

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

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

[0593] The transformer model is known for its ability to handle long sequences of data, making it particularly effective for tasks such as machine translation and text summarization. In the transformer architecture, positional encoding is used to give the model information about the relative positions of the words in the input sequence. Since the model itself does not have any inherent sense of order or sequence, positional encoding is a way to inject some order information into the otherwise order-agnostic attention mechanism.

[0594] The Embeddings Vector Space

[0595] In the context of neural networks, tokenization refers to the process of converting the input and output spaces, such as natural language text or programming code, into discrete units or ‘‘tokens". This process allows the network to effectively process and understand the data, as it transfonns complex structures into manageable, individual elements that the model can learn from and generate.

[0596] In the training of neural networks, embeddings serve as a form of distributed word representation that converts discrete categorical variables (i.e., tokens) into a continuous vector space (i.e., embedding vectors). This conversion process captures the semantic properties of tokens, enabling tokens with similar meanings to have similar embeddings. These embeddings provide a dense representation of tokens and their semantic relationships. Embeddings are typically represented as vectors, but may also be represented as matrices or tensors.

[0597] The input of a transformer typically requires conversion from an input space (e.g., the natural language token space) to an embeddings space. This process, referred to as “encoding”, transfonns discrete inputs (tokens) into continuous vector representations (embeddings). This conversion is a prerequisite for the transfonner model to process the input data and understand the semantic relationships between tokens (e.g., words). Similarly, the output of a transformer typically requires conversion from the embeddings space to an output space (e.g., natural language tokens, programming code tokens, etc.), in a process referred to as “decoding”. Therefore, the training of a neural network and its evaluation (i.e., its use upon deployment) both occur within the embeddings space.

[0598] In this document, the processes of tokenization, encoding, decoding, and dc-tokcnization may be assumed. In other words, the processes described below occur in the “embeddings space”. Hence, while the tokenization and encoding of training data and input prompts may not be represented or discussed explicitly, they may nevertheless be implied. Similarly, the decoding and de-tokenization of neural network outputs may also be implied.

[0599] Training and Fine-Tuning Machine Learning (ML) Modules

[0600] Fig. 30 is an illustrative flow diagram showing the different phases and datasets involved in training an ML model, according to exemplary embodiments of the present invention.

[0601] The training process starts at step 3010 with data acquisition, retrieval, assimilation, or generation. At step 3020, acquired data are pre-processed, or prepared. At step 3030, the ML model is trained using training data 3025. At step 3040, the ML model is evaluated, validated, and tested, and further refinements to the ML model are fed back into step 3030 for additional training. Once its perfonnance is acceptable, at step 3050. optimal ML parameters are selected.

[0602] Training data 3025 is a dataset containing multiple instances of system inputs (e.g., user inputs, user prompts, performance data, simulation data, and / or certification / requirement documents, etc.) and correct outcomes (e.g., updated script, model, document, etc.). It trains the ML model to optimize the perfonnance for a specific target task, such as the prediction of a specific target output data field within a specific target document. In Fig. 30. training data 3025 may also include subsets for validating and testing the ML model, as part of the training iterations 3030 and 3040. For an NN-based ML model, the quality of the output may depend on (a) NN architecture design and hyperparameter configurations, (b) NN coefficient or parameter optimization, and (c) quality of the training data set. These components may be refined and optimized using various methods. For example, training data 3025 may be expanded via a document database augmentation process.

[0603] In some embodiments, an additional fine-tuning 3060 phase including iterative fine-tuning 3060 and evaluation, validation, and testing 3070 steps, is carried out using fine-tuning data 3055. Fine-tuning in machine learning is a process that involves taking a selected 3050 pre-trained model and further adjusting or “tuning” its parameters to better suit a specific task or fine-tuning dataset 3055. This technique is particularly useful when dealing with deep learning models that have been trained on large, general training datasets 3025 and are intended to be applied to more specialized tasks or smaller datasets. The objective is to leverage the knowledge the model has already acquired during its initial training (often referred to as transfer learning) and refine it so that the model performs better on a more specific task at hand.

[0604] The fine-tuning process typically starts with a model that has already been trained on a large benchmark training dataset 3025, such as ImagcNct (available at iniage-net.org') for image recognition tasks. Hie model's existing weights, which have been learned from the original training, serve as the starting point. During fine-tuning, the model is trained further on a new fine-tuning dataset 3055, which may contain different classes or types of data than the original training set. This additional training phase allows the model to adjust its weights to better capture the characteristics of the new fine-tuning dataset 3055, thereby improving its perfonnance on the specific task it is being fine-tuned for.

[0605] In some embodiments, additional test and validation phases 3080 are performed using test and validation data 3075. Testing and validation of a ML model both refer to the process of evaluating the model's performance on a separate dataset 3075 that was not used during training, to ensure that it generalizes well to new unseen data. Validation of a ML model helps to prevent overfitting by ensuring that the model's performance generalizes beyond the training data.

[0606] While the validation phase is considered part of ML model development and may lead to further rounds of fine-tuning, the testing phase is tire final evaluation of the model's perfonnance after the model has been trained and validated. The testing phase provides an unbiased assessment of the final model's performance that reflects how well the model is expected to perform on unseen data, and is usually carried out after the model has been finalized to ensure the evaluation is unbiased.

[0607] Once the ML model is trained 3030, selected 3050, and optionally fine-tuned 3060 and validated / tested 3080, the process ends with the deployment 3090 of the ML model. Deployed ML models 3095 usually receive new data 3085 that was pre-processed 3080.

[0608] In machine learning, data pre-processing 3020 is tailored to the phase of model development. During model training 3030, pre-processing involves cleaning, normalizing, and transforming raw data into a format suitable for learning patterns. For fine-tuning 3060, pre-processing adapts the data to align with the distribution of the specific targeted task, ensuring the pre-trained model can effectively transfer its knowledge. Validation 3080 pre-processing mirrors that of training to accurately assess model generalization without leakage of information from the training set. Finally, in deployment 3090, pre-processing ensures real-world data matches the trained model's expectations, often involving dynamic adjustments to maintain consistency with the training and validation stages.

[0609] Machine Learning Algorithms

[0610] Various exemplary ML algorithms are within the scope of the present invention. Such machine learning algorithms include, but are not limited to. random forest, nearest neighbor, decision trees, support vector machines (SVM). Adaboost. gradient boosting. Bayesian networks, evolutionary algorithms, various neural networks (including deep learning networks (DLN), convolutional neural networks (CNN), and recurrent neural networks (RNN)), etc.

[0611] ML modules based on transformers and Large Language Models (LLMs) arc particularly well suited for the tasks described herein. The online article ^Understanding Large Language Models - A Transformative Reading List”, by .S' Raschka (posted Feb. 7, 2023, available at sebastianraschka.com blog 2()23 llm-reading-list.html). describes various LLM architectures that are within the scope of the methods and systems described herein, and is hereby incorporated by reference in its entirety herein as if fully set forth herein.

[0612] The input to each of the listed ML modules is a feature vector comprising the input data described above for each ML module. The output of the ML module is a feature vector comprising the corresponding output data described above for each ML module.

[0613] Prior to deployment, each of the ML modules listed above may be trained on one or more respective sample input datasets and on one or more corresponding sample output datasets. The input and output training datasets may be generated from a database containing a history of input instances (e.g., user inputs, user prompts, performance data, simulation data, and / or certification / requirement documents) and output instances (e.g.. updated scripts, models, documents, etc.), or may be generated synthetically by subject matter experts.

[0614] Exemplary System Architecture

[0615] An exemplary embodiment of the present disclosure may include one or more servers (management computing entities), one or more networks, and one or more clients (user computing entities). Each of these components, entities, devices, and systems (similar terms used herein interchangeably) may be cloud-based, and in direct or indirect communication with, for example, one another over the same or different wired or wireless networks. All of these devices, including servers, clients, and other computing entities or nodes may be run internally by a customer (in various architecture configurations including private cloud), internally by the provider of the platform (in various architecture configurations including private cloud), and / or on the public cloud.

[0616] Fig. 31 provides illustrative schematics of a server (management computing entity) 3110 connected via a network 3120 to a client (user computing entity) 3130 used within Fyber, according to some embodiments of the present invention. While Fig. 31 illustrates the various system entities as separate, standalone entities, the various embodiments are not limited to this particular architecture. Additionally, tire terms “client device”, “client computing entity”, “edge device”, and “edge computing system” are equivalent and are used interchangeably herein.

[0617] Exemplary Management Computing Entity

[0618] An illustrative schematic is provided in Fig. 31 for a server or management computing entity 3110. In general, the terms computing entity, computer, entity, device, system, and / or similar words used herein interchangeably may refer to, for example, one or more cloud servers, computers, computing entities, desktop computers, mobile phones, tablets, phablets, notebooks, laptops, distributed systems, gaming consoles, watches, glasses, iBeacons, proximity beacons, key fobs, radio frequency identification (RFID) tags, earpieces, scanners, televisions, dongles, cameras, wristbands, wearable items / devices, kiosks, input tenninals, servers or server networks, blades, gateways, switches, processing devices, processing entities, set-top boxes, relays, routers, network access points, base stations, the like, and / or any combination of devices or entities adapted to perform the functions, operations, and / or processes described herein. Such functions, operations, and / or processes may include, for example, transmitting, receiving, operating on, processing, crawling, displaying, storing, determining, creating / generating, monitoring, evaluating, and / or comparing (similar terms used herein interchangeably). In one embodiment, these functions, operations, and / or processes can be performed on data, content, and / or information (similar temrs used herein interchangeably), as they are used in a digital engineering process.

[0619] In one embodiment, management computing entity 3110 may be equipped with one or more communication interfaces 3112 for communicating with various computing entities, such as by exchanging data, content, and / or information (similar terms used herein interchangeably) that can be transmitted, received, operated on, processed, displayed, stored, and / or the like. For instance, management computing entity 3110 may communicate with one or more client computing devices such as 3130 and / or a variety of other computing entities. Network or communications interface 3112 may support various wired data transmission protocols including, but not limited to, Fiber Distributed Data Interface (FDDI), Digital Subscriber Line (DSL), Ethernet, Asynchronous Transfer Mode (ATM), frame relay, and data over cable service interface specification (DOCSIS). In addition, management computing entity 3110 may be capable of wireless communication with external networks, employing any of a range of standards and protocols, including but not limited to, general packet radio service (GPRS), Universal Mobile Telecommunications System (UMTS), Code Division Multiple Access 2000 (CDMA2000), CDMA2000 IX (IxRTT). Wideband Code Division Multiple Access (WCDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), Evolved Universal Terrestrial Radio Access Network (E-UTRAN), Evolution-Data Optimized (EVDO), High-Speed Packet Access (HSPA), High-Speed Downlink Packet Access (HSDPA), IEEE 802.11 (Wi-Fi), Wi-Fi Direct, 802.16 (WiMAX), ultra-wideband (UWB), infrared (IR) protocols, near field communication (NFC) protocols, Wibree. Bluetooth protocols, wireless universal serial bus (USB) protocols, and / or any other wireless protocol.

[0620] As shown in Fig. 31 , in one embodiment, management computing entity 31 10 may include or be in communication with one or more processors 3114 (also referred to as processors and / or processing circuitry, processing elements, and / or similar tenns used herein interchangeably) that communicate with other elements within management computing entity 3110, for example, via a bus. As will be understood, processor 3114 may be embodied in a number of different ways. For example, processor 3114 may be embodied as one or more complex programmable logic devices (CPLDs), microprocessors, multi-core processors, co-processing entities, application-specific instruction-set processors (ASIPs), graphical processing units (GPUs), microcontrollers, and / or controllers. The term circuitry may refer to an entire hardware embodiment or a combination of hardware and computer program products. Thus, processor 3114 may be embodied as integrated circuits (ICs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable logic arrays (PLAs), hardware accelerators, other circuitry, and / or the like. As will therefore be understood, processor 3114 may be configured for a particular use or configured to execute instructions stored in volatile or non-volatile (or non-transitory) media 3116 and 3118, or otherwise accessible to processor 3114. As such, whether configured by hardware or computer program products, or by a combination thereof, processor 3114 may be capable of perfonning steps or operations according to embodiments of the present disclosure when configured accordingly.

[0621] In one embodiment, management computing entity 3110 may further include or be in communication with non-transitory memory 3118 (also referred to as non-volatile media, non-volatile storage, non-transitory storage, physical storage media, memory, memory storage, and / or memory circuitry - similar terms used herein interchangeably). In one embodiment, the non-transitory memory or storage may include one or more non-transitory memory or storage media, including but not limited to hard disks, ROM, PROM, EPROM, EEPROM, flash memory, MMCs, SD memory cards. Memory Sticks, CBRAM, PRAM, FeRAM, NVRAM, MRAM, RRAM, SONOS, FJG RAM, Millipede memory, racetrack memory, and / or the like. As will be recognized, the non-volatile (or non-transitory) storage or memory media may store cloud storage buckets, databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and / or the like. The term database, database instance, and / or database management system (similar terms used herein interchangeably) may refer to a collection of records or data that is stored in a computer-readable storage medium using one or more database models, such as a hierarchical database model, network model, relational model, entity-relationship model, object model, document model, semantic model, graph model, and / or the like.

[0622] In one embodiment, management computing entity 3110 may further include or be in communication with volatile memory 31 16 (also referred to as volatile storage, memory, memory storage, memory and / or circuitry - similar terms used herein interchangeably). In one embodiment, the volatile storage or memory may also include one or more volatile storage or mcmorj' media, including but not limited to RAM, DRAM, SRAM, FPM DRAM. EDO DRAM, SDRAM, DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, RDRAM, TTRAM, T-RAM, Z-RAM, RIMM, DIMM, SIMM, VRAM, cache memory, register memory', and / or the like. As will be recognized, the volatile storage or memory media may be used to store at least portions of the databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and / or tire like being executed by, for example, processor 3114. Thus, the cloud storage buckets, databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and / or the like may be used to control certain aspects of the operation of management computing entity 3110 with the assistance of processor 3114 and an operating system.

[0623] Although not shown, management computing entity 3110 may include or be in communication with one or more input elements, such as a keyboard input, a mouse input, a touch screen / display input, motion input, movement input, audio input, pointing device input, joystick input, keypad input, and / or the like. Management computing entity 3110 may also include or be in communication with one or more output elements, also not shown, such as audio output, visual output, screen / display output, motion output, movement output, spatial computing output (e.g., virtual reality or augmented reality), and / or the like.

[0624] As will be appreciated, one or more of the components of management computing entity 3110 may be located remotely from other management computing entity components, such as in a distributed system. Furthermore, one or more of the components may be combined and additional components performing functions described herein may be included in management computing entity 3110. Thus, management computing entity 3110 can be adapted to accommodate a variety of needs and circumstances. As will be recognized, these architectures and descriptions are provided for exemplary purposes only and are not limited to the various embodiments.

[0625] Exemplary User Computing Entity

[0626] A user may be a human individual, a company, an organization, an entity, a department within an organization, a representative of an organization and / or person, an artificial user such as algorithms, artificial intelligence, or other software that interfaces, and / or the like. Fig. 31 further provides an illustrative schematic representation of a client user computing entity 3130 that may be used along with embodiments of the present disclosure. In various embodiments, computing device 3130 may be a general-purpose computing device with dedicated modules for performing digital engineering-related tasks or for digital model-related tasks. It may alternatively be implemented in the cloud, with logically and / or physically distributed architectures. As shown in Fig. 31, user computing entity 3130 may include a power source 3131, an antenna 3170, a radio transceiver 3132, a network and communication interface 3134, and a processor unit 3140 that provides signals to and receives signals from the network and communication interface. The signals provided to and received may include signaling information in accordance with air interface standards of applicable w ireless systems. In this regard, user computing entity 3130 may be capable of operating with one or more air interface standards, communication protocols, modulation types, and access types. More particularly, user computing entity 3130 may operate in accordance with any of a number of wireless communication standards and protocols, such as those described above with regard to management computing entity 3110. Similarly, user computing entity 3130 may operate in accordance with multiple wired communication standards and protocols, such as those described above with regard to management computing entity 3110.

[0627] Via these communication standards and protocols, user computing entity 3130 may communicate with various other entities using concepts such as Unstructured Supplementary Service Data (USSD), Short Message Service (SMS), Multimedia Messaging Service (MMS), Dual-Tone Multi-Frequency Signaling (DTMF), and / or Subscriber Identity Module Dialer (SIM dialer). User computing entity 3130 may also download changes, add-ons, and updates, for instance, to its firmware, software (e.g., including executable instructions, applications, program modules), and operating system.

[0628] In some implementations, processing unit 3140 may be embodied in several different ways. For example, processing unit 3140 may be embodied as one or more complex programmable logic devices (CPLDs), microprocessors, multi-core processors, co-processing entities, application-specific instruction-set processors (ASIPs), graphical processing units (GPUs), microcontrollers, and / or controllers. Further, processing unit 3140 may be embodied as one or more other processing devices or circuitry. The term circuitry may refer to an entirely hardware embodiment or a combination of hardware and computer program products. Thus, processing unit 3140 may be embodied as integrated circuits, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), hardware accelerators, other circuitry, and / or the like. As will therefore be understood, processing unit 3140 may be configured for a particular use or configured to execute instructions stored in volatile or non-volatile media or otherwise accessible to the processing unit. As such, whether configured by hardware or computer program products, or by a combination thereof, processing unit 3140 may be capable of performing steps or operations according to embodiments of the present invention when configured accordingly.

[0629] In some embodiments, processing unit 3140 may comprise a control unit 3142 and a dedicated arithmetic logic unit (ALU) 3144 to perform arithmetic and logic operations. In some embodiments, user computing entity 3130 may comprise a graphics processing unit (GPU) 3146 for specialized parallel processing tasks, and / or an artificial intelligence (Al) module or accelerator 3148, also specialized for applications including artificial neural networks and machine learning. In some embodiments, processing unit 3140 may be coupled with GPU 3146 and / or Al accelerator 3148 to distribute and coordinate digital engineering related tasks.

[0630] In some embodiments, computing entity 3130 may include a user interface, comprising an input interface 3150 and an output interface 3152. each coupled to processing unit 3140. User input interface 3150 may comprise any of a number of devices or interfaces allowing computing entity 3130 to receive data, such as a keypad (hard or soft), a touch display, a mic / speaker for voice / speech / conversation, a camera for motion or posture interfaces, and appropriate sensors for spatial computing interfaces. User output interface 3152 may comprise any of a number of devices or interfaces allowing computing entity 3130 to provide information to a user, such as through the touch display, or a speaker for audio outputs. In some embodiments, output interface 3152 may connect computing entity 3130 to an external loudspeaker or projector, for audio and / or visual output. In some embodiments, user interfaces 3150 and 3152 integrate multimodal data in an interface that caters to human users. Some examples of human interfaces include a dashboard-style interface, a workflow-based interface, conversational interfaces, and spatial-computing interfaces. As shown in Fig. 17, computing entity 3130 may also support bot / algorithmic interfaces such as code interfaces, text-based API interfaces, and the like.

[0631] User computing entity 3130 can also include volatile and / or non-volatile storage or memory' 3160, which can be embedded and / or may be removable. For example, the non-volatile or non-transitory memory' may be ROM, PROM, EPROM, EEPROM, flash memory', MMCs, SD memory cards, Memory' Sticks, CBRAM, PRAM, FeRAM, NVRAM, MRAM, RRAM, SONOS, FJG RAM, Millipede memory, racetrack memory, and / or the like. Tire volatile memory may be RAM, DRAM, SRAM, FPM DRAM, EDO DRAM, SDRAM, DDR SDRAM, DDR2 SDRAM, DDR3 SDRAM, RDRAM, TTRAM, T-RAM, Z-RAM. RIMM, DIMM. SIMM. VRAM, cache memory, register memory, and / or the like. Tire volatile and non-volatile (or non-transitory) storage or memory 3160 may store an operating system 3162, application software 3164, data 3166, databases, database instances, database management systems, data, applications, programs, program modules, scripts, source code, object code, byte code, compiled code, interpreted code, machine code, executable instructions, and / or the like to implement functions of user computing entity 3130. As indicated, this may include a user application that is resident on the entity or accessible through a browser or other user interface for communicating with management computing entity 31 10 and / or various other computing entities.

[0632] In some embodiments, user computing entity 3130 may include one or more components or functionalities that arc the same or similar to those of management computing entity’ 3110, as described in greater detail above. As will be recognized, these architectures and descriptions are provided for exemplary purposes only and are not limited to the various embodiments.

[0633] In some embodiments, computing entities 3110 and / or 3130 may communicate to external devices like other computing devices and / or access points to receive infomiation such as software or finnware, or to send information from the memory of the computing entity to external systems or devices such as servers, computers, smartphones, and the like.

[0634] In some embodiments, two or more computing entities such as 3110 and / or 3130 may establish connections using a network such as 3120 utilizing any of the networking protocols listed previously. In some embodiments, the computing entities may use network interfaces such as 3112 and 3134 to communicate with each other, such as by communicating data, content, information, and / or similar tenns used herein interchangeably that can be transmitted, received, operated on, processed, displayed, stored, and / or the like.

[0635] Additional Hardware & Software Implementation Details

[0636] Although an example processing system has been described above, implementations of the subject matter and the functional operations described herein can be implemented in other types of digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them.

[0637] Embodiments of the subject matter and the operations described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described herein can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on computer storage medium for execution by, or to control the operation of, information / data processing apparatus. Alternatively, or in addition, the program instructions can be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, which is generated to encode information / data for transmission to suitable receiver apparatus for execution by an infonnation / data processing apparatus. A computer storage medium can be, or be included in, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices). The operations described herein can be implemented as operations performed by an information / data processing apparatus on information / data stored on one or more computer-readable storage devices or received from other sources.

[0638] Tire terms “processor”, “computer,” “data processing apparatus”, and the like encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing. The apparatus can include special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platfomr runtime environment, a virtual machine, or a combination of one or more of them. The apparatus and execution environment can realize various different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0639] A computer program (also known as a program, software, software application, script, code, program code, and the like) can be w ritten in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may. but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or information / data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0640] The processes and logic flows described herein can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input infomration / data and generating output. Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and information / data from a read only memory or a random-access memory or both. The essential elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive information / data from or transfer information / data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Devices suitable for storing computer program instructions and information / data include all forms of non-volatile memory, media, and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0641] To provide for interaction with a user, embodiments of the subject matter described herein can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information / data to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to tire computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user’s client device in response to requests received from the web browser.

[0642] Embodiments of the subject matter described herein can be implemented in a computing system that includes a backend component, e.g., as an information / data server, or that includes a middleware component, e.g., an application server, or that includes a frontend component, e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described herein, or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by any fonn or medium of digital information / data communication, e.g., a communication network. Examples of communication networks include a local area network (‘"LAN”) and a wide area network (“WAN”), an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0643] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship with each other. In some embodiments, a server transmits information / data (e.g., an HTML page) to a client device (e.g., for purposes of displaying information / data to and receiving user input from a user interacting with the client device). Information / data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server.

[0644] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any embodiment or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described herein in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

[0645] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in tire particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0646] Tirus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in tire claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.

[0647] In some embodiments of the present invention, the entire system can be implemented and offered to the end-users and operators over the Internet, in a so-called cloud implementation. No local installation of software or hardware would be needed. The end-users and operators would be allowed access to the systems of the present invention directly over tire Internet, using either a web browser or similar software on a client, which client could be a desktop, laptop, mobile device, and so on. This eliminates any need for custom software installation on the client side and increases the flexibility of delivery' of the service (software-as-a-service), and increases user satisfaction and ease of use. Various business models, revenue models, and delivery mechanisms for the present invention are envisioned, and are all to be considered within the scope of the present invention.

[0648] In general, the method executed to implement the embodiments of the invention, may be implemented as part of an operating system or a specific application, component, program, object, module, or sequence of instructions referred to as “program code,” “computer program(s)”, “computer codc(s),” and the like. The computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects of the invention. Moreover, while the invention has been described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that the various embodiments of the invention are capable of being distributed as a program product in a variety of forms, and that the invention applies equally regardless of the particular type of machine or computer-readable media used to actually affect the distribution. Examples of computer-readable media include but are not limited to recordable type media such as volatile and non-volatile (or non-transitory) memory devices, floppy and other removable disks, hard disk drives, optical disks, which include Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks (DVDs), etc., as well as digital and analog communication media.

[0649] Terminology

[0650] Some illustrative terminologies used with the Fyber Platform are provided below to assist in understanding the present invention, but these are not to be read as restricting the scope of the present invention. The terms may be used in the form of norms, verbs, or adjectives, within the scope of the definition. One embodiment of Fyber applied to digital models may be known as tire Interconnected Digital Model Platform (IDMP).

[0651] Digital Engineering

[0652] • Digital engineering (DE), one field to which the IDMP may be applied: According to the Defense Acquisition University’ (DAU) and the Department of Defense (DOD) Digital Engineering Strategy published in 2018, digital engineering is "an integrated digital approach to systems engineering, using authoritative sources of systems’ data and models as a continuum across disciplines to support lifecycle activities from concept through disposal.” Digital engineering incorporates digital technological innovations into an integrated, model-based approach that empowers a paradigm shift from the traditional design-build-test methodology of systems engineering to a new model-analyze-build methodology, thus enabling systems design, prototyping, and testing all in a virtual environment.

[0653] • DE data: Digital engineering (DE) data includes project management, program management, product management, design review, and / or engineering data.

[0654] • DE data field: A data field for DE data, for example, in a DE document template.

[0655] • Phases: The stages within a DE product lifecycle, including but not limited to, stakeholder analysis, concept studies, requirements definition, preliminary’ design and technology review, system modeling, final design, implementation, system assembly and integration, prototyping, verification and validation on system, sub-system, and component levels, and operations and maintenance.

[0656] • DE model: A computer-generated model that represents characteristics or behaviors of a complex product, system, or process. A DE model can be created or modified using a DE tool, and a DE model may be represented by one or more DE model files. A DE model file is the computer model file created or modified using the DE tool. In the present disclosure, the terms ‘"digital model”, “DE model” and “DE model file” may be used interchangeably, as the context requires. A DE model within the IDMP as disclosed herein refers to any digital file uploaded onto the platform, including documents that are appropriately interpreted, as defined below. For example, a computer-aided design (CAD) file, a Systems Modeling Language (SysML) file, a Systems Requirements Document (SDR) text file, and a Neural Network Model JSON file may each be considered a DE model, in various embodiments of the present invention. A DE model may be machine-readable only, may be human-readable as well but written in programming codes, or may be human-readable and written in natural language-based texts. For example, a word-processing document comprising a technical specification of a product, or a spreadsheet file comprising technical data about a product, may also be considered a DE model. A DE model is a type of digital model, defined below. In general, any reference to a DE model in the specification and drawings may be considered equivalent to a reference to a digital model, and vice versa.

[0657] • Digital Model: A computer-generated model that represents characteristics or behaviors of a complex product, system, or process. Digital models include DE models but are not limited to the field of digital engineering. For example, digital models include medical model files used to build digital twins of patients (e.g., digital patients), such as clinical documentation, laboratory results, physiological test results, psychological test results, patient communications and reports, patient medical data, health records, remote monitoring data, and the like. Digital models also include the financial models used to build digital twins of financial assets, such as enterprise data, business financial data, process data (e.g., manufacturing, logistics, sales, supply chain), research results, etc. Other examples of digital models are also within the scope of the present invention, for example, scientific models, geophysical models, climate models, biological models, biochemical models, chemical models, drug models, petrochemical models, oceanographic models, business process models, management science models, economic models, econometric models, sociological models, population dynamics models, socioeconomic models, planetary science models, mining models, mineral models, metallurgical models, supply chain logistics models, manufacturing models, and so on. Digital models include one or more digital artifacts, where each digital artifact is accessible with a security network. A model file can be created or modified using a software tool. A model file, also referred to as a '‘data source” including “resource data” (e.g., model data) within the Interconnected Digital Model Platform (IDMP) and the Fyber Platform as disclosed herein, refers to any digital file uploaded, linked, retrieved, and tire like onto the platfonn, including files on the Internet, digital models on a customer environment that is publicly or confidentially shared, files within security networks that are not otherwise directly accessible on the Internet such as security classification networks, air-gapped installations, etc. All the terms and concepts defined above and included herein, including model splicing, model splices, and software-defined digital threads, apply in the context of the digital model and within the context of the IDMP.

[0658] • Verification: According to the DAU, verification “confirms that a system element meets design-to or build-to specifications. Through the system’s life cycle, design solutions at all levels of the physical architecture are verified through a cost-effective combination of analysis, examination, demonstration, and testing.” Verification refers to evaluating whether a product, service, or system meets specified requirements and is fit for its intended purpose, checking externally against customer or stakeholder needs. For example, in the aerospace industry, a verification process may include testing an aircraft component to ensure it can withstand tire forces and conditions it will encounter during flight.

[0659] • Validation: According to the DAU. validation is “I) the review and approval of capability requirement documents by a designated validation authority. 2) The process by which the contractor (or as otherwise directed by the DoD component procuring activity) tests a publication / technical manual for technical accuracy and adequacy. 3) The process of evaluating a system or software component during, or at the end of, the development process to determine whether it satisfies specified requirements.” Thus, validation refers to 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, checking internally against specifications and regulations. For example, for an industrial product manufacturing, a validation process may include consumer surveys that inform product design, modeling and simulations for validating the design, prototype testing for failure limits and feedback surveys from buyers.

[0660] • Common Verification & Validation (V&V) products: Regulatory and certification standards, compliances, calculations, and tests (e.g., for the development, testing, and certification of products and / or solutions) are referred to herein as “common V&V products.” • DE tool: A tool or DE tool is a DE application software (e.g., a CAD software), computer program, and / or script that creates or manipulates a DE model during at least one stage or phase of a product lifecycle . A DE tool may comprise multiple functions or methods.

[0661] Fyber Platform / IDMP IDEP

[0662] • Interconnected Digital Engineering Platfonn (IDEP), also referred to as a “Digital Engineering and Certification Ecosystem”: According to the DAU, a “DE ecosystem” is the “interconnected infrastructure, environment, and methodology (process, methods, and tools) used to store, access, analyze, and visualize evolving systems’ data and models to address the needs of the stakeholders.” Embodiments of the IDEP as disclosed herein comprise software platforms running on hardware to realize the aforementioned capabilities under zero-trust principles. Specifically, an embodiment of the IDEP is a software platform that interconnects a plurality of spliced DE model files through one or more software-defined digital threads (see Figs. 1-4 from PCT application No. PCT / US24 / 61606 (Docket No. IST-03.008PCT)). A DE and certification ecosystem perfonns verification and validation tasks, defined next. An IDEP may be considered a type of Interconnected Digital Model Platfonn (IDMP) when one or more of the digital models are engineering or science related, the IDMP being defined below. In general, any reference to an IDEP in the specification and drawings can be considered equivalent to a reference to an IDMP, and vice versa.

[0663] • Fyber Platform, ‘digital platfonn’, ‘software platform’, or simply ‘platform’, and sometimes also referred to as Interconnected Digital Model Platfonn (IDMP) when used in the context of models: Embodiments of the Fyber platfonn or IDMP as disclosed herein include interconnected infrastructure, environment, and methodology (process, methods, and tools) used to store, access, analyze, visualize, and modify data and / or digital models associated with a product or system, including from data sources on the Internet. In some embodiments, Fyber and IDMP include software platforms running on hardware to realize the aforementioned capabilities under zero-trust principles. Specifically, an embodiment of Fyber and IDMP is a software platform that interconnects a plurality of spliced model files or resource representations through one or more software -defined digital threads. Fyber Platform generalizes IDMP to process data from any trusted data source, for example, from resources on the public Internet. All capabilities and features described in the “Reference to Related Applications” section that are described in the context of the IDEP and / or the IDMP therein, apply equally to the Fyber platfonn, as generalized herein. • Hyperscale capabilities: The ability of a system architecture to scale adequately when faced with massive demand.

[0664] • IDMP / Fyber enclave or platform enclave: A central command hub responsible for the management and functioning of platfomr operations. 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 ,c .. multi-tenant) that does not take dependencies on resources in other enclaves.

[0665] • IDMP / Fyber exclave or platform exclave: A secondary hub situated within a customer environment to assist with customer DE tasks and operations. An exclave is a set of cloud resources outside enclaves managed by the platform, to perform work for individual customers. Examples of exclaves include virtual machines (VMs) and / or servers that the platfomr maintains to run tools for customers who may need such services.

[0666] • Admins or Administrators: Project managers or other authorized users. Admins may create templates in the documentation system and have high-level permissions to manage settings in the platform.

[0667] • Requesters: Users who use the platfomr for the implementation of the modeling and simulations towards certification and other purposes, and who may generate documentation in the digital documentation system, but do not have admin privileges to alter the required templates, document formats, or other system settings.

[0668] • Reviewers / Approvers: Users who review and / or approve templates, documents, or other system data.

[0669] • Contributors: Users who provide comments or otherwise contribute to the platform.

[0670] • Al Agent or Tool Agent: a software entity or module that takes instructions from the enclave and acts on behalf of a user or another program to perform specific tasks or operations related to an Al model or a DE tool. An Al agent or a tool agent may be designed as part of the platform but deployed by a customer within a secured customer environment to interface in-between the platform, Al models, and / or proprietary tools the customer is licensed for. Inside the customer environment, modular agents interact directly with the domain-specific tools and models to allow for bi-directional data flow across distributed tools.

[0671] • Resource-capability mapping: A framework for identifying and linking available resources with the capabilities they enable or support. An exemplary resource-capability mapping is the IDMP API, or platform API, where the resource refers to third-party tools and functions integrated into and accessible via the platform, and where the exemplary capability refers to platform functions written in scripts for completing certain tasks using the available resource. Such resource-capability mappings may be used to identify how tool-specific resources such as tool functions, access and control capabilities, human-machine interfaces, processes, and objects can be allocated, invoked, and utilized efficiently and effectively to achieve specific platform functions or tasks. Resource capability mapping also assists with zero-knowledge implementations where the capability details are available to a user while the specific digital tool resource or its functions are only mapped within the customer environment. Another example of the resource-capability mapping framework is a variable mapping table.

[0672] • User intent: The goal, objective, or desired outcome that a user aims to achieve when interacting with the platform. User intent may be expressed through various forms of input, such as user actions, natural language prompts, commands, or selections within the platform interface.

[0673] • User actions: Specific interactions, inputs, or operations performed by a user within the platform. User actions may include, but are not limited to, mouse clicks, keyboard inputs, voice commands, or any other form of interaction with the platform's interface or components.

[0674] • Multi-Tenancy Architecture: A software architecture paradigm where a singular software instance concurrently serves multiple users or organizations (tenants), each shielded within isolated operational environments. In the case of Fyber, the platform enclave orchestrates the secure digital thread execution across multiple tenants that are strictly siloed from one another.

[0675] • Tenancy: A tenant or a tenancy is an account in a computer system. Generally, a customer usually corresponds to a tenant (the group of people) holding a tenancy (the computer’s representation of that group). An account (the computer’s representation of who’s paying for access) usually corresponds to a whole company or an organization / division within a large company that has a distinct budget.

[0676] Model and Resource Splicing on IDMP / IDEP / Fvber

[0677] • Application Programming Interface (API): A software interface that provides programmatic access to services by a software program, thus allowing application software to exchange data and communicate with each other using standardized requests and responses. It allows different programs to work togethe...

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 generating a digital thread script operating on data from a trusted data source within a digital platform, the program code comprising code to: receive a data source as the trusted data source, wherein the trusted data source is located in an external security environment external to the digital platform; derive a digital artifact from the data source, the digital artifact comprising a data subunit and artifact metadata derived from the data source; store the digital artifact in a digital artifact storage environment accessible by the digital platform; generate an external, commonly-accessible function script that enables external access to the digital artifact, 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 tire data source; generate a sharable resource representation of the data source, wherein the sharable resource representation comprises access to a selective portion of the digital artifact, wherein the sharable resource representation comprises the external, commonly-accessible function script, and wherein the sharable resource representation is accessible via the addressable API or SDK endpoints by the third-party applications and users; generate a digital thread script based on the sharable resource representation using the addressable API or SDK endpoints in the sharable resource representation; and execute the digital thread script on the digital platform to generate a live digital resource, wherein the live digital resource is configured through the digital thread script to access the digital artifact, and wherein a notification of a modification of the data source appears in the live digital resource within a predetermined delay.

2. The non-transitory physical storage medium of claim 1. wherein the data source is identified by a resource identifier, wherein the program code to receive tire data source further comprises program code to receive the resource identifier, andwherein the program code to derive the digital artifact from the data source further comprises program code to extract resource data from the data source identified by the resource identifier.

3. Tire non-transitory physical storage medium of claim 2, wherein the live digital resource is configured through the digital thread script to store the artifact metadata, and wherein the artifact metadata comprises the resource identifier.

4. The non-transitory physical storage medium of claim 1, further comprising program code to: generate a trusted data envelope associated with the digital artifact, wherein the trusted data envelope comprises a cryptographically verifiable structure that encapsulates access policies, a metadata block, and a reference to the digital artifact, and wherein the access to the selective portion of the digital artifact further invokes program code to verify the trusted data envelope.

5. Tire non-transitory physical storage medium of claim 4, wherein the trusted data envelope comprises a data pointer field indicating a location of tire digital artifact, a data hash field comprising a cryptographic digest of a data component of the digital artifact, the metadata block, and one or more digital signatures.

6. The non-transitory physical storage medium of claim 5, wherein the metadata block comprises an issuer identity, a subject identifier, a timestamp, and one or more permitted operations.

7. The non-transitory physical storage medium of claim 6, wherein the one or more pennitted operations comprises an access policy.

8. The non-transitory physical storage medium of claim 5, wherein the one or more digital signatures comprise an issuer signature, a recipient signature, and a signature from a Timestamp Authority (TSA).

9. The non-transitory physical storage medium of claim 4, wherein the trusted data envelope depends on a parent trusted data envelope associated with a parent digital artifact, wherein access to the digital artifact requires access to the parent digital artifact.

10. The non-transitory physical storage medium of claim 4, further comprising program code to:receive a security network identifier associated with the data source, wherein the metadata block comprises the security network identifier associated with the data source.

11. Tire non-transitory physical storage medium of claim 1, further comprising program code to: receive a security network identifier associated with the digital artifact, wherein the artifact metadata comprises the security network identifier associated with the digital artifact.

12. The non-transitory physical storage medium of claim 1, wherein the program code to generate the live digital resource comprises program code to update the live digital resource.

13. The non-transitory physical storage medium of claim 1, further comprising program code to: output, for display, the live digital resource to a user on a user interface.

14. The non -transitory physical storage medium of claim 1, wherein the data source has a data source type and is in a native file format, wherein the addressable API or SDK endpoints enable access to the digital artifact without access to the entirety of the data source and without requiring direct engagement by the third-party applications and users with a software tool associated with the data source type, and wherein the addressable API or SDK endpoints provide a unified programming interface to sharable resource representations generated from data sources having the data source type.

15. The non-transitory physical storage medium of claim 1, wherein the digital artifact storage environment is located within the external security environment of the trusted data source.

16. The non-transitory physical storage medium of claim 1, wherein the digital artifact storage environment is distinct from tire external security environment of the trusted data source.

17. The non-transitory physical storage medium of claim 16, wherein the access to tire selective portion of the digital artifact is limited in time.

18. A computer-implemented method for generating a digital thread script operating on data from a trusted data source within a digital platform, comprising: receiving a data source as the trusted data source, wherein the trusted data source is located in an external security environment external to the digital platform;deriving a digital artifact from the data source, the digital artifact comprising a data subunit and artifact metadata derived from the data source; storing the digital artifact in a digital artifact storage environment accessible by the digital platform; generating an external, commonly-accessible function script that enables external access to the digital artifact, 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 data source; generating a sharable resource representation of the data source, wherein the sharable resource representation comprises access to a selective portion of the digital artifact, wherein the sharable resource representation comprises the external, commonly-accessible function script, and wherein the sharable resource representation is accessible via the addressable API or SDK endpoints by the third-party applications and users; generating a digital thread script based on the sharable resource representation using the addressable API or SDK endpoints in tire sharable resource representation; and executing the digital thread script on the digital platform to generate a live digital resource, wherein the live digital resource is configured through the digital thread script to access the digital artifact, and wherein a notification of a modification of the data source appears in the live digital resource within a predetermined delay.

19. The computer-implemented method of claim 18, further comprising: generating a trusted data envelope associated with the digital artifact, wherein the trusted data envelope comprises a cryptographically verifiable structure that encapsulates access policies, a metadata block, and a reference to the digital artifact, and wherein the access to the selective portion of the digital artifact invokes verifying the trusted data envelope.

20. The computer-implemented method of claim 19. wherein the trusted data envelope comprises a data pointer field indicating a location of the digital artifact, a data hash field comprising a cryptographic digest of a data component of the digital artifact, the metadata block, and one or more digital signatures.

Images