[adi-kumo]

Adds a Databricks quickstart for Kumo Tabular, next to the relational one. It deploys the model to a one-GPU Model Serving endpoint that scales to zero, loads the AdventureWorks products table, and asks three questions of it: which color a product has, what its list price is, and the color question again as a predictive query. Each answer is checked against the recorded value and compared with a simple rule. The notebook is saved with the outputs of a real run.

The tabular model is the one registered in Unity Catalog as kumo_tabular. Its 16 MB limit message used to talk about entities, which a one-table request does not have, so that wording is made model-neutral too.

Changes

• examples/databricks/kumo_tabular_quickstart.ipynb: the notebook, with every Unity Catalog name part quoted so hyphenated catalogs work.
• The refusal for a request over 16 MB now says fewer context rows or fewer rows to score for a tabular request (databricks_serving.py), with matching text in docs/reference/limits.md and the quickstart, a changelog line, and tests.
• Saved outputs are from the run below. The catalog, schema and endpoint names in them are the notebook's defaults. The %pip cell's output is left out; it only repeats the protobuf notice the text explains.
• Example 2's text says the price question is an easy one, because the table's standard cost tracks the list price.

Testing

Run on Databricks (EDSP workspace), 2026-10-22 UTC (2026-10-21 local): one-time job run 107355698597869, task run 923635785761350, serverless environment version 5 (client.5.12), Python 3.12.3, pandas 2.2.3, numpy 2.1.3, databricks-sdk 0.156.0, client, api, pql and connectors built from this branch at f5ae890 (1.0.0). The notebook created the endpoint (GPU_MEDIUM, Small, scale to zero) for Kumo Tabular version 1 and ran from top to bottom in 2.7 minutes, because the endpoint image was already cached from an earlier deployment of the same model. A first deployment took about 18 minutes in an earlier smoke test. The only differences from this notebook were the install cell (wheels from a Volume, as the package is not on PyPI yet) and the constants (that workspace's model, catalog and schema, and a throwaway endpoint name). The cells are otherwise unchanged. After that run only Example 2's text and the saved outputs changed. The endpoint was deleted afterwards.

What the run showed:

• Example 1: 47 of 60 colors correct; always guessing the most common color (Black) gets 21.
• Example 2: average error $2.63 on the list price; always guessing the median ($337.22) is off by $544.46.
• Example 3: 47 of 60, equal to Example 1's count, as the text says.
• Step 8 with 200 context rows: average error $2.58.
• The probability columns are named probability_<color>, one per color, as the text describes.

Also run for this PR: ruff check, ruff format --check, scripts/check_repo_hygiene.py all, and the five-package pytest suite (2179 passed, 330 skipped), which includes the Databricks notebook tests. The engine suite is not affected.

Follow-ups

• The install cell installs from PyPI, so the notebook only runs as written once this client is released.
• Splitting a large tabular request by bytes, rather than only refusing it, is not part of this PR.
• Over Databricks the client sends rows as arrays; Arrow was tested with raw requests and is about 3.6 times smaller. A client-side Arrow encoding would raise the column limit at 10,000 rows from about 84 to about 310.

🤖 Generated with Claude Code