Hi everyone, I'm working on a solution that attempts to resolve the version consensus of multiple consumers in the same provider. I'm trying to develop a composer that can unify the contracts published by clients (verified/unverified) to offer a standard contract that is the basis for generating unit tests in the opposite direction to the perspective assumed in PactFlow AI. These created tests will be made available to new consumers, so they wouldn't exactly be bidirectional contracts. The basic idea would be community-based tests or democratic contracts. Can I count on your experience to evolve this idea or am I straying too far from the PACT philosophy?

Interesting. Can you please elaborate on the problem statement a little further? Is it about avoiding writing tests that multiple consumers have of the same provider to reduce the amount of code to be written?

- Payloads specifications in many situations can be imposed by goverment institutions (consumer A), for example in a instant payments system. So it is necessary that the provider (provider A) progressively adapt to these new versions. - In addition to this there are mature consumers who are in an advanced phase (consumers B,C,D...) regarding new consumers (consumer X) and there is no way to share the experience of mature consumers with new consumers. - The goal is for all consumers to adapt progressively to a common pattern, that can be visible to consumers (specially consumer X,Y,Z...). - Once the consumer generates the tests based on the standard contract, the amount of code that must be written can decrease.

I understand the want to try and reduce code duplication, and additionally to help future consumers understand the existing patterns. A few additional questions: 1. Do all consumers consume all of the fields that come back from the provider or just a subset? 2. Are all consumer’s code bases generated by a spec, or hand crafted? 3. Is it possible that some consumers only use some of the APIs and others use a different subset?

Ok thank you very much for paying attention ... - Do all consumers consume all of the fields that come back from the provider or just a subset? A: Verified consumers consume all fields and non -verified consume a proposed subset in their new version - Are all consumer’s code bases generated by a spec, or hand crafted? A: The initial consumers codes are generated by hand, however the codes of the new consumers are intended to be generated through this technique. - Is it possible that some consumers only use some of the APIs and others use a different subset? A: We want that all consumers to use all endpoints and API fields I identified differences and similarities between contracts, with the aim of making a merge.But I am stagnant in the field analysis, I don't know if I have to use ontologies to obtain a standard payload with semantically viable fields. In the second objective I make an automatic generation of unit tests based on the contract, simply I read the interactions recursively and create the unit tests.