with my experience both framework and implementation  does the same thing. As long as you don't have multiple implementations which shares the common assets we don't require to have a framework layer.

For your question it does not matter what we call it as implementation or Framework. If we don't know about future extensibility of the requirement, you can simply build one layer.

If it going to extended in future you can leverage that layer as a framework.

Nowhere is it stated that the same Development Team absolutely must start every project building two layers at a time, i.e., a "framework layer" and "implementation layer".  Layers are meant to be built one at a time.

It is not necessary to create something you want to call a "framework layer class" and a completely different "implementation layer class" when you start developing an Application.

Note the figure in this discussion.

You can create a class that serves as both your "framework" and "Implementation" class initially.

Only if and when the need arises to have a second implementation-layer class do you need to create a second implementation layer class.

Prior to creating that second class you would create a "wrapper" Application for your first implementation.  First you create a ruleset that declares a dependency the ruleset in which the current framework/implementation class was created -- temporarily adding it to your current Application.  Next save the current Application to that ruleset renaming the Application appropriately. After doing so, modify the new Application to say it is built on the current Application then remove every ruleset except the newly created one. Finally remove that new ruleset from the original Application. Easy,

From this point on, being that there are now two implementations dependent on the same frameworkruleset, care must be taken whenever changes are made that framework ruleset.  This is no different than making changes to a base class that multiple classes extend.

Note that the first implementation Application need not override the framework Application's Case Type rules.  The second implementation Application cannot avoid having to override the framework's Case Type rules since it has a different class.