oci-data-science-ai-samples: What the Oracle Sample Repo Actually Gives You
This repo contains a series of tutorials and code examples highlighting different features of the OCI Data Science and AI services, along with a release vehicle for experimental programs.
At a glance
- What is it?
- Oracle's UPL-1.0 sample repository is a collection of Jupyter notebooks and Python SDK snippets for OCI Data Science and AI services, not a library you install. It is most useful when you already have an OCI tenancy and need a working reference for ADS, conda environments, Jobs, Pipelines, or model deployment artifacts.
- Who is it for?
- Adopt this repository as a reference if you are already running workloads on OCI Data Science and need concrete examples for ADS, conda environments, Jobs, Pipelines, distributed training, or the score.py and runtime.yaml pair that the Model Catalog requires. Do not adopt it if you want a framework, a local development kit, or vendor-neutral code: nearly every sample assumes OCI services, an OCI tenancy, and the ADS SDK.
- Can I use it commercially?
- Yes. UPL-1.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly Jupyter Notebook, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What problem the repository solves, and for whom
OCI Data Science is a managed service, and managed services are hard to learn from API documentation alone. The gap this repository fills is the distance between an API reference and a working notebook. Oracle states the intent plainly: the repo exists "to make demos, tutorials, and code examples that highlight various features of the OCI Data Science service and AI services." The audience is therefore narrow and specific. You are a data scientist or ML engineer who already has an OCI tenancy, or you are evaluating whether OCI Data Science can host a workload you currently run elsewhere. If neither is true, the material will read as a tour of services you cannot exercise. The repository is also positioned as "a release vehicle for experimental programs," which is worth reading literally. Some directories track features that are newer than the surrounding documentation, and the samples are the primary artifact rather than a polished product. The README invites feedback through GitHub issues and points contributors at a CONTRIBUTING.md file, so the project is maintained as an open sample set rather than a support channel.
How the repository is organised, and what that tells you
The layout is topical rather than layered. Notebook examples sit under notebook_examples and cover the Accelerated Data Science (ADS) SDK, with the README citing vault.ipynb as an example of storing secrets in OCI Vault. A separate conda_environment_notebooks directory is organised around conda environment families, because the service uses conda environments to manage the libraries a notebook can use. The labs directory holds end-to-end training and deployment walkthroughs. LLM material is split three ways: AI Quick Actions for fine-tuning, deployment and evaluation without writing code; a LangChain integration exposed through ADS; and direct Python coding inside the service. model_catalog_examples is the most operationally concrete section, since the Model Catalog requires you to supply a score.py file that loads the model and a prediction function, plus a runtime.yaml that describes the conda environment used at deployment. compute-target holds OCI Python SDK samples for creating a Managed Compute Cluster Compute Target and a model deployment that uses an existing Compute Target. capacity-reservation-discovery is explicitly read-only reporting tooling that validates the installed OCI Python SDK and CLI expose the required API fields before running discovery. Jobs, distributed_training, and pipelines round out the set. That structure is a map of service surface area, not a dependency graph: nothing in the repository is designed to be imported as a package.
The mechanism: notebooks plus SDK calls, not a runtime
There is no build step and no installed component. The primary language is Jupyter Notebook, and the samples work by calling OCI services through the ADS SDK or the OCI Python SDK from inside a notebook that runs in the OCI Data Science service. The data flow in a typical sample is: authenticate against your tenancy, construct a client or an ADS object, invoke the service (Vault, Model Catalog, Jobs, and so on), and inspect the returned object. The Model Catalog path is the clearest illustration of the contract, because it is not just a notebook pattern. You produce a score.py that loads the model and exposes a prediction function, and a runtime.yaml that names the runtime conda environment for deployment. ADS helps you create the artifacts, but the README is explicit that you must provide these files yourself. That is the real shape of the work: the repository shows you what a correct artifact looks like, and you still have to write yours. The same applies to compute targets and capacity reservation discovery, where the samples are Python SDK scripts that create or report on resources rather than libraries that abstract them.
Getting it running: what the material actually specifies
The README does not give a clone command, an install command, or a pip line. It links out to the ADS SDK documentation at docs.oracle.com and to the OCI Data Science service page, and it describes the conda environment model rather than enumerating environment names. So the honest starting procedure is: clone the repository, open the notebook directory that matches your task, and read the notebook's own setup cells for the environment it expects. The concrete, verifiable pieces of configuration in the material are the artifact filenames. score.py and runtime.yaml are named requirements for Model Catalog deployment, with runtime.yaml carrying the runtime conda environment information. For capacity-reservation-discovery the README states that the sample validates that the installed OCI Python SDK and CLI releases expose the required API fields before running discovery, which means you should check your SDK and CLI versions before trusting the output. Everything else, including credentials, region, and compartment identifiers, is tenancy-specific and is not spelled out in the README. Treat each notebook as self-documenting and read its first cells before running anything.
Where it stops being the right tool
The clearest limitation is coupling. Almost every sample assumes OCI services and the ADS SDK, so the code is not portable to another cloud or to a local-only workflow. If you want to prototype a model on your laptop and decide about infrastructure later, this repository adds friction rather than removing it. A second limitation is version drift. The repository publishes versioned releases (5.0, 4.2, 4.1) rather than a continuously versioned package, and the samples follow the latest public OCI Python SDK and CLI in at least the capacity-reservation-discovery section. A notebook written against one release can reference API fields or service features that behave differently in your tenancy, and the README gives no compatibility matrix. Third, the LLM section is a pointer set rather than a tutorial: it tells you that AI Quick Actions, an ADS LangChain integration, and direct Python coding exist, and sends you to external documentation for each. If you need a worked fine-tuning example with data preparation and evaluation, the repository does not obviously provide one in the README text. Finally, the material is documentation-adjacent sample code. There is no test suite described, no CI signal in the README, and no support commitment attached to the samples themselves.
Alternatives and the actual difference in approach
The natural comparison is to vendor-neutral notebook collections and framework documentation. A scikit-learn or PyTorch tutorial set teaches the modelling technique and leaves infrastructure to you; this repository does the opposite, teaching the service integration and assuming you bring the modelling knowledge. If your goal is to learn gradient boosting or transformer fine-tuning, the framework docs are the better first stop, because the OCI samples are about wiring models to managed services. Within the Oracle ecosystem, the ADS SDK documentation at docs.oracle.com is the reference layer, while this repository is the example layer; when the two disagree, the SDK documentation is the authority and the notebook is the demonstration. For teams already committed to a different cloud, the equivalent managed-service sample repositories from that vendor are the honest alternative, because the value here is OCI-specific API surface, not portable technique. The distinguishing feature of this repository is that it shows the full artifact contract for deployment, including score.py and runtime.yaml, which general framework tutorials do not cover at all.
Licence, maintenance, and what upgrading costs you
The repository is licensed under UPL-1.0, the Universal Permissive License. That is a permissive licence, but it is not identical to Apache-2.0 or MIT, and the specific terms matter if you intend to reuse code in a commercial product. Read the licence text and, if the distinction affects your organisation, get it reviewed; this article is not legal advice. On maintenance, the observable signals are the release cadence and the last push date. The repository shows releases 5.0 in February 2026, and 4.2 and 4.1 in October 2025, with the most recent push in September 2026. That pattern suggests active upkeep rather than abandonment. The upgrade cost is not a dependency bump. Because the repository is a sample collection, upgrading means re-reading the notebooks you depend on against the release you are targeting and re-checking that the service APIs they call still behave the same way in your tenancy. The capacity-reservation-discovery section is the one place the material hints at a mitigation: it validates that the installed SDK and CLI expose the required fields before it runs, which is a pattern worth imitating in your own scripts. Nothing in the README describes a deprecation policy for individual notebooks, so pinning to a release tag and reading the diff between tags is the only reliable way to know what changed.
Editorial conclusion
Adopt this repository as a reference if you are already running workloads on OCI Data Science and need concrete examples for ADS, conda environments, Jobs, Pipelines, distributed training, or the score.py and runtime.yaml pair that the Model Catalog requires. Do not adopt it if you want a framework, a local development kit, or vendor-neutral code: nearly every sample assumes OCI services, an OCI tenancy, and the ADS SDK. Before copying anything into a project, check the release tag against the service features you depend on, because the repository ships as versioned releases (5.0, 4.2, 4.1) rather than a continuously versioned package, and confirm that your conda environment matches the one a given notebook was written for.
Community notes