That's is true. However, I should have been more clear about my actual question. I understand caveats can do this but the docs clearly explained that you moved away from caveat-based expiration because it: 1. Requires clients to provide timestamps (added complexity) 2. Doesn't garbage collect automatically (performance/storage issues) 3. Increases evaluation costs with many caveated relationships If these were significant enough to justify native expiration support, wouldn't the same logic apply to native start support as well? Saves me from having to increase complexity of managing providing timestamp context.