Skip to main content
We no longer recommend authoring behavior rubrics by hand. The Docent plugin generates Reading steps inside an Analysis Plan for you. This page is kept for users with existing rubrics.
Docent helps you create and optimize LLM-based judges that evaluate agent runs against your criteria. A rubric is a configuration object that defines how a judge works, and a judge is a callable that evaluates an AgentRun using that rubric configuration. You can create and manage judges directly in the Docent web UI. This page focuses on the underlying data model and how to use the SDK to create and run judges programmatically.

The Data Model

A rubric defines the complete configuration for a judge. Here’s an example:
Let’s break down each of the key configuration options shown above.

prompt_templates

A list of messages that form the judge’s prompt. Templates must collectively include all three variables: {agent_run}, {rubric}, and {output_schema}. Variables can be distributed across multiple messages in the list.
Template Variables Prompt templates must collectively include all three of these variables, which are automatically substituted: Validation will fail if any required variable is missing or if templates contain other undefined variables. {output_format_instructions} is optional — include it only if you want the prompt to surface format-specific guidance to the judge.

rubric_text

The core evaluation criteria that the judge follows. This text is substituted into the {rubric} template variable in the prompt. Write clear decision procedures that the judge can follow step-by-step. Be specific about what constitutes success or failure.

output_schema

A JSON schema defining the structure of the judge’s output.
Metaschema Rules We will post a link to the full JSON metadata schema soon. In the meantime, judge output schemas must generally follow these rules:
  • Root must be type: "object" with properties
  • additionalProperties is optional, but if present must be false
  • Supported types: string, integer, number, boolean, array, object (recursive objects are allowed)
  • Arrays require an items schema; objects require properties
  • Special: "citations": true on string fields enables transcript references
  • anyOf, oneOf, allOf are not supported
Labels share this meta-schema. Label sets, which define structured annotations for agent runs, use the same meta-schema validation. Any schema you define for a label set must follow these same rules.
Example with Citations
When "citations": true is set on a string field, the judge must include citations to specific parts of the transcript in its response. The Docent web UI automatically parses and links these citations. SDK users must manually convert results using JudgeResultWithCitations.from_judge_result() to resolve citation references.

judge_model

Specifies which LLM to use for evaluation. Uses ModelOption with provider, model name, and optional reasoning effort.
Supported Providers Model Names Any model from the supported providers can be used as a judge. Use the exact model string that the provider uses:
  • OpenAI: gpt-4o, gpt-4o-mini, o1, o3-mini, etc.
  • Anthropic: claude-sonnet-4-5, claude-sonnet-4-20250514, etc.
  • Google: gemini-2.0-flash, gemini-1.5-pro, etc.
  • OpenRouter: Uses a different format with the provider prefix, e.g., anthropic/claude-3-opus, openai/gpt-4o
Reasoning Effort Some reasoning models support a reasoning_effort parameter that controls how much computation the model uses. Typical values are minimal, low, medium, and high. Not all models support this parameter—it is primarily available for OpenAI’s reasoning models (o1, o3-mini, etc.).

output_parsing_mode

Defines how the LLM output is parsed:
  • XML_KEY (default): Extract JSON from within XML tags (e.g., <response>...</response>). When using this mode, at least one prompt template must contain the XML tag <{response_xml_key}> (e.g., <response> by default).
  • CONSTRAINED_DECODING: Parse entire output as JSON (uses structured output). Supported by OpenAI, OpenRouter, and Anthropic. Not yet implemented for Google (will raise NotImplementedError).

response_xml_key

When using XML_KEY parsing mode, specifies the tag name to extract the response from. Defaults to "response". Note: At least one prompt template must contain the corresponding XML tag (e.g., <answer>...</answer> if using response_xml_key="answer").

output_format

Selects the serialization format the judge is instructed to emit and that the SDK parses. Supported values are "yaml" (default for new rubrics) and "json".
The {output_format_instructions} template variable, when present in a prompt template, is substituted with format-specific guidance derived from this field (for example, instructions on escaping for JSON or yaml.safe_load-compatible output for YAML). Output is still validated against output_schema regardless of format.
Rubrics created before the output_format field existed continue to behave as if output_format="json" was set, preserving backward compatibility.

SDK Methods

create_rubric()

Upload a rubric to a collection. Returns the rubric ID.

start_rubric_eval_job()

Start a rubric evaluation job for agent runs in a collection.
Use the method below to track the job progress and retrieve the results.

get_rubric_run_state()

Retrieve the current rubric evaluation results and job progress. This method does not start evaluation; use start_rubric_eval_job() first.
The response includes the current grouped judge results in results, plus progress metadata such as job_id, job_status, total_results_needed, and current_results_count while a job is still running.

get_rubric()

Retrieve a rubric configuration object by ID. Optionally specify a version.

get_judge()

Get a callable BaseJudge instance for running evaluations. Optionally specify a version.

list_rubrics()

List all rubrics in a collection.

Running the Judge

The build_judge function creates an async callable that wraps LLM providers. It takes a Rubric configuration and an LLM service, and returns a judge you can call directly on any AgentRun.
The BaseLLMService reads API keys from environment variables depending on the model provider:
  • OpenAI: OPENAI_API_KEY
  • Anthropic: ANTHROPIC_API_KEY
  • Google: GOOGLE_API_KEY
  • OpenRouter: OPENROUTER_API_KEY

JudgeResult

The judge returns a JudgeResult object with these fields: