info-tech-canon/seeds/InfoTechCanonLandscapeModel_RC1_seed.md

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.

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:

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:

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:

LandscapeEntity
LandscapeRelationship
LandscapeClaim
LandscapeState
LandscapeSource
LandscapeEvidence
LandscapeView
LandscapeProfile

7.2 Landscape Domains

Landscape domains define specialized landscape concepts.

Initial seed domains:

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:

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:

---
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:

idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired

Recommended concept statuses:

proposed
experimental
candidate
canonical
deprecated
retired

Recommended extraction statuses:

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:

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

Recommended attributes:

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:

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

Recommended attributes:

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

Root relationship types:

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:

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:

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:

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

Goal
Driver
Constraint
Principle
BusinessCapability
ValueStream
Initiative
RoadmapItem
ArchitectureDecision
Transformation

11.3 Key Relationships

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.

The Landscape Model should keep only landscape-relevant references once a dedicated strategy/capability standard exists.

---

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

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

12.3 Distinctions

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

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:

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

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:

Logical software component
Deployable artifact
Deployment record
Runtime workload
Network endpoint

Example:

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

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

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

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

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

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

15.4 Key Relationships

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

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

16.3 Seed Concepts

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:

Intent
Policy
Configuration
State
Flow
Path
Exposure

Definitions:

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

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

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

17.3 Key Relationships

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

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

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

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

19.3 Key Relationships

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

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

20.3 Key Relationships

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

Organization
OrganizationalUnit
Team
Person
Role
Responsibility
Ownership
Stewardship

21.3 Landscape Usage

These concepts are used to express:

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

Policy
Standard
ControlObjective
Control
Risk
Exception
Decision
Evidence
Audit
ComplianceRequirement

22.3 Landscape Usage

These concepts are used to express:

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:

exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference

23.2 Mapping Record

Example:

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:

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:

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:

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

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:

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:

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:

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:

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:

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

Included concepts:

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

Required relationships:

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:

Map Kubernetes runtime objects into landscape concepts.

Example mappings:

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:

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

Example mappings:

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:

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

Example mappings:

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:

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:

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:

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:

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:

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

Seed files:

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:

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:

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.