Ds deploy
Stands a packaged model up as a callable endpoint with prediction logging against the live baseline, drift detection, and a rollback pointer. Hard gate — refuses full traffic without all three, and stops before any remote or cloud push. Use when someone asks to serve, deploy, or stand up a model endpoint. Use when monitoring, drift, or rollback come up for a model that is about to run live.From its SKILL.md
npx -y skills add StamKavid/last-ds-mile --skill ds-deployAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.9 KB, as published. Nobody here has run it
ds-deploy — Make It Callable, Safely
Overview
A model that ships without monitoring degrades in silence. This stage stands the
/ds-package container up as a callable endpoint and requires the operational layer
that keeps it honest in production: logging predictions against the same baseline it
beat offline, watching for input drift, and a one-command way back. It is
local-container-first by design — the plugin never pushes to a remote or a cloud target
on its own. It ships no code; it guides you to generate the endpoint wiring, monitoring
and drift hooks, and rollback record into .last-ds-mile/deploy/.
When to Use
- After
/ds-packagehas produced a parity-verified image and an inference contract, and the model is ready to serve real requests. - NOT before parity passes — an unverified package is not deployable.
- NOT for retraining automation — retraining triggers are out of scope (roadmap).
Core Process
- Gate check. Confirm
/ds-packageproduced a parity-verified image and acontract.json. If parity was never proven, stop and run/ds-package. - Local endpoint. Stand the container up locally as the default callable service
(a thin HTTP or CLI entry over the packaged
predict). Cloud targets are documented adapter stubs the user fills in — never a baked-in vendor path. - Operational gate — all three required before full-traffic deploy:
- Monitoring hook →
.last-ds-mile/deploy/monitor.jsonl: append inputs, predictions, and — once labels arrive — the online metric against the same baseline heuristic the model beat at/ds-baseline. Newline-delimited JSON, no tool dependency. (If the team already runs MLflow, it can log there instead; the discipline is what matters, not the tool.) - Drift hook: compare serving-input distributions against the training
distributions and warn on drift. Reuse the
distribution-shiftskill for the method rather than reinventing it. - Rollback pointer →
.last-ds-mile/deploy/rollback.json: the previous image digest and a one-command revert.
- Monitoring hook →
- Canary discipline. Recommend shadow or a small canary before routing full traffic — never send 100% to a freshly deployed model on the first cutover.
- Confirm before any outward push. Standing up locally is fine to proceed. Pushing to a container registry, a remote host, or a cloud serving target is outward-facing — stop and ask the user to confirm (and let them perform any credentialed step). The plugin makes no network calls of its own.
- Write
.last-ds-mile/stages/12-deploy.md: the endpoint location, the monitoring and drift hook locations, the rollback pointer, and the canary plan.
Common Rationalizations
See ds-method for the shared Rationalizations that apply to every stage.
| Rationalization | Reality |
|---|---|
| "Ship it to 100% now, we'll add monitoring after" | Without monitoring you can't see degradation, and "after" rarely comes. The gate requires it before full traffic for exactly this reason. |
| "We don't need a rollback plan, the model's good" | Rollback isn't about whether this model is good — it's about being able to undo the deploy in one step when the unexpected happens. |
| "Just push it to the registry, it's basically the same" | A registry/cloud push is an outward, often irreversible action. Confirm with the user; never push silently. |
Red Flags
See ds-method for the shared Red Flags that apply to every stage.
| Red Flag | What it usually means |
|---|---|
| No online comparison against the baseline heuristic | You can't tell whether the deployed model is still beating the dumb baseline — degradation stays invisible. |
| No rollback pointer recorded | A bad deploy has no clean way back; the next incident becomes an emergency instead of a one-command revert. |
| Full traffic routed on the first deploy | Skipped the canary — any serving bug hits every user at once instead of a slice. |
Verification
- Gate check passed: a parity-verified
/ds-packageimage andcontract.jsonexist. - Endpoint stands up locally and answers a smoke request.
- Monitoring hook logs inputs, predictions, and the online-vs-baseline metric.
- Drift hook compares serving inputs to training (via
distribution-shift). - Rollback pointer recorded (previous image digest + revert command).
- Any push to a remote/registry/cloud target was confirmed with the user, not done silently.
-
.last-ds-mile/stages/12-deploy.mdwritten.