• conforms_to::[[Aspiration Form Contract]]
• in_practice_domain::[[eOS Continuum]]
• authored_by::[[Christopher Allen]]
• has_lifecycle::[[Seed Stage]]↗
• has_curation::[[Working Draft]]↗

Builders Own the Runtime Platform They Depend On

Builders running serious agent workflows on the eOS runtime platform can run, audit, fork, and exit it under licenses and operational posture that preserve their commitment to it. The directional target is a world-state where committing to the platform is not a bet on a vendor's continued existence, a particular license remaining unchanged, or a tooling surface a single team's tacit knowledge holds together; it is a commitment a builder can make on their own terms, with documentation and tooling that make sovereignty practical rather than nominal.

Why It Is Worth Pursuing

Vendor lock-in and license contagion are real costs to teams committing to an agent-infrastructure platform. Sovereignty restores the ability to commit without betting on someone else's runway, license, or roadmap. Five commitments name the target this Aspiration works toward: permissively licensed where the team has freedom to choose; self-hostable as a primary deployment model; auditable; forkable; data exit as a first-class feature. Each commitment is what a sophisticated builder needs in order to commit to the platform for serious work. Without sovereignty, the platform is a tactical convenience that production-time teams accept on the vendor's terms; with sovereignty, the platform is infrastructure that a team owns and can defend.

Three load-bearing commitments are already in place at the project level. The License Posture Decision ([[Adopt BSD-2-Clause-Patent License]]) commits the project's application-layer code to BSD-2-Clause-Patent (gold-rated by the Blue Oak Council, OSI- and FSF-approved, GPLv2-compatible) over public-domain ancestors; the driver's AGPL-3 dependency is named explicitly in the project's license inventory rather than hidden. The Cloud-Server Decision ([[Adopt Cloud-Server with Hard Fork]]) chooses the foundation that preserves the upstream cherry-pick channel while seeding the kernel layer -- now the sibling eOSContinuum/eOS-kernellib repository per [[Adopt Sibling-Repository Locus for eOS-kernellib]] -- with provenance the project controls. The Composes-With Conviction ([[eOS-Harness Composes With Adjacent Tools, Not Against Them]]) commits the project to additive positioning -- adopters do not rewrite their stack, they add the platform where the gap is. Together these three commitments are the foundation of the sovereignty story: the license enables it, the foundation choice supports auditability, and the additive-composition framing makes commitment achievable without the lock-in costs that "rewrite your full stack" imposes.

The reason these commitments alone do not satisfy the Aspiration is that sovereignty is a practical claim, not just a license-and-architecture claim. A team that picks up the platform today can read the license (sovereignty in principle); they cannot yet reproduce a production-shape deployment from documented steps, audit the kernel layer in days rather than weeks, export the runtime state in a documented portable format, or fork-and-resume cleanly if the upstream project changes direction. The license enables sovereignty; the tooling and documentation that make sovereignty practical are gapped. The Aspiration is what carries the directional commitment to close that gap.

Current Gap

License committed and self-hostable in principle, but kernel-auditability documentation, snapshot/export tooling for portable data exit, reproducible-deployment runbooks, and patterns for forking-as-recovery are not yet shipped. A team committing to the platform today can clone the repository, build the runtime, and run it locally. They cannot yet reproduce a production-shape deployment, audit the kernel layer's capability-enforcement surface in days rather than weeks, export the runtime state in a documented portable format that survives upstream changes, or fork-and-resume cleanly if the project's direction diverges from theirs.

The auditability gap is specific. The kernel layer is a known artifact, but the audit surface a sovereign adopter cares about -- which files are load-bearing for capability enforcement, which are incidental, which are required for platform-vs-glue coherence -- is not yet documented in this project's own terms. A builder who wants to verify the kernel is what the project claims has to read source against the upstream foundation's documentation rather than against the project's own audit-surface documentation.

The data-exit gap is also specific. The runtime's snapshot mechanism is a load-bearing primitive of the platform; what is missing is documented portable-format export, versioning, and re-import tooling that an exiting team can use without reverse-engineering the dump file's binary layout. Snapshots documented, versioned, and self-describing, with tools to export the state graph in a portable format shipping alongside the runtime, is the directional target this gap measures against.

The deployment-reproducibility gap is the surface gap the platform still carries from the upstream side: the documentation that would let a sophisticated builder absorb the platform in days rather than months is being written. At sovereignty scope, the gap is reproducible-deployment specifically: a builder following documented steps can stand up a production-shape deployment without reading source code or asking the project's contributors. Today the steps for the platform's initial transport pattern are documented for the project's early bootstrap work; the steps for production-shape deployment (TLS at the platform level, reverse-proxy patterns, secrets handling) are deferred to a future deployment-shape workstream that does not yet exist.

The fork-and-resume gap is conceptually distinct. The license and foundation choice make forking legally and architecturally clean; what is missing is the operational pattern -- what a builder takes if they fork the platform, what they leave, what they pick up if they ever rejoin upstream. Without the pattern documented, the forkability claim is theoretical. The cherry-pick channel that the Cloud-Server Decision preserves applies upstream-to-this-project; the analogous channel for this-project-to-fork is not yet sketched.

Work

Taking this Aspiration seriously asks the project to ship the auditability, data-exit, deployment-reproducibility, and fork-and-resume tooling that turns the License Posture Decision's commitments into practical sovereignty. None of this work was in the platform's initial scope; each is a candidate for a post-bootstrap workstream.

The audit-surface documentation work is to author audit-surface documentation specific to the project's kernel layer. The work names which files enforce capability boundaries, which files are incidental, which files are required for the platform-vs-glue coherence the project commits to in [[Agent Runtimes Require Native Primitives, Not External Glue]], and how a sovereign adopter verifies the kernel matches the documentation. The output is documentation a builder can read in days rather than weeks.

The data-exit tooling work is to ship snapshot-export tooling that produces portable, versioned, self-describing state-graph dumps and re-import tooling that consumes them. The work names the export format explicitly -- a versioned schema documented by the project, not a binary dump file format that requires runtime-version-specific tooling to read. The output is a tool a sovereign adopter can run to leave the platform without losing what they built.

The deployment-reproducibility work is a future deployment-shape workstream: TLS at the platform level, reverse-proxy patterns, secrets handling, network-accessible deployment. The TLS-posture strand now has a named owner in a queued identity-architecture workstream that decides native-TLS-vs-reverse-proxy for the platform's first network-crossing consumer. The output is a runbook a sovereign adopter can follow to stand up a production-shape deployment without source-code reading or contributor consultation.

The fork-and-resume documentation work is to author the operational fork pattern -- what a sovereign builder takes if they fork the platform for divergent direction, what they pick up if they ever rejoin upstream. The output complements the existing upstream cherry-pick channel preserved in [[Adopt Cloud-Server with Hard Fork]]; the cherry-pick channel handles upstream-to-this-project, the fork-and-resume documentation handles this-project-to-fork-and-back. Together they let a builder fork-and-rejoin without the friction that ad-hoc rebase-and-merge imposes.

The Aspiration does NOT ask the project to shift to a managed-cloud-as-a-service deployment model, to bury the AGPL-3 driver dependency under a vendor abstraction, or to take on the breadth-vs-depth tradeoffs of a vendor agent platform. The five commitments named above are the foundation of the sovereignty story; trading any of them for short-term convenience erodes the Aspiration.

Progress Recognition

Progress toward this Aspiration is recognized by the following observable markers:

• Kernel layer documented as auditable. A builder reading the kernel layer against the project's own audit-surface documentation can verify the kernel's capability-enforcement claims in days rather than weeks. Internal to the project; the project controls whether this lands.
• Snapshot/export tooling shipped. A builder can export their runtime state in a documented portable format and re-import it elsewhere without reverse-engineering the dump file. Internal to the project.
• Self-host runbook published for production-shape deployment. A builder following documented steps can stand up a production-shape deployment on their own infrastructure (not just the platform's initial transport pattern) without reading source code. Internal to the project.
• Fork-and-resume operational pattern documented. A builder forking the platform for divergent direction has documented guidance on what they take, what they leave, and what they pick up if they ever rejoin upstream. Internal to the project.
• First non-author self-hosts the runtime end-to-end and runs a workflow against it. Depends on adopter participation; the strongest evidence that the directional target has moved.

The first four markers are necessary before the fifth is achievable. The Aspiration's progress between markers four and five is the surface-building work that bridges sovereignty-in-principle to sovereignty-in-practice; without that work, the license enables the right but the right is hard to exercise.

Relations

• conforms_to::[[Aspiration Form Contract]]

  • Exercises the Contract's directional-target Filename pattern, body shape, and identity-block prohibitions.

• grounded_in::[[eOS-Harness Composes With Adjacent Tools, Not Against Them]]

  • The additive-composition Conviction is what makes sovereignty achievable without the lock-in costs that "rewrite your full stack" migration would impose. Without it, the Aspiration would require rewrite-everything commitment from adopters, which would put sovereignty out of reach for most. With it, sovereignty is achievable incrementally: adopt the platform where the platform gap is, keep the rest, exit the parts that do not work without unwinding the parts that do. Currently a ghost link; the composes-with Conviction has not yet migrated.

• informed_by::[[Adopt BSD-2-Clause-Patent License]]

  • The License Posture Decision commits the project to permissive licensing at the application layer. The Decision is one of the three load-bearing commitments the Aspiration rests on; the Aspiration carries the directional target that the License Posture Decision alone does not -- the tooling and documentation that turn the licensed-self-hostability into practiced sovereignty. Currently a ghost link; the Decision has not yet migrated.

• informed_by::[[Adopt Cloud-Server with Hard Fork]]

  • The Cloud-Server Decision supports the audit-surface commitment by giving the project a kernel layer it owns. The Decision's preservation of the upstream cherry-pick channel composes with the Aspiration's fork-and-resume Work item: the cherry-pick channel handles upstream-to-this-project, the fork-and-resume documentation handles this-project-to-fork-and-back, and together they let a sovereign builder pick up upstream improvements without surrendering their fork's direction. Currently a ghost link; the Decision has not yet migrated.

• contrasts_with::[[eOS-Harness Is the Wrong Runtime Platform Without Platform-Pain]]

  • The pair sits at adjacent positions in scope-of-applicability framing. This Aspiration names the directional target for builders for whom sovereignty over the platform is load-bearing -- teams committing to an agent-infrastructure platform for years across team transitions, who cannot accept vendor risk or license drift. The anti-pitch Conviction's managed-cloud-SaaS case names workloads where sovereignty is not load-bearing because the operational model is "send us a credit card, get an API key, never think about infrastructure"; for those workloads, this Aspiration's target is not where the value is. Currently a ghost link; the anti-pitch Conviction has not yet migrated.