Colleagues, I am requesting a formal review of P4003R3, "A Minimal Coroutine Execution Model." It is published in the May 2026 mailing, so it is eligible under the rules, and I would like it read closely before it next goes to LEWG. Please all read the same revision so the summary attaches cleanly to a published artifact: - **Paper under review - P4003R3:** https://wg21.link/P4003R3 - **Design companion - P4172 (rationale, alternatives, preemptive objections):** https://wg21.link/P4172 - **Umbrella - P4100 (the Network Endeavor):** https://wg21.link/P4100 - **Implementations:** Capy (https://github.com/cppalliance/capy) and Corosio (https://github.com/cppalliance/corosio) - **Self-contained demo:** https://godbolt.org/z/Wzrb7McrT What the paper proposes The paper asks LEWG to advance the *IoAwaitable* protocol as a standard coroutine execution model. It starts from the smallest possible use case, `co_await f();`, and observes that for this to work something must decide three things at the moment a coroutine suspends: 1. Who resumes it, and where (executor affinity). 2. Whether it should stop (stop token propagation). 3. Where its frame is allocated (frame allocator delivery). The protocol provides exactly those three things and nothing more. It is positioned as a companion to `std::execution` (P2300), not a replacement: each serves the domain where its design choices pay off. What I am asking you to evaluate Reviews here are informational. There is no verdict and no gate, so please do not feel you are voting the paper up or down. What I would most value is an honest read on four questions. **1. Is it worth standardizing?** Does this belong in the standard, or can it live as a library? The central claim is that a small normative protocol unlocks a large amount of interoperable user code (the "What We Get" table in Section 2). Is that interoperability argument convincing? Is the benefit worth the committee time and the standard surface it would consume? **2. Did the use of AI affect your perception?** This paper, and the review program you are reading this on, were developed with heavy AI assistance, and I am not hiding that. I want to know candidly whether knowing or suspecting that changed how you read it. Did it raise or lower your trust? Did you go looking for tells, and did you find any? Did it make you more or less rigorous than you would be with a paper written entirely by hand? I would rather you name this in your review than leave it unsaid. The answers matter as much to me as the technical feedback, and they will shape how the Network Endeavor and this program handle AI-assisted work. **3. What is the technical quality?** Are the concepts sound and precisely stated? Do the central claims hold up - zero per-operation allocation under type erasure, symmetric-transfer resumption, automatic frame-allocator propagation, and the structured-concurrency argument in Section 5? Is the implementation evidence (Capy, Corosio, the benchmark table, the Compiler Explorer demo) credible and reproducible? Where is the reasoning weakest? **4. What is missing?** What would you need to see before LEWG could act on this? I am looking for gaps in specification or wording, unaddressed edge cases, missing comparisons (against existing coroutine task libraries, or other parts of `std::execution`), lifetime or cancellation corners, threading hazards, and anything the paper moves past too quickly. Tell me what you went looking for and did not find. Thanks