> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Run an approved Core ML model over a batch description: >- Run an approved Core ML model over typed inputs and read the actual predictions, with measured performance where the run produces it. This is not a training service. route: /docs/compute/examples/coreml-lab page_id: docs-compute-examples-coreml-lab page_type: tutorial content_layer: guided documentation surface_profile: guided_docs audience: Machine learning teams running an existing model over a batch of inputs voice: D reader_question: How do I run my own Core ML model over a batch and see the predictions and timings? primary_action: Run a fifty-sample prediction test source_locale: en-US source_status: APPROVED source_version: docs-compute-examples-coreml-lab-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## What you get Real predictions from your own model, plus the numbers that tell you whether the run is worth repeating. - One prediction per sample in `data/part-*`, carrying `lithi_result` and, where the model emits one, `lithi_confidence`. - Samples the model could not accept in `failures/part-*`, with a typed code and a next action. - Measured performance in `metrics.json` where the run produces it, such as sample counts and timing. - `provenance.json`, binding the model asset digest to the predictions, so you always know which build produced them. The model digest matters more than it looks. Two builds of "the same" model give different predictions, and only the digest tells you which one you are reading. ## What you need An approved model asset and typed inputs that match its declared interface. Register the model as an input asset first, so it is versioned and referenced rather than pasted into a request. The workflow reads the model's declared input and output descriptions, and it will refuse a batch whose shape does not match. Fifty samples is enough for a first run: ```text sample_id,path,width,height,color_space CM-0001,samples/receipt-01.jpg,1024,768,rgb CM-0002,samples/receipt-02.jpg,1024,768,rgb CM-0003,samples/receipt-03.png,640,480,rgb CM-0004,samples/grayscale-04.jpg,1024,768,gray CM-0005,samples/tiny-05.jpg,32,24,rgb ``` Declare `sample_id` as your `item_id_field`. Sample four is grayscale and sample five is far below the model's input size, so both test whether the run refuses cleanly or silently rescales. ## Run it 1. Inspect locally: `lithi inspect ./coreml-fixture`. Confirm the formats and dimensions, so a shape mismatch surfaces on your machine and not in a paid run. 2. Read the workflow: `lithi workflow explain `, and confirm your model's input format is one it accepts: [supported input and output formats](/docs/compute/reference/formats). 3. Reference the registered model version explicitly in your parameters. Never rely on whichever build happens to be newest. 4. Quote it: `lithi quote --workflow --input ./coreml-fixture/manifest.csv`. The quote gives a maximum charge and an expiry, and authorizes nothing. 5. Approve the quote separately, then submit with `lithi batch submit` and track with `lithi status `. ## Read the result Open `result-manifest.json`, then reconcile the counts. Predictions plus failures plus abstentions should equal the fifty samples you submitted. Check `provenance.json` next and confirm the model digest is the version you intended. Predictions from an older build look completely normal and will quietly contradict everything you concluded last week. Then read the two awkward samples. The grayscale and undersized inputs should either be converted under a rule the workflow declares, or refused with a typed code. Silent rescaling is the outcome to look for, because it produces confident predictions from an image the model never really saw. Read the measured performance beside the predictions, not instead of them. Timing tells you what a larger batch will cost you in time; it says nothing about whether the predictions are right. ## Where it stops You get predictions and measurements from a model you already have. This is not a general training service. Nothing is trained, fine-tuned, distilled or improved here, and no model is promoted, registered as production or deployed anywhere. Bring your model in and take predictions out: [how model and build assets are accepted](/docs/compute/inputs/model-and-build-assets). No predictions are written back into an application, a database or a device. Nothing is filed and nothing is sent. Accuracy is a property of your model, and it is not promised by the run. A confidence value is the model's own output, so calibrate it against a labeled set of your own before you let a threshold decide anything.