# Oracle's sample repo is half tutorials and half pipeline definitions

> This repository holds Oracle's examples for OCI Data Science and AI services: JupyterLab notebooks, end to end labs, and a set of directories that sit closer to pipeline definitions than to tutorials. Licensed UPL-1.0, with a VERSION file and its own release cadence, it doubles as a release vehicle for experimental programs. The defects are as informative as the content, because the README links a notebook directory that does not exist in the tree.

**oracle-samples/oci-data-science-ai-samples** — 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.

- Repository: https://github.com/oracle-samples/oci-data-science-ai-samples
- Stars: 301 · Forks: 234
- Language: Jupyter Notebook
- License: UPL-1.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/oracle-samples-oci-data-science-ai-samples

## The README links a notebook directory the tree does not contain

Start with a documentation defect, because it calibrates how much of this repository you should trust at face value. The Notebook Examples section points its heading at ./notebook_examples/, and that directory does exist at the top level. But the sentence inside the same section links the vault notebook as ./ads_notebooks/vault.ipynb, and there is no ads_notebooks directory anywhere in the listing. One of the two is stale, and the README does not say which is current. Two more small blemishes sit in the Large Language Models section. The heading itself is malformed markdown, with a closing bracket and no opening one, so it renders as literal text instead of a link, and the body ends with a link whose text is simply here. None of this breaks the service or the examples, and all of it is the kind of thing that tells you the README was edited in place over a long period rather than generated from a checked structure. There is a VERSION file at the root, so somebody is tracking state; it is just not the README.

## VERSION sits at 5.0 while main has moved for months

The release history here is unusual enough to plan around. Three releases are visible: 4.1 and 4.2 both published on 2025-10-09, the second one about half an hour after the first, and 5.0 on 2026-02-28. Two releases in a single morning followed by a seven month gap is the shape of a repository that gets version-bumped when a batch of examples is ready rather than on a schedule. The last push to main was 2026-09-05, which means the tagged 5.0 line describes a February state while the branch has moved on through seven months of work. Nothing is archived and the default branch is main, so this is not a dead repository; it is one where you should treat the release tags as snapshots of example sets rather than as a versioned product. That distinction matters most for the frameworks listed later, since a distributed training example that has moved on by two releases may target a different base image than the one you find under the tag. Read the directory, not the version number.

## One Node dependency, and a pre-commit setup that scans for secrets

The root package.json is three lines long and contains exactly one dependency, oci-sdk at version 2.50.3 or later within the 2.x range. That single fact explains the shape of the whole toolchain. The primary language of the repository is Jupyter Notebook, so every substantive example is Python running inside conda environments, and the Node manifest exists for the OCI command line interface rather than for anything a browser would install. Alongside it sit four governance files worth reading before you copy an example: .pre-commit-config.yaml and .pre-commit-hooks.yaml, which define what runs before a commit, a pre_commit_scripts directory that holds their implementation, and .gitleaks.toml, which configures secret scanning across the repository history. For a collection of notebooks that walk through credentials, key management and vault access, having secret scanning wired into the commit path is a stronger signal about the project's standards than anything in the prose. It also means a pasted key in a tutorial cell is a failure the project has already decided to catch.

## Model Catalog requires score.py and runtime.yaml before anything else

Most sample repositories treat deployment as an afterthought. This one states the contract up front, in the Model Catalog section, and it is the most reusable thing in the README. The Model Catalog is described as a managed, centralised storage space for models, and the ADS SDK helps you create the artifacts it needs. Two files are mandatory. You must provide a score.py that loads the model and contains a function that makes predictions, which means your inference signature is part of the interface rather than an implementation detail. And you must provide a runtime.yaml describing the runtime conda environment, if you want to deploy the model. On top of that you can document the provenance of the model as model metadata. The section then provides examples of both files for various common machine learning models and configurations. Read this as a two-file interface: whatever framework you use, the catalog wants the same two artefacts, and getting them right is most of the work.

## Capacity reservation discovery validates the SDK before it reports

One small directory shows a different kind of care. Capacity Reservation Discovery is described as read only tools for reporting explicitly configured capacity reservation associations, and the interesting sentence is the second one: the sample follows the latest public OCI Python SDK and command line releases, and validates that they expose the required API fields before running discovery. That ordering is the whole design. Rather than assuming a field exists because a recent release notes entry mentioned it, the sample checks first and stops, which means the failure mode is a clear message rather than an attribute error three calls into a walk. It is also honest about what it covers: explicitly configured associations, which excludes anything inferred from defaults or tenancy-wide settings. For a read-only reporting tool over a cloud inventory, that is exactly the right amount of caution, and it is a better pattern to copy than most of the tutorials in the repository.

## Conda families are the unit of organisation, not topics

Most sample repositories are organised by problem, with directories named after the task you want to solve. This one is organised by execution environment. The explanation is practical: the OCI Data Science service uses conda environments to manage the libraries a notebook can use, provides several environments designed for common data science tasks, and groups them into families, each with notebooks demonstrating tasks for that family. The conda-environments directory is built on that structure. Problem-shaped directories exist alongside it, such as labs for end to end training and deployment walkthroughs, use_cases, ml-applications, ml-insights, data-wrangling, data_labeling_examples and feature_store, but they are peers rather than the primary axis. Two more directories show the service side. Jobs covers repeatable managed tasks, from data preparation and hyperparameter optimization through batch inference and large model training, and distributed_training names its four supported frameworks explicitly: Dask, Horovod, TensorFlow Distributed and PyTorch Distributed.

## It is also a release vehicle for experimental programs

The repository description gives away what a newcomer spends a week working out: this is a series of tutorials and code examples that highlight different features of the OCI Data Science and AI services, along with a release vehicle for experimental programs. Those programs are the directories no tutorial would need. actions, ai-operators, ai-quick-actions and ai_services sit alongside the example material and are better read as definitions that get deployed than as notebooks you run. ai-quick-actions in particular connects to the documented no-code route into large language models, where you fine tune, deploy and evaluate through AI Quick Actions without writing code, and the README names the other two routes as a LangChain integration via ADS and simply writing Python directly in the service. That is three distinct levels of involvement, from a console action to a Python script, and the repository is arranged so you can enter at any of them. The cost of that breadth is obvious in the README, which covers every service feature in the same document and necessarily gets thin in places.

## Conclusion

This repository fits a team already committed to OCI Data Science who wants a working reference for a specific service feature rather than a tutorial to follow from the beginning. It does not fit someone choosing a cloud, since it is vendor documentation for one provider's AI services and nothing in it compares them, and it does not fit someone who needs a pinned, released version, because the VERSION file and the last tagged release sit months behind the last push. Before you copy anything out of it, check that the path still exists, since the README's own notebook link points at a directory absent from the top-level listing, and read the pre-commit and gitleaks configuration first, because it tells you what the project considers a mistake worth failing a build over.

## FAQ

### What is OCI data science?

The OCI Data Science service is a suite of tools for data scientists aimed at faster machine learning model development and deployment. Its named features include the Accelerated Data Science SDK, distributed training, batch processing and machine learning pipelines.

### What is OCI generative AI?

The repository documents three routes into large language models on OCI Data Science: fine tune, deploy and evaluate without writing code through AI Quick Actions; a LangChain integration through the ADS SDK; or writing Python directly in the service.

### What files does the OCI Model Catalog require?

Two. You must supply a score.py that loads the model and a function that makes predictions, and a runtime.yaml describing the runtime conda environment if you want to deploy the model. You can also document metadata about the provenance of the model.

### Which distributed training frameworks does oci-data-science-ai-samples cover?

The distributed_training directory covers Dask, Horovod, TensorFlow Distributed and PyTorch Distributed, all through OCI Data Science Jobs. Distributed training is described as the option for datasets or models that are difficult or impossible to train on a single machine.

### How is oci-data-science-ai-samples organised?

Notebook examples are grouped by conda environment family, because the service manages notebook libraries through conda environments, with problem-shaped directories such as labs, use_cases, ml-applications, data-wrangling and feature_store alongside them. Service definitions live in jobs, pipelines, model_catalog_examples, compute-target and capacity-reservation-discovery.

## Sources

- [Issues](https://github.com/oracle-samples/oci-data-science-ai-samples/issues)
- [License: UPL-1.0](https://github.com/oracle-samples/oci-data-science-ai-samples/blob/main/LICENSE)
- [oracle-samples/oci-data-science-ai-samples on GitHub](https://github.com/oracle-samples/oci-data-science-ai-samples)
- [README](https://github.com/oracle-samples/oci-data-science-ai-samples/blob/main/README.md)
- [Releases](https://github.com/oracle-samples/oci-data-science-ai-samples/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/oracle-samples-oci-data-science-ai-samples