Contributing a Model¶

Guide for contributing a base model to fAIr. A base model is a reusable ML blueprint that users can finetune on their own datasets through the fAIr platform.

Reference Implementations¶

Model Scope¶

fAIr targets feature extraction from very high resolution (VHR) aerial and satellite imagery ; typically ~ > 30 cm ground sample distance (GSD), RGB only. All imagery is sourced from OpenAerialMap.

Supported Tasks¶

Your mlm:tasks must use one or more of these exact values. CI rejects anything else.

Supported Feature Categories¶

fAIr is a humanitarian mapping platform. Models should prioritise features that support disaster response, infrastructure mapping, and environmental monitoring. Core categories:

Other OpenStreetMap feature categories (landuse, bridge, etc.) are welcome as long as they are compatible with the platform's RGB input and vector output constraints. To add a new keyword, include it in keywords.json as part of your PR.

Input Requirements¶

Models must normalize the uint8 pixel values (0-255) in their preprocess function.

Output Requirements¶

fAIr only supports vector output. Your model's final output must produce GeoJSON geometries of one of these types:

Your stac-item.json must declare exactly which geometry type the model produces via the keywords array. CI enforces that at least one of polygon, line, or point is present.

Raster-only output (e.g. raw segmentation masks without vectorization) is acceptable as an intermediate step, but the post_processing_function must ultimately convert to one of the supported geometry types for downstream consumption.

Sample Data Layout¶

data/sample/
  train/
    oam/             # RGB GeoTIFF chips (OAM-{x}-{y}-{z}.tif, ≥30cm GSD)
    osm/             # GeoJSON labels (osm_features_*.geojson)
  predict/
    oam/             # Input chips for inference
    predictions/     # Output directory (model writes here)

Chip filenames follow the pattern OAM-{x}-{y}-{z}.tif where x, y, z are tile coordinates. Your model must accept these as input during both training and inference.

Prerequisites¶

Before starting, ensure you have:

• A working ML model for geospatial feature extraction (buildings, roads, trees, etc.)
• Pretrained weights that are publicly downloadable or distributable
• Familiarity with Docker and Python packaging

License¶

Directory Structure¶

Create a subdirectory under models/ named after your model (lowercase, underscores for spaces, must be a valid Python package name):

models/your_model/
  pipeline.py          # ZenML pipeline with training + inference
  Dockerfile           # Self-contained runtime environment
  stac-item.json       # STAC MLM item (model metadata)
  README.md            # Model overview, limitations, citation
  tests/
    conftest.py        # generate_toy_dataset fixture
    test_steps.py      # Step-level tests

pipeline.py¶

This is the core of your contribution. It must export two @pipeline-decorated functions that the platform discovers and dispatches automatically.

Required Exports¶

CI AST-parses pipeline.py and expects the names below. The signatures are the contract ; use these exact argument names.

from typing import Annotated, Any
from zenml import pipeline, step

@pipeline
def training_pipeline(
    base_model_weights: str,
    dataset_chips: str,
    dataset_labels: str,
    num_classes: int,
    hyperparameters: dict[str, Any],
) -> None: ...

@pipeline
def inference_pipeline(
    model_uri: str,
    input_images: str,
    inference_params: dict[str, Any] | None = None,
) -> None: ...

@step
def split_dataset(
    dataset_chips: str,
    dataset_labels: str,
    hyperparameters: dict[str, Any],
) -> Annotated[dict[str, Any], "split_info"]: ...

def preprocess(image_path: Any) -> Any: ...
def postprocess(raw_output: Any) -> Any: ...

def predict(
    session: Any,
    input_images: str,
    params: dict[str, Any],
) -> dict[str, Any]: ...

Training flow¶

flowchart LR
    A[split_dataset] -->|split_info| B[train_model]
    A -->|split_info| C[evaluate_model]
    B -->|trained_model| C
    B -->|trained_model| D[export_onnx]
    C -.->|metrics| E([ZenML + MLflow])
    D -.->|onnx path| E

The split_info dict returned by split_dataset is passed as a dependency to both train_model and evaluate_model. This enforces step ordering and guarantees both steps reconstruct the same split.

@pipeline
def training_pipeline(
    base_model_weights: str,
    dataset_chips: str,
    dataset_labels: str,
    num_classes: int,
    hyperparameters: dict[str, Any],
) -> None:
    split_info = split_dataset(dataset_chips, dataset_labels, hyperparameters)
    trained = train_model(
        dataset_chips, dataset_labels, base_model_weights,
        hyperparameters, split_info, num_classes,
    )
    evaluate_model(trained, dataset_chips, dataset_labels, hyperparameters, split_info)
    export_onnx(trained_model=trained, hyperparameters=hyperparameters)

split_dataset¶

Single source of truth for how data is divided into train/val. Read val_ratio and split_seed from hyperparameters, run your splitting strategy, log metadata, and return a split_info dict for downstream steps. CI enforces its presence via AST parsing.

@step
def split_dataset(
    dataset_chips: str,
    dataset_labels: str,
    hyperparameters: dict[str, Any],
) -> Annotated[dict[str, Any], "split_info"]:
    val_ratio = hyperparameters.get("val_ratio", 0.2)
    seed = hyperparameters.get("split_seed", 42)

    train, val = my_split_logic(dataset_chips, dataset_labels, val_ratio, seed)

    split_info = {
        "strategy": "random",
        "val_ratio": val_ratio,
        "seed": seed,
        "train_count": len(train),
        "val_count": len(val),
        "description": "...",
    }
    log_metadata(metadata={"fair/split": split_info})
    return split_info

The split_info dict must contain:

The metadata flows through the promotion pipeline into the local model STAC item as fair:split, giving users full visibility into how each finetuned model was trained.

train_model¶

Build (or load) your model from base_model_weights, loop over the train split only (reconstructed from split_info), and return the trained model. Wrap the loop in mlflow_training_context so params and per-epoch metrics land in MLflow automatically.

@step
def train_model(
    dataset_chips: str,
    dataset_labels: str,
    base_model_weights: str,
    hyperparameters: dict[str, Any],
    split_info: dict[str, Any],
    num_classes: int,
) -> Annotated[Any, "trained_model"]:
    with mlflow_training_context(hyperparameters, ...):
        model = build_model(base_model_weights, num_classes)
        train_loader = build_loader(
            dataset_chips, dataset_labels, split_info, split="train"
        )
        for epoch in range(hyperparameters["epochs"]):
            loss = run_epoch(model, train_loader)
            mlflow.log_metric("train_loss", loss, step=epoch)
    return model.cpu()

Must:

• Read only the train portion implied by split_info
• Apply freeze_encoder, max_grad_norm, scheduler, etc. from hyperparameters
• Return an in-memory model (or raw checkpoint bytes for non-picklable frameworks ; see the YOLO tip in Inference flow)

evaluate_model¶

Reconstruct the val split deterministically from split_info, run inference, compute task-appropriate metrics, and publish them so the platform can copy them onto the promoted local model STAC item.

@step
def evaluate_model(
    trained_model: Any,
    dataset_chips: str,
    dataset_labels: str,
    hyperparameters: dict[str, Any],
    split_info: dict[str, Any],
) -> Annotated[dict[str, Any], "metrics"]:
    val_loader = build_loader(
        dataset_chips, dataset_labels, split_info, split="val"
    )
    metrics = compute_metrics(trained_model, val_loader)
    log_evaluation_results(metrics)
    return metrics

export_onnx¶

Export the trained model to ONNX for downstream inference runtimes and validate the result with onnx.checker.check_model(). CI relies on a valid ONNX file being produced by this step.

@step
def export_onnx(
    trained_model: Any,
    hyperparameters: dict[str, Any],
) -> Annotated[bytes, "onnx_model"]:
    chip_size = hyperparameters.get("chip_size", 256)
    dummy = torch.randn(1, 3, chip_size, chip_size)
    _, path = tempfile.mkstemp(suffix=".onnx")
    try:
        torch.onnx.export(
            trained_model.cpu().eval(),
            (dummy,),
            path,
            input_names=["input"],
            output_names=["output"],
            dynamic_axes={"input": {0: "batch"}, "output": {0: "batch"}},
            opset_version=18,
        )
        onnx.checker.check_model(path)
        return Path(path).read_bytes()
    finally:
        Path(path).unlink(missing_ok=True)

Inference flow¶

Inference runs on ONNX via a single predict(session, input_images, params) function. The same function powers three paths:

@step
def run_inference(
    model_uri: str,
    input_images: str,
    inference_params: dict[str, Any],
) -> Annotated[dict[str, Any], "predictions"]:
    from fair.serve.base import load_session
    session = load_session(model_uri)
    return predict(session, input_images, inference_params)

@pipeline
def inference_pipeline(
    model_uri: str,
    input_images: str,
    inference_params: dict[str, Any] | None = None,
) -> None:
    run_inference(
        model_uri=model_uri,
        input_images=input_images,
        inference_params=inference_params or {},
    )

def predict(
    session: onnxruntime.InferenceSession,
    input_images: str,
    params: dict[str, Any],
) -> dict[str, Any]:
    # 1. Iterate over image files in input_images directory
    # 2. For each: preprocess, run session, decode
    # 3. Return {"type": "FeatureCollection", "features": [...]}
    ...

The predict function always returns a GeoJSON FeatureCollection. Valid params keys and whether they are required are declared in mlm:hyperparameters using the inference. prefix (see Hyperparameters below).

Pre/post processing & weights¶

Three module-level helpers are referenced from the STAC item by dotted path. Keep their bodies small ; they should just wrap your existing ML code.

def preprocess(image_path: Any, chip_size: int) -> Any:
    # 1. open RGB GeoTIFF
    # 2. normalize uint8 → float32 in [0, 1]
    # 3. resize to (chip_size, chip_size) if needed
    tensor = ...
    return tensor

def postprocess(raw_output: Any) -> Any:
    # threshold / NMS / decode however your task needs
    return predictions

def _download_checkpoint(url: str) -> Path:
    from upath import UPath

    local = Path(tempfile.mkdtemp()) / UPath(url).name
    local.write_bytes(UPath(url).read_bytes())
    return local

Dockerfile¶

Your Dockerfile must be self-contained and use four named stages:

flowchart LR
    A[builder<br/>uv pip install deps] --> B[runtime<br/>framework + fair-py-ops]
    B --> C[test<br/>+ fair-py-ops test extras]
    B -.->|pushed to registry| D([ghcr.io])
    C -.->|used by CI| E([pytest])

The inference stage uses a two-step distroless build (builder venv -> gcr.io/distroless/cc-debian12:nonroot) so live serving cold starts and image sizes stay small. It installs only fair-py-ops[serve] plus the model's inference-specific libs (rasterio, pyproj, numpy, Pillow, etc.) and copies pipeline.py into /app/models/{name}/pipeline.py. The CMD is uvicorn fair.serve.base:create_app --factory --host 0.0.0.0 --port 8080.

Requirements:

1. Use uv pip install in the builder (not bare pip)
2. Install /tmp/fair-src[k8s] from the copied project source
3. The test stage must install /tmp/fair-src[test] via uv pip install --system
4. Set ENTRYPOINT ["/usr/local/bin/python"]
5. Never install test dependencies in the runtime stage

CI builds --target test to run tests, then pushes only --target runtime.

See any existing model Dockerfile (e.g. models/unet_segmentation/Dockerfile) for the full pattern.

Testing¶

Each model needs a tests/ directory with three files:

• conftest.py : a generate_toy_dataset fixture that creates toy chips + labels at test time
• test_steps.py : four test functions : test_split_dataset, test_train_model, test_evaluate_model, test_export_onnx
• test_serve.py : tests that call predict(session, input_images, params) against a mocked ONNX session and assert the output is a valid GeoJSON FeatureCollection

The shared models/conftest.py provides common fixtures (toy_chips, toy_labels, base_hyperparameters, etc.) automatically. You only write generate_toy_dataset.

import pytest

@pytest.fixture
def generate_toy_dataset(tmp_path):
    chips_dir = tmp_path / "chips"
    labels_dir = tmp_path / "labels"
    # write a handful of tiny RGB GeoTIFFs + matching GeoJSON labels
    make_toy_chips(chips_dir, count=4)
    make_toy_labels(labels_dir, count=4)
    return {
        "chips": str(chips_dir),
        "labels": str(labels_dir),
        "dataset_stac_item": build_toy_dataset_item(chips_dir, labels_dir),
    }

from models.your_model.pipeline import (
    split_dataset, train_model, evaluate_model, export_onnx,
)

def test_split_dataset(generate_toy_dataset, base_hyperparameters):
    info = split_dataset.entrypoint(
        generate_toy_dataset["chips"],
        generate_toy_dataset["labels"],
        base_hyperparameters,
    )
    assert info["train_count"] > 0 and info["val_count"] > 0

def test_train_model(generate_toy_dataset, base_hyperparameters):
    ...  # run train_model.entrypoint on the toy split, assert non-null output

def test_evaluate_model(...): ...
def test_export_onnx(...): ...

See models/resnet18_classification/tests/, models/yolo11n_detection/tests/, or models/unet_segmentation/tests/ for complete working examples.

just test-models your-model   # Build Docker image + run tests

stac-item.json¶

The STAC item is your model's metadata card. It follows the STAC MLM Extension v1.5.1 and is validated by CI against the platform's requirements schema.

"stac_extensions": [
    "https://stac-extensions.github.io/mlm/v1.5.1/schema.json",
    "https://stac-extensions.github.io/version/v1.2.0/schema.json",
    "https://stac-extensions.github.io/classification/v2.0.0/schema.json",
    "https://stac-extensions.github.io/file/v2.1.0/schema.json",
    "https://stac-extensions.github.io/raster/v1.1.0/schema.json"
]

Required Properties¶

fair:metrics_spec¶

The MLM extension does not define evaluation metrics semantics. fair:metrics_spec fills this gap by declaring the meaning and storage location of each evaluation metric your model produces during evaluate_model. Users need this to understand what "accuracy" means (pixel accuracy? per-class? mean IoU?).

Each entry must declare:

"fair:metrics_spec": [
    {"key": "fair:mean_iou", "name": "Mean IoU", "description": "Mean intersection-over-union across all classes, including background."},
    {"key": "iou_building", "name": "Building IoU", "description": "Per-class IoU for the 'building' class (matches classification:classes entry)."},
    {"key": "fair:pixel_accuracy", "name": "Pixel Accuracy", "description": "Fraction of pixels correctly classified across the val split."}
]

"fair:metrics_spec": [
    {"key": "fair:map50", "name": "mAP@0.5", "description": "Mean average precision at IoU threshold 0.5 across all classes."},
    {"key": "fair:map50_95", "name": "mAP@0.5:0.95", "description": "Mean average precision averaged over IoU thresholds 0.5 to 0.95."},
    {"key": "fair:precision", "name": "Precision", "description": "Box-level precision at the default confidence threshold."}
]

"fair:metrics_spec": [
    {"key": "fair:accuracy", "name": "Accuracy", "description": "Top-1 accuracy on the val split."},
    {"key": "fair:f1", "name": "F1 Score", "description": "Macro-averaged F1 across all classes."}
]

When evaluate_model logs metrics via log_metadata(infer_model=True), the platform copies those values to the promoted local model STAC item. Class IoU keys use the classification:classes names, e.g. iou_background, iou_building (not numeric indices like iou_class_0).

fair:split_spec¶

The fair:split_spec property declares how your model expects training data to be split into train and validation sets. This is a required property on base model STAC items. CI validates its presence and structure.

The split strategy depends on the task type:

"fair:split_spec": {
    "strategy": "random",
    "default_ratio": 0.2,
    "seed": 42,
    "description": "Seeded shuffle of sorted image filenames, first (1 - ratio) for train, remainder for val."
}

"fair:split_spec": {
    "strategy": "spatial",
    "default_ratio": 0.2,
    "seed": 42,
    "description": "RandomGeoSampler over training AOI, GridGeoSampler for non-overlapping val tiles; avoids spatial leakage between splits."
}

Contributors can define custom split strategies as long as they document the approach in description and implement the corresponding split_dataset step. The val_ratio and split_seed hyperparameters allow users to override the defaults at finetuning time.

Keywords¶

The keywords array must include:

1. At least one feature keyword: building, road, tree, water, landuse
2. At least one task keyword: matches mlm:tasks values
3. Exactly one geometry type: polygon, line, or point

Example: ["building", "semantic-segmentation", "polygon"]

Hyperparameters¶

The mlm:hyperparameters object in your STAC item declares default values for both training and inference. Keys are prefixed so the platform can route them to the right path:

When users finetune your model, the platform reads these defaults and merges any user overrides into a generated YAML config (via fair.zenml.config.generate_training_config). This YAML is then passed to your training_pipeline.

Example:

"mlm:hyperparameters": {
    "training.epochs": 5,
    "training.batch_size": 4,
    "training.learning_rate": 0.0001,
    "inference.confidence_threshold": 0.5,
}

The STAC schema enforces four keys as compulsory in every mlm:hyperparameters block (base and local models):

fAIr chips are 256*256; each model handles any internal resize to its native ONNX input size inside preprocess.

Your training_pipeline receives all hyperparameters as a single hyperparameters: dict[str, Any] argument. Each step reads values with hyperparameters.get("epochs", ...) and applies defaults locally. Validation is declared in the STAC item under fair:hyperparameters_spec, not in the Python signature.

Each entry in fair:hyperparameters_spec declares:

"fair:hyperparameters_spec": [
    {"key": "epochs", "type": "int", "default": 5, "min": 1, "max": 500, "description": "..."},
    {"key": "learning_rate", "type": "float", "default": 0.001, "min": 1e-5, "max": 1.0, "description": "..."},
    {"key": "scheduler", "type": "str", "default": "cosine", "values": ["cosine", "none"], "description": "..."}
]

The platform uses this spec to render the finetuning form, validate user overrides at submission time, and populate the YAML config passed to training_pipeline.

In addition to model-specific hyperparameters, you must declare these split parameters (the others are recommended unless the training framework manages them internally, e.g. Ultralytics):

See the three reference models under models/ for working fair:hyperparameters_spec and mlm:hyperparameters blocks.

The platform auto-extracts chip_size from mlm:input[0].input.shape[-1] and num_classes from classification:classes length, so those don't need to be duplicated in mlm:hyperparameters unless your defaults differ.

Each entry in mlm:input must declare exactly 3 RGB bands (shape: [-1, 3, H, W], dim_order: [batch, bands, height, width], data_type: float32) and a pre_processing_function pointing to your preprocess entrypoint (models.your_model.pipeline:preprocess).

Each entry in mlm:output must declare result (shape, dim_order, data_type), classification:classes (one entry per output class with name and value), and a post_processing_function pointing to your postprocess entrypoint.

"mlm:input": [{
    "name": "rgb",
    "bands": ["red", "green", "blue"],
    "input": {
        "shape": [-1, 3, 256, 256],
        "dim_order": ["batch", "bands", "height", "width"],
        "data_type": "float32"
    },
    "pre_processing_function": "models.unet_segmentation.pipeline:preprocess"
}],
"mlm:output": [{
    "name": "mask",
    "tasks": ["semantic-segmentation"],
    "result": {
        "shape": [-1, 2, 256, 256],
        "dim_order": ["batch", "classes", "height", "width"],
        "data_type": "float32"
    },
    "classification:classes": [
        {"name": "background", "value": 0},
        {"name": "building", "value": 1}
    ],
    "post_processing_function": "models.unet_segmentation.pipeline:postprocess"
}]

"mlm:input": [{
    "name": "rgb",
    "bands": ["red", "green", "blue"],
    "input": {
        "shape": [-1, 3, 640, 640],
        "dim_order": ["batch", "bands", "height", "width"],
        "data_type": "float32"
    },
    "pre_processing_function": "models.yolo11n_detection.pipeline:preprocess"
}],
"mlm:output": [{
    "name": "boxes",
    "tasks": ["object-detection"],
    "result": {
        "shape": [-1, 6],
        "dim_order": ["detections", "xyxy_conf_class"],
        "data_type": "float32"
    },
    "classification:classes": [
        {"name": "building", "value": 0}
    ],
    "post_processing_function": "models.yolo11n_detection.pipeline:postprocess"
}]

"mlm:input": [{
    "name": "rgb",
    "bands": ["red", "green", "blue"],
    "input": {
        "shape": [-1, 3, 224, 224],
        "dim_order": ["batch", "bands", "height", "width"],
        "data_type": "float32"
    },
    "pre_processing_function": "models.resnet18_classification.pipeline:preprocess"
}],
"mlm:output": [{
    "name": "label",
    "tasks": ["classification"],
    "result": {
        "shape": [-1, 2],
        "dim_order": ["batch", "classes"],
        "data_type": "float32"
    },
    "classification:classes": [
        {"name": "no_building", "value": 0},
        {"name": "building", "value": 1}
    ],
    "post_processing_function": "models.resnet18_classification.pipeline:postprocess"
}]

Required Assets¶

"assets": {
    "checkpoint": {
        "href": "https://huggingface.co/torchgeo/unet/resolve/<commit>/unet.pt",
        "type": "application/octet-stream; framework=PyTorch",
        "title": "UNet pretrained weights",
        "roles": ["mlm:model", "mlm:weights"],
        "mlm:artifact_type": "torch.save"
    },
    "source-code": {
        "href": "https://github.com/hotosm/fAIr-models/tree/master/models/unet_segmentation/pipeline.py",
        "type": "text/x-python",
        "title": "UNet pipeline source",
        "roles": ["mlm:source_code"],
        "mlm:entrypoint": "models.unet_segmentation.pipeline:predict"
    },
    "mlm:training": {
        "href": "ghcr.io/hotosm/fair-models/unet_segmentation:latest",
        "type": "application/vnd.oci.image.index.v1+json",
        "title": "Training runtime image",
        "roles": ["mlm:training-runtime"]
    },
    "mlm:inference": {
        "href": "ghcr.io/hotosm/fair-models/unet_segmentation:latest",
        "type": "application/vnd.oci.image.index.v1+json",
        "title": "Inference runtime image",
        "roles": ["mlm:inference-runtime"]
    },
    "readme": {
        "href": "https://raw.githubusercontent.com/hotosm/fAIr-models/refs/heads/main/models/unet_segmentation/README.md",
        "type": "text/markdown",
        "title": "Model README",
        "roles": ["metadata"]
    }
}

The checkpoint asset href must be a direct HTTPS URL pointing to the pretrained weights file (e.g. a HuggingFace commit-pinned URL, a GitHub release URL, or a PyTorch download URL). Framework weight enums, short names, and local paths are not accepted. CI validates that the URL is accessible via an HTTP HEAD check.

The readme asset href must be an absolute URL to the raw file (e.g. https://raw.githubusercontent.com/hotosm/fAIr-models/refs/heads/main/models/your_model/README.md). Relative paths such as ./README.md are not accessible from deployed STAC catalogs and will be flagged by validation.

The source-code asset href must point to the git repository (or tree URL) where the model's source code lives. This is validated by CI and displayed on the model's catalog page.

cite-as Link¶

If your model or its pretrained weights come from a published paper, add a cite-as link under links[] pointing to the canonical DOI (preferred) or arXiv URL. This link is displayed in the catalog UI.

"links": [
    {
        "rel": "cite-as",
        "href": "https://doi.org/10.48550/arXiv.1505.04597",
        "title": "U-Net: Convolutional Networks for Biomedical Image Segmentation"
    }
]

README.md¶

Every model must include a README.md in its directory. This is the human-readable documentation for your model ; it covers context that the STAC MLM item cannot express.

The README is referenced as a readme asset in stac-item.json with an absolute raw GitHub URL (see Required Assets above). Validation checks that the README file exists locally and that the asset is present in the STAC item.

What to include¶

Keep it concise. The STAC item already captures hyperparameters, input/output specs, and keywords ; the README is for everything else.

PR Checklist¶

Before opening a PR, make sure:

The full requirements are described in the sections above, especially the STAC metadata, pipeline structure, assets, and README guidance. CI checks the detailed metadata, pipeline exports, Docker build, and consistency rules for you.

CI Checks¶

flowchart LR
    A[PR opened] --> B[validate_model.py<br/>AST checks]
    B --> C[validate_stac_items.py<br/>pystac + fAIr schema]
    C --> D[docker build<br/>--target test]
    D --> E[pytest models/name/tests/]
    E --> F[docker build<br/>--target runtime]
    F --> G[push to registry]

On PR submission, CI will:

1. Validate pipeline exports : scripts/validate_model.py checks for training_pipeline and inference_pipeline (@pipeline), split_dataset (@step), and required test functions via AST parsing
2. Validate STAC item : scripts/validate_stac_items.py runs pystac validation against the fAIr base model schema (requires fair:metrics_spec, fair:split_spec, all MLM fields, assets, keywords including a geometry type, and a supported license)
3. Build test Docker image : builds --target test which includes pytest and zenml[server]
4. Run step tests : python -m pytest models/<name>/tests/ inside the test image validates all 4 pipeline steps with toy data
5. Push production image : builds --target runtime (no test deps) and pushes to the container registry

All checks must pass before the PR is reviewed.

Local Development¶

just setup                             # Install deps + ZenML init
just validate                          # Validate STAC items + model pipelines
just test                              # Run tests
just example                           # Run full example pipeline

Reference¶

• STAC MLM Extension v1.5.1 -- MLM fields spec
• MLM Best Practices
• UNet segmentation model -- segmentation reference
• ResNet18 classification model -- classification reference
• YOLOv11n detection model -- detection reference
• UNet STAC item -- STAC item template