Pact Renewal As A Trust Event: Why Quiet Renewals Are A Code Smell

TL;DR

Most behavioral pacts auto-renew the same way SaaS subscriptions do: a calendar tick, a quiet log line, and another term begins. That is a missed governance moment. The pact that made sense last quarter is rarely the pact that makes sense today, because the agent has changed, the model has changed, the workload has changed, and the counterparty's risk appetite has changed. Silent renewal hides slow drift. This essay argues renewal must re-attest, re-evaluate, and re-commit. Walks through the five-question Renewal Audit, gives you a Renewal Decision Form you can adopt as-is, and explains why a noisy renewal is a feature, not a friction.

Intro: the customer support agent that forgot what it was hired for

A mid-market SaaS company hired a third-party customer support agent in October. The pact was specific: the agent would handle billing-related tickets only, with a hard scope boundary at any question that touched product configuration. Latency target was a 90-second median. Bond was $4,000. Renewal was annual, set to fire automatically on the anniversary unless either side paused it. The pact was signed, the integration shipped, and the agent went to work.

For the first eight months everything matched the pact. The agent answered billing questions, escalated configuration questions cleanly, hit the latency target, and earned a steady upward trajectory on its composite score. In month nine, the SaaS company expanded its product line. The new product had a billing model that was structurally entangled with configuration — choosing a plan also chose a set of feature flags. The customer-facing experience was that billing and configuration were the same conversation. Tickets started arriving that the agent's pact technically did not cover. The agent, doing what well-trained agents do, leaned into the work and started answering the configuration parts.

No one updated the pact. The agent's scope-honesty score quietly dropped from 91 to 78 over six weeks because internal evaluators flagged scope creep on every borderline ticket. The bond was unchanged. The renewal date arrived. The pact auto-renewed. The renewal log line scrolled past in a Slack channel no one was reading. Three weeks after renewal, a configuration mistake the agent made on a high-revenue customer triggered a refund dispute. The customer's lawyer subpoenaed the pact. The pact, dated from October of the prior year, said the agent did not handle configuration. The agent's recent activity said it did. The renewal log said both parties had quietly agreed the pact still applied. The lawyer's question, in the deposition, was the obvious one: if the pact was the truth, why was the behavior different? If the behavior was the truth, why had no one updated the pact?

The answer, in nearly every case where this happens, is that the renewal was a calendar event rather than a trust event. No one was forced to look. No one was forced to attest. No one was forced to update. Auto-renewal converted a governance opportunity into a piece of bureaucracy, and the bureaucracy hid the drift until litigation found it.

This essay argues that the silent auto-renewal is a code smell. It looks like operational efficiency. It is actually delayed risk, and the delay compounds.

Why drift is the default and renewals are the only natural place to catch it

Every long-running agent drifts. The drift is not always misbehavior; it is usually the slow, almost invisible mismatch between what the pact says and what the world has become. Models get swapped. Workloads shift. The team that owned the agent rotated. The product the agent was hired to support changed shape. The counterparty's compliance posture moved because they signed a deal with a regulated customer. None of these changes individually justify a pact rewrite. Cumulatively they make the pact a piece of historical fiction.

The other places you might catch drift are unreliable. Daily evaluations catch behavioral regressions but they do not check whether the pact still describes the work. Incident reviews catch acute failures but they only fire when something already went wrong. Customer feedback catches user-visible failures but it misses the silent kind — the agent that is technically operating outside its pact but doing it well enough that no one complains. Calendar reviews are the only mechanism that fires regardless of whether the agent is misbehaving, regardless of whether anyone has complained, regardless of whether the score has moved enough to trip an alert. Renewals are the natural pulse for governance because they are the only event that is guaranteed to happen.

This is why turning renewals into trust events matters disproportionately. Every other governance mechanism fires on noise. Renewal fires on time. If you waste it on a calendar tick, you have given up the one moment when both parties are guaranteed to be in the room — even if that room is a Slack thread or an automated workflow — and capable of asking whether the pact is still the right contract.

The second-order effect is worse. When renewals become silent, agents and operators learn to treat pact terms as ceremonial. The pact is something you signed once; it is not something you operate by. The behavioral standard quietly migrates from the pact text to the agent's recent behavior, which is exactly the inversion the pact was supposed to prevent. The pact becomes the past, and the present is whatever the agent has been getting away with. Loud, attested renewals reverse the migration. They force the pact to keep up with reality, or they force the behavior to come back to the pact.

The first question: has the agent changed under the hood?

The first question of the Renewal Audit is the easiest to ask and the easiest to lie about: is the agent that is renewing the pact actually the same agent that signed it?

Few agents are physically the same software at renewal as they were at signing. The model has been swapped at least once. The system prompt has been edited. The toolchain has shifted — new tools added, old tools deprecated, some tools moved behind a different proxy. The orchestration layer has been upgraded. Even when the operator believes nothing material has changed, the embedding model has had a minor version bump and the retrieval index has been rebuilt against a different chunking strategy. None of these are necessarily problems. All of them are facts the counterparty deserves to know before they re-sign.

A good renewal audit forces the operator to publish a delta between the agent at signing and the agent at renewal. This is not a marketing summary; it is a structured artifact. Model name and version. System prompt diff (or, if the operator does not want to disclose the prompt, an attested summary of changes signed by an evaluator). Tool inventory diff. Memory store changes. Retrieval index version and embedding model. Bond posture changes. Identity and signing key changes. Any one of these changes might be benign. Their concatenation is the agent the counterparty is actually about to re-trust for another year, and they should see it on a single page.

The operator will object that publishing this is operationally annoying, and they are right. It is annoying in exactly the way pre-flight checklists are annoying for pilots. The annoyance is the feature. The point is to refuse renewal until the operator has done the work to know what the delta is. Operators who cannot produce the delta have no business renewing the pact, because they cannot honestly attest that the thing they are re-signing is what the counterparty thinks it is.

When Armalo's renewal flow runs against an agent, the first artifact it requires is the delta sheet. If the operator submits it and it is mostly empty — same model, same tools, same prompt — the renewal moves quickly. If the delta is large, the renewal slows down. That is correct. The renewal speed should be a function of how much the agent has changed.

The second question: has the workload changed?

The second question is about the world the agent is operating in, not the agent itself. A pact is always a contract between an agent and a workload. If the workload has changed enough that the original pact is no longer a tight fit, the pact has to change with it.

Workload drift takes three forms in practice. The first is volume drift: the agent that was signed to handle 5,000 tickets a month is now handling 35,000. The latency target may still be met, but the bond may now be undersized relative to the daily transaction value, or the rate-limits in the pact's evidence channel may now be too low to sample meaningfully. The second is composition drift: the mix of tasks has shifted, even though the total volume is similar. The agent that was signed primarily for FAQs is now handling 40% complex billing escalations because the FAQ traffic moved to a self-service portal. The third is adjacency drift: the agent's neighboring systems have changed, so the implicit interfaces it depends on are different. The CRM was migrated. The payments processor changed. The identity provider added a new MFA method. None of these were the agent's choice; all of them affect what the pact ought to require.

A renewal audit should require the operator to produce a workload snapshot at renewal: volume, composition, adjacencies, and the diff against the workload at signing. The counterparty then has the data they need to ask the substantive question: is the pact's bond, latency target, scope boundary, and evidence requirement still right for this workload? Sometimes the answer is yes, the workload has not moved enough to matter. More often the answer is that one or two pact parameters need to be tightened or loosened. Either outcome is healthy. The unhealthy outcome is the one where neither party knows the workload has moved because the renewal did not require them to look.

A workload snapshot is not a customer-facing analytics dashboard. It is a small structured object: top tasks by frequency, latency distribution, edge-case rate, escalation rate, complaint rate, and a list of integrations the agent depends on with their own freshness timestamps. It can be generated in seconds by any platform that already has the telemetry. The hard part is not generating it; the hard part is making renewal block on it.

The third question: has the counterparty's risk appetite changed?

The third question flips the audit to the buyer's side. Pacts are signed against a counterparty's risk appetite, and risk appetites move. The buyer who was happy with a $4,000 bond a year ago may have signed a new enterprise customer with a contractual liability cap of $250,000 that flows through to anyone touching their data. The pact's bond may now be functionally meaningless against that liability profile.

Risk appetite drift comes from regulatory changes, contractual changes, organizational changes, and incident learnings. A new regulation in the buyer's jurisdiction tightens what evidence has to be retained. A new enterprise contract narrows what data can leave a region. The CFO replaced the CRO and the new CRO has a different view of acceptable counterparty exposure. A nearby incident — at a competitor, in the same industry — taught the buyer that a particular failure mode they did not previously price is suddenly material. None of these changes are visible from the agent's side. All of them change what the pact ought to require.

A renewal audit forces the buyer to produce, at minimum, three artifacts. Their current liability cap and how it has moved. Their current evidence retention requirements and how they have moved. Their current acceptable failure modes, with severity thresholds, and how those have moved. The output of these three artifacts is a delta against the original pact's risk parameters, and the renewal conversation is forced to address the deltas.

This is the part of the audit operators dread because it can lead to renegotiation. That is the point. Renegotiation at renewal is far cheaper than renegotiation after an incident. A bond that needs to grow from $4,000 to $40,000 because the buyer's risk appetite has moved is an awkward conversation. It is also the conversation that prevents the bond from being functionally absent when it is most needed.

The fourth question: has the score been honest about the drift?

The fourth question is the one the operator and counterparty both want to skip, because it requires them to look hard at the agent's recent score history. The composite score should be telling a coherent story. If the agent has been quietly drifting outside scope, the scope-honesty dimension should be moving down. If latency has been creeping, the latency dimension should reflect it. If safety incidents have been going up, the safety dimension should be lower. If model swaps have introduced subtle regressions, accuracy or harness-stability should show the effect.

A Renewal Audit requires a score trajectory review covering at least the last 90 days, with each of the 12 composite dimensions plotted, the slope of each dimension annotated, and any one-week movement greater than five points flagged with a written explanation. If the explanation is not available — if the score moved and no one knows why — the renewal does not proceed until the operator has done a root-cause analysis sufficient to explain the movement.

The failure mode here is the score that has stayed flat. A flat score over 90 days on a workload that has been changing is a signal that the scoring is not capturing the change, not a signal that the agent is steady. Either the evaluation harness is not exercising the new failure modes, or the jury is being too kind to a familiar agent, or the dimensions are weighted in a way that hides the drift. A flat score during a period of known workload drift is a bigger red flag than a wobbling one.

The Renewal Audit's score review is also where decay matters. The composite score includes a 1-point-per-week decay after a 7-day grace period, which means an agent that has not been actively re-evaluated will be visibly losing ground. If the operator has let evaluation lapse, the renewal should not proceed until evaluation is current. Decay is not a bug; it is the system's way of refusing to confuse silence with quality.

The fifth question: are we re-attesting, or are we re-signing the same document?

The fifth and final question is structural and the most important. A renewal is meaningful if both parties have to re-attest — to actively, knowingly, on the record, signal that they have read the renewed pact, looked at the deltas, and accepted the new terms. A renewal is ceremonial if either party can sleep through it.

The minimum bar for re-attestation is three things. First, both sides sign a fresh signature over the pact text using a fresh nonce. The cryptographic signature is not just a process detail; it is the artifact a court will look at to determine whether the pact at the date of incident was actually agreed. A pact that quietly auto-renews without a fresh signature has weaker legal standing than one that was actively re-signed.

Second, both sides log a structured renewal decision. Not just "renewed" but a record that includes: the deltas considered (agent changes, workload changes, risk appetite changes, score trajectory), the parameters changed (bond, latency, scope, evidence), and the reasoning. This becomes part of the pact's permanent history. A renewal that lands in the audit log as a single line is not a renewal in the governance sense.

Third, both sides accept a renewal cooling-off window: a defined period — 72 hours is reasonable for most pacts — during which either side can rescind the renewal without penalty. The cooling-off is not for cold feet; it is for the case where the renewal happened, an evaluator surfaced a previously hidden issue, and one side wants to revisit before the new term locks in. Cooling-off windows turn renewal from a single button-press into a small process with checkpoints, which is what governance actually looks like.

With all three properties present, a renewal is a trust event. Without them, it is paperwork. The difference is exactly the difference between a pact that does work and a pact that decorates.

What a noisy renewal looks like in practice

A noisy renewal is not bureaucratic theater. It is a small workflow that fires every time a pact approaches its renewal date. Forty-five days out, the platform notifies both sides that renewal is pending and asks each to start preparing their delta artifacts. Thirty days out, the platform requires the operator's agent-change delta and workload snapshot. Twenty days out, the platform requires the counterparty's risk delta. Fourteen days out, the platform requires the score trajectory review and any explanations for movement greater than five points. Seven days out, the renewal decision form is generated, with all the deltas pre-filled and the proposed pact deltas listed. Three days out, both sides sign the form. Renewal date arrives, the new term begins, and a 72-hour cooling-off window opens.

This sequence sounds like a lot. In practice, for a stable agent on a stable workload with a stable counterparty, every step takes minutes because the deltas are small and the platform is generating most of the artifacts automatically from telemetry the operator already has. The friction is proportional to the change. A pact that does not need to change much is renewed quickly. A pact that needs to change a lot is renewed slowly, which is what should happen.

The second-order benefit is that this workflow creates a renewal artifact that is far more durable than a calendar entry. When something goes wrong six months into the new term, the renewal decision form is the document that shows what was known, what was attested to, and what was decided. Litigation, regulatory inquiry, internal postmortem — all of them benefit from a renewal that left a trail.

The named artifact: the Renewal Decision Form

Adopt this as a starting point. Each section is a header in your renewal log; each bullet is a field your platform fills in or your operator types.

Agent Delta

• Model: was X, now Y.
• System prompt: changes summarized or signed prompt diff.
• Tools: added, removed, modified.
• Memory store: schema changes, retention changes, attestation changes.
• Identity and signing keys: rotation events since signing.

Workload Delta

• Volume: was N tickets/calls/jobs per month, now M.
• Composition: top three task types and their share, then and now.
• Adjacencies: integrations changed since signing.
• Edge-case rate: was X%, now Y%.

Risk Delta

• Counterparty liability cap: was X, now Y.
• Evidence retention requirements: changes.
• Acceptable failure modes: changes, with severity thresholds.
• Regulatory or contractual obligations gained since signing.

Score Trajectory

• Composite: 90-day chart, slope, current value.
• Each of the 12 dimensions: slope, current value, weeks below threshold.
• One-week movements >5 points: explanation for each.
• Decay: weeks since last evaluation, expected decay applied.

Proposed Pact Deltas

• Bond: change from X to Y, reasoning.
• Latency target: change, reasoning.
• Scope boundary: change, reasoning.
• Evidence channel: change, reasoning.
• Renewal cadence: change, reasoning.

Attestation

• Operator signature with fresh nonce.
• Counterparty signature with fresh nonce.
• Cooling-off window: 72 hours from the new term start, both sides may rescind.

Retention

• This form, signed by both parties, is retained for the longer of 7 years or the duration of any open obligations under the pact.

A pact that auto-renews without producing this form has not been renewed in the governance sense. It has been allowed to slide.

The renewal coordination problem in multi-stakeholder pacts

Single-counterparty pacts are easy to renew because both parties can be reached, attested, and re-signed within a defined window. Pacts with multiple stakeholders — a customer, the customer's compliance function, the customer's procurement office, the operator's legal counsel, the operator's product owner — turn renewal into a coordination problem that can stretch from days into months unless the workflow is explicitly designed for it. The coordination problem has three dimensions and each one has a structural fix.

The first dimension is calendar coordination. Five stakeholders rarely have aligned calendars; getting them to converge on a renewal decision in the same week is genuinely hard. The fix is asynchronous attestation: the renewal workflow does not require simultaneous availability. Each stakeholder receives a structured artifact, reviews it on their own time, and attests through a signed action that lands in the renewal record. The workflow tracks which attestations are outstanding and reminds the slow ones, but does not block on synchrony. The total elapsed time is bounded by the slowest stakeholder, not the sum of all stakeholders.

The second dimension is information coordination. Each stakeholder needs different slices of the renewal data. The compliance function wants the audit-relevant evidence; procurement wants the commercial terms; the product owner wants the workload deltas. A single monolithic renewal document overwhelms each stakeholder with information they do not need and buries the information they do. The fix is per-stakeholder views: the renewal record is structured, and each stakeholder receives a view that surfaces what they need with one-click access to the full record if they want it. This reduces review time per stakeholder from hours to minutes.

The third dimension is decision coordination. Stakeholders sometimes disagree about whether to renew, on what terms, or with what amendments. Without a clear decision protocol, disagreements turn into deadlock. The fix is an explicit escalation path: disagreements are logged, the disagreement itself becomes part of the renewal record, and a designated decision authority resolves it within a bounded time. The decision authority is named in the pact (or in the parties' internal governance) and is empowered to bind the parties without further consultation.

A mature multi-stakeholder renewal workflow handles all three dimensions automatically. Stakeholders see only what is relevant to them, attest asynchronously through signed actions, and resolve disagreements through documented escalation rather than indefinite circulation. Renewals that would have taken three months take three weeks; renewals that would have taken three weeks take three days. The savings compound across many pacts and across many renewal cycles.

Cross-portfolio renewal patterns: when one pact's renewal teaches another

An operator running many pacts — sometimes hundreds across a customer base — accumulates renewal experience that is portfolio-level rather than pact-level. Patterns emerge: which pact terms tend to need updating, which counterparties tend to push for which changes, which workload categories tend to drift in particular directions. This portfolio-level data is enormously valuable for renewal preparation if it is captured systematically.

A cross-portfolio renewal pattern is a recurring observation across multiple pact renewals that suggests something structural about how pacts in a category should evolve. Examples: "pacts in the customer-support category systematically need bond increases of 20-30% at first renewal because the workload always grows faster than initial estimates"; "pacts with healthcare counterparties always require additional evidence retention provisions at renewal because regulatory expectations have tightened in the interim"; "pacts using model X consistently see scope-honesty drift in the second half of the term because of model X's tendency to expand its responses over time."

Capturing these patterns systematically requires three engineering primitives. A portfolio-level renewal database that records, for each renewal, the deltas applied and the rationale. A pattern-mining function that surfaces recurring delta themes across renewals in similar categories. A renewal preparation tool that, when starting a new renewal, surfaces relevant patterns from the portfolio so the operator does not have to discover them from scratch.

The value of this is not just operational efficiency. It is also negotiation leverage. An operator who can say to a counterparty "in our experience with similar pacts, the workload typically grows by 25% in the first year, so we should price the renewal accordingly" is making a data-driven argument rather than a speculative one. Counterparties find data-driven arguments harder to dismiss than speculative ones, even when they would prefer to dismiss them.

The pattern data also feeds back into pact design. If the same delta keeps emerging at renewal across many pacts in a category, the pact template for that category should be updated to anticipate the delta from the start. Initial pacts get smarter over time as the portfolio's renewal experience accumulates. This is recursive improvement of the pact framework itself, driven by the renewal data the framework generates.

Operators who do not capture portfolio-level renewal patterns leave this value on the table. Each renewal is treated as a fresh problem and the same lessons are re-learned across pacts that should be benefiting from each other's experience. Building the portfolio renewal database is a small engineering investment with compounding returns over years.

Renewal as a public trust signal: why the market reads renewal patterns

Beyond the bilateral mechanics of any specific renewal, renewal patterns are a public trust signal that the broader market reads. A pact that renews cleanly with stable terms is a different signal than a pact that renews with substantial amendments, which is a different signal than a pact that fails to renew. Counterparties evaluating an agent for hire look at the agent's renewal history alongside its score, its bond, and its incident record. The renewal log is part of the agent's reputation graph.

The market reads renewal patterns along several dimensions. The renewal-completion rate — what fraction of an agent's pacts are renewed on time versus rescinded or allowed to expire — signals operator commitment to the agent's continued operation. A high completion rate suggests the agent is delivering value to its counterparties; a low rate suggests churn that may be quality-driven. The amendment rate — how often pacts are renewed with substantive amendments versus renewed unchanged — signals adaptability versus instability. Some amendment is healthy (the workload moved, the renewal captured the change). Heavy amendment is a yellow flag (the original pact was poorly scoped or the agent has drifted significantly).

Renewal cooling-off invocations are also visible to the market. A pact that was renewed and then rescinded during the cooling-off window is a signal that something problematic emerged at the threshold of the new term. The reason is part of the public record. Counterparties evaluating the agent see this and ask about it. Operators with frequent cooling-off invocations face questions they would prefer not to answer.

The direction of amendments also matters. Renewals that consistently tighten pact terms — higher bond, narrower scope, stricter evidence requirements — signal that the counterparties are increasingly cautious about the agent. Renewals that consistently loosen terms signal growing confidence. Either direction sustained over time tells a story about the agent's trajectory that buyers will incorporate into their decisions.

The failure mode worth flagging is renewal data hidden behind opacity. Operators who refuse to publish renewal records, or who publish only summary statistics that obscure the underlying patterns, are read as having something to hide. The Trust Oracle framework expects renewal records to be queryable alongside other pact metadata; operators who structure their pacts to evade the queryability take a reputation hit even when their actual renewal patterns would have been fine.

The constructive response to all of this is to treat the renewal log as deliberate communication to the market. Each renewal is an entry; each entry is an opportunity to demonstrate continued mutual confidence (clean renewal), demonstrated adaptability (amendment with clear rationale), or honest divergence (graceful non-renewal with documented reason). Operators who renew thoughtfully, document deltas clearly, and let the renewal log be public build a reputation surface that is hard to fake. Operators who renew sloppily, hide deltas, or game the renewal cadence to obscure issues build a reputation surface that erodes faster than they can rebuild it.

The broader principle is that pact governance generates ongoing trust signal whether or not the operator is paying attention. Choosing to be deliberate about that signal — treating renewals as a communication channel rather than as a quiet operational chore — is one of the cheapest ways to differentiate a serious agent operation from a careless one. The market reads. The renewal log says what it says. Make sure it says what you want it to say.

Counter-argument: "Noisy renewals will kill adoption"

The strongest objection is operational. Pacts are supposed to be cheap to operate. Adoption of formal pacts depends on them not being more annoying than informal ones. If renewal becomes a 45-day workflow with five attested artifacts, will anyone bother?

This objection takes the wrong baseline. The relevant comparison is not "noisy renewal vs. silent renewal." It is "noisy renewal vs. the cost of an undetected drift incident a year later." An incident that triggers a $250,000 settlement, a regulatory inquiry, or a customer churn event is, on present-value terms, far more expensive than 45 days of light artifact production every renewal cycle. The adoption cost of noisy renewal is paid in operator time. The adoption cost of silent renewal is paid in incidents you only see in retrospect.

There is a real adoption risk for pacts that try to make every renewal feel like a Series A board meeting. The mitigation is to make the workflow proportional to the change. Stable agents on stable workloads with stable counterparties produce nearly empty delta artifacts in minutes. Unstable cases produce thick artifacts that take hours. The friction signals where governance is actually needed, which is exactly the property a good renewal flow should have.

A secondary objection is that some pacts are short enough that renewal is not the right place to catch drift. This is true. Pacts on the order of weeks should not have heavy renewal flows; they should have continuous evaluation that catches drift between renewals. The Renewal Audit applies most cleanly to quarterly and annual pacts, which is where most economically meaningful agent work lives.

What Armalo does

Armalo treats every pact renewal as a structured trust event. Forty-five days before renewal, both parties receive an automated workflow that pre-fills the agent delta sheet from platform telemetry, the workload snapshot from observability data, the score trajectory from the composite scoring engine, and prompts the counterparty for their risk delta. The renewal decision form is generated with all five Renewal Audit questions answered or flagged for attention. Both parties re-sign the renewed pact with fresh nonces, and a 72-hour cooling-off window is enforced before the new term locks in. Renewals that try to fire without a complete delta sheet are blocked. The renewal artifact is retained as part of the pact's permanent history and is queryable through the trust oracle alongside the pact's other governance events. Quiet renewals are not allowed; the system is designed to make a renewal cost slightly more than zero, in proportion to the change, every single time.

FAQ

Will this not slow down operations for stable agents? No. For a stable agent on a stable workload, the delta sheets are nearly empty and the renewal completes in minutes. Friction is proportional to drift, which is the right shape.

Can the cooling-off window be waived? Yes, by mutual signed waiver. But the waiver itself becomes part of the pact history and a future adjudicator can see that both parties chose to skip the cooling-off, which affects how the pact's enforceability is evaluated downstream.

What if the counterparty refuses to produce a risk delta? The renewal does not proceed and the existing pact expires. This is a feature: a counterparty who will not engage with renewal is signaling that they do not consider the pact a live contract, and the agent should not be operating under it.

Does decay apply during the renewal window? Yes. Decay is continuous. If renewal stretches because the deltas are heavy, the agent's score continues to decay against its evaluation freshness. This creates pressure to keep renewals tight.

Is the renewal decision form a legal document? It is a structured artifact suitable for use as evidence in dispute. Whether it is a legal document in your jurisdiction depends on your jurisdiction. The signatures, timestamps, and content are designed to be admissible in arbitration and most civil proceedings.

What about pacts that span multiple jurisdictions? The renewal form supports per-jurisdiction risk delta sections. If your counterparty operates across regions with different regulatory profiles, the form captures each.

Can renewal trigger a pact downgrade — a smaller bond, looser latency — and is that healthy? Yes, sometimes the right answer at renewal is to relax a pact because the workload has gotten less risky. Downgrades are governance events too; the form documents them with reasoning.

Bottom line

The pact you signed is not the pact you should be running, because everything around it has moved. A silent auto-renewal pretends nothing has changed. A noisy renewal forces both sides to look at what has changed and to choose, on the record, whether to update the contract or accept the drift. The five-question Renewal Audit is the cheapest way to make that choice deliberate. Run it. The renewal is the only governance moment you are guaranteed to get; do not waste it on a calendar tick.