# 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. 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 ```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.