fix: add a guardrail for TSDB requirement

[tremes]

No description provided.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tremes
Once this PR has been reviewed and has the lgtm label, please assign xiormeesh for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[iNecas]

Works for me. @saswatamcode any objections?

[saswatamcode]

Not blocking here, but is this really a guardrail?
To me, a guardrail is something that blocks or guides the LLM away from certain actions.

Looks like this guardrail is more a workaround for categorizing other guardrails?

How about instead we have some guardrail type like

type Guardrail struct {
    Name string
    RequiresTSDBEndpoint bool
}

And refactor a bit so our Guardrails type is basically a slice of []Guardrail?
So, certain guardrails of type TSDB (or Cardinality?) can be disabled via some flag?

Wdyt @tremes @iNecas?

Again not blocking, if this is needed for urgent testing, fine to merge and iterate :)

[tremes]

@saswatamcode I tried the alternative with using map of gurardrails (I think it's better for lookup) #47, but not sure if it's not too much & too much verbose.

[tremes]

Closing in favor of #47