In 1997, an engineering thesis at EPITA proposed distributed objects carrying their own usage and transformation rules, classified into three boxes: white, grey, black. Twenty-nine years later, that intuition became PanglotOS, a micro-kernel and an ecosystem of more than one hundred and fifty polyglot services — and its next chapter is called KARL core.
1997, a thesis and an intuition
In 1997, at EPITA, I finished my engineering degree with a thesis on a subject that was captivating distributed systems researchers at the time: distributed objects. CORBA was everywhere, in lectures and in research papers. The idea of the era was seductive: an object living on one machine could be called from another machine, possibly written in another language, thanks to an interface contract describing what the object knew how to do.
The thesis went further than the usual exercise. It proposed a distributed object environment in which every object carried, declaratively, its own usage and modification properties. The object was no longer just a bundle of code behind an interface. It was an autonomous entity that carried the rules of the game with it: who can use me, how, and above all, to what extent I may be transformed.
Today, the industry is returning to the idea of autonomous objects that carry their own properties and can operate without constant dependence on the infrastructure that created them. The idea is not new: it appeared in an engineering thesis in 1997, accompanied by an initial implementation that demonstrated it worked. It continued to evolve into PanglotOS.
Three boxes to express trust
The thesis was built around a simple classification: three boxes.
The white box. The object ships with its source code. Whoever receives it can open it, read it, modify it, recompile it. Total trust, complete transmission.
The grey box. The object ships without its code, but remains modifiable: you can specialize it, override some of its behaviors, derive a finer object from it, without ever touching the original. Modification happens through inheritance, not rewriting.
The black box. The object is untouchable. You use it as is, period. Its contract says what it does, and no one can distort it.
This gradation was no theoretical gadget. It answered a very concrete question companies were already asking: how do you distribute software components to partners without losing control over what they do with them? Modifiability as a property, carried by the object itself rather than by a paper contract or a server's configuration, was the answer. The object itself knew which box it lived in.
What CORBA understood, and what was missing
One of CORBA’s key ideas was the interface contract: written in a neutral language, it lets independent systems cooperate. A client doesn't need to know what language an object is written in to call it. It needs to know the contract.
But a CORBA object still depended on a bus, a server and heavy infrastructure to function. Its properties — what it was allowed to do, how it could be extended — lived outside of it, in documentation, in developers' heads, in system configuration. Remove the infrastructure, and the object was nothing.
The thesis's intuition was to bring all of that back into the object: its contract, its properties, its transformation rules, its identity. An object that carries itself. An object whose nature and permissions can be checked without asking the system hosting it.
Twenty years of maturation
Between the thesis and PanglotOS there were long years of industrial practice, and patient observation of passing fashions: EJBs, web services, SOAP, then REST, then microservices, then containers. Each wave picked up a piece of the idea, never the whole idea. Microservices rehabilitated autonomy. Containers rehabilitated portability. APIs rehabilitated the contract. But nowhere could you find an object carrying its contract, its usage properties and its modification rules at once, declaratively and verifiably.
PanglotOS grew from that observation: instead of waiting for the industry to bring these pieces together, it was time to build the system envisioned in the 1997 thesis with today’s tools.
PanglotOS: the OS layer, a necessity, not an end
PanglotOS is first an operating system because autonomous software objects need an environment that supports them: a micro-kernel, clear process isolation, security where nothing is permitted by default, and a small footprint so each object uses only the resources it consumes.
The OS layer provides that foundation; the main subject is what runs on top of it. A PanglotOS container is a binary, a manifest describing it, and an explicit security policy: it starts in a few dozen milliseconds, weighs under two megabytes at rest, and can do nothing that was not declared. This foundation guarantees that the objects placed on top of it remain what they claim to be. Without it, the properties carried by the object would be mere promises. With it, they become verifiable facts.
The real subject begins above: the modules.
Polyglot modules that ignore each other
The PanglotOS marketplace today counts more than one hundred and fifty microservices written in Go, Rust, Python, TypeScript, Ada and C. Some are tiny, others are entire business, finance or artificial intelligence building blocks. All of them share a property straight out of 1997: you call them without knowing, and without needing to know, what language they are written in.
Every module carries its contract: its entry points, its inputs and outputs, its version, its declared capabilities. A service written in Ada can be consumed by a client written in Python, itself called from a Go service, without any of the three knowing the other two exist. What CORBA tried to achieve with an object bus and stub generators, PanglotOS achieves with a contract everyone can read and a runtime that enforces the rules. The implementation language becomes a private detail again, as it always should have been.
As in the thesis, the contract is not enough: the object must also carry its transformation rules. The three boxes return here.
The three boxes in container inheritance
The first concrete incarnation of the 1997 boxes inside PanglotOS is service inheritance, the mechanism called SOX. A root service can allow other services to derive from it, and it declares under which conditions: in white box mode, the derivative receives everything and may modify everything; in grey box mode, it overrides specific, precise behaviors — a validation rule, a scoring computation — without ever touching the parent; in black box mode, it consumes the service as is, unable to change anything.
Concretely, a customer relationship service can exist in a generic version, then be derived for an industry, then derived again for a region of the world, each level modifying only what the previous level's box authorizes. When a derivative cannot answer, it delegates to its parent, which delegates to its own, exactly like an object walking up its inheritance chain. The services' family tree is readable, governed, and every link knows which box it lives in.
What was, in the thesis, a property of distributed objects has become a property of services in production. The white, grey, black gradation has not changed one iota in twenty-nine years. It simply found its scale.
Cortex: the 1997 object turned autonomous service
Then came Cortex, and with it the second, deeper incarnation. Cortex is PanglotOS's universal runtime: every service in the system, from the smallest utility to the largest business engine, lives inside a Cortex instance. And Cortex takes over the thesis object's properties, adding new ones that did not exist in 1997 because nobody needed them yet.
The 1997 object carried its contract and its modification rules. A service under Cortex also carries:
Its self-described identity. Every service can introduce itself: who it is, its version, what it can do, how it was built. You don't query a central registry to know whom you are talking to; you ask the service itself.
Its energy autonomy. A service can fall asleep at several levels when unused, stay dormant but ready, or run at full capacity. It manages its own life instead of being kept artificially awake by the infrastructure.
Its mobility. A service can be delegated from one instance to another, migrate from one machine to a more powerful one, or one closer to its users, without its clients noticing. The object is no longer moored to its server; it carries enough of itself to live elsewhere.
Its citizenship. A service registers, obtains an address, a name, a port, declares itself to the cluster registry. The system needs no frozen central configuration to know what is running: objects introduce themselves.
Its discipline. Explicit capabilities, quotas, supervision: the service cannot do more than what was granted, and it reports on its own health to whoever asks.
In other words, where the 1997 object was autonomous in theory, the Cortex service is autonomous in practice: it describes itself, governs itself, moves, sleeps, wakes up and accounts for itself, without any of these properties depending on a central platform holding them on its behalf.
KARL core: the next chapter
PanglotOS is not the destination; it is one stage in the project. The next chapter is called KARL core. The idea stays the same, pushed one notch further: if an object can carry its contract, its properties and its rules of life, it can also carry its history. KARL core extends the lineage opened in 1997 toward objects whose existence, state and past remain verifiable even when the infrastructure that saw them born is no longer there to testify. The object, once again, carries itself.
This is not a rupture. It is the same sentence, written over twenty-nine years, finally finding all of its punctuation.
Epilogue
Watching the industry rediscover today, under ever-new vocabularies, that software should carry its proofs, its properties and its rights with it rather than delegate them to the platforms hosting it, it is tempting to smile. These ideas have an age. They have a genealogy. In my case, it begins in an EPITA lecture hall in 1997, with three colored boxes and one intuition: an object that knows who it is, what it allows and how it can be transformed needs no one to exist.
The thesis became an operating system. The system became an ecosystem of polyglot services. The ecosystem is becoming a core. The boxes, meanwhile, have not moved.