Deploy with a reversible plan.

A release changes who receives a result

A classroom uses a model to explore flower measurements. A new package may load successfully and still change predictions, reject valid requests or fail behind a service interface. A release plan should explain who sees the change, which evidence allows wider use, and how to return to a known version.

Entering midway: deployment makes a selected artifact available to an application. A stable release is the version you are retaining as a return point; that name does not prove it is perfect. A candidate is a proposed replacement. A receipt records which request and version produced an outcome. Rollback restores an earlier operating choice for future work.

This lesson uses a local simulation with actual inference, inert JSON boundaries and explicitly assumed costs. There is no real network service or user traffic. Public regression cases come from a separate Python implementation of the packaged model. They test interface consistency and original predictions, not ground-truth species accuracy or independent learner mastery.

Local inference and a service boundary have different obligations

A local function can receive a typed object and return a prediction inside the same application. A service boundary typically serializes inputs, sends them elsewhere and decodes a response. It adds failure modes: unavailable service, timeout, stale routing and a response belonging to the wrong request or release.

The simulation’s service path really serializes and parses JSON, checks the model request, and validates the returned request ID, release name, model digest, response schema and finite probability in [0, 1]. Network travel itself is simulated. The local path calls the model directly. Both must respect feature names, units and missing-value policy.

Boundary	Useful capability	Additional questions
Local model	Can run without an application server or network inference	Which artifact is on this device? What happens during an update?
Model service	Can centralize artifact selection and share computation	How are requests authenticated, bounded, timed out and attributed? What if the service is unavailable?
Staged release controller	Chooses which version serves each request	What evidence permits advancement? What returns traffic to stable?

A real service also needs authentication, request-size/resource limits, operational ownership and observability appropriate to its setting. This simulation does not implement those server controls. The optional operations implementation studio is separate from the required browser lesson.

Inspect before exposing, then increase exposure

Shadow comparison: stable serves the request while the candidate is evaluated separately. Its output is inspected rather than presented as the served result. This can detect a regression without making the candidate the user-facing version, but duplicates work and may duplicate sensitive-data access in a real system. Shadow behavior must still respect permissions and retention rules.

Staged traffic: a chosen share of requests goes to the candidate. The lab’s stages are 25%, 50% and 100%. In a 20-request cohort those shares are 5, 10 and 20 requests. Twenty-five percent means 25 / 100; multiplying by 20 gives 5. The fixed slot rule assigns positions by index modulo four. It is deterministic and easy to inspect, not randomized experimentation or protection against traffic-mix bias.

Practice: at 50% traffic, three of ten candidate requests fail. What is the candidate failure rate? Three divided by ten is 30%, not three divided by all twenty. Always state the denominator. If fallback repairs every served result, the served failure rate can be zero while the raw candidate failure rate stays 30%.

The next stage requires the latest cohort at the current stage, matching candidate artifact and boundary/fault/fallback settings. It must cover both complete and missing-input groups, include at least five candidate requests, and have zero raw candidate regression failures. Changing settings prevents a stale pass from authorizing advancement. A new shadow comparison is required after returning to 0%.

These thresholds are authored teaching rules, not an industry deployment standard. The cases are fixed and public; repeated passing runs do not create statistically independent confidence. They also cannot establish absence of failures on inputs the suite never covered.

Keep loading checks separate from behavior checks

Try the corrupted candidate. Its bytes no longer match their digest, so the loader refuses to make it available. There is no valid candidate to stage.

Now try the changed-spread candidate. Its preprocessing and dependency hashes are internally consistent, so the component loads. It still changes the function learned by the original weights. Shadow compares its outputs with the recorded Python reference and detects numerical regressions. This is a compatibility-versus-behavior distinction, not evidence that the candidate was newly trained or that its botanical accuracy is worse.

The same-model candidate retains the original learned parameters but receives a different release label. It demonstrates controller and interface behavior without claiming an improved model. A release label and a model digest identify different things: packaging or service code can change while fitted model bytes remain identical.

Fallback must not erase failure evidence

Inject a candidate timeout after reaching 25%. The stable fallback can provide the expected result, but the candidate’s original receipt still says unavailable. The gate uses those raw failures rather than only the final served result, so a healthy fallback cannot justify increasing exposure to a failing candidate.

Inject the wrong-release receipt. The returned number could be plausible, yet the response cannot be attributed to the version requested. The simulation rejects it. A fallback may then run the stable component. It does not merely accept the number because it lies between zero and one.

A valid rejection of malformed input is different from service failure. The two deliberately invalid traffic cases use an unsupported unit and a numeric string. Correctly rejecting them matches the contract. The runtime does not retry a well-formed “invalid input” outcome as though the model were down.

This fallback handles timeout and bad receipt identity. It does not automatically recognize a numerically wrong but otherwise valid prediction. Regression checking detects that separately by comparing with an expected output. Real tasks may not have an immediate trusted answer, so monitoring and delayed labels are separate topics.

Charge the work that actually happened

The lab assumes a 2 ms local call, an additional 5 ms for the service boundary, and a 10 ms limit for a timed-out candidate call. These are teaching assumptions; the browser does not wait for these durations and they are not measured hardware timings.

A normal simulated service call charges 2 + 5 = 7 ms. A timed-out candidate followed by stable fallback charges 10 + 7 = 17 ms. A 10 ms per-call timeout is not a 10 ms end-to-end deadline. If an application needs an overall deadline, it must budget the remaining time before attempting fallback; that scheduler is not modelled here.

At 25%, five of twenty requests go to the candidate. If each candidate times out and falls back, the cohort charges 5 × 17 + 15 × 7 = 190 ms of summed call duration. Without faults it charges 20 × 7 = 140 ms. Those totals are work accounting, not measured throughput or elapsed time under concurrency. The shadow record includes both stable and candidate calls; do not compare its two-call cost with a single served call without acknowledging the extra work.

The actual inference-profiling lesson supplies measured local timing with its own workload and boundaries. Keep those measurements separate from these release-control assumptions.

Rollback changes future routing

Rollback sets candidate traffic to zero and retains the original stable component. It does not delete failed receipts, rewrite previous runs as successes, or correct outputs already shown. The next traffic cohort demonstrates the restored selection; the history demonstrates what happened before it.

A real rollback also depends on compatible data and state. If a release migrated a database, changed stored records or triggered an external action, selecting old model weights may not restore the earlier system. Keep compatible artifacts available, rehearse recovery and plan remediation for irreversible effects. This lab has no database migration or external action to undo.

The stable service is assumed healthy while faults affect candidate calls only. A shared network outage could defeat both the candidate and fallback. Likewise, a stale schema in the client could affect both versions. State the fallback’s assumptions instead of treating it as a universal rescue mechanism.

Leave an operating plan someone can review

• Guided experiment: load the same-model candidate, pass shadow, move to 25%, inject a timeout, inspect raw and served outcomes, roll back, and confirm future stable routing.
• Implementation practice: specify a real local service’s typed request/response contract, timeouts, bounded parsing and version attribution. Implement tests for wrong identity, malformed input and unavailable candidate, then demonstrate rollback with preserved receipts. The simulation report alone is not runnable-service evidence.
• Decision practice: write a go/no-go brief naming the candidate artifact, observed cohorts, failed assumptions, owner, stop condition, fallback cost and rollback plan. Explain which additional task and subgroup evidence you need before real users are exposed.

The downloadable report preserves the candidate identity, stage history and up to six full cohorts. A new practice deliberately clears this temporary trace; it does not change saved course progress. Public simulation checks, independent project assessment, human artifact review and learner pilots remain distinct.