Google Cloud's open-source project dgem has made its first public release. Developers automating customer inquiry or security alert classification can use answer probabilities and uncertainty scores to separate immediate actions from cases needing review. The release also covers questions with many options and stronger request authentication.
1. Read probabilities for each option instead of generating sentences
dgem uses DiffusionGemma as a decision engine that selects answers from options, rather than a free-form text generator. Developers define boolean, choice, and scoring questions in policy templates containing decision rules. A single model computation reads multiple questions and returns each answer's probability. This reduces the need to reinterpret answer text, making results easier to use in automation.
Each answer comes with an entropy-based hesitation score showing how widely probability is spread across options. Low scores allow immediate processing; high scores trigger a handoff to a larger model or a human. The default follow-up model is Gemini 3.8 Flash.
The repository says policy templates can be edited to change decisions, unlike classifiers that require retraining for new categories. Compared with free-form generation models, the focus is on reading probabilities of allowed answers directly for downstream processing.
2. Narrow down large candidate sets and incorporate prior information
This version adds a path for questions with more than 26 options. A single model computation reads the top candidates and a combined remainder entry. When mapping probabilities back to all options, it retains the candidate set's normalized uncertainty score, adjusted for differences in option count. Without prior probabilities, likelihood information available before a decision, it uses a two-stage tournament that splits the candidates into groups.
Prior probabilities add other signals to model decisions. The timing of the combination and the influence of the two sources can be configured.
An experimental label set, a collection of names assigned to answer options, also supports reading up to 52 options at once. The default label set remains at 26.
3. Stronger request authentication and image retrieval paths
Operators can configure IAP authentication, Google's access control service, or API key authentication on the gateway that relays requests. The gateway identifies callers from verified credentials rather than client-supplied identity headers, request fields containing caller information.
The serving image, a deployable file containing the environment that runs the model, can have an optional service key. When configured, POST requests require a matching key header, while health-check routes remain accessible without a key.
The gateway handles image URLs, and the serving image rejects image inputs from web URLs by default. This reduces the risk of requests being redirected to internal addresses when the model server can access external networks.
Both the serving image and gateway reject audio and video inputs. Users are instructed to send video as image frames and audio as transcripts.
4. Handle request rejection differently from server failures
When the model server rejects a request, the gateway forwards a rejection response rather than treating it as a generic server error. Rejected decision requests return 422 instead of 502 and are not retried. The gateway retains 502 when the actual server cannot be reached.
The adapter, a component connecting different request formats, processes scoring questions alongside other questions in batches of up to 8. Questions with only one option are answered without a model call.
The evaluation tool for comparing existing and new deployments now includes server processing time metrics. Alongside total elapsed time, it shows the times within which 90, 95, and 99% of requests are processed, helping identify delays inside and outside the server.
Gateway request and response body logging is off by default. It can be enabled selectively for a specified caller and end time, limiting troubleshooting to the necessary scope and period.
5. Review rates and deployment preparation are key to adoption
The two-stage handoff based on hesitation scores now includes a normalized threshold that adjusts for differences in option count. The existing default is 0.35 in natural-log units, using logarithms with base e, while the normalized threshold is 0.16. In the company's reported test configuration of 341 cases, normalization handed off 31% of decisions to the next stage, versus 22% under the existing threshold. These values do not represent the same operating point, so thresholds need tuning for real traffic.
The expanded features offer control over the boundary between automatic processing and further review. Settings that hand more decisions to a follow-up model or humans increase their workload. Operators must tune thresholds with real data and configure keys and deployment environments for their chosen authentication method.
The features are available through a command-line tool, a program controlled by typed commands, an HTTP gateway, an MCP server for external tool integration, and a browser interface. Prebuilt serving images are not yet available, so users build them in their own Google Cloud projects.
Below is the repository's example for building the command-line tool. To obtain this release's version label, check out the v0.4.0 tag before building.
# Clone the repository
git clone https://github.com/GoogleCloudPlatform/dgem.git
cd dgem
# Compile dgem binary into bin/
make builddgem v0.4.0 connects answer probabilities to operational workflows and protects them with authentication and error controls, while results depend on tailoring deployment and decision thresholds to each environment.