First, in response to Birkal - Closing a decision on customs in discussion sounds perfect to me! And also the clarification on the multiple Pokémon frameworks sounds good too (though I personally still have reservations about said FWs).
And secondly I'd like to address something about the two-one limit issue that's been on my mind. Have we set a clear definition for 'limit' or 'alter' or 'modification' yet? I had been operating off of what Birkal's suggested opening post said, which appeared to define whatever term you want to refer to the changes in process as, as "dictates CAP25's typing and primary ability. An illegal framework would also mandate a specific stat bias on top of those restrictions." Notice the harsh, restrictive verbs here. "Dictate" and "Mandate" are very hard-line words that indicate an illegal framework would only be illegal if it pre-decided 2 things in a meaningful manner. My interpretation of that phrasing was along the lines of a change/alteration/limit/whatever being something that would go beyond slightly limiting discussion, but instead eliminates discussion entirely. As jas said, restriction can coexist with discussion as long as the caveat exists that a restriction is not classified as a 'limit.'
With this in mind, I would then look to the past posts on this issue and question what their definition of a alteration/change to the process/what have you is (For the sake of less '/' I'm just going to refer to them as changes from here on out, because it's getting annoying for me). I would argue that BIrk, jas, and Deck have a different interpretation than mine; one that is inherently less rigid in what counts as a limit. I think the UB framework illustrates this perfectly. According to my interpretation, a UB has one change. According to you all, it has two, one being the mandate that the only ability is Beast Boost. I would agree on that. It is 100% something that obstructs the process by bypassing a stage. However, the second part is where we get a bit trickier. Y'all argue that a UB FW also puts a change on stats, because it mandates 570 BST and that each individual stat be prime numbers.
This is the part where the definition in the opening post becomes important. I can understand why one would classify the change to the stats process as a 'limit' of some sorts. Nobody here would argue that only primes is a bit of a headache, especially if they have to add up to 570. It would probably decrease out submission pool greatly, in fact. However, the current opening post doesn't seem to indicate that type of change as a, well, change. It's a soft restriction, sure, but it doesn't indicate a particular stat bias. It doesn't tell me "You must make your stats fit this general archetype." So, to me, going off of the railroad definition of a change, this wouldn't be a change. It would just be extra baggage for the stats stage.
I can kind of make similar arguments for Birkal's examples as well. Sure, it makes logical sense that Forecast would produce a form with a typing associated with the weather, putting a hard restriction on ability and a soft restriction on type. But there's nothing saying we have to abide by that logic. I could be totally wrong here, but is there anything saying hypothetical Forecast CAP couldn't have a dual typing? A type that stays between all of its forms? Or perhaps it gains a completely new dual type in each form, just to be completely counterintuitive? Similar logic (if the mechanics still hold) would apply to Multitype. It's a form change triggered by ability. Theoretically there shouldn't be anything stopping us from adding a constant secondary type to each form.
I think the best way to go about this would be to edit the opening post in an attempt to aim for absolute clarity. Along the lines of what Deck suggested, let's say each framework cannot exceed two total of railroads (or insert other term here) and restrictions, but only one of which can be a railroad.
Define a railroad as a limitation on standard CAP procedures that completely eliminates discussion on a regular stage of the process. This would be your "This CAP WILL 100% FOR SURE have X Ability, Y/Z dual typing, or Q pure typing." Meanwhile, a restriction would be, as Deck was talking about, a 'soft restriction.' This would be your FWs that say stuff like: CAP must have an ability that allows it to change forms (This restricts ability discussion, but doesn't railroad as there are multiple options here), CAP must be at least partially X type (Restricts part of the typing stage, but leaves open whether or not the mon will have a secondary type, and what that type would be), and basically anything that doesn't explicitly outline every stat in a stat spread, but says something about how the stats should go (e.g. The speed stat will be 255, A strong special tank, must follow UB stat patterns, etc.). I think this approach allows for the most freedom in frameworks by allowing two total breaches of protocol, but also more clearly defines what we're talking about when we say 'trivializes the process.'
Additionally, I think it wouldn't hurt to add a part to the FW submission where submitters specify what railroads or restrictions their project entails. I think it will help streamline framework/concept analysis if we aren't starting off by saying "So what actually does this framework entail in terms of what we can/can't do?" Additionally, it gives those reading the concepts the ability to quickly identify what stages would be impacted by choosing a given framework. Honestly, this is all probably too complicated a way to go about this, and I'm sure someone else here will be able to streamline this better, but I really do think we need to nail this framework definition now in order to save so much headache later.
