Fifteen years ago, adding storage capacity was still a project: order arrays, carve volumes, extend filesystems, watch partitions fill up overnight. Object storage ended that era. A key, a bucket, an API: capacity became a service, retention a setting, access an application concern rather than a network path. Infrastructure teams got years back, and nobody is asking to return to the old regime.

StratoFoundry comes from that world. Our initial work was on S3 services, and two of our current products still belong to that universe: S3Guardian, which replicates data between S3 SaaS, on-premises S3 and CIFS/NFS sources, now at version 2.0, and S3Proxy, which decouples applications from endpoint changes. Precisely because this world is ours, we can say plainly where its contract ends.

What object storage actually solved

The problem object storage took on was real and massive: scale. Grow without re-architecting, retain according to configured rules, expose content to applications through APIs instead of shared directory trees. On that ground, it delivered, and the industry reorganized itself around the model.

A bucket is still a namespace, and a key is an address at a point in time. Storage keeps what you ask it to keep, for as long as the configured retention says. It does not know who wrote a given version, under which policy, with what rights, in what state of the business file held in the ERP or the PLM, or what the SIEM (security event management) was reporting at that moment. That information exists, but it lives elsewhere, scattered across each application’s logs and records. This is no failing on the storage side: that kind of continuity was never part of the contract.

What an object key cannot tell you

Take an ordinary supplier file: contract, assessments, technical documents, approval threads. Over the months it moves through a SharePoint, an ERP, a PLM, an S3 vault. Every system keeps its own representation, metadata and logs. When an incident or an audit asks a question of time and context (what did we know, when, under which rule, with what authority), no single system holds the answer. The answer sits between them.

Three things are missing then. A persistent identity: the file as a logical object, addressable across its successive states, rather than a string of versions with no common thread. An operational context: actors, rights, policies in force, provenance, still linked to the content. And a governed history: timestamped states, captured under explicit rules, queryable as of a chosen date, with evidence attached. Scale alone produces none of this. It has to be captured while events happen.

A knowledge layer above storage

That is the role of the Knowledge Layer carried by KARL Core: linking objects, their successive states, their context and their evidence, without replacing the source systems. The authoritative source remains the source of truth. KARL receives events and context (files and permissions, ERP/PLM business states, AI runs and their sources, SIEM signals, recovery point and receipt from backup or S3) and returns evidence, trusted states and recovery instructions.

The target architecture is deliberately lean: governed content and metadata stay in the S3 chosen by the customer; local compute (a local model, vectorization, integration) only comes in when the use case requires it; managed or customer-controlled modes (identities, keys, trusted time, supervision, updates) are defined per environment. Inside the governed perimeter, every write creates a timestamped state; retention follows the defined policy and the S3 capacity.

Two honest limits stand in for promises.

Governed memory starts when the perimeter is activated: KARL does not reconstruct a history that was never captured.

An honest temporal search distinguishes the time declared by a source system from the time of capture; the two do not always coincide.

A useful piece of data tells you what it contains. A governed one also lets you find what it was, where it came from, which rules applied and what was done with it. When that knowledge becomes queryable over time and reusable across applications, users and agents, it takes on the value of a Memory Layer: an operational memory built over time, on a single governed history.

Governed history, backup, replication: three distinct jobs

Confusion is expensive, so let us be precise.

  • Replication keeps synchronized copies across endpoints. It serves availability and locality; a corrupted write propagates just as faithfully as any other.
  • Backup provides independent retention, restore points and recovery testing. Protecting workloads belongs to dedicated solutions; KARL does not operate a backup platform.
  • Governed history preserves identity, states, context and evidence over time. It lets you find a version, verify its integrity and provenance, then select a trusted state; the restore itself is executed by an authorized workflow, often the backup solution's own.

These functions complete one another; none stands in for another. They also share a requirement: separate identities and keys, avoid a single failure domain (one bucket, one account, one credential domain), and keep the history portable. Sovereignty and resilience depend on a deployment profile, explicit assumptions and tested procedures.

Resilience is an architecture and tested procedures, not a marketing adjective.

Object storage solved scale, and solved it well. The next question is continuity: what history do we want to be able to query two years from now, under which rules, for whose benefit? That is as much an architecture question as a product one, and it is best asked early, before the perimeter worth governing has quietly grown on its own.

KARL Core is currently being validated in bounded, controlled pilots, with explicit measurement criteria: quality of evidence, recovery accuracy, operator effort. If these questions run through your own architectures, let’s talk about an architecture or a deployment profile: that is where a serious perimeter starts.