Versioning Pacts Without Breaking Counterparties: The Migration Pattern That Holds

TL;DR

A pact with 30 active counterparties cannot be silently changed. Operators learn this the hard way the first time they try. Pacts are signed contracts; changing the predicate set, the evidence schema, or the penalty calibration is a contract amendment that has to be negotiated, signed, and migrated to. The migration pattern that holds is four stages: announce, dual-run, migrate, retire. The discipline that keeps it sane is semver applied to behavioral commitments — major for behavior changes, minor for additive scope, patch for clarifications. This essay walks the pattern in detail and ends with a Pact Migration Checklist you can run before any pact change goes live.

The pact-upgrade incident that breaks 30 deals

An agent operator decides to update their standing pact. The update looks small from the operator's seat. They are tightening a Predicate around response-time guarantees because the underlying model is now faster and they want the pact to reflect the better SLA they can offer. They edit the pact text, bump a version number, and push the new pact to their pact registry. They do not negotiate with their existing counterparties because, in their mental model, they are improving the pact rather than degrading it.

Within two weeks, the operator has lost four deals, accumulated three formal disputes, and triggered an automatic operational pause on a tier-sensitive marketplace. The post-mortem identifies five distinct failure modes that each independently broke the migration.

The first counterparty had built their internal monitoring against the old Evidence specification, which expected a 90-second response window. The new pact's 60-second window changed the threshold the post-hoc jury used, and the counterparty's monitoring started flagging "violations" that were not actually violations under the new pact — but the counterparty's automation rolled back to the prior provider before anyone noticed the threshold had moved.

The second counterparty had a deal contract that referenced "the pact in force at deal signing." When the operator changed the pact, the deal contract's reference became ambiguous. The legal team flagged it; the deal got paused for clarification; the operator lost two months of revenue while the lawyers worked it out.

The third counterparty's automation had hardcoded the pact version string in a comparison check. When the version bumped, the check failed, the automation refused to dispatch work to the agent, and the counterparty silently routed work to a competitor for a week before anyone realized.

The fourth counterparty did not notice the change at all but their post-hoc jury did, because the jury was reading the Evidence specification from the new pact and the agent's actual telemetry was emitting the schema the old pact specified. Verdicts started coming back as inconclusive, the counterparty's automated reputation feed started flagging the agent as low-confidence, and the relationship cooled without either party knowing why.

The fifth counterparty's compliance team treated the silent change as an unauthorized contract modification and filed a formal dispute. The dispute would have been resolvable in the operator's favor (the change was an improvement, not a degradation) but the dispute itself triggered a 30-day operational hold on the deal.

None of these failures were inevitable. All of them are predictable consequences of treating a multi-party signed contract as if it were a configuration value the operator can edit unilaterally. The migration pattern that prevents them is the subject of this essay.

Why pacts cannot be changed in place

The core mistake in the incident sketch is treating the pact as an editable artifact. It is not. A pact is a signed object whose signatures anchor a specific version to a specific commitment. Changing the version invalidates the signatures. Changing the content without bumping the version produces an unsigned object that no longer represents the contract.

This is the same property that makes git tags immutable, JWT tokens unmodifiable after issuance, and SSL certificates require reissue rather than edit. The signed nature of the artifact is the property that makes it trustworthy; preserving that property requires that changes happen through versioned reissuance rather than in-place edit.

The consequence is that every pact change is a migration. There is no "silent fix." There is no "minor edit that nobody needs to know about." The smallest pact change — a typo correction in a Predicate — is still a new version, still requires re-signing, and still has to be propagated to the systems that read the pact. The propagation may be cheap (in the typo case, nothing depending on the pact's behavior changes) but the migration mechanism is the same as for the largest change.

This discipline feels heavy until the first time it prevents an incident. The teams that resist it are the teams that have not yet had the incident; the teams that have had the incident enforce it absolutely.

Semver for pacts: major, minor, patch

The versioning discipline that maps cleanly onto pacts is semver — semantic versioning — adapted from software releases. The rules are simple and load-bearing.

A major version bump indicates a behavior change. The Predicate set has changed in a way that affects what the agent will do. A response-time threshold tightened. A scope was narrowed. A safety constraint was added. A penalty was strengthened. Anything that changes the agent's observable behavior or the consequences of its actions is a major bump. Major bumps require renegotiation with every active counterparty; they cannot be deployed unilaterally.

A minor version bump indicates additive scope. New Predicates have been added that expand the agent's capability set without changing existing commitments. New Evidence sources have been added that supplement existing ones. New Penalties have been added that apply to new Predicates. Minor bumps do not require renegotiation in most cases — they are strictly additive — but they do require notification so counterparties can update their monitoring and acknowledgment.

A patch version bump indicates a clarification. The Predicate set is unchanged. The Evidence specification is unchanged in substance. The Penalty calibration is unchanged. What changed is wording, formatting, or precision of language that resolves ambiguity without changing intent. Patches can be deployed with notification only and require no acknowledgment.

This three-tier discipline gives counterparties a clean signal about what kind of change they are looking at. A counterparty receiving a major-version notification knows they need to engage; a minor-version notification means they should review and update monitoring; a patch-version notification is informational. Without this discipline, every pact change looks like a potential crisis, and the response is either alert fatigue (changes get ignored) or paralysis (no changes happen).

The failure mode of semver-for-pacts is misclassification. Operators often want to call a tightening of behavior a "minor improvement" rather than a major change because it sounds less disruptive. This is exactly wrong. A tightening is a major bump because it changes what the agent commits to, even if the change benefits the counterparty in expectation. The discipline is to err on the side of larger bumps; it costs nothing to call a minor change major and engage counterparties unnecessarily, and it costs deals to call a major change minor and break counterparties silently.

The related discipline is to use the version string everywhere. The pact's signed object includes the version. The agent's runtime configuration references the version. The post-hoc jury reads the version. Every system that touches the pact knows which version it is operating under, and version mismatches are detectable rather than silent.

Stage one: announce

The first stage of pact migration is announce. The operator publishes the proposed new version of the pact to all active counterparties, along with a structured diff that explains what changed and why. The announcement is not a request for approval (that comes in later stages); it is a request for review.

The announcement has five components. The current pact version that is being superseded. The proposed new pact version, in full text. The structured diff showing field-by-field changes with semver classification (this Predicate is new, this one was modified, this Evidence threshold tightened from X to Y). The motivation — why the operator is making the change. And the migration timeline, including the dual-run window and the planned retirement date for the old version.

The announcement window is typically two to four weeks for a major change, one to two weeks for a minor change, and as short as 48 hours for a patch. The duration is calibrated to give counterparties enough time to review, ask questions, and propose modifications, while not so long that the migration drags on indefinitely.

The announcement channel is structured. Operators in 2026 use a combination of: a notification through the pact registry's API (which counterparty automation can consume), an email to each counterparty's compliance contact (for human review), and a publication on the operator's pact-changes feed (which downstream observers can subscribe to). The Trust Oracle reflects the announcement immediately so that any third party reading the agent's pact set sees both the current pact and the proposed change.

What the announcement stage catches is the counterparty objection. A counterparty might respond "we cannot accept the tightened response-time threshold because our SLA to our own customers depends on the looser threshold staying in place." Or "we need the new Evidence schema to be backward-compatible because our monitoring cannot be updated in this quarter." Or "we object to the new penalty calibration as too punitive for the violation class." Each of these is feedback the operator can act on by adjusting the proposed pact, extending the migration timeline, or carving out exceptions for specific counterparties.

The failure mode of the announce stage is treating it as ceremony. Operators who push announcements without genuinely engaging with feedback discover that the feedback they ignored becomes the dispute they litigate three months later. The announcement stage is the cheapest place to catch problems with the pact change, and the cost grows by orders of magnitude in each subsequent stage.

Stage two: dual-run

The second stage is dual-run. The operator deploys the runtime infrastructure to support both the old pact and the new pact simultaneously, for a defined window. During the dual-run window, both pacts are technically in force. The agent's behavior is evaluated against both the old Evidence specification and the new one. Verdicts are produced under both. The composite score takes the more lenient of the two during the dual-run period (which protects the agent from being penalized for transitional inconsistencies).

Dual-run does several things at once. It lets counterparties test their integrations against the new pact while the old one is still authoritative. It produces parallel evidence streams that the operator can compare to validate that the new pact's behavior matches expectations. It surfaces incompatibilities between the new pact and the agent's actual telemetry early enough to fix them before the migration completes. And it gives counterparties a defined window to acknowledge migration readiness without forcing an instant cutover.

The duration of the dual-run window depends on the change's severity. A patch can dual-run for a few days. A minor change should dual-run for one to two weeks. A major change should dual-run for at least four weeks, and longer if any counterparty is using the time to update integrations or monitoring. The cost of dual-run is real — running two evidence pipelines is more expensive than one — but it is the cheapest insurance against migration failure.

The technical surface of dual-run is the part most teams underestimate. The agent's telemetry has to emit both the old and new schema. The runtime guardrail has to evaluate against both Predicate sets. The post-hoc jury has to produce verdicts under both Evidence specifications. The pact registry has to mark both pacts as active for the dual-run window. The composite score logic has to handle the case where both pacts are scoring the same interaction. None of this is technically deep, but all of it is fiddly, and skipping any of it produces silent gaps that surface as disputes.

The dual-run stage also catches a category of pact-change problem that nothing else catches: the operator's own implementation bug. Operators sometimes change a pact in a way that they cannot actually deliver against. Dual-run produces side-by-side evidence that exposes the gap. Better to find that during dual-run, when the old pact is still authoritative, than to find it after migration when the agent is silently violating the new pact every interaction.

Stage three: migrate

The third stage is migrate. The new pact becomes authoritative, the old pact transitions to deprecated, and counterparties switch their integrations to read against the new pact. This is the stage that looks like the entire migration to outside observers; in practice, if the announce and dual-run stages went well, this stage is administrative.

The migrate stage requires a defined cutover. At a specific timestamp, the new pact's status flips from "proposed during dual-run" to "in force." The old pact's status flips from "in force" to "deprecated." Both transitions are signed events recorded in the pact registry and propagated to the Trust Oracle. After the cutover, the post-hoc jury produces verdicts only under the new pact (the dual-run parallel pipeline shuts down). The composite score takes only the new pact's evidence.

The cutover itself should be communicated. A second wave of notifications goes out to counterparties confirming that the migration is complete and that any monitoring still reading the old pact will produce stale results. The Trust Oracle's pact set view updates so that the agent's current pact is unambiguously the new one.

What can still go wrong at this stage is the counterparty who did not engage during announce or dual-run and is now caught flat-footed. Their monitoring is broken, their integration is reading the wrong schema, their compliance team is fielding alerts they cannot interpret. The operator's options are limited at this point — the migration has happened, the old pact is deprecated, and rolling back is more disruptive than helping the lagging counterparty catch up. The lesson is that engagement during announce and dual-run is not optional; counterparties who skip those stages bear the cost.

The migrate stage also has to handle the agent's actual runtime cutover. The runtime configuration that was emitting both old and new schemas now emits only the new one. The runtime guardrail that was evaluating both Predicate sets now evaluates only the new one. These transitions need to be coordinated with the pact registry's cutover so that there is not a window where the runtime is one version and the registry is another.

Stage four: retire

The fourth stage is retire. After a defined period — typically 30 to 90 days after migration — the old pact transitions from deprecated to retired. The retired pact is still queryable for historical purposes (any interaction that occurred under the old pact is still graded under the old pact's specification, forever) but no new evidence is produced under it and no integration should be reading it as a current contract.

The retire stage is the cleanup. Counterparty integrations that were reading the old pact should have been updated by now; any that have not are flagged. The operator's runtime no longer emits the old schema; storage of the old evidence streams transitions to archive. The pact registry updates to show the old pact's lifecycle as complete.

What retire prevents is the long-tail integration that keeps reading a pact long after it is no longer authoritative. Without a retire stage, deprecated pacts pile up and the integration ecosystem becomes ambiguous about which pact is the current one. Counterparties' monitoring drifts to whichever version they last integrated against, which may or may not be current. The retire stage forces the question: is this pact still in use? If yes, the migration was not complete and there is residual cleanup to do. If no, archive it cleanly.

The retire stage is also the right time to publish a post-migration report. What changed in the pact, who acknowledged the change in which stage, what the dual-run period revealed, how many counterparties needed extra support to migrate. This is institutional learning that makes the next migration cheaper and informs future pact-change governance.

When to use the four stages versus a faster path

The four-stage pattern is calibrated for major and minor pact changes with multiple active counterparties. It is overkill for some cases and underweight for others.

A pact patch — a clarification with no behavioral change — does not need dual-run because there is nothing for counterparties to test against. The pattern collapses to announce and migrate, with retire happening immediately. The whole sequence can run in 48 hours.

A pact change for a brand-new pact with no counterparties yet does not need announce because there is nobody to announce to. The whole sequence collapses to deploy and use.

A pact change driven by a regulatory or safety emergency — the agent is doing something dangerous and the pact has to change immediately to constrain it — cannot wait for the four-stage pattern. The right pattern here is emergency deploy with retroactive announce: deploy the constraint immediately, then engage counterparties about how to migrate cleanly. The emergency is the correct override; the discipline is to use it only for actual emergencies.

A pact change with very high stakes — a financial pact governing millions in flow, a safety pact with regulatory exposure — should extend the four-stage pattern, not compress it. Six-week dual-run windows, multiple announcement waves, formal counterparty acknowledgments before migration, and longer deprecation periods are all reasonable for high-stakes pacts.

The pattern is a default, not a mandate. The right cadence depends on the change's severity, the number of counterparties affected, and the operational risk of getting the migration wrong.

Backward-compatible pact design: making future migrations cheaper

The smartest pact migration is the one that does not need the full four stages because the original pact was designed with backward compatibility in mind. A few design choices in initial pact authoring make subsequent migrations dramatically cheaper.

The first is explicit Evidence schema versions. Every Evidence specification carries its own version string, and the runtime emits multiple schema versions in parallel for a defined window. When the pact is updated to use a newer Evidence schema, the migration is just a pact-version bump; the runtime is already producing the new schema and nothing material has to change.

The second is additive Predicate design. Predicates that are written to be composable rather than monolithic make minor-version additions easier. A pact with one Predicate "the agent will respond within 90 seconds and refuse out-of-scope requests and not disclose PII" is hard to extend cleanly. The same commitments split into three Predicates can have a fourth added without disturbing the three.

The third is wide initial scope on Renewal. Pacts that include explicit clauses for how minor changes are handled — "minor-version updates do not require re-signing if the counterparty does not object within 14 days" — bake the migration discipline into the contract from the start. Subsequent migrations can use the contractual machinery rather than negotiating from scratch.

The fourth is structured Penalty composition. Penalties that are expressed as a set of components (bond percentage, score delta, operational pause) rather than a single numeric value can be extended without re-calibrating from zero. Adding a new component to an existing Penalty is a minor change; replacing the whole calibration is a major one.

None of these design choices is free, and all of them require the original pact author to anticipate future change. But anticipated change is what serious infrastructure design looks like; pacts that are designed only for their first day of operation will require painful migration on every subsequent change.

The Pact Migration Checklist

The artifact for this essay is a checklist you can run before any pact change goes live. The checklist is structured to catch the failure modes from the opening incident sketch by name.

1. Classify the change. Is this a major, minor, or patch bump? Apply the semver rules strictly. When in doubt, classify higher.

2. Inventory active counterparties. Who is currently signed against the existing pact? What integrations do they have that depend on the pact's specifics? Pull this list before you start; updating it during migration is a sign you started without enough preparation.

3. Draft the new pact in full. Not a diff; the full new text, signable. Run it through the structural validation you would run on a new pact: all five fields present, all Predicates dimension-tagged, all Evidence sources schema-versioned, all Penalties calibrated.

4. Generate the structured diff. Field by field, what changed. Each change tagged with the semver classification (this added a Predicate — minor; this tightened an Evidence threshold — major; this reworded a Penalty — patch). The diff is the artifact counterparties will read; make it scannable.

5. Plan the migration timeline. Announce window, dual-run window, migrate cutover, retire date. Calibrate by change severity. Publish the timeline as part of the announcement.

6. Engage counterparties during announce. Not just notify — engage. Solicit objections, propose accommodations, adjust the new pact in response. The announce stage is the cheapest correction window.

7. Verify dual-run readiness in the runtime. The agent's telemetry emits both old and new schemas. The runtime guardrail evaluates both Predicate sets. The post-hoc jury produces verdicts under both. The pact registry has both pacts marked active. None of this works automatically; it has to be tested before dual-run starts.

8. Monitor the dual-run period for divergence. Are the parallel verdict streams agreeing? Where they disagree, why? Are any counterparties' integrations producing errors against the new pact? Investigate every signal.

9. Confirm migration cutover with counterparties. Send the cutover notification with explicit confirmation that counterparties have updated their integrations and are reading the new pact. Track who has confirmed; follow up with those who have not.

10. Execute the cutover atomically. New pact in force, old pact deprecated, runtime emits new schema only, registry updates, Trust Oracle reflects the change. All in a single coordinated operation, not a drift across hours.

11. Document the retirement of the old pact. Plan the retire date, communicate it, and execute it cleanly when it arrives. Archive the old pact's evidence streams; do not delete them (interactions that occurred under the old pact remain graded under it forever).

12. Publish the post-migration report. What changed, what worked, what did not. Use it to inform the next migration and to demonstrate institutional discipline to counterparties.

The checklist is structured so that skipping any item produces a known failure mode. Skip step 2 and you discover counterparties you did not know about during stage three. Skip step 6 and you discover their objections during stage four. Skip step 7 and you discover runtime gaps in dual-run. Skip step 9 and you discover stranded integrations after migration. Each step is doing specific work; cutting corners is borrowing trouble.

Counter-argument: "This is too much process for a small pact change"

The strongest objection to the four-stage migration pattern is the same as the objection to most disciplines: it is heavyweight for cases that do not need it. A small pact change with few counterparties can absorb a sloppier migration without much pain. The full pattern, with its checklists and notification waves and dual-run engineering, feels like overhead for the simple case.

This is right and the response is calibration, not abandonment. The four-stage pattern compresses naturally for small cases — patches in 48 hours, minor changes in a week, no-counterparty cases in an afternoon. The discipline is in the structure (announce, dual-run, migrate, retire) rather than in the specific timeline. A pact change that runs through all four stages quickly is still safer than a pact change that skips stages, even if the quick version takes only a fraction of the time.

The deeper response is that the cost of getting a pact migration wrong is asymmetric. A successful migration is invisible; a failed migration breaks deals, accumulates disputes, and damages the operator's reputation across the entire counterparty graph. The migrations that fail are not the small, low-stakes ones; they are the medium-stakes ones where the operator decided the pattern was overkill and skipped the disciplines that turned out to matter. Following the pattern even on small changes builds the muscle memory that makes the medium and large changes safer.

The pragmatic adaptation is to template the migration. Most pact changes for a given operator follow a small number of patterns (Evidence threshold tightening, Predicate addition, Penalty calibration), and each pattern can have a templated migration plan that fills in the specific values. The first few migrations are full process; subsequent ones inherit from the templates and execute much faster. This is the right way to amortize the discipline.

How migration interacts with the broader pact ecosystem

A pact migration does not happen in isolation. The pact being changed is part of a broader ecosystem — other pacts the same agent holds, other agents the counterparty engages, marketplaces and platforms that read the pact's metadata, downstream consumers of the agent's verdicts and scores. Migrations that ignore this ecosystem context produce ripple effects that the migration plan did not anticipate.

The most common ecosystem interaction is the agent's other active pacts. An agent operating under multiple pacts simultaneously may have shared Evidence schemas across them; a migration that changes one pact's Evidence schema may inadvertently affect the verdict pipeline for the other pacts. The right discipline is to inventory all of the agent's active pacts at the start of migration and identify which ones share evidence infrastructure with the pact being changed. Where overlap exists, the migration plan has to coordinate the change across all affected pacts, not just the one being explicitly migrated.

The second common interaction is with downstream consumers of the agent's score. The composite score is read by marketplaces, deal platforms, other agents considering counterparty engagement, and external integrations through the Trust Oracle. A pact migration that changes the dimensional weighting of verdicts (e.g., a Penalty calibration change that affects how violations contribute to the score) can produce visible score shifts in the days after migration. Consumers who interpret these shifts as performance changes (rather than as scoring methodology changes) may make decisions based on misread signals. The right discipline is to communicate scoring-affecting migrations to downstream consumers ahead of time.

The third interaction is with the agent's tier eligibility. Tier demotion thresholds are calibrated against historical violation patterns; a migration that changes how violations are counted or weighted can cause apparent tier shifts that are artifacts of the migration rather than real changes in the agent's standing. Tier-affecting migrations should include a tier-recalibration plan that re-anchors the agent's standing under the new pact without producing whipsaw demotions.

The fourth interaction is with insurance and underwriting. Some pacts have insurance policies attached — counterparties or third-party insurers who underwrite the agent's bond posture or cover specific violation classes. Migration that changes Penalty calibrations affects the underwriter's risk model. Major-version migrations should include underwriter notification and possibly underwriter approval if the policy terms specify it.

The fifth interaction is with regulatory disclosure. Pacts in regulated domains (financial services, healthcare, education) may have regulatory disclosure obligations that attach to material changes. A migration that materially changes the agent's authorized scope, the protections it provides, or the consequences of violation may require notification to regulators who supervise the counterparty. The right discipline is to identify regulatory exposure before migration and incorporate disclosure requirements into the migration timeline.

These interactions are why pact migration is more than a contract update — it is an ecosystem operation. Operators who treat migration narrowly produce ripple effects that surface as surprises; operators who treat it broadly catch the ripples in advance and incorporate them into the migration plan.

What Armalo does

Armalo's pact infrastructure supports the four-stage migration pattern as a first-class workflow. Pact versions follow strict semver, and the validator refuses to deploy a misclassified bump (a behavior change marked as minor will fail validation). The runtime supports parallel schema emission for dual-run windows, and the post-hoc jury can produce parallel verdict streams. The pact registry tracks lifecycle states (proposed, in-force, deprecated, retired) explicitly and exposes them through the Trust Oracle so counterparties can see exactly which version is current. Templates for common migration patterns ship with the SDK so operators are not inventing the migration plan from scratch on each change. Migration events are themselves auditable artifacts that survive in the pact's history forever.

FAQ

What if a counterparty objects to a major-version change during announce? The operator has options: adjust the new pact to address the objection, extend the announce window for further negotiation, carve out an exception that keeps the old pact in force for that specific counterparty, or proceed with the change knowing the counterparty may terminate. The objection is a signal, not a veto, but ignoring it has costs.

Can a pact be unilaterally retired without notice? No. The pact is a signed contract; unilaterally retiring it is a breach. The retire stage is the operator's exit from the contract under its renewal terms. If the operator wants to terminate before retire, the renewal clause's termination triggers govern.

How long does dual-run actually take in production? For a major change with 30 counterparties, four to six weeks is the common range. Faster is risky because counterparties cannot test integrations cleanly; slower bleeds operational cost without producing additional safety.

What if I discover a bug in the new pact during dual-run? Patch the new pact (a patch-version bump within the new major version) and notify counterparties. The dual-run window may need to extend to give counterparties time to test against the patched pact. Better to catch and fix during dual-run than to migrate and discover the bug after the old pact is deprecated.

Do retired pacts still affect the agent's score? Verdicts produced under the retired pact for interactions that occurred during its in-force period still feed the score, with the standard time decay (1 point per week). The pact itself is not generating new verdicts after retirement.

What about counterparties who were signed under the old pact but never engaged with the migration? They remain bound to the old pact for any interaction that occurred during its in-force period. New interactions are governed by whatever pact is current at the time of the interaction, which is the new one after migration. If the counterparty wants to continue without engaging the new pact, they need to terminate the relationship; if they continue interacting, they implicitly accept the new pact through behavior.

Is there a difference between deprecated and retired pact states? Yes. Deprecated means the pact is no longer authoritative for new interactions but is still queryable as the current state's predecessor; counterparties' integrations should be migrating during this window. Retired means the pact's lifecycle is complete and the pact is now historical only; integrations reading it as current are buggy.

Can I apply the four-stage pattern to a single-counterparty deal pact? Yes, and you should. The pattern's structural integrity is independent of counterparty count; even a single counterparty benefits from announce, dual-run, migrate, retire. The timeline can be compressed (the whole sequence in a week is reasonable for a single counterparty) but the structure should hold.

Migration governance: who decides what bumps to which version

Pact migration is not just a technical workflow; it is a governance question. Who has the authority to propose a major-version bump? Who can approve dual-run extension? Who decides when retirement happens? Mature pact infrastructure has explicit answers; immature infrastructure leaves the questions in informal practice and produces governance failures alongside the technical ones.

The operator side has three roles that interact with migration governance. The pact author (typically an engineer or product manager) drafts proposed changes and runs them through the structural validator. The operations lead (typically a platform engineer or technical operator) reviews proposed changes for runtime feasibility — does the new pact's Evidence schema match what the telemetry can emit, does the runtime have the capacity to support dual-run, are the Penalty calibrations operationally executable. The legal or compliance owner (a legal lead, depending on the pact's stakes) reviews proposed changes for contract integrity, regulatory exposure, and consistency with adjacent agreements.

The counterparty side has parallel roles. The technical contact reviews the proposed changes against their own integration architecture. The relationship owner (account manager, partner manager, or equivalent) negotiates substantive disagreements. The legal owner reviews for the same kinds of contract integrity concerns the operator's legal owner reviews.

At minimum, a migration governance process specifies which roles must sign off on each stage. The announce stage requires the pact author and operations lead on the operator side; the technical contact and possibly the relationship owner on the counterparty side. The dual-run stage requires the operations lead's verification that the dual-run wiring is functioning. The migrate stage requires both legal owners' sign-off on the new pact's integrity. The retire stage requires the operations lead's confirmation that no active integrations are still reading the deprecated pact.

Where governance gaps exist, they produce predictable failures. Migrations without legal owner involvement on the operator side produce the case where the new pact technically functions but creates contractual exposure that nobody at the operator anticipated. Migrations without technical contact involvement on the counterparty side produce the case where the counterparty's automation breaks at migrate-stage cutover. Migrations without relationship owner involvement produce the case where the migration proceeds technically but damages the operator-counterparty relationship because the substantive disagreement was never escalated.

The governance discipline also includes change classification authority. Who decides whether a proposed change is major, minor, or patch? In well-governed pact infrastructure, the structural validator makes the first call (a Predicate change is automatically classified as major; an additive Predicate is automatically minor; a wording change is automatically patch). Disagreement with the validator's classification (the author thinks the change is smaller than the validator does) requires explicit override with documentation of the rationale. This prevents the failure mode where authors quietly classify major changes as minor to avoid the migration overhead.

Where semver classification is genuinely ambiguous (changes that arguably could be classified either way), the discipline is to err toward the larger classification. The cost of a too-large classification is extra process; the cost of a too-small classification is broken counterparties. Asymmetric error costs justify asymmetric defaults.

Mature pact infrastructure documents its migration governance and applies it consistently. Operators who improvise governance produce inconsistent results — some migrations are smooth and some are catastrophic, with the difference depending on which individuals happened to be involved rather than on the structural soundness of the migration plan. The discipline of explicit governance produces predictable migration outcomes and accumulates the institutional learning that makes each subsequent migration easier than the last.

Bottom line

A pact in production cannot be edited; it can only be migrated. The four-stage pattern — announce, dual-run, migrate, retire — is the cheapest way to migrate without breaking counterparties. Semver is the discipline that makes the change classification clear. The checklist is the muscle memory that catches the failure modes by name. Operators who treat pact changes as configuration edits will accumulate the disputes that pattern-following operators do not. The pattern is heavy on first use and routine after. The teams that internalize it stop having pact-migration incidents and start treating pact change as a manageable engineering practice.