Skip to content
WebmasterID

Exercise · beginner

Inspect lifecycle before integration

Pull lifecycle state for a candidate model, check for retirement date, and add a migration target to your notes if one exists.

Estimated time: 5 minutes. Exercises produce evidence artifacts, never model recommendations.

Goal

Make lifecycle a hard gate on integration decisions instead of a footnote.

Prerequisites

  • Read /learn/model-lifecycle so the four states (active, preview, deprecated, retired) are clear.

Step-by-step exercise

  1. Open the selection workspace and filter for active

    Visit /select?lifecycle=active and confirm the shortlist only includes active models.

    Open /select?lifecycle=active →

    Expected outcome: Your candidate list contains only models with a verified active lifecycle field.

  2. Open one model record

    Click any candidate. Read the lifecycle field, its citation, and any retirement date.

    Open /models →

    Expected outcome: You can name the lifecycle state and the date of the citation.

  3. Look up the same provider's deprecated entries

    Switch the filter to /select?provider=<provider-slug>&lifecycle=deprecated. Note any models the provider has deprecated.

    Open /select →

    Expected outcome: You can describe the provider's recent deprecation cadence — useful context for integration timing.

  4. Open the coverage audit

    Visit /coverage to see whether the provider's verification + lifecycle coverage is healthy.

    Open /coverage →

    Expected outcome: You can name the verified-field count and citation density for the provider.

Completion checklist

Completion checklist

  • You confirmed the candidate is in an active lifecycle state.
  • You read the lifecycle citation.
  • You checked the provider's deprecation history.
  • You did NOT integrate a deprecated snapshot 'just for now'.

Evidence artifact

At the end of this exercise you should have: A short lifecycle note: state, citation URL, retrievedAt, and any retirement date — paste-ready into a design doc.

Paste the artifact into your design doc, ticket, or PR description. The catalogue's role ends with the artifact; the workload-specific testing is yours.

Related workflow routes

Exercise does not recommend a model — external testing still required.

Common mistake

Treating 'deprecated' as still safe because retirement is months away. Deprecation + migration work usually consumes more runway than teams estimate.

Example artifact

Illustrative example — not a recommendation. Substitute your own values when you run the workflow.

Example artifact

## Lifecycle review (illustrative)
Candidate: <slug>
Lifecycle status: <active / preview / deprecated / retired>
Retirement date: <date or n/a>
Source URL: <provider docs>
RetrievedAt: <date>

Migration target (if published): <slug or 'not stated'>
Runway available: <days / weeks>
Decision: <proceed / migrate-first / re-scope>

Substitute your real shortlist, slugs, dates, and values when you walk the exercise.

Repeat this exercise when

  • A provider publishes new deprecation notices.
  • The integration timeline shifts and runway changes.
  • A snapshot rotation flips lifecycle state.

Review before moving on

  • Lifecycle status is verified, not assumed.
  • Retirement date is captured if applicable.
  • Runway vs integration timeline is explicit.
  • Successor snapshot is listed if the provider named one.

Caution: No persistence — checklist resets on every visit. Capture progress in your own notes.

What this exercise does not produce

  • A model recommendation. The exercise routes you through evidence — you decide.
  • A score or grade for any model. The catalogue does not score.
  • A substitute for external prompt, latency, rate-limit, cost, or compliance tests.