ASA (AI Solution Architecture) Elements - A Quick Reference

Category	Name	Prefix	Image	Definition	Instance / Usage Example
Intent & Metrics	Intent	IT		Represents the strategic intent, value drivers, and guiding principles that justify and direct the solution.	Strategic goals, desired business outcomes, measurable impact, expected ROI, cost/value, core value propositions, and guiding architectural principles that drive solutions.
Intent & Metrics	Capability	CP		Represents the business, technical and AI abilities the solution enables or delivers.	Business and technical capabilities that the solution enables or delivers, encompassing both enterprise-level functional capabilities and specific AI capabilities such as prediction, classification, generation, or natural language understanding.
Intent & Metrics	Requirement	RQ		Represents the functional and non-functional needs, scenarios, quality expectations, and acceptance criteria the solution must satisfy.	Use case scenarios, user stories, business process flows, functional and non-functional requirements, quality metrics, implicit requirements, acceptance criteria, and context-specific solution needs.
Intent & Metrics	Governance	GV		Represents the principles, policies, compliance obligations, ethical controls, and accountability structures that guide responsible solution behavior.	Governance guided by principles, policies, regulatory compliance requirements, guardrails, ethical guidelines, bias detection and mitigation controls, responsible AI frameworks, and accountability mechanisms.
Intent & Metrics	Decision	KC		Represents the key architectural choices, evaluated trade-offs, and rationale that shape the solution design.	Critical decision points, architectural trade-offs, design alternatives evaluated, rationale for selected approaches, and strategic technology choices that shape the solution.
Functional	Access Interface	UI		Represents the interaction channels, UI/UX surfaces, and entry points through which humans engage with the solution.	User experience or interaction channels, UI/UX components, conversational interfaces (GUI, CLI, voice, media), call access, app triggers, and entry points for human-AI interaction.
Functional	Application	AP		Represents a bounded software system, enterprise application, or business component that integrates with or consumes service capabilities.	Bounded software unit, enterprise applications, legacy systems, AI-native applications, microservices, and business components that integrate with.
Functional	App Logic	AS		Represents explicitly defined non-GUI logic, control flow, or compositional behavior of an application.	Explicitly defined non-GUI application behavior and control logic, business rules engines, conditional branching logic, and application composition.
Functional	Data Service	DS		Represents services responsible for data access, integration, transformation, federation, and transactional integrity.	Data access layers, streaming services, data transformation pipelines, and services that provide or prepare data for integration, federation, transactional access, and data quality assurance.
Functional	Technical Component	TS		Represents reusable technical capabilities, utility services, and cross-cutting infrastructure functions available across the solution.	Reusable technical utilities, infrastructure services, cross-cutting capabilities such as authentication services, logging frameworks, and notification services shared across the solution.
Functional	Interface Contract	SI		Represents the defined interface, contract, API, or protocol through which components expose and consume capabilities.	Service interface, RESTful APIs, GraphQL interfaces, gRPC service contracts, Model Context Protocol (MCP) endpoints, webhooks, and interface specifications that define synchronous service interaction boundaries. Note: When the Message & Event element is not used, it’s also used to indicate asynchronous message contracts, domain events, integration event schemas, event-driven notification payloads, and information contracts governing data exchanged through messaging and event streaming channels.
Functional-AI Specific	AI Agent	AG		Represents an autonomous AI entity capable of goal-directed reasoning, planning, and action.	Autonomous AI entities (e.g., LLM-based, goal-oriented agents), ReAct and plan-execute agents, specialized AI assistants, and conversational bots operating with decision-making autonomy.
Functional-AI Specific	AI Orchestrator	AC		Represents the coordination logic, workflow control, and multi-agent management that sequences and routes AI operations.	Agent orchestration engines, multi-agent coordination frameworks, task routers, workflow controllers, and application logic that sequences and manages AI model invocations and agent interactions.
Functional-AI Specific	Context State	CN		Represents the mechanisms for managing conversational state, memory, prompt engineering, and interaction coherence.	Context window management, conversation state tracking, session memory stores, prompt engineering templates, context caching mechanisms, and strategies for maintaining interaction coherence across multi-turn dialogues.
Functional-AI Specific	AI Model	ML		Represents the models, inference engines, and reasoning frameworks that generate predictions, decisions, or outputs.	LLMs, foundation models, fine-tuned domain models, ensemble methods, reasoning and inference engines, decision logic frameworks, and AI/ML models that produce predictions, classifications, or generated outputs.
Functional-AI Specific	Knowledge Service	KA		Represents the semantic retrieval, RAG, embedding, and knowledge management capabilities that ground AI responses in relevant information.	RAG services, vector databases and embedding services, semantic retrieval pipelines, knowledge index management, knowledge freshness monitoring, data sources, and configuration services that govern AI knowledge access quality and relevance.
Functional-AI Specific	AI/ML Lifecycle	AL		Represents the lifecycle management processes for model training, experimentation, versioning, and deployment.	MLOps and AIOps pipelines, model training and fine-tuning workflows, experiment tracking platforms, model registries, versioning systems, and CI/CD pipelines for automated AI model deployment and lifecycle management.
Functional-AI Specific	Tool	TL		Represents external functions, plugins, and third-party services that extend AI capabilities through invocation.	External function-calling capabilities, third-party API integrations, plugins, code execution environments, web search tools, and actions invoked autonomously by AI agents to fulfill task requirements.
Operational	Data Store	DB		Represents the repositories where structured, unstructured, or semi-structured data is persisted and managed.	Databases, data warehouses, data lakes, vector databases for embedding storage, object storage systems, file repositories, and knowledge bases that persist solution data assets.
Operational	Deployment Package	DP		Represents a discrete, deployable and scalable package of software or functionality.	Deployment packages that define the deployable and independently scalable units of the solution. Containerized microservices, serverless functions, Kubernetes pods, and virtual machine images.
Operational	Node	ND		Represents the physical and virtual compute resources that host and execute the solution.	Physical and virtual compute resources, GPUs, TPUs, CPUs, edge devices, cloud compute instances, clusters, and infrastructure.
Operational	Quality & Adaptation	QV		Represents the testing, validation, and continuous improvement mechanisms that assess solution quality and performance.	Model evaluation (evals) and tracing, performance metrics dashboards, safety and bias evaluation frameworks, A/B testing pipelines, feedback loop mechanisms, continuous monitoring, and model quality improvement workflows.
Operational	Governance Control	GO		Represents the operational controls, policy enforcement, observability, security monitoring, and human oversight mechanisms active during execution.	Runtime governance operations, policy enforcement mechanisms, access controls, audit trails, and operational risk management, security monitoring, observability dashboards, and human-in-the-loop (HITL) oversight.
Operational	Middleware	MW		Represents the system and platform software, middleware, and services that underpin application execution and integration.	System software, platform software and services such as PaaS (Platform as a Service) and iPaaS (infrastructure PaaS) that underpin cross-component communication and operational management, service meshes, application servers, message brokers, cost control services. Note: Common subtypes include integration and messaging (MW-ESB), security (MW-SEC), API gateway (MW-GW), and analytics (MW-DA).
General	Group	GP		Represents a logical or functional organizational structure used to partition, layer, or modularize the architecture.	Architectural layer groupings (e.g., AI layer, data layer), domain-driven bounded contexts, functional subsystem boundaries, location boundaries, and service decompositions that organize solution elements into coherent structural units.
General	Role	RO		Represents the individuals, roles, personas, or entities that interact with or have a stake in the solution.	User roles, system roles, stakeholders, actors, system actors, personas, oversight authorities, and individuals or entities with specific needs, responsibilities with the solution.
General	Task	TK		Represents discrete activities, process steps, decisions, and work units performed by humans or automated systems within the solution.	Discrete activities, planning tasks, work units, decisions supported by AI, business processes, process steps, automated tasks, and human tasks within the solution workflow.
General	Input	IN		Represents the data, signals, queries, and information consumed by the solution.	User inputs (prompt and query or prompt package), data sources, signals, inference data, external feeds, batch data, streaming data, and any information consumed by the solution.
General	Output	OU		Represents the results, recommendations, and responses produced by the solution.	Generated artifacts, predictions, recommendations, confirmations, decisions, reports, notifications, feedback to users, and results produced by the solution.
General	Note	NT		Represents commentary, annotation, or interpretive explanation of the architecture.	Clarifying comments on complex interactions, interpretive notes, and contextual explanations added to views for enhanced communication.

Usage Notes

• As an agile element set, naming may be adapted to reflect solution-specific needs. Assistive or instance-specific naming (e.g., RQ-NFR for non-functional requirements, ZN for zone as a group/domain element) is permitted but should be used sparingly, with each assistive element explicitly mapped to its corresponding base element in this table.

• For connection relationships, only association and flow link types are used, where flow represents directionality, triggering, access, serving, dependency, and influence relationships, in the interest of simplicity and consistency. Composition relationships can be represented using the Grouping element or through labeled relationship links.

• A Bot may be classified as either an AI Agent or an Autonomous Tool depending on its architectural role and decision-making scope. For example, a conversational bot with reasoning autonomy is generally an AI Agent; a rule-based, deterministic bot is generally an Autonomous Tool.

• ASA is based on the ESA specification, extended with AI-specific elements, but uses only a subset of the foundational ESA elements for simplicity. The excluded ESA elements can be represented through alternative elements or relationship links. For example:

  • Constraint (e.g., problem, issue, risk, assumption) is represented as part of the Requirement element, or within the Governance element (e.g., compliance constraints).

  • Message & Event are represented through the Interface Contract element, or indicated via labeled relationship links.

  • System can be represented by either the Interface Contract or Application element, depending on context.

  • Granularity-related elements such as Domain and Viewframe (drill-down construct) are represented using the Grouping element.

  • Solution management or software design elements such as Deliverable and Artifact are represented using Output or Note elements. 

  • Physical equipment and Robotic Systems are not core ASA elements. When relevant, they should be represented as System Device elements or external system actors.

  • Infrastructure concerns such as networks and storage topology are not core ASA elements, as they are peripheral to solution-level architecture. Network and Location elements are part of the broader ESA specification but are excluded from ASA scope.