OpenAI, NVIDIA and SB Energy Define Roles for Ohio AI Campus
The proposed Ohio AI campus now has a clearer public map of who is doing what. SB Energy, OpenAI and NVIDIA have each published accounts of the project that separate the main roles across site operations, customer demand and compute infrastructure.
That matters because large AI campuses can involve many overlapping contracts, suppliers, land decisions, power arrangements, community questions and long-term technology plans. Without clear role labels, inquiries can land with the wrong organization. Published company statements now give ASCEND and similar directories a practical starting point for classifying the project.
Based on the companies’ statements, SB Energy is the site developer, owner and operator, OpenAI is the customer under a long-term lease arrangement, and NVIDIA infrastructure is intended to be hosted at the campus. NVIDIA has also described credit-support and compute arrangements tied to the project.
The right way to treat those roles is as dated and source-linked. Agreements can change, project phases can narrow or expand, and local engagement programs may be run by different companies at different times.

The published roles now form a workable starting point
The main update is not that every contract detail is public. It is that the central project roles have been described separately by the companies involved.
OpenAI’s published account says SB Energy will build, own and operate the site under a 20-year lease, while OpenAI will be the customer. NVIDIA’s release describes its credit-support and compute arrangements, and says the campus will host NVIDIA AI compute. SB Energy’s own project statement also places the company in the role of site owner and operator for the proposed technology campus.
Taken together, those accounts give directory operators, local stakeholders, vendors and public agencies a cleaner framework:
Subject | Published role to start from | Best routing logic |
Site development and campus operations | SB Energy | Route questions about buildout, ownership, operations and site profile details to SB Energy. |
Customer use and long-term lease demand | OpenAI | Route questions about OpenAI’s customer role and announced participation to OpenAI. |
AI compute infrastructure and related support | NVIDIA | Route questions about NVIDIA compute, credit support and infrastructure arrangements to NVIDIA. |
Local engagement tied to a specific company | Depends on the program | Route to the company that announced or administers that program. |
Future phase contracts | Depends on the contract | Attach dates and source links as new agreements are published. |
This is a classification tool, not a full legal map. The public statements describe roles at a high level. They do not replace contracts, permits, community agreements or future project notices.
For ASCEND’s company directory, the safest approach is to use these published statements as the first classification layer and attach source dates to each role. That way, users can see not just the company name, but the reason for the label and the date tied to it.
SB Energy is presented as the campus builder, owner and operator
SB Energy’s role is the most direct for site-level questions. The OpenAI statement says SB Energy will build, own and operate the site under a 20-year lease. SB Energy’s own project statement aligns with that role.
That makes SB Energy the starting contact for subjects tied to the physical campus. These may include:
Construction sequencing and site preparation
Property and facility ownership
Campus operations
Utility coordination at the site level
Project profile updates about the campus itself
Company-specific local engagement run by SB Energy
A directory entry for SB Energy should not treat the company as a generic partner. The published role is more specific. SB Energy is the entity described as building, owning and operating the proposed site.
That distinction helps avoid a common problem with large infrastructure projects. If every company in the announcement is listed as a “project partner,” public inquiries can scatter. A resident asking about site construction needs a different path than a vendor asking about compute infrastructure, or a reporter asking about OpenAI’s customer role.
The phrase operator also needs careful handling. In this context, it points to the campus site and its operation as described in the company statements. It should not be stretched to mean that SB Energy controls every hosted technology decision or every compute arrangement unless a source says so.
A good directory label would read along these lines:
SB Energy is identified in published company statements as the builder, owner and operator of the proposed Ohio AI campus, under a 20-year lease arrangement with OpenAI as customer.
That label stays close to the source language and avoids adding claims that are not public.

OpenAI is identified as the customer under the long-term lease
OpenAI’s role is different. Its own account says SB Energy will build, own and operate the site under a 20-year lease, and that OpenAI will be the customer.
That customer role is central to why the campus is being discussed as an AI project. OpenAI’s demand is the anchor described in its announcement. Yet the wording does not make OpenAI the site owner or operator in the public role map provided by the companies.
For directory and inquiry routing, that means OpenAI is the right path for questions about:
Its announced participation in the Ports Pike project
The customer relationship described in its statement
How the campus fits its broader infrastructure needs, to the extent OpenAI has published that information
OpenAI-specific public statements, updates or local programs
OpenAI is not the default route for every construction or site operations question just because it is the customer. A customer under a lease can be central to a project’s demand without being the party that builds or manages the site.
That split matters for public clarity. AI infrastructure announcements often combine energy, land, cloud, hardware and software names in one press cycle. Readers may recognize one company more than the others, then assume that company controls the whole site. The published statements here support a more exact classification.
The phrase OpenAI, NVIDIA and SB Energy define roles for Ohio AI campus captures the central point. The announcements are complementary, but the roles are not identical.
NVIDIA is tied to compute infrastructure, credit support and hosting
NVIDIA’s release adds another layer. It describes credit-support and compute arrangements tied to SB Energy’s Ports Pike Technology Campus in Ohio, and says the site will exclusively host NVIDIA AI compute.
That points to NVIDIA as the company linked to the campus’s compute infrastructure role. It does not replace SB Energy’s site operator role or OpenAI’s customer role. It sits beside them.
For routing, NVIDIA is the best starting point for questions about:
NVIDIA AI compute described in the release
NVIDIA’s credit-support arrangements
NVIDIA-specific infrastructure commitments
Public updates that NVIDIA publishes about the compute side of the campus
The word compute should also be used with precision. It refers to the AI computing infrastructure described in NVIDIA’s materials. It should not be used as a broad label for every facility function, power arrangement or lease term.
This is where source-linked directory entries can prevent confusion. A directory can list NVIDIA as “compute infrastructure and credit-support role, per NVIDIA release,” rather than as a general campus operator.
That small change improves accuracy. It also gives people a better chance of contacting the right organization first.
Dates should travel with every project role
The source dates matter because these are living projects. The brief identifies source dates beginning August 17, 2026, and later project statements. Those dates should stay attached to role classifications.
A directory entry should answer three basic questions:
What role did the company publish or confirm?
Which source supports that role?
When was that source published or last updated?
That approach reduces the risk of stale information. It also creates a clean update path if later phase contracts, lease documents, permits or engagement programs clarify the structure.
A practical directory format might include fields like:
Field | Why it matters |
Company name | Keeps each organization’s profile separate. |
Published project role | Shows whether the company is listed as operator, customer, compute provider or another role. |
Source link | Lets users verify the public statement. |
Source date | Shows when the role was recorded. |
Scope note | Explains what the role does and does not cover. |
Last profile review | Helps users judge whether the entry may need updating. |
This matters most when projects move from announcement to execution. Early descriptions often focus on headline roles. Later documents may explain phases, facilities, contractors, power delivery, community benefits, workforce programs and procurement processes.
A good profile does not try to predict all of that. It records what has been published and leaves room for updates.

Inquiries should follow the subject, not the loudest company name
Large AI campus announcements often create a visibility imbalance. One well-known company may attract most public attention, even when another company owns or operates the site. That can create delays for residents, vendors, journalists and local organizations.
The cleaner rule is simple: route the inquiry to the organization whose published role matches the subject.
If the subject is the physical campus, SB Energy is the starting point based on the published operator role. If the subject is OpenAI’s use of the site as customer, OpenAI is the starting point. If the subject is NVIDIA AI compute or the credit-support arrangements described by NVIDIA, NVIDIA is the starting point.
Some inquiries will not fit neatly. Local engagement is one example. Company-specific programs should route to the company that announced them. A workforce event run by one company does not automatically belong to another. A community update about construction may belong with the site operator. A technical update about hosted compute may belong with NVIDIA.
The same is true for profile updates. If ASCEND receives a correction request, the requested edit should be checked against the relevant company source. A claim about campus ownership should not be resolved with a compute release alone. A claim about AI compute should not be resolved only with a lease summary.
What ASCEND should watch as the campus moves forward
The current public role map is useful, but it should not be treated as finished forever. The main items to watch are phase contracts and company-specific local engagement programs.
Phase contracts may add new names to the project. They may also clarify responsibilities within construction, equipment delivery, energy systems, facility services or community programs. Those companies should not be folded into the same label by default. Each should receive a role tied to the specific contract or statement that names it.
Local engagement programs also need care. If SB Energy runs one program, OpenAI runs another, and NVIDIA publishes a separate initiative, a directory should keep them separate. That helps local groups find the right contact and avoids implying that one company speaks for all others.
Good updates should use plain language. For example:
SB Energy Site builder, owner and operator, based on company statements.
OpenAI Customer under the long-term lease arrangement described by OpenAI.
NVIDIA AI compute infrastructure and credit-support role, based on NVIDIA’s release.
That format is short, useful and source-aware.
The source record should remain visible
The three core source streams are OpenAI, NVIDIA and SB Energy. A directory or profile page should link to each relevant statement rather than collapse them into one summary with no trail.
Helpful source links include:
The best summaries will stay close to those sources. They will also make clear that public role descriptions can evolve as agreements and project scope evolve.

The takeaway for project classification
The proposed Ohio AI campus now has a clearer public role structure. SB Energy is described as the builder, owner and operator of the site. OpenAI is described as the customer under a 20-year lease. NVIDIA is tied to hosted AI compute, credit support and related infrastructure arrangements.
For ASCEND’s company directory, that is enough to set a first classification layer, as long as each role carries its source and date. The directory should route questions by subject, not by name recognition, and it should expect future updates as phase contracts and local engagement programs are published.
Clear labels will not answer every project question. They will make the next question easier to send to the right place.





Comments