[CNCF LFX Proposal] Resource State Metrics: Extract and enforce shared behaviors between resolvers

### CNCF Project

Kubernetes

### Term

2026 Term 3 (Sep-Nov)

### Program Name

Extract and enforce shared behaviors between resolvers

### Program Description

One of the most prominent selling points of [`kubernetes-sigs/resource-state-metrics`](https://github.com/kubernetes/enhancements/issues/4785) is its extensibility, allowing it to support a number of DSLs as the community deems.

At the moment, there are three resolvers supported in the subproject, in increasing order of their ability to deal with complex tasks: [`unstructured`](https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured#NestedFieldNoCopy), [CEL](https://github.com/cel-expr/cel-go), and [Starlark](https://github.com/bazelbuild/starlark). Every resolver is required to implement a `Resolver` interface, with a single `Resolve` method, specifying a signature that helps set the same expectations when sending queries and receiving resolutions from these resolvers, so the same wrapper code can work with any `Resolver` implementation that is plugged into it.

However, there is room for improvement for this particular interface. Essentially, we'd like for this to be broken down into methods that track the implementations on a much more granular level. Output resolution for various composite data-types, as well as unique traits such as underscore replacement for unsupported runes are eligible candidates for shared behaviors that should be abstracted.

Ideally, the \ (see below) should detail the specifics of such gaps in the common behaviors between resolvers today that can be surfaced to the interface and how they will be addressed, for a much better onboarding experience for more resolvers in the future.

_Please note that we're actively looking for long-term contributors to the project (as it's relatively new, and still in BETA) through the means of the LFX project, and we'd like for someone with similar expectations to drive this task, who'd later be interested in joining the maintainer team as well, but this is not a requirement._

### Technologies

Go, Kubernetes, Observability

### Skills same as Technologies?

- [x] Yes, the required skills are the same as the technologies listed above.

### Required/Desirable Skills

_No response_

### Mentors

Pranshu Srivastava | @rexagod | rexagod@gmail.com | rexagod
Manuel Rüger | @mrueg | manuel@rueg.eu | ManuelRueger

### Upstream Issue URL

https://github.com/kubernetes-sigs/resource-state-metrics/issues/15

### Application Prerequisites

- [x] Resume
- [x] Cover Letter
- [ ] School Enrollment Verification
- [ ] Participation Permission from school or employer
- [ ] Coding Challenge

### Coding Challenge URL

_No response_

### Custom Prerequisites

- [x] Custom Prerequisite (fill in details below)

### Custom Prerequisite Name

Prior contributions

### Custom Prerequisite Description

Substantial patches in Kubernetes, Prometheus, or OTel demonstrate understanding of the O11y ecosystem. While not mandatory, they give maintainers confidence in your experience.

Without prior patches, offset this with a detailed custom prerequisite file explaining your technical approach. Note that past interaction with maintainers also carries weight.

### Custom Prerequisite — File Upload

- [x] Yes — completion of this task requires the mentee to submit a file.

---
**LFX program:** [CNCF - Kubernetes: Extract and enforce shared behaviors between resolvers (2026 Term 3)](https://mentorship.lfx.linuxfoundation.org/project/352c0c5d-ab96-4e12-bf6e-0ebcd4bf8ca6)

Begin with upstream issue #15 and the Resolver interface described here; inspect the unstructured, CEL, and Starlark implementations and compare their shared behavior. Document the gaps and acceptance criteria in the custom prerequisite file, then confirm the proposed interface accounts for composite outputs and underscore replacement without breaking existing resolvers.

Written by the indexing model from the issue text.