Introduction

The Bill of Materials (BOM) page in the Cranium platform provides users with a comprehensive view of the technologies, models, and datasets that make up their AI Systems. By managing AI Bills of Materials, organizations gain critical visibility into the components that power their AI solutions, helping ensure transparency and accountability across their development lifecycle. An AI BOM provides your organization with a detailed inventory of all AI System components to demonstrate compliance, explainability, and optimize resources. 

On this page, you can create new BOMs, edit existing ones, and initiate CodeSensor and Detect AI scans. CodeSensor supports scanning for Python, Pickle, Poetry, JavaScript, TypeScript, and Java files and packages. CodeSensor also detects agentic AI frameworks in scanned repositories and captures static system prompts associated with AI models, surfacing both within the BOM detail view. Additionally, you can access vulnerability assessments tied to your AI Systems for a deeper understanding of potential security risks. Cranium’s Detect AI feature can help uncover hidden or "shadow AI" components that may exist without formal documentation.

This guide will walk you through the key features and actions on the BOM page, providing the tools to manage and enhance your AI Systems' component visibility.

Bill of Materials List

The Bill of Materials tab on the Bill of Materials page allows you to manage BOMs that you’ve created for your AI Systems. Each record in the table displays key information, including:

• BOM name and description
• Repository name
• AI Type(s) detected within the BOM
• VCS Integration name
• Name of the user identified as the BOM owner
• Status of the latest CodeSensor scan (complete, failed, or unscanned)
• Status of the Vulnerability Assessment (complete, failed, or unscanned)

The AI Type(s) column shows badges aggregating the categorization of models detected in the BOM:

• Generative AI
• Deep Learning
• Traditional Machine Learning
• Unknown.

A warning triangle icon next to a BOM name indicates the BOM is out of date and should be rescanned to pick up the latest categorization data.

Bills of Materials can be filtered by the owner, CodeSensor scan status, vulnerability scan status, or model type.

Bill of Materials Details

To gain deeper insights into a specific Bill of Materials, you can view its detailed breakdown by clicking the 3-dot kebab menu at the end of the corresponding record and selecting "View Details." This page provides a comprehensive overview of the BOM's components, helping you monitor the models, datasets, technologies, and infrastructures that form your AI System. Technologies refer to the packages and libraries that are found in the repository. Models are the AI/ML models present in the repository, while datasets are the collections of data that the AI System uses. Infrastructure includes the hardware resources (such as GPUs or CPUs) and cloud or on-premise infrastructure necessary for training and deploying models. These components are organized across four tabs — Technologies, Models, Datasets, and Infrastructure — each displaying the entries detected during the CodeSensor scan. Along with summary details like the BOM owner, description, and repository sources, you can also check the status of both CodeSensor scans and vulnerability reports. From this page, you can easily export, edit, or delete the BOM, or use the search function to locate specific elements by name.

Agentic Systems

For repositories that use supported agentic AI frameworks, the Agentic Systems tab in the BOM detail view lists each detected agentic system along with its framework and the number of agents it contains. Clicking Details opens a tabular breakdown of the individual agents within that system, showing each agent's name, model, instructions, tools, handoffs, file paths, guardrails, and MCP servers. Clicking View in the Visualization column opens an interactive graph displaying the relationships between agents in the system. Visualization is available when a system contains more than one agent with input or output connections. Agent relationships can be edited manually the same way as other BOM components, and Agentic Systems data is included when exporting the BOM in CycloneDX format. Supported frameworks include:

• Amazon Strands
• CrewAI
• Hugging Face smolagents
• Microsoft AutoGen-AgentChat
• LangGraph
• OpenAI Agents

If you do not see agent data for an existing BOM, rescan the repository to pick up agent framework detection.

Model Categorization

Within the Models tab, each model row includes Standardized Name, Confidence Level, and Model Type columns alongside the existing name, description, and file path. The Standardized Name column displays a normalized model identifier sourced from:

• HuggingFace Hub for HuggingFace models and
• Cranium model database for other models.

Teams can use this column to correlate the same model across BOMs even when it appears under different aliases. The Model Type column displays a badge that identifies the model as Generative AI, Deep Learning, Traditional Machine Learning, or Unknown. The Confidence Level column indicates how strongly the model type was identified. A Standardized Model View toggle at the top of the tab replaces the Name column with the Standardized Name column as the first column in the table, giving teams a normalized view of the same models. If you do not see categorization data for an existing BOM, rescan the repository to pick up model categorization.

System Prompts

When CodeSensor detects a static system prompt associated with a model in the repository, that prompt appears in a read-only panel nested under the relevant model entry in the Models tab. Security analysts can use this view to verify expected model behavior, and compliance teams can reference it when documenting AI system configuration. System prompt content cannot be edited from this view. If you do not see a system prompt panel for an existing model, rescan the repository to surface any detected prompts. Note that dynamically assembled prompts — those constructed at runtime rather than stored statically in the codebase — are not captured by CodeSensor.