AI Software Meta-Model

The Product Definition & Context layer defines what the product is, where its boundaries are, and in what environment it exists.

The Aeilus Value Streams layer defines how value is created, transformed, transferred, accumulated, degraded, lost, or destroyed within and around the product.

The Stakeholders and Motivation layer defines who cares about the product and why.

The Business Architecture layer defines how the product is structured from a business perspective.

The Critical Path layer defines the minimal sequence of steps required to deliver the core value of the product including how this path behaves under failure conditions.

The Product Economics (P&L) layer defines how the product generates revenue, incurs costs, and produces financial outcomes.

The Subject Domains and Domain Knowledge layer describes the real-world problem domains the product automates, independent of how the system is built.

The Business Hypotheses layer defines structured, testable assumptions about the product, market, users, value, behavior, and economics.

The Strategy and Product Management layer defines how validated knowledge is transformed into controlled product evolution.

The Processes layer defines how the product operates through real executable workflows.

The Outcomes and Hypothesis Validation layer closes the loop between what we intended and what actually happened at the level of value and business goals.

The Applications and System Architecture layer defines how the product is decomposed into systems, applications, and components — and how responsibilities from business layers are mapped into executable system structure.

The Data and Information Architecture layer defines how information is structured, owned, transformed, and flows across the system.

The API and Interfaces layer defines how system capabilities are exposed as formal interaction contracts between components.

The Integrations layer defines how systems are actually connected and communicate in real-world environments.

Model external systems as first-class entities with contracts, SLAs, and breaking-change monitoring.

Model event-driven architecture with a first-class event catalog, producers, consumers, and contracts.

Model strategic DDD: bounded contexts, subdomains, context maps, and anti-corruption layers.

The Technology Architecture layer defines the technological foundation, constraints, and runtime context used to implement the system.

The Code and Implementation layer defines how the system is realized in actual source code and logical implementation structure.

The Build, Deployment and Runtime Artifacts layer defines how code is transformed into runnable artifacts and how those artifacts are delivered into execution environments.

Model the full dependency graph, SBOM, license inventory, and supply chain provenance for build reproducibility.

Model configuration, feature flags, and environment variants as a separate surface from code.

The Requirements layer defines what the system must do and under which conditions it is considered correct.

The Domain Model and Business Rules layer defines the core logic of the product domain — what entities exist, how they behave, and which rules must always hold.

The Access Rights layer defines who is allowed to perform which actions under which conditions.

The NFR (Non-Functional Requirements) and Quality Attributes layer defines how well the system must perform its behavior.

Model explicit state machines and entity lifecycles for safe AI-assisted behavior modification.

Model formal behavioral contracts (pre/postconditions, invariants) for AI-safe behavior reasoning.

Model the complete error taxonomy and failure behavior for the product.

The User Scenarios and UX Logic layer defines how users interact with the system to achieve their goals.

The Interface Structure and Navigation layer defines how the user interface is organized and how users move through it.

The Screens, Forms and UI States layer defines what the user actually sees and how the interface reacts.

Model the design system, component library, tokens, and themes for AI-assisted UI development.

Model accessibility requirements, localization rules, and outbound notification contracts.

The Runtime Environment and Topology layer defines how the system exists and operates in real environments.

The Observability and Monitoring layer defines how the system is observed, measured, and understood in runtime.

The Incident Management and Response layer defines how the system and organization detect, classify, respond to, and learn from incidents.

The SLA, SLO and Operational Governance layer defines how system quality, reliability, and risks are governed in runtime.

Model capacity planning, scaling rules, and performance baselines for runtime operations.

Model disaster recovery, backup policies, RPO/RTO, and continuity scenarios.

Model production readiness reviews, game days, chaos experiments, and DR drills.

The Quality Assurance and Testing layer defines how the product quality is verified, validated, and controlled before and during release cycles.

The Risk Management layer defines how risks are identified, analyzed, mitigated, and controlled across the product and system.

The Security and Privacy layer defines how the system protects assets, data, and users from threats, and ensures proper handling of sensitive information.

The Compliance and Audit layer defines how the system demonstrates conformity to internal policies, external regulations, and contractual obligations.

Model threat models, attack surfaces, attack trees, and trust boundaries.

Model vulnerability lifecycle, CVE tracking, patch plans, and responsible disclosure.

Model DPIA records, data subject rights, consent scopes, and deletion requests.

The Work Items and Change Requests layer defines how changes are initiated, described, justified, and tracked.

The Planning and Delivery Flow layer defines how work items move through time, resources, and delivery processes.

The Testing and Acceptance Execution layer defines how testing is actually executed for specific changes and how acceptance decisions are made.

The Release, Version and Rollout Management layer defines how validated changes are packaged, versioned, released, and safely rolled out into runtime.

The Change History and Decision Log layer defines how the evolution of the product is recorded, explained, and made understandable over time.

The Knowledge Retention and History Compaction layer defines how SDLC history is preserved, prioritized, compressed, and transformed into long-term knowledge based on importance, not time.

This layer defines how product and system feedback becomes structured change and knowledge.

This layer models the CI/CD pipeline as an executable SDLC entity.

Large system changes are not always normal work items or releases. Migrations, data backfills, and long-running refactors require separate lifecycle modeling because they:

The Retrospectives and Process Effectiveness layer evaluates how well the way we worked served the goal — the quality of the process, decisions, and approach used to deliver an initiative.

The Knowledge Index and Navigation layer defines how knowledge within AISMM is organized, indexed, and made discoverable for humans and AI agents.

The Traceability Graph layer defines a unified weighted graph of relationships across all AISMM entities, enabling end-to-end traceability, impact analysis, and reasoning.

The Source Provenance and Confidence layer defines where knowledge comes from and how much it can be trusted.

The Context Coverage and Consistency layer defines how complete, up-to-date, and internally consistent the AISMM knowledge base is.

The Context Retrieval and RAG layer defines how AISMM knowledge is prepared, retrieved, ranked, assembled, and delivered as context for humans and AI agents.

Define the common vocabulary, ontology concepts, relationship types, and graph semantics used across AISMM.

The Ingestion Bindings and Extraction Recipes layer defines how records in each layer are populated by agents from the systems that own the data.

Model data products as owned, versioned, reusable assets with explicit contracts and SLAs.

Track how data moves, transforms, and changes schema over time.

Model ML features, embeddings, and vector indexes — how they are created, refreshed, invalidated, and served.

Track AI/ML models as versioned artifacts with model cards, inference endpoints, and promotion history.

Model training runs, evaluation runs, experiments, and golden datasets.

Detect and respond to data and model drift with explicit signals, checks, and retraining triggers.

Manage human or automated labeling tasks, annotations, and ground truth datasets.

Measure the quality and reliability of data with quality rules, metrics, and observability signals.

Define team structures, roles, collaboration modes, and responsibility assignments (RACI) across the organization.

Map ownership of all AISMM entities to teams and individuals. Every component, service, and data product must have a declared owner.

Define who has authority to make which decisions, what requires approval, and how governance bodies operate.

Track skills, competencies, and gaps across the organization to support planning, hiring, and risk management.

Model vendor relationships, external responsibilities, and support contracts — connecting external parties to AISMM entities.

Track team capacity, allocation, load, reservations, and forecasts to support delivery planning and risk management.

Model cost allocation and showback as first-class AISMM entities for technical financial observability.

Model capacity and commitment management as first-class AISMM entities for technical financial observability.

Model token and inference economics as first-class AISMM entities for technical financial observability.

Model cost of quality and incident as first-class AISMM entities for technical financial observability.

Model unit economics by service, tenant and request as first-class AISMM entities for technical financial observability.

Model carbon and sustainability accounting as first-class AISMM entities for technical financial observability.