Assembled From the Commons · Own Your Intelligence

Every Intelligence Hub is built almost entirely from parts nobody sells. The open-source AI ecosystem contains model servers, vector databases, orchestration frameworks, observability stacks, identity systems, schedulers, and more, several competing options in each category, each evolving monthly. This commons is enormously productive, and it has a well-known problem: it arrives as a warehouse of excellent parts and no vehicle. Assembling those parts into a coherent, governed, production-grade system is specialist work, and the specialists are concentrated in a few hundred firms.

The paper now names what the assembly is for. Layer 1, in its words, is "the layer where information technology begins its evolution into Intelligence Infrastructure": the point at which a rack of general-purpose systems starts being the thing that carries the organization's intelligence rather than merely its data. The components below are unchanged; the claim about what they add up to is new.

The infrastructure question underneath everything in this guide is therefore really two questions. Who turns the commons into a working Hub for organizations that cannot do it themselves? And how do the artifacts of Part II, the Frames and Cogs and Ops, get packaged so they can be installed into any Hub and behave the same way? The paper's answers are, respectively, a market role and two open-source projects, and Revision 9 is careful that the role belongs to no one in particular.

Nebari: the curated stack

Nebari (nebari.dev) is OpenTeams' flagship contribution to the commons: an open-source ecosystem for deploying, managing, and scaling AI infrastructure reproducibly. Since mid-2025 it has been rearchitected as a modular stack: an infrastructure core with more than fifteen packs above it, at varying levels of maturity by the paper's own account, spanning the Jupyter-based data-science tooling the project began with through open-weight LLM serving and generative-AI chat. Two design commitments matter more than the pack inventory. Nebari is additive: its components are curated open-source tools, usable à la carte alongside whatever an organization already runs, not a monolith demanding allegiance. And it is deliberately one contribution among many: the paper itself insists that "an Intelligence Hub is not 'a Nebari deployment'" but a purpose-built assembly of the right components for a specific organization, in which Nebari may play a role and rarely plays the only one.

That restraint is strategic, and it has a precedent the paper leans on by name.

Precedent

NumPy became the universal array standard for scientific computing not by outcompeting alternatives commercially but by being open, useful, and neutral enough that an entire ecosystem (SciPy, pandas, scikit-learn, and eventually the Python AI stack) could safely build on it. Openness was what made it a foundation rather than a product. Travis Oliphant, who created NumPy and co-founded Anaconda, leads OpenTeams; Dharhas Pothina, who has guided Nebari for six years, brings the enterprise and government deployment history. Revision 9 moves this record to the front of the paper and argues it in the first person: SciPy, NumPy, Numba, and conda are offered as a lineage of shared abstractions where "the value accrued broadly, to the communities and companies that adopted it," with the further claim that "it is a fair argument that many of these shared abstractions laid the foundation the AI revolution was built on." Two observations. The pattern is real and verifiable, which is more than most credibility claims in this literature offer. And a track record of giving away foundations is evidence about disposition, not about outcomes: NumPy succeeded in a research commons with no incumbent defending the position, which is not the situation enterprise AI is in.

The market context for betting on open infrastructure, rather than against it:

Nebi: the install primitive

Nebi is the quieter project and, for this guide's argument, the more load-bearing one. It is the packaging and environment-management layer: the mechanism by which environments, models, dependencies, Frames, Cogs, Ops, and Guards are specified, versioned, installed, updated, and removed. The paper's framing: Nebari is OpenTeams' flagship contribution to the AI infrastructure ecosystem; Nebi is its contribution to reproducibility and distribution. The operating-system analogy (Nebari as the OS, Nebi as pip, npm, or apt) is this guide's shorthand (earlier revisions of the paper used it too), and the paper's own pip/npm comparison for Op distribution (§4.5) points the same direction.

The paper makes two claims here that earlier editions of this guide treated as prospective. Nebi "is built and working today," and it is "deliberately not built from scratch": Nebi builds on the pixi ecosystem, which itself built on conda, "a large, stable, community-governed distribution ecosystem with more than a decade of production use." The paper calls that lineage "the paper's thesis in miniature: shared abstractions compound across generations rather than being reinvented by each new wave," and repeats the point twice more elsewhere in the revision, which is how you can tell it matters to the author.

It is also the paper arguing on this guide's own ground, so the guide owes it a test rather than an echo. The first claim is checkable, so check it: nebi.nebari.dev labels the project early release at v0.13 as of this writing, and the scope it describes there is environment management for teams (Pixi workspaces, sync, diff, OCI publishing) rather than the cross-Hub distribution of Frames, Cogs, Ops, and Guards the paper assigns it. "Built and working today" is true of the former; the latter is the claim that matters here, and the paper's own ledger files the marketplace those artifacts would travel through under thesis. The second claim invites an engineering test. Building on pixi and conda buys a decade of packaging discipline and a working solver; it also inherits a lineage optimized for software environments. The artifacts this economy needs to move are not only software: they are multi-gigabyte model weights, Frames that are folders of governed prose, and Cogs that combine both. Whether conda-lineage tooling handles weight-scale binaries, content-addressed deduplication, and license-encumbered model distribution as gracefully as it handles Python packages is an engineering question the paper does not answer, and it is exactly the question that decides whether "reproducible by construction" survives contact with a 70-billion-parameter Cog.

Keep the italicized caveat; the design depends on it. Two installations of one Op differ for two reasons, and only one of them is what the caveat concerns. The first is designed: the Op picks up each installer's Frames and memory, which is Section 5's whole point; the Ohio hospital's install is supposed to sound like Ohio. The second is stochastic: generative models do not return identical outputs even under identical conditions, and no packaging layer changes that. What Nebi reproduces is everything around the model: versions, dependencies, environments, configurations, pinned and logged so that every installation is auditable. Determinism is not the claim. The claim is that the installed artifact is verifiably the published one, and that its work is verifiable run by run, which is what Section 6's Guards are for.

The assembly business

Between the commons and a running Hub sits skilled labor. Earlier revisions of the paper said outright that this is where OpenTeams earns money. Revision 9 describes the same work as a role that anyone can fill: organizations "need a concierge to that ecosystem — one accountable partner responsible for selection, integration, hardening, maintenance, and evolution," and then, pointedly, "OpenTeams offers that role, as do integrators and consultancies building on the same standards; the architecture works precisely because the role is not exclusive." The same de-personalizing edit reaches the Intelligent Ops Factory, the paper's name for a facility that produces and continuously maintains an organization's standard operating procedures the way a software factory produces software, and which is now operable by "integrators, consultancies, vertical specialists, and organizations themselves"; and it reaches the startup ecosystem, where "no single company needs to build every vertical Frame, Cog, Op, or Guard — nor should one."

The edit is not uniform, and the residue is worth naming here rather than only in Section 11. The paper's own canonical sentence, set in bold and offered as "worth stating once and holding to throughout," still reads: "The Intelligence Hub is a customer-specific assembly of open-source and proprietary components that OpenTeams integrates, governs, and maintains" (§3). And §3.3 still describes the assembly in the first person, with OpenTeams as the concierge and the promise that "we can help select, integrate, harden, and maintain the right open-source components." Those are claims about who builds and runs the thing, not merely about who earns from it, and they sit uneasily beside the non-exclusive sentence quoted above.

Even so, this is a case where the ecosystem framing strengthens rather than weakens the market-structure reading. Whenever a rich commons meets scarce assembly skill, an integration business forms, and if several form rather than one, the standard underneath them is more likely to stay a standard. Red Hat built one on Linux; Anaconda built one on scientific Python; the pattern is old and the economics are unmysterious. What the model requires to scale is that the assemblies themselves become standardized and reusable rather than perpetually bespoke, which is precisely what Nebari packs and Nebi packaging exist to do. McKinsey's talent finding (insufficient AI skills as the #1 integration barrier, with Deloitte finding only 20% of companies reporting high talent preparedness) is, read from this angle, the demand curve for that business.