While I think this particular sketch isn't going anywhere without a lot more work on concrete implementation details, I do believe it is well worth spending time on what a working formalism of development would look like built atop the first principle of "there are no estimates".

No existing methodology in practice works like this.

If you asked developers why this is the case, they would point out that at the high level, business deals are made in the shape of pay X for Y by time Z, while at the low level managers carry out the same internal deals of deliver Y at cost X by time Z, whether day by day or project by project.

Nonetheless, I agree with the basic idea that estimates in software development cannot be given with any reliability at all. The corollary there is that the client never receives what they asked for in anything but the high level sense. Every single deal is basically a polite fiction that is renegotiated at length all along the way.

Given that this is already the case, and people kludge their way through to make a business of it, whether kludging at the large scale with waterfall or kludging at the low level with agile, one has to imagine that there is a distinct, different way to actually surface and incorporate the absence of estimates top to bottom in the process of business and development, and thereby reduce friction and waste.