I would like to progress the janus prototype into an actual project. There are a few foundational things that must be resolved: what is it called, where does it live. I was wondering if we should create a new GitHub org for it with a main repo for the engine. That way example projects can be in that org. The Pact org is getting rather over run. Other options is a repo in the Pact org or a subdirectory in the pact reference repo, and if it is Pact V5 or Pact2, but I think it is a totally different design so should be named on it's own. It can execute Pact files, but the process would be to upgrade to it as it provides better contract that a Pact file (an upgraded Pact file will only contain a single variant which is the example defined in the Pact file) Here is the list Claude drew up: Questions for the community The charter says these belong to the community, and this plan does not decide them. What it can do is say why each one matters and what the prototype found that bears on it. 1. Naming and versioning. Janus writes its own contract format and does not claim to be "pact v5" (ADR 0011). Some of the options: ◦ make that format the Pact specification's next version; ◦ keep it a separately versioned format under the Pact name; ◦ brand the whole redesign (the RFC's "MkII", "Pact 6"). It needs deciding before stage 2 ships a major version, because the format's identifier is written into every contract. 2. Where it lives, and who owns what. The engine, the specifications, and conformance sign-off each need an owner. The prototype suggests sign-off can be mechanical (a build passes the suite, ADR 0017), which leaves people deciding what goes into the specification rather than whether an SDK complies. The engine could live beside

pact_matching

in pact-reference, which it forked, or in a repository of its own. 3. Funding. Stages 1 and 2 are large, and providers-first means stage 1 pays back before stage 2 finishes. Whether that is foundation sponsorship, vendor contribution or grants is not this plan's to say. 4. When today's implementations go into maintenance mode. The RFC ties it to each SDK passing conformance on the new engine. This plan's stage exits make that measurable per language. The timeline around them is the community's. 5. How the broker's API evolves. The broker notes (task 7.5) set out a PR series for provider shapes and decisions. How far the open-source broker and PactFlow each go is theirs to decide.

I will give this the time it deserves soon, I wonder if this might warrant an at channel to get eyes on the RFC and let the community have their say (if they decide to!)

Ok, #C0C858ZTP9U channel created