Is AI the product, or just a wrapper?

The score is a weighted sum of six pillars, each scored from 0 to 100: Product Embedding (30%), Model Integration (20%), Retrieval / Data Plane (15%), Platform Readiness (15%), MLOps & Evaluation (10%), and Adoption Velocity (10%). Each pillar contributes its score multiplied by its weight. The scoring is rule-based and versioned, so the same codebase always produces the same result. It is not generated by an AI model.

It's the highest of four usage classes. A company qualifies when at least 10% of its code is machine learning code and the product uses at least one production-grade AI technology, such as model APIs, ML frameworks, agent runtimes, or local LLMs. Companies with production AI technology but less ML code are classed as AI Augmented. Those with only notebooks or experimental tooling are AI Exploratory, and those with no AI signals are No AI Signal. A codebase with a lot of ML code but no recognized AI technology stays in AI Exploratory.

Not on its own. Listing an AI package as a dependency has only a small effect on the score. What matters is how much of the shipped code is machine learning, measured file by file. We also check where each AI package is actually used. If it only appears in tests, documentation, or authentication code, it doesn't count toward Model Integration.

IP depth describes what kind of AI the company has built, separate from how much. Each repository is placed in one class: own models, data pipeline, agentic system, AI integrator, API wrapper, or no AI. Classes are checked from deepest to shallowest, and the first one supported by the evidence is assigned. Own models requires evidence of model training and a meaningful share of ML code. Agentic system requires an agent framework that plays a central role in the product. Two repositories can have the same score but very different IP depth, which can mean very different investment value.

Four sources. First, every file is classified as machine learning or application code. Second, we detect the technologies in use from packages and imports, then confirm where they're actually used. Third, we analyze the architecture, including shared data stores, infrastructure, scaling, deployment, and operational maturity. Fourth, we review the Git history, including when AI was first introduced and how much AI-related work happened in the last 90 days. CI/CD maturity is reflected through the architecture and MLOps findings.

A zero means no supporting evidence was found, and it's a finding in its own right. Retrieval / Data Plane scores zero when there are no embeddings, vector stores, or shared data architecture. Adoption Velocity scores zero when there's no AI-related development in the last 90 days. Platform Readiness scores zero when there's no architecture data to assess.

AI Native measures the AI inside the product: what has been built and shipped. AI in Development measures AI in how the team writes code: how much was written by coding agents, and how it was reviewed and deployed. They answer different questions, so a full picture needs both.

No. An optional AI-generated summary can turn the findings into memo-ready text, but the score, pillars, IP depth, and evidence are calculated independently and remain available even if no summary is produced. Investment decisions should rely on the underlying findings, not the summary alone.

Only the structured results of the analysis: the share of ML code, detected technologies, pillar scores, usage class, IP depth, and the Git activity used for Adoption Velocity. We do not store source code. For cloud audits, the source code is removed once the analysis is complete.