Guardian as a multi-workflow engine for independent data streams

[anvabr]

Problem description

Some business processes, for example in supply chains, produce substantial amounts of machine-readable data which can be used for analysis and serve as evidence in various regulatory areas, of which environmental/carbon impact is just one. Some examples can be food safety or quality attributes such as vegan, or kosher, halal, and/or other certifications.

At the moment there is no way to usefully 'apply' Guardian workflow and policy engine to the such data in areas other than carbon accounting.

Requirements

Guardian should be able to inject machine-readable product data and process them simultaneously in multiple independent Policy processing streams, each with an independent ruleset, however with the possibility to coordinate and cross reference the artifacts produced by these streams, all while maintaining and referencing the single original instance of the 'master' data.

1. Extend and adapt the topics architecture to support multi-workflow processing of the master data (from a topic)
2. Develop a multi-streams Guardian policy coordination mechanisms which were in a single instance and across different Guardian instances, which include
   • trigger workflow execution based on an event such as NFT issuance, data events.
   • pause and wait for the availability of specific data
3. Introduce additional (to token issuance) Guardian policy actions to enable 'final' stages of policy streams executions, such as:
   • payment execution (see Guardian policy driven conditioned payment execution on-chain #5430)
   • certificate (invoice, bill of lading, etc) issuance

Definition of done

TBD

Acceptance criteria

TBD

[denischasovskikh]

https://www.figma.com/design/r4opkmPm3TPieVSXTb0pjK/Design-file--Guardian-?node-id=7010-64392&t=zCjWkKUz6kKcjXY7-1

[itsrishabh]

At Nset, we are implementing Carbon Inventory Certificates (CICs) as a volumetric asset class. We view the Multi-Workflow Engine as the critical architectural component for moving agricultural data beyond "siloed" carbon accounting into a unified Digital Product Passport (DPP) ecosystem.

Specific Use Case:
Our Beef and Pork programs ingest a single "Master Data" stream (e.g., farm-level fuel, feed intake, and production volume $Q$) . We need the Guardian to process this single stream through simultaneous independent processing streams:

• Stream A (Carbon Intensity): Quantifies attributes under our Methodology v1.1 for Scope 3 reporting.
• Stream B (Quality/Regenerative): Simultaneously verifies regenerative or safety standards (e.g., Grass-Fed or Organic) from the same physical activity data.

Critical Technical Feedback & Requirements:

1. Cross-Reference Integrity: We strongly endorse the "coordinate and cross-reference" requirement. For Nset, a Carbon CIC in Stream A should be able to "pause and wait" until a parallel Regulatory Stream confirms the legal validity of the Carbon Rights Agreement.
2. Atomic State Consistency: When dealing with physical commodities, the "Final Stage" of these multiple streams must be atomic. If a buyer purchases a "Premium CIC," the underlying DPP must verify that all relevant workflows (Carbon + Quality + Origin) have reached a "Verified" state before the token is allowed to transfer.
3. Master Topic Sovereignty: To minimize the MRV burden on producers, it is essential that the "Master Data" topic serves as the single source of truth. Any update to the Master Data should trigger recalculations across all active policy streams without duplicating the data footprint on-chain.

I think to be sound Hedera should have:

• Inter-Policy "If/Then" Logic: Policy authors must be able to write conditions in one policy that are dependent on the state or NFT issuance event of another policy.

From our side:

• Unified Artifact Generation: The system should be able to output a single "Consolidated Certificate" (or DPP) that aggregates the verified artifacts from multiple independent streams. We already have most of in this place :)

[anvabr]

@itsrishabh thank you very much for the detailed and thoughtful use-case write-up. I would like to try to cross-check some of the statements reflecting the design approaches and Guardian functional scope with you - just to make sure all the above was understood correctly:

1. Current designs for multi-stream (i.e. multi-workflow) processing imply that these separate 'streams' would be implemented as different policies, coordination of which happen via publishing their corresponding artefacts in Hedera/IPFS. The availability of one of new master data, and/or such artefacts triggers the processing in the workflow of the other.
2. Guardian multi-workflow engine would enable atomic 'final stage' by ensuring that workflow processing results/artefacts are discoverable and accessible (if they have been produced). Verifying their existence and cryptographic validity, triggering/permitting purchase action is a function of exchanges and marketplaces (3rd party systems).
3. We built flexibility into Guardian policy definition language which would allow using the same, or different topics for products/systems/etc. The 'source' data is defined as 'topic'+'minimal schema' - i.e. to match the exact type of the information that workflows require, the pipelines can output data (i.e. 'certificates' or intermediate results) into any topic as configured.

Does the above align with your view of the use-case?

Also, if at all possible would you be able to provide realistic looking examples for 'in' and 'out' data for each of the streams (A, and B) in your example above? This would help us to create a more targeted demo case for the implementation for you.