North American Institute of Digital Archaeology
Department of Pre-Collapse Computational Cultures
Field Season: 2140

Summary

Excavation of Site AWS-4 has uncovered one of the most complete late-21st-century enterprise software environments yet recovered.

The site appears to have been occupied continuously from approximately 2027 through the mid-2060s. Unlike smaller computational settlements of the same period, AWS-4 was not abandoned following a single platform transition. Instead, successive modernization efforts were built over earlier systems without fully replacing them, leaving a dense and unusually well-preserved technical record.

Preliminary work has identified multiple generations of container orchestration, event-streaming infrastructure, infrastructure-as-code systems, observability platforms, API gateways, service meshes, and several large structures referred to in surviving documents simply as “the platform.”

The precise function of the platform remains under investigation.

Site Description

AWS-4 occupies approximately 2.8 petabytes of recovered storage distributed across several former commercial cloud regions. The original name of the organization is unknown.

Fragments recovered from documentation refer variously to “Enterprise Digital Platform,” “Core Platform,” “NextGen Platform,” and “Unified Platform.” These were initially believed to be separate systems. Current evidence suggests they may instead represent successive names for substantially overlapping infrastructure.

The central settlement appears to have been organized around a large Kubernetes complex surrounded by application services connected through APIs, queues, topics, gateways, policy engines, secrets stores, telemetry systems, and a considerable amount of configuration.

The Kubernetes layer alone contains more than three million lines of YAML.

Very little of it is annotated.

Initial Excavation

The earliest intact repository discovered so far is named:

platform-foundation-final-v2

Commit metadata indicates that it was neither final nor the second version.

The repository contains Terraform templates describing several hundred resources. Many reference modules in other repositories, which in turn reference additional modules. After reconstructing the dependency chain, researchers determined that the complete system ultimately provisioned infrastructure that could have been described much more directly.

The reason for this indirection is unclear.

One possibility is that abstraction itself carried professional significance during this period. This interpretation is supported by repeated references to “reusability,” including in modules for which no second user has yet been found.

That conclusion remains controversial.

The Kubernetes Precinct

The largest surviving structure is the Kubernetes Precinct, accounting for roughly 41 percent of all recovered configuration.

Kubernetes appears originally to have been used for scheduling software workloads across groups of machines. By later periods its responsibilities had expanded to include networking, security policy, secrets distribution, scaling, application health, deployment strategy, telemetry, certificate management, and numerous other operational concerns.

Particular attention appears to have been given to two mechanisms called liveness probes and readiness probes.

These were automated tests performed repeatedly against running applications. A liveness probe determined whether the application remained functional. A readiness probe determined whether it was prepared to receive traffic.

Applications failing these tests could be removed and replaced automatically.

This seems to have worked reasonably well.

The larger question is why researchers have recovered several thousand distinct probe configurations for applications that, in many cases, appear to have been nearly identical.

The answer may lie in the site's organizational structure rather than its technical one.

The Service Mesh Layer

Above the Kubernetes deposits lies a later stratum associated with a technology called a service mesh.

The inhabitants appear to have encountered increasing difficulty managing communication among large numbers of distributed services. Their response was to introduce an additional software layer alongside those services to manage routing, encryption, identity, retries, telemetry, and policy enforcement.

Surviving documents consistently describe this change as a simplification.

This claim is not entirely unsupported. Application code from the period does contain less networking logic than earlier examples.

At the same time, the archaeological record begins showing a new class of operational material devoted to understanding the additional networking layer: sidecar configuration, certificate failures, routing rules, proxy logs, policy definitions, upgrade procedures, and troubleshooting guides.

The change therefore appears to have reduced one category of complexity by concentrating it somewhere else.

This pattern will become significant later in the excavation.

Event Structures

The site's event-streaming infrastructure is extensive. More than 11,000 Kafka topics have been identified so far, though many contain little or no recoverable traffic.

Naming conventions vary sharply between periods.

Early examples are straightforward:

customer-created

Later examples include names such as:

enterprise.customer.lifecycle.customer-created.v3

In the upper strata, several names contain both the terms legacy and nextgen.

Researchers have not yet established whether “nextgen” describes a technical generation, a planning designation, or a recurring cultural aspiration.

One topic is of particular interest.

It appears to have remained active for more than twenty years. A message was published to it every five minutes, with remarkable regularity, despite the fact that we have not yet located a consumer.

At first this was assumed to be missing data.

That explanation is becoming harder to sustain.

Documentation

AWS-4 contains an enormous documentary archive, including architecture diagrams, design proposals, decision records, runbooks, migration plans, service catalogs, and internal technical standards.

Unfortunately, the archive does not correspond cleanly to the system we have excavated.

Some diagrams contain services for which no deployed artifacts exist. Hundreds of deployed components appear nowhere in formal architecture documentation. Several documents marked “current state” appear to describe systems already obsolete when the documents were created.

This has led researchers to reconsider the purpose of architectural diagrams during the period.

They may not have been intended primarily as records of running systems.

A competing interpretation is that they described approved relationships: which systems were expected to communicate, which platforms were considered strategic, and which organizational boundaries were recognized at the time the diagram was produced.

If so, architecture diagrams may have served partly as technical documentation and partly as administrative maps.

Further analysis is required.

Anomalous Repository L-17

Near the end of the current excavation phase, the team recovered a repository from one of the site's deepest layers.

It differs markedly from the surrounding material.

The service is small. It is written in Java, stores data in PostgreSQL, exposes six endpoints, and has very few dependencies. The README is fourteen lines long.

No associated service-mesh configuration has yet been found. There is no custom deployment operator, event-stream integration, policy framework, or architecture decision record explaining why the service exists.

Traffic records suggest it entered production in 2029.

They also suggest it remained there.

For how long, we are not yet prepared to say.

Last week, the laboratory team succeeded in restoring a compatible database snapshot and reconstructing enough of the original runtime environment to start the service.

A request was sent to one of the recovered endpoints.

The service responded.

HTTP 200.

Excavation Report 2140-18 will examine Artifact L-17, its operational history, and the increasingly uncomfortable question of how much of Site AWS-4 was actually necessary.