Maintaining Sovereignty: Updates, Forks, and Exit Strategies

You adopted a tool. It passed sec-scan. It cleared the decision framework. You wrapped it properly. It has been running in production for four months.

Is it still the right choice?

Most engineers never ask this question after the initial adoption. The tool is working. Nobody is complaining. It fades into the background of the stack — invisible until it breaks.

That invisibility is the risk. Dependencies do not announce when they stop earning their place. Maintainers lose interest quietly. CVEs accumulate silently. Better alternatives emerge without notification. The tool you adopted in January may be the wrong tool in June — and you will not know unless you ask.

The 90-Day Review Cycle

Every adopted dependency gets a calendar entry. Every 90 days, it faces five questions:

1. Is it still maintained? Check the repository. When was the last commit? Last release? Are issues being responded to, or is the issue tracker a graveyard? A project with no commits in 90 days is not necessarily dead — but it is on life support. Flag it.

2. Is it still secure? Re-run sec-scan. A tool that was clean at adoption may have accumulated issues. New CVEs get disclosed against transitive dependencies. Maintainers sometimes commit secrets accidentally. The security posture at adoption is not the security posture today.

3. Is it still earning its place? Has a better alternative emerged? Has your capability grown to the point where you could now build this in a week? Has the blast radius changed — are you more coupled to it than you intended?

4. Has the blast radius grown? Dependencies have a way of spreading. You adopted a library for one use case. Now three services depend on it. The blast radius at adoption was low. The blast radius today may be medium or high. Measure it again.

5. Can you still rip it out in a day? This is the exit test. If the answer is no, your wrapper has leaked — calling code is touching the provider directly, or the integration has grown beyond the original boundary. Fix the boundary before the exit cost grows further.

Monitoring Adoption Health

Between reviews, two signals indicate that a dependency is degrading:

Increasing error rates. Your wrapper logs every call and every error (Lesson 147). If the error rate for a provider trends upward over weeks, the dependency is degrading. This might be rate limiting changes, API deprecations, or infrastructure instability on the provider's end. The trend matters more than any single failure.

Increasing maintenance cost. You are spending time on this dependency. Migration work for a major version bump. Debugging integration issues caused by upstream changes. Patching around behavior changes that were not documented. If the maintenance cost of a dependency exceeds the cost of building the replacement, the adoption math has flipped.

Fork Strategy: When and How

Sometimes the right answer is not "keep" or "remove." It is "fork."

Fork when:

• The upstream project is abandoned but the code is solid
• The maintainer's roadmap diverges from your needs
• You need modifications that would never be accepted upstream
• A security issue exists that the maintainer will not fix in your timeframe

Fork discipline:

Minimize the diff. The smaller the delta between your fork and upstream, the easier it is to pull future patches. Do not rewrite the project. Apply the minimum changes needed for your use case.

Document the reason. Every fork must have a FORK.md or equivalent that explains: why the fork exists, what was changed, and under what conditions the fork could be abandoned in favor of upstream.

Re-evaluate at every 90-day review. Has upstream fixed the issue? Has the maintainer returned? Has a better alternative emerged? Forks are not permanent. They are bridges until a better path exists.

Exit Strategies: The One-Day Test

Every adopted dependency must pass the one-day test: can you remove it from your stack and replace it with either a built alternative or a different adoption within one working day?

If yes, the wrapper is clean, the boundary is maintained, and the dependency is truly reversible.

If no, diagnose why:

• Calling code touches the provider directly. Fix the wrapper boundary. Move all direct references behind the wrapper.
• Multiple services depend on it. Consolidate to a single wrapper instance that all services share. The exit path is one file, not twelve.
• No fallback identified. Identify at least one alternative provider and stub it in the wrapper's fallback chain.
• Data format dependency. Your system stores data in the provider's format. Add a normalization layer in the wrapper that converts to your internal format. The exit cost drops when your stored data is in your format, not theirs.

# The one-day test in practice
# Before: scattered direct imports
from leonardo_sdk import generate_image  # in service_a.py
from leonardo_sdk import generate_image  # in service_b.py
from leonardo_sdk import generate_image  # in pipeline.py

# After: single wrapper, all calling code uses your interface
from wrappers.image_gen import ImageGenerator  # in service_a.py
from wrappers.image_gen import ImageGenerator  # in service_b.py
from wrappers.image_gen import ImageGenerator  # in pipeline.py
# Exit cost: rewrite wrappers/image_gen.py. One file. One day.

Things We Never Adopt Externally

Some domains are sovereignty lines. No tool, no matter how good, crosses them:

Trading logic. Foresight, a sports prediction agent, and a perpetuals trading bot are all built from scratch. The blast radius of external trading logic — someone else's algorithm making decisions with your capital — is existential. The Rewired Minds principle applies: the decisions that define your outcomes must come from your own reasoning.

Agent architecture. Our OpenClaw is our agent platform. It manages conversations, spawns coding agents, runs cron jobs, and coordinates a fleet. Adopting an external agent framework would surrender control over the most fundamental layer of our operations.

Memory systems. Our semantic memory layer — 414 tests, 92% coverage, 2,968 chunks indexed across 43 repos. Memory is how our agents compound. An external memory system would mean our agents' learned knowledge lives in someone else's code, subject to someone else's data model and retention policies.

Monitoring. The watchdog service watches everything. Sentinel runs 50+ monitors. If the monitoring system itself is an external dependency, who monitors the monitor? The watchdog must be yours.

The Sovereignty Mindset

Sovereignty is not paranoia. It is engineering discipline applied to the question of control.

Every external dependency is a tradeoff: you gain capability and save development time in exchange for control over that capability. For commodities with low blast radius, that tradeoff is excellent. For differentiators with high blast radius, it is unacceptable.

The sovereignty mindset does not reject external code. It evaluates, scans, wraps, monitors, and reviews it — continuously. The dependency that earns its place today gets re-evaluated in 90 days. The one that stops earning it gets removed. The one that was never appropriate never enters.

Lesson 149 Drill

List every adopted dependency in your stack. For each one:

1. When was it last reviewed? If never, schedule the review this week.
2. Re-run sec-scan against the current version.
3. Apply the one-day test: can you rip it out and replace it within one working day?
4. For any that fail the one-day test, identify the boundary leak and plan the fix.
5. For any that have not been reviewed in 90+ days, run the full five-question review now.

Then identify your sovereignty lines — the domains where no external code is allowed. Write them down. Make them explicit. Share them with your team.

The list should be short. Three to five domains. But they should be absolute.

Bottom Line

Adoption is a continuous relationship, not a one-time event. The 90-day review keeps adopted dependencies honest. The one-day exit test keeps your boundaries clean. The fork strategy gives you a middle path when upstream goes sideways. And the sovereignty lines — the domains you never outsource — protect the capabilities that define your system.

The stack with 49+ custom applications and a handful of carefully adopted commodities did not happen by accident. It happened because every dependency was evaluated, wrapped, monitored, and re-evaluated on a cycle. The ones that earned their place stayed. The ones that did not were removed. That is how sovereignty survives contact with the real world.