OpenMetrics Discovery Format

I wanted to start a discussion on an idea that could fit in well with OpenMetrics.

I've spent a lot of time recently looking at metrics exported by various applications (mainly K8s components) and trying to find the metrics that are available.
Most of the time this involves looking through the code of the respective application and hoping all metrics exported about a topic are defined in a single source file and easy to find.
The other option is to run the respective application and hope all metrics are always exported (none of them are only exported in certain conditions).

This seems like a usability issue.
Other APIs have solved this with e.g. OpenAPI, gRPC/Protos and I'd like to view metrics more like another API surface too.
So what do people think about a formal OpenMetrics Discovery Format?
A way for applications to specify the metrics they export in a structured, human and machine readable format.

It would help operators decide which metrics they care about and identify potential gaps in the monitoring surface of an application.
For Prometheus specifically it would help operators get a better understanding of the load an application might generate and what metrics to filter for.

It could also help developers as they have a structured single-point of truth allowing them to detect breaking changes in their metrics API, depending on how this is realized (this would probably require some sort of code generation).

It could be served either at runtime (similar to openapi) which is probably easier to implement, or shipped as a file with the code (which would be easier for end users).

Is anyone aware of a discussion like this in the past, has something it it been proposed before?

No files, tests, or entry points are named. Start by reviewing prior discussions or proposals about an OpenMetrics discovery format, then establish the format's scope and delivery approach; the issue provides no concrete completion criteria.