Expose trace interface in scorers

[Qard]

Only possibly controversial thing in here is exposing the btql API publicly when it only supports AST/object mode--there's no builder yet.

Refs braintrustdata/braintrust-sdk#1060

[CLowbrow]

I don't think we want to do it like this anymore. The way these are generated in the main SDK and in the data plane is by calling invoke on a preprocessor:

• https://github.com/braintrustdata/braintrust-sdk/blob/main/js/src/trace.ts#L381
• https://github.com/braintrustdata/braintrust/blob/main/api-ts/src/wrapper/trace.ts#L122

I don't know if we have support for these invoke calls in this or other non-main repo SDKs so we might want to skip this method for now?

[delner]

This adds significant complexity in that it:

1. Adds caching to global state
2. Adds multi-threading/synchronization behavior between workers
3. Couples tracing to Evals and reaches deeply into internals in the process

Many of these things have potential for significant impact on performance and stability, as well as scaling the software without harming the prior two categories. Before we merge, I would like to review the requirements, design goals, and patterns more thoroughly. Let's talk.

[delner]

I don't think this belongs here: Eval::Runner concerns running evals, not building trace contexts.

[delner]

Why does a scorer take a trace context?

[delner]

Per our conversation yesterday with @CLowbrow, we should not use a span cache for the purposes of piping trace content between tracing and evals locally because:

1. Spans may be mutated once they reach Braintrust (become stale locally)
2. Distributed tracing means the set of spans will be incomplete (need to query the API anyways)
3. Eval for the trace may not run locally at all (wasted memory)
4. Performance impact of caching spans is potentially high
5. This creates a hard coupling between tracing and evals (which are meant to be severable)
6. The overall complexity of the feature makes it difficult to reason about, refactor, and may affect the stability of the SDK.

Per my analysis, we should:

1. Remove write_to_cache from SpanProcessor entirely. The tracer generates and submits spans via OTel only (no local buffering for Evals)
2. Remove SpanRegistry — it only exists to bridge Trace → Eval.
3. TraceContext.get_spans should always go through BTQL. It can cache the BTQL response locally, but that cache is populated by API results, not by the tracer.
4. Eval::Context should not own a SpanCache that the tracer writes to. If caching is needed, it should be scoped to TraceContext and populated from BTQL only.
5. eval.rb should not import anything from trace/.

[delner]

When would scorers not exist? (I would think that if you run an Eval you would want to score it?)

[Qard]

Might not be using local code scorers though, right? Could just be getting scored in our backend.