Service

Services exist as running processes that engineers know about from memory. There is no service catalog, no architecture diagram, and no written record of what services exist or who owns them. 'What depends on the auth service?' gets answered by whoever has been around longest. New engineers discover services by stumbling into production issues.

None — AI cannot map dependencies, predict failures, or reason about service health because no service definitions exist in any system.

A wiki page or spreadsheet lists known services, but it was last updated six months ago. Some services have owners listed; others say 'TBD.' Dependency information is scattered across README files, Slack threads, and tribal knowledge. The service registry is a starting point for discovery but cannot be trusted as a source of truth — 'is this list even current?' is a common question.

AI can read the service list but cannot reliably map the architecture because the registry is stale, incomplete, and disconnected from the actual running infrastructure.

Services are registered in a catalog tool like Backstage or a structured Confluence space with consistent fields — owner team, repository, dependencies, health check URL, and deployment pipeline. Engineers can look up any service and find its basics. But the catalog entries are manually maintained, so they drift from reality. Dependency lists miss recently added connections, and ownership changes lag behind team reorgs.

AI can navigate the service catalog and answer basic 'who owns this?' and 'what are its dependencies?' questions. Cannot perform accurate impact analysis because the manually maintained dependency graph has gaps and stale entries.

The service catalog is current and comprehensive. Dependency graphs are pulled from deployment manifests and service mesh configurations. Every service has documented SLOs, ownership, runbooks, and architecture decision records. An engineer can query 'show me all services that depend on the payment gateway, their owners, and their current health status' and get an accurate, real-time answer.

AI can perform dependency impact analysis, predict blast radius for outages, and recommend incident response paths based on the service graph. Cannot yet autonomously evolve the architecture because service boundary decisions require human strategic judgment.

Services are formal entities in a platform architecture ontology. Each service has typed relationships to its APIs, data stores, upstream and downstream dependencies, infrastructure resources, and SLO definitions. An AI agent can ask 'generate a capacity plan for Black Friday that accounts for all transitive dependencies of the checkout service and their historical scaling patterns' and produce an architecturally valid plan.

AI can autonomously generate architecture proposals, capacity plans, and migration strategies within the formal service model. Can produce structurally valid recommendations for well-defined operational patterns. Human judgment is needed for novel architecture decisions and business trade-offs.

The service catalog is a self-documenting architecture model. Every deployment, configuration change, and infrastructure modification automatically updates the service graph. New services register themselves upon first deployment. Dependency relationships are discovered from actual traffic patterns and validated against declared dependencies. The catalog generates its own structural knowledge from the running platform.

Can autonomously maintain the complete service architecture model, detect undocumented dependencies from traffic analysis, and keep ownership and health status current in real-time without human catalog maintenance.

Ceiling of the CMC framework for this dimension.