Red Hat’s Docling field kit separates tested OpenShift AI paths from promising prototypes

A new Red Hat AI Americas reference repository turns Docling document conversion into a menu of OpenShift AI 3.5 deployment patterns rather than a single demo. The docling-applied project covers direct SDK use, command-line conversion, a REST service and batch pipelines, then extends the same foundation toward serverless APIs, event-driven ingestion, retrieval-augmented generation and agent tool use.

The useful part is not simply the number of examples. It is the boundary the maintainers draw between paths they present as ready to try and paths that still need validation on a real OpenShift AI 3.5 cluster.

Four starting points, not one prescribed architecture

The repository’s main README identifies four primary quickstarts. Developers can call the Docling SDK directly in a workbench, run one-off conversions through the CLI, deploy the upstream docling-serve REST API, or convert an object-storage bucket through a Kubeflow Pipelines workflow.

That progression gives platform teams a practical choice about where document conversion belongs. A notebook or CLI is enough for exploration; the service path creates a shared cluster API; and the pipeline path fits scheduled or repeatable ingestion. The project includes architecture notes, prerequisites and configuration references under its docs/ directory, while the root Makefile coordinates installation, builds, tests and deployment across the examples.

The setup deliberately uses Red Hat’s OpenShift AI 3.5 Python package index as its primary source and pins Python 3.12 because that is the version for which the index publishes wheels. The README says public PyPI remains a fallback where the Red Hat index lacks a package for the local platform.

The warning label is part of the design

Four more patterns live under pending-redhat-testing: a custom FastAPI service on Knative Serverless, CloudEvents-based ingestion with Knative Eventing, a RAG flow using OpenShift AI Llama Stack, and an MCP server that lets an agent invoke Docling. The maintainers describe those as complete quickstarts but explicitly say they have not yet been confirmed against a real OpenShift AI 3.5 cluster.

That distinction matters. It lets teams inspect the intended architecture without confusing working reference code with a supported production blueprint. The repository also warns users to verify image references, resource sizing and fast-moving API surfaces before relying on the examples in customer environments.

What to try first

For a low-risk evaluation, this desk would follow the project’s own sequence: run the direct SDK example, deploy docling-serve, and then choose batch, request-driven, event-driven, RAG or MCP integration according to the workload. The commit history shows the repository was assembled and corrected across September 23–24, including a fix to the REST example and the move of unvalidated quickstarts into the pending area.

The result is a useful field artifact precisely because it exposes its maturity boundaries. Teams get several concrete OpenShift AI shapes to test, while the repository makes clear which ones still need proof on-cluster.