A Model Exit Plan: Reducing Lock-In Without Building an Abstraction Maze

What this checklist is for

A model exit plan is not a promise that every model can be replaced without change. It is a way to know what would have to change, what evidence would justify a move, and how the business would keep operating while the team makes it. The target is a controlled decision—not a universal interface that pretends models behave identically.

Use this checklist when a model supports a meaningful customer or internal workflow, when a provider change could affect delivery, or when renewal, product direction, data handling, or operating needs are under review. It focuses on application-level model portability. It does not attempt to prescribe a cloud migration, procurement contract, agent incident response, or token-cost program.

The practical test is whether you can move one defined workflow from its incumbent model to a named candidate, compare results against an agreed acceptance set, understand the changes required, and decide whether to proceed. A useful exit plan can conclude that the incumbent is still the right choice. It should not force a migration merely to satisfy an abstract portability goal.

The checklist is grouped around decisions that commonly get lost between engineering, product, and operations: what is actually dependent on the model; what must stay equivalent; how to evaluate a candidate; how to expose differences safely; and what to record before calling the system portable. Each checkbox includes the reasoning and evidence to retain.

1. Define the exit decision before designing the abstraction

• Name the workflow and the reason an exit might be needed. Record the business process, user group, and consequence of an interruption—for example, extracting fields from submitted forms or drafting a support response for staff review. State whether the trigger is a planned review, a commercial change, a product change, a reliability concern, or another specific condition. “Avoid lock-in” is too vague to prioritize engineering work.

  The reason matters because different triggers produce different migration requirements. A scheduled model evaluation allows time to compare candidates and update prompts. A provider change that removes a needed behavior may create a shorter decision window. Do not invent an emergency deadline if there is no evidence for one; instead record who can set the deadline and what information they need.

• Set an exit boundary for this workflow. List what is in scope: the model call, prompt and context assembly, response parsing, downstream rules, and any human review step. Separately list what is not in scope, such as a full data-platform change or a rewrite of unrelated application services. This prevents a model substitution exercise from quietly becoming a broad replatforming project.

  The boundary should include the parts that determine whether the business result is acceptable. If a response is parsed, validated, and then used by another service, a test that compares only model text is incomplete. Conversely, unrelated storage or user-interface changes should not be bundled into the model decision unless they are genuinely required for the proposed exit.

• Write down the condition for staying as well as leaving. Define what would make the incumbent remain the preferred option: for example, a candidate fails a critical workflow case, requires unacceptable changes to review, or introduces a dependency the team cannot operate. Define what evidence would make a switch worth planning. This gives the evaluation a meaningful outcome beyond “the candidate looks promising.”

  Record the decision owner and the people who supply evidence, such as engineering, product, and the operator responsible for the workflow. The owner makes the choice; the contributors establish whether the evidence is complete. This distinction reduces the risk that a technically attractive result is treated as a business decision without considering changes to users’ work.

• Separate replaceability from sameness. Decide which behavior must remain stable and which implementation details may change. A candidate may produce different wording while preserving the required structured fields; another may match the wording but omit a value used downstream. Define acceptable variation in terms of workflow outcomes rather than assuming that matching surface form proves portability.

  A model exit plan should identify the smallest set of observable behaviors that must be preserved. If the product depends on exact response shape, specify and validate that shape. If a person reviews a draft before use, define what information and uncertainty that reviewer needs. Be precise about what is a hard failure and what is a difference the team can accept.

2. Map the real model dependency

• Inventory every call site associated with the workflow. Capture the application component, purpose, environment, owner, and exact provider model ID used at the time of the inventory. Include background jobs and secondary calls, not just the endpoint most visible in the user-facing feature. The inventory is the starting point for a real migration estimate.

  Do not use a display label such as “latest model” as the identifier in a decision record. If deployment configuration resolves a label to an exact ID, record the resolved value and when it was observed. If the team cannot establish the exact deployed ID, mark that as an inventory gap; do not silently infer it from a code comment or a remembered release.

• Trace the complete input and output path. Document which data is selected, how it is assembled, what instructions are applied, how a response is parsed, and what uses the parsed result. Include defaults, retries, validation, and any handoff to a person when those affect the workflow. A model adapter cannot make a path portable if a hidden downstream assumption remains tied to the incumbent.

  Keep the map at a useful level of detail. A short sequence such as “select record fields → construct request → parse structured response → validate required values → create draft for staff review” is often more actionable than a diagram of every service. Add implementation references only where an engineer can use them to locate the actual dependency.

• Mark provider-specific behavior rather than hiding it. Identify response formats, tool or function conventions, parameter names, and other provider-specific constructs used by this workflow. For each one, record whether it is essential, translated by your own code, or merely present in a shared interface. This makes the true cost of switching visible without assuming that every difference needs a universal abstraction.

  A provider-specific feature may be valuable enough to keep. The important decision is whether the application knows it is using that feature and has a fallback or an explicit acceptance of the dependency. If provider semantics are scattered across product code, a migration can involve many independent changes. A focused adapter can centralize translation, but it should not conceal behavior that cannot be translated faithfully.

• Locate the durable assets and the assets that need rebuilding. Record which evaluation cases, prompts, examples, schemas, and workflow rules your organization controls, and which configuration is available only through a provider’s environment. Identify what can be exported or recreated and who can do that work. Do not assume that a prompt, response history, or other artifact automatically transfers with the model.

  This inventory is about operational knowledge, not a claim that every artifact is portable in the same way. A test set that captures business requirements may remain useful even if its prompts need revision. Conversely, a prompt that has been tuned around undocumented output behavior may require careful rework. Record the distinction so the migration estimate does not treat all assets as either fully reusable or entirely lost.

• Mark each dependency by consequence and switching effort. Use simple categories such as low, medium, and high, and define them locally. For example, “high consequence” might mean an error can cause a downstream transaction to be wrong; “high switching effort” might mean multiple components or operating procedures must change. Avoid a single blended score that hides whether a dependency is risky because it matters or because it is hard to change.

  Add evidence beside each rating. A claim that a component is easy to replace should point to an existing boundary, a test, or a small demonstrated change—not merely the presence of an interface. This map also helps scope the next evaluation: test the high-consequence assumptions first rather than spending time polishing low-impact implementation details.

3. Specify what a candidate must preserve

• Write acceptance criteria in workflow terms. Define the required result, critical fields, allowed omissions, unacceptable errors, and any human action needed before the output is used. A criterion might say that a required reference number must be present in the parsed result or that an ambiguous case must be sent for review. It should be possible for two reviewers to apply the criterion consistently.

  Separate mandatory conditions from quality preferences. A missing value that blocks a business process may be a hard failure. A stylistic difference in an internal draft may be acceptable. If every preference is treated as mandatory, the team may reject a viable candidate; if nothing is mandatory, a candidate can appear acceptable while quietly breaking the workflow.

• Build a representative evaluation set from real workflow variation. Include ordinary cases, incomplete or ambiguous inputs, edge cases that downstream code handles, and examples where the correct action is to abstain or request review. Remove or handle sensitive information according to the organization’s own policies. Record why each case is included so the test set stays connected to actual work.

  A set made only of easy, clean inputs can reward a candidate that fails precisely where staff need support. Include enough variation to cover the workflow’s meaningful branches, while avoiding the false confidence of treating a small set as proof of universal performance. The evaluation set is a decision aid whose limits should be stated alongside its results.

• Keep expected outcomes separate from model-produced examples. For each case, record the acceptable answer or outcome and the reason it is acceptable. Where multiple results are valid, describe the allowed range or the review path rather than insisting on one exact phrase. This makes it possible to compare candidates without turning the incumbent’s wording into the definition of correctness.

  Have someone familiar with the work check the criteria before a migration decision. That reviewer can identify cases where a technically valid output would still create confusion or extra work. For a broader approach to selecting useful release measures, see Benchmarks That Actually Matter for New Model Releases.

• Choose the evaluation method for each criterion. Some conditions can be checked mechanically, such as whether required fields exist or whether a value passes a format check. Other judgments—such as whether a summary preserves an important distinction—need a defined review method. Record who or what assesses each criterion, and how disagreements are resolved.

  Do not turn a subjective judgment into a numeric score unless the scoring rules have a clear interpretation and are applied consistently. A single aggregate number can conceal a severe miss in one important case. Keep critical failures visible in the result, even when the candidate performs well across less consequential examples.

• Define the minimum evidence for a decision before running comparisons. Specify which cases must be covered, which failures block approval, what additional review is required, and who signs off on the workflow result. Include the exact model IDs, relevant request configuration, prompt version, evaluation-set version, and test date in the record. These details make the comparison repeatable enough to inform a later decision.

  Decide in advance whether a candidate needs to meet every hard criterion or whether a particular shortcoming can be mitigated by a changed review step. If the latter, include that change in the candidate design and evaluate the full workflow again. Do not treat an informal rerun with different prompts or settings as the same test; version the changed inputs.

4. Keep the abstraction small and honest

A portability layer is useful when it gives the application one stable place to express the parts of a request that genuinely recur and to handle known differences. It becomes an abstraction maze when it tries to make unlike model behavior look identical, accumulates optional fields nobody understands, or spreads provider selection across unrelated services. The design goal is a clear seam with visible exceptions.

• Define the smallest application contract this workflow needs. Specify the inputs your application owns, the output it expects, and the error states it must handle. Include only fields used by this workflow. Avoid designing a universal request object around hypothetical future models; each extra concept adds translation and testing obligations without proving that a future migration becomes easier.

  A practical contract might represent the task, relevant context, desired output shape, and the application’s handling of invalid or incomplete results. It need not expose every setting of every provider. When the application genuinely requires a provider-specific capability, represent that requirement explicitly or route it through a deliberately specific path rather than pretending it is a universal feature.

• Keep provider adapters responsible for translation, not policy. An adapter can translate the application’s request into a provider request and map the response or error into an application-level form. Business rules—such as whether a result is acceptable or must be reviewed—belong in the workflow where they can be tested and understood. This separation reduces the chance that switching providers also changes business meaning.

  For systems that connect to external tools, avoid assuming that a common tool representation makes execution semantics identical. The MCP architecture separates host, client, and server roles, and treats transport and authorization separately from tool semantics; this is a useful reminder that a shared connection pattern does not itself standardize what a tool does. See the MCP architecture specification when that distinction is relevant to your design.

• Preserve observable provider identity and configuration. Ensure an operator can determine which exact model ID and configuration handled a result, without relying on a generic label in an application log. Keep the identity associated with the evaluation or operational record. The purpose is diagnosis and repeatability, not collecting more data than the workflow needs.

  If the provider changes behavior under a label or a configuration is updated, your records should let the team distinguish those events from an application-code change. Record the information needed for that comparison while following the organization’s data-retention and privacy rules. A portability layer that erases model identity makes a later quality investigation harder.

• Document behavior the abstraction cannot promise. State where candidates may differ, which differences are handled by validation, and which require a workflow change. If one candidate needs a different prompt or review instruction, record that as part of the candidate configuration rather than disguising it as an invisible adapter detail.

  This is where a thin boundary earns its keep: it gives the team a place to make a controlled change while keeping the limitations visible. If the abstraction requires many exceptions to preserve a fictional notion of equivalence, compare the cost of maintaining it with a direct integration and a well-documented migration procedure.

5. Evaluate a named candidate, not a category

• Choose a specific candidate model ID and record why it is being considered. A broad label such as “another provider” is not testable. Record the exact candidate ID, the date it was selected, the use case, and any relevant configuration that the team controls. If the ID or configuration changes, create a new evaluation record rather than assuming the earlier result still applies.

  Keep the comparison bounded to the exit decision. The goal is not to rank every available model or claim that one candidate is generally superior. It is to establish whether this candidate, for this workflow and these acceptance criteria, is suitable enough to justify the next step.

• Run the same defined cases against incumbent and candidate. Keep inputs, expected outcomes, and evaluation rules aligned. Record errors, incomplete results, parsing failures, and review requirements—not just successful responses. Where request configurations must differ, record the difference and why it is necessary so the comparison remains interpretable.

  Do not present an illustrative comparison as a measured result. For a real decision, record the exact model IDs, test date, evaluation-set version, prompt versions, and any limitations. A useful report can say that the comparison is incomplete or inconclusive. “Not enough evidence” is a valid result and is safer than treating an unstructured demonstration as a migration approval.

• Compare the end-to-end workflow, including the downstream consumer. Check whether the parsed result satisfies validation and whether the next step behaves as intended. If a person reviews the output, assess the information they receive and the action they must take. A response that reads well but changes a downstream decision is not equivalent for this workflow.

  Assign responsibility for verifying the business result separately from judging a model’s text. The person evaluating the output should know which outcomes matter and what constitutes an acceptable escalation. If the model makes a claim that is not independently checked by the workflow, do not treat confident wording as proof that the business result is correct.

• Record costs and operating constraints without reducing the choice to price. Capture the assumptions used to estimate request volume and workload, along with any relevant latency, review effort, or operational changes measured in the evaluation. Keep those values tied to the candidate and date; do not treat a calculation based on assumed traffic as an observed bill or guaranteed saving.

  This article does not prescribe a token-budget or agent-workflow cost model. If the workflow involves multiple agent steps and cost allocation across them, use the more specific treatment in FinOps for AI Agents: Budget the Workflow, Not Just the Model. For a single workflow exit decision, include only the cost and effort evidence that changes the choice.

• Review the result against a counterexample. Identify a case where an apparently portable design could still fail: a candidate returns valid-looking fields with a different interpretation, an ambiguous input is handled differently, or an adapter maps an error into a misleading success state. Add that case to the evaluation or record why it does not apply.

  A counterexample is not a reason to reject abstraction by default. It tests whether the team has mistaken a common shape for common semantics. If the candidate fails, decide whether a clear validation or review rule can contain the difference. If not, document the dependency and its accepted business consequence rather than hiding it in a generalized interface.

6. Plan a controlled change and a safe return path

The exit sequence should match the workflow’s actual exposure. A low-impact internal drafting feature may be evaluated in a controlled non-production setting before a limited operational trial. A workflow that affects important decisions needs stronger evidence and an explicit way to stop the change. A percentage of traffic is not automatically an appropriate experiment, and it should not be assumed that every hosting route can split traffic.

• Choose a rollout method that the system can actually support. State whether the candidate is tested offline, in a separate environment, with an explicitly selected set of cases, or through another available route. Name the component that selects the model and confirm that it can direct the intended requests. Do not promise a canary merely because it appears in an architecture diagram.

  If the design needs a canary, define the external routing mechanism and how the selected requests are identified. Verify that the proposed route is compatible with the actual hosting arrangement before scheduling the change. For the distinct problem of staged agent and prompt changes, see Canary Releases for Agent Changes: Prompts Need Rollback Too.

• Define stop conditions in observable terms. Examples include a critical required field failing validation, an increase in cases sent for review beyond the agreed limit, or a downstream process receiving an invalid result. Set the responsible observer and the action they can take. Avoid thresholds that cannot be measured with the system’s existing instrumentation.

  Stop conditions should be connected to business consequences, not chosen solely because they produce a tidy dashboard. If a threshold needs a baseline, establish the baseline and its period before the change. If evidence is insufficient to set a defensible numeric boundary, use a specific qualitative condition and a named reviewer rather than inventing precision.

• Make rollback a tested operational action, not an assumption. Record how the workflow returns to the incumbent configuration, who can authorize that action, and what must be checked afterward. Include configuration and prompt versions so the previous known state can be restored. A rollback is not complete until the workflow is confirmed to be using the intended model and its normal checks are functioning.

  Test the return path in a controlled environment where practical. If it cannot be tested beforehand, list the unverified steps as a risk and assign an owner to verify them before production change. Do not assume switching a model ID automatically reverses changes to parsing, prompts, review procedures, or downstream data.

• Account for work already in flight. Decide how requests, queued jobs, and partially completed cases are handled if the candidate is stopped. Ensure operators can distinguish a completed result from one that needs retry or review. Where an action affects an external system, define how the workflow avoids accidentally repeating that action during recovery.

  Do not promise exactly-once effects merely because the model call is retried or the application can restore an earlier configuration. The workflow must identify what has already happened and what remains to be done. If recovery becomes a broader operational incident, use the organization’s incident process; the related Agent Incident Runbook: Stop, Contain, Investigate and Resume addresses that separate response problem.

7. Make the decision path explicit

The following flow is a compact decision aid, not an automatic migration policy. A failed candidate evaluation returns the team to the incumbent while the gap is understood; an incomplete evaluation is not treated as a pass. If the candidate passes the agreed criteria, the team still decides whether a controlled rollout is justified by the workflow’s risk and expected benefit.

flowchart TD
  accDescr: Workflow stages and decisions: Map incumbent workflow, Define acceptance criteria, Select exact candidate ID, Evaluate same cases, Criteria met?, Keep incumbent; revise plan, Approve controlled change. The adjacent text explains the conditions and exceptions.
  accTitle: A Model Exit Plan — Reducing Lock-In Without Building an Abstraction Maze workflow
    A["Map incumbent workflow"] --> B["Define acceptance criteria"]
    B --> C["Select exact candidate ID"]
    C --> D["Evaluate same cases"]
    D --> E{"Criteria met?"}
    E -->|"No or unclear"| F["Keep incumbent; revise plan"]
    E -->|"Yes"| G["Approve controlled change"]

• Require a complete evaluation record before treating the flow as passed. The record should identify the incumbent and candidate model IDs, test date, request and prompt versions, evaluation cases, results, and known limitations. A test with missing configuration details may still help exploration, but it is not strong evidence for a repeatable exit decision.

  If a candidate changes during the evaluation or a prompt is materially revised, state which results still apply and which must be rerun. The chart deliberately has no shortcut from choosing a candidate to approving a change. Candidate selection starts an evaluation; it does not establish suitability.

• Treat “unclear” as a distinct outcome. An incomplete set, conflicting reviewer judgments, a parsing problem, or an untested critical branch should leave the decision unresolved. Assign the next evidence-gathering action and a date for review. This avoids the common failure mode in which schedule pressure turns missing information into tacit approval.

  The team may decide to continue with the incumbent while gathering evidence. That is not the same as proving that the incumbent is low risk. Record the unresolved dependency and whether the workflow has a practical continuity measure, such as a manual review path or a reduced-scope operating mode.

8. Prepare the versioned decision table

Use this worksheet as a printable record. It is deliberately a decision table, not a claim that a migration test has been run. Replace the bracketed fields with values from the actual environment before relying on it. Do not fill a model ID from memory, and do not mark a test complete without its date and evaluation record.

• Version the worksheet when the decision inputs change. A new candidate ID, meaningful prompt revision, changed evaluation set, or altered acceptance rule can make an earlier comparison stale. Retain the earlier record and create a new version with the changed fields identified. This preserves the reasoning behind a decision without implying that old evidence applies to a different system.

  The worksheet’s preparation date above is not a test date. That distinction matters: it prevents a template from looking like measured evidence. When the comparison is eventually run, enter the actual test date and exact model IDs, including the incumbent’s ID, then attach or reference the results and known limitations.

• Record a decision that can be revisited. Select one outcome: stay with the incumbent, gather more evidence, or plan a controlled change. Add the reason, the evidence used, the unresolved risks, and the next review date. If the team stays, record whether that is an affirmative choice based on the evidence or a temporary choice because the evaluation is incomplete.

  A useful decision record says more than “approved.” It explains what the decision covers and what would reopen it. For example, a result might apply only to one workflow and one candidate ID, with a review required if the request format, prompt, or downstream process changes. Scope limits make a future review faster and prevent a local result from becoming a general claim.

9. Check operational ownership and review cadence

• Assign a named owner for the dependency map and evaluation evidence. The owner keeps exact model IDs, workflow boundaries, acceptance criteria, and the decision record current. This does not mean one person performs every review; it means there is a clear destination when someone needs to know whether a migration claim has evidence behind it.

  Keep the work proportionate. A small, low-impact workflow may need a concise record reviewed when its trigger occurs. A business-critical workflow may need a more regular review because the consequences and change exposure are greater. Choose a cadence that reflects the decision, rather than adding a quarterly meeting that produces no new evidence.

• Revisit the exit plan when the system changes materially. Review it when the deployed model ID changes, a provider-specific feature is added, the output schema changes, or the downstream process begins using the result differently. These changes can invalidate assumptions even if no vendor switch is planned. Record whether the existing evaluation still represents the workflow.

  A release review should ask whether the dependency map and acceptance set need updating, not automatically repeat every test. For a targeted method of assessing a new Claude version without retesting unrelated behavior, see Evaluating a New Claude Release Without Re-Testing Everything. Keep the scope focused on the affected behavior.

• Confirm that the people operating the workflow understand a candidate change. Explain what output differences they may see, which cases require escalation, and where they report a problem. If a human review step changes, update its instructions and give reviewers a way to distinguish a candidate trial from the established workflow.

  An engineering-only approval can miss added operational effort. Reviewers may see more ambiguous cases, need different context, or need to take a different action. Include that work in the decision and evaluation. If the change makes the workflow harder to operate, the candidate may not be an acceptable exit even when its model responses satisfy a narrow technical check.

• Check whether the abstraction is still earning its maintenance cost. Review the provider adapter, exception handling, tests, and documentation when a model change is considered. Remove unused compatibility paths and clarify any mapping that obscures different behavior. Keep only the boundary that supports an actual application need or a credible, evaluated exit path.

  A wrapper is not valuable merely because it exists. Its benefit is demonstrated when it centralizes real translation, makes a change easier to inspect, or enables a repeatable comparison. If it creates duplicate configuration, ambiguous error handling, or a growing matrix of combinations nobody tests, simplify it or document why the additional complexity is justified.

10. Judge portability by evidence, not by architecture labels

A system can have a clean-looking model interface and still be difficult to move because its prompts, parsing assumptions, and workflow decisions depend on one model’s behavior. Another system can use a direct provider integration yet have a credible exit plan because its requirements, tests, and recovery path are well understood. Architecture matters, but it is not a substitute for evidence.

Consider a hypothetical operations team that uses a model to extract a few fields from submitted forms and create a draft for staff review. The team has a stable internal output schema, but staff have learned to correct a particular kind of ambiguous result. A candidate returns the required fields on ordinary examples yet handles that ambiguous case differently, causing more work for reviewers. The correct next step is not automatically to add a larger universal abstraction. It is to make the ambiguity criterion explicit, test the review path, and decide whether a focused adapter or workflow change can manage the difference.

Now consider the counterexample: a team builds a broad router with options for many hypothetical providers, normalizes every response into one generic shape, and assumes that any model behind it is replaceable. The application no longer exposes which exact model handled a result, and the generic error mapping hides a provider-specific failure as an empty response. The interface is more abstract, but the exit decision is less defensible because the team cannot reproduce what happened or see where semantics changed.

The better design is not the one with the fewest lines of integration code or the most vendors represented. It is the one whose workflow boundary is explicit, whose critical behavior can be evaluated, and whose exceptional differences are visible. Keep an abstraction if it reduces the work of a real, bounded change. Avoid one whose promise depends on all candidates behaving alike.

• Confirm that the evidence supports the decision actually being made. An evaluation of one workflow and candidate does not establish portability for every feature in the application. State the boundaries of the result and identify any other model-dependent workflows that remain unassessed. This is especially important when a shared adapter serves different product functions.

  If an organization needs help defining model-selection criteria, workflow boundaries, or an evaluation plan, AI strategy and model selection is a relevant next step. The immediate internal task remains concrete: name the workflow, its exit trigger, its exact incumbent ID, and the evidence needed to choose a candidate.

Printable summary

Use this compact page at a planning meeting or in a change review. Check an item only when there is evidence or a named owner and next action. The worksheet above holds the detailed record; this summary is a quick completeness check, not a substitute for results.

Decision and dependency

• We named the workflow, its business consequence, and a specific exit trigger.
• We set a clear boundary around the model-dependent path and its downstream use.
• We recorded the deployed incumbent’s exact model ID and configuration source.
• We mapped prompts, parsing, validation, provider-specific behavior, and review steps.
• We separated high-consequence dependencies from high switching effort.

Evaluation evidence

• We defined hard acceptance criteria and acceptable variation before comparing models.
• Our evaluation cases cover routine, ambiguous, incomplete, and critical workflow paths.
• We identified who evaluates each criterion and how disagreements are resolved.
• The candidate has an exact model ID, and the test record includes a real test date.
• Results include failures, limitations, workflow effects, and unresolved differences.

Change readiness

• Our application boundary handles only the behavior the workflow actually needs.
• Provider-specific differences and model identity remain visible to operators.
• The rollout route is supported by the actual system design and has an owner.
• Stop conditions, in-flight work, and the return path are documented.
• The decision record says stay, gather more evidence, or plan a controlled change.
• A named owner and next review date are recorded.

A model exit plan is ready when the organization can explain what it depends on, what “good enough to move” means for the workflow, and how it will detect and respond to a bad change. It is not ready simply because an adapter exists, another model has been named, or a comparison produced a favorable summary. Keep the boundary small, make the evidence reproducible, and preserve the option to stay when the candidate has not earned a change.

WANT TO TALK THROUGH YOUR SITUATION?

Talk it through with us. Thirty minutes, no slides.