While this is definitely needed, I have my doubts about cramping everything into one kind. Are we going to make that table huge?

For example, @LeoWandersleb wants to position himself as a reproduceable attestation service provider. He's drafted an event for this response which would be too complicated for inclusion here.

Same for WoT, it is a contentious topic and I'm not even sure what 0-100 means. The response would likely require more data than an integer.  @pippellia 

Something like the DVM NIP that uses sub-kinds might be more useful. 

 I agree. We don't need to put everything on 30382. 

What we do need is to specify what the "service" is calculating so that the user can chose which provider of that calculation they trust and clients can know what the value means.

There will be some differences between providers, but the goal and the final result spec (type, range, tags, etc) should be just one. 

Hopefully this NIP enables that multiple provider specification to come together.  

 >  final result spec (type, range, tags, etc) should be just one

Did I understand correctly - you want to include type, range, tags etc for each service into this NIP? 

 In the early days, yes. As it grows we can break it off. 

Right now we just need to start the work of specifying stuff.