← Back to blog
Engineering note2026-06-19 16:30 UTC

Pressure-testing Ota on Ollama: Go module hydration and honest source-runtime proof

How Ollama pushed Ota to model Go module hydration as a first-class preparation phase and sharpened the boundary between source-runtime proof, built binaries, and contract correction.

Overview

Ollama ended up being valuable for a narrower reason than Immich, but still for a real product reason.

The repo did not need a new orchestration model. It did not need a new multi-service app story. What it exposed was a weaker but still important Ota gap:

  • Go dependency hydration was still trapped inside shell run glue
  • runtime proof could easily blur built-binary truth with source-runtime truth
  • some failures that looked like platform defects were actually just contract corrections

That combination made Ollama the right repo to tighten Ota's preparation surface instead of just broadening another matrix lane.

What Ollama exposed in Ota

The core lesson was simple:

go mod download is not arbitrary shell.

It is the same class of finite dependency hydration as:

  • pnpm install
  • npm ci
  • docker compose pull ...

Before this pass, Ota already had first-class dependency hydration for:

  • docker-backed image hydration
  • node package-manager hydration

But Go repos still had to hide module hydration in run.

Ollama made that gap obvious.

The product change

Ota now ships a Go module dependency-hydration slice under tasks.<name>.prepare:

GO MODULE HYDRATIONyaml
tasks:  setup:    prepare:      kind: dependency_hydration      medium: package_dependencies      source:        kind: go_modules        cwd: .    requirements:      toolchains:        - go    effects:      network: true      network_kind: dependency_hydration

That lets Ota execute go mod download structurally instead of requiring:

COMMANDSyaml
run: go mod download

This matters for the same reason the earlier prepare work mattered elsewhere:

  • the task intent is machine-readable
  • the side effects stay explicit
  • setup is kept distinct from runtime startup
  • Ota can classify this as dependency hydration instead of opaque shell

Why this repo was also useful for runtime-proof honesty

Ollama also forced a cleaner contract distinction around runtime proof.

The repo documents two different runtime truths:

  • go run . serve
  • ./ollama serve

Those are not the same claim.

One is the documented source-runtime path. The other assumes a built native payload already exists.

That sounds obvious, but it is exactly the kind of thing contracts blur when a tool only cares that "something starts."

The right contract had to be explicit about which truth it was proving.

For the current pressure slice, Ota now proves the documented Go source-runtime path honestly instead of pretending the built-binary path and the source path are interchangeable.

What this did not mean

Ollama was also a useful reminder that not every failing run is an Ota defect.

Several failures in the pressure cycle were contract corrections:

  • runtime proof using the wrong serve path
  • setup/run sequencing that did not match the actual documented slice
  • unclear assumptions about whether proof was against a prepared workspace

Those needed to be fixed in the contract first.

That distinction matters because Ota maturity does not come from labeling every bad run a platform bug. It comes from classifying the failure correctly:

  • fix contract truth when the contract is lying
  • fix Ota when the platform is the thing that is weak

Ollama gave both kinds of signal, but the highest-value lasting change was still the new Go hydration slice.

What the final Ollama slice now proves

The current cleared slice proves:

  • native cross-OS verification
  • Go module hydration as first-class preparation
  • native source build and Go test
  • runtime proof against the documented local API surface
  • a contract that distinguishes source-runtime proof from broader packaging or GPU claims

It still does not claim the whole Ollama world:

  • not Docker deployment truth
  • not GPU backend truth
  • not packaged installer truth

That is the correct scope. A narrower honest slice is better than a broader vague one.

Why this repo mattered

Ollama mattered because it kept pressure on a product rule that is easy to violate:

if a setup phase has stable structure, Ota should model it directly instead of making repos hide it inside run.

This repo pushed Ota one step further in that direction by making Go module hydration a first-class preparation surface.

Takeaway

Ollama reinforced a narrower but important Ota rule:

finite setup truth should graduate out of shell glue as soon as Ota can model it honestly.

That is what happened here for Go module hydration.