Native & Embedded: Classification Methodology
The Arion Enterprise AI Atlas | Draft v0.1 | August 2026 | Arion Research
1. Purpose and Scope
The Arion Enterprise AI Atlas is a curated map of enterprise AI solutions organized around the Native & Embedded framework. This document defines the framework, the criteria used to classify every solution on the map, and the process for handling ambiguous cases. It is published so that classification decisions are transparent, contestable, and consistent across editions.
The Atlas maps products and solutions, not vendors. A single vendor can, and often will, appear in multiple cells and in both panels.
2. The Framework
The framework recognizes two structural types of enterprise AI solutions and one deployment pattern.
AI Native. A solution whose core architecture and primary value depend on AI models. The model is not a feature of the product; it is the reason the product exists. Remove the models and the product either stops functioning or loses its reason to exist. AI Native solutions span the full stack, from compute infrastructure and foundation models through agent platforms to native applications.
AI Embedded. AI capability delivered inside a pre-existing enterprise software product or category. The host product predates its AI capability and functions without it. The AI augments established workflows, data, and user bases rather than defining the product. Examples of the pattern: an AI assistant inside a CRM suite, agents operating on an established workflow platform, generative features inside a collaboration suite.
AI Enhanced (a pattern, not a panel). AI Enhanced describes solutions and deployments created by composing AI Native tools with existing enterprise systems, typically on the buyer side or through integrators. Because AI Enhanced outcomes are built from the two mapped populations rather than existing as a separate vendor population, the Atlas does not map it as a panel. The methodology names it because the term is part of the original framework and describes how most enterprise value is realized in practice.
3. Unit of Analysis
The unit of analysis is the product or solution, defined as a distinctly named, separately adoptable offering. Suites are decomposed when their components are sold, deployed, or architected separately. This choice follows from the framework itself: classification tests examine architecture and value delivery, which are properties of products, not companies.
Consequences of this choice:
Large vendors appear multiple times. A hyperscaler's AI development platform can sit in the Native panel while its productivity copilot sits in the Embedded panel.
Company history does not determine classification. Founding date, funding era, and prior pivots are signals at most, never decisive.
The map stays honest as vendors converge. When an embedded suite vendor ships a separately architected native product, the product is classified on its own merits.
4. Classification Tests
Every solution is evaluated against five tests, applied in order. Test 1 is decisive when the answer is clear. Tests 2 through 5 resolve ambiguous cases by weight of evidence.
Test 1: Dependency (decisive). Does the product deliver its core value proposition if the AI models are removed? If no, the product is a Native candidate. If yes, it is an Embedded candidate. This is the heart of the framework: it asks what the product is, not what it advertises.
Test 2: Architecture. Where does the model sit in the execution path? In a Native product, models sit in the primary execution path of core workflows. In an Embedded product, models sit in an assistive or optional path alongside deterministic workflows that carry the core load.
Test 3: Origin. Was the product designed around model capabilities from its first release, or was AI added to a product that already existed? This is a supporting signal, not a decisive one. It guards against two errors: treating every startup as Native by default, and treating every established vendor as Embedded by default. An established vendor can ship a genuinely Native product; a startup can ship a conventional product with AI features.
Test 4: Commercial. Is AI capability the headline value proposition and the basis of pricing, or is it a feature, SKU, or add-on attached to an existing license? Follow the money: how a vendor charges reveals how it thinks about what it is selling.
Test 5: Interface. Is the primary interaction paradigm model-mediated (conversational, agentic, generative) or a conventional interface with AI assists? This is the weakest test, used only as a tiebreaker, because interface fashion changes faster than architecture.
Decision rule. A clear answer on Test 1 settles classification. When Test 1 is ambiguous, classify by the majority of Tests 2 through 5, and record the case as an edge case with written rationale and a confidence rating (see Section 7).
5. Edge Cases and Precedents
These recurring situations are resolved as follows. New precedents are added as the Atlas encounters them, so classification stays consistent across editions.
Pivots. Classify the current product architecture, not the company's history. A company founded in 2018 that rebuilt its product around models in 2024 is evaluated on the 2024 architecture.
Platform extensions. AI agents or assistants that ride on an established platform (workflow, CRM, ERP), inherit its data model, and are sold as extensions of it are Embedded, even when the AI capability is sophisticated. The test is whether the AI capability stands alone.
Acquired native products. A Native product acquired by a suite vendor stays Native while it remains separately sold and separately architected. When it is absorbed into the host suite as a feature, it moves to Embedded, and the change is recorded in the edition delta.
Data and analytics platforms. Platforms that predate the model era and have added substantial AI capability (lakehouse platforms, cloud data warehouses, BI suites) are Embedded: the host platform functions without the AI, and the AI capability rides the platform's data gravity. A separately adoptable AI infrastructure product from the same vendor is classified on its own merits.
Models inside applications. Using models internally does not make a product Native if the customer-facing value proposition survives without them. Nearly every enterprise product now touches a model somewhere; the framework classifies what the product delivers, not what its plumbing includes.
6. Attributes
Attributes describe capabilities that cut across the taxonomy. They are recorded per product and rendered as visual tags on the map, never as categories. The first release defines one primary attribute; others (deployment model, target segment) are stored in the database for analysis.
Agentic capability is scored on a four-level scale:
Level 0, None. No agentic capability. May still include generative or predictive AI.
Level 1, Assistive. Responds to prompts within a single turn or task: drafting, summarizing, answering. No multi-step execution.
Level 2, Agentic. Plans and executes multi-step work using tools, with human checkpoints. Operates under supervision within a bounded scope.
Level 3, Autonomous. Accepts goal-level delegation and executes with minimal supervision, including initiating work. Bounded by policy rather than by per-task approval.
Products at Level 2 or above carry the agentic tag on the map. The level itself is stored in the database and reported in category analyses.
7. Inclusion Criteria
The Atlas is curated. Inclusion reflects an editorial judgment that a solution matters to enterprise buyers, backed by the following bar. A product must meet all of the first four criteria:
Enterprise-grade. Sold to enterprises with a credible security, compliance, and administration posture. Consumer-only products are excluded.
Generally available. Shipping and adoptable today. Waitlist-only, private-beta-only, and announced-but-unshipped products are excluded.
Demonstrated traction. Evidence of real enterprise adoption: named customers, meaningful revenue or funding signals, or clear category presence.
Active. Shipped meaningful product updates within the trailing twelve months.
Exclusions: pure consulting and services firms, hardware-only offerings, and products in stealth. Systems integrators and service-led AI practices are acknowledged in the methodology as the primary builders of AI Enhanced deployments but are not mapped.
Target scale for the first edition is roughly 300 to 500 products. The constraint is deliberate: the Atlas's value is judgment, not census.
8. Governance and Process
Rationale and confidence. Every classification records a written rationale and a confidence rating (high, medium, low). Low-confidence classifications are flagged for re-review before each edition.
Evidence. Each product entry cites the public evidence used: documentation, pricing pages, architecture descriptions, customer references.
Re-review cadence. All entries are re-verified before each annual edition. Products involved in acquisitions, major re-architectures, or repositioning are re-reviewed when the event occurs.
Vendor challenges. Vendors may challenge a classification by providing evidence against the tests in Section 4. Challenges are decided against the published criteria, and the decision and reasoning are recorded. The criteria themselves change only between editions, with changes documented in the version history.
Deltas. Each edition publishes what changed: products added, removed, reclassified, or moved between categories, with reasons. The delta is a first-class output of the Atlas, not a footnote.
9. Version History
v0.1 (August 2026). Initial draft of definitions, tests, edge-case precedents, agentic levels, inclusion criteria, and governance process.