Part III — THE GROUND IT STANDS ON
7.The Intelligence Hub: A Perimeter of One's Own
the deployment where Frames, Cogs, Ops, and Tracks actually live, and the memory it accumulates. Assumes: Frames (Section 3), Cogs (Section 4), Ops (Section 5), Guards and Tracks (Section 6).
Part II built an execution model out of context artifacts, governed workers, installable jobs, and declared validation. Now the question that has been waiting since Section 1: where does all of this run? If the answer is "on a vendor's platform, under a vendor's policies," the architecture has decorated the tenancy problem rather than solved it, and everything the system learns will accumulate on the wrong side of the property line again.
The whitepaper's answer is the Intelligence Hub: a governed AI deployment operating inside the organization's own infrastructure perimeter, whether that perimeter is on-premise, in a private cloud, hybrid, or extended across edge devices. The Hub is where Frames are stored, versioned, and inherited; where Cogs are installed, configured, and run; where Ops execute against enterprise systems; where Tracks accumulate; and where the organization connects outward, on its own terms, to everyone else's Hubs and to the marketplace.
The paper restates what the Hub is in terms the Introduction previewed. The Hub is "an organization's Intelligence Infrastructure made concrete," and it is "where the organization's intelligence and its most important data are brought into the intimate contact that applied intelligence requires, inside a perimeter the organization governs" (§3.3). That sentence carries the revision's whole answer to the question this section exists to ask. The reason a Hub cannot be somebody else's product is no longer only custody — it is proximity. Useful AI has to sit close to the data that makes it useful, and sitting that close to a system you do not control is the definition of exposure rather than a risk to be managed. Whether the premise holds is the thing to test: it assumes applied intelligence genuinely requires intimacy rather than well-scoped, well-audited access, and a sufficiently good access-and-audit regime would weaken the argument considerably.
Sovereignty, defined realistically
"Own your AI" invites an obvious objection: almost nobody can own the whole stack. Chip fabrication, frontier model training, and hyperscale data centers are concentrated in a handful of firms and countries, and pretending otherwise is fantasy. Earlier editions of this guide supplied the realistic version of sovereignty as a corrective the paper had left implicit. Revision 9 states it directly, so the correction is now a citation:
Worth noting what the concession costs and what it buys. A realistic definition is more honest and considerably harder to falsify: "control at the points that matter" is only as strong as the list of points, and the list is the architecture's own. The evidence the paper marshals behind it, though, is third-party and unusually convergent.
Sovereignty at control points, not autarky. The organization does not need to have trained the model; it needs to control which model runs, what data reaches it, what policies bind it, and what evidence its work leaves behind. Those control points are exactly what the Hub is: the place where model choice, data access, governance, and audit all sit inside the organization's authority.
Two design principles sharpen the picture. First, there is no mandatory central Hub. Revision 9 rewrites this from a company commitment into a property of the architecture: "there is no central Hub and no mandatory platform that all users must flow to — only a distributed fabric of owned Hubs, each fully owned by the organization that operates it, interoperating through shared open standards rather than through a shared owner." What makes the fabric possible, the paper says, is that the abstractions are shared. OpenTeams is then described as one participant among several, contributing Nebari and Nebi, operating a public reference Hub for small organizations that cannot yet build their own, building products around the Hub, and providing maintenance so that owning a Hub "does not have to correlate with in-house AI engineering expertise," followed by the sentence that carries the revision's whole posture: "Others participate in the same ways, and the architecture is designed so that they can." Second, Hubs connect without merging. Sovereign does not mean isolated: Hubs exchange artifacts and appropriate derived results with other Hubs under the explicit policies of the organizations accountable for the data.
Organizational Memory: what the Hub accumulates
A deployment alone is plumbing. What makes the Hub compound in value is the substrate the paper calls Organizational Memory: the persistent context layer where everything the organization's AI work produces and learns accumulates, inside the perimeter.
The paper draws a distinction worth keeping crisp. Frames hold intentional, human-accountable context: what the organization has deliberately chosen to make explicit. But AI work also generates emergent context: what actually happened, across thousands of Cog conversations, Op executions, human corrections, and Tracks. The paper folds the accountability plane in explicitly: Guards, Gates, and Tracks are part of the full Organizational Memory too. Organizational Memory is where both kinds live and become available to future work, which is what turns a Hub from a static deployment into a system that gets better at being this particular organization.
Implementation is a continuum, not a product, and the paper is refreshingly unprecious about it:
- versioned Frame files in git“many organizations will start here, but most will not find this sufficient”
- + knowledge bases, wikis
- + semantic search over past Cog work and Op records
- + knowledge graphs, time-aware retrieval, full execution records
A spectrum from simple to sophisticated implementations of Organizational Memory. At the simple end: versioned files and documents in ordinary repositories. In the middle: retrieval over indexed document stores. At the sophisticated end: dedicated memory systems with vector search, knowledge graphs, and observability. All points on the continuum are legitimate; organizations start simple and move right as needs grow (though the paper now expects most to outgrow the simple end), and the memory belongs to the organization at every point.
View as text diagram
simple ────────────────────────────────────────────────────→ sophisticated
versioned + knowledge + semantic search + knowledge graphs,
Frame files bases, wikis over past Cog time-aware retrieval,
in git work and Op full execution
records records
"many organizations will start here,
but most will not find this sufficient"Because memory records what the organization has thought, decided, and discussed with AI assistance, it is the Hub's most sensitive capability, and the paper's governance requirements are correspondingly strict: access controls on who reads what, retention policies aligned with regulation, redaction, audit trails on memory access itself, and the ability to forget, removing specific memories when law or policy requires.
And it is here that the paper plants its flag on why the Hub cannot simply be repackaged as someone else's product:
"Organizational Memory belongs to the organization that produced it — owned and controlled. That is the whole point: it is the most intimate part of an organization's Intelligence Infrastructure, and intimacy without ownership is exposure."
Vendors and contractors can maintain components; particular services can be outsourced. But the accumulated memory of an organization's work, increasingly, is the organization, in the same way its general ledger is, and no company proposes renting its ledger's contents back from a chatbot vendor. The paper's blunt conclusion: an Intelligence Hub can be built with help, but it cannot be bought as a tenancy, because the thing that makes it valuable is precisely the thing that must not live on someone else's infrastructure.
One caution belongs here rather than in fine print. Integration is where this section's elegance meets enterprise reality: the Hub earns its keep only if it actually connects to the ERP, the CRM, the data lake, and the knowledge bases, and the industry's track record on that plumbing is poor. PwC's 2026 Digital Trends in Operations Survey (n=767 operations executives; the paper's source list records that this attribution was corrected from Deloitte in an earlier revision, and the correction still stands in Revision 9) finds 87% of leaders saying poor data quality has already hampered their digital initiatives; McKinsey's corrective is that "localization keeps data inside, but it does not automatically make data usable." A Hub does not repeal those statistics. It gives the integration work a single governed destination, which is progress, but the work remains work.