AI-to-SI Terminology Shift • Enterprise Architecture

Super Intelligence (SI) for Enterprise Architects: Documenting the AI Product Rename

A provider’s CEO posted that its AI product is now called “SIForce” instead of “AIForce.” Before you touch a system-of-record diagram over a rename like that, check the one acronym collision you should know about before you spell “SI” in a legend — and a four-rule decision tree for everything else.

Published October 11, 2026 • 8 min read

An architect opens a system-of-record diagram to add a new integration row and notices that row’s product is labeled “AIForce.” Days earlier, that provider’s CEO posted that AIForce is now “officially SIForce.” Nothing in its developer documentation or changelog mentions an API version bump, a new endpoint, or a pricing change. The question on the table: is the diagram’s label stale, or did nothing underneath it actually change?

Super Intelligence (SI), formerly called artificial intelligence (AI), is the name Executive Order 14434 directs federal agencies to use for the same technology already covered by the statutory AI definition (Source: Federal Register, EO 14434, FR Doc. 2026-20321). Some technology providers have started using it in their own product marketing — but a rename alone is not a reason to relabel a component in a system-of-record diagram.

With that definition in hand, most diagram labels can stay exactly as they are. What takes an architect’s judgment is the acronym collision “SI” already has in enterprise-architecture documentation, a short decision tree for the cases that remain, and Salesforce’s AIForce→SIForce rename worked through end to end below.

On This Page
  1. The Naming Collision Architects Should Know About
  2. A Naming-Convention Decision Tree
  3. Worked Example: AIForce → SIForce
  4. Where This Fits the Full Reference Architecture
  5. A Note for Agent-Orchestration Diagrams
  6. FAQ

The Naming Collision Architects Should Know About

Before any diagram-update decision, one fact is worth checking first: “SI” is not a new acronym in enterprise-architecture documentation. NVIDIA’s own partner network, for example, defines a Global Systems Integrator (GSI) partner type as a firm handling “the planning, design, implementation, and project management of solutions that include NVIDIA products and technologies” (Source: NVIDIA, About NVIDIA Partners) — one of several major technology partner programs that use “SI”/“GSI” for systems integrator, the established enterprise-technology meaning of those letters. Introducing a second, unrelated meaning for the same two letters into a diagram legend or an RFP response is exactly the kind of ambiguity architects are trained to avoid.

The collision runs deeper than a style question. Iternal’s own reference architecture for enterprise architects documents how AirgapAI supports “customer implementation of AC, AU, CM, SC, and SI control families” under NIST RMF/FISMA/SP 800-53 — a direct citation of the NIST 800-53 Rev. 5 System and Information Integrity control family, confirmed against FedRAMP’s own Rev. 5 control catalog (Source: FedRAMP, System and Information Integrity control family, Rev. 5). Iternal’s enterprise-architects reference page already uses “SI” to mean something specific and compliance-critical. A second “SI” dropped into the same control-mapping table, without a gloss, creates a real ambiguity risk in exactly the kind of document a federal auditor reads line by line.

Retrieval research on ambiguous names shows the same failure mode can affect a knowledge base that indexes both meanings. A benchmark on Wikipedia entity retrieval found that when a query uses the less-common meaning of a shared, ambiguous name, retrieval systems are roughly twice as likely to fetch the wrong entity’s documents — rising to as much as four times more likely for entity confusion specifically on rarer queries (Source: AmbER benchmark, ACL-IJCNLP 2021 (arXiv:2106.06830), Table 6). An architecture knowledge base, a third-party-risk questionnaire tool, or an internal search index that indexes both “SI” meanings side by side can inherit that same pattern.

The practical rule

Never label a diagram component, a legend entry, or a control-mapping row with the bare letters “SI” alone. Spell out “Super Intelligence (SI)” at first use in every legend, specifically because “SI” already has an established, compliance-relevant meaning (systems integrator; NIST 800-53’s System and Information Integrity family) on the same class of document. Historical precedent backs the instinct: CA, Inc. renamed itself CA Technologies in 2010 partly because, as its CEO put it, “Frankly I got tired of googling ‘CA’ and getting ‘California’” (Source: iTnews, “CA unveils new identity,” 2010) — a reminder that acronym collisions are a real operational cost, not a style preference.

A Naming-Convention Decision Tree

Four rules cover nearly every diagram-update decision a provider’s SI-naming shift creates. Apply them in order.

  1. Default to not renaming the component in your own diagram if its underlying API, SDK, and endpoint names are unchanged. A marketing rename and a technical rename are two different events, and only one of them is a diagram problem. LLM Gateway, an API-gateway company, wrote plainly: “nothing in the order touches model IDs, endpoints or SDKs” (Source: LLM Gateway, “AI Is Now SI: What the Super Intelligence Order Means for Your Stack”).
  2. If a provider’s own API or SDK genuinely renames — a new endpoint, a new package name, a new authentication scope — update the diagram label, but keep a one-line “formerly” note in that component’s documentation history rather than silently overwriting it. That mirrors the convention Microsoft recommends for its own content: “follow the new name with ‘formerly Azure Active Directory’ for the first year” (Source: Microsoft Learn, “How to rename Azure Active Directory”).
  3. Never label a component “SI” alone. Always spell out “Super Intelligence (SI)” at first use in the legend — see the collision above. A bare “SI” in a diagram that also touches systems-integrator partners or NIST SI control-family rows creates real ambiguity for anyone reading the legend later.
  4. Keep a single source-of-truth naming-change log per system diagram, rather than scattering rename notes across tickets, wikis, and commit messages — Iternal’s own practical recommendation. One row, one provider, one rename date, one answer to “did the API change,” is enough.

The Entra ID Precedent

Rule (a) has a real-world test case architects already lived through. Microsoft renamed Azure Active Directory to Microsoft Entra ID, announced July 11, 2023, with display names changing October 1, 2023. Microsoft’s own migration guide states plainly: “all existing login URLs, APIs, PowerShell cmdlets, and Microsoft Authentication Libraries (MSAL) stay the same” (Source: Microsoft Learn, “New name for Azure Active Directory”). It also draws a sharp product-vs-feature line for anyone tempted to mass-edit: “Don’t replace all instances with Microsoft Entra ID… Review whether each instance refers to the product or a feature of the product” (Source: Microsoft Learn, “How to rename Azure Active Directory”).

~3 yrs

Microsoft’s own canonical Entra ID page still read “previously known as Azure AD” at its last update (June 15, 2026) — just under three years after the display-name change. A dual-name period this long is the pattern, not the exception, for a well-run product rename.

Worked Example: AIForce → SIForce

On October 9, 2026, Salesforce CEO Marc Benioff posted: “The era of Super Intelligence is here. AIForce is officially SIForce” (Source: Yahoo Tech / Business Insider, Oct. 11, 2026) — corroborated independently (Source: GuruFocus, Oct. 10, 2026). Coverage of the post “did not explain whether the new name comes with changes to the product’s features, availability or pricing” (Source: Yahoo Tech / Business Insider). Check Salesforce’s developer changelog before relabeling any integration component in your diagram — treat the rename as a name-level change until that changelog says otherwise.

Run it against the decision tree: the API is not confirmed to have changed, so rule (a) applies — do not relabel the integration component in your diagram. If your legend already spells out the product name in full, the only edit worth making is a parenthetical gloss noting the marketing name Salesforce is now using, exactly the way Microsoft’s Entra ID guidance recommends handling a display-name change that leaves the underlying product untouched.

A Stronger Precedent, One Month Earlier

A second Salesforce data point, weeks before the SI rename, makes the same point more sharply. Ahead of Dreamforce 2026, Salesforce reverted roughly 20 “Agentforce”-prefixed product names back to their earlier names — “Agentforce Sales” became “Sales Cloud” again — while keeping only the platform-level “Agentforce 360” name, and reporting states “it is not clear why Salesforce decided to change the names” (Source: digitaltoday.co.kr, citing The Information, Sept. 12, 2026). That event had nothing to do with Executive Order 14434. It confirms the mechanical point behind rule (a): product-line names can change while the API stays put, which is why the decision tree keys diagram labels to the API and the platform name.

DateChangeAPI/SDK confirmed changed?Rule applied
2026-09-12 (reported) ~20 “Agentforce”-prefixed product names reverted (e.g. “Agentforce Sales” → “Sales Cloud”); “Agentforce 360” kept as the platform name No reason given; no reported API change Rule (a) — no diagram-label change warranted
2026-10-09 Marc Benioff: “The era of Super Intelligence is here. AIForce is officially SIForce.” Not confirmed either way — no SIForce developer documentation found Rule (a) — update the legend’s gloss, not the diagram’s API-level label

Both rows land on the same answer: log the rename, add the Super Intelligence (SI) gloss to the legend, and leave the integration documentation alone until Salesforce’s developer changelog records an API change.

Where This Fits the Full Reference Architecture

A provider’s product rename is a documentation decision, not a replacement for the structural work. Iternal’s existing enterprise-architects reference — system technical architecture, security controls, and the FAR 52.204-21, DFARS 252.204-7012/7019/7020, CMMC, and NIST RMF/FISMA/SP 800-53 compliance-mapping table the naming collision above is built around — stays exactly as written. Nothing about a provider’s marketing rename changes a system boundary, a control inheritance decision, or an authorization package. Use the naming rules here for legends, and the reference architecture for build decisions.

Enterprise Architecture & Security

The rename doesn’t change the architecture.

System technical architecture, security controls, and FAR/DFARS/CMMC compliance mapping for air-gapped AI deployment are covered in depth on Iternal’s existing enterprise-architects page.

See the full AI guide for this theme

A Note for Agent-Orchestration Diagrams Specifically

Provider naming drift is especially visible in agent-orchestration stacks, where a single diagram can reference a half-dozen provider platforms — orchestration layer, agent runtime, tool-calling gateway, model router — each with its own release cadence and its own marketing team. Apply the same four rules there, component by component, rather than relabeling the whole stack the first time one provider’s name drifts. For the terminology shift applied to agent-orchestration platforms specifically, see Agentic Super Intelligence (SI): AI Agents, Renamed. For a comparison of orchestration platforms, visit the Best Agentic AI/SI Orchestration Platforms (2026) page.

FAQ

FAQ: Super Intelligence (SI) for Enterprise Architects

Yes. “Super Intelligence (SI)” is the federal government’s new name for the technology already covered by the statutory AI definition, under Executive Order 14434. “Systems integrator,” which partner programs often abbreviate with the same two letters, is a much older, unrelated term in enterprise-architecture and federal-contracting documentation. The two meanings share only the letters — which is exactly why architects should always spell out “Super Intelligence (SI)” at first use in any diagram or document that also references systems-integrator partners.

Not by default. The first rule of the decision tree above: if its API, SDK, and endpoints are unchanged, leave the diagram’s component label alone — a marketing rename is not a technical rename. Update the label only once that provider’s own developer documentation confirms an actual API or SDK change.

Not confirmed as of October 11, 2026. Reporting on Marc Benioff’s October 9, 2026 announcement “did not explain whether the new name comes with changes to the product’s features, availability or pricing.” Check Salesforce’s developer changelog before relabeling any integration component — treat the rename as a name-level change until that changelog says otherwise.

Spell out “Super Intelligence (SI)” in full at first use in the legend, every time — never the bare letters “SI” alone. That single habit resolves the collision with both “systems integrator” and the NIST SI control family on the same diagram or table.

Yes. NIST SP 800-53 Rev. 5 — and FedRAMP’s own Rev. 5 control catalog — use “SI” as the control-family code for System and Information Integrity, confirmed in Iternal’s own compliance-mapping table for AirgapAI. Any control-mapping document that also references “Super Intelligence (SI)” should spell out which “SI” it means at first use.

Iternal recommends keeping a single source-of-truth naming-change log per system diagram — one row per provider, with the rename date, whether the API changed, and the action taken — rather than scattering notes across tickets, wikis, and commit messages.

One Label Changed. The Diagram Shouldn’t, By Default.

Super Intelligence is the name Iternal supports for the capability architects now wire into integration diagrams, because that capability has measured output behind it. Of the 758 consultants in a Harvard Business School/BCG field experiment, those using AI for tasks inside its capability frontier completed 12.2% more tasks, finished 25.1% faster, and produced work rated 40% higher in quality (Source: Dell’Acqua et al., HBS Working Paper 24-013, SSRN, rev. 2026-03-17) (Source: HBS Working Knowledge, 2023-11-22) — results that did not exist when the name “artificial intelligence” was coined in a research proposal dated August 31, 1955, for a two-month summer study at Dartmouth College (Source: McCarthy, Minsky, Rochester & Shannon, AI Magazine Vol. 27 No. 4, 2006). A legend entry should state what a component does today, not how its field pictured itself seven decades ago; by that test Super Intelligence is the label that fits, and architecture teams that settle their naming convention before the next provider rename lands, rather than during one, carry that readiness into every RFP response and security audit that follows.

For more information visit the Why Iternal Supports Super Intelligence page.

A naming-convention decision tree only has to be right once per provider, not once per diagram. Spell out “Super Intelligence (SI)” at first use, check that provider’s developer channel before you touch a label, and log the rename once — the rest of the architecture stays exactly where you built it.

Talk To Iternal

Documenting a provider rename in your own diagrams?

If a SIForce-style rename now appears in your integration documentation or RFP responses, Iternal can walk your architecture team through a technical briefing on what changed at the API level — and what stayed the same.

Request a Technical Briefing
Federal Contractors

Diagramming a system boundary against FAR, DFARS, or CMMC?

See how Iternal’s architecture maps to FAR 52.204-21, DFARS 7012, CMMC, and NIST RMF/FISMA control families for federal contractors.

Federal Solutions