info-tech-canon/infospace/models/landscape/InfoTechCanonLandscapeModel.md

---
owned_concepts:
  - SoftwareSystem
  - SoftwareComponent
  - BusinessService
  - ApplicationService
  - TechnicalService
  - RuntimeResource
  - Environment
  - Workload
  - LandscapeClaim
  - LandscapeEntity
  - LandscapeEvidence
  - LandscapeRelationship
  - LandscapeSource
  - LandscapeState
---

# InfoTechCanon Landscape Model

**Short Name:** `ITC-LAND`
**Former Working Name:** Canonical IT Landscape Model (CILM)
**Document Status:** Seed Standard Release Candidate 1
**Version:** RC1-seed
**Date:** 2026-05-22
**Repository Context:** `info-tech-canon`
**Document Type:** InfoTechCanon Domain Standard
**Intended Audience:** Enterprise architects, platform engineers, DevSecOps teams, network architects, security architects, service owners, CMDB/ITSM owners, knowledge-system builders, standards authors, and agentic tooling.

---

# 1. Purpose

The **InfoTechCanon Landscape Model** defines a canonical seed model for representing information-technology landscapes across services, software systems, delivery pipelines, runtime environments, infrastructure, networking, security posture, observability, data, governance references, and operational evidence.

It is intended to be the first practical seed standard of the broader **InfoTechCanon** information space.

Its purpose is not to finish the complete canon. Its purpose is to provide a coherent starting point from which related standards, patterns, mappings, profiles, and assimilation workflows can grow.

This standard provides:

- a stable semantic spine for IT landscape knowledge,
- a first hierarchy of landscape concepts,
- clear concept-ownership boundaries,
- extraction seams for future standards,
- mapping hooks to external standards and products,
- seed pattern references,
- profile hooks for concrete implementations,
- and retrieval-friendly structure for humans, agents, and markdown-based infospaces.

---

# 2. Position in InfoTechCanon

The Landscape Model is a **domain standard** within InfoTechCanon.

It depends on the future `InfoTechCanonCore` for general canon mechanisms such as:

- concept ownership,
- artifact metadata,
- mappings,
- assimilation,
- profiles,
- patterns,
- provenance,
- versioning,
- conformance,
- and retrieval conventions.

Until `InfoTechCanonCore` is fully specified, this seed standard declares the assumptions it uses and marks concepts that should later be extracted into their proper owning standards.

```text
InfoTechCanon
├── InfoTechCanonCore
├── InfoTechCanonLandscapeModel     <-- this standard
├── InfoTechCanonOrganizationModel  <-- extraction candidate
├── InfoTechCanonGovernanceModel    <-- extraction candidate
├── InfoTechCanonSecurityModel      <-- extraction candidate
├── InfoTechCanonTaskModel          <-- related external/internal dependency
├── InfoTechCanonTaggingStandard    <-- related external/internal dependency
├── InfoTechCanonPatternLanguage
└── Application Profiles
```

---

# 3. Seed Standard Design Stance

This document deliberately acts as a **seed standard**, not a final domain closure.

A seed standard shall:

1. define enough canonical concepts to be useful immediately,
2. avoid pretending adjacent domains are already fully solved,
3. mark extraction candidates clearly,
4. define mapping and assimilation hooks,
5. remain readable as Markdown,
6. remain retrievable by agents,
7. provide examples and profiles,
8. and support future refactoring without semantic collapse.

The Landscape Model should therefore be read as:

```text
A first stable landscape spine
+ domain seeds
+ extraction seams
+ mapping hooks
+ pattern anchors
+ profile starting points
```

---

# 4. Scope

## 4.1 In Scope

This standard covers canonical representation of:

- IT landscapes,
- services and service relationships,
- software systems and solution components,
- source repositories and delivery pipelines,
- artifacts, deployments, and runtime resources,
- environments, platforms, clusters, workloads, compute, storage, and middleware,
- network domains, endpoints, segments, paths, flows, and policies,
- data objects and data stores as landscape-relevant entities,
- observability and operational signals,
- security posture as it relates to landscape entities,
- ownership and governance references,
- evidence and provenance for landscape claims,
- state distinctions between intended, declared, applied, observed, historical, and assessed reality,
- and external mappings to standards, products, frameworks, and regulations.

## 4.2 Out of Scope

This standard does not fully define:

- the general InfoTechCanon meta-model,
- organization theory,
- governance theory,
- project management,
- task management,
- canonical tagging,
- detailed access-control semantics,
- detailed legal or regulatory interpretation,
- complete security-control frameworks,
- complete observability semantic conventions,
- complete network configuration schemas,
- complete software architecture notation,
- or a mandatory database schema.

Those areas may be referenced, mapped, profiled, or marked as extraction candidates.

---

# 5. Normative Language

The following terms are used normatively:

- **SHALL** indicates a mandatory rule for conformance.
- **SHOULD** indicates a recommended practice.
- **MAY** indicates an optional capability.
- **MUST NOT** indicates a prohibited practice.
- **SEED** marks a concept that is defined provisionally here but may later move to another standard.
- **EXTRACT** marks a concept or section expected to be moved into another standard when mature.

---

# 6. Core Principles

## 6.1 Landscape as a Graph

An IT landscape SHALL be modeled as a graph of entities and relationships, not merely as a tree.

Hierarchies MAY be used for abstraction and navigation, but relationships SHALL remain first-class.

## 6.2 Concept Ownership

Every canonical concept SHOULD have a clear owning standard.

When the owning standard does not yet exist, this standard MAY temporarily define the concept as a seed concept and mark it as an extraction candidate.

## 6.3 Imported Concepts Are Not Redefined

This standard SHOULD import concepts from other InfoTechCanon standards once they exist.

It MUST NOT permanently redefine concepts that are clearly owned by another standard.

## 6.4 External Standards Are Mapped, Not Obeyed

The Landscape Model MAY map to external standards and products such as ArchiMate, CSDM, CIM, NetBox, Backstage, YANG, SPDX, CycloneDX, SLSA, OpenTelemetry, NIST, ITIL, or similar frameworks.

It MUST NOT subordinate its internal semantics to any single external standard.

## 6.5 Declared Reality Is Not Observed Reality

The model SHALL distinguish intended, declared, applied, observed, historical, and assessed state.

## 6.6 Evidence-Carrying Claims

Important landscape claims SHOULD carry source, confidence, time, and evidence metadata.

## 6.7 Profiles Make the Model Practical

Concrete implementation contexts SHOULD be expressed through application profiles.

Examples:

- Kubernetes landscape profile,
- GitHub / GitLab delivery profile,
- ServiceNow CSDM mapping profile,
- NetBox network source-of-truth profile,
- Backstage software catalog profile,
- small SaaS platform profile.

---

# 7. Canonical Architecture

The Landscape Model is organized into four layers:

```text
InfoTechCanonLandscapeModel
├── Landscape Core
├── Landscape Domains
├── Landscape Patterns
└── Landscape Profiles
```

## 7.1 Landscape Core

The Landscape Core defines concepts that are needed across all landscape domains:

```text
LandscapeEntity
LandscapeRelationship
LandscapeClaim
LandscapeState
LandscapeSource
LandscapeEvidence
LandscapeView
LandscapeProfile
```

## 7.2 Landscape Domains

Landscape domains define specialized landscape concepts.

Initial seed domains:

```text
Strategy and Capability
Service and Product
Software and Solution
DevSecOps Delivery
Runtime and Platform
Network
Data and Information
Security Posture
Observability and Operations
Physical and Facility
Organization Reference
Governance Reference
```

## 7.3 Landscape Patterns

Landscape patterns describe recurring ways to combine concepts.

Seed patterns include:

```text
Service Spine
Capability-to-Workload Trace
Commit-to-Runtime Trace
Declared-vs-Observed State
Source-of-Truth Boundary
Network Reachability Slice
Evidence-Carrying Finding
Landscape Impact Trace
Profile Not Fork
```

## 7.4 Landscape Profiles

Landscape profiles constrain the model for specific tools, platforms, domains, or use cases.

A profile SHALL declare:

- included concepts,
- required relationships,
- required metadata,
- external mappings,
- validation rules,
- source-of-truth assumptions,
- and known deviations.

---

# 8. Canonical Seed Metadata

Every canonical landscape artifact SHOULD support structured metadata.

Recommended front matter:

```yaml
---
id: itc-land:ApplicationService
type: concept
standard: InfoTechCanonLandscapeModel
standard_version: RC1-seed
status: candidate
canonical_owner: InfoTechCanonLandscapeModel
extraction_status: stable-in-landscape
preferred_label: Application Service
related:
  - itc-land:BusinessService
  - itc-land:RuntimeWorkload
mappings:
  - itc-map:application-service-to-csdm
---
```

Recommended artifact statuses:

```text
idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired
```

Recommended concept statuses:

```text
proposed
experimental
candidate
canonical
deprecated
retired
```

Recommended extraction statuses:

```text
stable-in-landscape
seed-owned-here
import-when-available
extract-to-organization
extract-to-governance
extract-to-security
extract-to-task
extract-to-tagging
extract-to-data
extract-to-observability
```

---

# 9. Landscape Core Concepts

## 9.1 LandscapeEntity

A **LandscapeEntity** is an identifiable thing relevant to understanding, operating, governing, securing, or changing an IT landscape.

Examples:

- business service,
- application service,
- software component,
- repository,
- artifact,
- workload,
- cluster,
- subnet,
- endpoint,
- vulnerability finding,
- metric,
- incident,
- owner reference.

Required attributes:

```yaml
id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
source_system:
created_at:
updated_at:
```

Recommended attributes:

```yaml
owner:
steward:
criticality:
classification:
source_confidence:
valid_from:
valid_to:
tags:
external_references:
```

## 9.2 LandscapeRelationship

A **LandscapeRelationship** is a typed, directional, evidence-aware connection between landscape entities.

Relationships SHALL be first-class records when used for integration, impact analysis, automation, security, or governance.

Required attributes:

```yaml
id:
relationship_type:
source_entity_id:
target_entity_id:
source_system:
created_at:
updated_at:
```

Recommended attributes:

```yaml
confidence:
criticality:
state_context:
valid_from:
valid_to:
evidence_ids:
attributes:
```

Root relationship types:

```text
composes
part_of
depends_on
realizes
serves
supports
uses
produces
consumes
deployed_to
deployed_as
hosted_on
connected_to
routes_to
exposes
protects
governs
observes
generates
affects
owned_by
operated_by
changed_by
evidenced_by
mapped_to
```

## 9.3 LandscapeClaim

A **LandscapeClaim** is an assertion about an entity, relationship, state, risk, mapping, or observation.

Claims are useful when the model needs to preserve uncertainty or conflicting sources.

Example:

```yaml
id: itc-claim:prod-api-depends-on-db
claim_type: relationship-claim
subject: itc-land:workload:prod-api
predicate: depends_on
object: itc-land:database:customer-db
state_context: observed
source_system: opentelemetry
confidence: 0.84
evidence:
  - itc-evidence:trace-sample-2026-05-22
```

## 9.4 LandscapeSource

A **LandscapeSource** identifies the origin of a claim, entity, relationship, mapping, or observation.

Examples:

- ServiceNow,
- NetBox,
- Backstage,
- Kubernetes API,
- Git repository,
- Terraform state,
- CI/CD platform,
- SBOM repository,
- vulnerability scanner,
- OpenTelemetry backend,
- manual architecture decision record.

## 9.5 LandscapeEvidence

**LandscapeEvidence** is information used to support a claim.

Examples:

- discovery record,
- API response,
- scan result,
- deployment log,
- SBOM,
- attestation,
- trace sample,
- configuration file,
- architecture decision record,
- audit record.

## 9.6 LandscapeState

A **LandscapeState** describes the truth context in which an entity or relationship is asserted.

Required state contexts:

```text
intended
declared
applied
observed
historical
assessed
```

Meaning:

| State | Meaning |
|---|---|
| `intended` | Desired by strategy, architecture, policy, or design. |
| `declared` | Submitted to a source system or control plane. |
| `applied` | Accepted and acted on by a control plane. |
| `observed` | Discovered or measured in runtime reality. |
| `historical` | True or asserted at a known point in the past. |
| `assessed` | Inferred by analysis, risk evaluation, or compliance assessment. |

This distinction is mandatory for mature landscape modeling.

---

# 10. Root Landscape Taxonomy

The seed taxonomy is:

```text
LandscapeEntity
├── CapabilityEntity
├── ServiceEntity
├── SoftwareEntity
├── DeliveryEntity
├── RuntimeEntity
├── NetworkEntity
├── DataEntity
├── SecurityPostureEntity
├── ObservabilityEntity
├── PhysicalEntity
├── OrganizationReferenceEntity
└── GovernanceReferenceEntity
```

The taxonomy is intentionally not exhaustive. It is a starting point for growing the information space.

---

# 11. Domain: Strategy and Capability

**Ownership Status:** Seed concepts. Likely future extraction or alignment with strategy / organization / governance standards.

## 11.1 Purpose

The Strategy and Capability domain connects landscape entities to business direction, capabilities, value streams, constraints, and transformation initiatives.

## 11.2 Seed Concepts

```text
Goal
Driver
Constraint
Principle
BusinessCapability
ValueStream
Initiative
RoadmapItem
ArchitectureDecision
Transformation
```

## 11.3 Key Relationships

```text
BusinessCapability realized_by BusinessService
Initiative changes ApplicationService
ArchitectureDecision constrains SoftwareComponent
Constraint governs LandscapeEntity
Goal motivates Initiative
```

## 11.4 Extraction Notes

These concepts SHOULD eventually be reviewed against:

- organization theory,
- enterprise architecture practice,
- strategy modeling,
- ArchiMate motivation and strategy concepts,
- portfolio management,
- product management,
- and governance models.

A dedicated capability model now exists: **ITC-CAP**
(`model/capability`). Abstract ability — what a system must be able to do
— is owned there. `BusinessCapability` / `ProductCapability` in this
domain SHOULD resolve to references to ITC-CAP ids. This domain keeps
landscape-relevant strategy concepts (Goal, Driver, Initiative,
RoadmapItem, ValueStream). Capability as ability is no longer owned here.

ITC-CAP names *intended* requirement targets. This model still owns
services, technologies, runtime resources, and *observed* SLOs.

---

# 12. Domain: Service and Product

**Ownership Status:** Core landscape domain.

## 12.1 Purpose

The Service and Product domain provides the service spine that connects business meaning to software, runtime, operations, and risk.

## 12.2 Seed Concepts

```text
Service
BusinessService
ApplicationService
TechnicalService
ServiceOffering
ServiceInstance
ServiceLevelObjective
ServiceConsumer
ServiceProvider
SupportGroup
CatalogItem
Product
ProductCapability
```

## 12.3 Distinctions

```text
BusinessService
  A business-consumable capability delivered as a service.

ApplicationService
  A running or supportable application capability.

TechnicalService
  A reusable technical capability such as identity, logging, Kubernetes,
  networking, storage, database, or backup.

ServiceOffering
  A consumable package of a service with scope, SLA, cost, support model,
  and availability constraints.

ServiceInstance
  A concrete instance of a service in a specific environment, region,
  tenant, or customer context.
```

## 12.4 Key Relationships

```text
BusinessService served_by ApplicationService
ApplicationService supported_by TechnicalService
ServiceOffering offers Service
ServiceInstance instance_of Service
Service has_slo ServiceLevelObjective
Service consumed_by ServiceConsumer
Service operated_by SupportGroup
```

## 12.5 Canonical Rule

Service concepts MUST NOT be collapsed into a generic `Application` concept.

The model SHOULD distinguish:

```text
business-consumable service
application capability
technical capability
offering
instance
implementation component
runtime workload
```

---

# 13. Domain: Software and Solution

**Ownership Status:** Core landscape domain with future alignment to software architecture standards.

## 13.1 Purpose

The Software and Solution domain represents logical and design-time software structures.

## 13.2 Seed Concepts

```text
SoftwareSystem
Application
Solution
SoftwareComponent
DeployableComponent
Module
API
Endpoint
Interface
IntegrationFlow
EventType
MessageContract
DataObject
DataSchema
Dependency
Library
RuntimeConfiguration
```

## 13.3 Key Distinction

The Landscape Model SHALL distinguish:

```text
Logical software component
Deployable artifact
Deployment record
Runtime workload
Network endpoint
```

Example:

```text
Logical component: billing-api
Artifact: ghcr.io/org/billing-api@sha256:...
Deployment: billing-api v1.8.2 deployed to prod-eu
Runtime workload: Kubernetes Deployment/billing-api in cluster prod-1
Network endpoint: https://billing.example.com
```

## 13.4 Key Relationships

```text
SoftwareSystem composed_of SoftwareComponent
SoftwareComponent exposes API
SoftwareComponent consumes API
SoftwareComponent uses Library
SoftwareComponent produces EventType
SoftwareComponent reads DataObject
SoftwareComponent writes DataObject
DeployableComponent realizes SoftwareComponent
```

---

# 14. Domain: DevSecOps Delivery

**Ownership Status:** Core landscape domain with future alignment to DevSecOps / supply-chain standards.

## 14.1 Purpose

The DevSecOps Delivery domain connects source code, build systems, artifacts, security evidence, releases, deployments, and runtime reality.

## 14.2 Seed Concepts

```text
Repository
Branch
Commit
PullRequest
BuildDefinition
Pipeline
PipelineStage
PipelineJob
PipelineRun
Artifact
ArtifactVersion
ContainerImage
Package
IaCModule
HelmChart
SBOM
Provenance
Attestation
Signature
PolicyGate
ScanResult
Finding
DeploymentPlan
DeploymentRecord
Release
ChangeRequest
```

## 14.3 Key Relationships

```text
Commit produces ArtifactVersion
PipelineRun produces ArtifactVersion
ArtifactVersion described_by SBOM
ArtifactVersion attested_by Attestation
ArtifactVersion signed_by Signature
ScanResult generates Finding
Finding affects ArtifactVersion
Release includes ArtifactVersion
DeploymentRecord deploys ArtifactVersion
DeploymentRecord instantiates RuntimeWorkload
PolicyGate blocks PipelineRun
ChangeRequest authorizes DeploymentRecord
```

## 14.4 Canonical Rule

A deployment MUST be modeled as a historical event or record, not merely as the current state of a workload.

A runtime workload may currently run an artifact, but the deployment record explains how it got there.

---

# 15. Domain: Runtime and Platform

**Ownership Status:** Core landscape domain.

## 15.1 Purpose

The Runtime and Platform domain represents the environments where software and technical services operate.

## 15.2 Seed Concepts

```text
Environment
Tenant
Account
Subscription
Region
AvailabilityZone
RuntimePlatform
PlatformService
KubernetesCluster
Namespace
Node
Workload
Pod
Container
Function
VirtualMachine
BareMetalHost
OperatingSystem
Runtime
Middleware
DatabaseInstance
Queue
Cache
ObjectBucket
Volume
SecretReference
CertificateReference
```

## 15.3 Suggested Hierarchy

```text
Tenant / Account / Subscription
  └── Region
        └── Environment
              └── RuntimePlatform
                    └── Cluster / Host Group
                          └── Namespace / Segment
                                └── Workload
                                      └── Runtime Unit
```

## 15.4 Key Relationships

```text
RuntimePlatform hosts Workload
Workload runs ArtifactVersion
Workload part_of ApplicationService
Workload uses DatabaseInstance
Workload uses Queue
Workload exposes Endpoint
Workload emits ObservabilitySignal
Workload subject_to SecurityPolicy
```

---

# 16. Domain: Network

**Ownership Status:** Core landscape domain with future alignment to detailed network standards.

## 16.1 Purpose

The Network domain represents addressability, topology, routing, connectivity, exposure, reachability, and network policy.

## 16.2 Subdomains

```text
Network Inventory
Addressing
Topology
Routing and Connectivity
Policy and Intent
Flows and Paths
Exposure
```

## 16.3 Seed Concepts

```text
NetworkDomain
NetworkFabric
NetworkZone
NetworkSegment
Subnet
VLAN
VRF
NetworkDevice
Router
Switch
Firewall
Gateway
LoadBalancer
WAF
Interface
Port
Link
Circuit
Path
Endpoint
IPAddress
Prefix
DNSZone
DNSRecord
RouteTable
Route
Peering
NAT
NetworkPolicy
NetworkIntent
NetworkRule
SecurityGroup
ACL
FirewallPolicy
ServiceMeshPolicy
Flow
ObservedFlow
Exposure
```

## 16.4 Required Distinctions

The model SHALL distinguish:

```text
Intent
Policy
Configuration
State
Flow
Path
Exposure
```

Definitions:

```text
Intent
  Desired network outcome in business or technical language.

Policy
  Formal rule expressing allowed, denied, required, or constrained behavior.

Configuration
  Concrete device, platform, or service setting.

State
  Observed or applied network reality.

Flow
  Actual or modeled traffic relation.

Path
  Realized or modeled route across topology.

Exposure
  A reachable surface presented to consumers or attackers.
```

## 16.5 Key Relationships

```text
Endpoint assigned_ip IPAddress
IPAddress part_of Prefix
Prefix belongs_to NetworkSegment
NetworkSegment part_of NetworkDomain
Device has Interface
Interface connected_to Interface
Workload exposes Endpoint
Endpoint reachable_via Path
Policy permits Flow
Policy denies Flow
Intent realized_by Policy
Policy realized_by Configuration
Configuration applied_to Device
ObservedFlow violates Policy
Exposure affects Service
```

---

# 17. Domain: Data and Information

**Ownership Status:** Seed domain. Likely future extraction into `InfoTechCanonDataModel`.

## 17.1 Purpose

The Data and Information domain represents data objects, datasets, schemas, classification, residency, lineage, and retention as landscape-relevant concerns.

## 17.2 Seed Concepts

```text
DataDomain
DataProduct
Dataset
DataObject
Schema
Field
DataStore
DataClassification
DataResidency
RetentionRule
DataFlow
DataLineage
ProcessingPurpose
DataOwner
```

## 17.3 Key Relationships

```text
ApplicationService processes Dataset
Dataset classified_as DataClassification
Dataset stored_in DataStore
DataFlow moves Dataset
DataLineage derived_from Dataset
RetentionRule applies_to Dataset
Control applies_to Dataset
```

## 17.4 Extraction Notes

This domain should later align with:

- data architecture,
- data governance,
- privacy,
- data lineage,
- AI readiness,
- data product thinking,
- and compliance requirements.

---

# 18. Domain: Security Posture

**Ownership Status:** Seed domain. Likely future extraction into `InfoTechCanonSecurityModel` and `InfoTechCanonAccessControlModel`.

## 18.1 Purpose

The Security Posture domain represents the landscape-visible security condition of systems, artifacts, identities, policies, secrets, certificates, vulnerabilities, controls, and risks.

## 18.2 Seed Concepts

```text
Identity
Principal
HumanUser
ServiceAccount
WorkloadIdentity
Group
Role
Permission
Entitlement
SecurityPolicy
Control
Secret
Key
Certificate
Vulnerability
Weakness
Misconfiguration
Finding
Threat
AttackPath
Risk
Mitigation
Exception
Evidence
AuditEvent
```

## 18.3 Key Relationships

```text
Principal has Role
Role grants Permission
Permission applies_to Resource
Secret used_by Workload
Certificate protects Endpoint
Finding affects LandscapeEntity
Risk aggregates Finding
Control mitigates Risk
Evidence supports Control
Exception waives Control
AttackPath traverses LandscapeEntity
```

## 18.4 Extraction Notes

The Landscape Model should retain security posture references but should not become the owner of detailed access-control theory, policy theory, or security-control frameworks.

Those belong in dedicated standards.

---

# 19. Domain: Observability and Operations

**Ownership Status:** Seed domain. Likely future extraction or alignment with observability and IT operations standards.

## 19.1 Purpose

The Observability and Operations domain connects runtime and service reality to telemetry, incidents, changes, health, and operational response.

## 19.2 Seed Concepts

```text
Metric
LogStream
Trace
Span
Event
Alert
SLO
SLI
Incident
Problem
Change
Runbook
HealthSignal
ErrorBudget
Dashboard
Observation
OperationalState
```

## 19.3 Key Relationships

```text
Workload emits Metric
Endpoint emits Trace
Alert triggered_by HealthSignal
Incident affects Service
Change changes LandscapeEntity
Runbook resolves IncidentType
SLO applies_to ServiceOffering
Observation supports LandscapeClaim
```

## 19.4 Canonical Rule

Observability data SHOULD be linked to landscape entities through stable identifiers wherever possible.

Telemetry that cannot be attached to a landscape entity remains operationally useful but has limited canonical landscape value.

---

# 20. Domain: Physical and Facility

**Ownership Status:** Optional core landscape domain depending on deployment context.

## 20.1 Purpose

The Physical and Facility domain represents physical infrastructure where relevant.

## 20.2 Seed Concepts

```text
Site
Building
Room
Rack
RackUnit
PhysicalDevice
Cable
PatchPanel
PowerFeed
PDU
CoolingUnit
Sensor
```

## 20.3 Key Relationships

```text
PhysicalDevice installed_in Rack
Rack located_in Room
Cable connects Port
PowerFeed supplies Device
Sensor observes FacilityCondition
```

---

# 21. Organization Reference Domain

**Ownership Status:** Extraction candidate for `InfoTechCanonOrganizationModel`.

## 21.1 Purpose

The Landscape Model needs to reference organizational responsibility without becoming a full organization model.

## 21.2 Seed Concepts

```text
Organization
OrganizationalUnit
Team
Person
Role
Responsibility
Ownership
Stewardship
```

## 21.3 Landscape Usage

These concepts are used to express:

```text
Service owned_by Team
Workload operated_by Team
Dataset stewarded_by Person
Control accountable_to Role
Incident assigned_to Team
```

## 21.4 Extraction Rule

When `InfoTechCanonOrganizationModel` exists, these concepts SHOULD be imported from it.

The Landscape Model should then keep only landscape-specific relationship guidance.

---

# 22. Governance Reference Domain

**Ownership Status:** Extraction candidate for `InfoTechCanonGovernanceModel`.

## 22.1 Purpose

The Landscape Model needs to reference governance constraints, risks, evidence, policies, and decisions without becoming a complete governance standard.

## 22.2 Seed Concepts

```text
Policy
Standard
ControlObjective
Control
Risk
Exception
Decision
Evidence
Audit
ComplianceRequirement
```

## 22.3 Landscape Usage

These concepts are used to express:

```text
Policy governs Service
Control applies_to Workload
Risk affects BusinessService
Evidence supports Finding
Decision constrains Architecture
Exception waives Control
```

## 22.4 Extraction Rule

When `InfoTechCanonGovernanceModel` exists, these concepts SHOULD be imported from it.

The Landscape Model should then own only the landscape-specific usage patterns.

---

# 23. Mapping Model for the Landscape Standard

Mappings relate InfoTechCanon landscape concepts to external standards, frameworks, products, and regulations.

## 23.1 Mapping Types

Recommended mapping types:

```text
exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference
```

## 23.2 Mapping Record

Example:

```yaml
id: itc-map:application-service-to-csdm-application-service
source_concept: itc-land:ApplicationService
target_body: ServiceNow CSDM
target_version: "5.x"
target_concept: Application Service
mapping_type: closeMatch
scope:
  - service-centric operational modeling
not_valid_for:
  - software source-code module boundaries
  - deployment artifact identity
rationale: >
  Both concepts represent a supportable application capability, but external
  implementations may vary in how they distinguish services, instances,
  offerings, and technical components.
confidence: medium
status: candidate
owner: InfoTechCanonLandscapeModel
```

## 23.3 Seed Mapping Targets

The Landscape Model SHOULD maintain mapping folders for:

```text
ArchiMate
ServiceNow CSDM
DMTF CIM
NetBox
Backstage Software Catalog
Kubernetes API
OpenTelemetry
SPDX
CycloneDX
SLSA
YANG / IETF topology models
NIST CSF
ITIL
COBIT
Cloud provider asset models
```

## 23.4 Mapping Rule

Mappings are adapters, not foundations.

External standards may influence InfoTechCanon through assimilation, but they do not directly define internal semantics.

---

# 24. Assimilation Hooks

The Landscape Model SHALL be able to receive new bodies of knowledge through the InfoTechCanon assimilation process.

## 24.1 Assimilation Triggers

Assimilation may be triggered by:

```text
new external standard
new regulation
new product data model
new internal project model
new repository schema
new operational practice
new integration conflict
new recurring ambiguity
```

## 24.2 Landscape Assimilation Output

A landscape assimilation SHOULD produce:

```text
source summary
extracted landscape concepts
concept comparison matrix
gap list
conflict list
mapping file
candidate new concepts
candidate relationship changes
candidate pattern changes
candidate profile changes
open questions
```

## 24.3 Assimilation Example

```text
Assimilate: Backstage Software Catalog

Expected outputs:
- mapping from Component/API/Resource/System to landscape software/service concepts
- gap analysis for ownership and lifecycle metadata
- profile proposal for Backstage catalog ingestion
- warnings about where Backstage semantics should not be treated as full runtime truth
```

---

# 25. Landscape Patterns

Patterns describe recurring combinations of landscape concepts.

## 25.1 Pattern: Service Spine

**Context:** An organization needs to connect business value to technical implementation.

**Problem:** Systems are modeled as isolated applications, infrastructure, or projects, making impact analysis difficult.

**Solution:** Use `BusinessService`, `ApplicationService`, `TechnicalService`, `ServiceOffering`, and `ServiceInstance` as a service spine connecting business, software, runtime, operations, and risk.

**Used Concepts:**

```text
BusinessService
ApplicationService
TechnicalService
ServiceOffering
ServiceInstance
RuntimeWorkload
SLO
Incident
Risk
```

## 25.2 Pattern: Commit-to-Runtime Trace

**Context:** A deployed workload must be traceable to source code and supply-chain evidence.

**Problem:** Runtime systems often cannot answer which source revision, build, artifact, scan, and approval produced a running workload.

**Solution:** Model the chain:

```text
Commit
  -> PipelineRun
  -> ArtifactVersion
  -> SBOM / Attestation / ScanResult
  -> Release
  -> DeploymentRecord
  -> RuntimeWorkload
```

## 25.3 Pattern: Declared-vs-Observed State

**Context:** Configuration and runtime reality diverge.

**Problem:** Treating declared state as truth hides drift, failed deployment, shadow infrastructure, and exposure.

**Solution:** Model intended, declared, applied, observed, historical, and assessed state separately.

## 25.4 Pattern: Source-of-Truth Boundary

**Context:** Multiple systems claim authority over overlapping landscape entities.

**Problem:** Duplicate authority causes conflicting data and integration fragility.

**Solution:** Declare source-of-truth boundaries per concept, relationship, and state context.

Example:

```text
NetBox owns intended network inventory.
Kubernetes owns observed workload state.
Git owns declared deployment manifests.
OpenTelemetry owns observed trace relations.
ServiceNow owns service support ownership.
```

## 25.5 Pattern: Profile Not Fork

**Context:** A use case needs a constrained model.

**Problem:** Teams fork the standard and create incompatible variants.

**Solution:** Create an application profile that constrains the standard without redefining its concepts.

---

# 26. Landscape Profiles

## 26.1 Profile Format

A Landscape Profile SHALL declare:

```yaml
id:
profile_name:
status:
implements:
  - InfoTechCanonLandscapeModel
target_context:
included_concepts:
required_relationships:
required_metadata:
source_of_truth_rules:
mapping_files:
validation_rules:
examples:
known_deviations:
```

## 26.2 Seed Profile: Small SaaS Landscape Profile

Purpose:

```text
Provide a minimal profile for a small SaaS platform moving toward production readiness.
```

Included concepts:

```text
BusinessService
ApplicationService
TechnicalService
ServiceOffering
SoftwareComponent
Repository
Pipeline
ArtifactVersion
DeploymentRecord
Environment
RuntimePlatform
Workload
Endpoint
NetworkPolicy
Finding
Incident
Team
Policy
Evidence
```

Required relationships:

```text
BusinessService served_by ApplicationService
ApplicationService realized_by SoftwareComponent
SoftwareComponent built_from Repository
Pipeline produces ArtifactVersion
DeploymentRecord deploys ArtifactVersion
Workload runs ArtifactVersion
Workload exposes Endpoint
Finding affects Workload
Incident affects ApplicationService
ApplicationService owned_by Team
Policy governs ApplicationService
```

## 26.3 Seed Profile: Kubernetes Landscape Profile

Purpose:

```text
Map Kubernetes runtime objects into landscape concepts.
```

Example mappings:

```text
Cluster -> RuntimePlatform / KubernetesCluster
Namespace -> Namespace
Deployment -> Workload
ReplicaSet -> RuntimeController
Pod -> RuntimeUnit
Container -> Container
Service -> InternalEndpoint / ServiceEndpoint
Ingress -> ExternalExposure / Endpoint
NetworkPolicy -> NetworkPolicy
ConfigMap -> RuntimeConfiguration
Secret -> SecretReference
```

## 26.4 Seed Profile: Backstage Catalog Profile

Purpose:

```text
Map developer portal catalog concepts into landscape software and ownership concepts.
```

Example mappings:

```text
System -> SoftwareSystem
Component -> SoftwareComponent
API -> API
Resource -> RuntimeResource / DataStore / PlatformResource
Group -> Team
User -> Person
Owner -> Ownership reference
```

## 26.5 Seed Profile: NetBox Network Profile

Purpose:

```text
Map network source-of-truth concepts into the Network domain.
```

Example mappings:

```text
Site -> Site
Rack -> Rack
Device -> NetworkDevice / PhysicalDevice
Interface -> Interface
Cable -> Cable / Link
Prefix -> Prefix
IPAddress -> IPAddress
VLAN -> VLAN / NetworkSegment
VRF -> VRF
Circuit -> Circuit
```

---

# 27. Canon Interface Card Usage

Subsystems that implement or produce landscape knowledge SHOULD publish a Canon Interface Card.

Example:

```yaml
subsystem: landscape-importer-netbox
implements:
  - InfoTechCanonLandscapeModel
  - NetBoxNetworkProfile
produces:
  - NetworkDevice
  - Interface
  - Link
  - Prefix
  - IPAddress
  - VLAN
  - Site
consumes:
  - Team
  - Service
relations:
  - Interface connected_to Interface
  - IPAddress part_of Prefix
  - Device installed_in Site
source_of_truth:
  intended_network_inventory: NetBox
known_deviations:
  - does not model observed packet flows
```

Canon Interface Cards help subsystems snap into the broader information space.

---

# 28. Retrieval Requirements

The Landscape Model is designed for markdown-based infospaces.

## 28.1 Required Retrieval Properties

Every major section SHOULD provide:

- stable headings,
- stable concept names,
- examples,
- relationship lists,
- extraction notes,
- mapping hooks,
- and profile references.

## 28.2 Agent Brief

Each mature standard SHOULD include an `agent-brief.md` file with:

```text
purpose
scope
owned concepts
imported concepts
do / do not rules
core relationship patterns
minimal examples
common mistakes
profile list
mapping list
```

## 28.3 Indexes

The landscape information space SHOULD provide indexes by:

```text
concept
relationship
domain
profile
pattern
mapping target
source system
state context
status
extraction candidate
```

---

# 29. Conformance Levels

## 29.1 Reference-Conformant

A document or system is reference-conformant if it uses Landscape Model terminology consistently but does not implement structured metadata or validation rules.

## 29.2 Metadata-Conformant

A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types.

## 29.3 Graph-Conformant

A system is graph-conformant if it represents entities and relationships as queryable graph-like records.

## 29.4 Evidence-Conformant

A system is evidence-conformant if important claims include sources, confidence, timestamps, and evidence references.

## 29.5 Profile-Conformant

A system is profile-conformant if it implements a declared Landscape Profile and passes its validation rules.

## 29.6 Assimilation-Conformant

A system or repository is assimilation-conformant if it can accept external concept bodies through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes.

---

# 30. Validation Rules

Initial validation rules:

```text
VAL-LAND-001: Every LandscapeEntity SHOULD have an id, entity_type, canonical_name, lifecycle_state, and source_system.

VAL-LAND-002: Every LandscapeRelationship SHOULD have a relationship_type, source entity, target entity, and source_system.

VAL-LAND-003: Relationship types SHOULD come from the canonical relationship vocabulary or a declared profile extension.

VAL-LAND-004: Every imported external concept SHOULD be represented through a mapping record, not by silently reusing external terminology.

VAL-LAND-005: Concepts marked as extraction candidates SHOULD identify the likely future owning standard.

VAL-LAND-006: A profile MUST NOT redefine a canonical concept. It may constrain it.

VAL-LAND-007: Declared state and observed state MUST NOT be collapsed in mature landscape implementations.

VAL-LAND-008: Every non-trivial mapping SHOULD include scope, target version, mapping type, rationale, and confidence.

VAL-LAND-009: Service, software component, artifact, deployment, workload, and endpoint SHOULD be modeled as distinct concepts.

VAL-LAND-010: Source-of-truth assumptions SHOULD be explicit for every profile.
```

---

# 31. Anti-Patterns

## 31.1 One Giant CMDB

Trying to model every detail in a single central database without profiles, ownership, provenance, or source boundaries.

## 31.2 Application Means Everything

Using `Application` to mean product, service, codebase, deployment, runtime workload, and business capability at the same time.

## 31.3 Declared State as Truth

Assuming Terraform, Kubernetes manifests, network configuration, or CMDB records are reality.

## 31.4 External Standard Subordination

Bending the internal model to fit one external standard so tightly that future improvement becomes difficult.

## 31.5 Profile Forking

Creating local variants of the standard instead of declared application profiles.

## 31.6 Invisible Ownership

Modeling services and systems without accountable owners, stewards, or operators.

## 31.7 Relationship as Comment

Storing critical dependencies as free-text notes instead of first-class relationships.

---

# 32. Initial Repository Placement

Recommended repository layout:

```text
info-tech-canon/
  standards/
    landscape/
      InfoTechCanonLandscapeModel.md
      agent-brief.md
      concepts/
      relationships/
      patterns/
      profiles/
      mappings/
      assimilation/
      examples/
      validation/
```

Seed files:

```text
standards/landscape/InfoTechCanonLandscapeModel.md
standards/landscape/agent-brief.md
standards/landscape/concepts/service.md
standards/landscape/concepts/software.md
standards/landscape/concepts/runtime.md
standards/landscape/concepts/network.md
standards/landscape/patterns/service-spine.md
standards/landscape/patterns/commit-to-runtime-trace.md
standards/landscape/profiles/small-saas-landscape-profile.md
standards/landscape/profiles/kubernetes-landscape-profile.md
standards/landscape/mappings/csdm.yaml
standards/landscape/mappings/backstage.yaml
standards/landscape/mappings/netbox.yaml
```

---

# 33. Roadmap

## Phase 1: Seed Stabilization

- Rename CILM to `InfoTechCanonLandscapeModel`.
- Mark concept ownership and extraction seams.
- Add mapping, profile, pattern, and assimilation sections.
- Define seed profiles.
- Define validation rules.

## Phase 2: Core Extraction

- Create `InfoTechCanonCore`.
- Move generic concepts such as Concept, Mapping, Pattern, Profile, Provenance, Versioning, and Conformance into Core.
- Adjust Landscape Model to import them.

## Phase 3: Organization and Governance Extraction

- Create `InfoTechCanonOrganizationModel`.
- Create `InfoTechCanonGovernanceModel`.
- Move organization and governance seed concepts to their own standards.
- Keep landscape-specific usage guidance.

## Phase 4: First Assimilations

Recommended first assimilation candidates:

```text
ServiceNow CSDM
Backstage Software Catalog
NetBox
Kubernetes API
NIST CSF
SPDX / CycloneDX
```

## Phase 5: Tooling Integration

- Generate concept indexes.
- Generate agent briefs.
- Generate machine-readable YAML/JSON exports.
- Add validation scripts.
- Integrate with markdown infobase tooling.
- Use in real subsystem Canon Interface Cards.

---

# 34. Summary

The InfoTechCanon Landscape Model is the first seed standard for growing the InfoTechCanon information space.

It provides a practical canonical spine for IT landscapes while deliberately exposing seams for future standards, mappings, profiles, patterns, and assimilation workflows.

Its most important commitments are:

```text
Model services, software, delivery, runtime, network, security posture,
observability, and evidence as connected landscape knowledge.

Keep concepts externally mappable but internally autonomous.

Use profiles instead of forks.

Treat declared and observed reality separately.

Make landscape knowledge retrievable by humans, agents, and tools.

Grow the canon through assimilation rather than blind adoption.
```

This makes the Landscape Model not only a data model, but a seed crystal for a larger, evolving, interoperable InfoTechCanon.