categories:
  - id: ai_infrastructure
    name: Layer 1 — AI Infrastructure
    short_name: L1 Infrastructure
    definition: >
      Physical and cloud substrate for AI: GPUs, accelerators, networking,
      datacenters, power, storage, and managed compute capacity.
    boundary_rule: >
      Place a vendor here when its primary role is supplying scarce compute,
      hardware, cloud capacity, or the physical systems that make AI workloads
      possible.
    buyer_question: >
      Where does the compute, power, and hardware capacity come from?
    control_points:
      - compute
      - power
      - networking
      - cloud_capacity
    responsibility_boundary: >
      Provider owns capacity, availability, hardware lifecycle, and physical
      resilience. Customer owns workload placement, demand forecasting, and
      utilization risk.
    leader_criteria:
      - Disclosed AI capex, accelerator share, or AI infrastructure revenue.
      - Demonstrated access to frontier accelerators or custom silicon.
      - Enterprise-grade availability, regional reach, and procurement path.
    visual_color_token: cyan-400

  - id: model_portfolio
    name: Layer 2 — Model Portfolio
    short_name: L2 Models
    definition: >
      Foundation, frontier, open-weight, specialist, and routed model portfolios
      that provide the intelligence primitives consumed by higher layers.
    boundary_rule: >
      Place a vendor here when model capability, model choice, model routing, or
      model governance is the primary product decision.
    buyer_question: >
      Which models should we use, for which workloads, at what cost and risk?
    control_points:
      - weights
      - benchmarks
      - token_pricing
      - model_policy
      - routing
    responsibility_boundary: >
      Model provider owns training, model behavior, release cadence, and safety
      defaults. Customer owns model selection, workload routing, evals, and
      fallback policy.
    leader_criteria:
      - Public frontier benchmark position or strong open-weight ecosystem.
      - Competitive cost, latency, context, modality, and reliability envelope.
      - Clear enterprise controls, model cards, and deployment posture.
    visual_color_token: orange-400

  - id: data_management
    name: Layer 3 — Data Management
    short_name: L3 Data Mgmt
    definition: >
      Raw systems of record, warehouses, lakehouses, operational databases, and
      document stores that hold enterprise data before it is shaped for AI use.
    boundary_rule: >
      Place a vendor here when the product primarily stores, governs, or manages
      source data that still needs processing, wrapping, indexing, or context
      compilation before an AI system can consume it directly.
    buyer_question: >
      Who owns the system of record, and how do we keep AI from being trapped inside SaaS silos?
    control_points:
      - source_data
      - governance
      - lineage
      - access_control
    responsibility_boundary: >
      Data platform owns storage, lineage, access control, and governance
      surfaces. Customer owns data quality, semantic modeling, and agent-access
      policy.
    leader_criteria:
      - Enterprise data gravity and governed access.
      - Strong integration with warehouses, lakehouses, documents, and systems of record.
      - Clear path to expose data safely to AI-ready layers and agents.
    visual_color_token: violet-400

  - id: ai_ready_data
    name: Layer 4 — AI-Ready Data
    short_name: L4 AI Data
    definition: >
      Processed, indexed, embedded, retrievable, policy-wrapped, and API-exposed
      data that can be consumed directly by models and agents.
    boundary_rule: >
      Place a vendor here when the product turns raw enterprise data into
      retrieval, context, embeddings, vector search, API access, or model-ready
      memory.
    buyer_question: >
      How do we make our data usable by AI without surrendering it to every SaaS vendor?
    control_points:
      - embeddings
      - vector_index
      - retrieval
      - api_gateway
      - context_layer
    responsibility_boundary: >
      AI-ready data provider owns retrieval quality, indexing, wrappers, and
      access surfaces. Customer owns source-data truth, freshness, permissions,
      and which agents may consume which context.
    leader_criteria:
      - Strong vector, embedding, retrieval, API, or context-management surface.
      - Evidence of production-scale freshness, permissions, and observability.
      - Ability to sit between SaaS-owned data and agent-owned execution.
    visual_color_token: emerald-400

  - id: developer_tools
    name: Layer 5 — Developer Tools
    short_name: L5 Dev Tools
    definition: >
      Build tools for humans and agents creating software: IDE copilots, coding
      agents, CLI agents, context management, orchestration, evals, and tool
      harnesses.
    boundary_rule: >
      Place a vendor here when the primary workflow is building, modifying,
      testing, or operating software with AI assistance.
    buyer_question: >
      Which tools turn developers into agent supervisors and software editors?
    control_points:
      - developer_workflow
      - context_management
      - orchestration
      - tool_harness
      - evals
    responsibility_boundary: >
      Tool provider owns coding UX, context packaging, model/tool invocation,
      and review affordances. Customer owns repository permissions, acceptance
      criteria, and production release governance.
    leader_criteria:
      - High developer adoption or paid seat growth.
      - Strong context management, tool execution, and review loop.
      - Evidence that the tool changes shipped software, not only chat usage.
    visual_color_token: amber-400

  - id: agent_tools
    name: Layer 6 — Agent Tools
    short_name: L6 Agents
    definition: >
      Agent runtimes and operational tools that run scheduled, triggered,
      multi-agent, tool-using, and exception-escalating work.
    boundary_rule: >
      Place a product here when the defining behavior is autonomous or
      semi-autonomous execution: agents talking to agents, invoking tools,
      maintaining memory, and paging humans on exception.
    buyer_question: >
      Which agent systems can we safely let act on our behalf?
    control_points:
      - tools
      - memory
      - permissions
      - task_execution
      - human_review
    responsibility_boundary: >
      Agent tool owns execution loop, tool-use guardrails, memory, logging, and
      escalation mechanics. Customer owns delegated authority, permissions,
      rollback, and exception policy.
    leader_criteria:
      - Demonstrated scheduled, triggered, or long-horizon tool use.
      - Human-in-the-loop controls and auditability.
      - Production integration with owned data, tools, and operational systems.
    visual_color_token: rose-400

  - id: commercial_tools
    name: Layer 7 — Commercial Tools
    short_name: L7 Commercial
    definition: >
      Finished point solutions and vertical AI tools: video, voice, legal,
      sales, research, support, writing, and other specialist business outcomes.
    boundary_rule: >
      Place a vendor here when buyers purchase a packaged business outcome, not
      a reusable model, data layer, developer tool, or agent runtime.
    buyer_question: >
      Which specialist tools survive when agents can work directly over our own data?
    control_points:
      - workflow_distribution
      - proprietary_context
      - seats
      - vertical_expertise
    responsibility_boundary: >
      Tool provider owns workflow UX, packaged domain behavior, and product
      controls. Customer owns data portability, agent access, workflow redesign,
      and whether point tools become durable or get absorbed by agent systems.
    leader_criteria:
      - Strong vertical adoption, retention, or enterprise spend.
      - Proprietary workflow context or domain-specific eval advantage.
      - Clear reason it is not just a feature inside a model provider or agent tool.
    visual_color_token: sky-400

control_points:
  compute: Scarce accelerator capacity and the systems that turn it into throughput.
  power: Energy availability, density, cooling, and site constraints.
  networking: Scale-up and scale-out fabric for training and serving clusters.
  cloud_capacity: Procured and managed AI compute capacity.
  source_data: Raw enterprise data in systems of record, warehouses, applications, documents, and logs.
  governance: Ownership, quality, retention, lineage, and semantic rules around source data.
  lineage: Evidence of where data came from and how it was transformed.
  access_control: Which users, services, models, and agents may read or mutate data.
  embeddings: Vector representations or other AI-consumable features derived from source data.
  vector_index: Searchable vector, hybrid, graph, or retrieval indexes.
  retrieval: Runtime retrieval and citation path that feeds model context.
  api_gateway: Controlled API surface that exposes data, tools, or model calls to agents.
  context_layer: Compiled, policy-wrapped, task-relevant context assembled for AI use.
  orchestration: Builder workflows that compose models, tools, data, and evaluation.
  evals: Evidence systems for quality, safety, reliability, and drift.
  developer_workflow: IDE, CI, deployment, and operational surfaces used by builders.
  context_management: Selection, compression, memory, and provenance of context used by developer agents.
  tool_harness: Safe invocation layer for shell, browser, code, MCP, APIs, and repo operations.
  weights: The model artifact, whether closed, gated, or open-weight.
  benchmarks: Public and private measures of model capability.
  token_pricing: The unit economics of using model intelligence.
  model_policy: Safety behavior, availability, data-handling, and release controls.
  routing: Selection, fallback, caching, and provider abstraction at inference time.
  workflow_distribution: Access to existing business process surfaces.
  proprietary_context: Product or enterprise context that improves output quality.
  seats: Paid or active user footprint.
  vertical_expertise: Domain-specific workflow knowledge, templates, evals, and compliance posture.
  tools: External systems an AI can call.
  memory: Persistent context, plans, preferences, and task state.
  permissions: Authority boundaries for reading, writing, and acting.
  task_execution: Completion of multi-step work, not only response generation.
  human_review: Escalation, approval, and exception handling around delegated work.
  policy: Rules for where AI may be used and what it may do.
  identity: User, agent, tool, and workload identity.
  audit: Evidence of prompts, responses, decisions, actions, and approvals.
  compliance: Certifications, controls, data residency, and regulated-workload posture.

shared_responsibility_controls:
  - id: accuracy
    label: Accuracy and fitness for task
  - id: data_exposure
    label: Data exposure and retention
  - id: action_safety
    label: Action safety and rollback
  - id: observability
    label: Logs, traces, evals, and cost visibility
  - id: compliance
    label: Compliance, residency, and audit evidence
  - id: human_review
    label: Human review and escalation
  - id: outcome_accountability
    label: Business outcome accountability
