Rent the Compute. Never Rent Your Ability to Survive.

For years, enterprise technology strategy was often reduced to two words:

Cloud first.

The logic was compelling.

Stop buying so much hardware.

Stop maintaining data centers.

Stop refreshing storage arrays every few years.

Trade capital investment for consumption.

Scale when necessary.

Let specialists run the infrastructure.

Let somebody else worry about power, cooling, replacement parts, capacity, replication, and physical facilities.

There was plenty of truth in that argument.

Public cloud transformed computing. SaaS eliminated enormous amounts of undifferentiated operational work. Managed infrastructure gave organizations capabilities they could never have economically built themselves.

Cloud was not the mistake.

The mistake came later.

Somewhere between cloud as an option and cloud as the destination, many organizations stopped asking a more important question:

What happens to us if the provider becomes unavailable to us?

Then Nine PBS in St. Louis found itself confronting exactly that kind of problem.

More than 50 terabytes of archival material, representing roughly seven decades of institutional history, became inaccessible after problems with the external storage relationship responsible for the archive.

The information had not necessarily been destroyed.

That is what makes the case so important.

The data was still there.

Control was not.

The archive reportedly sat on infrastructure associated with another organization in the custody chain. Nine PBS owned its information, but technical custody, contractual relationships, and practical access had become separated.

Eventually courts became part of the path toward retrieving the material.

Consider how strange that is from an architecture perspective.

Nobody deliberately designs:

Archive → Vendor → Intermediary → Custodian → Litigation → Recovery

Yet an architecture can effectively become exactly that when ownership and independently exercisable recovery are allowed to diverge.

The Nine PBS story should not be reduced to a cheap lesson about choosing better vendors.

It reveals something deeper.

A critical asset is not truly resilient when its recovery requires the continued cooperation of the dependency whose failure you are trying to survive.

Update: Ownership Won. Recovery Still Had to Be Engineered.

At an August 12, 2026 hearing, Denver District Court Judge Eric Elliff said Nine PBS was the rightful owner of its archival data and entitled to retrieve it. That is good news. It also sharpens the lesson.

The court did not make operational dependency disappear. It established a recovery framework. Current's hearing-based report says Iron Mountain must cooperate with a qualified third party selected to perform the recovery, Nine PBS must pay applicable storage charges, and the process must safeguard other customers' data. Unknown formats and possible encryption may require further court involvement. Secondary reporting corroborates that framework.

Nine PBS did not lose legal ownership. It lost the independent ability to exercise that ownership on its own schedule through a recovery mechanism it controlled.

The data survived. Ownership survived. The normal dependency chain did not. Independent recovery did not.

The ruling created an authorized path to retrieve the archive. It did not establish that recovery had been completed.

A successful rescue is not the same thing as designed resilience.

This Is Not an Anti-Cloud Argument

It would be easy to make the argument:

Cloud failed. Bring everything home.

That would be intellectually lazy.

Public cloud is useful.

Private infrastructure is useful.

SaaS is useful.

Managed services are useful.

Colocation is useful.

Owned hardware is useful.

Sometimes tape is useful, despite decades of people enthusiastically predicting its funeral.

The right architecture depends on the requirement.

The mistake is allowing any deployment model to become ideology.

There is nothing inherently resilient about public cloud.

There is nothing inherently resilient about infrastructure sitting inside your own building either.

Organizations lost data long before AWS existed.

They deleted things.

They misconfigured storage.

Buildings flooded.

Power failed.

Administrators made mistakes.

Ransomware arrived.

Disks died.

Ownership of hardware does not create resilience.

Neither does renting it.

Independent recovery paths create resilience.

That distinction matters.

We Confused Replication With Independence

Modern cloud platforms can replicate data across racks, facilities, availability zones, and regions at a scale most enterprises could never reproduce economically.

That is an extraordinary engineering achievement.

But replication solves a specific class of failures.

It does not automatically solve every dependency failure.

Imagine an architecture containing:

• - a primary database;
• - a read replica;
• - snapshots;
• - a geographically replicated backup;
• - an archive copy.

Five copies.

Excellent.

Now ask what controls them.

Suppose all five require:

• - the same provider;
• - the same tenant;
• - the same identity system;
• - the same administrative hierarchy;
• - the same key-management service;
• - the same commercial relationship.

From a storage perspective, you may have five copies.

From an authority perspective, you may still have one recovery path.

That produces one of the central principles of sovereign recovery:

Replica count is not recovery-path count.

Or, more memorably:

Five copies can still equal one way to lose everything.

The Architecture Diagram Is Incomplete

Architecture diagrams usually show infrastructure.

Applications.

Databases.

Services.

Networks.

Regions.

APIs.

Storage.

Backups.

Clusters.

Those diagrams are useful.

But beneath every infrastructure architecture is another architecture that receives far less attention.

Call it the Authority Architecture.

It answers different questions.

Who controls the identities?

Who controls the administrative accounts?

Who controls the encryption keys?

Who controls the tenant?

Who controls physical custody?

Who controls export?

Who controls billing?

Who can terminate access?

Who must cooperate during recovery?

Who possesses the authority to prevent recovery?

Those relationships are architectural dependencies too.

They simply do not fit as neatly into the boxes we normally draw.

A system can look highly distributed in an infrastructure diagram and astonishingly centralized in an authority diagram.

That is why resilient architecture needs both views.

Infrastructure architecture asks:

Where does everything run?

Authority architecture asks:

Who controls whether it can be recovered?

The second question becomes extremely important when things stop going according to plan.

Five Properties We Keep Treating as One

Enterprise technology discussions frequently use the word resilience as though it describes one property.

It does not.

At minimum, five properties need to be separated.

Durability

Did the bits survive?

Durability protects against physical or logical loss of stored information.

A storage platform can be extremely durable while still being inaccessible to its owner.

Availability

Can the service answer requests?

Availability describes whether something is usable during normal operations.

A highly available system can still fail catastrophically at the account, provider, identity, or contractual boundary.

Recoverability

Can useful operations be reconstructed after failure?

Recovery requires more than preserved bytes.

It may require:

• - credentials;
• - keys;
• - people;
• - procedures;
• - infrastructure;
• - documentation;
• - software;
• - time.

Portability

Can the asset be moved somewhere else?

A platform may make restoration easy while making departure extraordinarily difficult.

Those are different capabilities.

Sovereignty

Can the organization continue possessing, understanding, and recovering the asset without requiring the current host to cooperate?

That is the highest bar.

And organizations routinely purchase durability and availability while behaving as though they also purchased recoverability, portability, and sovereignty.

They did not.

Sovereignty Is Not Just Geography

The technology industry increasingly talks about:

• - sovereign cloud;
• - data sovereignty;
• - sovereign infrastructure;
• - sovereign AI.

Often the discussion collapses into geography.

Where is the server?

That matters.

But location is only one dimension of sovereignty.

A server can sit ten feet from you and still depend upon:

• - an external identity system;
• - a remote licensing service;
• - a cloud-hosted key manager;
• - a vendor-controlled API;
• - a proprietary management plane.

Conversely, information may reside hundreds of miles away while remaining independently exportable, decryptable, readable, and recoverable under organizational authority.

So a more useful definition is:

Digital sovereignty is the demonstrated ability to continue possessing, understanding, and recovering an asset when its current hosting environment becomes unavailable.

The word demonstrated matters.

Not promised.

Not documented.

Not contractually guaranteed.

Proven.

Trust Is Not a Control

Organizations often describe strategic vendors using the language of trust.

We trust Microsoft.

We trust Amazon.

We trust Google.

We trust our SaaS partner.

Fine.

Trust them.

Good providers matter.

Strong partnerships matter.

Competence matters.

But trust belongs to a different category than resilience.

Trust is relational.

Resilience is structural.

We do not install redundant power supplies because we think the manufacturer is dishonest.

We install them because components can fail.

We do not create backups because we assume our administrators are malicious.

We create them because people can make mistakes.

Providers deserve exactly the same architectural treatment.

A good architecture allows a trusted provider to fail without turning that provider's failure into organizational failure.

That is not distrust.

That is engineering.

The provider is allowed to fail. Your architecture is not allowed to require the provider to be immortal.

Contracts Are Not Recovery Mechanisms

Contracts matter.

Data ownership clauses matter.

SLAs matter.

Retention requirements matter.

Termination provisions matter.

Liability matters.

But contracts operate in a different layer than technical recovery.

A contract can help determine who was right after something goes wrong.

It cannot necessarily restore operations Tuesday morning.

A lawsuit may eventually resolve ownership.

It cannot reconstruct irreplaceable historical information if the underlying asset disappears during the dispute.

Legal protections should support resilient architecture.

They cannot replace it.

This leads to another important distinction:

Legal ownership and operational sovereignty are not the same thing.

You can own an asset while lacking the practical ability to exercise control over it.

Nine PBS is valuable precisely because it makes that distinction visible.

The Hyperscaler Argument Misses the Point

The obvious objection is:

Microsoft is not disappearing tomorrow.

Probably not.

Neither is Amazon.

Neither is Google.

That misses the architecture question.

The question is not:

Will Microsoft disappear?

The question is:

What happens if Microsoft becomes unavailable to us?

Those are different risk models.

A provider does not need to go bankrupt for a customer to lose effective control.

An account can be suspended.

An identity system can fail.

Credentials can be compromised.

Billing can fail.

A region can become unavailable.

A reseller can disappear.

A product can be discontinued.

An acquisition can alter terms.

A legal dispute can emerge.

A government can impose restrictions.

An API can change.

An administrative mistake can affect multiple systems at once.

The provider can remain an enormous, healthy company while your dependency becomes your failure.

That is why this is not really a vendor-quality argument.

It is a dependency-concentration argument.

Cloud-First Quietly Became Destination-First

The original cloud-first principle was reasonable:

Before buying more infrastructure, determine whether cloud offers a better solution.

But in many organizations, the question gradually changed.

Instead of asking:

What architecture gives this workload the right combination of economics, resilience, security, performance, regulatory control, portability, and recoverability?

we began asking:

How quickly can we move it into cloud?

Those are not the same question.

One is architecture.

The other is destination selection.

Once destination is predetermined, architecture begins working backward to justify it.

That is dangerous regardless of whether the preferred answer happens to be:

• - cloud;
• - on-premises;
• - Kubernetes;
• - SaaS;
• - private cloud;
• - whatever product acquired the most impressive keynote presentation this quarter.

Architecture should begin with required properties.

Not fashion.

Requirement First

The more mature principle is simple:

Requirement first.

Use public cloud where public cloud creates advantage.

Use SaaS where SaaS creates advantage.

Use owned infrastructure where ownership creates strategic value.

Use private compute where control, predictable economics, or sovereignty justify it.

Use multiple providers where meaningful independence justifies the complexity.

Use offline copies where irrecoverability warrants them.

Use open formats where long-term readability matters.

Use proprietary systems where their benefits exceed their exit cost.

The objective is not ideological purity.

It is preserving the properties the organization actually needs.

Owned Infrastructure Is Becoming Interesting Again

For years, owning infrastructure was sometimes treated as evidence that an organization had failed to modernize.

That was always too simplistic.

Owned infrastructure has obvious costs:

• - capital;
• - staffing;
• - maintenance;
• - lifecycle management;
• - power;
• - cooling;
• - capacity planning.

But it also offers properties that external consumption cannot always reproduce economically or institutionally:

• - deterministic custody;
• - predictable economics at sustained utilization;
• - offline capability;
• - independent recovery;
• - local high-performance compute;
• - physical control;
• - reduced reliance on remote control planes.

AI has made several of those properties more relevant.

High-utilization accelerators change economics.

Data gravity matters.

Sovereignty matters.

Geopolitical risk matters.

Cyber resilience matters.

Provider concentration matters.

None of this means everything should come back on-premises.

That would merely replace one simplistic doctrine with another.

The lesson is more disciplined:

Own what creates strategic independence.

Rent what creates strategic advantage.

Own Enough to Say No

An organization does not need to own everything.

It needs to own enough.

Enough recovery capability.

Enough copies.

Enough context.

Enough keys.

Enough knowledge.

Enough execution capacity.

Enough portability.

Enough administrative authority.

Enough optionality.

Enough independence that no provider becomes existential.

Own enough to say no.

That ability has value even if it is never exercised.

An organization that can leave a provider negotiates differently from one that cannot.

It can reject unacceptable pricing.

Change technology.

Respond to acquisitions.

Adapt to regulation.

Absorb geopolitical changes.

Move when economics change.

Survive provider failure.

Optionality has economic value.

A capability does not become waste simply because the emergency never happened.

Insurance does not become useless because the building remained standing.

Exit Must Be Engineered

Organizations spend enormous effort designing how they enter platforms.

Landing zones.

Migration factories.

Identity integrations.

Data migrations.

Transformation programs.

Reference architectures.

Then somebody asks:

How do we leave?

A slide appears.

It says:

Exit Strategy

Everyone feels reassured.

That is not an exit strategy.

Exit is an engineering capability.

A critical platform should answer:

• - How do we export everything?
• - What does everything mean?
• - What metadata is excluded?
• - What relationships are lost?
• - What formats are provided?
• - How long does complete extraction take?
• - What bandwidth is required?
• - Who owns the encryption keys?
• - What APIs are necessary?
• - Can those APIs disappear?
• - What alternate destination exists?
• - Can another system understand the exported information?
• - How are identities mapped?
• - How do we validate completeness?
• - When was this process last tested?

That is Exit Engineering.

If departure has never been exercised, portability remains a claim.

Every Platform Accumulates an Exit Tax

When a platform is first adopted, leaving may be easy.

Little data.

Few integrations.

Minimal customization.

Limited organizational dependence.

Then the platform succeeds.

Data accumulates.

Automation grows.

Users learn platform-specific workflows.

Identity becomes embedded.

APIs become dependencies.

Historical information builds up.

Semantics become encoded inside proprietary structures.

Ten years later, the organization is still technically free to leave.

Practically, departure may require organizational surgery.

That accumulated difficulty is the Exit Tax.

Not all lock-in is bad.

Sometimes the benefits dramatically outweigh the cost.

But lock-in should be understood as a liability, not treated as an invisible side effect.

Architecture should therefore ask:

What would it cost us to leave today?

Not just:

What did this platform cost us this month?

The Sovereign Recovery Test

Take any platform your organization considers critical.

Then ask one deliberately unpleasant question:

If this provider became completely unavailable to us at midnight tonight, what could we still do tomorrow morning?

No portal.

No support.

No API.

No account representative.

No friendly escalation contact.

What remains?

Can we retrieve the information?

Can we decrypt it?

Can authorized people authenticate?

Can we understand the data?

Can we reconstruct relationships?

Can another platform use it?

Can we restore critical operations?

Can the business operate in degraded mode?

Do we possess the necessary procedures?

Do we possess the keys?

Do we possess the authority?

Do we know how long recovery would take?

Has anyone ever actually done it?

If the answers repeatedly begin with:

"The vendor should..."

"According to the contract..."

"Support can probably..."

"We assume..."

then you have discovered dependency.

Not necessarily unacceptable dependency.

But dependency that should be visible, measured, governed, and deliberately accepted.

Six Dimensions of Sovereign Recovery

For important assets, recovery should be evaluated across six dimensions.

1. Data Independence

Can we obtain, verify, and restore the information independently?

2. Administrative Independence

Can recovery proceed if the ordinary administrative control plane is unavailable or compromised?

3. Identity Independence

Can authorized people recover without the primary identity system?

4. Cryptographic Independence

Can the organization obtain and use the encryption keys required for recovery?

5. Provider Independence

Can the primary provider disappear without eliminating every useful recovery path?

6. Semantic Independence

Can the information still be understood if the original application disappears?

The sixth dimension is where traditional disaster recovery often stops too early.

Recovering the Database Is Not Necessarily Recovering the System

Imagine recovering every database table perfectly.

Every row is intact.

Every checksum matches.

But:

• - identifiers are undocumented;
• - relationships were encoded only in application logic;
• - proprietary metadata disappeared;
• - nobody understands several fields;
• - business rules lived only in source code;
• - provenance was never preserved;
• - decision history was trapped in another platform.

Did you recover the system?

Perhaps not.

You recovered the bits.

That is different.

This introduces a critical principle:

A backup preserves data.

A resilient context architecture preserves meaning.

For information to survive applications, it should retain enough structure to reconstruct:

• - identity;
• - provenance;
• - relationships;
• - authority;
• - version history;
• - temporal context;
• - terminology;
• - evidence lineage;
• - decision context.

That is Semantic Independence.

And it leads directly to a larger SharePlane principle.

The Application Is Disposable. The Context Is Not.

Technology organizations instinctively protect applications.

Applications are often among the most replaceable parts of the environment.

Applications can be rewritten.

Infrastructure can be reprovisioned.

Servers can be replaced.

Containers can be rebuilt.

Software vendors can be changed.

Cloud accounts can be recreated.

Models can be replaced.

What cannot easily be reconstructed is accumulated organizational context.

Why was this decision made?

Who approved it?

What evidence supported it?

What changed afterward?

What happened before?

What does this record mean?

Who owns it?

What is related to it?

Which source is authoritative?

What assumptions existed at the time?

That context accumulates over years.

Eventually the people who created it retire.

Systems are decommissioned.

Projects disappear.

Documents are moved.

Companies reorganize.

Memories fade.

Suddenly what looked like ordinary data becomes irreplaceable institutional memory.

The application is disposable.

The context is not.

Context Must Outlive Its Container

A document is a container.

A database is a container.

A SaaS platform is a container.

A dashboard is a container.

A repository is a container.

An AI conversation is a container.

An application is a container.

Containers change.

Context should survive them.

That requires preserving more than the current representation.

It requires durable identity.

Provenance.

Relationships.

Authority.

History.

Meaning.

Evidence.

The application should be a projection over context.

Not its prison.

Context must outlive its container.

This is not merely knowledge management.

It is resilience architecture.

AI Is Recreating the Same Risk at Extraordinary Speed

Organizations are now pouring institutional context into:

• - AI conversations;
• - agent memory;
• - proprietary copilots;
• - hosted orchestration;
• - vector databases;
• - model-specific indexes;
• - managed knowledge stores;
• - proprietary semantic layers.

The capability is extraordinary.

So is the opportunity to recreate yesterday's lock-in with much more valuable information.

Imagine five years of organizational knowledge accumulating inside one AI ecosystem.

Terminology.

Relationships.

Preferences.

Decision history.

Operating practices.

Exceptions.

Agent memories.

Semantic enrichment.

Then the platform changes.

Can the organization export it?

Can another model use it?

Can embeddings be rebuilt?

Can provenance survive?

Can relationships be reconstructed?

Can the agent behavior be reproduced elsewhere?

Do you own the underlying context or merely possess temporary access to an implementation of it?

AI sovereignty is therefore not simply about owning models or GPUs.

A company can host its own model and still have terrible sovereignty if its institutional context remains trapped in proprietary structures.

Conversely, an organization can use externally hosted models while preserving strong sovereignty if context, provenance, relationships, and recovery remain under independent control.

Models are disposable.

Institutional context is not.

The Survivability Boundary

Every enterprise should identify the capabilities that cannot be allowed to disappear with an external dependency.

Call that line the Survivability Boundary.

Inside it may reside:

• - emergency identity;
• - critical communications;
• - regulatory evidence;
• - intellectual property;
• - source code;
• - encryption authority;
• - recovery documentation;
• - essential records;
• - institutional context;
• - core operating knowledge.

The implementation will differ by organization.

The principle does not:

No uncontrolled external dependency should cross the survivability boundary without an independently executable recovery path.

That does not mean everything inside the boundary must be hosted internally.

It means organizational survival cannot depend entirely upon outside permission.

The Minimum Viable Enterprise

A related question is:

What is the smallest version of this organization that must still function after catastrophic technology dependency loss?

Call it the Minimum Viable Enterprise.

Not normal operations.

Survival operations.

What must work during the first hour?

The first day?

The first week?

What people need to communicate?

What identities must remain usable?

What records must remain accessible?

What regulatory obligations cannot stop?

What transactions must continue?

What context must remain understandable?

What systems can wait?

The MVE forces resilience planning to focus on business capabilities rather than treating every application as equally important.

Applications are implementations.

Capabilities are what the organization must preserve.

Recovery Assurance

Another distinction matters.

A backup is not proof of recovery.

A runbook is not proof of recovery.

A vendor certification is not proof of recovery.

A green dashboard is not proof of recovery.

Recovery capability becomes credible when it is exercised.

That produces another concept:

Recovery Assurance

Evidence-backed confidence that a defined asset can be recovered within acceptable constraints after a defined failure.

Recovery assurance might include evidence of:

• - successful export;
• - successful restore;
• - integrity verification;
• - independent authentication;
• - key recovery;
• - alternate-environment restoration;
• - measured recovery time;
• - semantic reconstruction.

There is a large difference between:

We have backups.

and:

We successfully recovered the system after deliberately removing the primary provider from the exercise.

The second statement contains evidence.

Design for the Day They Disappear

Perhaps the most productive question in this entire discussion is:

What would we build differently if we knew this provider would disappear five years from today?

You would probably:

• - preserve independent exports;
• - retain recovery credentials;
• - test restores;
• - document semantics;
• - retain keys;
• - avoid unnecessary proprietary coupling;
• - create alternate execution paths;
• - track the exit tax;
• - preserve critical context independently;
• - define degraded operating modes.

Now suppose the provider remains excellent for twenty years.

Was that engineering wasted?

No.

You simply built a system that preserves options.

That is what architecture is supposed to do.

Nine PBS Is the Warning, Not the Villain

Incidents create a strong temptation to point at the affected organization and ask how anyone could have allowed it to happen.

That misses the useful lesson.

Serious failures often begin with reasonable decisions.

A plausible vendor.

A normal contract.

A working service.

A successful migration.

Years of routine operation.

Then assumptions change.

The better question is not:

How could they be so foolish?

It is:

Where have we made the same assumption?

What critical information do we legally own but cannot independently recover?

Which backup requires the same identity system as production?

Which SaaS application contains information we cannot reconstruct?

Which AI platform is accumulating context we cannot export?

Which provider has quietly become essential?

Which supposed recovery path requires the same administrative plane as the failed system?

Which exit strategy has never actually been exercised?

Which dependency would leave us saying:

"We believe somebody else still has our stuff."

Those are the useful questions.

The Architecture of Survival

A mature organization should be able to lose a meaningful dependency without losing itself.

Not every application.

Not every convenience.

Not necessarily full business-as-usual operations.

But the organization.

Critical information should remain recoverable.

Critical context should remain intelligible.

Critical authority should remain exercisable.

Critical capabilities should have a degraded path.

The exact architecture will differ.

The principle is stable:

Do not optimize only for the world in which everything continues working.

Design for the world in which something important disappears.

Rent the Compute

There is nothing sacred about a server.

Rent it.

Nothing sacred about storage hardware.

Rent it.

Nothing sacred about software.

Subscribe to it.

Use SaaS.

Use Azure.

Use AWS.

Use Google.

Use managed databases.

Use hosted AI.

Use external models.

Use private compute.

Use owned hardware.

Use whatever produces the right combination of capability, economics, performance, and risk.

But understand what you are handing over.

Know which assets can leave.

Know which dependencies can fail.

Know what authority remains yours.

Know where your keys are.

Know what can be recovered independently.

Know what can be understood without the original application.

Know your exit tax.

Know your survivability boundary.

And own enough capability that no provider becomes existential.

Rent the compute.

Rent the platform.

Rent the convenience.

Never rent your ability to survive.

Because when the provider disappears, the account locks, the contract breaks, the identity plane fails, the economics change, the API vanishes, the product is retired, or the platform simply no longer fits the world you operate in, there is one recovery plan nobody should ever have to present to leadership:

We believe somebody else still has our stuff.

That is not resilience.

That is not sovereignty.

That is not disaster recovery.

That is hope with an SLA.