Governing Claude Against a Moving Platform: A Maintenance Model for Enterprise Deployments

Sometime in the last several months, Anthropic moved its documentation. The API reference and build guides now live at platform.claude.com. The Claude Code documentation now lives at code.claude.com. The old docs.anthropic.com URLs still resolve, because redirects are in place, but the canonical locations changed.

Most teams did not notice. The redirects masked it. Internal runbooks that linked to the old URLs kept working. Onboarding guides kept pointing developers at addresses that quietly forward somewhere else. Nothing broke loudly.

That is the tell. The platform changed underneath a governance layer that was written against a snapshot, and the only reason it did not cause an incident is that someone at Anthropic was thoughtful enough to leave redirects in place. The next change might not be so forgiving.

This is the problem with governing Claude at enterprise scale: the platform moves faster than any static governance artifact can keep up. A governance document is accurate the day it is written and decaying by the end of the week. The discipline that separates durable deployments from fragile ones is not the quality of the initial governance. It is the maintenance model that keeps governance current as the platform evolves underneath it.

What Actually Changes, and How Often

To design for change you have to know what changes. On the Anthropic platform, five categories move on independent clocks.

• Models. New models ship on a cadence measured in months, not years. Each one shifts quality, latency, pricing, and sometimes default behavior. A deployment standardized on one model is standardized on a moving target.
• The API surface. Beta headers get promoted to general availability or retired. Parameters move. Deprecation windows open and close. The 1M context beta header for older Sonnet models retired this spring. Manual thinking budgets gave way to the effort parameter. Each of these is a small change that breaks a specific integration if you are relying on it.
• Claude Code. This moves the fastest of all. In peak months the release cadence runs to dozens of changelog entries. Features get added, defaults change, and capabilities consolidate. Custom slash commands were recently merged into the skills system. A team with a runbook describing the old command structure now has a runbook describing something that no longer exists exactly as written.
• The Model Context Protocol. The MCP specification revs on its own schedule. The current specification added new primitives. Servers and clients built against an older spec version keep working through backward compatibility, until the day they do not.
• Documentation and surfaces. As the doc-domain move showed, even the location of the source of truth is not fixed.

None of these changes is dramatic on its own. The risk is cumulative. A deployment governed by artifacts written six months ago is now governed by a description of a platform that has shifted in five independent ways, and nobody has reconciled the description with reality.

The Maintenance Model

Treat platform change as a known operating condition, not a series of surprises. The maintenance model has four practices, each with a clear owner and a defined cadence.

1. Monitor

Continuous. Owned by the platform team.

Someone has to own watching the changelog. Not occasionally, not when something breaks, but as a standing responsibility. That means the Anthropic release notes, the Claude Code releases, the MCP specification, and the SDK versions. The output of monitoring is not a feeling that things are current. It is a written record of what shipped and when, reviewed on a regular cadence. Teams that monitor the platform as a first-class practice learn about deprecations during the migration window. Teams that do not learn about them when something fails in production.

2. Triage

Weekly. Owned by the platform team.

Monitoring produces a stream of changes. Triage assesses each one for blast radius. The questions are always the same. What changed? Who does it affect? What workflows depend on the old behavior? Is there a migration window, and when does it close? Most changes triage to no action. A few triage to schedule a migration. A rare one triages to act this week. The value of triage is that it converts an undifferentiated stream of release notes into a short, ranked list of things that actually require work.

3. Version

Per change. Owned by whoever owns the artifact.

Governance artifacts are code. The CLAUDE.md files, the managed settings, the MCP allowlists, the prompt registries, the runbooks. When the platform changes in a way that affects one of these, the change goes through the same review process as any other code change: a pull request, a reviewer, a record of what changed and why. This is the practice that makes the previous two worthwhile. Monitoring and triage identify what needs to change. Versioning ensures the change is deliberate, reviewed, and reversible.

4. Migrate

Per recurring change class. Owned by the platform team, executed with domain teams.

Some changes recur often enough to deserve a playbook. Model upgrades are the clearest example. A model migration is not a header swap. It is a regression event: run the prompt evaluation suite against the new model, compare quality, latency, and cost against the incumbent, require parity or improvement before cutover, and keep a rollback path. A team that has a model migration playbook treats each new model as a routine, low-drama exercise. A team without one treats each new model as either a fire drill or, worse, a thing they avoid, which means they slowly fall behind the platform they are paying for.

Who Owns This

The maintenance model assumes a platform team, even a small one. In a large enterprise, this is a named function inside the Center of Excellence. In a mid-market company, it might be one engineer with the responsibility written into their role. At the smallest scale, it is the founder.

The size of the team does not matter. The existence of clear ownership does. Platform change without an owner is platform change that accumulates silently until it surfaces as an incident. The doc-domain move did not cause an incident because Anthropic absorbed the cost with redirects. Most platform changes will not come with that courtesy, and the ones that affect your specific integrations never will.

The Platform Will Keep Moving

The velocity is not a temporary condition that will settle down once the platform matures. Rapid change is the steady state of a platform under active development, and on any reasonable time horizon the Anthropic platform will keep shipping at this pace or faster.

That reframes the governance problem. The goal is not to build governance that is correct today. The goal is to build governance that stays correct as the ground shifts, which means building the maintenance practices that keep it current. The initial governance artifact is a snapshot. The maintenance model is the thing that keeps the snapshot from becoming a fiction.

The organizations that internalize this compound their advantage. Every change becomes a small, absorbed adjustment rather than a deferred liability. The organizations that do not will keep mistaking the absence of loud failures for the presence of working governance, right up until the redirects run out.