{
  "_meta": {
    "test_id": "4.2",
    "jira": "SAIL-171",
    "date": "2026-09-07",
    "scope_note": "Test inventory (docs/test-matrix/test-inventory.json) describes 4.2 as a MM-Grounding-DINO FINE-TUNE with boom+batten box labels. This run is narrower and explicit per Nate's instructions: ZERO-SHOT screen only, no fine-tune, no training data needed. It answers a smaller pre-question: can the off-the-shelf open-vocab detector find 'boom' and 'batten pocket' at all before any labeling/fine-tune investment is considered.",
    "holdout_source": "server/inference/test-holdout-ids-canonical.json (332 frozen test photos) — read-only, not modified, no labels written",
    "status": "BLOCKED_NEEDS_POD",
    "reason": "Zero-shot screen could not be run locally without repeating a prior OOM. A previous run of this exact test on this Mac caused a GroundingDINO python process to balloon to 6.5GB RSS. This session confirmed: (1) no MM-Grounding-DINO / GroundingDINO checkpoint or cache exists anywhere on disk (~/.cache/huggingface is 87M and contains nothing grounding-dino related; no mmdetection checkout found); (2) none of mmdet, mmcv, mmengine, or transformers are installed in server/inference/.venv (only torch 2.12.1 + torchvision 0.27.1 present); (3) mmcv in particular requires a compiled build, itself a nontrivial/fragile step on Apple Silicon and out of scope for a screen. Given the known 6.5GB runtime RSS ceiling from the prior run and zero infra currently in place, running this locally would very likely repeat the OOM. Per instructions, bailing to needs-pod is the correct, expected outcome here, not a failure.",
    "forward_passes_run": 0,
    "photos_processed": 0,
    "memory_cap_respected": true,
    "peak_rss_this_session_mb": "n/a — no model process launched; only zero-byte HEAD/API metadata requests were made against public checkpoint hosts",
    "checkpoint_size_findings": [
      {
        "name": "IDEA-Research/grounding-dino-tiny (HF transformers-compatible variant)",
        "file": "model.safetensors",
        "bytes": 689359096,
        "approx_mb": 657,
        "source": "https://huggingface.co/api/models/IDEA-Research/grounding-dino-tiny/tree/main",
        "verified_via": "HF tree API, zero bytes downloaded"
      },
      {
        "name": "IDEA-Research/grounding-dino-base (HF transformers-compatible variant)",
        "file": "model.safetensors",
        "bytes": 933400872,
        "approx_mb": 890,
        "source": "https://huggingface.co/api/models/IDEA-Research/grounding-dino-base/tree/main",
        "verified_via": "HF tree API, zero bytes downloaded"
      },
      {
        "name": "MM-GDINO-T (Swin-Tiny, O365+GoldG pretrain) — official mmdetection release, the model this test is actually named for",
        "file": "grounding_dino_swin-t_pretrain_obj365_goldg_20231122_132602-4ea751ce.pth",
        "bytes": 960771250,
        "approx_mb": 916,
        "source": "https://download.openmmlab.com/mmdetection/v3.0/mm_grounding_dino/grounding_dino_swin-t_pretrain_obj365_goldg/grounding_dino_swin-t_pretrain_obj365_goldg_20231122_132602-4ea751ce.pth",
        "verified_via": "HTTP HEAD, Content-Length header, zero bytes downloaded",
        "requires": "mmdet + mmcv + mmengine (none installed; mmcv needs a compiled build)"
      }
    ],
    "binding_constraint_note": "On-disk checkpoint size (~660MB-916MB) is under the 2GB local-load cap by itself, but is NOT the binding constraint. The measured problem is RUNTIME RSS (6.5GB observed in the prior run) once the Swin backbone + BERT text encoder + FPN + mmcv/torch overhead are all resident during inference, plus the missing mmdet/mmcv/mmengine stack that would need installing (mmcv compile on Apple Silicon is itself out of scope for a screen). Bailing to needs-pod per instructions.",
    "pod_run_needs": {
      "hardware": "Any CUDA GPU pod (T4/A10 class is plenty for a zero-shot screen at inference-only batch size 1), similar to prior RunPod recipes used for SAM3 spikes in this repo",
      "software": "mmdet + mmcv (matching torch/cuda build) + mmengine, OR the simpler HF transformers path (IDEA-Research/grounding-dino-tiny or -base) which needs only transformers+torch and avoids the mmcv compile entirely — recommended first path for a screen",
      "prompts_to_test": ["boom", "batten pocket"],
      "sample_size": "~10-20 holdout photos from server/inference/test-holdout-ids-canonical.json, streamed one at a time",
      "eval_method": "Eyeball/score whether predicted boxes land on the true boom/batten pocket regions; report hit rate as (photos with a usably-placed box) / (photos screened)",
      "critical_gotcha": "GROUND TRUTHS #1 (CLAUDE.md) applies to any future run that draws boxes on these photos: apply EXIF orientation to the image PIXELS before inference/drawing (ImageOps.exif_transpose), run the model on that same upright image, or ~17/200 photos with a rotation flag will show boxes rotated/off the sail. Do not re-derive this bug.",
      "estimated_cost": "Under an hour of GPU time for a 10-20 photo zero-shot screen; well within prior SAM3-spike-style pod budgets used in this repo"
    }
  },
  "product_question": "Can an open-vocabulary detector (MM-Grounding-DINO) with explicit 'boom' and 'batten pocket' text classes usefully box the boom and battens on our sail photos, zero-shot, with no training — well enough to feed SAM3 or veto false stripes?",
  "answer": "Not established either way. Zero forward passes were run. This screen is blocked on a GPU pod; running it locally would risk repeating a prior 6.5GB out-of-memory event on this machine.",
  "hit_rate": null,
  "photos_screened": 0
}