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.
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. The serious version of sovereignty, and the one the paper builds on, accepts this completely.
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 central Hub. The paper is explicit that OpenTeams is not building "the Intelligence Hub to rule them all": no shared tenant, no mandatory platform. Each organization assembles and owns its own, and the result is a fabric of sovereign peers interoperating through shared open standards rather than through a shared owner. 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 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. 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, and many will find this sufficient indefinitely”
- + 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, 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,
and many will find this sufficient indefinitely"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. That is the whole point."
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. TechTarget/ESG research finds 71% of organizations cannot get their storage infrastructure working smoothly with AI pipelines; Deloitte's operations survey 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.