From 1ed7198ce3c0eac1a04124f33e202dcac727acdf Mon Sep 17 00:00:00 2001 From: tegwick Date: Sat, 23 May 2026 00:55:01 +0200 Subject: [PATCH] Initial seeding of models, standards --- CODING_AGENT_BOOTSTRAP.md | 356 ++ INTENT.md | 108 + SCOPE.md | 241 + canon.yaml | 100 + ...nfoTechCanonAccessControlModel_RC1_seed.md | 2302 +++++++ ...TechCanonCaringAccessGovernanceStandard.md | 5413 +++++++++++++++++ seeds/InfoTechCanonCore_RC1_seed.md | 1982 ++++++ seeds/InfoTechCanonDataModel_RC1_seed.md | 2180 +++++++ seeds/InfoTechCanonDevSecOpsModel_RC1_seed.md | 2407 ++++++++ .../InfoTechCanonGovernanceModel_RC1_seed.md | 2181 +++++++ ...TechCanonInformationSpaceModel_RC1_seed.md | 2072 +++++++ seeds/InfoTechCanonKernelMap_RC1.md | 1565 +++++ seeds/InfoTechCanonLandscapeModel_RC1_seed.md | 1938 ++++++ seeds/InfoTechCanonNetworkModel_RC1_seed.md | 2433 ++++++++ ...nfoTechCanonObservabilityModel_RC1_seed.md | 2272 +++++++ ...InfoTechCanonOrganizationModel_RC1_seed.md | 1750 ++++++ seeds/InfoTechCanonSecurityModel_RC1_seed.md | 2234 +++++++ .../InfoTechCanonTaggingStandard_RC1_seed.md | 2037 +++++++ seeds/InfoTechCanonTaskModel_RC1_seed.md | 2100 +++++++ spec/RepositoryTreeManifest.md | 181 + spec/agent_global-agent-brief.md | 156 + spec/views_kernel-overview.md | 115 + spec/views_refactoring-checklist.md | 101 + wiki/ProductRequirementsDocument.md | 952 +++ 24 files changed, 37176 insertions(+) create mode 100755 CODING_AGENT_BOOTSTRAP.md create mode 100644 INTENT.md create mode 100644 SCOPE.md create mode 100644 canon.yaml create mode 100755 seeds/InfoTechCanonAccessControlModel_RC1_seed.md create mode 100755 seeds/InfoTechCanonCaringAccessGovernanceStandard.md create mode 100755 seeds/InfoTechCanonCore_RC1_seed.md create mode 100755 seeds/InfoTechCanonDataModel_RC1_seed.md create mode 100755 seeds/InfoTechCanonDevSecOpsModel_RC1_seed.md create mode 100755 seeds/InfoTechCanonGovernanceModel_RC1_seed.md create mode 100755 seeds/InfoTechCanonInformationSpaceModel_RC1_seed.md create mode 100755 seeds/InfoTechCanonKernelMap_RC1.md create mode 100755 seeds/InfoTechCanonLandscapeModel_RC1_seed.md create mode 100755 seeds/InfoTechCanonNetworkModel_RC1_seed.md create mode 100755 seeds/InfoTechCanonObservabilityModel_RC1_seed.md create mode 100755 seeds/InfoTechCanonOrganizationModel_RC1_seed.md create mode 100755 seeds/InfoTechCanonSecurityModel_RC1_seed.md create mode 100755 seeds/InfoTechCanonTaggingStandard_RC1_seed.md create mode 100755 seeds/InfoTechCanonTaskModel_RC1_seed.md create mode 100644 spec/RepositoryTreeManifest.md create mode 100644 spec/agent_global-agent-brief.md create mode 100644 spec/views_kernel-overview.md create mode 100644 spec/views_refactoring-checklist.md create mode 100644 wiki/ProductRequirementsDocument.md diff --git a/CODING_AGENT_BOOTSTRAP.md b/CODING_AGENT_BOOTSTRAP.md new file mode 100755 index 0000000..0e97d3f --- /dev/null +++ b/CODING_AGENT_BOOTSTRAP.md @@ -0,0 +1,356 @@ +# Coding Agent Bootstrap: info-tech-canon + +## Mission + +Establish the practical repository implementation for `info-tech-canon` based on the existing seed artifacts and the markdown-first infospace/tooling direction. + +The repository is intended to become the canonical markdown-first knowledge and standards space for InfoTechCanon. + +--- + +## Current Conceptual State + +The current InfoTechCanon structure distinguishes: + +```text +kernel/ + InfoTechCanonCore.md + InfoTechCanonKernelMap.md + +models/ + information-space/ + landscape/ + organization/ + governance/ + task/ + access-control/ + security/ + data/ + devsecops/ + network/ + observability/ + +standards/ + tagging/ + caring/ + +profiles/ +patterns/ +mappings/ +assimilation/ +schemas/ +views/ +agent/ +examples/ +validation/ +``` + +Core principle: + +```text +Kernel = how the canon works. +Models = broad domain structures. +Standards = cross-cutting conventions or named analytical/design frameworks. +Profiles = concrete implementation constraints. +Patterns = reusable practical solutions. +Mappings = alignment to external bodies of knowledge. +Assimilation = structured digestion of external knowledge. +``` + +--- + +## First Implementation Goal + +Create a clean repository scaffold that can host the existing Markdown seed documents and support future automation. + +Do not over-engineer. Start with file layout, manifests, validation stubs, and repeatable commands. + +--- + +## Expected First Commit + +Create or verify: + +```text +README.md +INTENT.md +SCOPE.md +canon.yaml + +kernel/ +models/ +standards/ +profiles/ +patterns/ +mappings/ +assimilation/ +schemas/ +views/ +agent/ +examples/ +validation/ +``` + +Add placeholder `README.md` files in empty directories so Git tracks structure. + +--- + +## File Placement Rules + +Use this placement: + +```text +kernel/InfoTechCanonCore.md +kernel/InfoTechCanonKernelMap.md + +models/information-space/InfoTechCanonInformationSpaceModel.md +models/landscape/InfoTechCanonLandscapeModel.md +models/organization/InfoTechCanonOrganizationModel.md +models/governance/InfoTechCanonGovernanceModel.md +models/task/InfoTechCanonTaskModel.md +models/access-control/InfoTechCanonAccessControlModel.md +models/security/InfoTechCanonSecurityModel.md +models/data/InfoTechCanonDataModel.md +models/devsecops/InfoTechCanonDevSecOpsModel.md +models/network/InfoTechCanonNetworkModel.md +models/observability/InfoTechCanonObservabilityModel.md + +standards/tagging/InfoTechCanonTaggingStandard.md +standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md +``` + +--- + +## Initial Automation Targets + +Create minimal scripts or Make targets for: + +```text +make validate +make index +make tree +make agent-briefs +``` + +Initial implementations may be simple stubs that check file existence and generate basic views. + +Recommended early scripts: + +```text +scripts/validate_structure.py +scripts/generate_views.py +scripts/check_links.py +scripts/extract_frontmatter.py +``` + +--- + +## Initial Schemas + +Start with lightweight YAML/JSON schemas for: + +```text +schemas/standard.schema.yaml +schemas/concept.schema.yaml +schemas/mapping.schema.yaml +schemas/profile.schema.yaml +schemas/assimilation.schema.yaml +schemas/interface-card.schema.yaml +schemas/agent-brief.schema.yaml +schemas/caring-access-descriptor.schema.yaml +``` + +Schemas may begin minimal. Prefer useful incremental validation over completeness. + +--- + +## Initial Generated Views + +Generate or maintain: + +```text +views/kernel-overview.md +views/by-standard.md +views/by-concept.md +views/by-profile.md +views/by-mapping-target.md +views/refactoring-checklist.md +``` + +Generated files should include a note: + +```text + +``` + +unless they are curated manually. + +--- + +## Important Guardrails + +Do not redefine domain concepts while implementing repository tooling. + +Do not collapse: + +```text +Organization Role +AccessRole +CARING Canonical Role +``` + +Do not collapse: + +```text +Actor +Subject +Principal +``` + +Do not collapse: + +```text +Policy +Control +Evidence +``` + +Do not collapse: + +```text +Dataset +DataStore +``` + +Do not collapse: + +```text +Artifact +Release +Deployment +Runtime State +``` + +Do not collapse: + +```text +Network Intent +Network Policy +Network Configuration +Observed Network State +``` + +Do not collapse: + +```text +Alert +Incident +``` + +Do not treat tags as substitutes for canonical fields, relationships, policies, or evidence. + +--- + +## CARING Placement + +CARING is a specialized standard, not just an Access Control profile. + +Use: + +```text +standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md +``` + +Namespace: + +```text +itc-caring +``` + +CARING should later get: + +```text +standards/caring/agent-brief.md +standards/caring/concepts/ +standards/caring/profiles/ +standards/caring/mappings/ +standards/caring/benchmarks/ +standards/caring/examples/ +standards/caring/validation/ +``` + +First CARING benchmark candidate: + +```text +Kubernetes RBAC +``` + +--- + +## Recommended First Task Sequence + +1. Create repository tree. +2. Add `INTENT.md`, `SCOPE.md`, and `canon.yaml`. +3. Place all seed Markdown files in the correct directories. +4. Add directory-local `README.md` placeholders. +5. Add basic validation script checking: + - required top-level files, + - required directories, + - files referenced in `canon.yaml`, + - missing agent briefs. +6. Add basic view generator for `views/by-standard.md`. +7. Add `Makefile`. +8. Add initial schemas. +9. Add CARING benchmark directory. +10. Commit as: `seed repository scaffold`. + +--- + +## Preferred Style + +Keep implementation boring and inspectable. + +Use: + +```text +Python for scripts +YAML for manifests and schemas +Markdown for human-facing docs +Makefile for repeatable local commands +``` + +Avoid introducing heavy dependencies before the basic repository structure works. + +--- + +## Acceptance Criteria for Initial Implementation + +The initial implementation is acceptable when: + +```text +make validate +``` + +can verify: + +- required files exist, +- required directories exist, +- all manifest paths resolve, +- standards/models are placed in the expected structure, +- generated views can be created or refreshed, +- missing optional artifacts are reported as warnings, not failures. + +--- + +## Next After Scaffold + +After the scaffold works: + +1. Create machine-readable concept ownership index. +2. Extract concept pages from seed standards. +3. Create agent briefs per standard. +4. Create mapping skeletons. +5. Create formal CARING assimilation workspace. +6. Add link validation. +7. Add front matter validation. +8. Add retrieval/chunk manifest generation. diff --git a/INTENT.md b/INTENT.md new file mode 100644 index 0000000..1fe1dd7 --- /dev/null +++ b/INTENT.md @@ -0,0 +1,108 @@ +# INTENT + +## Purpose + +This repository exists to develop and maintain **InfoTechCanon**: an evolving, markdown-first reference system for building interoperable, adaptable, and extensible information-processing systems. + +InfoTechCanon provides a shared semantic foundation for standards, concepts, patterns, profiles, mappings, and assimilation processes used across software, infrastructure, governance, DevSecOps, task management, knowledge systems, and related domains. + +--- + +## Primary Utility + +InfoTechCanon helps turn **integration by interpretation** into **integration by declared semantic contract**. + +It provides: + +- canonical concepts with clear ownership, +- orthogonal standards that can import but not redefine each other, +- mappings to external standards, regulations, frameworks, and product models, +- assimilation processes for incorporating new bodies of knowledge, +- reusable pattern-language structures, +- application profiles for concrete implementation contexts, +- retrieval-friendly markdown artifacts for humans, agents, and tools, +- and guidance for making independently developed subsystems easier to connect. + +--- + +## Intended Users + +This repository is intended for: + +- architects designing interoperable information-processing systems, +- standards authors defining reusable domain models, +- repository maintainers declaring semantic boundaries and interfaces, +- developers implementing compatible subsystems, +- agents retrieving structured reference knowledge, +- governance and compliance reviewers mapping internal concepts to external obligations, +- and tool builders working on markdown-based infospaces, knowledge engines, and agentic development workflows. + +--- + +## Strategic Role + +InfoTechCanon acts as a **semantic operating layer** for a growing ecosystem of repositories, services, agents, and documentation spaces. + +It should support projects that need to remain adaptable while still sharing a common vocabulary and integration logic. + +The repository is expected to become a reference point for related tools and systems, including markdown infobases, canonical landscape models, task and tagging standards, governance models, access-control models, and subsystem interface declarations. + +--- + +## Design Stance + +InfoTechCanon is: + +- **markdown-first** but machine-readable, +- **network-shaped** rather than purely hierarchical, +- **pattern-oriented** rather than merely taxonomic, +- **externally mappable** without being externally constrained, +- **evolutionary** without becoming arbitrary, +- **orthogonal** without becoming isolated, +- and **practical** enough to guide real subsystem integration. + +External standards influence InfoTechCanon through mappings and assimilation. They do not define its internal semantics directly. + +--- + +## Core Commitments + +InfoTechCanon commits to the following principles: + +1. Every canonical concept should have a clear owner. +2. Standards should import concepts instead of redefining them. +3. Mappings to external bodies of knowledge should be explicit, versioned, scoped, and justified. +4. Assimilation should turn new knowledge into gaps, conflicts, mappings, and improvement proposals. +5. Patterns should explain how concepts are combined in recurring practical situations. +6. Profiles should constrain standards for concrete implementation contexts. +7. Canon artifacts should be useful to both humans and agents. +8. Evolution should preserve provenance, compatibility information, and rationale. + +--- + +## Non-Goals + +This repository does not aim to replace external standards such as ArchiMate, CSDM, ITIL, PMBOK, NIST, YANG, SPDX, CycloneDX, or similar bodies of knowledge. + +It also does not aim to define one mandatory enterprise data model that every system must fully implement. + +Instead, InfoTechCanon provides a coherent internal reference system that can map to external standards, assimilate useful knowledge from them, and support practical interoperability across independently evolving systems. + +--- + +## Direction of Travel + +The repository should initially establish: + +- `InfoTechCanonCore`, +- a refactored `InfoTechCanonLandscapeModel`, +- early organization and governance model extraction points, +- a mapping model, +- an assimilation model, +- a pattern format, +- a profile format, +- retrieval conventions, +- and example subsystem interface declarations. + +Over time, the repository should grow into a living canon that supports human reasoning, agentic workflows, validation, documentation generation, knowledge retrieval, and practical system integration. + diff --git a/SCOPE.md b/SCOPE.md new file mode 100644 index 0000000..93c6ef3 --- /dev/null +++ b/SCOPE.md @@ -0,0 +1,241 @@ +# SCOPE + +## Current Repository Scope + +This repository currently contains the seed structure for **InfoTechCanon**: an evolving, markdown-first canon for building interoperable, adaptable, and extensible information-processing systems. + +At this stage, the repository is not yet a fully validated standards system. It is a **seed corpus** of kernel documents, domain models, specialized standards, and integration guidance that together define the first-generation InfoTechCanon kernel. + +--- + +## Current Purpose + +The repository currently serves to: + +- collect the first generation of InfoTechCanon standards and models, +- define the semantic boundaries between domains, +- preserve orthogonality between concepts, +- provide seed structures for mappings, profiles, patterns, assimilation, validation, and agent use, +- support future machine-readable extraction, +- and act as the first major use case for markdown-based infospaces and related tooling. + +--- + +## Current Kernel + +The current kernel consists of: + +```text +kernel/ + InfoTechCanonCore.md + InfoTechCanonKernelMap.md +``` + +### InfoTechCanonCore + +Defines shared canon mechanisms: + +- canon artifacts, +- concepts, +- concept ownership, +- relationships, +- mappings, +- assimilation, +- profiles, +- patterns, +- validation rules, +- conformance levels, +- versioning, +- provenance, +- agent briefs, +- and Canon Interface Cards. + +### InfoTechCanonKernelMap + +Shows how the first-generation standards and models fit together, including the position of CARING as a specialized access-governance standard. + +--- + +## Current Models + +The repository currently includes seed models for: + +```text +models/ + information-space/ + landscape/ + organization/ + governance/ + task/ + access-control/ + security/ + data/ + devsecops/ + network/ + observability/ +``` + +These models define broad domain structures. + +| Model | Current Responsibility | +|---|---| +| Information Space | Markdown-first knowledge packaging, retrieval, links, chunks, indexes, agent briefs | +| Landscape | IT landscapes, services, systems, runtime resources, infrastructure context | +| Organization | Actors, roles, teams, membership, responsibility, authority, accountability | +| Governance | Policies, rules, decisions, controls, risk, evidence, exceptions, assurance | +| Task | Work items, options, tasks, actions, blockers, dependencies, commitment, outcomes | +| Access Control | Subjects, principals, permissions, grants, authorization decisions, enforcement | +| Security | Threats, weaknesses, vulnerabilities, findings, exposure, attack paths, incidents | +| Data | Datasets, schemas, data products, classification, lineage, quality, contracts | +| DevSecOps | Source-to-artifact-to-release-to-deployment delivery flow and evidence | +| Network | Addressing, topology, routing, policy, reachability, exposure, network state | +| Observability | Telemetry, logs, metrics, traces, alerts, SLOs, health, operational evidence | + +--- + +## Current Specialized Standards + +The repository currently includes specialized standards for: + +```text +standards/ + tagging/ + caring/ +``` + +| Standard | Current Responsibility | +|---|---| +| Tagging | Tag identity, schemes, namespaces, assignments, mappings, validation | +| CARING | Orthogonal access-governance analysis using canonical roles, planes, exposure modes, derived and induced capabilities | + +--- + +## Current Structural Assumptions + +The current repository structure assumes the distinction: + +```text +Kernel + Defines how the canon works. + +Models + Define broad domain structures. + +Standards + Define cross-cutting conventions, mechanisms, or named analytical/design frameworks. + +Profiles + Constrain models and standards for concrete implementation contexts. + +Patterns + Describe recurring practical solutions. + +Mappings + Relate InfoTechCanon concepts to external bodies of knowledge. + +Assimilation + Analyzes external knowledge bodies and turns them into mappings, gaps, conflicts, and proposed changes. + +Views + Provide generated or curated navigation over canon artifacts. + +Agent + Provides compact, retrieval-optimized guidance for AI agents and tools. +``` + +--- + +## Current Non-Goals + +The current repository does not yet provide: + +- a complete ontology, +- complete YAML/JSON schemas for all artifact types, +- automated validation tooling, +- fully extracted concept pages, +- finalized mappings to external standards, +- complete application profiles, +- complete agent retrieval indexes, +- mature conformance tests, +- or a stable release of the InfoTechCanon. + +The current scope is seed-level structure and consolidation. + +--- + +## Current Known Duplication + +The current seed standards still repeat some generic sections that should eventually be centralized in `InfoTechCanonCore`, including: + +- mapping model, +- assimilation model, +- profile format, +- conformance levels, +- validation rule format, +- repository placement, +- agent brief requirements, +- Canon Interface Card usage, +- lifecycle statuses. + +This duplication is accepted for the seed phase but should be reduced during refactoring. + +--- + +## Current Refactoring Priorities + +Near-term work should focus on: + +1. moving repeated generic mechanisms into Core, +2. creating machine-readable schemas, +3. extracting concept pages from seed standards, +4. creating global indexes, +5. creating agent briefs, +6. creating first application profiles, +7. creating formal assimilation workspaces, +8. running CARING as the first full benchmark assimilation, +9. validating concept ownership across the kernel, +10. and creating Canon Interface Cards for initial tools and repositories. + +--- + +## First Validation Targets + +The first validation targets should be: + +```text +1. Concept ownership table +2. Cross-standard import matrix +3. Kernel dependency graph +4. CARING access descriptor schema +5. Mapping schema +6. Profile schema +7. Agent brief schema +8. Repository layout validation +9. Internal link validation +10. Duplicate concept detection +``` + +--- + +## Current Maturity + +The repository is currently at: + +```text +Maturity: Seed Kernel +Status: Pre-release consolidation +Primary use: Human/agent reference and refactoring foundation +``` + +The next maturity target is: + +```text +Maturity: Kernel RC1 +Condition: + Core mechanisms centralized, + standards indexed, + concept ownership explicit, + first profiles and mappings created, + CARING assimilation completed, + and basic validation scripts available. +``` diff --git a/canon.yaml b/canon.yaml new file mode 100644 index 0000000..c31ba8b --- /dev/null +++ b/canon.yaml @@ -0,0 +1,100 @@ +repository: info-tech-canon +title: InfoTechCanon +status: seed-kernel +version: RC1-seed +description: > + An evolving, markdown-first canon for building interoperable, adaptable, + and extensible information-processing systems. + +classification: + kernel: + description: Defines how the canon is organized and evolved. + models: + description: Define broad domain structures. + standards: + description: Define cross-cutting conventions or named analytical/design frameworks. + +kernel: + - id: itc-core + title: InfoTechCanonCore + path: kernel/InfoTechCanonCore.md + status: RC1-seed + - id: itc-kernel-map + title: InfoTechCanonKernelMap + path: kernel/InfoTechCanonKernelMap.md + status: RC1-kernel-map + +models: + - id: itc-infospace + title: InfoTechCanonInformationSpaceModel + path: models/information-space/InfoTechCanonInformationSpaceModel.md + status: RC1-seed + - id: itc-land + title: InfoTechCanonLandscapeModel + path: models/landscape/InfoTechCanonLandscapeModel.md + status: RC1-seed + - id: itc-org + title: InfoTechCanonOrganizationModel + path: models/organization/InfoTechCanonOrganizationModel.md + status: RC1-seed + - id: itc-gov + title: InfoTechCanonGovernanceModel + path: models/governance/InfoTechCanonGovernanceModel.md + status: RC1-seed + - id: itc-task + title: InfoTechCanonTaskModel + path: models/task/InfoTechCanonTaskModel.md + status: RC1-seed + - id: itc-access + title: InfoTechCanonAccessControlModel + path: models/access-control/InfoTechCanonAccessControlModel.md + status: RC1-seed + - id: itc-sec + title: InfoTechCanonSecurityModel + path: models/security/InfoTechCanonSecurityModel.md + status: RC1-seed + - id: itc-data + title: InfoTechCanonDataModel + path: models/data/InfoTechCanonDataModel.md + status: RC1-seed + - id: itc-devsecops + title: InfoTechCanonDevSecOpsModel + path: models/devsecops/InfoTechCanonDevSecOpsModel.md + status: RC1-seed + - id: itc-net + title: InfoTechCanonNetworkModel + path: models/network/InfoTechCanonNetworkModel.md + status: RC1-seed + - id: itc-obs + title: InfoTechCanonObservabilityModel + path: models/observability/InfoTechCanonObservabilityModel.md + status: RC1-seed + +standards: + - id: itc-tag + title: InfoTechCanonTaggingStandard + path: standards/tagging/InfoTechCanonTaggingStandard.md + status: RC1-seed + - id: itc-caring + title: InfoTechCanonCaringAccessGovernanceStandard + path: standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md + status: 0.4.0-RC2-aligned + +planned_directories: + - profiles/ + - patterns/ + - mappings/ + - assimilation/ + - schemas/ + - views/ + - agent/ + - examples/ + - validation/ + +next_actions: + - centralize generic mechanisms in Core + - create schemas for core artifact types + - create concept ownership index + - create agent briefs + - run CARING assimilation benchmark + - create small-saas kernel profile diff --git a/seeds/InfoTechCanonAccessControlModel_RC1_seed.md b/seeds/InfoTechCanonAccessControlModel_RC1_seed.md new file mode 100755 index 0000000..b62340f --- /dev/null +++ b/seeds/InfoTechCanonAccessControlModel_RC1_seed.md @@ -0,0 +1,2302 @@ +# InfoTechCanon Access Control Model + +**Short Name:** `ITC-ACCESS` +**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:** Security architects, platform engineers, identity engineers, authorization-system designers, service owners, DevSecOps teams, governance designers, application developers, operators, agentic tooling designers, repository maintainers, and standards authors. + +--- + +# 1. Purpose + +The **InfoTechCanon Access Control Model** defines a canonical seed model for representing authorization and access-control semantics across applications, platforms, services, infrastructure, repositories, operational tools, data systems, and human-agent environments. + +It provides the canonical vocabulary for: + +- subjects, +- principals, +- identities as references, +- resources, +- actions, +- permissions, +- privileges, +- entitlements, +- grants, +- bindings, +- policies, +- conditions, +- authorization requests, +- authorization decisions, +- enforcement, +- sessions, +- delegation, +- temporary access, +- break-glass access, +- access reviews, +- and access evidence. + +This standard deliberately distinguishes access control from generic organization modeling, governance, identity provisioning, and authentication protocols. + +It answers the core question: + +```text +Which authenticated subject may perform which action on which resource, +under which policy, in which context, with which evidence and review path? +``` + +--- + +# 2. Position in InfoTechCanon + +The Access Control Model is a **domain standard** within InfoTechCanon. + +It depends on the existing seed standards as follows: + +```text +Organization = actors, persons, agents, teams, roles, memberships, authority. +Governance = policies, controls, decisions, exceptions, reviews, evidence. +Landscape = systems, services, resources, endpoints, repositories, data, runtime objects. +Task = work items, requests, changes, reviews, remediation. +Tagging = classification and selectors, not access semantics by default. +Access = authorization relationships and decisions. +``` + +```text +InfoTechCanon +├── InfoTechCanonCore +├── InfoTechCanonLandscapeModel +├── InfoTechCanonOrganizationModel +├── InfoTechCanonGovernanceModel +├── InfoTechCanonTaskModel +├── InfoTechCanonTaggingStandard +├── InfoTechCanonAccessControlModel <-- this standard +├── InfoTechCanonSecurityModel +├── InfoTechCanonDataModel +├── InfoTechCanonDevSecOpsModel +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +--- + +# 3. Boundary with Adjacent Standards + +## 3.1 Boundary with Organization + +The Organization Model owns: + +```text +Person +Agent +Team +Organization +Role +Membership +Assignment +Authority +Responsibility +Accountability +Ownership +Stewardship +``` + +The Access Control Model owns: + +```text +Subject +Principal +AccessRole +Permission +Privilege +Entitlement +Grant +RoleBinding +PolicyBinding +AuthorizationRequest +AuthorizationDecision +EnforcementPoint +AccessSession +AccessReview +AccessExceptionReference +``` + +Boundary rule: + +```text +Organization defines who actors are and what organizational roles or responsibilities they carry. +Access Control defines what authenticated subjects may do to protected resources. +``` + +## 3.2 Boundary with Governance + +The Governance Model owns: + +```text +Policy +Control +ControlObjective +Decision +Approval +Exception +Risk +Evidence +Review +Audit +ComplianceRequirement +``` + +The Access Control Model uses governance concepts for: + +```text +access policy references +access-control objectives +access reviews +access exceptions +access evidence +access approvals +risk-based access decisions +``` + +Boundary rule: + +```text +Governance defines why and under what rule access should be controlled. +Access Control defines how authorization is represented, decided, granted, enforced, and reviewed. +``` + +## 3.3 Boundary with Landscape + +The Landscape Model owns: + +```text +Service +ApplicationService +Repository +RuntimeResource +Endpoint +DataStore +Dataset +Environment +NetworkResource +PlatformResource +``` + +The Access Control Model refers to these as protected resources. + +Boundary rule: + +```text +Landscape owns resource identity and relationships. +Access Control owns access semantics for those resources. +``` + +## 3.4 Boundary with Security + +The Security Model should own: + +```text +Threat +Vulnerability +AttackPath +SecurityFinding +SecurityEvent +SecurityIncident +SecurityControlImplementation +``` + +Access Control owns authorization semantics. + +Security may analyze or test access control as a security domain. + +## 3.5 Boundary with Identity and Authentication + +Identity provisioning and authentication are related but distinct. + +This standard references but does not fully own: + +```text +User provisioning +Identity provider configuration +Authentication factors +MFA token lifecycle +Password policy +Federation protocol details +SCIM provisioning protocol +OIDC authentication protocol +SAML assertion protocol +``` + +Access Control begins after or alongside identity proofing and authentication: + +```text +Authentication asks: Is this subject who or what it claims to be? +Authorization asks: What may this subject do now? +``` + +--- + +# 4. Research Basis and External Alignment + +This seed standard draws on multiple access-control bodies of knowledge. + +## 4.1 RBAC + +Role-Based Access Control provides the classic model of users, roles, permissions, operations, and objects. The NIST/INCITS RBAC reference model distinguishes core RBAC, role hierarchies, and separation-of-duty constraints. + +## 4.2 ABAC + +Attribute-Based Access Control models authorization decisions as evaluations of subject, object/resource, action, and environment attributes against policies, rules, and relationships. + +## 4.3 ReBAC and Zanzibar-Style Authorization + +Relationship-Based Access Control represents access through relationships among users, groups, resources, tenants, and objects. Zanzibar-style systems use tuples and namespace/configuration models to evaluate authorization at large scale. + +## 4.4 Policy-Based Access Control + +Policy-based systems such as XACML, OPA/Rego, Cedar, Keycloak Authorization Services, and similar tools decouple authorization logic from application code and evaluate access requests against explicit policies. + +## 4.5 OAuth 2.0 and OpenID Connect + +OAuth 2.0 is an authorization framework enabling limited access to HTTP services, commonly through access tokens. OpenID Connect adds an identity layer on top of OAuth 2.0 for verifying end-user identity and retrieving profile claims. + +These are protocol and token ecosystems, not complete canonical authorization semantics. + +## 4.6 SCIM + +SCIM provides platform-neutral schemas and protocols for provisioning users, groups, and related identity resources across domains. + +SCIM is a mapping target for identity references, subjects, users, and groups, but does not replace access-control semantics. + +## 4.7 Kubernetes RBAC + +Kubernetes RBAC demonstrates practical resource/action authorization using Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. It is a key profile target for platform and cluster access. + +## 4.8 Keycloak, privacyIDEA, OPA, OpenFGA, Cedar, Casbin + +Practical tooling demonstrates complementary access-control approaches: + +```text +Keycloak + identity, federation, realm/client roles, authorization services, policy enforcement. + +privacyIDEA + MFA and authentication-token orchestration with policy-driven behavior. + +OPA + general-purpose policy decision engine and Rego language. + +OpenFGA + Zanzibar-inspired fine-grained relationship-based authorization. + +Cedar / Amazon Verified Permissions + schema-aware fine-grained authorization policy language and decision service. + +Casbin + authorization library supporting many models such as ACL, RBAC, ABAC, ReBAC, PBAC, and others. +``` + +InfoTechCanon should map to these, not be captured by any one of them. + +--- + +# 5. Seed Standard Design Stance + +This standard is a **seed standard**, not a full implementation specification. + +It shall: + +1. define canonical access-control semantics, +2. distinguish identity, authentication, authorization, and governance, +3. support RBAC, ABAC, ReBAC, ACL, PBAC, and hybrid approaches, +4. support human and non-human subjects, +5. support agentic access and operational access, +6. support fine-grained resource/action authorization, +7. support temporary, delegated, emergency, and service-account access, +8. support policy decision and enforcement architecture, +9. support mappings to real standards and tools, +10. remain markdown-first and agent-retrievable, +11. and support future assimilation of access-control standards, products, and implementation patterns. + +--- + +# 6. Scope + +## 6.1 In Scope + +This standard covers canonical representation of: + +- subjects, +- principals, +- identity references, +- authenticated subjects, +- resources, +- protected resources, +- resource scopes, +- actions, +- operations, +- permissions, +- privileges, +- entitlements, +- grants, +- role bindings, +- policy bindings, +- access policies as references, +- access-control policies as access-specific artifacts, +- conditions, +- attributes, +- relationships, +- authorization requests, +- authorization decisions, +- authorization evidence, +- policy enforcement points, +- policy decision points, +- policy administration points, +- policy information points, +- access sessions, +- delegated access, +- temporary access, +- emergency access, +- break-glass access, +- service-account access, +- agent access, +- access reviews, +- access exceptions, +- and least privilege analysis. + +## 6.2 Out of Scope + +This standard does not fully define: + +- identity proofing, +- account lifecycle management, +- password policy, +- MFA token enrollment, +- authentication protocol implementation, +- OAuth flow implementation, +- OIDC claim design, +- SAML profile implementation, +- full SCIM provisioning implementation, +- HR master data, +- all cybersecurity incident handling, +- full IAM product configuration, +- or legal/compliance interpretation. + +Those may be mapped, assimilated, profiled, or handled by adjacent standards. + +--- + +# 7. 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 defined provisionally here but open to later refinement. +- **EXTRACT** marks a concept that may later move to a more specialized standard. + +--- + +# 8. Core Principles + +## 8.1 Authentication Is Not Authorization + +The model SHALL distinguish authentication from authorization. + +Authentication verifies or establishes subject identity. +Authorization determines whether an authenticated or otherwise recognized subject may perform an action on a resource. + +## 8.2 Organizational Role Is Not Access Role + +An organizational role does not automatically imply an access role. + +Access roles are permission-bearing constructs. + +## 8.3 Permission Is Not Assignment + +A permission defines allowed action on resource type or scope. +An assignment or binding connects a subject, role, permission, or policy to a concrete access scope. + +## 8.4 Grant Is Not Decision + +A grant is a durable or time-bound authorization relationship. +A decision is the result of evaluating a specific access request. + +## 8.5 Access Requires Scope + +Access rights SHOULD be scoped to resource, tenant, environment, service, dataset, system, or operational context. + +## 8.6 Conditions Matter + +Access may depend on attributes, relationships, time, network, device, authentication strength, risk, purpose, or environment context. + +## 8.7 Enforcement Is First-Class + +An access decision has practical effect only if enforced by an enforcement point. + +## 8.8 Access Must Be Reviewable + +Access grants, privileged access, emergency access, and agent access SHOULD be reviewable and evidence-carrying. + +## 8.9 Least Privilege Is a Directional Principle + +Access-control implementations SHOULD minimize permissions relative to required purpose and scope. + +## 8.10 Tags Are Not Entitlements by Default + +Tags may help select resources or policies but MUST NOT become entitlements unless an access-control profile explicitly defines that behavior. + +--- + +# 9. Canonical Seed Metadata + +Every access-control artifact SHOULD support structured metadata. + +Recommended front matter: + +```yaml +--- +id: itc-access:Permission +type: concept +standard: InfoTechCanonAccessControlModel +standard_version: RC1-seed +status: candidate +canonical_owner: InfoTechCanonAccessControlModel +preferred_label: Permission +related: + - itc-access:Action + - itc-access:Resource + - itc-access:Grant + - itc-access:AuthorizationDecision +mappings: + - itc-map:permission-to-rbac-permission +--- +``` + +Recommended artifact statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +Recommended concept statuses: + +```text +proposed +experimental +candidate +canonical +deprecated +retired +``` + +--- + +# 10. Root Access-Control Taxonomy + +```text +AccessControlEntity +├── SubjectEntity +│ ├── Subject +│ ├── Principal +│ ├── AuthenticatedSubject +│ ├── HumanSubject +│ ├── ServiceSubject +│ ├── AgentSubject +│ ├── GroupSubject +│ └── FederatedSubject +├── ResourceEntity +│ ├── Resource +│ ├── ProtectedResource +│ ├── ResourceType +│ ├── ResourceInstance +│ ├── ResourceScope +│ └── ResourceOwnerReference +├── ActionEntity +│ ├── Action +│ ├── Operation +│ ├── ResourceAction +│ ├── AdministrativeAction +│ ├── PrivilegedAction +│ └── DelegableAction +├── AuthorizationEntity +│ ├── Permission +│ ├── Privilege +│ ├── Entitlement +│ ├── Grant +│ ├── Denial +│ ├── AccessRole +│ ├── RoleBinding +│ ├── PolicyBinding +│ └── ScopeBinding +├── PolicyEvaluationEntity +│ ├── AuthorizationRequest +│ ├── AuthorizationDecision +│ ├── DecisionReason +│ ├── Condition +│ ├── Attribute +│ ├── RelationshipTuple +│ └── EvaluationContext +├── EnforcementEntity +│ ├── PolicyEnforcementPoint +│ ├── PolicyDecisionPoint +│ ├── PolicyAdministrationPoint +│ ├── PolicyInformationPoint +│ ├── PolicyRetrievalPoint +│ └── EnforcementResult +├── SessionEntity +│ ├── AccessSession +│ ├── TokenReference +│ ├── CredentialReference +│ ├── AuthenticationStrengthReference +│ └── SessionContext +├── SpecialAccessEntity +│ ├── DelegatedAccess +│ ├── TemporaryAccess +│ ├── JustInTimeAccess +│ ├── BreakGlassAccess +│ ├── ServiceAccountAccess +│ └── AgentAccess +└── ReviewEntity + ├── AccessReview + ├── AccessCertification + ├── AccessFinding + ├── ExcessAccess + ├── OrphanedAccess + ├── StaleAccess + └── AccessRemediation +``` + +--- + +# 11. Core Concepts + +## 11.1 AccessControlEntity + +An **AccessControlEntity** is any identifiable concept used to represent authorization, permissions, access grants, decisions, enforcement, or review. + +Recommended attributes: + +```yaml +id: +entity_type: +canonical_name: +display_name: +lifecycle_state: +source_system: +created_at: +updated_at: +``` + +Optional attributes: + +```yaml +owner: +steward: +governance_scope: +resource_scope: +source_confidence: +valid_from: +valid_to: +tags: +external_references: +``` + +--- + +## 11.2 Subject + +A **Subject** is an entity requesting, holding, or exercising access. + +A subject may be: + +```text +human user +service account +workload identity +AI agent +automation bot +group +federated identity +external partner +``` + +Canonical rule: + +```text +Subject is the access-control view of an actor. +Actor semantics are owned by the Organization Model. +``` + +--- + +## 11.3 Principal + +A **Principal** is an identity-bearing subject recognized by an access-control system. + +Examples: + +```text +user account +service account +federated identity +client application +machine identity +agent identity +``` + +A principal may map to a Person, Agent, Team, or external identity. + +--- + +## 11.4 IdentityReference + +An **IdentityReference** points to an identity record in an identity provider, directory, federation source, SCIM system, IAM system, or local user store. + +The Access Control Model references identities but does not own identity lifecycle. + +--- + +## 11.5 AuthenticatedSubject + +An **AuthenticatedSubject** is a subject whose identity or credential has been verified with a defined authentication strength or context. + +--- + +## 11.6 Resource + +A **Resource** is an entity that may be accessed, modified, invoked, viewed, administered, or otherwise acted upon. + +Resources may include: + +```text +service +API endpoint +repository +branch +environment +cluster +namespace +database +dataset +document +file +secret +certificate +pipeline +artifact +dashboard +tenant +organization +configuration +``` + +Resource identity is usually owned by Landscape or another domain model. + +--- + +## 11.7 ProtectedResource + +A **ProtectedResource** is a resource subject to access-control enforcement. + +--- + +## 11.8 ResourceScope + +A **ResourceScope** defines the boundary within which access applies. + +Examples: + +```text +tenant +organization +project +repository +branch +service +environment +namespace +cluster +dataset +record +region +``` + +--- + +## 11.9 Action + +An **Action** is something a subject may attempt to do to a resource. + +Examples: + +```text +read +list +create +update +delete +execute +approve +deploy +administer +impersonate +assume-role +download +share +grant-access +``` + +--- + +## 11.10 Operation + +An **Operation** is a system-specific or API-specific action. + +Operation may be mapped to canonical Action. + +--- + +## 11.11 ResourceAction + +A **ResourceAction** is a canonical action applied to a resource type or resource instance. + +Example: + +```text +repository:write +environment:deploy +dataset:read +secret:rotate +cluster:admin +``` + +--- + +## 11.12 Permission + +A **Permission** is an authorization unit describing an allowed action or set of actions on a resource type, resource instance, or scope. + +Canonical rule: + +```text +Permission SHOULD separate action, resource, and scope when possible. +``` + +--- + +## 11.13 Privilege + +A **Privilege** is a permission or permission set with elevated consequence, sensitivity, or administrative power. + +Examples: + +```text +root shell +cluster-admin +user-management admin +secret-read +production deploy +impersonation +policy edit +``` + +--- + +## 11.14 Entitlement + +An **Entitlement** is a permission, access package, role, grant, or benefit assigned to a subject. + +Entitlement is often used in IAM governance and access review contexts. + +--- + +## 11.15 AccessRole + +An **AccessRole** is a permission-bearing role in an access-control system. + +It is distinct from an organizational role. + +Examples: + +```text +repository-maintainer +cluster-admin +billing-reader +support-agent +release-manager +secret-rotator +``` + +--- + +## 11.16 Grant + +A **Grant** is a durable or time-bound relationship giving a subject access under defined scope and conditions. + +Recommended attributes: + +```yaml +subject: +permission_or_role: +resource_scope: +conditions: +granted_by: +valid_from: +valid_to: +source_system: +evidence: +``` + +--- + +## 11.17 Denial + +A **Denial** is an explicit rule, decision, or binding that prevents access. + +Denials may override grants depending on policy profile. + +--- + +## 11.18 RoleBinding + +A **RoleBinding** assigns an AccessRole to a Subject within a ResourceScope. + +Example: + +```text +Subject alice@example.com has AccessRole repository-maintainer on repository info-tech-canon. +``` + +--- + +## 11.19 PolicyBinding + +A **PolicyBinding** connects a policy, policy set, or access rule to a subject, resource, tenant, environment, or scope. + +--- + +## 11.20 AuthorizationRequest + +An **AuthorizationRequest** is a request to determine whether a subject may perform an action on a resource in a context. + +Recommended attributes: + +```yaml +subject: +action: +resource: +context: +requested_at: +request_source: +``` + +--- + +## 11.21 AuthorizationDecision + +An **AuthorizationDecision** is the result of evaluating an authorization request. + +Recommended decision values: + +```text +permit +deny +not_applicable +indeterminate +conditional_permit +``` + +Recommended attributes: + +```yaml +request: +decision: +reason: +policy_references: +evaluated_at: +decision_point: +evidence: +``` + +--- + +## 11.22 DecisionReason + +A **DecisionReason** explains why an authorization decision was reached. + +Reason may reference: + +```text +matched policy +missing permission +expired grant +failed condition +explicit denial +insufficient authentication strength +risk signal +break-glass requirement +``` + +--- + +## 11.23 Condition + +A **Condition** is a requirement that must hold for access to be permitted. + +Examples: + +```text +time window +network location +device posture +MFA present +ticket reference present +risk score below threshold +resource owner approval +environment is non-production +``` + +--- + +## 11.24 Attribute + +An **Attribute** is a property of subject, resource, action, or environment used in policy evaluation. + +Attribute categories: + +```text +subject attribute +resource attribute +action attribute +environment attribute +session attribute +risk attribute +relationship attribute +``` + +--- + +## 11.25 RelationshipTuple + +A **RelationshipTuple** represents a relationship used for authorization. + +Generic form: + +```text +subject relation object +``` + +Examples: + +```text +alice viewer document:123 +team-platform maintainer repository:abc +group-admins admin tenant:customer1 +``` + +This concept supports ReBAC and Zanzibar-style models. + +--- + +## 11.26 EvaluationContext + +An **EvaluationContext** is the set of attributes, relationships, session data, resource data, environmental data, and policy references used to evaluate an authorization request. + +--- + +## 11.27 PolicyEnforcementPoint + +A **PolicyEnforcementPoint** is the system component that intercepts or controls access and enforces authorization decisions. + +--- + +## 11.28 PolicyDecisionPoint + +A **PolicyDecisionPoint** is the system component that evaluates authorization requests and returns decisions. + +--- + +## 11.29 PolicyAdministrationPoint + +A **PolicyAdministrationPoint** is the system component or process where access policies are created, maintained, approved, or published. + +--- + +## 11.30 PolicyInformationPoint + +A **PolicyInformationPoint** is a source of attributes, relationships, or context used during policy evaluation. + +Examples: + +```text +directory +HR system +SCIM service +CMDB +resource inventory +risk engine +device posture service +ticket system +``` + +--- + +## 11.31 PolicyRetrievalPoint + +A **PolicyRetrievalPoint** stores or retrieves policies for evaluation. + +--- + +## 11.32 AccessSession + +An **AccessSession** is a time-bounded context in which a subject exercises access. + +A session may reference: + +```text +token +credential +authentication strength +device +network +client +risk context +start time +expiry +``` + +--- + +## 11.33 TokenReference + +A **TokenReference** points to a token used in an access session or protocol exchange. + +Examples: + +```text +OAuth access token +OIDC ID token +SAML assertion +Kubernetes service account token +SSH certificate +``` + +--- + +## 11.34 CredentialReference + +A **CredentialReference** points to a credential used for authentication or access. + +Examples: + +```text +password +SSH key +API key +certificate +MFA token +hardware key +workload identity credential +``` + +--- + +## 11.35 AuthenticationStrengthReference + +An **AuthenticationStrengthReference** records the strength or assurance of authentication used. + +Examples: + +```text +password-only +MFA +phishing-resistant MFA +hardware-backed key +workload identity +mutual TLS +``` + +--- + +## 11.36 DelegatedAccess + +**DelegatedAccess** is access where one subject grants or delegates access authority to another subject within defined limits. + +--- + +## 11.37 TemporaryAccess + +**TemporaryAccess** is access granted for a limited time. + +--- + +## 11.38 JustInTimeAccess + +**JustInTimeAccess** is temporary access granted only when needed, often after approval, ticket reference, risk check, or workflow. + +--- + +## 11.39 BreakGlassAccess + +**BreakGlassAccess** is emergency access used when normal processes are insufficient or unavailable. + +Break-glass access SHOULD be: + +```text +rare +time-bound +strongly authenticated +logged +reviewed +evidence-carrying +subject to post-use review +``` + +--- + +## 11.40 ServiceAccountAccess + +**ServiceAccountAccess** is access exercised by a service account, machine identity, workload identity, automation, or non-human subject. + +--- + +## 11.41 AgentAccess + +**AgentAccess** is access exercised by an AI or software agent. + +Agent access SHOULD declare: + +```text +supervising actor +scope +tools +permissions +safety boundaries +audit expectations +revocation mechanism +``` + +--- + +## 11.42 AccessReview + +An **AccessReview** is a governance review of whether access grants, roles, entitlements, privileges, or policies remain appropriate. + +--- + +## 11.43 AccessCertification + +**AccessCertification** is a formal attestation that reviewed access remains appropriate or has been corrected. + +--- + +## 11.44 AccessFinding + +An **AccessFinding** is a finding produced by access review, audit, analysis, monitoring, or security assessment. + +Examples: + +```text +excess access +stale access +orphaned account +unused privilege +privilege escalation path +missing owner +break-glass misuse +``` + +--- + +## 11.45 ExcessAccess + +**ExcessAccess** is access beyond what is needed for the subject's current purpose, role, task, or scope. + +--- + +## 11.46 OrphanedAccess + +**OrphanedAccess** is access assigned to a subject, account, or identity reference that no longer has a valid owner, actor, employment/membership relation, or purpose. + +--- + +## 11.47 StaleAccess + +**StaleAccess** is access that was once justified but has not been used, reviewed, or renewed within expected limits. + +--- + +## 11.48 AccessRemediation + +**AccessRemediation** is work to correct inappropriate, excessive, stale, orphaned, or risky access. + +AccessRemediation may create Task Model work items. + +--- + +# 12. Core Relationship Vocabulary + +Recommended root relationship types: + +```text +requests_access_to +has_permission +has_privilege +has_entitlement +granted_to +denied_to +bound_to +assigned_role +applies_to_resource +applies_to_scope +permits_action +denies_action +requires_condition +evaluated_by +enforced_by +provided_by +retrieved_from +informed_by +delegated_to +expires_at +reviewed_by +certified_by +violates_policy +remediated_by +maps_to +``` + +Relationship records SHOULD support: + +```yaml +id: +relationship_type: +source_entity: +target_entity: +scope: +valid_from: +valid_to: +source_system: +confidence: +evidence: +rationale: +``` + +--- + +# 13. Access Decision Model + +## 13.1 Authorization Request Shape + +A canonical authorization request SHOULD include: + +```yaml +subject: +action: +resource: +context: + time: + environment: + session: + authentication_strength: + network: + device: + risk: + purpose: + request_source: +``` + +## 13.2 Authorization Decision Values + +Recommended decision values: + +```text +permit +deny +not_applicable +indeterminate +conditional_permit +``` + +## 13.3 Decision Evidence + +Mature systems SHOULD preserve: + +```text +policy references +matched grants +matched denials +condition results +attribute sources +relationship tuples used +decision time +decision point +enforcement point +request correlation id +``` + +## 13.4 Fail-Safe Rule + +Profiles SHOULD define how to handle indeterminate decisions. + +Security-sensitive systems SHOULD default to deny unless an explicit profile states otherwise. + +--- + +# 14. Access-Control Patterns + +## 14.1 Pattern: Subject-Action-Resource + +**Context:** A system needs a stable core authorization model. + +**Problem:** Access rules become inconsistent when subjects, actions, resources, and scopes are mixed together. + +**Solution:** Represent authorization around: + +```text +Subject +Action +Resource +Context +Decision +``` + +--- + +## 14.2 Pattern: Organizational Role to Access Role Mapping + +**Context:** Organizational roles often need access. + +**Problem:** Treating organizational roles as direct permissions creates hidden privilege. + +**Solution:** Map OrganizationalRole to AccessRole through explicit grants, bindings, policies, or profiles. + +--- + +## 14.3 Pattern: Policy Decision / Enforcement Split + +**Context:** Application code needs authorization but should not hard-code policy logic. + +**Problem:** Access rules become scattered across services. + +**Solution:** Separate: + +```text +Policy Enforcement Point +Policy Decision Point +Policy Administration Point +Policy Information Point +``` + +--- + +## 14.4 Pattern: Least Privilege Grant + +**Context:** A subject needs access to perform work. + +**Problem:** Broad roles accumulate and become risky. + +**Solution:** Grant only the needed actions on the needed resources for the needed scope and duration. + +--- + +## 14.5 Pattern: Just-in-Time Privilege + +**Context:** Privileged access is needed occasionally. + +**Problem:** Standing privileged access creates persistent risk. + +**Solution:** Use temporary, approved, logged, expiring access grants. + +--- + +## 14.6 Pattern: Break Glass with Review + +**Context:** Emergency access is required to restore or protect critical systems. + +**Problem:** Emergency access can become an invisible bypass. + +**Solution:** Require strong authentication, explicit reason, time limit, logging, post-use review, and remediation of any misuse. + +--- + +## 14.7 Pattern: Service Account Ownership + +**Context:** Non-human accounts access systems. + +**Problem:** Service accounts become orphaned or over-privileged. + +**Solution:** Every service account should have owner, purpose, scope, permissions, rotation expectation, and review cycle. + +--- + +## 14.8 Pattern: Agent Access Boundary + +**Context:** AI or software agents perform actions. + +**Problem:** Agents may combine tools and permissions in unexpected ways. + +**Solution:** Agent access must declare supervising actor, allowed tools, resource scope, action scope, safety boundary, logging, and review requirements. + +--- + +## 14.9 Pattern: Access Review to Remediation + +**Context:** Access reviews find inappropriate access. + +**Problem:** Findings do not turn into corrective action. + +**Solution:** Model: + +```text +AccessReview + -> AccessFinding + -> AccessRemediationTask + -> Evidence + -> AccessCertification +``` + +--- + +## 14.10 Pattern: Relationship Tuple for Collaboration + +**Context:** Access depends on relationships such as owner, viewer, editor, parent folder, team membership, or tenant membership. + +**Problem:** Flat roles cannot express dynamic collaborative access cleanly. + +**Solution:** Use relationship tuples and relationship-based checks where appropriate. + +--- + +# 15. Access Profiles + +## 15.1 Profile Format + +An Access Profile SHALL declare: + +```yaml +id: +profile_name: +status: +implements: + - InfoTechCanonAccessControlModel +target_context: +included_concepts: +required_relationships: +required_metadata: +decision_model: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +--- + +## 15.2 Seed Profile: Small SaaS Access Profile + +Purpose: + +```text +Provide a minimal access model for a small SaaS platform moving toward production readiness. +``` + +Included concepts: + +```text +Subject +Principal +Resource +Action +Permission +AccessRole +RoleBinding +AuthorizationRequest +AuthorizationDecision +AccessSession +AccessReview +TemporaryAccess +ServiceAccountAccess +``` + +Required relationships: + +```text +Principal maps_to Actor +AccessRole has_permission Permission +RoleBinding grants AccessRole to Subject within ResourceScope +AuthorizationRequest evaluated_by PolicyDecisionPoint +AuthorizationDecision enforced_by PolicyEnforcementPoint +AccessReview reviews Grant +``` + +--- + +## 15.3 Seed Profile: Kubernetes RBAC Profile + +Purpose: + +```text +Map Kubernetes RBAC objects into InfoTechCanon access-control concepts. +``` + +Example mappings: + +```text +User / Group / ServiceAccount -> Subject +Role -> AccessRole scoped to Namespace +ClusterRole -> AccessRole scoped to Cluster +RoleBinding -> RoleBinding scoped to Namespace +ClusterRoleBinding -> RoleBinding scoped to Cluster +PolicyRule verbs -> Actions +PolicyRule resources -> ResourceTypes +Namespace -> ResourceScope +``` + +Known deviations: + +```text +Kubernetes RBAC is additive and does not model explicit deny in standard RBAC. +Kubernetes subjects may reference identities outside the cluster. +ClusterRole can be bound namespace-locally through RoleBinding. +``` + +--- + +## 15.4 Seed Profile: OPA Policy Decision Profile + +Purpose: + +```text +Map OPA/Rego-style policy decision architecture into InfoTechCanon access-control concepts. +``` + +Example mappings: + +```text +input -> AuthorizationRequest +data -> PolicyInformation / PolicyData +rego policy -> AccessPolicyImplementation +allow result -> AuthorizationDecision +OPA server/library -> PolicyDecisionPoint +application gateway/service -> PolicyEnforcementPoint +``` + +--- + +## 15.5 Seed Profile: OpenFGA / Zanzibar Profile + +Purpose: + +```text +Map relationship-based authorization concepts into InfoTechCanon. +``` + +Example mappings: + +```text +user -> Subject +object -> Resource +relation -> RelationshipTuple relation +tuple -> RelationshipTuple +authorization model -> Policy / Schema +check request -> AuthorizationRequest +check response -> AuthorizationDecision +``` + +--- + +## 15.6 Seed Profile: Keycloak Authorization Profile + +Purpose: + +```text +Map Keycloak identity and authorization concepts into InfoTechCanon. +``` + +Example mappings: + +```text +Realm -> AccessDomain / TenantScope +Client -> ResourceServer / ClientApplication +Realm Role -> AccessRole +Client Role -> AccessRole within ClientScope +Group -> GroupSubject +User -> Principal +Resource -> ProtectedResource +Scope -> Action / ResourceScope depending on usage +Policy -> AccessPolicyImplementation +Permission -> Permission / PolicyBinding +``` + +--- + +## 15.7 Seed Profile: Cedar / Verified Permissions Profile + +Purpose: + +```text +Map Cedar-style fine-grained authorization into InfoTechCanon. +``` + +Example mappings: + +```text +principal -> Subject +action -> Action +resource -> Resource +context -> EvaluationContext +policy -> AccessPolicyImplementation +schema -> AccessModelSchema +permit/forbid -> AuthorizationDecision rule type +authorization API call -> AuthorizationRequest +``` + +--- + +## 15.8 Seed Profile: Ops / Break-Glass Access Profile + +Purpose: + +```text +Represent high-risk operational access to infrastructure, production systems, secrets, and emergency tools. +``` + +Included concepts: + +```text +PrivilegedAction +TemporaryAccess +JustInTimeAccess +BreakGlassAccess +ApprovalReference +AccessSession +SessionRecordingReference +AccessEvidence +PostUseReview +AccessFinding +AccessRemediation +``` + +Required relationships: + +```text +TemporaryAccess approved_by Actor +BreakGlassAccess requires Reason +AccessSession evidences AccessUse +PostUseReview reviews AccessSession +AccessFinding remediated_by Task +``` + +--- + +## 15.9 Seed Profile: Agent Access Profile + +Purpose: + +```text +Support AI and software agents that act through tools and APIs. +``` + +Included concepts: + +```text +AgentSubject +ToolResource +ActionScope +ResourceScope +SupervisingActor +DelegatedAccess +TemporaryAccess +PolicyBinding +ExecutionEvidence +HumanReview +RevocationMechanism +``` + +Required relationships: + +```text +AgentSubject supervised_by Actor +AgentSubject has_permission Permission +Permission applies_to ToolResource +Grant constrained_by SafetyCondition +ExecutionEvidence evidences Action +HumanReview reviews AgentAccess +``` + +--- + +# 16. Mapping Model for the Access Control Standard + +Mappings relate InfoTechCanon access-control concepts to external standards, tools, and products. + +## 16.1 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +regulatoryReference +toolEquivalent +``` + +## 16.2 Mapping Record + +Example: + +```yaml +id: itc-map:permission-to-rbac-permission +source_concept: itc-access:Permission +target_body: NIST/INCITS RBAC +target_version: "INCITS 359-2012 / R2022" +target_concept: Permission +mapping_type: closeMatch +scope: + - role-based access-control modeling +not_valid_for: + - attribute-based conditions + - relationship-based dynamic authorization +rationale: > + Both concepts represent an authorization unit combining operations and objects/resources, + but InfoTechCanon generalizes permission across RBAC, ABAC, ReBAC, and policy-based models. +confidence: high +status: candidate +owner: InfoTechCanonAccessControlModel +``` + +## 16.3 Seed Mapping Targets + +The Access Control Model SHOULD maintain mappings to: + +```text +NIST / INCITS RBAC +NIST SP 800-162 ABAC +XACML 3.0 +OAuth 2.0 +OpenID Connect +SAML 2.0 +SCIM 2.0 +Kubernetes RBAC +AWS IAM +Cedar / Amazon Verified Permissions +Open Policy Agent / Rego +OpenFGA +Google Zanzibar +Keycloak roles and authorization services +privacyIDEA policies and MFA concepts +Casbin model/policy concepts +Linux users/groups/sudo +LDAP groups +GitHub repository roles +GitLab permissions +Jira permissions +Cloud provider IAM models +``` + +--- + +# 17. Assimilation Hooks + +The Access Control Model SHALL be able to receive new access-control standards, tools, products, and patterns through the InfoTechCanon assimilation process. + +## 17.1 Assimilation Triggers + +Assimilation may be triggered by: + +```text +new IAM product +new authorization framework +new policy language +new access-control model +new cloud provider IAM feature +new Kubernetes authorization feature +new DevSecOps access requirement +new agentic access-control need +new production-readiness requirement +new access-control failure +``` + +## 17.2 Access Assimilation Output + +An access assimilation SHOULD produce: + +```text +source summary +extracted access concepts +concept comparison matrix +gap list +conflict list +mapping file +candidate new concepts +candidate relationship changes +candidate pattern changes +candidate profile changes +open questions +``` + +## 17.3 Recommended First Assimilation Candidates + +```text +Kubernetes RBAC +Keycloak role and authorization model +privacyIDEA policies and MFA model +NIST RBAC +NIST ABAC +OpenFGA / Zanzibar +OPA / Rego +Cedar / Amazon Verified Permissions +SCIM 2.0 +OAuth 2.0 / OIDC +Linux sudoers +GitHub repository permissions +``` + +--- + +# 18. Integration with Other InfoTechCanon Standards + +## 18.1 Organization Model + +Access imports organization concepts for: + +```text +actor +person +agent +team +group +organizational role +authority +responsibility +ownership +membership +``` + +## 18.2 Governance Model + +Access imports governance concepts for: + +```text +access policy +control objective +control +approval +exception +risk +evidence +review +audit +compliance requirement +``` + +## 18.3 Landscape Model + +Access applies to landscape concepts such as: + +```text +service +repository +pipeline +artifact +runtime resource +network endpoint +dataset +secret +environment +platform +tenant +``` + +## 18.4 Task Model + +Access creates or references tasks such as: + +```text +access request +access approval task +access review task +access remediation task +break-glass review task +agent access review task +``` + +## 18.5 Tagging Standard + +Tags may classify access grants, resources, or policies but must not replace access-control relationships. + +## 18.6 Security Model + +Security imports access-control concepts for: + +```text +privilege escalation +excess access +access finding +identity attack path +credential misuse +authorization bypass +``` + +--- + +# 19. Canon Interface Card Usage + +Subsystems that implement or produce access-control knowledge SHOULD publish a Canon Interface Card. + +Example: + +```yaml +subsystem: keycape +implements: + - InfoTechCanonAccessControlModel + - SmallSaaSAccessProfile +produces: + - Principal + - AccessRole + - RoleBinding + - AuthorizationDecision + - AccessSession +consumes: + - Person + - Team + - Policy + - Service +relations: + - Principal maps_to Person + - Principal assigned_role AccessRole + - AccessRole has_permission Permission + - AuthorizationDecision enforced_by Service +source_of_truth: + principal_identity: keycape + role_binding: keycape +known_deviations: + - does not model full HR lifecycle + - does not own governance policy definitions +``` + +--- + +# 20. Retrieval Requirements + +The Access Control Model is designed for markdown-based infospaces. + +## 20.1 Required Retrieval Properties + +Every major concept SHOULD provide: + +- stable heading, +- stable identifier, +- short definition, +- longer explanation, +- examples, +- distinction notes, +- relationship examples, +- mapping hooks, +- profile references, +- and common mistakes. + +## 20.2 Agent Brief + +A mature Access Control Model SHOULD include an `agent-brief.md` file with: + +```text +purpose +scope +owned concepts +imported concepts +core distinctions +do / do not rules +relationship patterns +minimal examples +common mistakes +profile list +mapping list +``` + +## 20.3 Indexes + +The access-control information space SHOULD provide indexes by: + +```text +concept +relationship +subject type +resource type +action +permission +role +grant +decision +profile +pattern +mapping target +status +source system +``` + +--- + +# 21. Conformance Levels + +## 21.1 Reference-Conformant + +A document or system is reference-conformant if it uses Access Control Model terminology consistently but does not implement structured metadata or validation rules. + +## 21.2 Metadata-Conformant + +A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types. + +## 21.3 Relationship-Conformant + +A system is relationship-conformant if it represents subjects, resources, actions, permissions, grants, bindings, decisions, and enforcement as explicit relationships. + +## 21.4 Decision-Conformant + +A system is decision-conformant if authorization requests and decisions are represented with subject, action, resource, context, decision value, and policy or reason references. + +## 21.5 Evidence-Conformant + +A system is evidence-conformant if access reviews, privileged access, break-glass access, and authorization decisions can be linked to evidence. + +## 21.6 Profile-Conformant + +A system is profile-conformant if it implements a declared Access Profile and passes its validation rules. + +## 21.7 Assimilation-Conformant + +A system or repository is assimilation-conformant if it can accept external access-control concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes. + +--- + +# 22. Validation Rules + +Initial validation rules: + +```text +VAL-ACCESS-001: Authentication and authorization SHOULD be modeled as distinct concerns. + +VAL-ACCESS-002: OrganizationalRole MUST NOT be treated as AccessRole unless a mapping or profile declares it. + +VAL-ACCESS-003: Permission SHOULD identify action, resource, and scope where possible. + +VAL-ACCESS-004: Grant SHOULD identify subject, permission or role, resource scope, source, and validity period where applicable. + +VAL-ACCESS-005: AuthorizationRequest SHOULD identify subject, action, resource, and evaluation context. + +VAL-ACCESS-006: AuthorizationDecision SHOULD record decision value, decision reason, evaluated policy or grant references, and decision point where available. + +VAL-ACCESS-007: PolicyEnforcementPoint SHOULD be identified for enforced access decisions. + +VAL-ACCESS-008: Privileged access SHOULD be time-bounded or periodically reviewed. + +VAL-ACCESS-009: BreakGlassAccess SHOULD require reason, strong authentication, logging, expiry, and post-use review. + +VAL-ACCESS-010: ServiceAccountAccess SHOULD declare owner, purpose, scope, and review expectation. + +VAL-ACCESS-011: AgentAccess SHOULD declare supervising actor, allowed actions, resource scope, safety boundary, and evidence requirements. + +VAL-ACCESS-012: AccessReview SHOULD produce findings or certification evidence. + +VAL-ACCESS-013: AccessFinding SHOULD create or reference remediation work when correction is required. + +VAL-ACCESS-014: Tags MUST NOT be treated as entitlements unless an Access Profile explicitly defines that behavior. + +VAL-ACCESS-015: Imported external access concepts SHOULD be represented through mapping records rather than silently reused. + +VAL-ACCESS-016: Profiles MUST NOT redefine canonical concepts. They may constrain them. + +VAL-ACCESS-017: Standing privileges SHOULD be justified by purpose, scope, and review cycle. + +VAL-ACCESS-018: Orphaned, stale, or excess access SHOULD be detectable in mature implementations. +``` + +--- + +# 23. Anti-Patterns + +## 23.1 Login Means Access + +Assuming that authentication implies authorization. + +## 23.2 Organizational Role Equals Permission + +Giving permissions directly based on job titles or informal roles without explicit access mapping. + +## 23.3 God Role + +Creating broad administrator roles without scope, review, or justification. + +## 23.4 Standing Privilege Everywhere + +Keeping persistent privileged access when temporary or just-in-time access would suffice. + +## 23.5 Service Account Without Owner + +Allowing non-human accounts without owner, purpose, expiry, credential rotation, or review. + +## 23.6 Break Glass Without Glass + +Emergency access exists but is not time-bounded, logged, reviewed, or exceptional. + +## 23.7 Policy in Code Only + +Hard-coding authorization logic in application code without explicit policy model or review path. + +## 23.8 Token as Truth + +Treating token claims as always sufficient for authorization without checking resource, context, or policy. + +## 23.9 Tag-Based Authorization Drift + +Using uncontrolled labels or tags to grant access. + +## 23.10 Access Review Theater + +Running access reviews that do not produce evidence, findings, remediation, or certification. + +--- + +# 24. Initial Repository Placement + +Recommended repository layout: + +```text +info-tech-canon/ + standards/ + access-control/ + InfoTechCanonAccessControlModel.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +Seed files: + +```text +standards/access-control/InfoTechCanonAccessControlModel.md +standards/access-control/agent-brief.md +standards/access-control/concepts/subject.md +standards/access-control/concepts/resource.md +standards/access-control/concepts/action.md +standards/access-control/concepts/permission.md +standards/access-control/concepts/grant.md +standards/access-control/concepts/authorization-decision.md +standards/access-control/concepts/policy-enforcement-point.md +standards/access-control/concepts/access-review.md +standards/access-control/patterns/subject-action-resource.md +standards/access-control/patterns/policy-decision-enforcement-split.md +standards/access-control/patterns/least-privilege-grant.md +standards/access-control/patterns/just-in-time-privilege.md +standards/access-control/profiles/small-saas-access-profile.md +standards/access-control/profiles/kubernetes-rbac-profile.md +standards/access-control/profiles/openfga-zanzibar-profile.md +standards/access-control/profiles/agent-access-profile.md +standards/access-control/mappings/rbac.yaml +standards/access-control/mappings/abac.yaml +standards/access-control/mappings/kubernetes-rbac.yaml +standards/access-control/mappings/oidc-oauth.yaml +``` + +--- + +# 25. Roadmap + +## Phase 1: Seed Stabilization + +- Establish this standard as `InfoTechCanonAccessControlModel`. +- Add seed concepts, relationship vocabulary, patterns, and profiles. +- Define validation rules. +- Align with Organization, Governance, Landscape, Task, and Tagging. + +## Phase 2: First Assimilations + +Recommended first assimilations: + +```text +NIST / INCITS RBAC +NIST SP 800-162 ABAC +Kubernetes RBAC +Keycloak roles and authorization services +privacyIDEA policies and MFA model +OpenFGA / Zanzibar +OPA / Rego +Cedar / Amazon Verified Permissions +SCIM 2.0 +OAuth 2.0 / OIDC +``` + +## Phase 3: Profile Maturation + +- Mature Small SaaS Access Profile. +- Mature Kubernetes RBAC Profile. +- Mature Keycloak Authorization Profile. +- Mature Agent Access Profile. +- Mature Ops / Break-Glass Access Profile. + +## Phase 4: Tooling Integration + +- Generate concept indexes. +- Generate agent brief. +- Create machine-readable YAML/JSON exports. +- Add validation scripts. +- Use in `user-engine`, `user-accounts`, `user-manager`, `OpsBridge`, `Keycape`, `NetKingdom`, and production-readiness tooling. + +## Phase 5: Security Integration + +- Feed access findings into Security Model. +- Connect access reviews to Governance. +- Connect privileged actions to observability and audit evidence. +- Connect access remediation to Task Model. + +--- + +# 26. Summary + +The InfoTechCanon Access Control Model is the seed standard for representing authorization semantics across human, system, service, platform, and agentic access. + +Its most important commitments are: + +```text +Separate authentication from authorization. + +Separate organizational roles from access roles. + +Represent access as subject, action, resource, context, decision, and enforcement. + +Support RBAC, ABAC, ReBAC, ACL, PBAC, and hybrid models without being captured by one. + +Make grants, permissions, decisions, enforcement, sessions, reviews, and evidence explicit. + +Treat service-account, privileged, temporary, break-glass, and agent access as first-class patterns. + +Map to external standards and tools without surrendering internal semantic autonomy. +``` + +This makes the Access Control Model a core seed for production readiness, user management, operational access, security posture, agent boundaries, and interoperable authorization across the InfoTechCanon ecosystem. diff --git a/seeds/InfoTechCanonCaringAccessGovernanceStandard.md b/seeds/InfoTechCanonCaringAccessGovernanceStandard.md new file mode 100755 index 0000000..9afb7ca --- /dev/null +++ b/seeds/InfoTechCanonCaringAccessGovernanceStandard.md @@ -0,0 +1,5413 @@ +--- +id: itc-caring:CaringAccessGovernanceStandard +title: InfoTechCanon CARING Access Governance Standard +short_name: CARING +type: specialized-standard +standard_family: InfoTechCanon +repository_context: info-tech-canon +recommended_path: standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md +status: release-candidate +version: 0.4.0-RC2-itc1 +source_version: 0.4.0-RC2 +source_file: CareNeedsGovernanceStandard.md +canonical_owner: InfoTechCanonCaringAccessGovernanceStandard +namespace: itc-caring +classification: standard +primary_cluster: access-governance +imports: + - InfoTechCanonCore + - InfoTechCanonOrganizationModel + - InfoTechCanonGovernanceModel + - InfoTechCanonAccessControlModel + - InfoTechCanonSecurityModel + - InfoTechCanonDataModel + - InfoTechCanonDevSecOpsModel + - InfoTechCanonNetworkModel + - InfoTechCanonObservabilityModel + - InfoTechCanonTaskModel + - InfoTechCanonTaggingStandard +related: + - InfoTechCanonKernelMap + - InfoTechCanonAccessControlModel + - InfoTechCanonGovernanceModel + - InfoTechCanonSecurityModel +owned_concepts: + - CARINGAccessDescriptor + - CARINGCanonicalRole + - CARINGOrganizationRelation + - CARINGPlane + - CARINGCapabilityProfile + - CARINGExposureMode + - CARINGExposureEvent + - CARINGDeclaredAccessMap + - CARINGEffectiveAccessMap + - CARINGDerivedCapability + - CARINGInducedAccess + - CARINGRestrictionPrecedence + - CARINGAnalysisFitnessTest + - CARINGAnalysisProcedure + - CARINGRedesignProcedure +created_at: 2026-05-23 +updated_at: 2026-05-23 +--- + +# InfoTechCanon CARING Access Governance Standard + +**CARING:** Canonical Access Roles for Information Needs Governance +**Document Status:** Release Candidate, InfoTechCanon-aligned refactor +**Source Version:** 0.4.0-RC2 +**Canon Version:** 0.4.0-RC2-itc1 +**Document Type:** Specialized InfoTechCanon Standard +**Recommended Repository Path:** `standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md` + +--- + +# 0. InfoTechCanon Integration Preface + +## 0.1 Classification + +CARING is a **named specialized standard** in the InfoTechCanon structure. + +It is not a generic domain model and it is not merely a profile of the Access Control Model. + +```text +Kernel + InfoTechCanonCore + InfoTechCanonKernelMap + +Models + Landscape, Organization, Governance, Task, Access Control, Security, + Data, DevSecOps, Network, Observability, Information Space + +Standards + InfoTechCanonTaggingStandard + InfoTechCanonCaringAccessGovernanceStandard +``` + +CARING defines a named orthogonal framework for access-governance analysis and design. It composes concepts from Access Control, Organization, Governance, Security, Data, DevSecOps, Network, Observability, Task, and Tagging, but it also owns several distinctive access-governance concepts. + +## 0.2 Canonical Name and Namespace + +Canonical file name: + +```text +InfoTechCanonCaringAccessGovernanceStandard.md +``` + +Recommended namespace: + +```text +itc-caring +``` + +Recommended repository placement: + +```text +info-tech-canon/ + standards/ + caring/ + InfoTechCanonCaringAccessGovernanceStandard.md + agent-brief.md + concepts/ + profiles/ + mappings/ + benchmarks/ + examples/ + validation/ +``` + +## 0.3 Purpose in the Kernel + +CARING provides a rigorous way to analyze and design access governance by separating access into independent dimensions: + +```text +Subject +Organization Relation +Canonical Role +Scope +Plane +Capability +Exposure Mode +Condition +Lifecycle State +Restriction +Exposure Event +``` + +Its strongest kernel contribution is the disciplined separation of local or native access constructs from canonical access-governance meaning. + +A native construct named `role` may be a role, a capability profile, a group, a local title, a policy object, a rule bundle, or an access assignment. CARING requires analysis of the actual semantics before mapping. + +## 0.4 Imports from Generic Models + +CARING imports the following generic model concepts instead of redefining them: + +| Imported Concept Area | Canonical Source | +|---|---| +| Canon artifacts, mappings, profiles, validation, conformance | InfoTechCanonCore | +| Actors, persons, teams, organizations, authority, responsibility | InfoTechCanonOrganizationModel | +| Policies, exceptions, controls, reviews, evidence, obligations | InfoTechCanonGovernanceModel | +| Subjects, principals, permissions, grants, decisions, enforcement | InfoTechCanonAccessControlModel | +| Threat, exposure, security finding, privilege escalation, secret exposure | InfoTechCanonSecurityModel | +| Dataset, field, data classification, masking, pseudonymity, retention | InfoTechCanonDataModel | +| Pipeline identity, build, deploy, workload creation, artifact delivery | InfoTechCanonDevSecOpsModel | +| Cluster, namespace, network reachability, endpoint exposure | InfoTechCanonNetworkModel | +| Audit logs, access events, post-review evidence, session recordings | InfoTechCanonObservabilityModel | +| Remediation, review, redesign, access-review work items | InfoTechCanonTaskModel | +| Classification of descriptors, findings, benchmark cases | InfoTechCanonTaggingStandard | + +## 0.5 Concepts Owned by CARING + +CARING owns its distinctive analytical dimensions and procedures: + +```text +CARINGAccessDescriptor +CARINGCanonicalRole +CARINGOrganizationRelation +CARINGPlane +CARINGCapabilityProfile +CARINGExposureMode +CARINGExposureEvent +CARINGDeclaredAccessMap +CARINGEffectiveAccessMap +CARINGDerivedCapability +CARINGInducedAccess +CARINGRestrictionPrecedence +CARINGAnalysisFitnessTest +CARINGAnalysisProcedure +CARINGRedesignProcedure +CARINGBenchmarkCorpus +``` + +## 0.6 Boundary Rules + +```text +Organization Role != AccessRole != CARINGCanonicalRole +``` + +- **Organization Role** is a pattern of responsibility, authority, participation, or behavior. +- **AccessRole** is a permission-bearing construct in an authorization model. +- **CARINGCanonicalRole** is a lifecycle responsibility posture used for access-governance analysis. + +```text +CARING Plane != InfoTechCanon Domain +``` + +A CARING Plane is an access surface such as Build, Runtime, Data, Identity, Policy, Secret, or Audit. It may map to InfoTechCanon domains, but it does not replace those domains. + +```text +CARING Scope != ResourceScope != Landscape Scope +``` + +A CARING Scope is an access-governance boundary. It may map to an Access Control resource scope or a Landscape containment boundary, but the mapping must be explicit. + +```text +Namespace != Tenant Boundary +``` + +A namespace may support tenant isolation, but it MUST NOT be treated as a tenant boundary unless the wider effective access model supports that claim. + +## 0.7 Relationship to the Access Control Model + +The Access Control Model owns the generic authorization primitives: + +```text +Subject +Principal +Resource +Action +Permission +Privilege +Entitlement +Grant +AccessRole +AuthorizationRequest +AuthorizationDecision +PolicyEnforcementPoint +AccessReview +``` + +CARING specializes these into an analysis and design grammar that asks: + +```text +Who or what acts? +Under whose authority? +In which lifecycle responsibility posture? +Within which scope? +On which access plane? +With which capabilities? +With what exposure mode? +Under what conditions? +For which lifecycle state? +Subject to which restrictions? +And when does access become exceptional or irregular? +``` + +## 0.8 Relationship to Governance and Security + +Governance owns policies, exceptions, approvals, reviews, controls, risk, and evidence. + +Security owns threats, vulnerabilities, exposure, security findings, attack paths, incidents, and mitigations. + +CARING sits between them for access governance. It identifies declared access, effective access, induced access, exposure modes, exposure events, tenant-boundary findings, and privilege-escalation findings. Those outputs should then connect to Governance reviews, Security findings, Access Control remediation, Task work items, and Observability evidence. + +## 0.9 Recommended Companion Files + +```text +standards/caring/agent-brief.md +standards/caring/concepts/caring-access-descriptor.md +standards/caring/concepts/caring-canonical-role.md +standards/caring/concepts/caring-plane.md +standards/caring/concepts/exposure-mode.md +standards/caring/concepts/exposure-event.md +standards/caring/mappings/caring-to-access-control.md +standards/caring/mappings/caring-to-governance.md +standards/caring/mappings/caring-to-security.md +standards/caring/profiles/kubernetes-rbac-caring-profile.md +standards/caring/profiles/agentic-access-caring-profile.md +standards/caring/benchmarks/kubernetes-rbac/ +standards/caring/benchmarks/lotus-domino-acl/ +``` + +## 0.10 Refactor Notes + +This file preserves the substantive CARING 0.4.0-RC2 content while renaming and positioning the standard according to the InfoTechCanon kernel structure. + +Future refinement should: + +```text +1. Extract each CARING dimension into its own concept page. +2. Create machine-readable schemas for CARING access descriptors. +3. Add mappings to InfoTechCanon Access Control, Governance, Security, Data, DevSecOps, Network, and Observability. +4. Add benchmark cases, starting with Kubernetes RBAC and Lotus/Domino ACL. +5. Add an agent brief for access-analysis tasks. +``` + +--- + +# Original CARING Standard Content, Canon-Aligned + +## 1. Purpose + +CARING — **Canonical Access Roles for Information Needs Governance** — provides a practical, canonical vocabulary for describing and governing access to information systems across the full lifecycle of an information product. + +It is intended for systems where humans, services, automations, AI agents, organizations, customers, communities, vendors, service providers, consultants, and authorities collaborate across product creation, deployment, operation, support, use, feedback, continuous improvement, and exceptional access events. + +CARING exists to prevent access-control systems from degrading into unmanaged collections of local roles, implicit exceptions, historical permissions, support backdoors, hidden operator powers, unclear tenant boundaries, uncontrolled service accounts, induced privilege paths, and poorly understood data-exposure risks. + +CARING is not tied to one access-control technology. It may be mapped to IAM roles, ACLs, RBAC groups, ABAC policies, ReBAC relations, service accounts, workflow permissions, database grants, Kubernetes permissions, Git permissions, support tooling, agent execution policies, runtime controllers, CI/CD pipelines, or other access-control mechanisms. + +--- + +## 2. Core Hypothesis + +CARING is based on the following hypothesis: + +> Existing access-control implementations can be analyzed as compositions of CARING dimensions. A successful CARING mapping reconstructs the implementation’s declared and effective access semantics while revealing bundled roles, missing scopes, hidden exposures, weak lifecycle controls, restrictive design choices, induced access paths, and governance gaps. + +A CARING analysis is considered successful when an access-control implementation can be rebuilt as a set of CARING access descriptors without introducing ad-hoc concepts outside the standard. + +If an implementation cannot be modeled cleanly, the mismatch is itself valuable. It may indicate: + +```text + +1. A genuine gap in CARING. + +2. An implementation-specific constraint below CARING’s abstraction level. + +3. Hidden authority. + +4. Ambiguous scope. + +5. Mixed responsibility. + +6. Implicit exposure. + +7. Missing lifecycle governance. + +8. An unmanaged exception path. + +9. A gap between declared access and effective access. + +10. An induced access path through automation, controllers, agents, services, or workflows. + +``` + +This makes CARING both a standard and an evolving analytical framework. + +--- + +## 3. Descriptive and Prescriptive Use + +CARING may be used in two modes. + +### 3.1 Descriptive CARING + +Descriptive use maps an existing access-control implementation into CARING dimensions. + +The purpose is to answer: + +```text + +What does this system actually allow, deny, expose, obscure, delegate, induce, or fail to govern? + +``` + +Outputs may include: + +```text + +Access descriptor catalog + +Capability profile map + +Declared access map + +Effective access map + +Derived capability map + +Scope model + +Plane classification + +Exposure map + +Restriction map + +Lifecycle access map + +Exceptional access map + +Role bundling findings + +Tenant-boundary findings + +Privilege-escalation findings + +Induced-access findings + +Redesign recommendations + +``` + +### 3.2 Prescriptive CARING + +Prescriptive use designs or improves an access-control model using CARING dimensions. + +The purpose is to answer: + +```text + +How should access be structured for clarity, safety, speed, collaboration, and governance? + +``` + +Outputs may include: + +```text + +Canonical role model + +Capability profiles + +Scope hierarchy + +Plane model + +Exposure rules + +Condition rules + +Agent access ceilings + +Service-account rules + +Exception workflows + +Review cycles + +Governance controls + +Policy linting rules + +Conformance tests + +``` + +CARING does not require an existing system to be well-designed in order to describe it. + +--- + +## 4. Core Principle: Orthogonality + +CARING separates access governance into independent dimensions. + +The core dimensions are: + +```text + +Subject + +Organization Relation + +Canonical Role + +Scope + +Plane + +Capability + +Exposure Mode + +Condition + +Lifecycle State + +Restriction + +Exposure Event + +``` + +No single dimension should be overloaded to express all others. + +A role does not fully define access. + +A role only becomes an effective access policy when combined with organization relation, scope, plane, capability, exposure mode, conditions, lifecycle controls, and restrictions. + +--- + +## 5. Native Role Warning + +Many systems use the word **role** for constructs that are not equivalent to a CARING Canonical Role. + +A native construct named `role` may represent: + +```text + +A capability profile + +A local title + +A group + +A rule bundle + +A policy object + +An access assignment + +A workflow responsibility + +An application-specific modifier + +``` + +Therefore: + +> A native construct named “role” SHOULD NOT be assumed to map to a CARING Canonical Role. It must be analyzed according to its actual semantics. + +Examples: + +```text + +A Lotus/Domino ACL level such as Reader or Editor + +→ usually a Capability Profile under Doer. + +A Kubernetes Role + +→ usually a Capability Profile over verbs, resources, and scope. + +A business title such as Department Admin + +→ usually a Local Title that must be mapped to role, scope, plane, and capabilities. + +``` + +--- + +## 6. CARING Access Descriptor + +Every relevant access assignment should be expressible as: + +```text + +Subject + +has Canonical Role + +from Organization Relation + +within Scope + +on Plane + +with Capabilities + +under Conditions + +with Exposure Mode + +for Lifecycle State + +unless overridden by Restrictions + +or classified as an Exposure Event. + +``` + +Example: + +```text + +A Vendor Operator + +may restart production services + +for Tenant Alpha + +on the Runtime Plane + +with Operate and Restore capabilities + +under ticket + MFA + audit conditions + +with metadata-only exposure + +for incident recovery. + +``` + +This is different from: + +```text + +A Customer Operator + +may restart customer-managed automations + +inside Workspace Finance + +on the Execution Plane + +with Operate capability + +under tenant policy + +with no platform access. + +``` + +Same canonical role word: **Operator**. + +Different organization relation, scope, plane, exposure, and governance context. + +--- + +## 7. Declared Access and Effective Access + +CARING distinguishes declared access from effective access. + +### 7.1 Declared Access + +**Declared Access** is access explicitly represented by the native access-control system. + +Examples: + +```text + +A database ACL grants Editor. + +A Kubernetes Role grants create pods. + +An IAM policy allows s3:GetObject. + +A Git repository role grants Maintainer. + +``` + +### 7.2 Effective Access + +**Effective Access** is access that can actually be achieved through direct, delegated, mediated, derived, or induced execution paths. + +Examples: + +```text + +A user can create a workload. + +The workload can mount a service account. + +The service account can read secrets. + +Therefore the user may effectively gain secret exposure. + +``` + +### 7.3 Analysis Requirement + +CARING analysis MUST attempt to reconstruct effective access, not merely declared access. + +A CARING map that only records declared policy may miss the actual security posture of a system. + +--- + +## 8. Derived Capability + +A **Derived Capability** is a capability that is not directly granted as a named permission, but becomes available as a consequence of another permission. + +Example: + +```text + +Declared capability: + + Create workload. + +Derived capabilities: + + Execute code. + + Use mounted secrets. + + Use mounted service account. + + Access mounted volumes. + +``` + +Derived capabilities are especially important in: + +```text + +Kubernetes and container platforms + +CI/CD systems + +Workflow engines + +Agentic coding systems + +Automation platforms + +Plugin systems + +Integration platforms + +Low-code/no-code platforms + +``` + +CARING analysis SHOULD identify derived capabilities where they materially affect exposure, scope, tenant isolation, or privilege escalation. + +--- + +# Part I — Core Dimensions + +--- + +## 9. Dimension: Subject + +A **Subject** is the entity to which access may be assigned or attributed. + +Canonical subject types: + +```text + +Human + +Group + +Organization + +Service + +Automation + +Agent + +System + +Device + +Process + +Anonymous + +Unknown + +``` + +### 9.1 Human + +A natural person acting directly. + +Examples: + +```text + +Developer + +Customer employee + +Consultant + +Support agent + +Auditor + +Trainer + +``` + +### 9.2 Group + +A collection of subjects. + +Groups are assignment conveniences. They are not equivalent to canonical roles. + +### 9.3 Organization + +A legal, contractual, commercial, or community entity. + +Examples: + +```text + +Vendor company + +Customer company + +Consultancy + +Open-source foundation + +Regulator + +``` + +### 9.4 Service + +A non-human technical identity that performs system functions. + +Examples: + +```text + +Service account + +Database replication identity + +CI/CD runner identity + +Monitoring service + +Operator controller + +Kubernetes ServiceAccount + +``` + +### 9.5 Automation + +A deterministic or semi-deterministic mechanism executing defined tasks. + +Examples: + +```text + +Scheduled job + +Workflow automation + +Deployment pipeline + +Import job + +Backup job + +``` + +### 9.6 Agent + +A goal-seeking or semi-autonomous subject, often AI-supported, that acts through tools, workflows, or APIs. + +Examples: + +```text + +Coding agent + +Support agent + +Ops remediation agent + +Research agent + +Policy review agent + +``` + +### 9.7 System + +A larger technical system treated as an acting subject. + +Examples: + +```text + +Identity provider + +Cluster controller + +Replication system + +Managed service + +``` + +### 9.8 Device + +A hardware or virtual device acting as or constraining a subject. + +Examples: + +```text + +Trusted workstation + +Mobile device + +Hardware security module + +IoT device + +``` + +### 9.9 Process + +An executing runtime process with attributable behavior. + +Examples: + +```text + +Application process + +Worker process + +Container process + +Agent runtime process + +``` + +### 9.10 Anonymous + +A subject without authenticated identity. + +### 9.11 Unknown + +A subject that cannot be classified or identified. + +This includes adversarial, accidental, misconfigured, or not-yet-classified access attempts. + +--- + +## 10. Dimension: Organization Relation + +The **Organization Relation** describes the structural relationship of the subject to the information product, tenant, operating environment, or governance context. + +It is not a role. + +Canonical organization relations: + +```text + +Vendor + +ServiceProvider + +Distributor + +Consultant + +Customer + +Community + +Authority + +Unknown + +``` + +### 10.1 Vendor + +The entity that creates, owns, licenses, or governs the product or core platform. + +Examples: + +```text + +Vendor Builder + +Vendor Maintainer + +Vendor Operator + +Vendor Coach + +Vendor Integrator + +``` + +### 10.2 ServiceProvider + +An entity that operates the system or parts of it on behalf of another party. + +The ServiceProvider may be the same legal entity as the Vendor, but should still be conceptually separable. + +Examples: + +```text + +ServiceProvider Operator + +ServiceProvider Integrator + +ServiceProvider Manager + +``` + +### 10.3 Distributor + +An entity that brings the product to market, resells it, bundles it, or introduces it to customers. + +Examples: + +```text + +Distributor Coach + +Distributor Integrator + +Distributor Manager + +``` + +### 10.4 Consultant + +An entity that helps configure, customize, adopt, extend, or optimize the system. + +Examples: + +```text + +Consultant Integrator + +Consultant Coach + +Consultant Builder + +Consultant Manager + +``` + +### 10.5 Customer + +The tenant, buyer, subscriber, internal department, business unit, or end organization using the information product. + +Examples: + +```text + +Customer Manager + +Customer Doer + +Customer Operator + +Customer Coach + +``` + +### 10.6 Community + +A participant who contributes feedback, code, documentation, extensions, issue reports, tests, examples, training material, governance input, or public knowledge without necessarily belonging to the vendor or customer organization. + +Examples: + +```text + +Community Builder + +Community Maintainer + +Community Coach + +Community Verifier + +``` + +### 10.7 Authority + +A legal, regulatory, or institutional entity with exceptional access claims. + +Authority access should normally be modeled as an exposure event, not as ordinary standing access. + +Examples: + +```text + +Authority LegalDemand + +Authority AuditDemand + +Authority DisclosureDemand + +``` + +### 10.8 Unknown + +An organization relation that is unidentified, untrusted, adversarial, anonymous, or not yet classified. + +--- + +## 11. Dimension: Canonical Role + +A **Canonical Role** describes the lifecycle responsibility posture of a subject toward an information product, system, tenant, resource, or process. + +A canonical role is not a permission level. + +CARING defines nine primary canonical roles: + +```text + +Creator + +Builder + +Verifier + +Maintainer + +Integrator + +Operator + +Manager + +Coach + +Doer + +``` + +These are deliberately limited. + +Local systems may define additional titles, groups, application-specific roles, or native policy objects, but they should be mapped to these canonical roles where possible. + +--- + +## 12. Role: Creator + +The **Creator** provides original intent, concept, purpose, direction, or authority of meaning. + +The Creator may define why the system exists, what problem it solves, what values shape it, and what boundaries should be respected. + +Typical access needs: + +```text + +Intent + +Scope + +Roadmap + +Concept + +Requirements + +Product direction + +Vision documents + +``` + +Not automatically granted: + +```text + +Production data + +Runtime operation + +Tenant administration + +Customer plaintext + +Policy override + +``` + +Examples: + +```text + +Vendor Creator + +Community Creator + +Customer Creator + +``` + +--- + +## 13. Role: Builder + +The **Builder** creates or modifies system artifacts. + +This includes code, configuration templates, schemas, UI components, workflows, automations, agent prompts, tests, deployment definitions, documentation, integration adapters, and models. + +Typical access needs: + +```text + +Source repositories + +Development environments + +Test data + +Build systems + +Design documents + +Issue context + +Generated artifacts + +``` + +Not automatically granted: + +```text + +Production operation + +Customer plaintext + +Policy management + +Tenant-wide data access + +Secret access + +``` + +Examples: + +```text + +Vendor Builder + +Community Builder + +Consultant Builder + +Customer Builder + +AI Coding Agent as Builder + +CI/CD Service as Builder + +``` + +--- + +## 14. Role: Verifier + +The **Verifier** checks correctness, safety, quality, compliance, security, and fit to intent. + +Verifier deserves canonical status because fast agentic innovation cycles require continuous independent checking. + +Typical access needs: + +```text + +Test systems + +Logs + +Evidence + +Requirements + +Security findings + +Quality reports + +Acceptance criteria + +Audit records + +``` + +Common verifier modes: + +```text + +Quality Verifier + +Security Verifier + +Compliance Verifier + +Acceptance Verifier + +Policy Verifier + +``` + +Not automatically granted: + +```text + +Unbounded production write access + +Customer plaintext + +Policy override + +Destructive access + +``` + +Examples: + +```text + +Vendor Verifier + +Customer Verifier + +Community Verifier + +Authority Verifier + +AI Test Agent as Verifier + +Monitoring Service as Verifier + +``` + +--- + +## 15. Role: Maintainer + +The **Maintainer** keeps a product, component, information space, or artifact coherent over time. + +Maintainers coordinate feedback, bugs, releases, patches, compatibility, deprecation, community interaction, and lifecycle continuity. + +Typical access needs: + +```text + +Issue tracker + +Release planning + +Change approval + +Merge coordination + +Documentation + +Version history + +Support escalation context + +Community discussions + +``` + +Not automatically granted: + +```text + +Runtime operation + +Tenant content + +Production secrets + +Customer data + +Unbounded policy authority + +``` + +Examples: + +```text + +Vendor Maintainer + +Community Maintainer + +Customer Maintainer + +Repository Maintainer + +``` + +--- + +## 16. Role: Integrator + +The **Integrator** connects, installs, configures, migrates, adapts, or ramps up a system for a specific environment. + +Integrator is not a generic administrator. Integrator is a lifecycle role around bringing a system into a working context. + +Typical access needs: + +```text + +Setup + +Initial configuration + +Environment connection + +Identity federation + +Data migration + +API integration + +Tenant onboarding + +System handover + +Acceptance preparation + +``` + +Critical characteristic: + +```text + +Integrator access should usually be temporary. + +``` + +Default lifecycle: + +```text + +Pre-production + +Onboarding + +Migration + +Handover + +Post-go-live support window + +Expiry + +``` + +Examples: + +```text + +Vendor Integrator + +ServiceProvider Integrator + +Distributor Integrator + +Consultant Integrator + +Customer Integrator + +Automation Integrator + +``` + +--- + +## 17. Role: Operator + +The **Operator** keeps the system running. + +This role covers monitoring, incident response, backup, restore, updates, scaling, technical health, runtime intervention, and service continuity. + +Typical access needs: + +```text + +Runtime status + +Deployment state + +Logs + +Metrics + +Alerts + +Backup and restore + +Job control + +Infrastructure control + +Incident tooling + +Operational dashboards + +``` + +Not automatically granted: + +```text + +Business content + +Tenant plaintext + +Policy grant authority + +Customer impersonation + +Bulk export + +Product modification + +``` + +Principle: + +```text + +Operator access is runtime continuity access, not automatic information access. + +``` + +Examples: + +```text + +Vendor Operator + +ServiceProvider Operator + +Customer Operator + +Automation Operator + +Ops Agent as Operator + +Kubernetes Controller as Operator + +``` + +--- + +## 18. Role: Manager + +The **Manager** governs a bounded information, application, tenant, process, or policy scope. + +Manager captures framework-bound administration, customization, configuration, and data governance. + +Manager is not a generic super-admin. + +Manager means: + +```text + +Can shape the system within a defined governance boundary. + +``` + +Typical access needs: + +```text + +Application configuration + +Tenant settings + +Workspace settings + +User and group assignment + +Business rules + +Workflow configuration + +Data lifecycle settings + +Template management + +Controlled access delegation + +Policy administration within scope + +``` + +Manager can exist at many scopes: + +```text + +Tenant Manager + +Workspace Manager + +Project Manager + +Dataset Manager + +Workflow Manager + +Policy Manager + +Namespace Manager + +``` + +But CARING does not create separate canonical roles for each. The role remains **Manager**; the scope defines the boundary. + +Distinction from Operator: + +```text + +Operator keeps the system running. + +Manager shapes how the system is used. + +``` + +Distinction from Builder: + +```text + +Builder changes the product or artifact. + +Manager changes allowed configuration within the product. + +``` + +--- + +## 19. Role: Coach + +The **Coach** helps others understand, adopt, use, sell, teach, support, or improve their practical use of the system. + +Coach unifies promoter, consultant, trainer, supporter, success guide, and similar roles under one canonical role. + +Typical access needs: + +```text + +Demo spaces + +Training material + +Support cases + +Usage analytics + +Configuration advice + +Customer context + +Documentation + +Best practices + +``` + +Common coach modes: + +```text + +Promoter + +Trainer + +Supporter + +Consultant + +Success Guide + +Community Guide + +``` + +The canonical role remains Coach. + +Examples: + +```text + +Vendor Coach + +Distributor Coach + +Consultant Coach + +Customer Coach + +Community Coach + +AI Support Agent as Coach + +``` + +Coach access should often be: + +```text + +Case-scoped + +Delegated + +Time-limited + +Masked by default + +Audited + +Purpose-bound + +``` + +--- + +## 20. Role: Doer + +The **Doer** uses the system to perform actual work. + +This is the business-use role. + +Typical access needs: + +```text + +Read + +Create + +Edit + +Comment + +Submit + +Approve + +Execute + +Publish + +Collaborate + +Consume information + +Produce information + +``` + +Doer is not a single permission level. + +Capability profiles such as Reader, Author, Editor, Depositor, Approver, Publisher, or Executor may be modeled under Doer. + +Examples: + +```text + +Customer Doer + +Community Doer + +Vendor Doer + +External Doer + +``` + +--- + +## 21. Dimension: Scope + +Scope defines where the role applies. + +Scope prevents canonical roles from exploding into countless local variants. + +Canonical scope ladder: + +```text + +Ecosystem + +Product + +Platform + +Cluster + +Environment + +Tenant + +Namespace + +Domain + +Workspace + +Project + +Process + +Dataset + +Resource + +Subresource + +Record + +Field + +Action + +``` + +### 21.1 Ecosystem + +The whole collaboration environment: vendor, community, distributors, customers, services, extensions, agents, governance processes, and shared artifacts. + +### 21.2 Product + +The information product or software product as a governed artifact. + +### 21.3 Platform + +Shared infrastructure, shared services, runtime substrate, or common technical foundation. + +### 21.4 Cluster + +A bounded infrastructure or runtime control domain. + +Example: + +```text + +Kubernetes cluster + +Database cluster + +Search cluster + +Compute cluster + +``` + +Cluster is not automatically equivalent to tenant or environment. + +### 21.5 Environment + +Development, test, staging, production, sandbox, demo, customer-managed instance, etc. + +### 21.6 Tenant + +A customer or isolated organizational unit. + +Tenant should be treated as a structural isolation boundary, not merely as a group. + +### 21.7 Namespace + +A technical partition inside a platform, cluster, product, tenant, or environment. + +Examples: + +```text + +Kubernetes namespace + +Object-store namespace + +Package namespace + +Application namespace + +``` + +Namespace may be used for tenant separation, but it is not automatically a tenant boundary. + +### 21.8 Domain + +A tenant-internal domain such as finance, HR, legal, operations, procurement, support, engineering, or sales. + +### 21.9 Workspace + +A collaborative space, team space, department, case room, project area, or knowledge area. + +### 21.10 Project + +A bounded effort or initiative. + +### 21.11 Process + +A workflow or business process. + +### 21.12 Dataset + +A collection of information objects. + +### 21.13 Resource + +A specific document, entity, file, ticket, record collection, dashboard, agent, automation, repository, model, API, workload, deployment, secret, service account, or system component. + +### 21.14 Subresource + +A subordinate access surface of a resource. + +Examples: + +```text + +pods/log + +pods/exec + +deployments/scale + +nodes/proxy + +object/metadata + +object/content + +``` + +### 21.15 Record + +An individual business object. + +### 21.16 Field + +A specific attribute or field. + +Example: + +```text + +Customer Doer may read Employee Record + +but not Salary Field. + +``` + +### 21.17 Action + +A specific operation. + +Example: + +```text + +May approve payment + +but may not edit payment recipient. + +``` + +--- + +## 22. Dimension: Plane + +Plane defines what kind of system layer or access surface is being accessed. + +Canonical planes: + +```text + +Intent Plane + +Build Plane + +Runtime Plane + +Execution Plane + +Configuration Plane + +Data Plane + +Identity Plane + +Policy Plane + +Secret Plane + +Audit Plane + +Commercial Plane + +Community Plane + +``` + +### 22.1 Intent Plane + +Purpose, scope, requirements, values, roadmap, product direction, governance intent. + +Typical roles: + +```text + +Creator + +Manager + +Maintainer + +Verifier + +``` + +### 22.2 Build Plane + +Source code, artifacts, schemas, tests, pipelines, documentation, models, prompts, agent recipes. + +Typical roles: + +```text + +Builder + +Verifier + +Maintainer + +``` + +### 22.3 Runtime Plane + +Deployments, jobs, services, health, incidents, monitoring, scaling, backups, runtime objects. + +Typical roles: + +```text + +Operator + +Integrator + +Verifier + +``` + +### 22.4 Execution Plane + +The ability to cause code, jobs, commands, workflows, agents, scripts, or workloads to run. + +Typical roles: + +```text + +Operator + +Builder + +Doer + +Automation + +Agent + +``` + +Execution Plane is separated from Runtime Plane because the ability to run something may create derived or induced access beyond ordinary runtime visibility. + +### 22.5 Configuration Plane + +Application settings, tenant settings, workflows, templates, business rules, integrations, config maps, feature flags. + +Typical roles: + +```text + +Manager + +Integrator + +Coach + +``` + +### 22.6 Data Plane + +Business content, documents, records, messages, files, knowledge, operational data. + +Typical roles: + +```text + +Doer + +Manager + +Coach + +Verifier + +``` + +### 22.7 Identity Plane + +Users, groups, service accounts, agents, federation, authentication, lifecycle, certificates. + +Typical roles: + +```text + +Manager + +Integrator + +Operator + +Verifier + +``` + +### 22.8 Policy Plane + +Authorization rules, ACLs, approval flows, restrictions, delegation boundaries, role bindings, policy objects. + +Typical roles: + +```text + +Manager + +Verifier + +Maintainer + +``` + +### 22.9 Secret Plane + +Keys, credentials, certificates, tokens, encryption material, signing keys, recovery keys. + +Typical roles: + +```text + +Operator + +Integrator + +Verifier + +``` + +Secret Plane access should usually be heavily restricted, separated, and audited. + +### 22.10 Audit Plane + +Logs, access records, evidence, compliance reports, security findings, traceability. + +Typical roles: + +```text + +Verifier + +Operator + +Manager + +Authority + +``` + +### 22.11 Commercial Plane + +Contracts, subscriptions, billing, license entitlements, quotas, purchased modules, commercial terms. + +Typical roles: + +```text + +Manager + +Coach + +Distributor + +Vendor + +``` + +### 22.12 Community Plane + +Issues, pull requests, discussions, public docs, contribution records, extension catalogs, reputation, public roadmap. + +Typical roles: + +```text + +Community Builder + +Community Maintainer + +Community Coach + +Community Verifier + +``` + +--- + +## 23. Dimension: Capability + +Capabilities describe what can be done. + +Roles must not be confused with capabilities. + +Canonical capability verbs: + +```text + +View + +ViewCollection + +Observe + +Create + +EditOwn + +EditAssigned + +EditAny + +DeleteOwn + +DeleteAny + +BulkDelete + +Submit + +Comment + +Review + +Approve + +Reject + +Publish + +Archive + +Restore + +Execute + +Configure + +Operate + +Deploy + +Integrate + +Grant + +Revoke + +Delegate + +Impersonate + +Export + +Import + +Replicate + +Encrypt + +Decrypt + +Mask + +Inspect + +Audit + +Override + +Escalate + +Bind + +Use + +``` + +### 23.1 Capability Profiles + +A **Capability Profile** is a named bundle of capabilities. + +Capability profiles are useful for human understanding and compatibility with existing systems. + +Examples: + +```text + +Reader + +Author + +Contributor + +Editor + +Depositor + +Approver + +Publisher + +Designer + +RuntimeOperator + +TenantManager + +DatabaseManager + +NamespaceAdmin + +ClusterAdmin + +``` + +Capability profiles are not canonical roles. They should be mapped to canonical roles, scopes, planes, and capabilities. + +--- + +## 24. Common Capability Profiles + +### 24.1 Reader + +```text + +Canonical Role: + + Doer + +Capabilities: + + View + +Plane: + + Data + +Exposure: + + Plaintext or masked, depending on data policy + +``` + +### 24.2 Contributor / Author + +```text + +Canonical Role: + + Doer + +Capabilities: + + View + + Create + + EditOwn or EditAssigned + +Plane: + + Data + +``` + +### 24.3 Editor + +```text + +Canonical Role: + + Doer + +Capabilities: + + View + + Create + + EditOwn + + EditAny + +Plane: + + Data + +``` + +### 24.4 Depositor / Submitter + +```text + +Canonical Role: + + Doer + +Capabilities: + + Submit + + Create + +Not granted: + + View + +Plane: + + Data + +Exposure: + + None or minimal confirmation after submission + +``` + +### 24.5 Designer + +```text + +Canonical Role: + + Builder + +Capabilities: + + Create + + EditAny + + Configure + + Review + +Plane: + + Build / Configuration + +``` + +### 24.6 Runtime Operator + +```text + +Canonical Role: + + Operator + +Capabilities: + + Operate + + Restore + + Inspect + + Deploy, if authorized + +Plane: + + Runtime + +``` + +### 24.7 Tenant Manager + +```text + +Canonical Role: + + Manager + +Capabilities: + + Configure + + Grant + + Revoke + + Delegate + + Archive + + Restore + +Scope: + + Tenant + +``` + +### 24.8 Namespace Manager + +```text + +Canonical Role: + + Manager + +Capabilities: + + Configure + + Grant + + Revoke + + Bind + + Create + + EditAny + + DeleteAny + +Scope: + + Namespace + +Planes: + + Runtime + + Configuration + + Policy + +``` + +### 24.9 Full Manager / Database Manager + +```text + +Canonical Role: + + Manager + +Capabilities: + + Configure + + Grant + + Revoke + + Delegate + + View + + Create + + EditAny + + DeleteAny + + Archive + + Restore + + Replicate, if authorized + +Planes: + + Policy + + Configuration + + Data + +``` + +This is a compound profile and should be treated as high authority. + +### 24.10 Cluster Superuser / Cluster Admin + +```text + +Canonical Roles: + + Operator + + Manager + + sometimes Integrator + +Capabilities: + + Operate + + Configure + + Grant + + Revoke + + Bind + + Escalate + + Override + + Impersonate, if included + + View + + Create + + EditAny + + DeleteAny + + Restore + +Scope: + + Cluster + +Planes: + + Runtime + + Execution + + Configuration + + Policy + + Identity + + Secret + + Audit + +``` + +This is a compound maximum-authority profile and should be treated as exceptional or highly controlled. + +--- + +## 25. Dimension: Exposure Mode + +Exposure Mode describes how much information the subject may perceive, derive, retain, extract, or transfer. + +Canonical exposure modes: + +```text + +None + +Metadata + +Masked + +Aggregated + +Synthetic + +Pseudonymous + +Encrypted + +Plaintext + +SecretMaterial + +Exportable + +CrossTenantAggregate + +``` + +### 25.1 None + +No information is exposed. + +### 25.2 Metadata + +Only metadata is exposed. + +Examples: + +```text + +Resource name + +Timestamp + +Status + +Size + +Owner identifier + +Record count + +Runtime status + +``` + +### 25.3 Masked + +Sensitive values are hidden or redacted. + +### 25.4 Aggregated + +Information is shown only in aggregated form. + +### 25.5 Synthetic + +Non-real information is used. + +Typical for development, testing, demos, and training. + +### 25.6 Pseudonymous + +Direct identifiers are replaced with pseudonyms. + +### 25.7 Encrypted + +Information is stored or transmitted but not intelligible to the subject. + +### 25.8 Plaintext + +The subject can perceive the real content. + +### 25.9 SecretMaterial + +The subject can perceive, copy, use, or derive secret material. + +Examples: + +```text + +Passwords + +API keys + +Private keys + +Tokens + +Certificates + +Session secrets + +Recovery material + +``` + +SecretMaterial is separated from ordinary Plaintext because it can create further access beyond the immediate system. + +### 25.10 Exportable + +The subject can extract, copy, replicate, download, forward, or otherwise remove information from its controlled context. + +Exportable is not implied by Plaintext. + +### 25.11 CrossTenantAggregate + +The subject can see aggregated information across tenants. + +This should be separately governed. + +Important rules: + +```text + +Plaintext is not implied by role. + +Exportable is not implied by plaintext. + +SecretMaterial is not ordinary plaintext. + +CrossTenantAggregate is not implied by platform access. + +Secret visibility is not implied by runtime visibility. + +``` + +--- + +## 26. Dimension: Condition + +Conditions define when and under what obligations access is valid. + +Canonical conditions: + +```text + +MFARequired + +DeviceTrusted + +NetworkTrusted + +TicketRequired + +TenantConsentRequired + +CustomerApprovalRequired + +DualApprovalRequired + +TimeLimited + +BusinessHoursOnly + +EmergencyOnly + +TrainingRequired + +ContractRequired + +NDARequired + +PurposeBound + +CaseBound + +EnvironmentBound + +NamespaceBound + +PipelineBound + +ChangeWindowBound + +Logged + +Recorded + +NotificationRequired + +PostReviewRequired + +HumanReviewRequired + +PolicyReviewRequired + +WorkloadIdentityRequired + +``` + +Example: + +```text + +Vendor Coach may access Tenant Alpha support case data + +only when: + + TicketRequired + + TenantConsentRequired + + TimeLimited + + Logged + + PurposeBound + +``` + +Conditions are part of effective access. + +If required conditions are not satisfied, access is denied. + +--- + +## 27. Dimension: Lifecycle State + +Lifecycle State describes why access exists now. + +Canonical lifecycle states: + +```text + +Design + +Build + +Test + +Review + +Release + +Onboard + +Integrate + +Migrate + +Operate + +Support + +Improve + +Deprecate + +Archive + +Incident + +Legal + +Terminate + +``` + +Lifecycle matters because access that is legitimate in one state may become illegitimate in another. + +Example: + +```text + +Consultant Integrator access is valid during Onboard and Integrate. + +It does not remain valid during Operate unless explicitly extended. + +``` + +Agentic development compresses lifecycle loops: + +```text + +Customer feedback + +→ issue + +→ generated patch + +→ test + +→ review + +→ deployment + +→ runtime observation + +→ further improvement + +``` + +CARING therefore requires lifecycle-aware access governance. + +--- + +## 28. Dimension: Restriction + +Restrictions are overriding policy effects. + +They are not normal roles. + +Canonical restrictions: + +```text + +NoAccess + +Suspended + +Terminated + +Quarantined + +ScopeExcluded + +DataClassRestricted + +LegalHold + +ExportBlocked + +ImpersonationBlocked + +CrossTenantBlocked + +SecretAccessBlocked + +PolicyFrozen + +EmergencyLocked + +RiskDenied + +ExecutionBlocked + +WorkloadCreationBlocked + +PrivilegeEscalationBlocked + +``` + +### 28.1 Restriction Precedence + +Recommended precedence: + +```text + +1. Tenant boundary + +2. Legal hold / quarantine / suspension / termination + +3. Explicit deny + +4. Data classification restriction + +5. Secret restriction + +6. Execution restriction + +7. Conditional requirements + +8. Scoped allow + +9. Default deny + +``` + +### 28.2 NoAccess + +NoAccess is an explicit deny effect. + +It should not be treated as an ordinary role. + +### 28.3 Suspended + +Subject exists but cannot access until reinstated. + +### 28.4 Terminated + +Subject is no longer eligible for access. + +### 28.5 Quarantined + +Access blocked due to risk, incident, malware, abuse, or investigation. + +### 28.6 ScopeExcluded + +Subject is member of a broader group but explicitly excluded from this scope. + +### 28.7 DataClassRestricted + +Sensitive class, field, or tag overrides otherwise broad access. + +### 28.8 LegalHold + +Resource cannot be deleted or altered because of legal or compliance hold. + +### 28.9 ExportBlocked + +Subject may view but may not export. + +### 28.10 SecretAccessBlocked + +Subject may operate or configure without access to secret material. + +### 28.11 CrossTenantBlocked + +Subject may not cross tenant boundaries. + +This should generally be structural and non-bypassable. + +### 28.12 ExecutionBlocked + +Subject may inspect or configure but may not cause execution. + +### 28.13 WorkloadCreationBlocked + +Subject may not create workloads that could induce broader access. + +### 28.14 PrivilegeEscalationBlocked + +Subject may not bind, escalate, impersonate, or otherwise expand effective authority. + +--- + +## 29. Dimension: Exposure Event + +Exposure Events are controlled exceptions or observed irregularities. + +They are not ordinary roles. + +Canonical exposure event classes: + +```text + +X-Support + +X-BreakGlass + +X-SecurityTest + +X-Incident + +X-LegalDemand + +X-ComplianceAudit + +X-Migration + +X-Recovery + +X-Adversarial + +X-Misconfiguration + +X-InducedAccess + +X-PrivilegeEscalation + +``` + +### 29.1 X-Support + +Support case required access to tenant data or environment. + +### 29.2 X-BreakGlass + +Emergency privileged access to prevent or repair serious harm. + +### 29.3 X-SecurityTest + +Authorized penetration test, red-team activity, white-hat test, or vulnerability validation. + +### 29.4 X-Incident + +Security or reliability incident investigation. + +### 29.5 X-LegalDemand + +Court order, regulator demand, police request, subpoena, statutory duty, or similar legal access demand. + +### 29.6 X-ComplianceAudit + +Compliance investigation or audit. + +### 29.7 X-Migration + +Data migration, tenant move, onboarding, export/import, or restructuring. + +### 29.8 X-Recovery + +Backup restore, disaster recovery, corruption repair, or data reconstruction. + +### 29.9 X-Adversarial + +Unauthorized or hostile access attempt or confirmed compromise. + +### 29.10 X-Misconfiguration + +Unexpected exposure caused by configuration error, policy error, implementation error, or misunderstood inheritance. + +### 29.11 X-InducedAccess + +Unexpected or high-risk access caused indirectly through automation, controllers, workloads, workflows, agents, service accounts, or other mediated execution paths. + +### 29.12 X-PrivilegeEscalation + +Access expansion caused by policy manipulation, impersonation, binding, escalation, secret exposure, induced workload authority, or other privilege growth. + +Each exposure event should record: + +```text + +event_id + +actor + +subject + +organization_relation + +canonical_role + +scope + +plane + +capabilities_used + +derived_capabilities + +exposure_mode + +reason + +authority_source + +approval + +start_time + +end_time + +resources_accessed + +evidence + +notification_status + +post_review + +``` + +--- + +# Part II — Structural Rules + +--- + +## 30. Tenant Isolation + +Tenant isolation is a structural boundary. + +It must not be treated merely as a role, group, namespace, label, or naming convention. + +CARING tenant isolation principles: + +```text + +1. Every protected resource should have a tenant context + + or be explicitly classified as platform-global. + +2. Every authorization decision involving tenant resources + + should include tenant context. + +3. A subject’s role in Tenant A does not imply the same role in Tenant B. + +4. Platform access does not imply tenant data access. + +5. Cross-tenant access requires explicit purpose, scope, exposure mode, + + authority source, and audit trail. + +6. Internal tenant groupings may overlap, but overlap must be resolved + + by scope, relationship, attributes, capabilities, and restrictions. + +7. Tenant boundary violations should be classified as incidents + + or exposure events. + +8. Technical namespaces may support tenant isolation, + + but they are not automatically sufficient tenant boundaries. + +``` + +Example: + +```text + +A Customer Manager in Tenant Alpha + +has no access in Tenant Beta + +unless separately assigned. + +``` + +--- + +## 31. Namespace and Tenant Separation + +A namespace is a technical scope. A tenant is a governance and isolation scope. + +The two may correspond, but they are not equivalent by default. + +CARING analysis SHOULD ask: + +```text + +Is the namespace intended to represent a tenant? + +Can subjects in one namespace affect another namespace? + +Can controllers or operators cross namespaces? + +Can workloads mount service accounts or secrets that expand authority? + +Are network, storage, secrets, identity, and policy boundaries aligned? + +Are cluster-scoped resources shared across namespaces? + +``` + +If a namespace is used as a tenant boundary, the analysis must verify whether the effective access model supports that claim. + +--- + +## 32. Agents, Automations, and Services + +CARING treats agents, automations, and services as first-class subjects. + +For non-human subjects, access must distinguish: + +```text + +Principal + +Effective actor + +Delegator + +Tool or agent + +Policy ceiling + +Execution context + +Audit identity + +``` + +### 32.1 Agent Access Formula + +```text + +Effective Agent Access = + + Delegated Human/System Authority + + ∩ Agent Capability Ceiling + + ∩ Scope Boundary + + ∩ Exposure Policy + + ∩ Runtime Conditions + +``` + +Example: + +```text + +Human Alice is Customer Doer.Editor in Project A. + +Agent DraftBot may create drafts but may not publish or export. + +Therefore DraftBot acting for Alice can create drafts in Project A, + +but cannot publish, export, or access Project B. + +``` + +### 32.2 Agent Principles + +```text + +1. No agent receives access merely because it participates in a workflow. + +2. Every agent should have an organization relation, + + canonical role, scope, plane, capability ceiling, + + exposure limit, delegation source, and audit trail. + +3. Agent access should be purpose-bound. + +4. Agent access should be inspectable. + +5. Agent access should not silently inherit all human capabilities. + +6. Agent access should not silently cross tenant boundaries. + +7. Agent output that changes system state should be attributable. + +``` + +--- + +## 33. Direct, Delegated, Mediated, and Induced Access + +CARING distinguishes access by execution path. + +### 33.1 Direct Access + +The subject acts directly. + +Example: + +```text + +A user opens a document. + +``` + +### 33.2 Delegated Access + +The subject delegates authority to another subject. + +Example: + +```text + +A user authorizes an agent to draft a reply. + +``` + +### 33.3 Mediated Access + +The subject’s action is mediated by a system component that performs work on the subject’s behalf. + +Example: + +```text + +A workflow engine creates a task after a user submits a form. + +``` + +### 33.4 Induced Access + +The subject triggers a privileged component whose actual authority exceeds the subject’s direct authority. + +Example: + +```text + +A user creates a custom resource. + +A privileged controller reacts and modifies infrastructure elsewhere. + +``` + +Another example: + +```text + +A user can create a workload. + +The workload runs under a service account. + +The service account can read secrets. + +The user may thereby induce secret access. + +``` + +Induced access is especially important for agentic systems, workflow engines, Kubernetes operators, integration platforms, CI/CD systems, and automation frameworks. + +### 33.5 Analysis Requirement + +CARING analysis MUST consider whether a granted capability induces additional effective capabilities through controllers, agents, workflows, service accounts, admission hooks, pipelines, plugins, runtime execution, or other mediated mechanisms. + +--- + +## 34. Local Roles, Capability Profiles, and Titles + +CARING distinguishes: + +```text + +Canonical Role + +Capability Profile + +Local Role + +Local Title + +Group + +Native Policy Object + +``` + +### 34.1 Canonical Role + +Lifecycle responsibility posture. + +Example: + +```text + +Builder + +Operator + +Manager + +Doer + +``` + +### 34.2 Capability Profile + +A named bundle of capabilities. + +Example: + +```text + +Reader + +Editor + +RuntimeOperator + +DatabaseManager + +ClusterAdmin + +``` + +### 34.3 Local Role + +An application-specific or system-specific role. + +Example: + +```text + +[Approver] + +FinanceReviewer + +ProjectLead + +NamespaceAdmin + +``` + +### 34.4 Local Title + +Human-readable organizational title. + +Example: + +```text + +Senior Developer + +Department Admin + +Support Engineer Level 2 + +Regional Sales Analyst + +``` + +### 34.5 Group + +A collection of subjects. + +Groups may be used for assignment, but group membership should not be confused with canonical role semantics. + +### 34.6 Native Policy Object + +A system-native object that expresses permissions. + +Examples: + +```text + +Kubernetes Role + +AWS IAM policy + +Azure role assignment + +Database grant + +Unix sudo rule + +``` + +Native policy objects should be mapped to CARING dimensions according to their actual semantics. + +--- + +# Part III — Normative Requirements + +--- + +## 35. Normative Statements + +### CRS-001: Orthogonality + +CARING-compliant access models MUST distinguish organization relation, canonical role, scope, plane, capability, exposure mode, condition, lifecycle state, restriction, and exposure event. + +### CRS-002: Role limitation + +CARING implementations SHOULD map local roles to the canonical roles: + +```text + +Creator + +Builder + +Verifier + +Maintainer + +Integrator + +Operator + +Manager + +Coach + +Doer + +``` + +### CRS-003: Native role analysis + +A native construct named `role` MUST NOT be assumed to map directly to a CARING Canonical Role. It may represent a capability profile, local title, group, policy object, rule bundle, or access assignment. + +### CRS-004: Scope binding + +No role assignment is complete without an explicit scope. + +### CRS-005: Plane binding + +No role assignment is complete without identifying the plane or planes on which it applies. + +### CRS-006: Capability binding + +Roles MUST NOT imply unlimited capabilities. Effective permissions MUST be expressed as capabilities within scope. + +### CRS-007: Tenant isolation + +Tenant isolation MUST be enforced as a structural boundary and MUST NOT depend solely on role naming, group membership, namespace naming, labels, or convention. + +### CRS-008: Exposure separation + +Plaintext visibility, secret-material visibility, export ability, impersonation, and cross-tenant aggregation MUST be separately controlled capabilities or exposure modes. + +### CRS-009: Operator separation + +Operator access MUST NOT imply ordinary business data access. + +### CRS-010: Builder separation + +Builder access MUST NOT imply production data access unless explicitly granted through a governed exposure event. + +### CRS-011: Integrator expiry + +Integrator access SHOULD be time-limited and SHOULD expire after onboarding, migration, or handover unless explicitly extended. + +### CRS-012: Coach delegation + +Coach access to tenant data SHOULD be case-bound, purpose-bound, delegated, time-limited, and auditable. + +### CRS-013: Manager boundary + +Manager access MUST be bounded by scope and MUST distinguish configuration authority from runtime operation and product modification. + +### CRS-014: Agent ceiling + +Automated and agentic subjects MUST have explicit capability ceilings independent of the delegating user. + +### CRS-015: Exposure events + +Exceptional access MUST be recorded as an exposure event with actor, reason, authority source, scope, plane, exposure mode, derived capabilities where relevant, and post-event review. + +### CRS-016: Default deny + +Access not explicitly granted within the relevant scope, plane, capability, condition, and lifecycle context MUST be denied by default. + +### CRS-017: Restriction precedence + +Restrictions MUST be evaluated before scoped allow grants. + +### CRS-018: NoAccess semantics + +NoAccess MUST be treated as a restriction or deny effect, not as an ordinary role. + +### CRS-019: Export separation + +Export, replicate, copy, bulk download, and external sharing capabilities MUST be distinguished from ordinary view access. + +### CRS-020: Secret separation + +Secret Plane access MUST be explicitly modeled and MUST NOT be inferred from Runtime Plane, Configuration Plane, or workload access. + +### CRS-021: Policy-plane sensitivity + +Capabilities that grant, revoke, bind, escalate, impersonate, or override permissions MUST be modeled as Policy Plane access. + +### CRS-022: Execution-plane sensitivity + +Capabilities that execute code, run workflows, launch jobs, create workloads, or invoke agents MUST be modeled as Execution Plane access where relevant. + +### CRS-023: Lifecycle review + +Access SHOULD be reviewed when lifecycle state changes. + +Examples: + +```text + +Onboard → Operate + +Support → Closed + +Build → Release + +Incident → PostReview + +Employee Active → Terminated + +``` + +### CRS-024: Descriptive completeness + +A CARING analysis SHOULD attempt to reconstruct effective access, not merely declared access. + +### CRS-025: Derived capability analysis + +CARING analysis SHOULD identify derived capabilities where direct grants produce additional effective authority. + +### CRS-026: Induced access analysis + +CARING analysis SHOULD identify mediated and induced access effects caused by agents, controllers, workflows, automations, integrations, service accounts, plugins, or privileged services. + +### CRS-027: Namespace caution + +A namespace SHOULD NOT be assumed to be a tenant boundary unless the wider effective access model supports that interpretation. + +--- + +# Part IV — Analysis Process + +--- + +## 36. CARING Analysis Fitness Test + +Given an access-control implementation, CARING passes the analysis test if: + +```text + +1. Every declared access grant can be represented + + as a CARING access descriptor. + +2. Every effective access grant can be represented + + as a CARING access descriptor. + +3. Every effective deny or restriction can be represented + + as a CARING restriction or condition. + +4. Every exceptional or irregular access path can be represented + + as an exposure event. + +5. The mapping preserves effective access semantics sufficiently + + for governance analysis. + +6. Any semantic loss is explicitly identifiable as either: + + a) implementation-specific detail below CARING abstraction level, or + + b) a genuine gap in CARING. + +7. The mapping reveals bundled, ambiguous, risky, + + underspecified, induced, or restrictive access decisions. + +``` + +--- + +## 37. CARING Analysis Procedure + +### Step 1: Identify Subjects + +Questions: + +```text + +Who or what can act? + +Are subjects human, service, automation, agent, group, anonymous, or unknown? + +Are service accounts and agents visible as first-class subjects? + +``` + +### Step 2: Identify Organization Relations + +Questions: + +```text + +Under whose authority does the subject act? + +Vendor? + +ServiceProvider? + +Distributor? + +Consultant? + +Customer? + +Community? + +Authority? + +Unknown? + +``` + +### Step 3: Map Native Roles and Policy Objects + +Questions: + +```text + +Is the native role a canonical role, capability profile, + +local title, group, policy object, or access assignment? + +``` + +### Step 4: Map to Canonical Roles + +Questions: + +```text + +Is this subject creating, building, verifying, maintaining, + +integrating, operating, managing, coaching, or doing? + +``` + +### Step 5: Identify Scope + +Questions: + +```text + +Where does the access apply? + +Platform? + +Cluster? + +Environment? + +Tenant? + +Namespace? + +Workspace? + +Project? + +Process? + +Dataset? + +Resource? + +Subresource? + +Record? + +Field? + +Action? + +``` + +### Step 6: Identify Plane + +Questions: + +```text + +What kind of thing is accessed? + +Intent? + +Build? + +Runtime? + +Execution? + +Configuration? + +Data? + +Identity? + +Policy? + +Secret? + +Audit? + +Commercial? + +Community? + +``` + +### Step 7: Extract Declared Capabilities + +Questions: + +```text + +What does the native policy explicitly allow? + +View? + +Create? + +Edit? + +Delete? + +Execute? + +Configure? + +Grant? + +Export? + +Impersonate? + +Deploy? + +Restore? + +Override? + +``` + +### Step 8: Extract Derived Capabilities + +Questions: + +```text + +What does the declared capability make possible indirectly? + +Can execution expose data? + +Can workload creation expose secrets? + +Can policy editing create privilege escalation? + +Can configuration trigger privileged automation? + +``` + +### Step 9: Determine Exposure Mode + +Questions: + +```text + +What information becomes visible? + +None? + +Metadata? + +Masked? + +Aggregated? + +Synthetic? + +Pseudonymous? + +Encrypted? + +Plaintext? + +SecretMaterial? + +Exportable? + +Cross-tenant aggregate? + +``` + +### Step 10: Identify Conditions + +Questions: + +```text + +When is access valid? + +MFA? + +Ticket? + +Consent? + +Time limit? + +Dual approval? + +Case binding? + +Purpose binding? + +Logging? + +Post-review? + +Pipeline binding? + +Workload identity? + +``` + +### Step 11: Identify Lifecycle State + +Questions: + +```text + +Why does this access exist now? + +Design? + +Build? + +Test? + +Onboard? + +Operate? + +Support? + +Incident? + +Legal? + +Terminate? + +``` + +### Step 12: Identify Restrictions + +Questions: + +```text + +What overrides access? + +NoAccess? + +Suspension? + +Quarantine? + +Legal hold? + +Data classification? + +Export block? + +Secret access block? + +Execution block? + +Cross-tenant block? + +Privilege-escalation block? + +``` + +### Step 13: Identify Execution Paths + +Questions: + +```text + +Is access direct? + +Delegated? + +Mediated? + +Induced? + +Can a subject cause another subject to act? + +Can a low-privilege subject trigger a high-privilege component? + +``` + +### Step 14: Identify Exposure Events + +Questions: + +```text + +Are there break-glass paths? + +Support access? + +Legal access? + +Migration access? + +Security testing? + +Incidents? + +Misconfiguration? + +Adversarial access? + +Induced access? + +Privilege escalation? + +``` + +### Step 15: Identify Bundling and Gaps + +Questions: + +```text + +Which local roles bundle multiple CARING dimensions? + +Where does runtime access imply data access? + +Where does view imply export? + +Where does configuration imply policy? + +Where does execution imply secret access? + +Where does tenant access leak across boundaries? + +Where does lifecycle access fail to expire? + +Where do declared and effective access differ? + +``` + +--- + +## 38. CARING Redesign Procedure + +When redesigning an access-control model: + +```text + +1. Preserve legitimate practical intent. + +2. Decompose bundled roles into CARING dimensions. + +3. Separate canonical role from capability profile. + +4. Make scope explicit. + +5. Make plane explicit. + +6. Make exposure mode explicit. + +7. Separate operator access from data access. + +8. Separate builder access from production data access. + +9. Separate manager access from runtime operation. + +10. Separate view from export. + +11. Separate plaintext from secret material. + +12. Separate declared access from effective access. + +13. Add lifecycle expiry where needed. + +14. Add exposure-event workflows for exceptions. + +15. Add agent and service-account capability ceilings. + +16. Add tenant-boundary enforcement. + +17. Add induced-access analysis. + +18. Review resulting model for usability. + +``` + +--- + +# Part V — Reference Matrices + +--- + +## 39. Canonical Role Matrix + +| Role | Core question | Lifecycle center | Default plane | + +|---|---|---|---| + +| **Creator** | Why should this exist? | Intent | Intent | + +| **Builder** | How is it made or changed? | Build | Build | + +| **Verifier** | Is it correct, safe, and fit? | Review | Audit / Build / Data | + +| **Maintainer** | How does it remain coherent over time? | Improve / Release | Build / Community / Intent | + +| **Integrator** | How is it brought into this environment? | Onboard / Migrate | Configuration / Identity / Runtime | + +| **Operator** | How is it kept running? | Operate / Incident | Runtime | + +| **Manager** | How is this bounded scope governed and configured? | Configure / Govern | Configuration / Policy / Data | + +| **Coach** | How are others helped to use it well? | Support / Adoption | Data / Community / Commercial | + +| **Doer** | What work is performed with it? | Use | Data / Execution | + +--- + +## 40. Organization Relation × Role Examples + +| Organization Relation | Example role combinations | + +|---|---| + +| Vendor | Vendor Creator, Vendor Builder, Vendor Maintainer, Vendor Operator, Vendor Coach | + +| ServiceProvider | ServiceProvider Operator, ServiceProvider Integrator, ServiceProvider Manager | + +| Distributor | Distributor Coach, Distributor Integrator, Distributor Manager | + +| Consultant | Consultant Integrator, Consultant Builder, Consultant Coach, Consultant Manager | + +| Customer | Customer Manager, Customer Doer, Customer Operator, Customer Verifier | + +| Community | Community Builder, Community Maintainer, Community Coach, Community Verifier | + +| Authority | Authority Verifier, Authority LegalDemand | + +| Unknown | Unknown Actor, Unknown Adversarial Subject | + +--- + +## 41. Capability Profile Mapping Examples + +| Capability Profile | Canonical Role | Main Capabilities | Main Plane | + +|---|---|---|---| + +| Reader | Doer | View | Data | + +| Contributor / Author | Doer | View, Create, EditOwn/EditAssigned | Data | + +| Editor | Doer | View, Create, EditAny | Data | + +| Depositor / Submitter | Doer | Submit/Create without View | Data | + +| Designer | Builder | Create/Edit design, Configure | Build / Configuration | + +| RuntimeOperator | Operator | Operate, Inspect, Restore | Runtime | + +| TenantManager | Manager | Configure, Grant, Revoke, Delegate | Configuration / Policy | + +| NamespaceManager | Manager | Configure, Create, EditAny, Grant/Bind | Runtime / Configuration / Policy | + +| SupportAgent | Coach | View/Comment/Guide under case conditions | Data / Configuration | + +| QAReviewer | Verifier | Review, Inspect, Audit | Build / Audit | + +| ReleaseMaintainer | Maintainer | Review, Approve, Publish | Build / Community | + +| ClusterAdmin | Operator + Manager | Operate, Configure, Grant, Override | Runtime / Policy / Secret | + +--- + +## 42. Native System Mapping Summary + +| Native system concept | CARING interpretation | + +|---|---| + +| Lotus/Domino Manager | Compound Manager capability profile | + +| Lotus/Domino Designer | Builder capability profile | + +| Lotus/Domino Reader/Author/Editor | Doer capability profiles | + +| Lotus/Domino NoAccess | Restriction | + +| Lotus/Domino Readers/Authors fields | Record-level scope and relationship condition | + +| Kubernetes Role | Capability profile / native policy object | + +| Kubernetes ClusterRole | Cluster-scoped or reusable capability profile | + +| Kubernetes RoleBinding | Access assignment | + +| Kubernetes ClusterRoleBinding | Cluster-scoped access assignment | + +| Kubernetes ServiceAccount | Service / automation subject | + +| Kubernetes verb | Capability | + +| Kubernetes resource | Scope + Plane | + +| Kubernetes namespace | Namespace scope; possible but not automatic tenant boundary | + +| Kubernetes secret access | Secret Plane + SecretMaterial exposure | + +| Kubernetes workload creation | Execution Plane + possible derived capabilities | + +--- + +# Part VI — Examples + +--- + +## 43. Vendor Builder + +```text + +Subject: + + Human or Agent + +Organization Relation: + + Vendor + +Canonical Role: + + Builder + +Scope: + + Product / Module / Repository / Branch / Issue + +Plane: + + Build + +Capabilities: + + Create + + EditOwn + + EditAny + + Submit + + Review + +Exposure Mode: + + Source context + + Issue context + + Synthetic or masked data + +Conditions: + + Code review + + CI checks + + Signed commits + + No production secrets + +Lifecycle State: + + Build / Improve + +``` + +--- + +## 44. Community Maintainer + +```text + +Subject: + + Human + +Organization Relation: + + Community + +Canonical Role: + + Maintainer + +Scope: + + Open-source module + +Plane: + + Build / Community + +Capabilities: + + Review + + Approve + + Publish + +Exposure Mode: + + Public + + Metadata + +Conditions: + + Maintainer policy + + Contribution rules + + Review process + +Lifecycle State: + + Improve / Release + +``` + +--- + +## 45. Consultant Integrator + +```text + +Subject: + + Human or Service + +Organization Relation: + + Consultant + +Canonical Role: + + Integrator + +Scope: + + Customer Tenant / Integration Project + +Plane: + + Configuration / Identity / Runtime + +Capabilities: + + Configure + + Integrate + + Import + + Test + +Exposure Mode: + + Masked by default + + Plaintext only by approval + +Conditions: + + Tenant consent + + Ticket + + Time limit + + Audit + +Lifecycle State: + + Onboard / Integrate / Migrate + +``` + +--- + +## 46. ServiceProvider Operator + +```text + +Subject: + + Human, Service, Automation, or Agent + +Organization Relation: + + ServiceProvider + +Canonical Role: + + Operator + +Scope: + + Production Environment + +Plane: + + Runtime + +Capabilities: + + Operate + + Deploy + + Restore + + Inspect + +Exposure Mode: + + Metadata + + Masked logs + +Conditions: + + MFA + + Ticket + + Privileged access control + + Logging + +Lifecycle State: + + Operate / Incident + +``` + +--- + +## 47. Customer Manager + +```text + +Subject: + + Human + +Organization Relation: + + Customer + +Canonical Role: + + Manager + +Scope: + + Tenant / Workspace + +Plane: + + Configuration / Policy / Data + +Capabilities: + + Configure + + Grant + + Revoke + + Delegate + + Archive + +Exposure Mode: + + Plaintext within tenant policy + +Conditions: + + Tenant governance rules + +Lifecycle State: + + Configure / Operate / Improve + +``` + +--- + +## 48. Customer Doer as Depositor + +```text + +Subject: + + Human, Anonymous, or External Actor + +Organization Relation: + + Customer / Community / Unknown + +Canonical Role: + + Doer + +Capability Profile: + + Depositor / Submitter + +Scope: + + Submission Process + +Plane: + + Data + +Capabilities: + + Submit + +Exposure Mode: + + None after submission + +Conditions: + + Purpose-bound + + Form validation + +Lifecycle State: + + Use + +``` + +--- + +## 49. Vendor Coach + +```text + +Subject: + + Human or Agent + +Organization Relation: + + Vendor + +Canonical Role: + + Coach + +Scope: + + Customer Support Case + +Plane: + + Data / Configuration + +Capabilities: + + View + + Comment + + Guide + + Configure, if delegated + +Exposure Mode: + + Masked or tenant-approved Plaintext + +Conditions: + + Ticket + + Tenant consent + + Time limit + + Audit + +Lifecycle State: + + Support + +``` + +--- + +## 50. AI Coding Agent + +```text + +Subject: + + Agent + +Organization Relation: + + Vendor / Community / Customer + +Canonical Role: + + Builder + +Scope: + + Repository / Branch / Issue + +Plane: + + Build + +Capabilities: + + Create + + EditOwn + + Submit + +Exposure Mode: + + Source context + + Issue context + + Test output + +Conditions: + + No secret access + + No production deploy + + Human or policy review + +Lifecycle State: + + Build / Improve + +``` + +--- + +## 51. AI Support Agent + +```text + +Subject: + + Agent + +Organization Relation: + + Vendor + +Canonical Role: + + Coach + +Scope: + + Support Case + +Plane: + + Data / Configuration + +Capabilities: + + View + + Comment + + Recommend + +Exposure Mode: + + Masked by default + +Conditions: + + Case-bound + + Tenant policy + + Logged + + No autonomous export + +Lifecycle State: + + Support + +``` + +--- + +## 52. Break-Glass Operator Access + +```text + +Subject: + + Human + +Organization Relation: + + ServiceProvider + +Canonical Role: + + Operator + +Exposure Event: + + X-BreakGlass + +Scope: + + Tenant Alpha / Affected Runtime Resource Set + +Plane: + + Runtime / Data if unavoidable / Secret if unavoidable + +Capabilities: + + Operate + + Restore + + Inspect + + Limited View if required + +Exposure Mode: + + Metadata by default + + Plaintext only if necessary and recorded + + SecretMaterial only if necessary and recorded + +Conditions: + + EmergencyOnly + + TicketRequired + + DualApprovalRequired where feasible + + TimeLimited + + Logged + + Recorded + + PostReviewRequired + + NotificationRequired unless prohibited + +Lifecycle State: + + Incident + +``` + +--- + +## 53. Kubernetes Namespace Pod Reader + +```text + +Subject: + + User or ServiceAccount bound by RoleBinding + +Organization Relation: + + Customer / ServiceProvider / Vendor depending on identity source + +Canonical Role: + + Verifier or Operator + +Capability Profile: + + PodReader + +Scope: + + Namespace + + Resource: pods + +Plane: + + Runtime + +Capabilities: + + View + + ViewCollection + + Observe + +Exposure Mode: + + Metadata + runtime object details + +Conditions: + + Kubernetes authentication + + RoleBinding active + +Lifecycle State: + + Operate / Verify + +``` + +--- + +## 54. Kubernetes CI/CD Deployer + +```text + +Subject: + + ServiceAccount ci/deployer + +Subject Type: + + Service / Automation + +Organization Relation: + + Vendor or Customer + +Canonical Role: + + Builder or Operator + +Capability Profile: + + DeploymentDeployer + +Scope: + + Environment: staging + + Namespace: staging + + Resource: deployments + +Plane: + + Runtime / Build / Execution + +Capabilities: + + Deploy + + Create + + EditAny + +Exposure Mode: + + Runtime metadata + + Possibly configuration plaintext + +Conditions: + + PipelineBound + + EnvironmentBound + + Logged + + No production scope unless separately assigned + +Lifecycle State: + + Release / Build / Test + +``` + +--- + +## 55. Kubernetes Workload Creator with Induced Access + +```text + +Subject: + + Human or ServiceAccount + +Organization Relation: + + Customer / ServiceProvider / Vendor + +Canonical Role: + + Builder / Operator / Doer depending on purpose + +Scope: + + Namespace app-a + +Plane: + + Runtime / Execution + +Declared Capability: + + Create workload + +Derived Capabilities: + + Execute code + + Use mounted ServiceAccount + + Potentially access Secrets, ConfigMaps, volumes + +Exposure Mode: + + Potentially SecretMaterial / Plaintext / Runtime metadata + +Access Path: + + Induced Access + +Finding: + + Declared namespace-scoped runtime permission may result in + + broader effective authority than expected. + +``` + +--- + +# Part VII — Maturity and Evolution + +--- + +## 56. Standard Maturity Levels + +CARING may evolve through maturity levels. + +### Level 0 — Draft Vocabulary + +Initial terms, examples, and conceptual distinctions. + +### Level 1 — Release Candidate + +Stable enough to analyze real systems and collect feedback. + +### Level 2 — Mapping Standard + +Includes tested mappings to major access-control implementations. + +Examples: + +```text + +Lotus/Domino ACL + +Kubernetes RBAC + +Git hosting permissions + +Cloud IAM + +Database grants + +Enterprise IAM systems + +Document management systems + +``` + +### Level 3 — Design Standard + +Includes prescriptive design profiles, templates, and governance patterns. + +### Level 4 — Verification Standard + +Includes test cases, conformance checks, policy linting, and machine-readable schemas. + +### Level 5 — Operational Standard + +Includes lifecycle review automation, exposure-event workflows, agent policy ceilings, service-account governance, induced-access analysis, and continuous access governance. + +--- + +## 57. Standard Refinement Process + +CARING should evolve through concrete analysis challenges. + +For each analyzed system: + +```text + +1. Select access-control implementation. + +2. Describe system-native access model. + +3. Map native constructs to CARING dimensions. + +4. Identify successful mappings. + +5. Identify ambiguous mappings. + +6. Identify missing CARING concepts, if any. + +7. Identify implementation shortcomings exposed by CARING. + +8. Identify CARING terminology refinements. + +9. Update standard or mapping guide. + +10. Add findings to benchmark corpus. + +``` + +A proposed refinement should be accepted only if: + +```text + +1. It cannot be modeled cleanly with existing dimensions. + +2. It appears in more than one access-control context, + + or is fundamental enough to justify inclusion. + +3. It improves analytical clarity without causing role explosion. + +4. It preserves orthogonality. + +5. It avoids overfitting to one implementation. + +``` + +--- + +## 58. Candidate Analysis Benchmarks + +Initial benchmark candidates: + +```text + +1. Lotus/Domino ACL + +2. Kubernetes RBAC + +3. GitHub / GitLab repository access + +4. AWS IAM + +5. Azure RBAC / Entra ID + +6. PostgreSQL roles and grants + +7. SharePoint / Microsoft 365 permissions + +8. Jira / Confluence permissions + +9. Salesforce profiles, permission sets, and sharing rules + +10. Keycloak realm/client/resource permissions + +11. Linux users/groups/sudo + +12. CI/CD platform permissions + +13. Support desk access models + +14. Data warehouse access models + +15. Agentic workflow platform permissions + +``` + +Each benchmark should test different stresses: + +```text + +Document-level access + +Infrastructure access + +Tenant isolation + +Field-level access + +Secrets + +Service accounts + +Agentic delegation + +Community contribution + +Legal exposure + +Runtime operation + +Commercial entitlement + +Cross-tenant analytics + +Induced access + +Policy-plane escalation + +``` + +--- + +# Part VIII — Glossary + +--- + +## 59. Access Assignment + +A declared or effective grant of access to a subject. + +## 60. Access Descriptor + +A CARING representation of access using core dimensions. + +## 61. Capability + +An action the subject may perform. + +## 62. Capability Profile + +A named bundle of capabilities. + +## 63. Canonical Role + +A lifecycle responsibility posture defined by CARING. + +## 64. Condition + +A requirement that must be satisfied for access to be valid. + +## 65. Declared Access + +Access explicitly represented by the native access-control system. + +## 66. Derived Capability + +A capability that is not directly granted as a named permission, but becomes available as a consequence of another permission. + +## 67. Direct Access + +Access where the subject acts directly. + +## 68. Delegated Access + +Access where one subject delegates authority to another subject. + +## 69. Effective Access + +Access that can actually be achieved through direct, delegated, mediated, derived, or induced execution paths. + +## 70. Exposure Event + +A controlled exception or observed irregularity involving information access. + +## 71. Exposure Mode + +The degree and form in which information becomes visible, extractable, or usable. + +## 72. Induced Access + +Access caused when a subject triggers a component whose actual authority exceeds the subject’s direct authority. + +## 73. Lifecycle State + +The current reason or phase for which access exists. + +## 74. Local Role + +An application-specific role name not necessarily identical to a CARING canonical role. + +## 75. Mediated Access + +Access where a system component acts on behalf of or in response to a subject. + +## 76. Native Policy Object + +A system-native construct that expresses permissions, such as a Kubernetes Role, IAM policy, database grant, or ACL entry. + +## 77. Organization Relation + +The structural relationship of a subject to the product, platform, tenant, or governance context. + +## 78. Plane + +The kind of system layer or access surface being accessed. + +## 79. Restriction + +An overriding deny, block, quarantine, or limiting policy effect. + +## 80. Scope + +The boundary within which access applies. + +## 81. SecretMaterial + +Credentials, keys, tokens, certificates, or other secret values that can enable further access. + +## 82. Subject + +The entity to which access is assigned or attributed. + +## 83. Tenant + +A structurally isolated customer, organization, business unit, or operating context. + +--- + +# 84. Compact Definition + +> **CARING is a canonical access-control vocabulary for information products and runtime platforms. It defines a small set of lifecycle roles and combines them orthogonally with subject type, organization relation, scope, plane, capability, exposure mode, conditions, lifecycle state, restrictions, and exposure events. It distinguishes declared access from effective access and requires analysis of derived and induced capabilities. This allows vendors, service providers, consultants, customers, communities, humans, services, automations, and agents to collaborate safely across the full product lifecycle without collapsing access governance into unmanageable local role sprawl.** + +--- + +# 85. Core Mental Model + +```text + +Role describes lifecycle responsibility. + +Organization Relation says under whose authority the subject acts. + +Scope says where the access applies. + +Plane says what layer is accessed. + +Capability says what action is possible. + +Exposure says what information becomes visible or extractable. + +Condition says when access is valid. + +Lifecycle State says why access exists now. + +Restriction says what overrides access. + +Exposure Event says when access becomes exceptional or irregular. + +Declared Access says what the native policy states. + +Effective Access says what can actually be achieved. + +Derived Capability says what becomes possible as a consequence. + +Induced Access says what privileged behavior can be triggered indirectly. + +``` + +This is the core of CARING 0.4.0-RC2. + diff --git a/seeds/InfoTechCanonCore_RC1_seed.md b/seeds/InfoTechCanonCore_RC1_seed.md new file mode 100755 index 0000000..e35f907 --- /dev/null +++ b/seeds/InfoTechCanonCore_RC1_seed.md @@ -0,0 +1,1982 @@ +# InfoTechCanon Core + +**Short Name:** `ITC-CORE` +**Document Status:** Seed Standard Release Candidate 1 +**Version:** RC1-seed +**Date:** 2026-05-23 +**Repository Context:** `info-tech-canon` +**Document Type:** InfoTechCanon Core Standard +**Intended Audience:** Standards authors, repository maintainers, information architects, knowledge-system builders, AI-agent tool designers, platform builders, governance designers, and contributors to the InfoTechCanon ecosystem. + +--- + +# 1. Purpose + +The **InfoTechCanon Core** defines the constitutional layer of InfoTechCanon. + +It specifies how InfoTechCanon standards, concepts, relationships, mappings, profiles, patterns, assimilation records, validation rules, conformance levels, provenance records, version records, interface cards, and agent-facing artifacts are structured, related, governed, evolved, and reused. + +It exists to prevent each domain standard from reinventing the same mechanisms. + +The Core standard owns the general canon machinery. Domain standards own domain meaning. + +```text +Core owns the rules of the canon. +Domain standards own the concepts of their domains. +Profiles constrain standards for use. +Patterns explain recurring solutions. +Mappings connect the canon to external bodies of knowledge. +Assimilation turns external knowledge into structured improvement pressure. +``` + +--- + +# 2. Position in InfoTechCanon + +`InfoTechCanonCore` is the root standard of the InfoTechCanon standards system. + +All other standards SHOULD import or conform to it. + +```text +InfoTechCanon +├── InfoTechCanonCore <-- this standard +├── InfoTechCanonInformationSpaceModel +├── InfoTechCanonLandscapeModel +├── InfoTechCanonOrganizationModel +├── InfoTechCanonGovernanceModel +├── InfoTechCanonTaskModel +├── InfoTechCanonTaggingStandard +├── InfoTechCanonAccessControlModel +├── InfoTechCanonSecurityModel +├── InfoTechCanonDataModel +├── InfoTechCanonDevSecOpsModel +├── InfoTechCanonNetworkModel +├── InfoTechCanonObservabilityModel +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +The Core standard provides the shared structures that domain standards reuse: + +```text +Artifact model +Concept model +Relationship model +Mapping model +Assimilation model +Pattern model +Profile model +Validation model +Conformance model +Versioning model +Provenance model +Repository model +Agent interface model +Canon Interface Card model +``` + +--- + +# 3. Scope + +## 3.1 In Scope + +This standard covers canonical representation of: + +- canon artifacts, +- standards, +- concepts, +- concept ownership, +- relationships, +- namespaces, +- identifiers, +- labels, +- aliases, +- statuses, +- lifecycle states, +- mappings, +- assimilation records, +- patterns, +- profiles, +- validation rules, +- conformance levels, +- provenance records, +- version records, +- change records, +- deprecation records, +- repository layout conventions, +- agent briefs, +- canon interface cards, +- source references, +- evidence references, +- and common anti-patterns for canon evolution. + +## 3.2 Out of Scope + +This standard does not define the domain semantics of: + +- landscapes, +- organizations, +- governance, +- tasks, +- tagging, +- access control, +- security, +- data, +- DevSecOps, +- networking, +- observability, +- or information spaces. + +Those meanings belong to domain standards. + +Core may define the general artifact type `Concept`, but it does not define every domain concept. + +--- + +# 4. Design Stance + +InfoTechCanonCore is a **seed standard** and a **meta-standard**. + +It shall: + +1. provide enough common structure to align all seed standards, +2. avoid over-formalizing before actual use reveals needs, +3. preserve markdown-first authoring, +4. support machine-readable extraction, +5. support agent retrieval and reasoning, +6. support external mappings without external subordination, +7. support assimilation as a repeatable knowledge-ingestion process, +8. support explicit evolution and compatibility management, +9. support orthogonality between standards, +10. and support practical subsystem integration. + +--- + +# 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 defined provisionally but open to later refinement. +- **PROFILE** marks a context-specific constraint over canonical concepts. +- **MAPPING** marks a scoped relation to an external body of knowledge. +- **ASSIMILATION** marks structured analysis of an external knowledge body. + +--- + +# 6. Core Principles + +## 6.1 Internal Autonomy + +InfoTechCanon may map to external standards, products, regulations, and frameworks, but it MUST NOT be semantically subordinated to any one of them. + +External bodies of knowledge influence the canon through mappings, assimilation, patterns, and profiles. + +## 6.2 Single Canonical Owner + +Every canonical concept SHOULD have exactly one canonical owning standard. + +A concept may be referenced by many standards, but it should be owned by one. + +## 6.3 Import, Do Not Redefine + +A standard SHOULD import concepts from another standard instead of redefining them. + +## 6.4 Network Before Tree + +InfoTechCanon is fundamentally a network of concepts, artifacts, relationships, profiles, patterns, mappings, and evidence. + +Hierarchies are useful, but they are views or structuring aids, not the whole model. + +## 6.5 Profiles, Not Forks + +Concrete use cases SHOULD be expressed as profiles that constrain canonical concepts. + +Profiles MUST NOT redefine canonical concept meaning. + +## 6.6 Mappings Are Adapters + +Mappings relate InfoTechCanon concepts to external concepts. + +Mappings are adapters, not foundations. + +## 6.7 Assimilation Is Not Adoption + +Assimilation analyzes an external body of knowledge to produce mappings, gaps, conflicts, and proposed canon improvements. + +Assimilation does not automatically mutate the canon. + +## 6.8 Patterns Make Standards Practical + +Patterns describe recurring contexts, problems, forces, solutions, consequences, examples, and failure modes. + +A canon without patterns risks becoming abstract and inert. + +## 6.9 Evidence and Provenance Matter + +Important concepts, mappings, assimilations, decisions, and changes SHOULD preserve source, rationale, review, and provenance. + +## 6.10 Human-Readable and Agent-Usable + +Canon artifacts SHOULD be readable by humans and structured enough for agents and tools. + +--- + +# 7. Root Core Taxonomy + +```text +CoreEntity +├── CanonArtifact +│ ├── Standard +│ ├── Concept +│ ├── RelationshipDefinition +│ ├── Pattern +│ ├── Profile +│ ├── Mapping +│ ├── Assimilation +│ ├── ValidationRule +│ ├── ConformanceLevel +│ ├── VersionRecord +│ ├── ProvenanceRecord +│ ├── ChangeRecord +│ ├── DecisionRecord +│ ├── AgentBrief +│ └── CanonInterfaceCard +├── IdentityEntity +│ ├── Identifier +│ ├── Namespace +│ ├── Label +│ ├── Alias +│ └── ExternalReference +├── LifecycleEntity +│ ├── Status +│ ├── LifecycleState +│ ├── ReviewState +│ ├── Deprecation +│ ├── Supersession +│ └── CompatibilityState +├── RelationshipEntity +│ ├── Relationship +│ ├── RelationshipType +│ ├── Import +│ ├── Dependency +│ ├── Reference +│ └── Ownership +├── GovernanceEntity +│ ├── Rule +│ ├── Constraint +│ ├── Requirement +│ ├── Recommendation +│ ├── Rationale +│ └── ExceptionReference +└── QualityEntity + ├── ValidationResult + ├── Conflict + ├── Gap + ├── Overlap + ├── Ambiguity + ├── Drift + └── OpenQuestion +``` + +--- + +# 8. Canon Artifact Model + +## 8.1 CanonArtifact + +A **CanonArtifact** is any identifiable unit of canon content. + +Examples: + +```text +standard document +concept page +pattern document +profile document +mapping file +assimilation report +validation rule +agent brief +schema +example +decision record +``` + +Recommended attributes: + +```yaml +id: +type: +title: +status: +version: +canonical_owner: +created_at: +updated_at: +source_system: +``` + +Optional attributes: + +```yaml +summary: +scope: +imports: +related: +tags: +mappings: +provenance: +review_state: +compatibility: +``` + +--- + +## 8.2 Standard + +A **Standard** is a canon artifact that defines concepts, relationships, constraints, profiles, mappings, patterns, validation rules, and conformance expectations for a domain or meta-domain. + +A Standard SHOULD declare: + +```yaml +id: +title: +short_name: +status: +version: +purpose: +scope: +non_goals: +owned_concepts: +imported_standards: +profiles: +mappings: +validation_rules: +conformance_levels: +``` + +--- + +## 8.3 Concept + +A **Concept** is a unit of meaning owned by a standard. + +A Concept SHOULD declare: + +```yaml +id: +preferred_label: +definition: +canonical_owner: +status: +broader: +narrower: +related: +do_not_confuse_with: +mappings: +examples: +anti_examples: +``` + +Canonical rule: + +```text +A concept may be used by many standards, but SHOULD have one canonical owner. +``` + +--- + +## 8.4 RelationshipDefinition + +A **RelationshipDefinition** defines a type of relationship between concepts or artifacts. + +Recommended attributes: + +```yaml +id: +relationship_type: +definition: +domain: +range: +directionality: +inverse: +cardinality: +canonical_owner: +examples: +``` + +Examples: + +```text +depends_on +implements +maps_to +owned_by +governed_by +evidenced_by +derived_from +supersedes +``` + +--- + +## 8.5 Pattern + +A **Pattern** describes a recurring problem and reusable solution in context. + +Recommended pattern structure: + +```text +Name +Aliases +Context +Problem +Forces +Solution +Resulting Context +Used Concepts +Related Patterns +Known Variants +Failure Modes +Examples +Implementation Notes +``` + +--- + +## 8.6 Profile + +A **Profile** constrains one or more standards for a concrete implementation context. + +A Profile SHOULD declare: + +```yaml +id: +profile_name: +status: +implements: +target_context: +included_concepts: +required_relationships: +required_metadata: +constraints: +validation_rules: +mapping_files: +examples: +known_deviations: +``` + +Canonical rule: + +```text +A profile may constrain concepts but MUST NOT redefine them. +``` + +--- + +## 8.7 Mapping + +A **Mapping** relates an InfoTechCanon concept or artifact to an external concept, term, framework, regulation, product model, schema, or standard. + +Mappings are first-class artifacts. + +--- + +## 8.8 Assimilation + +An **Assimilation** is a structured analysis of an external body of knowledge to identify extracted concepts, mappings, gaps, conflicts, overlaps, and proposed canon changes. + +--- + +## 8.9 ValidationRule + +A **ValidationRule** defines a check that can be applied to artifacts, concepts, profiles, mappings, or implementations. + +--- + +## 8.10 ConformanceLevel + +A **ConformanceLevel** defines a recognizable level of adherence to a standard or profile. + +--- + +## 8.11 VersionRecord + +A **VersionRecord** records version, change, compatibility, and supersession information. + +--- + +## 8.12 ProvenanceRecord + +A **ProvenanceRecord** records source, activity, agent, generation, revision, influence, and review information. + +--- + +## 8.13 ChangeRecord + +A **ChangeRecord** records a change to a canon artifact. + +Recommended attributes: + +```yaml +id: +changed_artifact: +change_type: +summary: +rationale: +breaking: +supersedes: +created_at: +created_by: +reviewed_by: +``` + +--- + +## 8.14 DecisionRecord + +A **DecisionRecord** records a decision relevant to the canon. + +Recommended sections: + +```text +Context +Decision +Options Considered +Rationale +Consequences +Review Trigger +Supersession +``` + +--- + +## 8.15 AgentBrief + +An **AgentBrief** is a compact, retrieval-optimized artifact that helps AI agents use a standard correctly. + +Recommended sections: + +```text +Purpose +Scope +Owned Concepts +Imported Concepts +Do / Do Not +Core Patterns +Validation Hints +Common Mistakes +Minimal Examples +``` + +--- + +## 8.16 CanonInterfaceCard + +A **CanonInterfaceCard** declares how a subsystem, repository, service, or tool interacts with InfoTechCanon. + +Recommended structure: + +```yaml +subsystem: +implements: +produces: +consumes: +owned_concepts: +accepted_relationships: +emitted_events: +required_identifiers: +mapping_rules: +validation_rules: +source_of_truth: +known_deviations: +``` + +--- + +# 9. Identity and Naming Model + +## 9.1 Identifier + +An **Identifier** is a stable reference for a canon artifact or entity. + +Identifiers SHOULD be: + +```text +stable +unique within namespace +human-readable where practical +machine-parseable +version-aware where needed +``` + +Recommended form: + +```text +namespace:local-name +``` + +Examples: + +```text +itc-core:Concept +itc-land:ApplicationService +itc-gov:Policy +itc-task:Option +itc-access:Permission +``` + +--- + +## 9.2 Namespace + +A **Namespace** is a naming scope. + +Recommended namespace prefixes: + +```text +itc-core +itc-infospace +itc-land +itc-org +itc-gov +itc-task +itc-tag +itc-access +itc-sec +itc-data +itc-devsecops +itc-net +itc-obs +``` + +--- + +## 9.3 Label + +A **Label** is a human-readable name. + +A concept SHOULD have a preferred label and MAY have alternative labels. + +--- + +## 9.4 Alias + +An **Alias** is an alternative identifier or label. + +Aliases SHOULD be used for synonyms, historical names, external terms, and migrations. + +--- + +## 9.5 ExternalReference + +An **ExternalReference** points to an external body of knowledge, source, standard, regulation, product model, or document. + +--- + +# 10. Status and Lifecycle Model + +## 10.1 Standard Statuses + +Recommended standard statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +## 10.2 Concept Statuses + +Recommended concept statuses: + +```text +proposed +experimental +candidate +canonical +deprecated +retired +``` + +## 10.3 Artifact Statuses + +Recommended artifact statuses: + +```text +raw +captured +draft +reviewed +candidate +canonical +deprecated +superseded +archived +``` + +## 10.4 Review States + +Recommended review states: + +```text +not_reviewed +under_review +reviewed +changes_requested +approved +rejected +needs_revalidation +``` + +## 10.5 Compatibility States + +Recommended compatibility states: + +```text +compatible +backward_compatible +breaking_change +deprecated_compatibility +migration_required +unknown +``` + +--- + +# 11. Concept Ownership Model + +## 11.1 Canonical Owner + +A **Canonical Owner** is the standard responsible for defining and maintaining a concept. + +Example: + +```yaml +concept: itc-org:Team +canonical_owner: InfoTechCanonOrganizationModel +``` + +## 11.2 Use by Other Standards + +Other standards MAY use the concept through imports or references. + +Example: + +```yaml +uses: + - itc-org:Team +used_for: + - service ownership + - task assignment + - access review accountability +``` + +## 11.3 Ownership Rule + +```text +A concept SHOULD have exactly one canonical owner. +``` + +## 11.4 Overlap Handling + +If two standards appear to own the same concept, the conflict SHOULD be recorded as an `Overlap` or `ConflictingDefinition` and resolved by: + +```text +merge +split +rename +alias +mapping +import +deprecation +profile-specific distinction +``` + +--- + +# 12. Import and Dependency Model + +## 12.1 Import + +An **Import** declares that one standard uses concepts from another standard. + +Example: + +```yaml +standard: InfoTechCanonSecurityModel +imports: + - InfoTechCanonGovernanceModel + - InfoTechCanonAccessControlModel + - InfoTechCanonLandscapeModel +``` + +## 12.2 Dependency + +A **Dependency** is a stronger relation indicating that one artifact requires another to be interpreted correctly. + +## 12.3 Import Rule + +```text +Standards SHOULD import concepts rather than redefine them. +``` + +## 12.4 Circular Dependencies + +Circular dependencies SHOULD be avoided at the standard level. + +If unavoidable, they SHOULD be documented as mutual reference relations rather than hard ownership dependencies. + +--- + +# 13. Mapping Model + +## 13.1 Purpose + +Mappings keep InfoTechCanon externally legible without subordinating it to external standards. + +## 13.2 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +regulatoryReference +toolEquivalent +deprecatedReplacement +``` + +## 13.3 Mapping Record + +A Mapping SHOULD declare: + +```yaml +id: +source_concept: +target_body: +target_version: +target_concept: +mapping_type: +scope: +not_valid_for: +rationale: +confidence: +status: +owner: +source_references: +review_cycle: +``` + +## 13.4 Mapping Confidence + +Recommended confidence values: + +```text +low +medium +high +verified +contested +``` + +## 13.5 Mapping Statuses + +Recommended mapping statuses: + +```text +proposed +reviewed +candidate +accepted +deprecated +superseded +rejected +``` + +## 13.6 Mapping Rule + +```text +Mappings are adapters, not foundations. +``` + +--- + +# 14. Assimilation Model + +## 14.1 Purpose + +Assimilation is the process by which InfoTechCanon analyzes an external body of knowledge to identify useful concepts, gaps, conflicts, mappings, and improvement proposals. + +## 14.2 Assimilation Inputs + +Assimilation may apply to: + +```text +external standards +regulations +product schemas +tool models +academic frameworks +industry bodies of knowledge +internal project models +legacy schemas +books or theories +operational practice +``` + +## 14.3 Assimilation Stages + +Every formal assimilation SHOULD include: + +```text +1. Intake +2. Scoping +3. Concept Extraction +4. Concept Comparison +5. Gap and Conflict Analysis +6. Canon Impact Proposal +7. Mapping and Publication +``` + +## 14.4 Assimilation Candidate Record + +```yaml +id: +source_body: +source_version: +source_type: +reason: +requested_by: +status: +scope: +owner: +``` + +## 14.5 Assimilation Outputs + +A completed assimilation SHOULD produce: + +```text +ASSIMILATION.md +source-summary.md +extracted-concepts.yaml +comparison-matrix.md +mappings.yaml +proposed-changes.md +open-questions.md +``` + +## 14.6 Assimilation Result Categories + +Concept comparison SHOULD classify findings as: + +```text +already_covered +covered_differently +broader_than_existing +narrower_than_existing +missing_concept +conflicting_concept +implementation_detail_only +viewpoint_difference +terminology_difference_only +``` + +## 14.7 Assimilation Rule + +```text +Assimilation produces proposals, not automatic canon changes. +``` + +--- + +# 15. Pattern Model + +## 15.1 Purpose + +Patterns make standards practical by showing how concepts combine in recurring situations. + +## 15.2 Pattern Structure + +A Pattern SHOULD include: + +```text +Name +Aliases +Context +Problem +Forces +Solution +Resulting Context +Used Concepts +Related Patterns +Known Variants +Failure Modes +Examples +Implementation Notes +``` + +## 15.3 Pattern Families + +Recommended pattern families: + +```text +core +information-space +landscape +organization +governance +task +tagging +access-control +security +data +devsecops +network +observability +integration +agentic +``` + +## 15.4 Pattern Rule + +```text +A pattern SHOULD reference canonical concepts rather than invent local terminology. +``` + +--- + +# 16. Profile Model + +## 16.1 Purpose + +Profiles make canonical standards practical for concrete contexts without forking them. + +## 16.2 Profile Structure + +A Profile SHOULD declare: + +```yaml +id: +profile_name: +status: +implements: +target_context: +included_concepts: +required_relationships: +required_metadata: +constraints: +state_model: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +## 16.3 Profile Types + +Recommended profile types: + +```text +tool profile +domain profile +implementation profile +integration profile +repository profile +agent profile +compliance profile +runtime profile +``` + +## 16.4 Profile Rule + +```text +Profiles constrain standards. They MUST NOT redefine canonical concepts. +``` + +--- + +# 17. Validation Model + +## 17.1 ValidationRule + +A **ValidationRule** defines a check against canon artifacts, profiles, mappings, or implementations. + +Recommended structure: + +```yaml +id: +description: +applies_to: +severity: +check_type: +rationale: +examples: +``` + +## 17.2 Severity + +Recommended severity values: + +```text +info +warning +error +critical +``` + +## 17.3 Check Types + +Recommended check types: + +```text +structural +semantic +reference_integrity +metadata +mapping +profile +conformance +quality +security +retrieval +``` + +## 17.4 ValidationResult + +A **ValidationResult** records the outcome of applying a rule. + +```yaml +rule: +target: +result: +message: +evidence: +timestamp: +``` + +--- + +# 18. Conformance Model + +## 18.1 ConformanceLevel + +A **ConformanceLevel** defines a recognizable level of adherence to a standard or profile. + +## 18.2 General Conformance Levels + +All standards MAY specialize these levels: + +```text +Reference-Conformant +Metadata-Conformant +Relationship-Conformant +Evidence-Conformant +Profile-Conformant +Assimilation-Conformant +``` + +## 18.3 Reference-Conformant + +Uses terminology consistently. + +## 18.4 Metadata-Conformant + +Uses structured metadata and stable identifiers. + +## 18.5 Relationship-Conformant + +Represents important relationships explicitly. + +## 18.6 Evidence-Conformant + +Links important claims to source, evidence, or provenance. + +## 18.7 Profile-Conformant + +Implements a declared profile and passes validation rules. + +## 18.8 Assimilation-Conformant + +Can represent assimilation workspaces and produce mappings, gaps, conflicts, and proposed changes. + +--- + +# 19. Versioning and Change Model + +## 19.1 Version + +A **Version** identifies a specific state of a canon artifact. + +## 19.2 Change Types + +Recommended change types: + +```text +patch +minor +major +fork +``` + +## 19.3 Patch Change + +Clarification, typo fix, example, formatting, or non-semantic improvement. + +## 19.4 Minor Change + +Additive semantic change that should not break existing usage. + +## 19.5 Major Change + +Breaking semantic change requiring migration notes. + +## 19.6 Fork + +Incompatible conceptual branch. + +Forks SHOULD be avoided unless there is a strong reason. + +## 19.7 Deprecation + +A deprecated artifact SHOULD reference its replacement when one exists. + +## 19.8 Supersession + +Supersession records that one artifact replaces another. + +## 19.9 Migration Notes + +Major changes SHOULD provide migration notes. + +--- + +# 20. Provenance Model + +## 20.1 ProvenanceRecord + +A **ProvenanceRecord** records source, activity, agent, generation, revision, influence, and review information. + +Recommended structure: + +```yaml +id: +artifact: +generated_by: +derived_from: +influenced_by: +created_by: +reviewed_by: +source_references: +created_at: +updated_at: +``` + +## 20.2 Source + +A **Source** is an origin of information. + +## 20.3 Activity + +An **Activity** is an action that creates, modifies, maps, reviews, assimilates, or publishes an artifact. + +## 20.4 AgentReference + +An **AgentReference** points to a human, organization, tool, or AI/software agent involved in an activity. + +## 20.5 Influence + +An **Influence** records that one artifact, source, activity, or agent influenced another. + +## 20.6 Provenance Rule + +```text +Important canon changes SHOULD preserve provenance and rationale. +``` + +--- + +# 21. Repository Model + +## 21.1 Recommended Top-Level Repository Structure + +```text +info-tech-canon/ + README.md + INTENT.md + SCOPE.md + canon.yaml + + core/ + standards/ + patterns/ + profiles/ + mappings/ + assimilation/ + schemas/ + views/ + agent/ + examples/ + validation/ +``` + +## 21.2 Standard Directory Structure + +```text +standards// + InfoTechCanonModel.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +## 21.3 Core Directory Structure + +```text +core/ + InfoTechCanonCore.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + schemas/ + validation/ +``` + +## 21.4 Generated Views + +Generated views SHOULD be marked as generated. + +```text +views/ + by-standard.md + by-concept.md + by-pattern.md + by-profile.md + by-mapping-target.md + by-status.md + use-paths.md +``` + +--- + +# 22. Machine-Readable Artifact Requirements + +## 22.1 Markdown Front Matter + +Markdown artifacts SHOULD use structured front matter. + +Recommended base fields: + +```yaml +id: +title: +type: +status: +version: +canonical_owner: +created_at: +updated_at: +summary: +imports: +related: +tags: +mappings: +``` + +## 22.2 YAML / JSON Exports + +Mature repositories SHOULD be able to export: + +```text +concepts.yaml +relationships.yaml +patterns.yaml +profiles.yaml +mappings.yaml +validation-rules.yaml +conformance-levels.yaml +``` + +## 22.3 Schema Files + +Schema files SHOULD define expected structure for: + +```text +standard +concept +relationship +pattern +profile +mapping +assimilation +validation rule +interface card +agent brief +``` + +--- + +# 23. Agent Model + +## 23.1 AgentBrief + +An AgentBrief SHOULD help an AI agent use a standard correctly. + +Recommended file name: + +```text +agent-brief.md +``` + +## 23.2 Agent Retrieval Requirements + +Agent-facing artifacts SHOULD support: + +```text +stable headings +stable identifiers +short definitions +do / do not rules +common mistakes +minimal examples +mapping references +validation hints +``` + +## 23.3 Agent Safety Boundary + +When agents generate or modify canon artifacts, the change SHOULD include: + +```text +source context +generated artifact +rationale +review expectation +human approval requirement if needed +``` + +## 23.4 Agent Rule + +```text +Agent-generated canon changes SHOULD be reviewable, attributable, and reversible. +``` + +--- + +# 24. Canon Interface Card Model + +## 24.1 Purpose + +A Canon Interface Card declares how a subsystem, repository, service, or tool connects to InfoTechCanon. + +## 24.2 Structure + +```yaml +subsystem: +description: +implements: +produces: +consumes: +owned_concepts: +accepted_relationships: +emitted_events: +required_identifiers: +mapping_rules: +validation_rules: +source_of_truth: +known_deviations: +owner: +status: +``` + +## 24.3 Use Cases + +Canon Interface Cards support: + +```text +repository integration +service integration +agent onboarding +tool mapping +source-of-truth declaration +schema boundary declaration +knowledge ownership +``` + +## 24.4 Rule + +```text +A subsystem SHOULD declare what it produces, consumes, owns, and maps. +``` + +--- + +# 25. Quality Model + +## 25.1 Gap + +A **Gap** is a missing concept, relationship, mapping, profile, pattern, validation rule, or artifact. + +## 25.2 Conflict + +A **Conflict** is a contradiction between concepts, definitions, mappings, rules, or profiles. + +## 25.3 Overlap + +An **Overlap** occurs when two artifacts cover the same concern without clear ownership. + +## 25.4 Ambiguity + +An **Ambiguity** occurs when a term or concept has unclear meaning or boundary. + +## 25.5 Drift + +**Drift** occurs when artifact usage diverges from definition, source, or intended model. + +## 25.6 OpenQuestion + +An **OpenQuestion** is an unresolved issue requiring research, decision, assimilation, or design work. + +--- + +# 26. Core Patterns + +## 26.1 Pattern: Concept Owner + +**Context:** Multiple standards need the same term. + +**Problem:** Definitions diverge. + +**Solution:** Assign one canonical owner and require other standards to import or map. + +--- + +## 26.2 Pattern: Mapping Not Obedience + +**Context:** External standards are important. + +**Problem:** Internal models become distorted by external frameworks. + +**Solution:** Use mappings with type, scope, confidence, rationale, and version. + +--- + +## 26.3 Pattern: Profile Not Fork + +**Context:** A concrete implementation needs constraints. + +**Problem:** Teams fork the standard and create incompatibility. + +**Solution:** Define a profile that constrains canonical concepts without redefining them. + +--- + +## 26.4 Pattern: Assimilate Before Adopt + +**Context:** A new body of knowledge appears. + +**Problem:** Copying concepts directly creates overlap and contradiction. + +**Solution:** Run assimilation: extract, compare, map, identify gaps/conflicts, propose changes. + +--- + +## 26.5 Pattern: Agent Brief Beside Full Standard + +**Context:** Agents need concise context. + +**Problem:** Full standards are too large for routine use. + +**Solution:** Maintain `agent-brief.md` beside the full standard and validate it against the standard. + +--- + +## 26.6 Pattern: Source-Carrying Claim + +**Context:** A claim influences a concept, mapping, or rule. + +**Problem:** Unsupported claims become hard to trust. + +**Solution:** Link claims to source references, evidence, and provenance where appropriate. + +--- + +## 26.7 Pattern: Generated View Not Source + +**Context:** Indexes and views improve navigation. + +**Problem:** Generated views drift if manually edited. + +**Solution:** Treat generated views as derived artifacts and mark their source. + +--- + +# 27. Core Profiles + +## 27.1 InfoTechCanon Standard Profile + +A standard conforming to this profile SHOULD include: + +```text +1. Purpose +2. Position in InfoTechCanon +3. Boundary with Adjacent Standards +4. Research Basis and External Alignment +5. Design Stance +6. Scope +7. Normative Language +8. Core Principles +9. Metadata +10. Root Taxonomy +11. Core Concepts +12. Relationship Vocabulary +13. State Models +14. Patterns +15. Profiles +16. Mapping Model +17. Assimilation Hooks +18. Integration with Other Standards +19. Canon Interface Card Usage +20. Retrieval Requirements +21. Conformance Levels +22. Validation Rules +23. Anti-Patterns +24. Repository Placement +25. Roadmap +26. Summary +``` + +## 27.2 Minimal Concept Page Profile + +A concept page SHOULD include: + +```text +id +preferred label +definition +canonical owner +status +examples +non-examples +related concepts +mappings +validation notes +``` + +## 27.3 Minimal Mapping Profile + +A mapping SHOULD include: + +```text +source concept +target body +target version +target concept +mapping type +scope +not valid for +rationale +confidence +status +owner +``` + +## 27.4 Minimal Assimilation Profile + +An assimilation workspace SHOULD include: + +```text +source summary +extracted concepts +comparison matrix +gaps +conflicts +mappings +proposed changes +open questions +``` + +## 27.5 Minimal Agent Brief Profile + +An agent brief SHOULD include: + +```text +purpose +scope +owned concepts +imported concepts +do / do not rules +common mistakes +minimal examples +validation hints +``` + +--- + +# 28. Core Validation Rules + +Initial validation rules: + +```text +VAL-CORE-001: Every standard SHOULD declare id, title, short name, status, version, purpose, scope, and owned concepts. + +VAL-CORE-002: Every canonical concept SHOULD declare canonical owner. + +VAL-CORE-003: A concept SHOULD NOT be owned by more than one standard. + +VAL-CORE-004: Standards SHOULD import external InfoTechCanon concepts instead of redefining them. + +VAL-CORE-005: A profile MUST NOT redefine canonical concept meaning. + +VAL-CORE-006: A mapping SHOULD declare mapping type, scope, confidence, target version, and rationale. + +VAL-CORE-007: An assimilation SHOULD produce mappings, gaps, conflicts, proposed changes, and open questions. + +VAL-CORE-008: Deprecated artifacts SHOULD reference replacements where available. + +VAL-CORE-009: Generated views SHOULD be marked as generated or derived. + +VAL-CORE-010: Agent briefs SHOULD be reviewed against their source standards. + +VAL-CORE-011: Important canon changes SHOULD include provenance and rationale. + +VAL-CORE-012: Validation rules SHOULD declare applicability and severity. + +VAL-CORE-013: Canon Interface Cards SHOULD declare produces, consumes, source-of-truth, and known deviations. + +VAL-CORE-014: External standards SHOULD be mapped or assimilated rather than silently copied. + +VAL-CORE-015: Identifiers SHOULD be stable and namespace-qualified. + +VAL-CORE-016: Mappings marked exactMatch SHOULD be reviewed carefully and justified. + +VAL-CORE-017: Open questions SHOULD be tracked rather than hidden in prose. + +VAL-CORE-018: Domain standards SHOULD not own generic canon mechanisms already owned by Core. +``` + +--- + +# 29. Core Anti-Patterns + +## 29.1 Standard Sprawl + +Creating many standards without shared structure, identifiers, mappings, profiles, or validation. + +## 29.2 Concept Doppelgänger + +The same concept is defined independently in multiple standards. + +## 29.3 External Standard Capture + +The canon bends around one external standard and loses adaptability. + +## 29.4 Profile Fork + +A local profile redefines concepts instead of constraining them. + +## 29.5 Mapping in Prose Only + +Mappings are mentioned in paragraphs but not represented as artifacts. + +## 29.6 Assimilation by Copy-Paste + +External knowledge is copied without comparison, conflict analysis, or internal ownership. + +## 29.7 Agent Brief Drift + +Agent briefs become stale and contradict full standards. + +## 29.8 Generated View as Canon + +Generated indexes or diagrams are edited manually and become false sources. + +## 29.9 Validation Afterthought + +Validation rules are added after incompatible artifacts have accumulated. + +## 29.10 Provenance-Free Evolution + +Concepts change without rationale, source, or compatibility notes. + +--- + +# 30. Initial Repository Placement + +Recommended placement: + +```text +info-tech-canon/ + core/ + InfoTechCanonCore.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + schemas/ + validation/ +``` + +Seed files: + +```text +core/InfoTechCanonCore.md +core/agent-brief.md +core/concepts/canon-artifact.md +core/concepts/standard.md +core/concepts/concept.md +core/concepts/mapping.md +core/concepts/assimilation.md +core/concepts/pattern.md +core/concepts/profile.md +core/concepts/validation-rule.md +core/concepts/conformance-level.md +core/concepts/canon-interface-card.md +core/patterns/concept-owner.md +core/patterns/mapping-not-obedience.md +core/patterns/profile-not-fork.md +core/patterns/assimilate-before-adopt.md +core/profiles/infotechcanon-standard-profile.md +core/profiles/minimal-concept-page-profile.md +core/profiles/minimal-mapping-profile.md +core/profiles/minimal-agent-brief-profile.md +core/schemas/concept.schema.yaml +core/schemas/mapping.schema.yaml +core/schemas/profile.schema.yaml +core/schemas/assimilation.schema.yaml +core/schemas/interface-card.schema.yaml +core/validation/core-validation-rules.yaml +``` + +--- + +# 31. Roadmap + +## Phase 1: Core Stabilization + +- Establish this standard as `InfoTechCanonCore`. +- Define schema files for concept, standard, mapping, profile, assimilation, pattern, validation rule, and interface card. +- Create agent brief. +- Create validation rule index. + +## Phase 2: Refactor Existing Seed Standards + +Refactor these standards to import Core mechanisms: + +```text +InfoTechCanonLandscapeModel +InfoTechCanonOrganizationModel +InfoTechCanonGovernanceModel +InfoTechCanonTaskModel +InfoTechCanonTaggingStandard +InfoTechCanonAccessControlModel +InfoTechCanonSecurityModel +InfoTechCanonDataModel +InfoTechCanonDevSecOpsModel +InfoTechCanonNetworkModel +InfoTechCanonObservabilityModel +InfoTechCanonInformationSpaceModel +``` + +Remove duplicated generic mechanism sections where practical. + +## Phase 3: Machine-Readable Foundation + +- Add YAML schemas. +- Add concept indexes. +- Add mapping indexes. +- Add validation scripts. +- Add generated views. + +## Phase 4: Assimilation Pipeline + +- Create assimilation workspace template. +- Run first formal assimilation using a selected external standard. +- Produce mappings and proposed changes. + +## Phase 5: Interface Card Adoption + +- Create Canon Interface Cards for key repositories and tools. +- Use cards to align subsystem integration. + +## Phase 6: Agent Integration + +- Create agent briefs for all standards. +- Add retrieval tests. +- Add agent-safe generation rules. +- Integrate with markdown infobase tooling and agentic coding workflows. + +--- + +# 32. Summary + +InfoTechCanonCore is the constitutional seed standard for the InfoTechCanon system. + +It owns the general mechanisms used by all other standards: + +```text +canon artifacts +concept ownership +relationships +mappings +assimilation +patterns +profiles +validation +conformance +versioning +provenance +repository conventions +agent briefs +canon interface cards +``` + +Its most important commitments are: + +```text +One canonical owner per concept. + +Import, do not redefine. + +Map external standards without obeying them. + +Assimilate external knowledge before adopting it. + +Use profiles instead of forks. + +Make patterns practical. + +Preserve provenance and compatibility. + +Make artifacts readable by humans and usable by agents. +``` + +This makes InfoTechCanonCore the stabilizing layer that turns the seeded standards from a collection of documents into a coherent, evolvable, interoperable canon system. diff --git a/seeds/InfoTechCanonDataModel_RC1_seed.md b/seeds/InfoTechCanonDataModel_RC1_seed.md new file mode 100755 index 0000000..cf46137 --- /dev/null +++ b/seeds/InfoTechCanonDataModel_RC1_seed.md @@ -0,0 +1,2180 @@ +# InfoTechCanon Data Model + +**Short Name:** `ITC-DATA` +**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:** Data architects, data engineers, data stewards, platform engineers, governance designers, security architects, application architects, product owners, knowledge-system builders, compliance reviewers, AI/analytics teams, and agentic tooling. + +--- + +# 1. Purpose + +The **InfoTechCanon Data Model** defines a canonical seed model for representing data as a managed, governed, discoverable, classifiable, lineage-bearing, quality-assessable, and reusable information asset. + +It exists to give data its own canonical domain instead of leaving data semantics scattered across landscape, security, governance, DevSecOps, observability, and application models. + +This standard provides a canonical vocabulary for: + +- data domains, +- datasets, +- data products, +- data objects, +- records, +- fields, +- schemas, +- data elements, +- code lists, +- data stores as references, +- data flows, +- data lineage, +- data quality, +- metadata, +- catalogs, +- distributions, +- data services, +- data classification, +- sensitivity, +- residency, +- retention, +- processing purpose, +- data ownership and stewardship references, +- data contracts, +- and data evidence. + +--- + +# 2. Position in InfoTechCanon + +The Data Model is a **domain standard** within InfoTechCanon. + +It depends on the existing seed standards as follows: + +```text +Landscape = where data is stored, processed, moved, and exposed. +Organization = data owners, stewards, custodians, producers, consumers. +Governance = data policies, obligations, controls, evidence, exceptions. +Security = data exposure, data-security findings, data attack paths. +Access Control = permissions and grants to data resources. +Task = data-quality work, migration work, remediation, reviews. +Tagging = lightweight classification and retrieval. +Data = datasets, schemas, metadata, lineage, quality, classification, retention. +``` + +```text +InfoTechCanon +├── InfoTechCanonCore +├── InfoTechCanonLandscapeModel +├── InfoTechCanonOrganizationModel +├── InfoTechCanonGovernanceModel +├── InfoTechCanonTaskModel +├── InfoTechCanonTaggingStandard +├── InfoTechCanonAccessControlModel +├── InfoTechCanonSecurityModel +├── InfoTechCanonDataModel <-- this standard +├── InfoTechCanonDevSecOpsModel +├── InfoTechCanonNetworkModel +├── InfoTechCanonObservabilityModel +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +--- + +# 3. Boundary with Adjacent Standards + +## 3.1 Boundary with Landscape + +The Landscape Model owns: + +```text +DataStore +DatabaseInstance +ObjectBucket +FileShare +Queue +Cache +RuntimeResource +ApplicationService +IntegrationFlow +Endpoint +``` + +The Data Model owns: + +```text +Dataset +DataProduct +DataObject +Schema +Field +DataElement +DataFlow +DataLineage +DataClassification +DataQualityRule +DataContract +DataDistribution +``` + +Boundary rule: + +```text +Landscape owns the technical and runtime places where data lives or moves. +Data owns the semantic, structural, quality, classification, and lineage meaning of data. +``` + +## 3.2 Boundary with Governance + +The Governance Model owns: + +```text +Policy +Requirement +Obligation +Control +Risk +Exception +Evidence +Review +Approval +ComplianceRequirement +``` + +The Data Model owns data-specific structures that are governed: + +```text +RetentionRuleReference +ProcessingPurpose +DataClassification +DataQualityRule +DataContract +DataLineage +``` + +Boundary rule: + +```text +Governance defines why data must be governed. +Data defines what data is and how it is described, classified, measured, and traced. +``` + +## 3.3 Boundary with Security + +The Security Model owns: + +```text +DataSecurityFinding +ExposureFinding +CredentialExposure +SecurityIncident +AttackPath +Mitigation +``` + +The Data Model owns: + +```text +Sensitivity +Classification +DataResidency +DataSubjectCategory +DataCategory +DataLineage +``` + +Security may use these for posture analysis. + +## 3.4 Boundary with Access Control + +Access Control owns permissions, grants, authorization decisions, and enforcement. + +Data owns data resources and classifications that access policies may use. + +Example: + +```text +Dataset classified_as Confidential +AccessPolicy permits Role to read Dataset +AuthorizationDecision permits read on Dataset +``` + +## 3.5 Boundary with Organization + +Organization owns actors and responsibilities. + +Data references Organization concepts for: + +```text +DataOwner +DataSteward +DataCustodian +DataProducer +DataConsumer +DataTrustee +``` + +## 3.6 Boundary with DevSecOps + +DevSecOps owns source, build, artifact, pipeline, release, deployment, SBOM, and attestation semantics. + +Data owns data contracts, schema evolution, migration data, test data, synthetic data, lineage, and data-quality semantics. + +--- + +# 4. Research Basis and External Alignment + +This seed standard draws on multiple data-management bodies of knowledge. + +## 4.1 DAMA-DMBOK + +DAMA-DMBOK is a broad reference for data management disciplines including data governance, architecture, modeling, storage, security, integration, documents/content, reference/master data, warehousing/BI, metadata, and data quality. InfoTechCanon uses it as a broad mapping and assimilation target, not as a direct controlling model. + +## 4.2 DCAT + +W3C DCAT defines a vocabulary for data catalogs. DCAT Version 3 organizes catalog access around datasets, distributions, data services, and dataset series. This is highly relevant for InfoTechCanon catalog, dataset, distribution, and data-service concepts. + +## 4.3 PROV-O + +W3C PROV-O models provenance using entities, activities, and agents. This is highly relevant for data lineage, derivation, generation, transformation, and responsibility. + +## 4.4 ISO/IEC 11179 + +ISO/IEC 11179 provides a metadata registry framework for data elements, naming, identification, definitions, classification, and registration. It is an important mapping target for data element, representation, data definition, code list, and metadata registry concepts. + +## 4.5 Data Mesh and Data Products + +Data product thinking emphasizes ownership, discoverability, quality, fitness for use, service-like interfaces, and domain responsibility. InfoTechCanon should support data products without requiring a specific data-mesh organizational model. + +## 4.6 Data Contracts + +Data contracts define expectations between producers and consumers around schema, semantics, quality, delivery, compatibility, ownership, and change management. They are critical for reliable information-processing systems. + +## 4.7 Privacy and Data Protection Practice + +Privacy and data-protection practice contributes concepts such as personal data, sensitive data, data subject, processing purpose, lawful basis, retention, residency, and minimization. The Data Model provides data semantics, while Governance owns legal obligations and Security owns data exposure and incident semantics. + +--- + +# 5. Seed Standard Design Stance + +This standard is a **seed standard**, not a full data-governance or database-design manual. + +It shall: + +1. define canonical data semantics, +2. distinguish data from storage infrastructure, +3. distinguish dataset, data product, data object, schema, field, and data element, +4. support data classification, lineage, quality, retention, residency, and processing purpose, +5. support catalog and discovery concepts, +6. support data contracts and schema evolution, +7. support operational, analytical, reference, master, event, and document data, +8. support mappings to external standards without becoming subordinate to them, +9. remain markdown-first and agent-retrievable, +10. and support future assimilation of data standards, platforms, regulations, and product schemas. + +--- + +# 6. Scope + +## 6.1 In Scope + +This standard covers canonical representation of: + +- data domains, +- data products, +- datasets, +- dataset series, +- data distributions, +- data services, +- data objects, +- entities, +- records, +- fields, +- attributes, +- data elements, +- schemas, +- schema versions, +- code lists, +- reference data, +- master data references, +- metadata, +- catalogs, +- data lineage, +- data flows, +- data transformations, +- data quality rules, +- data quality results, +- data contracts, +- data classification, +- sensitivity, +- confidentiality level, +- integrity expectation, +- availability expectation, +- retention rules as data semantics, +- data residency, +- data minimization, +- processing purpose, +- data subject categories, +- data provenance, +- data ownership and stewardship references, +- and data lifecycle states. + +## 6.2 Out of Scope + +This standard does not fully define: + +- database engine internals, +- storage infrastructure, +- full data warehouse architecture, +- full analytics modeling, +- full privacy-law interpretation, +- full data-governance process, +- full security incident handling, +- all ontology modeling, +- all semantic-web representation, +- complete ETL/ELT implementation, +- or every vendor-specific data catalog schema. + +Those may be mapped, assimilated, profiled, or handled by adjacent standards. + +--- + +# 7. 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 defined provisionally here but open to later refinement. +- **EXTRACT** marks a concept that may later move to a more specialized standard. + +--- + +# 8. Core Principles + +## 8.1 Data Is Not Its Store + +A dataset is not the same thing as a database, bucket, table, file, topic, or API. + +Storage and runtime locations are Landscape concepts. Data semantics belong here. + +## 8.2 Dataset Is Not Schema + +A dataset may have one or more schemas, distributions, versions, contracts, lineage records, and quality expectations. + +## 8.3 Schema Is Not Meaning + +A schema describes structure. It does not fully define business meaning, ownership, usage constraints, quality, or purpose. + +## 8.4 Classification Is First-Class + +Data classification and sensitivity SHOULD be explicit where data has security, privacy, compliance, operational, or business significance. + +## 8.5 Lineage Is Evidence-Carrying + +Lineage SHOULD identify source data, transformations, activities, agents, and derived outputs with confidence and evidence where possible. + +## 8.6 Data Quality Is Contextual + +Data quality depends on intended use, domain meaning, contract expectations, and consumer needs. + +## 8.7 Data Contracts Make Data Reliable + +Producer-consumer expectations SHOULD be explicit when data is reused across system boundaries. + +## 8.8 External Standards Are Mapped, Not Obeyed + +The Data Model MAY map to DAMA-DMBOK, DCAT, PROV-O, ISO/IEC 11179, schema.org, OpenLineage, DataHub, OpenMetadata, dbt, Great Expectations, or similar standards and tools. + +It MUST NOT subordinate its internal semantics to any single external model. + +--- + +# 9. Canonical Seed Metadata + +Every data artifact SHOULD support structured metadata. + +Recommended front matter: + +```yaml +--- +id: itc-data:Dataset +type: concept +standard: InfoTechCanonDataModel +standard_version: RC1-seed +status: candidate +canonical_owner: InfoTechCanonDataModel +preferred_label: Dataset +related: + - itc-data:DataProduct + - itc-data:Schema + - itc-data:DataDistribution + - itc-data:DataLineage +mappings: + - itc-map:dataset-to-dcat-dataset +--- +``` + +Recommended artifact statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +Recommended concept statuses: + +```text +proposed +experimental +candidate +canonical +deprecated +retired +``` + +--- + +# 10. Root Data Taxonomy + +```text +DataEntity +├── DataAssetEntity +│ ├── DataDomain +│ ├── DataProduct +│ ├── Dataset +│ ├── DatasetSeries +│ ├── DataDistribution +│ ├── DataService +│ ├── DataObject +│ ├── Record +│ └── DocumentData +├── StructureEntity +│ ├── Schema +│ ├── SchemaVersion +│ ├── Field +│ ├── Attribute +│ ├── DataElement +│ ├── DataElementConcept +│ ├── Representation +│ ├── DataType +│ ├── Constraint +│ └── CodeList +├── SemanticEntity +│ ├── BusinessTerm +│ ├── GlossaryTerm +│ ├── ConceptualEntity +│ ├── DataDefinition +│ ├── ReferenceData +│ ├── MasterDataReference +│ └── CanonicalValue +├── GovernanceReferenceEntity +│ ├── DataClassification +│ ├── Sensitivity +│ ├── DataCategory +│ ├── DataSubjectCategory +│ ├── ProcessingPurpose +│ ├── RetentionRuleReference +│ ├── DataResidency +│ └── DataUsageConstraint +├── QualityEntity +│ ├── DataQualityDimension +│ ├── DataQualityRule +│ ├── DataQualityCheck +│ ├── DataQualityResult +│ ├── DataQualityIssue +│ └── FitnessForUse +├── LineageEntity +│ ├── DataFlow +│ ├── DataLineage +│ ├── Transformation +│ ├── Derivation +│ ├── SourceDataset +│ ├── TargetDataset +│ └── ProvenanceRecord +├── ContractEntity +│ ├── DataContract +│ ├── ProducerExpectation +│ ├── ConsumerExpectation +│ ├── CompatibilityRule +│ ├── BreakingChange +│ └── SchemaEvolutionPolicy +└── OperationalDataEntity + ├── DataPipelineReference + ├── DataStoreReference + ├── QueryReference + ├── DataAccessPattern + ├── DataFreshness + └── DataAvailability +``` + +--- + +# 11. Core Concepts + +## 11.1 DataEntity + +A **DataEntity** is any identifiable concept used to represent data, metadata, structure, classification, quality, lineage, contract, or data lifecycle. + +Recommended attributes: + +```yaml +id: +entity_type: +canonical_name: +display_name: +lifecycle_state: +source_system: +created_at: +updated_at: +``` + +Optional attributes: + +```yaml +owner: +steward: +data_domain: +classification: +source_confidence: +valid_from: +valid_to: +tags: +external_references: +``` + +--- + +## 11.2 DataDomain + +A **DataDomain** is a bounded area of data meaning, ownership, stewardship, or subject matter. + +Examples: + +```text +customer +billing +product +identity +orders +support +security +operations +finance +``` + +--- + +## 11.3 DataProduct + +A **DataProduct** is a managed data asset or set of data assets offered for use by consumers with explicit ownership, quality expectations, documentation, interfaces, and lifecycle. + +Recommended attributes: + +```yaml +owner: +steward: +producer: +consumers: +service_level_expectations: +quality_expectations: +contract: +distribution_methods: +``` + +--- + +## 11.4 Dataset + +A **Dataset** is a coherent collection of data published, managed, processed, analyzed, or consumed as a unit. + +A dataset may have: + +```text +schema +distribution +catalog entry +classification +lineage +quality rules +owner +steward +contract +retention expectation +``` + +Canonical rule: + +```text +Dataset MUST NOT be treated as identical to its storage location. +``` + +--- + +## 11.5 DatasetSeries + +A **DatasetSeries** is a sequence or family of related datasets organized over time, version, geography, domain, or release. + +--- + +## 11.6 DataDistribution + +A **DataDistribution** is an accessible representation of a dataset. + +Examples: + +```text +CSV file +Parquet file +API response +database table export +event stream +report download +object storage path +``` + +--- + +## 11.7 DataService + +A **DataService** is a service that provides access to data or operations over data. + +Examples: + +```text +query API +data product API +metadata API +streaming endpoint +analytics service +``` + +--- + +## 11.8 DataObject + +A **DataObject** is a meaningful object or structure represented in data. + +Examples: + +```text +Customer +Invoice +Order +Payment +Product +Device +UserProfile +AccessGrant +SecurityFinding +``` + +--- + +## 11.9 Record + +A **Record** is an instance-level representation of data about an entity, event, relationship, or observation. + +--- + +## 11.10 Field + +A **Field** is a named component of a schema, record, message, or table. + +--- + +## 11.11 Attribute + +An **Attribute** is a property of a data object or conceptual entity. + +A field may represent an attribute, but field is structural while attribute is semantic. + +--- + +## 11.12 DataElement + +A **DataElement** is a defined unit of data with meaning, representation, and expected usage. + +It may map to ISO/IEC 11179 data element concepts. + +Recommended attributes: + +```yaml +object_class: +property: +representation: +data_type: +definition: +permitted_values: +``` + +--- + +## 11.13 DataElementConcept + +A **DataElementConcept** is the semantic idea of a data element independent of representation. + +Example: + +```text +Customer birth date +Invoice total amount +Repository default branch name +``` + +--- + +## 11.14 Representation + +A **Representation** describes how a data element is represented. + +Examples: + +```text +string +integer +decimal +boolean +date +timestamp +code +identifier +URI +``` + +--- + +## 11.15 DataType + +A **DataType** specifies the technical or logical type of a field or data element. + +--- + +## 11.16 Constraint + +A **Constraint** is a rule limiting valid data. + +Examples: + +```text +required +unique +minimum +maximum +regex +foreign key +enum +format +cardinality +``` + +--- + +## 11.17 CodeList + +A **CodeList** is a controlled set of allowed values with definitions. + +Examples: + +```text +country codes +currency codes +status codes +classification labels +risk levels +``` + +--- + +## 11.18 BusinessTerm + +A **BusinessTerm** is a term used by domain actors to describe data meaning. + +--- + +## 11.19 GlossaryTerm + +A **GlossaryTerm** is a documented term in a glossary with definition, synonyms, ownership, and mappings. + +--- + +## 11.20 DataDefinition + +A **DataDefinition** is a textual or structured definition explaining the meaning, scope, and intended use of a data concept. + +--- + +## 11.21 ReferenceData + +**ReferenceData** is data used to classify, categorize, or constrain other data. + +Examples: + +```text +country list +currency list +product category list +status code list +business unit list +``` + +--- + +## 11.22 MasterDataReference + +A **MasterDataReference** points to a controlled source of core business entities. + +Examples: + +```text +customer master +product master +supplier master +employee master +``` + +The Data Model references master-data semantics but does not require a specific MDM architecture. + +--- + +## 11.23 DataClassification + +A **DataClassification** is a classification assigned to data based on sensitivity, confidentiality, regulatory concern, operational criticality, or business significance. + +Examples: + +```text +public +internal +confidential +restricted +regulated +personal +sensitive personal +secret +``` + +--- + +## 11.24 Sensitivity + +**Sensitivity** indicates potential harm, obligation, or restriction associated with data disclosure, modification, loss, misuse, or processing. + +--- + +## 11.25 DataCategory + +A **DataCategory** groups data by semantic, legal, operational, or analytical type. + +Examples: + +```text +personal data +financial data +health data +authentication data +transaction data +telemetry data +metadata +content data +``` + +--- + +## 11.26 DataSubjectCategory + +A **DataSubjectCategory** identifies the kind of person or entity data is about. + +Examples: + +```text +customer +employee +applicant +supplier contact +child +patient +user +administrator +``` + +--- + +## 11.27 ProcessingPurpose + +A **ProcessingPurpose** describes why data is collected, stored, transformed, shared, or used. + +Examples: + +```text +billing +support +security monitoring +analytics +product improvement +legal compliance +identity verification +``` + +--- + +## 11.28 RetentionRuleReference + +A **RetentionRuleReference** links data to governance-defined retention obligations, policies, or rules. + +The Data Model may model retention expectation, but Governance owns the policy and obligation. + +--- + +## 11.29 DataResidency + +**DataResidency** describes where data is stored, processed, transferred, or legally required to remain. + +Examples: + +```text +EU +Germany +customer region +cloud region +on-premises only +``` + +--- + +## 11.30 DataUsageConstraint + +A **DataUsageConstraint** describes a restriction on how data may be used. + +Examples: + +```text +not for training +not for export +internal analytics only +production use prohibited +no cross-border transfer +only aggregated use +``` + +--- + +## 11.31 DataQualityDimension + +A **DataQualityDimension** is an aspect of data quality. + +Common dimensions: + +```text +accuracy +completeness +consistency +timeliness +validity +uniqueness +freshness +integrity +fitness_for_use +``` + +--- + +## 11.32 DataQualityRule + +A **DataQualityRule** is a testable expectation about data quality. + +Examples: + +```text +customer_id must not be null +invoice_total must be >= 0 +country_code must be in ISO country code list +event_timestamp must be within expected delay window +``` + +--- + +## 11.33 DataQualityCheck + +A **DataQualityCheck** is an execution of one or more data quality rules. + +--- + +## 11.34 DataQualityResult + +A **DataQualityResult** is the outcome of a data quality check. + +--- + +## 11.35 DataQualityIssue + +A **DataQualityIssue** is a finding indicating data does not meet a quality rule or fitness expectation. + +It may create Task Model remediation work. + +--- + +## 11.36 FitnessForUse + +**FitnessForUse** is the degree to which data is suitable for a specific purpose or consumer context. + +--- + +## 11.37 DataFlow + +A **DataFlow** is movement or transfer of data between sources, systems, stores, services, actors, or processes. + +--- + +## 11.38 DataLineage + +**DataLineage** describes the origin, movement, transformation, derivation, and usage path of data. + +Lineage may include: + +```text +source dataset +transformation +activity +agent +target dataset +time +evidence +confidence +``` + +--- + +## 11.39 Transformation + +A **Transformation** is an activity that changes data structure, content, format, aggregation, classification, or meaning. + +--- + +## 11.40 Derivation + +A **Derivation** is a relationship where one data entity is derived from another. + +--- + +## 11.41 ProvenanceRecord + +A **ProvenanceRecord** records information about how data came to exist, who or what generated it, what activity produced it, and what source influenced it. + +--- + +## 11.42 DataContract + +A **DataContract** is an explicit agreement between data producers and consumers about data structure, semantics, quality, delivery, compatibility, ownership, and change expectations. + +--- + +## 11.43 ProducerExpectation + +A **ProducerExpectation** describes what a data producer commits to provide. + +Examples: + +```text +schema stability +freshness +completeness +availability +documentation +change notice +``` + +--- + +## 11.44 ConsumerExpectation + +A **ConsumerExpectation** describes what a data consumer expects or is allowed to assume. + +--- + +## 11.45 CompatibilityRule + +A **CompatibilityRule** describes what changes are considered compatible or breaking. + +--- + +## 11.46 BreakingChange + +A **BreakingChange** is a data, schema, semantic, quality, or delivery change that violates consumer expectations or compatibility rules. + +--- + +## 11.47 SchemaEvolutionPolicy + +A **SchemaEvolutionPolicy** defines rules for how schemas may change over time. + +--- + +## 11.48 DataStoreReference + +A **DataStoreReference** points to a Landscape data store or storage resource. + +Examples: + +```text +database +table +bucket +file share +topic +queue +index +warehouse +lakehouse table +``` + +--- + +## 11.49 DataAccessPattern + +A **DataAccessPattern** describes how data is accessed. + +Examples: + +```text +batch export +API query +event stream +direct database query +file download +replication +analytics dashboard +``` + +--- + +## 11.50 DataFreshness + +**DataFreshness** describes how current data is relative to a defined expectation. + +--- + +## 11.51 DataAvailability + +**DataAvailability** describes whether data is accessible according to expectations. + +--- + +# 12. Core Relationship Vocabulary + +Recommended root relationship types: + +```text +contains +part_of +describes +classified_as +has_schema +has_field +has_distribution +provided_by +consumed_by +stored_in +accessed_via +flows_to +derived_from +generated_by +transformed_by +governed_by +constrained_by +subject_to +owned_by +stewarded_by +produced_by +consumed_by +validated_by +violates +satisfies +maps_to +``` + +Relationship records SHOULD support: + +```yaml +id: +relationship_type: +source_entity: +target_entity: +scope: +valid_from: +valid_to: +source_system: +confidence: +evidence: +rationale: +``` + +--- + +# 13. Data State Models + +## 13.1 Dataset Lifecycle States + +```text +proposed +designed +active +deprecated +retired +archived +deleted +``` + +## 13.2 Schema States + +```text +draft +candidate +active +deprecated +superseded +retired +``` + +## 13.3 Data Quality States + +```text +unknown +unchecked +passing +warning +failing +waived +remediating +verified +``` + +## 13.4 Data Contract States + +```text +draft +under_review +active +violated +deprecated +superseded +retired +``` + +## 13.5 Lineage Confidence States + +```text +unknown +declared +inferred +observed +verified +conflicting +``` + +--- + +# 14. Data Patterns + +## 14.1 Pattern: Data Is Not Its Store + +**Context:** Teams model data by pointing at tables, buckets, or files. + +**Problem:** Storage location does not explain semantic meaning, ownership, classification, quality, or lineage. + +**Solution:** Model Dataset, Schema, Distribution, StoreReference, and Lineage separately. + +--- + +## 14.2 Pattern: Dataset Catalog Entry + +**Context:** Data consumers need to discover and understand data. + +**Problem:** Data assets remain invisible or only known by tribal knowledge. + +**Solution:** Provide a catalog entry with: + +```text +dataset name +description +owner +steward +classification +schema +distribution +quality expectations +lineage +access method +usage constraints +``` + +--- + +## 14.3 Pattern: Data Contract at Boundary + +**Context:** Data crosses a team, service, product, or system boundary. + +**Problem:** Consumers break when producers change data unexpectedly. + +**Solution:** Define a DataContract with schema, semantic expectations, quality rules, compatibility rules, and change process. + +--- + +## 14.4 Pattern: Classification Drives Controls + +**Context:** Data has different sensitivity and obligations. + +**Problem:** Systems apply uniform controls or rely on ad hoc judgment. + +**Solution:** Classify data and map classifications to governance controls, access policies, security measures, and retention expectations. + +--- + +## 14.5 Pattern: Lineage as Evidence + +**Context:** A derived dataset is used for decisions or compliance. + +**Problem:** Consumers cannot determine origin, transformations, or trustworthiness. + +**Solution:** Model lineage with source datasets, transformations, activities, agents, target datasets, and evidence. + +--- + +## 14.6 Pattern: Quality Rule to Remediation + +**Context:** Data quality checks fail. + +**Problem:** Failures remain dashboards instead of corrective action. + +**Solution:** + +```text +DataQualityRule + -> DataQualityCheck + -> DataQualityResult + -> DataQualityIssue + -> RemediationTask + -> VerificationEvidence +``` + +--- + +## 14.7 Pattern: Semantic Term and Field Split + +**Context:** Database columns are treated as business terms. + +**Problem:** Field names do not fully encode business meaning. + +**Solution:** Link Field to DataElement, BusinessTerm, and DataDefinition. + +--- + +## 14.8 Pattern: Retention with Governance Reference + +**Context:** Data must be kept or deleted according to obligations. + +**Problem:** Retention is encoded as undocumented operational behavior. + +**Solution:** Link Dataset or DataObject to RetentionRuleReference and keep the governing obligation in Governance. + +--- + +# 15. Data Profiles + +## 15.1 Profile Format + +A Data Profile SHALL declare: + +```yaml +id: +profile_name: +status: +implements: + - InfoTechCanonDataModel +target_context: +included_concepts: +required_relationships: +required_metadata: +state_model: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +--- + +## 15.2 Seed Profile: Small SaaS Data Profile + +Purpose: + +```text +Provide a minimal data model for a small SaaS platform moving toward production readiness. +``` + +Included concepts: + +```text +DataDomain +Dataset +DataObject +Schema +Field +DataClassification +DataStoreReference +DataFlow +DataQualityRule +RetentionRuleReference +DataOwnerReference +DataStewardReference +``` + +Required relationships: + +```text +Dataset has_schema Schema +Schema has_field Field +Dataset classified_as DataClassification +Dataset stored_in DataStoreReference +Dataset owned_by DataOwnerReference +Dataset stewarded_by DataStewardReference +DataFlow moves Dataset +RetentionRuleReference applies_to Dataset +``` + +--- + +## 15.3 Seed Profile: Data Catalog Profile + +Purpose: + +```text +Represent data catalog entries for discoverability and reuse. +``` + +Included concepts: + +```text +Catalog +Dataset +DatasetSeries +DataDistribution +DataService +DataOwnerReference +DataStewardReference +DataClassification +DataQualitySummary +DataLineageSummary +``` + +Mapping targets: + +```text +DCAT +DCAT-AP +DataHub +OpenMetadata +Amundsen +Collibra / catalog tools +``` + +--- + +## 15.4 Seed Profile: Data Contract Profile + +Purpose: + +```text +Represent data producer-consumer agreements. +``` + +Included concepts: + +```text +DataContract +ProducerExpectation +ConsumerExpectation +Schema +SchemaVersion +DataQualityRule +CompatibilityRule +BreakingChange +ChangeNotice +DataContractViolation +``` + +Required relationships: + +```text +DataContract applies_to Dataset +ProducerExpectation constrains Producer +ConsumerExpectation informs Consumer +CompatibilityRule governs SchemaEvolution +BreakingChange violates DataContract +``` + +--- + +## 15.5 Seed Profile: Data Lineage Profile + +Purpose: + +```text +Represent lineage across datasets, transformations, pipelines, and systems. +``` + +Included concepts: + +```text +Dataset +SourceDataset +TargetDataset +Transformation +DataFlow +DataLineage +ProvenanceRecord +DataPipelineReference +ActivityReference +AgentReference +``` + +Mapping targets: + +```text +PROV-O +OpenLineage +Marquez +dbt exposures/models/sources +DataHub lineage +``` + +--- + +## 15.6 Seed Profile: Privacy-Relevant Data Profile + +Purpose: + +```text +Represent data concepts relevant to privacy, data protection, retention, and processing. +``` + +Included concepts: + +```text +PersonalDataCategory +SensitiveDataCategory +DataSubjectCategory +ProcessingPurpose +DataResidency +RetentionRuleReference +DataUsageConstraint +DataMinimizationExpectation +``` + +Governance owns legal obligations and lawful-basis interpretation. + +--- + +## 15.7 Seed Profile: Analytics Dataset Profile + +Purpose: + +```text +Represent analytical datasets, metrics, dimensions, facts, models, and reports. +``` + +Included concepts: + +```text +Dataset +Metric +Dimension +Fact +Measure +AggregationRule +ReportReference +DashboardReference +DataQualityRule +FreshnessExpectation +``` + +--- + +# 16. Mapping Model for the Data Standard + +Mappings relate InfoTechCanon data concepts to external standards, frameworks, products, and regulations. + +## 16.1 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +regulatoryReference +toolEquivalent +``` + +## 16.2 Mapping Record + +Example: + +```yaml +id: itc-map:dataset-to-dcat-dataset +source_concept: itc-data:Dataset +target_body: W3C DCAT +target_version: "3" +target_concept: dcat:Dataset +mapping_type: closeMatch +scope: + - data catalog interoperability +not_valid_for: + - all internal schema semantics + - all data product lifecycle semantics +rationale: > + DCAT Dataset is a strong catalog-oriented match for InfoTechCanon Dataset, + but InfoTechCanon includes additional governance, quality, contract, + and lineage expectations that may not be required by DCAT. +confidence: high +status: candidate +owner: InfoTechCanonDataModel +``` + +## 16.3 Seed Mapping Targets + +The Data Model SHOULD maintain mappings to: + +```text +DAMA-DMBOK +W3C DCAT 3 +DCAT-AP +W3C PROV-O +ISO/IEC 11179 +schema.org Dataset +OpenLineage +DataHub metadata model +OpenMetadata +dbt sources/models/exposures +Great Expectations +Apache Atlas +Collibra / data catalog concepts +GDPR / privacy-regulation references +Dublin Core metadata +SPDX / CycloneDX data references where relevant +``` + +--- + +# 17. Assimilation Hooks + +The Data Model SHALL be able to receive new data standards, platforms, regulations, product schemas, and practices through the InfoTechCanon assimilation process. + +## 17.1 Assimilation Triggers + +Assimilation may be triggered by: + +```text +new data catalog model +new data lineage standard +new metadata registry standard +new privacy regulation +new data-quality tool +new data-contract practice +new data-product pattern +new analytics modeling method +new data platform integration +new recurring data classification conflict +``` + +## 17.2 Data Assimilation Output + +A data assimilation SHOULD produce: + +```text +source summary +extracted data concepts +concept comparison matrix +gap list +conflict list +mapping file +candidate new concepts +candidate relationship changes +candidate pattern changes +candidate profile changes +open questions +``` + +## 17.3 Recommended First Assimilation Candidates + +```text +W3C DCAT 3 +PROV-O +ISO/IEC 11179 +DAMA-DMBOK +OpenLineage +DataHub +OpenMetadata +Great Expectations +dbt semantic layer / metadata +GDPR data categories and processing concepts +``` + +--- + +# 18. Integration with Other InfoTechCanon Standards + +## 18.1 Landscape Model + +Data references Landscape concepts for: + +```text +data store +database +bucket +queue +topic +pipeline +runtime service +application service +endpoint +environment +``` + +## 18.2 Organization Model + +Data imports organization concepts for: + +```text +data owner +data steward +data custodian +data producer +data consumer +data trustee +responsible team +``` + +## 18.3 Governance Model + +Data imports governance concepts for: + +```text +policy +retention requirement +processing obligation +control +exception +evidence +review +compliance requirement +``` + +## 18.4 Security Model + +Security imports data concepts for: + +```text +classification +sensitivity +data category +data subject category +data exposure +residency +data security finding +``` + +## 18.5 Access Control Model + +Access Control imports data concepts for: + +```text +dataset +data object +data classification +data usage constraint +data access pattern +``` + +## 18.6 Task Model + +Data creates or references tasks such as: + +```text +data-quality remediation +schema migration +contract review +lineage clarification +classification review +retention cleanup +data incident investigation +``` + +## 18.7 Tagging Standard + +Tagging supports data discovery and classification but must not replace data classification, schema, lineage, quality, or governance records. + +--- + +# 19. Canon Interface Card Usage + +Subsystems that implement or produce data knowledge SHOULD publish a Canon Interface Card. + +Example: + +```yaml +subsystem: data-catalog-importer +implements: + - InfoTechCanonDataModel + - DataCatalogProfile +produces: + - Dataset + - Schema + - Field + - DataDistribution + - DataOwnerReference +consumes: + - Team + - DataStoreReference + - Policy +relations: + - Dataset has_schema Schema + - Schema has_field Field + - Dataset stored_in DataStoreReference + - Dataset owned_by Team +source_of_truth: + dataset_catalog_entries: data-catalog +known_deviations: + - lineage is summary-only + - data quality checks are imported from separate system +``` + +--- + +# 20. Retrieval Requirements + +The Data Model is designed for markdown-based infospaces. + +## 20.1 Required Retrieval Properties + +Every major concept SHOULD provide: + +- stable heading, +- stable identifier, +- short definition, +- longer explanation, +- examples, +- distinction notes, +- relationship examples, +- mapping hooks, +- profile references, +- and common mistakes. + +## 20.2 Agent Brief + +A mature Data Model SHOULD include an `agent-brief.md` file with: + +```text +purpose +scope +owned concepts +imported concepts +core distinctions +do / do not rules +relationship patterns +minimal examples +common mistakes +profile list +mapping list +``` + +## 20.3 Indexes + +The data information space SHOULD provide indexes by: + +```text +concept +relationship +data domain +dataset +schema +field +classification +quality rule +lineage +contract +profile +pattern +mapping target +status +source system +``` + +--- + +# 21. Conformance Levels + +## 21.1 Reference-Conformant + +A document or system is reference-conformant if it uses Data Model terminology consistently but does not implement structured metadata or validation rules. + +## 21.2 Metadata-Conformant + +A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types. + +## 21.3 Catalog-Conformant + +A system is catalog-conformant if datasets, distributions, data services, owners, stewards, descriptions, and classifications are represented. + +## 21.4 Lineage-Conformant + +A system is lineage-conformant if it represents data sources, transformations, targets, provenance, and confidence. + +## 21.5 Quality-Conformant + +A system is quality-conformant if it represents data quality rules, checks, results, and issues. + +## 21.6 Contract-Conformant + +A system is contract-conformant if producer and consumer expectations are represented as DataContracts. + +## 21.7 Profile-Conformant + +A system is profile-conformant if it implements a declared Data Profile and passes its validation rules. + +## 21.8 Assimilation-Conformant + +A system or repository is assimilation-conformant if it can accept external data concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes. + +--- + +# 22. Validation Rules + +Initial validation rules: + +```text +VAL-DATA-001: Dataset SHOULD NOT be modeled as identical to DataStoreReference. + +VAL-DATA-002: Dataset SHOULD have owner or steward reference when used for operational or governed purposes. + +VAL-DATA-003: Dataset SHOULD have classification when it may contain sensitive, regulated, operationally critical, or business-critical data. + +VAL-DATA-004: Schema SHOULD have version when used across system boundaries. + +VAL-DATA-005: Field SHOULD be distinguishable from DataElement where semantic precision matters. + +VAL-DATA-006: DataQualityRule SHOULD declare the dataset, field, or data object it applies to. + +VAL-DATA-007: DataQualityResult SHOULD reference the executed rule and check. + +VAL-DATA-008: DataLineage SHOULD distinguish declared, inferred, observed, and verified lineage. + +VAL-DATA-009: DataContract SHOULD declare producer, consumer, dataset, schema or semantic expectations, quality expectations, and compatibility rules where applicable. + +VAL-DATA-010: BreakingChange SHOULD reference the DataContract or CompatibilityRule it violates. + +VAL-DATA-011: RetentionRuleReference SHOULD point to Governance concepts rather than embedding legal interpretation in Data. + +VAL-DATA-012: DataResidency SHOULD reference region, jurisdiction, environment, or storage/processing scope where available. + +VAL-DATA-013: Tags MUST NOT replace DataClassification, Schema, Lineage, Quality, or Contract records. + +VAL-DATA-014: External data concepts SHOULD be represented through mapping records rather than silently reused. + +VAL-DATA-015: Profiles MUST NOT redefine canonical concepts. They may constrain them. + +VAL-DATA-016: Data used for AI training, analytics, or automation SHOULD declare usage constraints and provenance where relevant. +``` + +--- + +# 23. Anti-Patterns + +## 23.1 Table Equals Dataset + +Treating every table as a complete dataset and every dataset as a table. + +## 23.2 Schema Equals Meaning + +Assuming column names and types fully define business meaning. + +## 23.3 Classification by Tag Only + +Using tags such as `confidential` without a governed DataClassification record. + +## 23.4 Lineage by Diagram Only + +Drawing flows without source, transformation, target, evidence, or confidence. + +## 23.5 Quality Dashboard Graveyard + +Tracking quality failures without owners, tasks, remediation, or fitness-for-use decisions. + +## 23.6 Contract-Free Integration + +Letting consumers depend on producer data without explicit compatibility expectations. + +## 23.7 Hidden Retention Logic + +Deleting or keeping data based on undocumented scripts or tribal knowledge. + +## 23.8 Catalog Without Trust + +Cataloging datasets without owner, freshness, classification, quality, or lineage. + +## 23.9 Privacy in Free Text + +Recording processing purpose, data subject category, residency, or sensitivity as unstructured notes only. + +## 23.10 Vendor Model Capture + +Letting one data catalog, warehouse, or governance product define the internal data model. + +--- + +# 24. Initial Repository Placement + +Recommended repository layout: + +```text +info-tech-canon/ + standards/ + data/ + InfoTechCanonDataModel.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +Seed files: + +```text +standards/data/InfoTechCanonDataModel.md +standards/data/agent-brief.md +standards/data/concepts/dataset.md +standards/data/concepts/data-product.md +standards/data/concepts/schema.md +standards/data/concepts/data-element.md +standards/data/concepts/data-classification.md +standards/data/concepts/data-lineage.md +standards/data/concepts/data-quality-rule.md +standards/data/concepts/data-contract.md +standards/data/patterns/data-is-not-its-store.md +standards/data/patterns/dataset-catalog-entry.md +standards/data/patterns/data-contract-at-boundary.md +standards/data/patterns/lineage-as-evidence.md +standards/data/profiles/small-saas-data-profile.md +standards/data/profiles/data-catalog-profile.md +standards/data/profiles/data-contract-profile.md +standards/data/profiles/data-lineage-profile.md +standards/data/mappings/dcat.yaml +standards/data/mappings/prov-o.yaml +standards/data/mappings/iso-11179.yaml +standards/data/mappings/dama-dmbok.yaml +``` + +--- + +# 25. Roadmap + +## Phase 1: Seed Stabilization + +- Establish this standard as `InfoTechCanonDataModel`. +- Add seed concepts, relationship vocabulary, patterns, and profiles. +- Define validation rules. +- Align with Landscape, Governance, Security, Access Control, Task, and Tagging. + +## Phase 2: First Assimilations + +Recommended first assimilations: + +```text +W3C DCAT 3 +PROV-O +ISO/IEC 11179 +DAMA-DMBOK +OpenLineage +DataHub +OpenMetadata +Great Expectations +dbt metadata +GDPR data category concepts +``` + +## Phase 3: Profile Maturation + +- Mature Small SaaS Data Profile. +- Mature Data Catalog Profile. +- Mature Data Contract Profile. +- Mature Data Lineage Profile. +- Mature Privacy-Relevant Data Profile. +- Mature Analytics Dataset Profile. + +## Phase 4: Tooling Integration + +- Generate concept indexes. +- Generate agent brief. +- Create machine-readable YAML/JSON exports. +- Add validation scripts. +- Integrate data catalog, lineage, data-quality, schema registry, and contract tooling. + +## Phase 5: Data Intelligence Loop + +- Connect datasets to services and repositories. +- Connect classification to access control and security. +- Connect quality issues to tasks. +- Connect lineage to provenance and assurance. +- Connect data contracts to DevSecOps and release workflows. +- Connect privacy and retention to governance obligations. + +--- + +# 26. Summary + +The InfoTechCanon Data Model is the seed standard for representing data as a managed, governed, discoverable, reusable, classifiable, lineage-bearing, and quality-assessable asset. + +Its most important commitments are: + +```text +Separate data from storage. + +Separate dataset, schema, field, data element, data object, and data product. + +Treat classification, lineage, quality, retention, residency, and processing purpose as first-class concerns. + +Use data contracts at producer-consumer boundaries. + +Import governance, access-control, security, task, tagging, organization, and landscape concepts +instead of redefining them. + +Map to DCAT, PROV-O, ISO/IEC 11179, DAMA-DMBOK, OpenLineage, and catalog tools +without surrendering internal semantic autonomy. + +Use profiles to make the model practical for SaaS systems, catalogs, contracts, +lineage, privacy-relevant data, analytics, and AI/agentic workflows. +``` + +This makes the Data Model a core seed for information architecture, data governance, security posture, AI readiness, analytics reliability, and interoperable information-processing systems. diff --git a/seeds/InfoTechCanonDevSecOpsModel_RC1_seed.md b/seeds/InfoTechCanonDevSecOpsModel_RC1_seed.md new file mode 100755 index 0000000..a026b8f --- /dev/null +++ b/seeds/InfoTechCanonDevSecOpsModel_RC1_seed.md @@ -0,0 +1,2407 @@ +# InfoTechCanon DevSecOps Model + +**Short Name:** `ITC-DEVSECOPS` +**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:** Platform engineers, DevSecOps teams, release engineers, security architects, software architects, SREs, compliance reviewers, service owners, repository maintainers, CI/CD administrators, agentic coding tool designers, and standards authors. + +--- + +# 1. Purpose + +The **InfoTechCanon DevSecOps Model** defines a canonical seed model for representing secure software delivery from source change to build, test, scan, package, attest, sign, release, deploy, verify, observe, and improve. + +It exists to connect software delivery, supply-chain security, governance evidence, runtime landscape knowledge, security findings, data contracts, and operational feedback without forcing every organization into one CI/CD tool, branching model, release process, or deployment method. + +This standard provides a canonical vocabulary for: + +- repositories, +- branches, +- commits, +- pull requests, +- reviews, +- build definitions, +- pipelines, +- pipeline stages, +- jobs, +- steps, +- pipeline runs, +- quality gates, +- policy gates, +- tests, +- scans, +- artifacts, +- artifact versions, +- packages, +- container images, +- IaC modules, +- deployment manifests, +- SBOMs, +- provenance, +- attestations, +- signatures, +- releases, +- release candidates, +- deployments, +- deployment records, +- environments, +- promotion, +- rollback, +- verification, +- delivery metrics, +- and DevSecOps evidence. + +--- + +# 2. Position in InfoTechCanon + +The DevSecOps Model is a **domain standard** within InfoTechCanon. + +It depends on the existing seed standards as follows: + +```text +Landscape = services, software systems, runtime resources, environments, deployments. +Organization = teams, actors, owners, approvers, maintainers, operators. +Governance = policies, controls, approvals, exceptions, evidence, assurance. +Task = work items, reviews, remediation, releases, change tasks. +Tagging = classification of repos, work, findings, releases, and artifacts. +Access Control = permissions, grants, sessions, agent access, privileged pipeline actions. +Security = vulnerabilities, findings, supply-chain security, incidents, mitigations. +Data = data contracts, schemas, test data, migration data, lineage, data quality. +DevSecOps = delivery flow, pipeline execution, artifacts, provenance, release, deployment. +``` + +```text +InfoTechCanon +├── InfoTechCanonCore +├── InfoTechCanonLandscapeModel +├── InfoTechCanonOrganizationModel +├── InfoTechCanonGovernanceModel +├── InfoTechCanonTaskModel +├── InfoTechCanonTaggingStandard +├── InfoTechCanonAccessControlModel +├── InfoTechCanonSecurityModel +├── InfoTechCanonDataModel +├── InfoTechCanonDevSecOpsModel <-- this standard +├── InfoTechCanonNetworkModel +├── InfoTechCanonObservabilityModel +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +--- + +# 3. Boundary with Adjacent Standards + +## 3.1 Boundary with Landscape + +The Landscape Model owns: + +```text +ApplicationService +SoftwareSystem +RuntimeResource +Environment +RuntimeWorkload +NetworkEndpoint +DeploymentRecord as landscape/runtime history reference +``` + +The DevSecOps Model owns: + +```text +Repository +Commit +PullRequest +Pipeline +PipelineRun +Build +TestRun +ScanRun +Artifact +ArtifactVersion +SBOM +Provenance +Attestation +Signature +Release +DeploymentPlan +DeploymentExecution +Promotion +Rollback +DeploymentVerification +``` + +Boundary rule: + +```text +DevSecOps owns how changes become artifacts and deployments. +Landscape owns the runtime system and service context in which deployments exist. +``` + +## 3.2 Boundary with Security + +The Security Model owns: + +```text +Threat +Vulnerability +SecurityFinding +SupplyChainFinding +Exposure +Mitigation +SecurityIncident +AttackPath +SecurityPosture +``` + +The DevSecOps Model owns the delivery activities and evidence that produce or remediate security-relevant conditions. + +Examples: + +```text +ScanRun generates SecurityFinding +SBOM evidences ArtifactComposition +Attestation supports SupplyChainAssurance +PolicyGate blocks PipelineRun due to SecurityFinding +``` + +## 3.3 Boundary with Governance + +The Governance Model owns: + +```text +Policy +Rule +ControlObjective +Control +Decision +Approval +Exception +Evidence +Assurance +Review +RiskAcceptance +``` + +The DevSecOps Model references governance when delivery activity is governed. + +Examples: + +```text +PolicyGate implements Control +ReleaseApproval approves Release +Exception waives PolicyGate +PipelineEvidence supports ControlResult +``` + +## 3.4 Boundary with Task + +The Task Model owns: + +```text +WorkItem +Task +ReviewTask +ApprovalTask +RemediationTask +ChangeTask +Action +Outcome +``` + +DevSecOps may generate, consume, or close work items. + +Examples: + +```text +PullRequest implements Task +ScanFinding creates RemediationTask +Release requires ApprovalTask +DeploymentFailure creates IncidentTask +``` + +## 3.5 Boundary with Data + +The Data Model owns: + +```text +Schema +DataContract +DataQualityRule +DataLineage +Dataset +TestData +MigrationData semantics +``` + +DevSecOps owns data-related delivery activities. + +Examples: + +```text +MigrationRun applies DatabaseMigration +ContractTest validates DataContract +SchemaCheck validates SchemaEvolutionPolicy +``` + +## 3.6 Boundary with Access Control + +Access Control owns pipeline permissions, service-account access, agent access, privilege, grants, and authorization decisions. + +DevSecOps references those when delivery requires access. + +Examples: + +```text +PipelineIdentity has_permission deploy Environment +AgentAccess permits CodeModificationAction +BreakGlassAccess authorizes EmergencyDeployment +``` + +--- + +# 4. Research Basis and External Alignment + +This seed standard draws on multiple DevSecOps and software supply-chain bodies of knowledge. + +## 4.1 DevOps and DORA Metrics + +DORA software delivery performance metrics provide a widely used measurement vocabulary around deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time. These are valuable delivery-performance mapping targets. + +## 4.2 SLSA + +SLSA defines levels and tracks for software supply-chain security, including provenance and build trust. SLSA provenance describes what built an artifact, what process was used, and what inputs were used. + +## 4.3 in-toto Attestations + +in-toto provides a framework for software supply-chain integrity and an attestation framework for verifiable claims about how software was produced. + +## 4.4 SBOM Standards: SPDX and CycloneDX + +SPDX is an ISO-recognized open standard for communicating software bill of materials and related provenance, license, security, and system metadata. + +CycloneDX is an OWASP full-stack Bill of Materials standard with supply-chain capabilities for cyber risk reduction, including SBOM and other BOM types. + +## 4.5 Sigstore and Artifact Signing + +Sigstore and Cosign provide practical signing and verification mechanisms, including keyless signing and transparency-log-backed verification for artifacts such as container images. + +## 4.6 OpenSSF Scorecard and Supply-Chain Health + +OpenSSF Scorecard assesses open-source projects through automated checks covering source code, builds, dependencies, tests, maintenance, and related supply-chain risk indicators. + +## 4.7 GitHub Actions, GitLab CI, Jenkins, Tekton, Argo CD, Flux + +Practical CI/CD and GitOps tooling provides mapping targets for pipelines, workflows, jobs, runners, artifacts, environments, deployments, approvals, releases, and GitOps reconciliation. + +## 4.8 Feature Flagging and Progressive Delivery + +OpenFeature provides a vendor-agnostic feature flagging API standard. Feature flags and progressive delivery should be represented as delivery mechanisms that may decouple deployment from release. + +--- + +# 5. Seed Standard Design Stance + +This standard is a **seed standard**, not a CI/CD implementation manual. + +It shall: + +1. define canonical delivery and supply-chain semantics, +2. distinguish source change, build, artifact, release, deployment, and runtime state, +3. support secure delivery evidence, +4. support provenance, attestations, signatures, and SBOMs, +5. support pipeline policy gates and quality gates, +6. support manual, automated, GitOps, and progressive delivery models, +7. support human and agentic code/change workflows, +8. map to external tools and standards without becoming subordinate to them, +9. remain markdown-first and agent-retrievable, +10. and support future assimilation of CI/CD systems, supply-chain standards, and platform practices. + +--- + +# 6. Scope + +## 6.1 In Scope + +This standard covers canonical representation of: + +- repositories, +- source branches, +- commits, +- tags, +- pull requests, +- code reviews, +- merge events, +- build definitions, +- workflows, +- pipelines, +- pipeline stages, +- jobs, +- steps, +- runners, +- pipeline identities, +- pipeline runs, +- build runs, +- test runs, +- scan runs, +- quality gates, +- policy gates, +- artifacts, +- artifact versions, +- packages, +- container images, +- deployment manifests, +- infrastructure-as-code modules, +- SBOMs, +- provenance, +- attestations, +- signatures, +- release candidates, +- releases, +- release notes, +- deployment plans, +- deployment executions, +- deployment records, +- environment promotion, +- rollout strategies, +- rollback, +- deployment verification, +- delivery metrics, +- and DevSecOps evidence. + +## 6.2 Out of Scope + +This standard does not fully define: + +- source code semantics, +- all software architecture concepts, +- all task and issue management, +- all security vulnerability semantics, +- all governance control theory, +- all runtime landscape modeling, +- all access-control semantics, +- all observability telemetry models, +- all package-manager schemas, +- every CI/CD vendor schema, +- or every software-development methodology. + +Those may be mapped, assimilated, profiled, or handled by adjacent standards. + +--- + +# 7. 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 defined provisionally here but open to later refinement. +- **EXTRACT** marks a concept that may later move to a more specialized standard. + +--- + +# 8. Core Principles + +## 8.1 Source Is Not Artifact + +A repository or commit is not the same thing as a built artifact. + +## 8.2 Artifact Is Not Deployment + +An artifact version may exist without being deployed. + +A deployment is an event or execution that makes an artifact active or available in an environment. + +## 8.3 Deployment Is Not Release + +Deployment places a change into an environment. + +Release makes a capability available or active for consumers. + +Feature flags and progressive delivery may separate deployment from release. + +## 8.4 Pipeline Definition Is Not Pipeline Run + +A pipeline definition describes intended automation. + +A pipeline run is a concrete execution with inputs, outputs, logs, evidence, and result. + +## 8.5 Evidence Is First-Class + +Delivery claims SHOULD be supported by evidence such as logs, test results, scan results, SBOMs, provenance, signatures, approvals, and deployment records. + +## 8.6 Provenance and Attestation Are Distinct + +Provenance describes origin and build process. + +Attestation is a verifiable claim about an artifact, process, result, or control. + +## 8.7 Secure Delivery Requires Identity + +Pipeline identities, runners, agents, and deployers SHOULD be represented where they affect trust, authorization, and evidence. + +## 8.8 Policy Gates Are Governance in Delivery + +Policy gates implement governance rules in delivery workflows but do not own policy semantics. + +## 8.9 External Tools Are Mapped, Not Obeyed + +The DevSecOps Model MAY map to GitHub Actions, GitLab CI, Jenkins, Tekton, Argo CD, Flux, SLSA, in-toto, SPDX, CycloneDX, Sigstore, OpenSSF Scorecard, and similar systems. + +It MUST NOT subordinate its internal semantics to any single tool or standard. + +--- + +# 9. Canonical Seed Metadata + +Every DevSecOps artifact SHOULD support structured metadata. + +Recommended front matter: + +```yaml +--- +id: itc-devsecops:PipelineRun +type: concept +standard: InfoTechCanonDevSecOpsModel +standard_version: RC1-seed +status: candidate +canonical_owner: InfoTechCanonDevSecOpsModel +preferred_label: Pipeline Run +related: + - itc-devsecops:Pipeline + - itc-devsecops:ArtifactVersion + - itc-devsecops:Attestation + - itc-gov:Evidence +mappings: + - itc-map:pipeline-run-to-github-actions-workflow-run +--- +``` + +Recommended artifact statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +Recommended concept statuses: + +```text +proposed +experimental +candidate +canonical +deprecated +retired +``` + +--- + +# 10. Root DevSecOps Taxonomy + +```text +DevSecOpsEntity +├── SourceEntity +│ ├── Repository +│ ├── Branch +│ ├── Commit +│ ├── SourceTag +│ ├── PullRequest +│ ├── MergeEvent +│ ├── CodeReview +│ └── SourceChange +├── PipelineEntity +│ ├── Pipeline +│ ├── PipelineDefinition +│ ├── PipelineStage +│ ├── PipelineJob +│ ├── PipelineStep +│ ├── PipelineRun +│ ├── Runner +│ ├── PipelineIdentity +│ └── PipelineResult +├── VerificationEntity +│ ├── TestRun +│ ├── TestResult +│ ├── ScanRun +│ ├── ScanResult +│ ├── QualityGate +│ ├── PolicyGate +│ ├── GateDecision +│ └── VerificationEvidence +├── ArtifactEntity +│ ├── Artifact +│ ├── ArtifactVersion +│ ├── Package +│ ├── ContainerImage +│ ├── DeploymentManifest +│ ├── IaCModule +│ ├── BuildOutput +│ └── ArtifactDigest +├── SupplyChainEvidenceEntity +│ ├── SBOM +│ ├── Provenance +│ ├── Attestation +│ ├── Signature +│ ├── TransparencyLogEntry +│ ├── VEXReference +│ └── SupplyChainEvidence +├── ReleaseEntity +│ ├── ReleaseCandidate +│ ├── Release +│ ├── ReleaseVersion +│ ├── ReleaseNote +│ ├── ReleaseApprovalReference +│ └── ReleaseStatus +├── DeploymentEntity +│ ├── DeploymentPlan +│ ├── DeploymentExecution +│ ├── DeploymentRecord +│ ├── Promotion +│ ├── RolloutStrategy +│ ├── Rollback +│ ├── DeploymentVerification +│ └── EnvironmentPromotion +├── RuntimeFeedbackEntity +│ ├── DeploymentHealthSignal +│ ├── ChangeFailure +│ ├── RecoveryAction +│ ├── DeliveryMetric +│ └── FeedbackLoop +└── AgenticDeliveryEntity + ├── CodingAgentChange + ├── AgentGeneratedPatch + ├── AgentReview + ├── AgentExecutionEvidence + └── HumanSupervisionReference +``` + +--- + +# 11. Core Concepts + +## 11.1 DevSecOpsEntity + +A **DevSecOpsEntity** is any identifiable concept used to represent secure software delivery, automation, artifacts, release, deployment, provenance, verification, or delivery feedback. + +Recommended attributes: + +```yaml +id: +entity_type: +canonical_name: +display_name: +lifecycle_state: +source_system: +created_at: +updated_at: +``` + +Optional attributes: + +```yaml +owner: +steward: +repository: +environment: +source_confidence: +valid_from: +valid_to: +tags: +external_references: +``` + +--- + +## 11.2 Repository + +A **Repository** is a version-controlled source location containing source code, configuration, documentation, pipeline definitions, infrastructure definitions, or other delivery-relevant material. + +Repository ownership and relationship to software systems may be represented through Landscape and Organization concepts. + +--- + +## 11.3 Branch + +A **Branch** is a named line of development in a repository. + +Branching models are profile-specific. + +--- + +## 11.4 Commit + +A **Commit** is an immutable source-control change record. + +Recommended attributes: + +```yaml +commit_hash: +author: +committer: +timestamp: +repository: +parent_commits: +signature_reference: +``` + +--- + +## 11.5 SourceTag + +A **SourceTag** is a source-control reference marking a commit or version. + +This is distinct from InfoTechCanon tags. + +--- + +## 11.6 PullRequest + +A **PullRequest** is a proposed change to a repository requiring review, discussion, checks, merge, or rejection. + +Equivalent tool terms may include merge request or change request. + +--- + +## 11.7 CodeReview + +A **CodeReview** is a review of a source change, patch, pull request, or generated code. + +Governance owns review semantics where formal decision rights are involved. DevSecOps owns the delivery artifact. + +--- + +## 11.8 SourceChange + +A **SourceChange** is a change to source-controlled material. + +A source change may be represented by one or more commits and may implement a Task. + +--- + +## 11.9 Pipeline + +A **Pipeline** is a delivery workflow that automates or coordinates build, test, scan, package, release, deployment, verification, or related activities. + +--- + +## 11.10 PipelineDefinition + +A **PipelineDefinition** is the declared configuration of a pipeline. + +Examples: + +```text +GitHub Actions workflow file +GitLab CI YAML +Jenkinsfile +Tekton Pipeline +Argo Workflow +``` + +--- + +## 11.11 PipelineStage + +A **PipelineStage** is a logical phase in a pipeline. + +Examples: + +```text +build +test +scan +package +sign +publish +deploy +verify +promote +``` + +--- + +## 11.12 PipelineJob + +A **PipelineJob** is an executable unit within a pipeline stage. + +--- + +## 11.13 PipelineStep + +A **PipelineStep** is a smaller executable unit within a job. + +--- + +## 11.14 PipelineRun + +A **PipelineRun** is a concrete execution of a pipeline definition. + +Recommended attributes: + +```yaml +pipeline: +trigger: +source_revision: +started_at: +finished_at: +status: +runner: +inputs: +outputs: +logs: +evidence: +``` + +Canonical rule: + +```text +PipelineRun SHOULD be separated from PipelineDefinition. +``` + +--- + +## 11.15 Runner + +A **Runner** is the execution environment or agent that performs pipeline jobs or steps. + +Runners may be hosted, self-hosted, ephemeral, privileged, or isolated. + +--- + +## 11.16 PipelineIdentity + +A **PipelineIdentity** is the access-control subject used by a pipeline, job, runner, or deployment activity. + +This concept references Access Control and should be represented where trust or authorization matters. + +--- + +## 11.17 PipelineResult + +A **PipelineResult** is the outcome of a pipeline run, stage, job, or step. + +Seed result values: + +```text +success +failure +cancelled +skipped +blocked +timed_out +unstable +partial +``` + +--- + +## 11.18 TestRun + +A **TestRun** is an execution of tests. + +Test types: + +```text +unit +integration +contract +system +acceptance +performance +security +regression +smoke +chaos +``` + +--- + +## 11.19 TestResult + +A **TestResult** is the result of a TestRun. + +--- + +## 11.20 ScanRun + +A **ScanRun** is an execution of analysis or scanning. + +Scan types: + +```text +SAST +DAST +SCA +container scan +IaC scan +secret scan +license scan +SBOM scan +policy scan +malware scan +configuration scan +``` + +--- + +## 11.21 ScanResult + +A **ScanResult** is the output of a ScanRun. + +Scan results may generate Security Findings, Governance Findings, or Quality Findings. + +--- + +## 11.22 QualityGate + +A **QualityGate** is a delivery gate based on quality criteria. + +Examples: + +```text +tests pass +coverage threshold met +linting passes +performance threshold met +contract tests pass +``` + +--- + +## 11.23 PolicyGate + +A **PolicyGate** is a delivery gate based on governance, security, compliance, or release policy. + +Examples: + +```text +no critical vulnerabilities +artifact signed +SBOM present +release approved +change ticket linked +production deployment window valid +``` + +--- + +## 11.24 GateDecision + +A **GateDecision** is the result of evaluating a gate. + +Seed values: + +```text +pass +fail +waived +manual_review_required +not_applicable +indeterminate +``` + +--- + +## 11.25 VerificationEvidence + +**VerificationEvidence** is evidence produced by test, scan, review, gate, or deployment verification activities. + +--- + +## 11.26 Artifact + +An **Artifact** is a delivery output that may be versioned, stored, signed, scanned, released, or deployed. + +Examples: + +```text +package +container image +binary +library +chart +deployment manifest +IaC module +documentation bundle +model artifact +``` + +--- + +## 11.27 ArtifactVersion + +An **ArtifactVersion** is a specific version or immutable instance of an artifact. + +Recommended attributes: + +```yaml +artifact: +version: +digest: +repository: +build_reference: +created_at: +signature_reference: +sbom_reference: +provenance_reference: +``` + +--- + +## 11.28 Package + +A **Package** is a distributable artifact in a package ecosystem. + +Examples: + +```text +npm package +Maven artifact +PyPI package +Debian package +OCI artifact +``` + +--- + +## 11.29 ContainerImage + +A **ContainerImage** is a container artifact identified by tag and/or digest. + +Canonical rule: + +```text +Digest SHOULD be used for immutable identity. +``` + +--- + +## 11.30 DeploymentManifest + +A **DeploymentManifest** is a declared configuration artifact describing how a system should be deployed. + +Examples: + +```text +Kubernetes manifest +Helm chart values +Kustomize overlay +Terraform plan +Ansible playbook +CloudFormation template +``` + +--- + +## 11.31 IaCModule + +An **IaCModule** is an infrastructure-as-code module or artifact. + +--- + +## 11.32 ArtifactDigest + +An **ArtifactDigest** is a cryptographic hash or content-addressable identifier for an artifact. + +--- + +## 11.33 SBOM + +A **Software Bill of Materials** is a structured inventory of software components and related metadata for an artifact, product, or system. + +SBOM concepts may map to SPDX or CycloneDX. + +--- + +## 11.34 Provenance + +**Provenance** describes how an artifact was produced, including builder, build process, inputs, and relevant parameters. + +--- + +## 11.35 Attestation + +An **Attestation** is a verifiable claim about an artifact, process, result, control, or supply-chain event. + +Examples: + +```text +build provenance attestation +test result attestation +scan result attestation +SBOM attestation +deployment attestation +policy compliance attestation +``` + +--- + +## 11.36 Signature + +A **Signature** is cryptographic evidence binding identity or key material to an artifact, attestation, or document. + +--- + +## 11.37 TransparencyLogEntry + +A **TransparencyLogEntry** is a log entry in an append-only or transparency system used to support verification of signatures, attestations, or supply-chain events. + +--- + +## 11.38 VEXReference + +A **VEXReference** is a reference to Vulnerability Exploitability eXchange information describing whether known vulnerabilities affect a product or component in context. + +--- + +## 11.39 SupplyChainEvidence + +**SupplyChainEvidence** is evidence supporting trust, integrity, authenticity, composition, provenance, or policy compliance in the software supply chain. + +--- + +## 11.40 ReleaseCandidate + +A **ReleaseCandidate** is an artifact set, version, or change set proposed for release. + +--- + +## 11.41 Release + +A **Release** is a versioned set of capabilities, artifacts, or changes made available for deployment or consumption. + +Canonical rule: + +```text +Release SHOULD be distinguished from Deployment. +``` + +--- + +## 11.42 ReleaseVersion + +A **ReleaseVersion** is the version identifier associated with a release. + +--- + +## 11.43 ReleaseNote + +A **ReleaseNote** documents relevant changes, risks, fixes, known issues, migrations, or operational notes for a release. + +--- + +## 11.44 ReleaseApprovalReference + +A **ReleaseApprovalReference** points to governance approval, review, or decision records. + +--- + +## 11.45 DeploymentPlan + +A **DeploymentPlan** describes intended deployment steps, targets, strategy, dependencies, risk controls, and rollback expectations. + +--- + +## 11.46 DeploymentExecution + +A **DeploymentExecution** is a concrete execution of a deployment plan or deployment action. + +--- + +## 11.47 DeploymentRecord + +A **DeploymentRecord** is historical evidence that a deployment occurred. + +Recommended attributes: + +```yaml +artifact_version: +target_environment: +started_at: +finished_at: +actor_or_pipeline: +status: +strategy: +rollback_reference: +verification_reference: +``` + +--- + +## 11.48 Promotion + +**Promotion** is movement of an artifact, release candidate, configuration, or deployment from one environment or maturity level to another. + +Examples: + +```text +dev -> test +test -> staging +staging -> production +candidate -> approved release +``` + +--- + +## 11.49 RolloutStrategy + +A **RolloutStrategy** defines how a deployment or release is introduced. + +Examples: + +```text +all-at-once +rolling +blue-green +canary +feature-flagged +progressive +dark launch +shadow +``` + +--- + +## 11.50 Rollback + +A **Rollback** is a deployment or release action intended to return to a previous known-good state or disable a faulty change. + +--- + +## 11.51 DeploymentVerification + +**DeploymentVerification** is confirmation that a deployment achieved expected technical and operational conditions. + +Examples: + +```text +smoke test +health check +SLO check +error-rate check +canary analysis +synthetic transaction +operator verification +``` + +--- + +## 11.52 EnvironmentPromotion + +**EnvironmentPromotion** is a promotion between environments or environment-like lifecycle stages. + +--- + +## 11.53 DeploymentHealthSignal + +A **DeploymentHealthSignal** is an observability or verification signal used to assess deployment health. + +--- + +## 11.54 ChangeFailure + +A **ChangeFailure** is a failure caused by a change or deployment that requires remediation, rollback, hotfix, incident response, or recovery. + +--- + +## 11.55 RecoveryAction + +A **RecoveryAction** is action taken to restore service or safe operation after a failed change or deployment. + +--- + +## 11.56 DeliveryMetric + +A **DeliveryMetric** is a metric used to assess delivery performance, quality, reliability, security, or flow. + +Examples: + +```text +deployment frequency +change lead time +change failure rate +failed deployment recovery time +pipeline duration +queue time +test pass rate +scan finding rate +mean time to remediate +``` + +--- + +## 11.57 FeedbackLoop + +A **FeedbackLoop** connects runtime results, observability, incidents, findings, user feedback, or delivery metrics back to work, governance, security, or delivery improvements. + +--- + +## 11.58 CodingAgentChange + +A **CodingAgentChange** is a source change generated or substantially modified by an AI or software agent. + +--- + +## 11.59 AgentGeneratedPatch + +An **AgentGeneratedPatch** is a patch proposed or produced by an agent. + +--- + +## 11.60 AgentReview + +An **AgentReview** is a review performed by or on behalf of an agent. + +--- + +## 11.61 AgentExecutionEvidence + +**AgentExecutionEvidence** is evidence of agent activity, tool use, prompts, commands, generated patches, tests, or review results. + +--- + +## 11.62 HumanSupervisionReference + +A **HumanSupervisionReference** points to the human actor, review, approval, or policy governing agentic delivery work. + +--- + +# 12. Core Relationship Vocabulary + +Recommended root relationship types: + +```text +contains +part_of +derived_from +built_from +triggered_by +executes +produces +consumes +uses +tests +scans +generates +blocks +passes +fails +waives +attests +signs +verifies +publishes +releases +deploys +promotes +rolls_back +verifies_deployment +evidenced_by +implements +fixes +remediates +affects +maps_to +``` + +Relationship records SHOULD support: + +```yaml +id: +relationship_type: +source_entity: +target_entity: +scope: +valid_from: +valid_to: +source_system: +confidence: +evidence: +rationale: +``` + +--- + +# 13. DevSecOps State Models + +## 13.1 Pull Request States + +```text +draft +open +review_required +changes_requested +approved +merged +closed +rejected +superseded +``` + +## 13.2 Pipeline Run States + +```text +queued +running +success +failed +cancelled +skipped +blocked +timed_out +unstable +partial +``` + +## 13.3 Artifact States + +```text +created +scanned +signed +attested +published +deprecated +revoked +deleted +``` + +## 13.4 Release States + +```text +planned +candidate +under_review +approved +released +deprecated +withdrawn +superseded +``` + +## 13.5 Deployment States + +```text +planned +approved +queued +running +succeeded +failed +partially_succeeded +rolled_back +verified +degraded +superseded +``` + +## 13.6 Gate States + +```text +not_evaluated +passed +failed +waived +manual_review_required +indeterminate +``` + +--- + +# 14. DevSecOps Patterns + +## 14.1 Pattern: Commit-to-Runtime Trace + +**Context:** A team needs to know what source produced a running workload. + +**Problem:** Runtime systems often cannot reliably answer which commit, build, artifact, scan, approval, and deployment produced a workload. + +**Solution:** + +```text +Commit + -> PipelineRun + -> ArtifactVersion + -> SBOM / Provenance / Attestation / Signature + -> Release + -> DeploymentRecord + -> RuntimeWorkload +``` + +--- + +## 14.2 Pattern: Build Once, Promote + +**Context:** Artifacts move through multiple environments. + +**Problem:** Rebuilding per environment weakens provenance and introduces drift. + +**Solution:** Build an immutable artifact once, then promote the same artifact through environments with environment-specific configuration and evidence. + +--- + +## 14.3 Pattern: Policy Gate with Exception + +**Context:** Delivery must enforce governance and security requirements. + +**Problem:** Hard gates block urgent change; soft gates become meaningless. + +**Solution:** Use PolicyGate with explicit Governance Exception, scope, approver, evidence, expiry, and compensating control. + +--- + +## 14.4 Pattern: Provenance-Carrying Artifact + +**Context:** Consumers need to trust artifacts. + +**Problem:** Artifacts without provenance cannot explain source, builder, inputs, or process. + +**Solution:** Attach provenance and attestations to artifact versions and verify them before promotion or deployment. + +--- + +## 14.5 Pattern: SBOM-to-Finding-to-Remediation + +**Context:** Dependency vulnerabilities are discovered. + +**Problem:** Teams cannot connect dependency findings to runtime services and remediation work. + +**Solution:** + +```text +SBOM + -> Component + -> VulnerabilityFinding + -> Affected ArtifactVersion + -> DeploymentRecord / RuntimeWorkload + -> RemediationTask + -> VerificationEvidence +``` + +--- + +## 14.6 Pattern: Deployment Is Not Release + +**Context:** Feature flags and progressive delivery are used. + +**Problem:** Teams confuse deployed code with released capability. + +**Solution:** Model Deployment and Release separately and connect feature flag activation or exposure as release-related events. + +--- + +## 14.7 Pattern: Delivery Feedback Loop + +**Context:** Delivery performance and runtime reliability affect each other. + +**Problem:** CI/CD metrics are disconnected from incidents and SLOs. + +**Solution:** Connect deployment records to observability signals, incidents, change failures, recovery actions, and delivery metrics. + +--- + +## 14.8 Pattern: Agentic Change with Supervision + +**Context:** Coding agents generate changes. + +**Problem:** Agent output may lack accountability, authority, or evidence. + +**Solution:** Model agent-generated patches with supervising actor, prompt/context evidence, tool-use evidence, tests, review, and human approval where required. + +--- + +## 14.9 Pattern: Deployment Verification Before Closure + +**Context:** Pipelines report deployment success. + +**Problem:** Deployment success may only mean "command completed", not "service healthy". + +**Solution:** Require DeploymentVerification based on runtime health, SLOs, smoke tests, canary analysis, or operator confirmation. + +--- + +# 15. DevSecOps Profiles + +## 15.1 Profile Format + +A DevSecOps Profile SHALL declare: + +```yaml +id: +profile_name: +status: +implements: + - InfoTechCanonDevSecOpsModel +target_context: +included_concepts: +required_relationships: +required_metadata: +state_model: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +--- + +## 15.2 Seed Profile: Small SaaS DevSecOps Profile + +Purpose: + +```text +Provide a minimal delivery model for a small SaaS platform moving toward production readiness. +``` + +Included concepts: + +```text +Repository +Branch +Commit +PullRequest +CodeReview +Pipeline +PipelineRun +TestRun +ScanRun +ArtifactVersion +ContainerImage +SBOM +Provenance +Signature +Release +DeploymentRecord +DeploymentVerification +DeliveryMetric +``` + +Required relationships: + +```text +PullRequest contains Commit +PipelineRun triggered_by Commit +PipelineRun produces ArtifactVersion +ArtifactVersion described_by SBOM +ArtifactVersion attested_by Provenance +ArtifactVersion signed_by Signature +DeploymentRecord deploys ArtifactVersion +DeploymentVerification verifies DeploymentRecord +DeliveryMetric measures DeliveryFlow +``` + +--- + +## 15.3 Seed Profile: GitHub Actions Delivery Profile + +Purpose: + +```text +Map GitHub Actions and GitHub repository events into DevSecOps concepts. +``` + +Example mappings: + +```text +Repository -> Repository +Branch -> Branch +Commit -> Commit +Pull Request -> PullRequest +Workflow -> PipelineDefinition +Workflow Run -> PipelineRun +Job -> PipelineJob +Step -> PipelineStep +Runner -> Runner +Artifact -> BuildOutput / Artifact +Environment -> DeploymentTarget / EnvironmentReference +Deployment -> DeploymentRecord +Check Run -> GateDecision / TestResult / ScanResult +Release -> Release +``` + +Known deviations: + +```text +GitHub workflow artifacts are not always deployable artifacts. +GitHub labels belong to Tagging. +GitHub environments can combine deployment target, protection rules, and approval semantics. +``` + +--- + +## 15.4 Seed Profile: GitLab CI Delivery Profile + +Purpose: + +```text +Map GitLab CI/CD concepts into DevSecOps concepts. +``` + +Example mappings: + +```text +Project -> Repository / ProjectReference +Pipeline -> PipelineRun +.gitlab-ci.yml -> PipelineDefinition +Stage -> PipelineStage +Job -> PipelineJob +Runner -> Runner +Artifact -> BuildOutput / Artifact +Environment -> EnvironmentReference +Release -> Release +Deployment -> DeploymentRecord +``` + +--- + +## 15.5 Seed Profile: Kubernetes GitOps Delivery Profile + +Purpose: + +```text +Represent GitOps delivery to Kubernetes using tools such as Argo CD or Flux. +``` + +Included concepts: + +```text +Repository +DeploymentManifest +GitOpsApplication +ReconciliationRun +ArtifactVersion +Environment +KubernetesClusterReference +DeploymentRecord +DriftDetection +SyncStatus +Rollback +``` + +Example mappings: + +```text +Git commit -> Declared desired state +Argo CD Application / Flux Kustomization -> GitOpsApplication +Sync operation -> DeploymentExecution +Kubernetes workload state -> Landscape observed state +Drift -> DeploymentFinding / Landscape drift finding +``` + +--- + +## 15.6 Seed Profile: SLSA / Provenance Profile + +Purpose: + +```text +Represent build provenance and supply-chain trust levels. +``` + +Included concepts: + +```text +ArtifactVersion +BuildDefinition +Builder +PipelineRun +Provenance +Attestation +BuildInput +BuildOutput +Signature +TrustLevelReference +``` + +Mapping targets: + +```text +SLSA +in-toto attestations +Sigstore +SPDX Build Profile +``` + +--- + +## 15.7 Seed Profile: SBOM Profile + +Purpose: + +```text +Represent artifact composition and bill-of-materials evidence. +``` + +Included concepts: + +```text +ArtifactVersion +SBOM +Component +Dependency +Package +LicenseReference +VulnerabilityReference +VEXReference +``` + +Mapping targets: + +```text +SPDX +CycloneDX +OSV +GitHub Security Advisories +``` + +--- + +## 15.8 Seed Profile: Agentic Delivery Profile + +Purpose: + +```text +Support software changes generated, reviewed, tested, or deployed with AI/software agents. +``` + +Included concepts: + +```text +CodingAgentChange +AgentGeneratedPatch +AgentExecutionEvidence +AgentReview +HumanSupervisionReference +ToolUseEvidence +PromptContextReference +TestRun +CodeReview +PolicyGate +``` + +Required relationships: + +```text +AgentGeneratedPatch derived_from PromptContextReference +AgentGeneratedPatch implements Task +AgentExecutionEvidence evidences CodingAgentChange +HumanSupervisionReference governs AgenticChange +CodeReview reviews AgentGeneratedPatch +PolicyGate gates AgenticChange +``` + +--- + +# 16. Mapping Model for the DevSecOps Standard + +Mappings relate InfoTechCanon DevSecOps concepts to external standards, tools, and products. + +## 16.1 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +regulatoryReference +toolEquivalent +``` + +## 16.2 Mapping Record + +Example: + +```yaml +id: itc-map:provenance-to-slsa-provenance +source_concept: itc-devsecops:Provenance +target_body: SLSA +target_version: "1.2" +target_concept: Provenance +mapping_type: closeMatch +scope: + - artifact build provenance +not_valid_for: + - all lineage or runtime provenance +rationale: > + SLSA provenance describes how an artifact was built, including builder, + process, and inputs. InfoTechCanon Provenance is generalized but uses SLSA + provenance as a strong software-supply-chain mapping target. +confidence: high +status: candidate +owner: InfoTechCanonDevSecOpsModel +``` + +## 16.3 Seed Mapping Targets + +The DevSecOps Model SHOULD maintain mappings to: + +```text +SLSA +in-toto +SPDX +CycloneDX +Sigstore / Cosign +OpenSSF Scorecard +DORA metrics +GitHub Actions +GitLab CI +Jenkins +Tekton +Argo CD +Flux +Helm +Kustomize +Terraform +OpenFeature +OCI artifacts +Docker / container registries +Maven / npm / PyPI package ecosystems +SonarQube / CodeQL / SAST tools +DAST / SCA / IaC scanner schemas +``` + +--- + +# 17. Assimilation Hooks + +The DevSecOps Model SHALL be able to receive new delivery, CI/CD, supply-chain, and platform standards through the InfoTechCanon assimilation process. + +## 17.1 Assimilation Triggers + +Assimilation may be triggered by: + +```text +new CI/CD platform +new supply-chain standard +new artifact signing system +new SBOM format +new release management practice +new deployment method +new GitOps platform +new coding-agent workflow +new policy-gate requirement +new delivery-metric model +``` + +## 17.2 DevSecOps Assimilation Output + +A DevSecOps assimilation SHOULD produce: + +```text +source summary +extracted DevSecOps concepts +concept comparison matrix +gap list +conflict list +mapping file +candidate new concepts +candidate relationship changes +candidate pattern changes +candidate profile changes +open questions +``` + +## 17.3 Recommended First Assimilation Candidates + +```text +SLSA 1.2 +in-toto Attestation Framework +SPDX 3.x +CycloneDX +GitHub Actions +GitLab CI +Argo CD +Flux +OpenSSF Scorecard +DORA metrics +Sigstore / Cosign +OpenFeature +``` + +--- + +# 18. Integration with Other InfoTechCanon Standards + +## 18.1 Landscape Model + +DevSecOps connects to Landscape through: + +```text +ApplicationService +SoftwareSystem +Repository +Artifact +Environment +RuntimeResource +DeploymentRecord +RuntimeWorkload +Endpoint +``` + +## 18.2 Organization Model + +DevSecOps imports organization concepts for: + +```text +maintainer +reviewer +approver +release manager +operator +service owner +platform team +agent supervisor +``` + +## 18.3 Governance Model + +DevSecOps imports governance concepts for: + +```text +policy gate +release approval +change decision +control objective +exception +evidence +assurance +risk acceptance +``` + +## 18.4 Task Model + +DevSecOps imports task concepts for: + +```text +work item +pull request task +review task +remediation task +change task +release task +incident task +``` + +## 18.5 Security Model + +DevSecOps imports security concepts for: + +```text +security finding +vulnerability finding +supply-chain finding +mitigation +security review +security evidence +``` + +## 18.6 Access Control Model + +DevSecOps imports access concepts for: + +```text +pipeline identity +runner identity +deploy permission +release approval access +agent access +break-glass deployment access +``` + +## 18.7 Data Model + +DevSecOps imports data concepts for: + +```text +data contract +schema +schema evolution +test data +migration data +data quality rule +lineage evidence +``` + +## 18.8 Observability Model + +DevSecOps should later integrate with Observability for: + +```text +deployment health signal +change failure +recovery time +SLO impact +runtime verification +``` + +--- + +# 19. Canon Interface Card Usage + +Subsystems that implement or produce DevSecOps knowledge SHOULD publish a Canon Interface Card. + +Example: + +```yaml +subsystem: github-actions-importer +implements: + - InfoTechCanonDevSecOpsModel + - GitHubActionsDeliveryProfile +produces: + - PipelineRun + - PipelineJob + - PipelineStep + - TestResult + - BuildOutput + - DeploymentRecord +consumes: + - Repository + - Commit + - PullRequest + - Environment +relations: + - PipelineRun triggered_by Commit + - PipelineRun produces BuildOutput + - DeploymentRecord deploys ArtifactVersion +source_of_truth: + workflow_run_state: GitHub Actions +known_deviations: + - workflow artifacts may not be canonical artifacts + - environment approval semantics require Governance mapping +``` + +--- + +# 20. Retrieval Requirements + +The DevSecOps Model is designed for markdown-based infospaces. + +## 20.1 Required Retrieval Properties + +Every major concept SHOULD provide: + +- stable heading, +- stable identifier, +- short definition, +- longer explanation, +- examples, +- distinction notes, +- relationship examples, +- mapping hooks, +- profile references, +- and common mistakes. + +## 20.2 Agent Brief + +A mature DevSecOps Model SHOULD include an `agent-brief.md` file with: + +```text +purpose +scope +owned concepts +imported concepts +core distinctions +do / do not rules +relationship patterns +minimal examples +common mistakes +profile list +mapping list +``` + +## 20.3 Indexes + +The DevSecOps information space SHOULD provide indexes by: + +```text +concept +relationship +repository +pipeline +artifact +release +deployment +environment +evidence type +profile +pattern +mapping target +status +source system +``` + +--- + +# 21. Conformance Levels + +## 21.1 Reference-Conformant + +A document or system is reference-conformant if it uses DevSecOps Model terminology consistently but does not implement structured metadata or validation rules. + +## 21.2 Metadata-Conformant + +A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types. + +## 21.3 Traceability-Conformant + +A system is traceability-conformant if it can connect source change, pipeline run, artifact version, release, deployment, and runtime target. + +## 21.4 Evidence-Conformant + +A system is evidence-conformant if builds, tests, scans, gates, releases, and deployments are linked to evidence. + +## 21.5 Supply-Chain-Conformant + +A system is supply-chain-conformant if artifact versions can be connected to SBOMs, provenance, attestations, signatures, and verification results. + +## 21.6 Profile-Conformant + +A system is profile-conformant if it implements a declared DevSecOps Profile and passes its validation rules. + +## 21.7 Assimilation-Conformant + +A system or repository is assimilation-conformant if it can accept external DevSecOps concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes. + +--- + +# 22. Validation Rules + +Initial validation rules: + +```text +VAL-DEVSECOPS-001: Repository, Commit, ArtifactVersion, Release, DeploymentRecord, and RuntimeWorkload SHOULD be modeled as distinct concepts. + +VAL-DEVSECOPS-002: PipelineDefinition SHOULD be distinguished from PipelineRun. + +VAL-DEVSECOPS-003: PipelineRun SHOULD reference source revision and produced outputs where available. + +VAL-DEVSECOPS-004: ArtifactVersion SHOULD include immutable identity such as digest where available. + +VAL-DEVSECOPS-005: ContainerImage SHOULD use digest for immutable identity when used for deployment or evidence. + +VAL-DEVSECOPS-006: ArtifactVersion SHOULD reference SBOM, provenance, attestation, and signature where available. + +VAL-DEVSECOPS-007: ScanResult SHOULD reference the ScanRun and target artifact/source/configuration it scanned. + +VAL-DEVSECOPS-008: PolicyGate SHOULD reference Governance Policy, Rule, Control, or Exception where applicable. + +VAL-DEVSECOPS-009: GateDecision SHOULD record pass/fail/waived/indeterminate state and evidence. + +VAL-DEVSECOPS-010: DeploymentRecord SHOULD reference artifact version, target environment, actor or pipeline, time, and result. + +VAL-DEVSECOPS-011: Deployment SHOULD NOT be treated as identical to Release. + +VAL-DEVSECOPS-012: Rollback SHOULD reference the failed or superseded deployment where possible. + +VAL-DEVSECOPS-013: DeploymentVerification SHOULD reference runtime or observability evidence where available. + +VAL-DEVSECOPS-014: AgentGeneratedPatch SHOULD reference supervising actor, task, evidence, and review expectation where relevant. + +VAL-DEVSECOPS-015: DeliveryMetric SHOULD declare measurement definition and source. + +VAL-DEVSECOPS-016: Imported external delivery concepts SHOULD be represented through mapping records rather than silently reused. + +VAL-DEVSECOPS-017: Profiles MUST NOT redefine canonical concepts. They may constrain them. + +VAL-DEVSECOPS-018: Source tags MUST NOT be confused with InfoTechCanon tagging concepts. +``` + +--- + +# 23. Anti-Patterns + +## 23.1 Commit Equals Deployment + +Assuming that merging code means a change is running. + +## 23.2 Artifact Without Identity + +Publishing artifacts without immutable digest or version identity. + +## 23.3 Pipeline Run Without Evidence + +Running CI/CD without preserving logs, outputs, test results, scan results, or gate decisions. + +## 23.4 Deployment Equals Release + +Treating deployed code as released capability when feature flags or progressive delivery are used. + +## 23.5 Rebuild Per Environment + +Rebuilding artifacts in each environment and losing provenance. + +## 23.6 Scanner Dashboard Graveyard + +Producing scan findings without linking them to artifacts, runtime impact, remediation tasks, or verification. + +## 23.7 Policy Gate Theater + +Adding gates that can be bypassed without exception records, evidence, or review. + +## 23.8 Unsigned Trust + +Trusting artifacts without provenance, signature, attestation, or source traceability. + +## 23.9 Tool-Native Capture + +Letting GitHub, GitLab, Jenkins, or Argo CD define the internal delivery model. + +## 23.10 Agent Change Without Accountability + +Allowing agent-generated changes without supervision, evidence, review, or authorization boundaries. + +--- + +# 24. Initial Repository Placement + +Recommended repository layout: + +```text +info-tech-canon/ + standards/ + devsecops/ + InfoTechCanonDevSecOpsModel.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +Seed files: + +```text +standards/devsecops/InfoTechCanonDevSecOpsModel.md +standards/devsecops/agent-brief.md +standards/devsecops/concepts/repository.md +standards/devsecops/concepts/pipeline-run.md +standards/devsecops/concepts/artifact-version.md +standards/devsecops/concepts/sbom.md +standards/devsecops/concepts/provenance.md +standards/devsecops/concepts/attestation.md +standards/devsecops/concepts/release.md +standards/devsecops/concepts/deployment-record.md +standards/devsecops/patterns/commit-to-runtime-trace.md +standards/devsecops/patterns/build-once-promote.md +standards/devsecops/patterns/provenance-carrying-artifact.md +standards/devsecops/patterns/deployment-is-not-release.md +standards/devsecops/profiles/small-saas-devsecops-profile.md +standards/devsecops/profiles/github-actions-delivery-profile.md +standards/devsecops/profiles/kubernetes-gitops-delivery-profile.md +standards/devsecops/profiles/slsa-provenance-profile.md +standards/devsecops/profiles/sbom-profile.md +standards/devsecops/mappings/slsa.yaml +standards/devsecops/mappings/in-toto.yaml +standards/devsecops/mappings/spdx.yaml +standards/devsecops/mappings/cyclonedx.yaml +standards/devsecops/mappings/github-actions.yaml +``` + +--- + +# 25. Roadmap + +## Phase 1: Seed Stabilization + +- Establish this standard as `InfoTechCanonDevSecOpsModel`. +- Add seed concepts, relationship vocabulary, patterns, and profiles. +- Define validation rules. +- Align with Landscape, Governance, Task, Security, Data, Access Control, and Tagging. + +## Phase 2: First Assimilations + +Recommended first assimilations: + +```text +SLSA 1.2 +in-toto Attestation Framework +SPDX 3.x +CycloneDX +GitHub Actions +GitLab CI +Argo CD +Flux +OpenSSF Scorecard +DORA metrics +Sigstore / Cosign +OpenFeature +``` + +## Phase 3: Profile Maturation + +- Mature Small SaaS DevSecOps Profile. +- Mature GitHub Actions Delivery Profile. +- Mature GitLab CI Delivery Profile. +- Mature Kubernetes GitOps Delivery Profile. +- Mature SLSA / Provenance Profile. +- Mature SBOM Profile. +- Mature Agentic Delivery Profile. + +## Phase 4: Tooling Integration + +- Generate concept indexes. +- Generate agent brief. +- Create machine-readable YAML/JSON exports. +- Add validation scripts. +- Integrate repository, CI/CD, artifact registry, SBOM, scanner, signing, deployment, GitOps, observability, and task systems. + +## Phase 5: Delivery Intelligence Loop + +- Connect commits to tasks. +- Connect artifacts to SBOM/provenance/signature. +- Connect deployments to runtime and observability. +- Connect findings to remediation. +- Connect policy gates to governance. +- Connect release and deployment outcomes to DORA-style metrics. +- Connect agentic changes to supervision, review, and evidence. + +--- + +# 26. Summary + +The InfoTechCanon DevSecOps Model is the seed standard for representing secure delivery from source change to artifact, evidence, release, deployment, runtime verification, and feedback. + +Its most important commitments are: + +```text +Separate source, pipeline definition, pipeline run, artifact, release, deployment, and runtime state. + +Treat SBOMs, provenance, attestations, signatures, tests, scans, and gate decisions as first-class evidence. + +Support secure supply-chain models such as SLSA, in-toto, SPDX, CycloneDX, Sigstore, and OpenSSF Scorecard +without surrendering internal semantic autonomy. + +Represent deployment and release separately to support feature flags and progressive delivery. + +Connect delivery to governance, security, data contracts, access control, landscape runtime state, +tasks, observability, and agentic coding workflows. + +Use profiles to make the model practical for GitHub Actions, GitLab CI, GitOps, Kubernetes, +SBOMs, SLSA provenance, and agentic delivery. +``` + +This makes the DevSecOps Model a core seed for production readiness, supply-chain trust, secure delivery automation, auditability, and AI-assisted software development. diff --git a/seeds/InfoTechCanonGovernanceModel_RC1_seed.md b/seeds/InfoTechCanonGovernanceModel_RC1_seed.md new file mode 100755 index 0000000..16b0764 --- /dev/null +++ b/seeds/InfoTechCanonGovernanceModel_RC1_seed.md @@ -0,0 +1,2181 @@ +# InfoTechCanon Governance Model + +**Short Name:** `ITC-GOV` +**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:** Governance designers, enterprise architects, service owners, platform owners, risk managers, compliance reviewers, security architects, quality managers, auditors, product owners, DevSecOps teams, organization designers, knowledge-system builders, standards authors, and agentic tooling. + +--- + +# 1. Purpose + +The **InfoTechCanon Governance Model** defines a canonical seed model for representing governance across information-processing systems, organizations, services, platforms, software delivery, security, data, risk, compliance, and operational control. + +It provides the canonical vocabulary for: + +- policies, +- principles, +- rules, +- decisions, +- decision rights, +- obligations, +- requirements, +- controls, +- control objectives, +- risks, +- issues, +- exceptions, +- waivers, +- evidence, +- assurance, +- audits, +- reviews, +- approvals, +- governance processes, +- and governance cycles. + +This standard is intended to become the third foundational seed standard of InfoTechCanon, following: + +```text +InfoTechCanonLandscapeModel +InfoTechCanonOrganizationModel +InfoTechCanonGovernanceModel +``` + +Together these define the first core triad: + +```text +Landscape = what exists and how it relates. +Organization = who can act, belong, own, operate, and be responsible. +Governance = how action is directed, constrained, justified, reviewed, and evidenced. +``` + +--- + +# 2. Position in InfoTechCanon + +The Governance Model is a **domain standard** within InfoTechCanon. + +It should become the canonical owner of governance concepts that are currently only referenced by the Landscape Model and Organization Model. + +```text +InfoTechCanon +├── InfoTechCanonCore +├── InfoTechCanonLandscapeModel +├── InfoTechCanonOrganizationModel +├── InfoTechCanonGovernanceModel <-- this standard +├── InfoTechCanonTaskModel +├── InfoTechCanonTaggingStandard +├── InfoTechCanonAccessControlModel +├── InfoTechCanonSecurityModel +├── InfoTechCanonDataModel +├── InfoTechCanonDevSecOpsModel +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +--- + +# 3. Boundary with Adjacent Standards + +## 3.1 Boundary with Organization + +The Organization Model owns: + +```text +Actor +Person +Agent +Team +Organization +OrganizationalUnit +Role +Position +Membership +Assignment +Responsibility +Authority +Accountability +Ownership +Stewardship +ReportingLine +``` + +The Governance Model owns: + +```text +Policy +Principle +Rule +Decision +DecisionRight +Requirement +Obligation +ControlObjective +Control +Risk +Issue +Exception +Waiver +Evidence +Assurance +Audit +Review +Approval +GovernanceProcess +GovernanceCycle +``` + +Boundary rule: + +```text +Organization defines who can act and carry responsibility or authority. +Governance defines the rules, decisions, controls, obligations, risk structures, +and evidence systems that direct, constrain, justify, and review action. +``` + +## 3.2 Boundary with Landscape + +The Landscape Model owns: + +```text +Service +SoftwareSystem +RuntimeResource +NetworkEntity +DataStore +Artifact +DeploymentRecord +Endpoint +ObservabilitySignal +LandscapeRelationship +``` + +The Governance Model governs these entities but does not own their technical definitions. + +Example: + +```text +Policy governs ApplicationService +Control applies_to RuntimeWorkload +Risk affects BusinessService +Evidence supports LandscapeClaim +Exception waives Control +``` + +## 3.3 Boundary with Security + +The Security Model should own detailed security domain concepts such as: + +```text +Threat +Vulnerability +AttackPath +SecurityFinding +SecurityControlImplementation +Credential +Secret +SecurityEvent +``` + +The Governance Model owns generic governance concepts such as: + +```text +Risk +Control +ControlObjective +Policy +Exception +Evidence +Assurance +ComplianceRequirement +``` + +Security-specific governance should be modeled as a profile or specialization of generic governance. + +## 3.4 Boundary with Access Control + +Access Control should own: + +```text +Permission +Entitlement +Credential +AuthorizationDecision +AccessPolicyImplementation +Privilege +``` + +Governance owns: + +```text +AccessPolicy as a policy +AccessControlObjective as a control objective +AccessReview as a governance review +AccessException as an exception +``` + +--- + +# 4. Research Basis and External Alignment + +This seed standard draws on multiple bodies of governance knowledge. + +## 4.1 General Organizational Governance + +General governance standards such as ISO 37000 emphasize that governance applies to organizations of different types, sizes, structures, and purposes, and that governing bodies or groups guide organizations to fulfill their purpose responsibly. + +## 4.2 Governance of IT + +ISO/IEC 38500 and IT governance practice emphasize a governance cycle often summarized as: + +```text +Evaluate +Direct +Monitor +``` + +This cycle is highly useful as a canonical governance pattern. + +## 4.3 COBIT + +COBIT provides a mature body of knowledge for enterprise governance of information and technology. Its distinction between governance objectives and management objectives, including governance focused on Evaluate, Direct, and Monitor, is important for keeping governance distinct from operational management. + +## 4.4 COSO Internal Control + +COSO internal-control thinking contributes the idea that controls exist in an integrated control system with components such as control environment, risk assessment, control activities, information and communication, and monitoring. + +## 4.5 ISO 31000 Risk Management + +ISO 31000 provides a general, organization-neutral approach to risk management through principles, a framework, and a process. It reinforces the need to distinguish risk identification, analysis, evaluation, treatment, monitoring, and communication. + +## 4.6 NIST Cybersecurity Framework 2.0 + +NIST CSF 2.0 introduced `Govern` as one of its top-level functions alongside Identify, Protect, Detect, Respond, and Recover. This supports treating governance as an explicit foundation for cybersecurity and risk management rather than an implicit afterthought. + +## 4.7 ISO 9001 Roles, Responsibilities, and Authorities + +Quality management practice emphasizes that responsibilities and authorities must be assigned, communicated, and understood. In InfoTechCanon, Organization owns the actor/role structure, while Governance owns the rules and evidence that ensure responsibilities and authorities are directed and reviewed. + +## 4.8 Audit, Assurance, and Compliance Practice + +Audit and assurance practice contributes the distinction between requirements, controls, control objectives, evidence, testing, findings, exceptions, remediation, and assurance conclusions. + +--- + +# 5. Seed Standard Design Stance + +This standard is a **seed standard**, not a complete theory of governance. + +It shall: + +1. define enough canonical concepts for practical system integration, +2. distinguish governance from management, organization, security, and access control, +3. support general governance and IT governance, +4. support policy, control, risk, evidence, decision, and assurance modeling, +5. support mappings to external frameworks without becoming subordinate to them, +6. support regulatory alignment without becoming legal advice, +7. provide pattern anchors for practical governance mechanisms, +8. provide profiles for implementation contexts, +9. remain markdown-first and agent-retrievable, +10. and support future assimilation of standards, frameworks, regulations, and product models. + +--- + +# 6. Scope + +## 6.1 In Scope + +This standard covers canonical representation of: + +- governance systems, +- governance scopes, +- principles, +- policies, +- rules, +- standards, +- requirements, +- obligations, +- decisions, +- decision rights, +- approvals, +- reviews, +- controls, +- control objectives, +- risks, +- issues, +- exceptions, +- waivers, +- evidence, +- audit, +- assurance, +- compliance requirements, +- governance processes, +- governance cycles, +- governance bodies as references to Organization concepts, +- control testing, +- monitoring, +- and governance mappings. + +## 6.2 Out of Scope + +This standard does not fully define: + +- all organization theory, +- all IT service management, +- all risk management methods, +- all security domain controls, +- all legal compliance obligations, +- full audit methodology, +- full enterprise architecture governance, +- full quality management systems, +- full access-control mechanics, +- or specific regulatory interpretation. + +Those may be mapped, assimilated, profiled, or handled by adjacent standards. + +--- + +# 7. 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 defined provisionally here but open to later refinement. +- **EXTRACT** marks a concept that may later move to a more specialized standard. + +--- + +# 8. Core Principles + +## 8.1 Governance Is Not Management + +Governance SHALL be distinguished from management. + +```text +Governance evaluates, directs, constrains, authorizes, reviews, and assures. +Management plans, builds, operates, delivers, improves, and executes. +``` + +## 8.2 Governance Requires Scope + +Every policy, control, risk, decision, exception, and obligation SHOULD declare its governance scope. + +## 8.3 Governance Requires Accountable Actors + +Governance artifacts SHOULD reference accountable actors through the Organization Model. + +## 8.4 Policy Is Not Control + +A policy states intent, rule, or direction. +A control implements, enforces, verifies, or assures that intent. + +## 8.5 Requirement Is Not Evidence + +A requirement states what must be true. +Evidence supports a claim that something is true. + +## 8.6 Risk Is Not Finding + +A risk is uncertainty or exposure relative to objectives. +A finding is an observed issue, weakness, nonconformity, or result of assessment. + +## 8.7 Exception Is Not Deletion + +An exception or waiver does not remove a requirement or control. It records a scoped, justified, time-bound deviation. + +## 8.8 Governance Should Be Evidence-Carrying + +Governance claims SHOULD be supported by evidence, source, timestamp, scope, and confidence. + +## 8.9 External Frameworks Are Mapped, Not Obeyed + +The Governance Model MAY map to ISO, COBIT, COSO, NIST, ITIL, regulatory, and product models. + +It MUST NOT subordinate its internal semantics to any single external framework. + +--- + +# 9. Canonical Seed Metadata + +Every governance artifact SHOULD support structured metadata. + +Recommended front matter: + +```yaml +--- +id: itc-gov:Policy +type: concept +standard: InfoTechCanonGovernanceModel +standard_version: RC1-seed +status: candidate +canonical_owner: InfoTechCanonGovernanceModel +preferred_label: Policy +related: + - itc-gov:Rule + - itc-gov:Control + - itc-gov:Requirement + - itc-org:Authority +mappings: + - itc-map:policy-to-cobit-policy-component +--- +``` + +Recommended artifact statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +Recommended concept statuses: + +```text +proposed +experimental +candidate +canonical +deprecated +retired +``` + +--- + +# 10. Root Governance Taxonomy + +```text +GovernanceEntity +├── DirectionEntity +│ ├── Principle +│ ├── Policy +│ ├── Rule +│ ├── Standard +│ ├── Guideline +│ └── Requirement +├── DecisionEntity +│ ├── Decision +│ ├── DecisionRight +│ ├── Approval +│ ├── Review +│ ├── Escalation +│ └── GovernanceForum +├── ControlEntity +│ ├── ControlObjective +│ ├── Control +│ ├── ControlActivity +│ ├── ControlImplementation +│ ├── ControlTest +│ └── ControlResult +├── RiskEntity +│ ├── Risk +│ ├── RiskSource +│ ├── ThreatReference +│ ├── Impact +│ ├── Likelihood +│ ├── RiskTreatment +│ └── RiskAcceptance +├── ComplianceEntity +│ ├── Obligation +│ ├── ComplianceRequirement +│ ├── ControlMapping +│ ├── ComplianceStatus +│ └── RegulatoryReference +├── ExceptionEntity +│ ├── Exception +│ ├── Waiver +│ ├── Deviation +│ ├── CompensatingControl +│ └── ExpiryCondition +├── EvidenceEntity +│ ├── Evidence +│ ├── Attestation +│ ├── Assertion +│ ├── Finding +│ ├── Nonconformity +│ └── Remediation +├── AssuranceEntity +│ ├── Audit +│ ├── Assessment +│ ├── AssuranceCase +│ ├── AssuranceConclusion +│ └── MonitoringActivity +└── GovernanceSystemEntity + ├── GovernanceSystem + ├── GovernanceScope + ├── GovernanceProcess + ├── GovernanceCycle + ├── GovernanceBodyReference + └── ManagementInterface +``` + +--- + +# 11. Core Concepts + +## 11.1 GovernanceEntity + +A **GovernanceEntity** is any identifiable concept used to direct, constrain, authorize, review, evidence, or assure action within a defined scope. + +Recommended attributes: + +```yaml +id: +entity_type: +canonical_name: +display_name: +lifecycle_state: +governance_scope: +source_system: +created_at: +updated_at: +``` + +Optional attributes: + +```yaml +owner: +accountable_actor: +approver: +review_cycle: +criticality: +classification: +source_confidence: +valid_from: +valid_to: +tags: +external_references: +``` + +--- + +## 11.2 GovernanceSystem + +A **GovernanceSystem** is the organized set of principles, policies, decision structures, controls, risk processes, evidence mechanisms, and assurance activities used to direct and constrain action within a scope. + +A governance system may govern: + +```text +organization +product +service +platform +software delivery +security +data +architecture +operations +compliance domain +``` + +--- + +## 11.3 GovernanceScope + +A **GovernanceScope** defines the boundary within which a governance artifact applies. + +Examples: + +```text +whole organization +business unit +product +service +platform +environment +repository +data domain +customer tenant +regulatory domain +security domain +``` + +Canonical rule: + +```text +Governance artifacts SHOULD declare their scope. +``` + +--- + +## 11.4 Principle + +A **Principle** is a high-level normative statement that guides decisions and design. + +Examples: + +```text +Security is built in, not bolted on. +Production access must be accountable. +Declared state and observed state must be distinguished. +External standards are mapped, not obeyed. +``` + +Principles are more stable and abstract than policies or rules. + +--- + +## 11.5 Policy + +A **Policy** is an authoritative statement of intent, direction, constraint, or required behavior within a scope. + +A policy may be supported by: + +```text +rules +standards +controls +procedures +guidelines +evidence requirements +exception processes +``` + +Canonical rule: + +```text +A policy SHOULD have an accountable owner and a review cycle. +``` + +--- + +## 11.6 Rule + +A **Rule** is a more specific directive derived from a policy, standard, regulation, decision, or control objective. + +Examples: + +```text +All production deployments require signed artifacts. +Privileged scripts must be allowlisted. +Customer data must not be stored outside approved regions. +``` + +--- + +## 11.7 Standard + +A **Standard** is a defined set of required or recommended practices, terms, controls, criteria, or specifications. + +In InfoTechCanon, a standard may be: + +```text +internal InfoTechCanon standard +external industry standard +regulatory technical standard +implementation standard +quality standard +security standard +``` + +--- + +## 11.8 Guideline + +A **Guideline** is recommended but not strictly mandatory direction. + +Guidelines may become policies or standards if repeated implementation need or risk justifies stronger normative force. + +--- + +## 11.9 Requirement + +A **Requirement** is a statement of a condition, capability, behavior, constraint, or outcome that must be satisfied. + +Sources of requirements include: + +```text +policy +law +contract +standard +architecture decision +control objective +stakeholder need +risk treatment +service agreement +``` + +--- + +## 11.10 Obligation + +An **Obligation** is a requirement that an actor or organization is bound to satisfy because of law, contract, policy, decision, or accepted responsibility. + +Obligations SHOULD reference: + +```text +source +bound actor or scope +required action or condition +due date or recurrence +evidence expectation +consequence of non-fulfillment +``` + +--- + +## 11.11 Decision + +A **Decision** is a recorded choice that changes, constrains, authorizes, or interprets action within a scope. + +Examples: + +```text +approve architecture exception +accept risk +select platform standard +authorize production deployment +deprecate legacy interface +``` + +--- + +## 11.12 DecisionRight + +A **DecisionRight** is the authority to make a class of decisions within a defined scope. + +Decision rights reference Organization concepts such as Actor, Role, Authority, and Accountability. + +Canonical rule: + +```text +Decision rights SHOULD be scoped, explicit, and reviewable. +``` + +--- + +## 11.13 Approval + +An **Approval** is a decision that authorizes a proposed action, artifact, change, exception, release, or state. + +Approval should not be conflated with evidence. Approval says permitted; evidence says supported. + +--- + +## 11.14 Review + +A **Review** is a governance activity that examines an artifact, decision, state, risk, control, or process against criteria. + +Examples: + +```text +architecture review +access review +risk review +control review +release review +policy review +post-incident review +``` + +--- + +## 11.15 Escalation + +An **Escalation** is the transfer of a decision, issue, exception, risk, or conflict to a higher or different authority. + +Escalation SHOULD preserve context, prior decisions, evidence, and unresolved questions. + +--- + +## 11.16 GovernanceForum + +A **GovernanceForum** is a recurring or ad hoc structure where governance decisions, reviews, escalations, or interpretations occur. + +Examples: + +```text +architecture board +security review board +change advisory board +risk committee +data governance council +product steering group +``` + +A GovernanceForum references an organizational actor or collective structure but is modeled here as a governance mechanism. + +--- + +## 11.17 ControlObjective + +A **ControlObjective** is the intended governance, risk, compliance, quality, or security outcome a control is meant to achieve. + +Examples: + +```text +Only authorized actors can change production systems. +Software artifacts are traceable to source and build process. +Personal data is processed only within approved scope. +``` + +--- + +## 11.18 Control + +A **Control** is a mechanism intended to prevent, detect, correct, direct, or assure behavior relative to a control objective. + +Control types: + +```text +preventive +detective +corrective +directive +compensating +automated +manual +hybrid +``` + +Canonical rule: + +```text +A control SHOULD reference at least one control objective. +``` + +--- + +## 11.19 ControlActivity + +A **ControlActivity** is an operational activity that implements or performs a control. + +Examples: + +```text +review access list +verify artifact signature +run vulnerability scan +approve change +reconcile configuration drift +``` + +--- + +## 11.20 ControlImplementation + +A **ControlImplementation** is the concrete implementation of a control in a system, process, configuration, workflow, tool, script, or human procedure. + +Example: + +```text +ControlObjective: + Production deployment requires approval. + +Control: + Release approval gate. + +ControlImplementation: + GitHub Actions environment protection rule requiring approval by release managers. +``` + +--- + +## 11.21 ControlTest + +A **ControlTest** is an assessment activity used to determine whether a control is designed, implemented, and operating effectively. + +--- + +## 11.22 ControlResult + +A **ControlResult** is the outcome of a control activity or control test. + +Examples: + +```text +pass +fail +not applicable +inconclusive +partially effective +``` + +--- + +## 11.23 Risk + +A **Risk** is uncertainty or exposure that may affect objectives, outcomes, obligations, services, systems, people, or values. + +Risk SHOULD include: + +```yaml +risk_source: +affected_scope: +impact: +likelihood: +risk_level: +treatment: +owner: +status: +``` + +--- + +## 11.24 RiskSource + +A **RiskSource** is the origin or cause that may give rise to risk. + +Examples: + +```text +threat actor +supplier dependency +technical debt +regulatory change +single point of failure +skill concentration +manual control weakness +``` + +--- + +## 11.25 Impact + +An **Impact** is the consequence of risk materialization. + +Examples: + +```text +financial loss +service outage +regulatory violation +data breach +safety harm +reputational damage +delivery delay +loss of trust +``` + +--- + +## 11.26 Likelihood + +**Likelihood** is the assessed chance, frequency, or plausibility of risk occurrence. + +InfoTechCanon does not mandate a specific likelihood scale. Profiles may define one. + +--- + +## 11.27 RiskTreatment + +A **RiskTreatment** is an intended response to risk. + +Treatment types: + +```text +avoid +reduce +transfer +accept +monitor +exploit +``` + +--- + +## 11.28 RiskAcceptance + +**RiskAcceptance** is a decision to accept a risk within a defined scope, authority, duration, and rationale. + +Risk acceptance SHOULD be time-bounded and evidence-backed. + +--- + +## 11.29 ComplianceRequirement + +A **ComplianceRequirement** is a requirement derived from a law, regulation, standard, contract, policy, certification scheme, or external obligation. + +--- + +## 11.30 RegulatoryReference + +A **RegulatoryReference** is a pointer to an external law, regulation, standard, clause, control, article, or official guidance. + +The Governance Model does not interpret law by default. It records references, mappings, obligations, and evidence expectations. + +--- + +## 11.31 Exception + +An **Exception** is an approved deviation from a policy, rule, standard, requirement, or control. + +An exception SHOULD include: + +```yaml +scope: +justification: +risk_assessment: +approver: +valid_from: +valid_to: +compensating_controls: +review_cycle: +expiry_condition: +``` + +--- + +## 11.32 Waiver + +A **Waiver** is a specific kind of exception that temporarily or conditionally waives enforcement of a requirement or control. + +Canonical rule: + +```text +Waivers SHOULD expire unless explicitly renewed. +``` + +--- + +## 11.33 CompensatingControl + +A **CompensatingControl** is a control used to reduce risk when the primary expected control is absent, weakened, or waived. + +--- + +## 11.34 Evidence + +**Evidence** is information used to support a claim, decision, control result, compliance status, risk assessment, audit conclusion, or assurance case. + +Examples: + +```text +log extract +signed attestation +ticket +screenshot +scan result +configuration file +test result +deployment record +policy document +meeting decision +audit sample +``` + +--- + +## 11.35 Assertion + +An **Assertion** is a claim that something is true. + +Evidence supports assertions. + +--- + +## 11.36 Attestation + +An **Attestation** is a signed or otherwise accountable assertion by an actor, system, or process. + +--- + +## 11.37 Finding + +A **Finding** is an observed issue, weakness, nonconformity, result, or notable assessment outcome. + +Finding types: + +```text +control_failure +policy_violation +risk_observation +audit_finding +security_finding +quality_nonconformity +process_gap +data_quality_issue +``` + +--- + +## 11.38 Nonconformity + +A **Nonconformity** is a failure to meet a specified requirement, standard, policy, or control expectation. + +--- + +## 11.39 Remediation + +**Remediation** is action taken to correct a finding, nonconformity, control weakness, or risk condition. + +--- + +## 11.40 Audit + +An **Audit** is a systematic, independent, and documented examination of evidence against criteria. + +--- + +## 11.41 Assessment + +An **Assessment** is an evaluation of an artifact, system, process, risk, control, or state against criteria. + +Audits are a specific kind of assessment with stronger independence and procedural expectations. + +--- + +## 11.42 AssuranceCase + +An **AssuranceCase** is a structured argument, supported by evidence, that a claim about governance, risk, compliance, safety, security, or quality is justified. + +--- + +## 11.43 AssuranceConclusion + +An **AssuranceConclusion** is the result of an assurance activity. + +Examples: + +```text +effective +partially effective +ineffective +not assessed +not applicable +reasonable assurance +limited assurance +``` + +--- + +## 11.44 GovernanceProcess + +A **GovernanceProcess** is a repeatable process for making decisions, reviewing status, managing risk, approving exceptions, monitoring controls, or maintaining policies. + +Examples: + +```text +policy review process +risk review process +architecture review process +exception approval process +control testing process +access review process +release governance process +``` + +--- + +## 11.45 GovernanceCycle + +A **GovernanceCycle** is a recurring pattern by which governance is performed. + +Seed cycle: + +```text +Evaluate +Direct +Monitor +Review +Adapt +``` + +`Evaluate`, `Direct`, and `Monitor` form the core governance cycle. +`Review` and `Adapt` are added here to support learning, assimilation, and standard evolution. + +--- + +# 12. Core Relationship Vocabulary + +Recommended root relationship types: + +```text +governs +constrains +requires +permits +prohibits +recommends +implements +satisfies +violates +derives_from +interprets +decides +approves +rejects +waives +accepts +escalates_to +reviewed_by +owned_by +accountable_to +applies_to +affects +mitigates +treats +monitors +tests +evidences +supports +challenges +supersedes +maps_to +``` + +Relationship records SHOULD support: + +```yaml +id: +relationship_type: +source_entity: +target_entity: +scope: +valid_from: +valid_to: +source_system: +confidence: +evidence: +rationale: +``` + +--- + +# 13. Governance State Model + +Governance artifacts SHOULD use lifecycle and assessment states. + +## 13.1 Policy States + +```text +draft +under_review +approved +active +suspended +deprecated +retired +superseded +``` + +## 13.2 Risk States + +```text +identified +analysed +evaluated +treatment_planned +treatment_in_progress +accepted +monitored +realized +closed +``` + +## 13.3 Control States + +```text +designed +implemented +operating +tested_effective +tested_ineffective +not_applicable +retired +``` + +## 13.4 Exception States + +```text +requested +under_review +approved +rejected +active +expired +renewed +revoked +closed +``` + +## 13.5 Finding States + +```text +open +triaged +accepted +remediation_planned +remediation_in_progress +remediated +verified +closed +``` + +--- + +# 14. Governance Patterns + +## 14.1 Pattern: Evaluate-Direct-Monitor + +**Context:** A governing actor or body must govern a scope without performing all operational work. + +**Problem:** Governance collapses into either passive reporting or micromanagement. + +**Solution:** Use a cycle: + +```text +Evaluate current and expected conditions. +Direct through principles, policies, decisions, and priorities. +Monitor performance, risk, compliance, and outcomes. +``` + +**Extension for InfoTechCanon:** + +```text +Review results and adapt the governance system. +``` + +--- + +## 14.2 Pattern: Policy-Control-Evidence Chain + +**Context:** A policy must become practically enforceable and auditable. + +**Problem:** Policies remain aspirational if they are not linked to controls and evidence. + +**Solution:** + +```text +Policy + -> Requirement / Rule + -> ControlObjective + -> Control + -> ControlImplementation + -> ControlActivity / ControlTest + -> Evidence + -> AssuranceConclusion +``` + +--- + +## 14.3 Pattern: Exception with Expiry + +**Context:** Real systems sometimes cannot comply immediately. + +**Problem:** Permanent informal exceptions destroy governance integrity. + +**Solution:** Model exceptions with: + +```text +scope +justification +risk assessment +approver +validity period +compensating controls +review date +expiry condition +``` + +--- + +## 14.4 Pattern: Risk-to-Treatment Trace + +**Context:** Risks must lead to action or explicit acceptance. + +**Problem:** Risk registers become passive lists. + +**Solution:** + +```text +Risk + -> RiskEvaluation + -> RiskTreatment + -> Control / Action / Acceptance + -> Evidence + -> Monitoring +``` + +--- + +## 14.5 Pattern: Decision with Rationale + +**Context:** Architectural, governance, and operational decisions need traceability. + +**Problem:** Decisions are forgotten, repeated, or contradicted. + +**Solution:** Record: + +```text +decision +scope +context +options considered +rationale +decision authority +date +expected consequences +review trigger +supersession relation +``` + +--- + +## 14.6 Pattern: Control Objective Before Control + +**Context:** Organizations implement controls from checklists. + +**Problem:** Controls become cargo cults without clear purpose. + +**Solution:** Define or map the control objective before selecting or implementing controls. + +--- + +## 14.7 Pattern: Governance Not Management + +**Context:** Governance and management functions are confused. + +**Problem:** Governance bodies micromanage operations, or management decisions lack governance direction. + +**Solution:** Model governance activities separately from management activities, with explicit interfaces. + +--- + +## 14.8 Pattern: Evidence-Carrying Governance Claim + +**Context:** A system claims compliance, control effectiveness, or risk reduction. + +**Problem:** Claims without evidence cannot be trusted or audited. + +**Solution:** Model the claim separately from its evidence and source. + +--- + +# 15. Governance Profiles + +## 15.1 Profile Format + +A Governance Profile SHALL declare: + +```yaml +id: +profile_name: +status: +implements: + - InfoTechCanonGovernanceModel +target_context: +included_concepts: +required_relationships: +required_metadata: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +--- + +## 15.2 Seed Profile: Small SaaS Governance Profile + +Purpose: + +```text +Provide a minimal governance model for a small SaaS platform moving toward production readiness. +``` + +Included concepts: + +```text +Policy +Principle +Rule +Decision +Approval +Risk +ControlObjective +Control +Exception +Evidence +Finding +Review +GovernanceProcess +``` + +Required relationships: + +```text +Policy governs Service +Rule derives_from Policy +Control implements ControlObjective +Control applies_to RuntimeResource +Evidence supports ControlResult +Risk affects Service +Exception waives Requirement +Decision approves Exception +Finding violates Control +Review monitors Risk +``` + +--- + +## 15.3 Seed Profile: DevSecOps Governance Profile + +Purpose: + +```text +Define governance for secure software delivery without blocking adaptability. +``` + +Included concepts: + +```text +Policy +PolicyGate +Approval +Decision +ControlObjective +ControlImplementation +ArtifactEvidence +SBOMEvidence +Attestation +Finding +RiskAcceptance +Exception +ReleaseReview +``` + +Required relationships: + +```text +Policy governs Pipeline +PolicyGate implements Control +PipelineRun generates Evidence +Artifact attested_by Attestation +Finding affects Artifact +RiskAcceptance accepts Risk +Exception waives PolicyGate +Approval authorizes Release +``` + +--- + +## 15.4 Seed Profile: Access Governance Profile + +Purpose: + +```text +Connect organization, access control, and governance concepts. +``` + +Included concepts: + +```text +AccessPolicy +AccessReview +DecisionRight +Approval +Exception +ControlObjective +Control +Evidence +Finding +Remediation +``` + +Required relationships: + +```text +AccessPolicy governs Permission +AccessReview tests AccessControl +Evidence supports AccessReview +Finding identifies ExcessAccess +Approval authorizes AccessException +Remediation removes Entitlement +``` + +--- + +## 15.5 Seed Profile: Data Governance Profile + +Purpose: + +```text +Define governance concepts for data classification, retention, residency, lineage, and processing obligations. +``` + +Included concepts: + +```text +DataPolicy +DataClassificationRule +RetentionRequirement +ResidencyRequirement +ProcessingObligation +DataControl +DataException +Evidence +DataRisk +``` + +Required relationships: + +```text +Policy governs Dataset +Requirement applies_to DataObject +Control implements Requirement +Evidence supports ComplianceStatus +Exception waives Requirement +Risk affects Dataset +``` + +--- + +# 16. Mapping Model for the Governance Standard + +Mappings relate InfoTechCanon governance concepts to external standards, frameworks, products, and regulations. + +## 16.1 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +regulatoryReference +``` + +## 16.2 Mapping Record + +Example: + +```yaml +id: itc-map:governance-cycle-to-iso-38500-edm +source_concept: itc-gov:GovernanceCycle +target_body: ISO/IEC 38500 +target_version: "2015 or later" +target_concept: Evaluate-Direct-Monitor +mapping_type: closeMatch +scope: + - IT governance cycle +not_valid_for: + - full operational management lifecycle +rationale: > + InfoTechCanon uses Evaluate-Direct-Monitor as the core governance cycle + and adds Review/Adapt for learning and canon evolution. +confidence: high +status: candidate +owner: InfoTechCanonGovernanceModel +``` + +## 16.3 Seed Mapping Targets + +The Governance Model SHOULD maintain mappings to: + +```text +ISO 37000 governance of organizations +ISO/IEC 38500 governance of IT +COBIT 2019 +COSO Internal Control Framework +ISO 31000 risk management +NIST CSF 2.0 +ISO 9001 roles, responsibilities, and authorities +ISO/IEC 27001 / 27002 +ITIL 4 governance and service management +PMBOK governance and decision structures +RACI / RASCI models +ArchiMate motivation and implementation concepts +ServiceNow GRC / IRM concepts +Jira / GitHub approval and issue workflow concepts +``` + +--- + +# 17. Assimilation Hooks + +The Governance Model SHALL be able to receive new governance bodies of knowledge through the InfoTechCanon assimilation process. + +## 17.1 Assimilation Triggers + +Assimilation may be triggered by: + +```text +new regulation +new external governance framework +new audit framework +new security standard +new risk framework +new quality framework +new compliance obligation +new customer contract requirement +new recurring policy conflict +new governance failure +new agentic governance pattern +``` + +## 17.2 Governance Assimilation Output + +A governance assimilation SHOULD produce: + +```text +source summary +extracted governance concepts +concept comparison matrix +gap list +conflict list +mapping file +candidate new concepts +candidate relationship changes +candidate pattern changes +candidate profile changes +open questions +``` + +## 17.3 Recommended First Assimilation Candidates + +```text +ISO/IEC 38500 +COBIT 2019 +NIST CSF 2.0 +ISO 31000 +COSO Internal Control +ISO 37000 +ISO 9001 Clause 5.3 +ISO/IEC 27001 Annex A governance-related controls +ITIL 4 governance concepts +``` + +--- + +# 18. Integration with Other InfoTechCanon Standards + +## 18.1 Organization Model + +Governance imports organization concepts for: + +```text +governance body +accountable actor +policy owner +risk owner +control owner +decision authority +approver +reviewer +auditor +responsible role +``` + +## 18.2 Landscape Model + +Governance applies to landscape concepts such as: + +```text +BusinessService +ApplicationService +TechnicalService +SoftwareComponent +Pipeline +Artifact +RuntimeResource +NetworkEndpoint +Dataset +Environment +``` + +## 18.3 Task Model + +Task imports governance concepts for: + +```text +approval +review +decision +escalation +obligation +due date +policy-driven work +risk-driven work +exception remediation +``` + +## 18.4 Tagging Standard + +Tagging imports governance concepts for: + +```text +risk +control +policy +compliance +exception +review +approval +evidence +audit +``` + +## 18.5 Access Control Model + +Access Control imports governance concepts for: + +```text +access policy +decision rights +approval +access review +exception +waiver +control objective +evidence +``` + +## 18.6 Security Model + +Security imports governance concepts for: + +```text +security policy +security control objective +risk +exception +finding +evidence +assurance +compliance requirement +``` + +--- + +# 19. Canon Interface Card Usage + +Subsystems that implement or produce governance knowledge SHOULD publish a Canon Interface Card. + +Example: + +```yaml +subsystem: governance-policy-registry +implements: + - InfoTechCanonGovernanceModel + - SmallSaaSGovernanceProfile +produces: + - Policy + - Rule + - ControlObjective + - Exception + - Evidence +consumes: + - Team + - Service + - RuntimeResource +relations: + - Policy governs Service + - Rule derives_from Policy + - Control implements ControlObjective + - Exception waives Rule +source_of_truth: + active_policies: governance-policy-registry +known_deviations: + - does not perform independent audit + - does not own organizational roles +``` + +--- + +# 20. Retrieval Requirements + +The Governance Model is designed for markdown-based infospaces. + +## 20.1 Required Retrieval Properties + +Every major concept SHOULD provide: + +- stable heading, +- stable identifier, +- short definition, +- longer explanation, +- examples, +- distinction notes, +- relationship examples, +- mapping hooks, +- profile references, +- and common mistakes. + +## 20.2 Agent Brief + +A mature Governance Model SHOULD include an `agent-brief.md` file with: + +```text +purpose +scope +owned concepts +imported concepts +core distinctions +do / do not rules +relationship patterns +minimal examples +common mistakes +profile list +mapping list +``` + +## 20.3 Indexes + +The governance information space SHOULD provide indexes by: + +```text +concept +relationship +policy +control +risk +requirement +exception +evidence +profile +pattern +mapping target +status +source system +``` + +--- + +# 21. Conformance Levels + +## 21.1 Reference-Conformant + +A document or system is reference-conformant if it uses Governance Model terminology consistently but does not implement structured metadata or validation rules. + +## 21.2 Metadata-Conformant + +A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types. + +## 21.3 Relationship-Conformant + +A system is relationship-conformant if it represents policies, controls, risks, exceptions, evidence, reviews, and decisions as explicit relationships. + +## 21.4 Evidence-Conformant + +A system is evidence-conformant if governance claims, control results, compliance states, and risk decisions are linked to evidence. + +## 21.5 Profile-Conformant + +A system is profile-conformant if it implements a declared Governance Profile and passes its validation rules. + +## 21.6 Assimilation-Conformant + +A system or repository is assimilation-conformant if it can accept external governance concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes. + +--- + +# 22. Validation Rules + +Initial validation rules: + +```text +VAL-GOV-001: A Policy SHOULD declare an owner, scope, status, and review cycle. + +VAL-GOV-002: A Rule SHOULD derive from a Policy, Standard, Requirement, Decision, or external obligation. + +VAL-GOV-003: A Control SHOULD reference at least one ControlObjective. + +VAL-GOV-004: A ControlImplementation SHOULD reference the system, process, workflow, or artifact that implements it. + +VAL-GOV-005: A Risk SHOULD declare affected scope, owner, impact, likelihood or equivalent assessment, and treatment status. + +VAL-GOV-006: RiskAcceptance SHOULD declare authority, scope, rationale, and validity period. + +VAL-GOV-007: An Exception SHOULD declare scope, justification, approver, risk assessment, validity period, and expiry condition. + +VAL-GOV-008: A Waiver SHOULD NOT be permanent unless explicitly justified by a profile. + +VAL-GOV-009: Evidence SHOULD reference the claim, control result, decision, or requirement it supports. + +VAL-GOV-010: A Finding SHOULD reference the requirement, control, risk, or assessment that produced it. + +VAL-GOV-011: Approval MUST NOT be treated as Evidence unless the claim being evidenced is the approval itself. + +VAL-GOV-012: Governance and management activities SHOULD be distinguished in mature implementations. + +VAL-GOV-013: Imported external governance concepts SHOULD be represented through mapping records rather than silently reused. + +VAL-GOV-014: Profiles MUST NOT redefine canonical concepts. They may constrain them. + +VAL-GOV-015: Governance artifacts SHOULD reference Organization Model actors for ownership, accountability, approval, and review. + +VAL-GOV-016: Governance artifacts applying to systems SHOULD reference Landscape Model entities where possible. +``` + +--- + +# 23. Anti-Patterns + +## 23.1 Policy Without Control + +A policy exists but no controls, evidence expectations, or review mechanisms make it operational. + +## 23.2 Control Without Objective + +A control is implemented because a checklist says so, but nobody can explain which objective it supports. + +## 23.3 Evidence-Free Compliance + +Compliance is asserted without evidence. + +## 23.4 Permanent Exception + +An exception becomes a hidden permanent policy bypass. + +## 23.5 Risk Register as Graveyard + +Risks are recorded but not treated, accepted, monitored, or closed. + +## 23.6 Approval Theater + +Approvals are collected without meaningful decision rights, criteria, or accountability. + +## 23.7 Governance as Micromanagement + +A governance body directly manages operational details instead of evaluating, directing, monitoring, reviewing, and adapting. + +## 23.8 Framework Subordination + +The internal model is bent around a single external framework and loses adaptability. + +## 23.9 Hidden Decision Rights + +Decisions are made repeatedly without knowing who has authority to make them. + +## 23.10 Control Confusion + +Policy, rule, requirement, control objective, control, implementation, test, and evidence are treated as one thing. + +--- + +# 24. Initial Repository Placement + +Recommended repository layout: + +```text +info-tech-canon/ + standards/ + governance/ + InfoTechCanonGovernanceModel.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +Seed files: + +```text +standards/governance/InfoTechCanonGovernanceModel.md +standards/governance/agent-brief.md +standards/governance/concepts/policy.md +standards/governance/concepts/control.md +standards/governance/concepts/risk.md +standards/governance/concepts/evidence.md +standards/governance/concepts/exception.md +standards/governance/concepts/decision.md +standards/governance/patterns/policy-control-evidence-chain.md +standards/governance/patterns/exception-with-expiry.md +standards/governance/patterns/risk-to-treatment-trace.md +standards/governance/profiles/small-saas-governance-profile.md +standards/governance/profiles/devsecops-governance-profile.md +standards/governance/profiles/access-governance-profile.md +standards/governance/mappings/iso-38500.yaml +standards/governance/mappings/cobit.yaml +standards/governance/mappings/nist-csf.yaml +standards/governance/mappings/iso-31000.yaml +``` + +--- + +# 25. Roadmap + +## Phase 1: Seed Stabilization + +- Establish this standard as `InfoTechCanonGovernanceModel`. +- Extract governance concepts from the Landscape and Organization models. +- Add seed concepts, relationship vocabulary, patterns, and profiles. +- Define validation rules. + +## Phase 2: Core Alignment + +- Align with `InfoTechCanonCore` once defined. +- Move generic mapping, profile, pattern, provenance, and conformance mechanics into Core. +- Keep only governance-specific applications here. + +## Phase 3: First Assimilations + +Recommended first assimilations: + +```text +ISO/IEC 38500 +COBIT 2019 +NIST CSF 2.0 +ISO 31000 +COSO Internal Control +ISO 37000 +ISO 9001 Clause 5.3 +``` + +## Phase 4: Profile Maturation + +- Create Small SaaS Governance Profile. +- Create DevSecOps Governance Profile. +- Create Access Governance Profile. +- Create Data Governance Profile. +- Connect profiles to Landscape and Organization models. + +## Phase 5: Tooling Integration + +- Generate concept indexes. +- Generate agent brief. +- Create machine-readable YAML/JSON exports. +- Add validation scripts. +- Use governance model in task, access-control, security, data, DevSecOps, and landscape repositories. + +--- + +# 26. Summary + +The InfoTechCanon Governance Model is the seed standard for modeling how action is directed, constrained, justified, reviewed, evidenced, and improved. + +Its most important commitments are: + +```text +Separate governance from management. + +Separate policy, rule, requirement, control objective, control, +implementation, test, evidence, risk, finding, exception, and decision. + +Connect governance to Organization for accountable actors. + +Connect governance to Landscape for governed systems and services. + +Use mappings and assimilation to stay connected to external frameworks +without surrendering internal semantic autonomy. + +Treat evidence and expiry as first-class mechanisms. + +Use profiles to make governance practical for concrete implementation contexts. +``` + +This makes the Governance Model the third foundational seed of InfoTechCanon and a key bridge toward task modeling, tagging, access control, security, data governance, DevSecOps governance, and operational assurance. diff --git a/seeds/InfoTechCanonInformationSpaceModel_RC1_seed.md b/seeds/InfoTechCanonInformationSpaceModel_RC1_seed.md new file mode 100755 index 0000000..9df2720 --- /dev/null +++ b/seeds/InfoTechCanonInformationSpaceModel_RC1_seed.md @@ -0,0 +1,2072 @@ +# InfoTechCanon Information Space Model + +**Short Name:** `ITC-INFOSPACE` +**Document Status:** Seed Standard Release Candidate 1 +**Version:** RC1-seed +**Date:** 2026-05-23 +**Repository Context:** `info-tech-canon` +**Document Type:** InfoTechCanon Domain Standard +**Intended Audience:** Knowledge-system builders, markdown-infospace maintainers, standards authors, AI-agent tool builders, documentation architects, information architects, ontology/taxonomy maintainers, software architects, platform builders, and retrieval-system designers. + +--- + +# 1. Purpose + +The **InfoTechCanon Information Space Model** defines a canonical seed model for representing markdown-first, human-readable, machine-retrievable, provenance-aware, interconnected information spaces. + +It exists to provide the structural and semantic foundation for using InfoTechCanon as an evolving reference body for humans, agents, tools, and services. + +This standard owns the concepts required to make a body of knowledge: + +- navigable, +- retrievable, +- reusable, +- linkable, +- citable, +- chunkable, +- versionable, +- mappable, +- provenance-aware, +- profile-aware, +- and suitable for both human reading and agentic use. + +It provides a canonical vocabulary for: + +- information spaces, +- knowledge artifacts, +- markdown documents, +- concept pages, +- standard documents, +- chunks, +- sections, +- anchors, +- identifiers, +- links, +- backlinks, +- citations, +- references, +- indexes, +- summaries, +- agent briefs, +- retrieval units, +- embeddings, +- metadata, +- provenance, +- mappings, +- assimilation records, +- views, +- navigation structures, +- and knowledge-quality signals. + +--- + +# 2. Position in InfoTechCanon + +The Information Space Model is a **domain standard** within InfoTechCanon. + +It should serve as the structural substrate for how all other standards are stored, retrieved, navigated, linked, mapped, and reused. + +```text +InfoTechCanon +├── InfoTechCanonCore +├── InfoTechCanonInformationSpaceModel <-- this standard +├── InfoTechCanonLandscapeModel +├── InfoTechCanonOrganizationModel +├── InfoTechCanonGovernanceModel +├── InfoTechCanonTaskModel +├── InfoTechCanonTaggingStandard +├── InfoTechCanonAccessControlModel +├── InfoTechCanonSecurityModel +├── InfoTechCanonDataModel +├── InfoTechCanonDevSecOpsModel +├── InfoTechCanonNetworkModel +├── InfoTechCanonObservabilityModel +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +The dependency role is: + +```text +Domain standards define meaning. +Information Space defines how meaning is packaged, linked, indexed, retrieved, cited, and reused. +``` + +--- + +# 3. Boundary with Adjacent Standards + +## 3.1 Boundary with Core + +InfoTechCanonCore should own generic canon mechanisms: + +```text +Concept +Standard +Pattern +Profile +Mapping +Assimilation +Versioning +Conformance +Canonical Owner +``` + +The Information Space Model owns the storage, retrieval, navigation, chunking, and documentation structures used to operationalize those mechanisms. + +## 3.2 Boundary with Tagging + +The Tagging Standard owns tag identity, schemes, namespaces, assignments, and validation. + +The Information Space Model uses tags for navigation and retrieval but does not define tag semantics. + +## 3.3 Boundary with Data + +The Data Model owns datasets, schemas, data products, lineage, data contracts, and data quality. + +The Information Space Model owns knowledge artifacts, documents, chunks, indexes, and retrieval units. + +A corpus of Markdown files may be treated as data by the Data Model, but the information-space semantics are owned here. + +## 3.4 Boundary with Governance + +Governance owns policies, controls, decisions, exceptions, evidence, and assurance. + +The Information Space Model owns how governance documents, evidence references, citations, and versioned documentation artifacts are structured and retrieved. + +## 3.5 Boundary with DevSecOps + +DevSecOps owns source repositories, commits, pipelines, releases, deployments, SBOMs, and attestations. + +The Information Space Model may be implemented in Git and linked to DevSecOps records, but it owns the knowledge-space structure. + +## 3.6 Boundary with Observability + +Observability owns telemetry, signals, metrics, logs, traces, alerts, and operational evidence. + +The Information Space Model owns knowledge artifacts and retrieval structures, not runtime telemetry. + +--- + +# 4. Research Basis and External Alignment + +This seed standard draws on several knowledge organization and metadata traditions. + +## 4.1 SKOS + +SKOS defines a common data model for sharing and linking knowledge organization systems such as thesauri, taxonomies, classification schemes, and subject-heading systems. It provides useful concepts such as concept schemes, preferred labels, alternative labels, broader/narrower relations, related relations, and mapping relations. + +## 4.2 FAIR Principles + +The FAIR principles emphasize that digital assets should be Findable, Accessible, Interoperable, and Reusable. They are especially relevant because InfoTechCanon must be useful to both humans and machines. + +## 4.3 PROV-O + +PROV-O models provenance through entities, activities, and agents. This is central for tracking how knowledge artifacts, mappings, assimilations, and standards evolved. + +## 4.4 Dublin Core and Application Profiles + +Dublin Core and the Singapore Framework for application profiles distinguish reusable metadata vocabularies from application-specific profiles. This directly supports InfoTechCanon’s distinction between canonical concepts and concrete profiles. + +## 4.5 Zettelkasten, Wikis, and Hypertext + +Zettelkasten and wiki traditions emphasize durable notes, links, backlinks, local context, reuse, and emergent structure. They are useful for the human side of markdown-first information spaces. + +## 4.6 Documentation Systems and Static Site Generators + +Modern documentation systems emphasize stable headings, cross-links, front matter, sidebars, indexes, search, versioned docs, and generated navigation. These are practical implementation targets. + +## 4.7 Retrieval-Augmented Generation + +RAG systems require chunking, metadata, embeddings, summaries, stable identifiers, source references, and retrieval-quality evaluation. The Information Space Model should make retrieval a first-class design concern rather than an afterthought. + +--- + +# 5. Seed Standard Design Stance + +This standard is a **seed standard**, not a complete CMS, ontology, or retrieval-engine specification. + +It shall: + +1. define canonical information-space semantics, +2. remain markdown-first, +3. support human navigation and agent retrieval, +4. support stable identifiers and anchors, +5. support chunking and retrieval units, +6. support citations, references, provenance, and versioning, +7. support indexes, views, summaries, and agent briefs, +8. support mappings and assimilation records, +9. map to external standards without becoming subordinate to them, +10. support future integration with markdown infobase tools and services. + +--- + +# 6. Scope + +## 6.1 In Scope + +This standard covers canonical representation of: + +- information spaces, +- knowledge bases, +- infospaces, +- repositories as knowledge spaces, +- markdown documents, +- concept pages, +- standard documents, +- pattern documents, +- profile documents, +- mapping documents, +- assimilation reports, +- decision records, +- sections, +- headings, +- anchors, +- stable identifiers, +- chunks, +- retrieval units, +- summaries, +- agent briefs, +- front matter, +- metadata records, +- links, +- backlinks, +- citations, +- references, +- external references, +- indexes, +- navigation views, +- document collections, +- shard references, +- source references, +- provenance records, +- version records, +- quality signals, +- embedding records, +- retrieval queries, +- retrieval results, +- and reuse contexts. + +## 6.2 Out of Scope + +This standard does not fully define: + +- all semantic-web ontology modeling, +- all RDF/OWL reasoning, +- full CMS implementation, +- full search-engine ranking, +- all embedding algorithms, +- full vector-database implementation, +- all document authoring standards, +- all bibliography formats, +- all legal citation systems, +- all software repository structures, +- or every markdown dialect. + +Those may be mapped, assimilated, profiled, or handled by adjacent standards. + +--- + +# 7. 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 defined provisionally here but open to later refinement. +- **EXTRACT** marks a concept that may later move to a more specialized standard. + +--- + +# 8. Core Principles + +## 8.1 Markdown-First, Not Markdown-Only + +The canonical working format SHOULD be Markdown with structured metadata, but the model SHOULD allow export to JSON, YAML, RDF, JSON-LD, graph databases, search indexes, and vector stores. + +## 8.2 Human-Readable and Machine-Retrievable + +Every important artifact SHOULD be readable by humans and retrievable by machines. + +## 8.3 Stable Identity Is Mandatory for Reuse + +Artifacts, sections, concepts, mappings, profiles, and retrieval units SHOULD have stable identifiers. + +## 8.4 Chunking Is a Design Concern + +Documents SHOULD be structured so that retrieval chunks preserve meaning, context, and source traceability. + +## 8.5 Links Are First-Class + +Links, backlinks, references, citations, and mappings SHOULD be explicit and queryable where possible. + +## 8.6 Provenance Is First-Class + +Knowledge artifacts SHOULD preserve source, author, generator, change activity, review state, and influence where meaningful. + +## 8.7 Views Are Not the Model + +Indexes, navigation pages, diagrams, generated views, and dashboards are views over the information space, not the underlying knowledge itself. + +## 8.8 Retrieval Must Be Evaluated + +Useful information spaces SHOULD support retrieval-quality checks, stale-content detection, broken-link detection, and duplicate/conflict detection. + +## 8.9 External Standards Are Mapped, Not Obeyed + +The Information Space Model MAY map to SKOS, FAIR, PROV-O, Dublin Core, DCAT, Markdown, DITA, RDF, JSON-LD, static-site generators, and RAG tooling patterns. + +It MUST NOT subordinate its internal semantics to any single external model. + +--- + +# 9. Canonical Seed Metadata + +Every information-space artifact SHOULD support structured metadata. + +Recommended front matter: + +```yaml +--- +id: itc-infospace:KnowledgeArtifact +type: concept +standard: InfoTechCanonInformationSpaceModel +standard_version: RC1-seed +status: candidate +canonical_owner: InfoTechCanonInformationSpaceModel +preferred_label: Knowledge Artifact +related: + - itc-infospace:InformationSpace + - itc-infospace:Document + - itc-infospace:RetrievalUnit + - itc-infospace:ProvenanceRecord +mappings: + - itc-map:knowledge-artifact-to-prov-entity +--- +``` + +Recommended artifact statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +Recommended content statuses: + +```text +raw +captured +draft +reviewed +candidate +canonical +deprecated +superseded +archived +``` + +--- + +# 10. Root Information Space Taxonomy + +```text +InformationSpaceEntity +├── SpaceEntity +│ ├── InformationSpace +│ ├── KnowledgeBase +│ ├── Infospace +│ ├── RepositorySpace +│ ├── Shard +│ ├── Collection +│ └── Corpus +├── ArtifactEntity +│ ├── KnowledgeArtifact +│ ├── Document +│ ├── MarkdownDocument +│ ├── ConceptPage +│ ├── StandardDocument +│ ├── PatternDocument +│ ├── ProfileDocument +│ ├── MappingDocument +│ ├── AssimilationReport +│ ├── DecisionRecord +│ └── AgentBrief +├── StructureEntity +│ ├── Section +│ ├── Heading +│ ├── Anchor +│ ├── Block +│ ├── Chunk +│ ├── RetrievalUnit +│ ├── Summary +│ └── Excerpt +├── LinkEntity +│ ├── Link +│ ├── Backlink +│ ├── CrossReference +│ ├── Citation +│ ├── SourceReference +│ ├── ExternalReference +│ ├── MappingReference +│ └── DependencyReference +├── MetadataEntity +│ ├── FrontMatter +│ ├── MetadataRecord +│ ├── Identifier +│ ├── Namespace +│ ├── Label +│ ├── Alias +│ ├── Status +│ └── VersionRecord +├── RetrievalEntity +│ ├── Index +│ ├── SearchIndex +│ ├── VectorIndex +│ ├── EmbeddingRecord +│ ├── RetrievalQuery +│ ├── RetrievalResult +│ ├── RetrievalContext +│ └── RetrievalEvaluation +├── ProvenanceEntity +│ ├── ProvenanceRecord +│ ├── Source +│ ├── Activity +│ ├── AgentReference +│ ├── Generation +│ ├── Revision +│ ├── Influence +│ └── ReviewRecord +├── ViewEntity +│ ├── NavigationView +│ ├── TopicIndex +│ ├── ConceptIndex +│ ├── RelationshipIndex +│ ├── MapView +│ ├── GraphView +│ └── UsePath +└── QualityEntity + ├── BrokenLink + ├── DuplicateContent + ├── StaleContent + ├── ConflictingDefinition + ├── MissingMetadata + ├── LowRetrievalQuality + └── OrphanArtifact +``` + +--- + +# 11. Core Concepts + +## 11.1 InformationSpace + +An **InformationSpace** is a bounded, navigable, retrievable, and evolving body of knowledge. + +Examples: + +```text +InfoTechCanon repository +project wiki +standards library +markdown knowledge base +research corpus +documentation space +agent-readable context repository +``` + +--- + +## 11.2 KnowledgeBase + +A **KnowledgeBase** is an information space organized to preserve, retrieve, and reuse knowledge. + +--- + +## 11.3 Infospace + +An **Infospace** is a structured knowledge environment optimized for navigation, recombination, retrieval, and reuse. + +In InfoTechCanon, an infospace is expected to be markdown-first and machine-indexable. + +--- + +## 11.4 RepositorySpace + +A **RepositorySpace** is an information space backed by a source repository. + +--- + +## 11.5 Shard + +A **Shard** is an independently maintained portion of an information space that can be attached, federated, cached, or overlaid with other shards. + +This concept supports shard-wiki-like federation. + +--- + +## 11.6 Collection + +A **Collection** is a curated group of knowledge artifacts. + +--- + +## 11.7 Corpus + +A **Corpus** is a body of documents or artifacts used for search, retrieval, analysis, or training-like reference. + +--- + +## 11.8 KnowledgeArtifact + +A **KnowledgeArtifact** is any identifiable artifact that carries reusable knowledge. + +Examples: + +```text +standard document +concept page +pattern document +profile +mapping file +assimilation report +decision record +agent brief +example +schema +diagram +``` + +--- + +## 11.9 Document + +A **Document** is a knowledge artifact primarily represented as ordered textual or structured content. + +--- + +## 11.10 MarkdownDocument + +A **MarkdownDocument** is a document represented in Markdown or a Markdown-compatible dialect. + +--- + +## 11.11 ConceptPage + +A **ConceptPage** is a document or section that defines and explains one canonical concept. + +--- + +## 11.12 StandardDocument + +A **StandardDocument** is a document defining a standard, its scope, concepts, relationships, validation rules, mappings, and profiles. + +--- + +## 11.13 PatternDocument + +A **PatternDocument** is a document describing a recurring problem, forces, solution, resulting context, variants, and related patterns. + +--- + +## 11.14 ProfileDocument + +A **ProfileDocument** is a document defining constraints and implementation guidance for a specific context. + +--- + +## 11.15 MappingDocument + +A **MappingDocument** defines mappings between InfoTechCanon concepts and external standards, regulations, tools, vocabularies, or product schemas. + +--- + +## 11.16 AssimilationReport + +An **AssimilationReport** documents the analysis of an external body of knowledge, including extracted concepts, gaps, conflicts, mappings, and proposed canon changes. + +--- + +## 11.17 DecisionRecord + +A **DecisionRecord** records a decision, context, options, rationale, consequences, and review trigger. + +--- + +## 11.18 AgentBrief + +An **AgentBrief** is a compact, retrieval-optimized document summarizing a standard, profile, pattern, or subsystem for AI-agent use. + +Recommended content: + +```text +purpose +scope +owned concepts +imported concepts +do / do not rules +common mistakes +minimal examples +mapping targets +validation hints +``` + +--- + +## 11.19 Section + +A **Section** is a named portion of a document. + +--- + +## 11.20 Heading + +A **Heading** is a section title used for human navigation and machine chunking. + +--- + +## 11.21 Anchor + +An **Anchor** is a stable target within an artifact. + +Anchors SHOULD remain stable across non-breaking edits. + +--- + +## 11.22 Block + +A **Block** is a structurally meaningful piece of content such as a paragraph, list, table, code block, callout, or diagram block. + +--- + +## 11.23 Chunk + +A **Chunk** is a segment of content prepared for retrieval, indexing, embedding, citation, or context assembly. + +Canonical rule: + +```text +A Chunk SHOULD preserve enough context to be meaningful when retrieved independently. +``` + +--- + +## 11.24 RetrievalUnit + +A **RetrievalUnit** is a retrievable unit of knowledge. + +A retrieval unit may be: + +```text +document +section +chunk +concept page +pattern +profile +mapping +example +agent brief +``` + +--- + +## 11.25 Summary + +A **Summary** is a compressed representation of an artifact or retrieval unit. + +--- + +## 11.26 Excerpt + +An **Excerpt** is a quoted or extracted part of a source. + +Excerpts SHOULD preserve source reference and usage constraints. + +--- + +## 11.27 Link + +A **Link** is a directed reference from one artifact or section to another. + +--- + +## 11.28 Backlink + +A **Backlink** is an inverse view of a link. + +--- + +## 11.29 CrossReference + +A **CrossReference** is a link between related artifacts, concepts, patterns, profiles, or sections. + +--- + +## 11.30 Citation + +A **Citation** is a reference to a source used to support a claim, definition, mapping, or statement. + +--- + +## 11.31 SourceReference + +A **SourceReference** identifies the source from which information was derived, quoted, summarized, mapped, or assimilated. + +--- + +## 11.32 ExternalReference + +An **ExternalReference** points to a source outside the information space. + +--- + +## 11.33 MappingReference + +A **MappingReference** points from an artifact to a mapping record or external concept mapping. + +--- + +## 11.34 DependencyReference + +A **DependencyReference** indicates that one artifact depends on another for meaning, validity, or interpretation. + +--- + +## 11.35 FrontMatter + +**FrontMatter** is structured metadata embedded at the beginning of a Markdown document. + +--- + +## 11.36 MetadataRecord + +A **MetadataRecord** is structured data describing an artifact, section, chunk, index entry, or retrieval unit. + +--- + +## 11.37 Identifier + +An **Identifier** is a stable reference string for an artifact or entity. + +Recommended properties: + +```text +stable +unique within namespace +human-readable when practical +machine-parseable +version-aware where needed +``` + +--- + +## 11.38 Namespace + +A **Namespace** is a naming scope used to prevent identifier collisions. + +Examples: + +```text +itc-core +itc-land +itc-org +itc-gov +itc-task +itc-tag +itc-access +itc-sec +itc-data +itc-devsecops +itc-net +itc-obs +itc-infospace +``` + +--- + +## 11.39 Label + +A **Label** is a human-readable name for an artifact or concept. + +--- + +## 11.40 Alias + +An **Alias** is an alternative label or name. + +--- + +## 11.41 Status + +A **Status** indicates lifecycle or review state. + +--- + +## 11.42 VersionRecord + +A **VersionRecord** records artifact version, change, compatibility, and supersession information. + +--- + +## 11.43 Index + +An **Index** is a structured access path into an information space. + +Examples: + +```text +concept index +standard index +pattern index +mapping index +profile index +source index +status index +external standard index +``` + +--- + +## 11.44 SearchIndex + +A **SearchIndex** supports lexical or semantic search. + +--- + +## 11.45 VectorIndex + +A **VectorIndex** supports embedding-based retrieval. + +--- + +## 11.46 EmbeddingRecord + +An **EmbeddingRecord** stores or references an embedding for a retrieval unit. + +Recommended attributes: + +```yaml +retrieval_unit: +embedding_model: +embedding_version: +created_at: +source_hash: +chunking_strategy: +``` + +--- + +## 11.47 RetrievalQuery + +A **RetrievalQuery** is a query used to find relevant artifacts or retrieval units. + +--- + +## 11.48 RetrievalResult + +A **RetrievalResult** is the result of a retrieval query. + +It SHOULD preserve rank, source, retrieval unit, score, and snippet/context where possible. + +--- + +## 11.49 RetrievalContext + +A **RetrievalContext** is the assembled set of retrieval results, summaries, and metadata used for human or agent work. + +--- + +## 11.50 RetrievalEvaluation + +A **RetrievalEvaluation** assesses retrieval quality. + +Examples: + +```text +relevance +coverage +freshness +precision +recall +source diversity +citation correctness +staleness +``` + +--- + +## 11.51 ProvenanceRecord + +A **ProvenanceRecord** documents how an artifact, concept, mapping, or retrieval unit came to exist or change. + +--- + +## 11.52 Source + +A **Source** is an origin of information. + +Examples: + +```text +external standard +uploaded document +web page +internal decision +agent-generated draft +manual authoring +assimilation report +``` + +--- + +## 11.53 Activity + +An **Activity** is an action that generated, modified, reviewed, mapped, assimilated, or published an artifact. + +--- + +## 11.54 AgentReference + +An **AgentReference** points to a human, software agent, organization, or tool responsible for or involved in an activity. + +--- + +## 11.55 Generation + +A **Generation** records creation of an artifact or retrieval unit. + +--- + +## 11.56 Revision + +A **Revision** records modification of an artifact. + +--- + +## 11.57 Influence + +An **Influence** records that one source, artifact, activity, or agent influenced another. + +--- + +## 11.58 ReviewRecord + +A **ReviewRecord** records review activity, reviewer, outcome, and comments. + +--- + +## 11.59 NavigationView + +A **NavigationView** is a human-oriented view for browsing an information space. + +--- + +## 11.60 TopicIndex + +A **TopicIndex** organizes artifacts by topic. + +--- + +## 11.61 ConceptIndex + +A **ConceptIndex** organizes concept pages or concept definitions. + +--- + +## 11.62 RelationshipIndex + +A **RelationshipIndex** organizes relationships among artifacts or concepts. + +--- + +## 11.63 MapView + +A **MapView** visualizes or lists relationships, dependencies, domains, or concept mappings. + +--- + +## 11.64 GraphView + +A **GraphView** represents the information space as nodes and edges. + +--- + +## 11.65 UsePath + +A **UsePath** is a guided path through the information space for a common user intent. + +Examples: + +```text +I want to model a new subsystem. +I want to map an external standard. +I want to create a task-tag profile. +I want to onboard an agent. +I want to check conformance. +``` + +--- + +## 11.66 BrokenLink + +A **BrokenLink** is a link whose target cannot be resolved. + +--- + +## 11.67 DuplicateContent + +**DuplicateContent** is overlapping or repeated content that may create drift. + +--- + +## 11.68 StaleContent + +**StaleContent** is content whose age, supersession state, or source drift reduces trust. + +--- + +## 11.69 ConflictingDefinition + +A **ConflictingDefinition** is a contradiction between definitions or concept usage. + +--- + +## 11.70 MissingMetadata + +**MissingMetadata** is required or expected metadata that is absent. + +--- + +## 11.71 LowRetrievalQuality + +**LowRetrievalQuality** indicates poor retrieval performance for a query, use path, or artifact set. + +--- + +## 11.72 OrphanArtifact + +An **OrphanArtifact** is an artifact with no incoming links, no index membership, no owner, or no retrieval path. + +--- + +# 12. Core Relationship Vocabulary + +Recommended root relationship types: + +```text +contains +part_of +defines +describes +summarizes +references +cites +links_to +backlinks_to +maps_to +depends_on +derived_from +generated_by +revised_by +reviewed_by +influenced_by +supersedes +deprecated_by +chunks_into +indexed_by +retrieved_by +embedded_as +has_view +belongs_to_space +belongs_to_collection +evidenced_by +``` + +Relationship records SHOULD support: + +```yaml +id: +relationship_type: +source_entity: +target_entity: +scope: +valid_from: +valid_to: +source_system: +confidence: +evidence: +rationale: +``` + +--- + +# 13. Information Space State Models + +## 13.1 Artifact States + +```text +raw +captured +draft +reviewed +candidate +canonical +deprecated +superseded +archived +deleted +``` + +## 13.2 Retrieval Unit States + +```text +active +stale +invalidated +deprecated +superseded +excluded +needs_rechunking +``` + +## 13.3 Link States + +```text +active +broken +redirected +deprecated +ambiguous +external_unverified +``` + +## 13.4 Review States + +```text +not_reviewed +under_review +reviewed +changes_requested +approved +rejected +needs_revalidation +``` + +## 13.5 Index States + +```text +fresh +stale +partial +rebuilding +failed +deprecated +``` + +--- + +# 14. Information Space Patterns + +## 14.1 Pattern: Markdown with Structured Front Matter + +**Context:** Humans need readable documents, while tools need structured metadata. + +**Problem:** Pure prose is hard to index and validate; pure data is hard to author. + +**Solution:** Use Markdown for content and front matter for structured metadata. + +--- + +## 14.2 Pattern: Concept Page per Canonical Concept + +**Context:** Concepts need stable definitions. + +**Problem:** Definitions drift when scattered across documents. + +**Solution:** Create one canonical concept page per important concept and link other documents to it. + +--- + +## 14.3 Pattern: Chunk with Parent Context + +**Context:** Agents retrieve chunks of documents. + +**Problem:** Retrieved chunks lose meaning if separated from document context. + +**Solution:** Each chunk should preserve parent artifact, section path, heading, concept identifiers, source, and version. + +--- + +## 14.4 Pattern: Agent Brief + +**Context:** Agents need compact guidance. + +**Problem:** Full standards are too large for routine retrieval. + +**Solution:** Provide agent briefs summarizing scope, owned concepts, imports, do/do-not rules, patterns, and examples. + +--- + +## 14.5 Pattern: Use Path Navigation + +**Context:** Humans and agents approach the canon with tasks, not just topics. + +**Problem:** A concept index alone does not explain where to start. + +**Solution:** Provide UsePath documents that guide common activities through relevant standards, patterns, profiles, and examples. + +--- + +## 14.6 Pattern: Source-Carrying Summary + +**Context:** Summaries are useful but may detach from evidence. + +**Problem:** Unsourced summaries become untrustworthy. + +**Solution:** Summaries SHOULD retain source references, provenance, generation activity, and review state. + +--- + +## 14.7 Pattern: Mapping as Linkable Artifact + +**Context:** External standards and internal concepts must stay aligned. + +**Problem:** Mapping notes buried in prose cannot be maintained. + +**Solution:** Represent mappings as first-class artifacts with source concept, target concept, mapping type, scope, confidence, rationale, and version. + +--- + +## 14.8 Pattern: Assimilation Folder + +**Context:** New external knowledge bodies must be digested. + +**Problem:** Research notes disappear after standards are updated. + +**Solution:** Each assimilation should produce a folder with source summary, extracted concepts, comparison matrix, mappings, proposed changes, and open questions. + +--- + +## 14.9 Pattern: View Not Source + +**Context:** Generated indexes and diagrams are useful. + +**Problem:** Teams edit generated views as if they were canonical source. + +**Solution:** Mark generated views clearly and regenerate them from canonical artifacts. + +--- + +## 14.10 Pattern: Retrieval Quality Loop + +**Context:** Agents depend on retrieval. + +**Problem:** Retrieval failures cause hallucination, contradiction, or stale answers. + +**Solution:** Track retrieval queries, expected results, misses, stale hits, duplicate hits, and quality fixes. + +--- + +# 15. Information Space Profiles + +## 15.1 Profile Format + +An Information Space Profile SHALL declare: + +```yaml +id: +profile_name: +status: +implements: + - InfoTechCanonInformationSpaceModel +target_context: +included_concepts: +required_metadata: +required_indexes: +chunking_rules: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +--- + +## 15.2 Seed Profile: InfoTechCanon Repository Profile + +Purpose: + +```text +Define the expected structure for the info-tech-canon repository. +``` + +Required top-level files: + +```text +README.md +INTENT.md +SCOPE.md +canon.yaml +``` + +Recommended directories: + +```text +standards/ +patterns/ +profiles/ +mappings/ +assimilation/ +schemas/ +views/ +agent/ +examples/ +validation/ +``` + +Required indexes: + +```text +by-standard +by-concept +by-pattern +by-profile +by-mapping-target +by-status +use-paths +``` + +--- + +## 15.3 Seed Profile: Markdown Infospace Profile + +Purpose: + +```text +Define a general profile for markdown-first knowledge spaces. +``` + +Required concepts: + +```text +MarkdownDocument +FrontMatter +Section +Anchor +Link +Backlink +Index +RetrievalUnit +ProvenanceRecord +``` + +Recommended front matter: + +```yaml +id: +title: +type: +status: +owner: +created_at: +updated_at: +tags: +related: +sources: +``` + +--- + +## 15.4 Seed Profile: Agent-Retrievable Standards Profile + +Purpose: + +```text +Make standards retrievable and usable by AI agents. +``` + +Required artifacts: + +```text +standard.md +agent-brief.md +concept index +relationship index +profile index +mapping index +examples +validation rules +``` + +Chunking rules: + +```text +chunk by major section +preserve heading path +preserve artifact id +preserve concept ids +include summary chunks +exclude generated noise +``` + +--- + +## 15.5 Seed Profile: Assimilation Workspace Profile + +Purpose: + +```text +Define how external bodies of knowledge are analyzed and assimilated. +``` + +Required files: + +```text +ASSIMILATION.md +source-summary.md +extracted-concepts.yaml +comparison-matrix.md +mappings.yaml +proposed-changes.md +open-questions.md +``` + +--- + +## 15.6 Seed Profile: Sharded Wiki Profile + +Purpose: + +```text +Support federated markdown knowledge spaces where multiple shards attach around shared root entities. +``` + +Included concepts: + +```text +Shard +ShardRoot +Overlay +RemoteReference +PatchProposal +MergeRequestReference +CachedArtifact +ShardBoundary +``` + +Known deviations: + +```text +Shard synchronization and merge mechanics are implementation-specific. +``` + +--- + +## 15.7 Seed Profile: RAG Corpus Profile + +Purpose: + +```text +Prepare an information space for retrieval-augmented generation. +``` + +Included concepts: + +```text +Corpus +RetrievalUnit +Chunk +EmbeddingRecord +SearchIndex +VectorIndex +RetrievalQuery +RetrievalResult +RetrievalEvaluation +``` + +Required metadata: + +```text +source id +artifact id +section path +chunk id +version +source hash +embedding model +created_at +``` + +--- + +# 16. Mapping Model for the Information Space Standard + +Mappings relate InfoTechCanon information-space concepts to external standards, frameworks, and tools. + +## 16.1 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +regulatoryReference +toolEquivalent +``` + +## 16.2 Mapping Record + +Example: + +```yaml +id: itc-map:concept-page-to-skos-concept +source_concept: itc-infospace:ConceptPage +target_body: SKOS +target_version: "2009" +target_concept: skos:Concept +mapping_type: relatedMatch +scope: + - knowledge organization and concept documentation +not_valid_for: + - all SKOS semantic constraints +rationale: > + A ConceptPage documents an InfoTechCanon concept, while skos:Concept + represents a conceptual resource in a concept scheme. They are related but not identical: + the page is a documentation artifact, the concept is the meaning being documented. +confidence: medium +status: candidate +owner: InfoTechCanonInformationSpaceModel +``` + +## 16.3 Seed Mapping Targets + +The Information Space Model SHOULD maintain mappings to: + +```text +SKOS +FAIR principles +PROV-O +Dublin Core +Singapore Framework for Dublin Core Application Profiles +DCAT +RDF / JSON-LD +Markdown / CommonMark +YAML front matter conventions +Git repository concepts +static site generator concepts +Obsidian / wiki-link conventions +Zettelkasten note patterns +DITA topic concepts +schema.org CreativeWork / Dataset +RAG / vector index tool schemas +``` + +--- + +# 17. Assimilation Hooks + +The Information Space Model SHALL be able to receive new knowledge-organization, metadata, documentation, retrieval, and wiki systems through the InfoTechCanon assimilation process. + +## 17.1 Assimilation Triggers + +Assimilation may be triggered by: + +```text +new metadata standard +new knowledge organization model +new wiki engine +new markdown convention +new documentation generator +new RAG architecture +new retrieval evaluation method +new citation model +new provenance standard +new agent context-management pattern +``` + +## 17.2 Information Space Assimilation Output + +An information-space assimilation SHOULD produce: + +```text +source summary +extracted information-space concepts +concept comparison matrix +gap list +conflict list +mapping file +candidate new concepts +candidate relationship changes +candidate pattern changes +candidate profile changes +open questions +``` + +## 17.3 Recommended First Assimilation Candidates + +```text +SKOS +FAIR principles +PROV-O +Dublin Core / Singapore Framework +CommonMark / Markdown conventions +Obsidian / wiki-link practice +Zettelkasten note practice +DITA topic architecture +RAG corpus and chunking patterns +static site generator metadata conventions +``` + +--- + +# 18. Integration with Other InfoTechCanon Standards + +## 18.1 Core + +Information Space uses Core concepts for: + +```text +Concept +Standard +Pattern +Profile +Mapping +Assimilation +Version +Conformance +CanonicalOwner +``` + +## 18.2 Tagging + +Information Space uses tags for: + +```text +topic +status +artifact type +domain +mapping target +retrieval group +``` + +## 18.3 Data + +Data treats corpora, indexes, embeddings, and retrieval results as data assets where needed. + +## 18.4 Governance + +Governance applies to: + +```text +review state +approval +evidence +publication status +deprecation +retention +access policy +``` + +## 18.5 DevSecOps + +DevSecOps tracks: + +```text +repository changes +build generation +publication pipelines +index generation +release of standards +``` + +## 18.6 Observability + +Observability tracks: + +```text +retrieval quality +index freshness +broken links +agent usage +search failures +``` + +## 18.7 Security and Access Control + +Security and Access Control apply to: + +```text +sensitive documents +restricted knowledge +credentials in documentation +agent access to knowledge +index access +retrieval audit +``` + +--- + +# 19. Canon Interface Card Usage + +Subsystems that implement or produce information-space knowledge SHOULD publish a Canon Interface Card. + +Example: + +```yaml +subsystem: markitect-tool +implements: + - InfoTechCanonInformationSpaceModel + - MarkdownInfospaceProfile +produces: + - MarkdownDocument + - FrontMatter + - Index + - RetrievalUnit + - Link + - ValidationResult +consumes: + - StandardDocument + - ConceptPage + - MappingDocument +relations: + - MarkdownDocument chunks_into RetrievalUnit + - RetrievalUnit indexed_by SearchIndex + - Link references KnowledgeArtifact +source_of_truth: + markdown_artifacts: git_repository +known_deviations: + - embedding storage may be external + - generated indexes may be rebuilt from source +``` + +--- + +# 20. Retrieval Requirements + +The Information Space Model is itself designed for retrieval. + +## 20.1 Required Retrieval Properties + +Every major artifact SHOULD provide: + +- stable identifier, +- stable title, +- artifact type, +- status, +- owner or steward, +- source references, +- related artifacts, +- headings, +- anchors, +- summary, +- front matter, +- and retrievable sections. + +## 20.2 Agent Brief + +A mature Information Space Model SHOULD include an `agent-brief.md` file with: + +```text +purpose +scope +owned concepts +imported concepts +artifact types +front matter rules +chunking rules +retrieval rules +do / do not rules +common mistakes +profile list +mapping list +``` + +## 20.3 Indexes + +The information space SHOULD provide indexes by: + +```text +artifact +concept +standard +pattern +profile +mapping +source +status +owner +tag +external reference +retrieval unit +use path +``` + +--- + +# 21. Conformance Levels + +## 21.1 Reference-Conformant + +A repository or document set is reference-conformant if it uses Information Space terminology consistently but does not implement structured metadata or validation rules. + +## 21.2 Metadata-Conformant + +A repository or document set is metadata-conformant if major artifacts have structured metadata and stable identifiers. + +## 21.3 Link-Conformant + +A repository or document set is link-conformant if internal links, backlinks, citations, and references are represented and checkable. + +## 21.4 Retrieval-Conformant + +A repository or document set is retrieval-conformant if artifacts are chunked, indexed, and retrievable with stable source context. + +## 21.5 Provenance-Conformant + +A repository or document set is provenance-conformant if artifacts and important changes preserve source, activity, agent, and review records. + +## 21.6 Profile-Conformant + +A repository or document set is profile-conformant if it implements a declared Information Space Profile and passes its validation rules. + +## 21.7 Assimilation-Conformant + +A repository or document set is assimilation-conformant if it can represent assimilation workspaces and produce mappings, gaps, conflicts, and proposed changes. + +--- + +# 22. Validation Rules + +Initial validation rules: + +```text +VAL-INFOSPACE-001: Every major KnowledgeArtifact SHOULD have a stable id. + +VAL-INFOSPACE-002: Every StandardDocument SHOULD declare status, version, owner, and scope. + +VAL-INFOSPACE-003: Every ConceptPage SHOULD define exactly one primary concept. + +VAL-INFOSPACE-004: Generated views SHOULD be marked as generated or derived. + +VAL-INFOSPACE-005: Internal links SHOULD resolve to existing artifacts or anchors. + +VAL-INFOSPACE-006: External references SHOULD include source, access date or source version where relevant. + +VAL-INFOSPACE-007: RetrievalUnit SHOULD preserve artifact id, section path, version, and source context. + +VAL-INFOSPACE-008: EmbeddingRecord SHOULD reference source hash, embedding model, and chunking strategy. + +VAL-INFOSPACE-009: Summary SHOULD reference the artifact or retrieval unit it summarizes. + +VAL-INFOSPACE-010: AgentBrief SHOULD be derived from or reviewed against the full artifact. + +VAL-INFOSPACE-011: AssimilationReport SHOULD include source summary, extracted concepts, comparison matrix, mappings, proposed changes, and open questions. + +VAL-INFOSPACE-012: MappingDocument SHOULD declare source concept, target body, target concept, mapping type, scope, confidence, and rationale. + +VAL-INFOSPACE-013: Deprecated artifacts SHOULD reference replacements where available. + +VAL-INFOSPACE-014: Orphan artifacts SHOULD be reviewed for indexing, linking, archiving, or deletion. + +VAL-INFOSPACE-015: Conflicting definitions SHOULD create review work or mapping notes. + +VAL-INFOSPACE-016: Sensitive knowledge artifacts SHOULD reference Access Control, Security, Data, or Governance constraints where relevant. + +VAL-INFOSPACE-017: Tags MUST NOT replace stable identifiers, links, mappings, or metadata. + +VAL-INFOSPACE-018: Profiles MUST NOT redefine canonical concepts. They may constrain them. +``` + +--- + +# 23. Anti-Patterns + +## 23.1 Markdown Pile + +A folder full of Markdown files without stable IDs, indexes, links, or metadata. + +## 23.2 Chunk Soup + +Chunks created for retrieval without preserving document context, heading path, source, or version. + +## 23.3 Summary Without Source + +Summaries detached from the source artifacts they summarize. + +## 23.4 Link Rot Inside the Repo + +Internal links break because anchors and file paths are not validated. + +## 23.5 View as Source + +Generated indexes or diagrams are edited manually and diverge from canonical artifacts. + +## 23.6 Embedding Without Provenance + +Embeddings are stored without model, source hash, chunking strategy, or creation time. + +## 23.7 Concept Drift by Duplication + +The same concept is defined in multiple places without canonical ownership. + +## 23.8 Agent Brief as Replacement + +Agents use compact briefs that are stale or inconsistent with full standards. + +## 23.9 Retrieval Without Evaluation + +Search and RAG are used without tests for relevance, freshness, and citation correctness. + +## 23.10 External Standard Copy-Paste + +External standards are copied into the information space without mapping, assimilation, or source boundaries. + +--- + +# 24. Initial Repository Placement + +Recommended repository layout: + +```text +info-tech-canon/ + standards/ + information-space/ + InfoTechCanonInformationSpaceModel.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +Seed files: + +```text +standards/information-space/InfoTechCanonInformationSpaceModel.md +standards/information-space/agent-brief.md +standards/information-space/concepts/information-space.md +standards/information-space/concepts/knowledge-artifact.md +standards/information-space/concepts/retrieval-unit.md +standards/information-space/concepts/chunk.md +standards/information-space/concepts/index.md +standards/information-space/concepts/agent-brief.md +standards/information-space/concepts/provenance-record.md +standards/information-space/patterns/markdown-with-structured-front-matter.md +standards/information-space/patterns/concept-page-per-canonical-concept.md +standards/information-space/patterns/chunk-with-parent-context.md +standards/information-space/patterns/agent-brief.md +standards/information-space/profiles/infotechcanon-repository-profile.md +standards/information-space/profiles/markdown-infospace-profile.md +standards/information-space/profiles/agent-retrievable-standards-profile.md +standards/information-space/profiles/assimilation-workspace-profile.md +standards/information-space/profiles/rag-corpus-profile.md +standards/information-space/mappings/skos.yaml +standards/information-space/mappings/fair.yaml +standards/information-space/mappings/prov-o.yaml +standards/information-space/mappings/dublin-core.yaml +``` + +--- + +# 25. Roadmap + +## Phase 1: Seed Stabilization + +- Establish this standard as `InfoTechCanonInformationSpaceModel`. +- Add seed concepts, relationship vocabulary, patterns, and profiles. +- Define validation rules. +- Align with Core, Tagging, Data, Governance, DevSecOps, Observability, Security, and Access Control. + +## Phase 2: First Assimilations + +Recommended first assimilations: + +```text +SKOS +FAIR principles +PROV-O +Dublin Core / Singapore Framework +CommonMark / Markdown conventions +Obsidian / wiki-link practice +Zettelkasten note practice +DITA topic architecture +RAG corpus and chunking patterns +``` + +## Phase 3: Profile Maturation + +- Mature InfoTechCanon Repository Profile. +- Mature Markdown Infospace Profile. +- Mature Agent-Retrievable Standards Profile. +- Mature Assimilation Workspace Profile. +- Mature Sharded Wiki Profile. +- Mature RAG Corpus Profile. + +## Phase 4: Tooling Integration + +- Generate concept indexes. +- Generate agent briefs. +- Generate chunk manifests. +- Generate machine-readable YAML/JSON exports. +- Add validation scripts. +- Add broken-link checks. +- Add stale-content checks. +- Add retrieval-quality tests. +- Integrate with markitect-tool, kontextual-engine, shard-wiki, llm-connect, and phase-memory. + +## Phase 5: Knowledge Intelligence Loop + +- Track retrieval failures. +- Track stale concepts. +- Track conflicting definitions. +- Track missing mappings. +- Track assimilation backlog. +- Generate improvement tasks. +- Use agent feedback to refine chunks, briefs, indexes, and profiles. + +--- + +# 26. Summary + +The InfoTechCanon Information Space Model is the seed standard for representing markdown-first, human-readable, machine-retrievable, provenance-aware, interconnected knowledge spaces. + +Its most important commitments are: + +```text +Separate domain meaning from knowledge-space packaging. + +Treat documents, sections, chunks, retrieval units, links, citations, indexes, +summaries, agent briefs, provenance, and mappings as first-class artifacts. + +Make markdown useful for both humans and agents through structured metadata, +stable identifiers, chunking rules, source references, and validation. + +Map to SKOS, FAIR, PROV-O, Dublin Core, Markdown, and RAG practices +without surrendering internal semantic autonomy. + +Use profiles to make the model practical for the InfoTechCanon repository, +markdown infospaces, sharded wikis, assimilation workspaces, and agent retrieval. +``` + +This makes the Information Space Model the structural substrate for turning InfoTechCanon from a collection of documents into a living, reusable, agent-operable knowledge system. diff --git a/seeds/InfoTechCanonKernelMap_RC1.md b/seeds/InfoTechCanonKernelMap_RC1.md new file mode 100755 index 0000000..6d17688 --- /dev/null +++ b/seeds/InfoTechCanonKernelMap_RC1.md @@ -0,0 +1,1565 @@ +# InfoTechCanon Kernel Map + +**Short Name:** `ITC-KERNEL-MAP` +**Document Status:** Draft 1 +**Version:** RC1-kernel-map +**Date:** 2026-05-23 +**Repository Context:** `info-tech-canon` +**Document Type:** Kernel Integration Map +**Purpose:** Consolidate the first-generation InfoTechCanon seed standards into one coherent kernel and show how the CARING standard fits into the canon. + +--- + +# 1. Purpose + +The **InfoTechCanon Kernel Map** describes how the first generation of InfoTechCanon seed standards fit together. + +It provides: + +- the initial canon kernel overview, +- the dependency and import graph, +- concept ownership boundaries, +- cross-standard integration points, +- the place of CARING within the canon, +- shared mechanisms that should be centralized in `InfoTechCanonCore`, +- known overlap and boundary tensions, +- first implementation profiles, +- first assimilation candidates, +- and the recommended refactoring sequence. + +This document is not itself a domain standard. It is a **coordination artifact** used to stabilize the kernel before further domain expansion. + +--- + +# 2. Kernel Overview + +The current InfoTechCanon kernel consists of these seed standards: + +```text +InfoTechCanonCore +InfoTechCanonInformationSpaceModel +InfoTechCanonLandscapeModel +InfoTechCanonOrganizationModel +InfoTechCanonGovernanceModel +InfoTechCanonTaskModel +InfoTechCanonTaggingStandard +InfoTechCanonAccessControlModel +InfoTechCanonSecurityModel +InfoTechCanonDataModel +InfoTechCanonDevSecOpsModel +InfoTechCanonNetworkModel +InfoTechCanonObservabilityModel +``` + +Together they form a coherent first-generation semantic substrate for building interoperable information-processing systems. + +A compact mental model: + +```text +Core = how the canon works. +Information Space = how canon knowledge is stored, linked, retrieved, and reused. +Landscape = what systems, services, resources, and runtime entities exist. +Organization = who can act, belong, own, steward, operate, and be responsible. +Governance = how action is directed, constrained, justified, reviewed, and evidenced. +Task = what work exists and how it becomes actionable, committed, and completed. +Tagging = how entities are lightly classified, filtered, and retrieved. +Access Control = who/what may perform which action on which resource under which conditions. +Security = threats, weaknesses, vulnerabilities, exposures, findings, incidents, and posture. +Data = datasets, schemas, classification, lineage, quality, contracts, and data products. +DevSecOps = source-to-artifact-to-release-to-deployment delivery flow and evidence. +Network = addressing, topology, routing, policy, reachability, flow, exposure, and state. +Observability = telemetry, signals, logs, metrics, traces, events, alerts, SLOs, and evidence. +``` + +--- + +# 3. Kernel Dependency Graph + +## 3.1 Foundational Layer + +```text +InfoTechCanonCore + ├── concept ownership + ├── mappings + ├── assimilation + ├── patterns + ├── profiles + ├── validation + ├── conformance + ├── versioning + ├── provenance + ├── agent briefs + └── canon interface cards +``` + +`InfoTechCanonCore` should be imported by every other standard. + +## 3.2 Knowledge Substrate Layer + +```text +InfoTechCanonInformationSpaceModel + imports: + - InfoTechCanonCore + - InfoTechCanonTaggingStandard + - InfoTechCanonDataModel + - InfoTechCanonGovernanceModel +``` + +The Information Space Model defines how standards and related artifacts become a retrievable, markdown-first, agent-usable infospace. + +## 3.3 Actor / Rule / World Triad + +```text +InfoTechCanonLandscapeModel + owns: systems, services, resources, runtime, infrastructure context + +InfoTechCanonOrganizationModel + owns: actors, roles, memberships, responsibility, authority, accountability + +InfoTechCanonGovernanceModel + owns: policies, rules, decisions, controls, risk, exceptions, evidence +``` + +This is the first conceptual triad: + +```text +Landscape = what exists. +Organization = who acts. +Governance = how action is directed and constrained. +``` + +## 3.4 Execution and Classification Layer + +```text +InfoTechCanonTaskModel + imports: + - Organization + - Governance + - Landscape + +InfoTechCanonTaggingStandard + imports: + - Task + - Core + - optionally Organization / Governance / Landscape for tag dimensions +``` + +Task turns systems, actors, and governance into actionable work. Tagging classifies and retrieves work and other entities. + +## 3.5 Control and Protection Layer + +```text +InfoTechCanonAccessControlModel + imports: + - Organization + - Governance + - Landscape + - Task + - Tagging + +InfoTechCanonSecurityModel + imports: + - Governance + - Access Control + - Landscape + - Task + - Data + - DevSecOps + - Network + - Observability +``` + +Access Control owns authorization semantics. Security owns adversarial and defensive security semantics. + +## 3.6 Information and Delivery Layer + +```text +InfoTechCanonDataModel + imports: + - Landscape + - Organization + - Governance + - Security + - Access Control + - Task + - Tagging + +InfoTechCanonDevSecOpsModel + imports: + - Landscape + - Organization + - Governance + - Task + - Security + - Access Control + - Data + - Observability +``` + +Data owns semantic data assets. DevSecOps owns secure delivery flow and evidence. + +## 3.7 Runtime Understanding Layer + +```text +InfoTechCanonNetworkModel + imports: + - Landscape + - Governance + - Security + - Access Control + - Data + - DevSecOps + - Observability + +InfoTechCanonObservabilityModel + imports: + - Landscape + - Organization + - Governance + - Task + - Security + - Access Control + - Data + - DevSecOps + - Network +``` + +Network owns communication and reachability. Observability owns signals and runtime understanding. + +--- + +# 4. Concept Ownership Map + +## 4.1 Core Owns Canon Machinery + +| Concept Family | Canonical Owner | +|---|---| +| Standard | Core | +| Concept | Core | +| RelationshipDefinition | Core | +| Pattern | Core | +| Profile | Core | +| Mapping | Core | +| Assimilation | Core | +| ValidationRule | Core | +| ConformanceLevel | Core | +| VersionRecord | Core | +| ProvenanceRecord | Core | +| AgentBrief | Core | +| CanonInterfaceCard | Core | + +## 4.2 Information Space Owns Knowledge Packaging + +| Concept Family | Canonical Owner | +|---|---| +| InformationSpace | Information Space | +| KnowledgeArtifact | Information Space | +| MarkdownDocument | Information Space | +| ConceptPage | Information Space | +| Chunk | Information Space | +| RetrievalUnit | Information Space | +| Index | Information Space | +| Link / Backlink | Information Space | +| Citation / SourceReference | Information Space | +| EmbeddingRecord | Information Space | +| RetrievalEvaluation | Information Space | + +## 4.3 Landscape Owns System Reality + +| Concept Family | Canonical Owner | +|---|---| +| BusinessService | Landscape | +| ApplicationService | Landscape | +| TechnicalService | Landscape | +| SoftwareSystem reference | Landscape / later Architecture | +| RuntimeResource | Landscape | +| Environment | Landscape | +| Workload | Landscape | +| Endpoint reference | Landscape / Network split | +| DeploymentRecord reference | Landscape / DevSecOps split | + +## 4.4 Organization Owns Actors and Responsibility + +| Concept Family | Canonical Owner | +|---|---| +| Person | Organization | +| Agent as organizational actor | Organization | +| Team | Organization | +| Organization | Organization | +| OrganizationalUnit | Organization | +| Role | Organization | +| Position | Organization | +| Membership | Organization | +| Responsibility | Organization | +| Authority | Organization | +| Accountability | Organization | +| Ownership / Stewardship | Organization | + +## 4.5 Governance Owns Rules and Assurance + +| Concept Family | Canonical Owner | +|---|---| +| Policy | Governance | +| Rule | Governance | +| Requirement | Governance | +| Obligation | Governance | +| Decision | Governance | +| Approval | Governance | +| ControlObjective | Governance | +| Control | Governance | +| Risk | Governance | +| Exception / Waiver | Governance | +| Evidence | Governance | +| Audit / Assurance | Governance | + +## 4.6 Task Owns Work + +| Concept Family | Canonical Owner | +|---|---| +| WorkItem | Task | +| Option | Task | +| Task | Task | +| Action / NextAction | Task | +| Step / Move | Task | +| Exploration / Experiment | Task | +| Commitment | Task | +| Blocker / Dependency | Task | +| WorkflowState | Task | +| Outcome / AcceptanceCriteria / DefinitionOfDone | Task | + +## 4.7 Tagging Owns Lightweight Classification + +| Concept Family | Canonical Owner | +|---|---| +| Tag | Tagging | +| TagDefinition | Tagging | +| TagScheme | Tagging | +| TagNamespace | Tagging | +| TagCategory | Tagging | +| TagAssignment | Tagging | +| TagProfile | Tagging | +| TagMapping | Tagging | +| TagValidationRule | Tagging | + +## 4.8 Access Control Owns Authorization + +| Concept Family | Canonical Owner | +|---|---| +| Subject | Access Control, as access-control subject view | +| Principal | Access Control | +| Resource as protected access target | Access Control / Landscape reference | +| Action as access operation | Access Control | +| Permission | Access Control | +| Privilege | Access Control | +| Entitlement | Access Control | +| Grant | Access Control | +| AccessRole | Access Control | +| RoleBinding | Access Control | +| AuthorizationRequest | Access Control | +| AuthorizationDecision | Access Control | +| PolicyEnforcementPoint | Access Control | +| AccessReview | Access Control / Governance reference | +| BreakGlassAccess | Access Control / Governance reference | + +## 4.9 Security Owns Adversarial and Defensive Semantics + +| Concept Family | Canonical Owner | +|---|---| +| Threat | Security | +| ThreatActor | Security | +| Weakness | Security | +| Vulnerability | Security | +| Exposure as security condition | Security / Network reference | +| SecurityFinding | Security | +| AttackPath | Security | +| Mitigation | Security | +| Detection | Security | +| SecurityIncident | Security | +| SecurityPosture | Security | + +## 4.10 Data Owns Data Semantics + +| Concept Family | Canonical Owner | +|---|---| +| DataDomain | Data | +| Dataset | Data | +| DataProduct | Data | +| Schema | Data | +| Field | Data | +| DataElement | Data | +| DataClassification | Data | +| DataLineage | Data | +| DataQualityRule | Data | +| DataContract | Data | +| ProcessingPurpose | Data | +| RetentionRuleReference | Data / Governance reference | + +## 4.11 DevSecOps Owns Delivery Flow + +| Concept Family | Canonical Owner | +|---|---| +| Repository as delivery source | DevSecOps / Information Space if knowledge repo | +| Commit | DevSecOps | +| PullRequest | DevSecOps | +| Pipeline | DevSecOps | +| PipelineRun | DevSecOps | +| TestRun / ScanRun | DevSecOps | +| ArtifactVersion | DevSecOps | +| SBOM | DevSecOps | +| Provenance / Attestation / Signature | DevSecOps | +| Release | DevSecOps | +| DeploymentExecution / DeploymentRecord | DevSecOps | +| DeploymentVerification | DevSecOps / Observability reference | + +## 4.12 Network Owns Communication Semantics + +| Concept Family | Canonical Owner | +|---|---| +| NetworkDomain | Network | +| Prefix / IPAddress / DNSRecord | Network | +| NetworkDevice | Network | +| Interface / Link / Path | Network | +| NetworkSegment / VLAN / VRF | Network | +| Route / RouteTable | Network | +| Endpoint as network surface | Network / Landscape reference | +| NetworkPolicy | Network | +| NetworkIntent | Network | +| NetworkFlow / ObservedFlow | Network / Observability reference | +| ReachabilityClaim | Network | +| Exposure as reachability condition | Network / Security reference | + +## 4.13 Observability Owns Signals + +| Concept Family | Canonical Owner | +|---|---| +| Telemetry | Observability | +| Metric | Observability | +| LogRecord | Observability | +| Trace / Span | Observability | +| Event as observability signal | Observability | +| Profile as runtime profile | Observability | +| AlertRule / Alert | Observability | +| SLI / SLO / ErrorBudget | Observability | +| HealthState | Observability | +| ObservedIncident | Observability / Task or ITSM reference | +| ObservabilityEvidence | Observability / Governance reference | + +--- + +# 5. CARING Fit in InfoTechCanon + +## 5.1 Summary + +The uploaded **CARING Standard — Canonical Access Roles for Information Needs Governance** fits well into InfoTechCanon as a **cross-domain access-governance standard**. + +It should not be absorbed entirely into `InfoTechCanonAccessControlModel`, because CARING has a stronger and more specific purpose: + +```text +CARING = orthogonal access-governance analysis and design standard +for information products and runtime platforms. +``` + +It belongs as a named standard/profile family: + +```text +standards/access-control/caring/ + InfoTechCanonCaringAccessGovernanceStandard.md +``` + +or: + +```text +standards/caring/ + CARING.md +``` + +Recommended canonical name inside InfoTechCanon: + +```text +InfoTechCanonCaringAccessGovernanceStandard +``` + +Recommended status: + +```text +external-user-originated standard candidate +or +internal specialized standard candidate +``` + +## 5.2 Why CARING Is Valuable + +CARING contributes a mature orthogonal decomposition for access governance. + +Its central insight is that a role is not enough. Effective access emerges from several independent dimensions: + +```text +Subject +Organization Relation +Canonical Role +Scope +Plane +Capability +Exposure Mode +Condition +Lifecycle State +Restriction +Exposure Event +``` + +This directly supports InfoTechCanon’s orthogonality principle. + +## 5.3 CARING as a Stress Test + +CARING should become one of the first benchmark standards for testing the kernel because it crosses many domains: + +```text +Organization: subject, relation, role, lifecycle responsibility. +Access Control: capability, permissions, grants, effective access. +Governance: restrictions, exposure events, lifecycle review, conditions. +Security: induced access, privilege escalation, secret exposure. +Data: exposure mode, plaintext, masked, synthetic, cross-tenant aggregate. +Network: scope, platform, cluster, namespace, runtime, reachability implications. +DevSecOps: CI/CD service accounts, build plane, release lifecycle, agents. +Observability: audit plane, logs, evidence, post-review. +Task: remediation, redesign, review work from CARING findings. +Tagging: classification of access descriptors and findings. +``` + +## 5.4 CARING Placement Options + +### Option A: Access Control Profile + +```text +InfoTechCanonAccessControlModel +└── profiles/ + └── caring-access-governance-profile.md +``` + +Pros: + +- lightweight integration, +- easy to use as a profile over access-control entities, +- good first step. + +Cons: + +- CARING is richer than a normal profile, +- it owns canonical role semantics that overlap with Organization, +- it includes governance and analysis process concepts. + +### Option B: Specialized Access-Governance Standard + +```text +InfoTechCanonCaringAccessGovernanceStandard +``` + +Pros: + +- preserves CARING as a coherent standard, +- respects its analytical and prescriptive modes, +- avoids forcing all CARING concepts into Access Control, +- allows CARING to import Access, Organization, Governance, Security, Data, DevSecOps, and Network. + +Cons: + +- adds another standard to the kernel, +- requires explicit ownership decisions. + +### Option C: Pattern Language Only + +CARING could be turned into patterns such as: + +```text +Role Is Not Permission +Declared vs Effective Access +Induced Access Analysis +Exposure Event +Tenant Isolation Boundary +Agent Capability Ceiling +``` + +Pros: + +- useful immediately. + +Cons: + +- loses the systematic descriptor model. + +## 5.5 Recommendation + +Use **Option B**. + +CARING should become a specialized standard under the Access/Governance cluster: + +```text +InfoTechCanonCaringAccessGovernanceStandard +``` + +It should import the kernel standards rather than redefine their generic concepts. + +The standard should be treated as: + +```text +a specialized orthogonal access-governance analysis standard +built on top of Core, Organization, Governance, Access Control, +Security, Data, DevSecOps, Network, Observability, Task, and Tagging. +``` + +--- + +# 6. CARING Concept Ownership and Import Map + +## 6.1 CARING Concepts That Should Remain Owned by CARING + +These are distinctive enough to be owned by CARING: + +```text +CARINGAccessDescriptor +CARINGCanonicalRole +OrganizationRelation as CARING access dimension +Plane as CARING access dimension +ExposureMode +ExposureEvent +DerivedCapability +InducedAccess +DeclaredAccessMap +EffectiveAccessMap +CapabilityProfileMap +RoleBundlingFinding +TenantBoundaryFinding +InducedAccessFinding +CARINGAnalysisFitnessTest +CARINGAnalysisProcedure +CARINGRedesignProcedure +``` + +## 6.2 CARING Concepts That Should Import from Organization + +| CARING Term | InfoTechCanon Owner | +|---|---| +| Subject as human/group/organization/service/agent/system/device/process | Access Control / Organization split | +| Human | Organization | +| Organization | Organization | +| Group | Organization / Access Control depending on use | +| Agent | Organization | +| Authority as actor | Organization / Governance | +| Lifecycle responsibility posture | Organization / CARING specialization | +| Vendor / Customer / Community / Consultant / ServiceProvider | Organization relation profile, owned by CARING as access-governance dimension | + +## 6.3 CARING Concepts That Should Import from Access Control + +| CARING Term | InfoTechCanon Owner | +|---|---| +| Subject as access subject | Access Control | +| Declared Access | Access Control / CARING specialization | +| Effective Access | Access Control / CARING specialization | +| Capability | Access Control | +| Capability Profile | Access Control / CARING specialization | +| Native Policy Object | Access Control | +| Access Assignment | Access Control | +| Restriction as deny effect | Access Control / Governance | +| Default Deny | Access Control | + +## 6.4 CARING Concepts That Should Import from Governance + +| CARING Term | InfoTechCanon Owner | +|---|---| +| Condition | Governance / Access Control depending on enforcement | +| Lifecycle review | Governance | +| Exposure Event review | Governance | +| Legal hold | Governance | +| Authority source | Governance | +| Approval | Governance | +| Post-review | Governance | +| Policy linting | Governance / Access Control | +| Conformance tests | Core / Governance | + +## 6.5 CARING Concepts That Should Import from Security + +| CARING Term | InfoTechCanon Owner | +|---|---| +| PrivilegeEscalationBlocked | Security / Access Control | +| X-Adversarial | Security | +| X-Misconfiguration | Security / Governance | +| X-InducedAccess | Security / CARING | +| X-PrivilegeEscalation | Security / CARING | +| SecretMaterial exposure risk | Security / Data / Access Control | +| Induced access as security finding | Security / CARING | + +## 6.6 CARING Concepts That Should Import from Data + +| CARING Term | InfoTechCanon Owner | +|---|---| +| Plaintext | Data / Security context | +| Masked | Data | +| Aggregated | Data | +| Synthetic | Data | +| Pseudonymous | Data | +| Encrypted | Security / Data | +| CrossTenantAggregate | Data / Governance | +| Field | Data | +| Dataset | Data | + +## 6.7 CARING Concepts That Should Import from DevSecOps + +| CARING Term | InfoTechCanon Owner | +|---|---| +| Build Plane | DevSecOps / CARING access plane | +| CI/CD Service as Builder | DevSecOps / Access Control | +| PipelineBound condition | DevSecOps / Governance / Access | +| DeploymentDeployer profile | DevSecOps / CARING | +| Agentic coding system | DevSecOps / Organization / Access | + +## 6.8 CARING Concepts That Should Import from Network + +| CARING Term | InfoTechCanon Owner | +|---|---| +| Cluster | Network / Landscape depending on context | +| Namespace | Network / Landscape / Platform context | +| Tenant boundary network implications | Network / Security / Access | +| Runtime Plane network exposure | Network / CARING | + +## 6.9 CARING Concepts That Should Import from Observability + +| CARING Term | InfoTechCanon Owner | +|---|---| +| Audit Plane evidence | Observability / Governance | +| Logged | Observability / Governance | +| Recorded | Observability / Governance | +| PostReviewRequired evidence | Governance / Observability | +| Access event evidence | Observability / Access Control | + +--- + +# 7. CARING-Driven Refactor Suggestions + +## 7.1 Access Control Model Should Add or Strengthen + +The Access Control seed should explicitly include: + +```text +DeclaredAccess +EffectiveAccess +DerivedCapability +InducedAccess +CapabilityProfile +NativePolicyObject +AccessDescriptor +ExposureModeReference +RestrictionPrecedence +``` + +Some of these should be imported or profiled from CARING rather than owned directly. + +## 7.2 Organization Model Should Add or Strengthen + +The Organization seed should strengthen: + +```text +ExternalOrganizationRelation +Vendor +Customer +Consultant +ServiceProvider +Distributor +Community +Authority +LifecycleResponsibilityRole +``` + +However, the CARING canonical roles should remain in CARING unless they prove broadly useful beyond access governance. + +## 7.3 Governance Model Should Add or Strengthen + +The Governance seed should strengthen: + +```text +ExceptionWorkflow +ExposureEventGovernance +PostEventReview +AuthoritySource +LifecycleAccessReview +AccessGovernanceControl +``` + +## 7.4 Security Model Should Add or Strengthen + +The Security seed should strengthen: + +```text +InducedAccessFinding +PrivilegeEscalationFinding +SecretExposureFinding +TenantBoundaryFinding +EffectiveAccessRisk +``` + +## 7.5 Data Model Should Add or Strengthen + +The Data seed should strengthen: + +```text +ExposureModeMapping +SecretMaterial +CrossTenantAggregate +MaskedData +SyntheticData +PseudonymousData +ExportableData +``` + +## 7.6 DevSecOps Model Should Add or Strengthen + +The DevSecOps seed should strengthen: + +```text +PipelineBoundAccess +CICDIdentity +AgenticBuildAccess +WorkloadCreationCapability +DeploymentCapabilityProfile +``` + +## 7.7 Network Model Should Add or Strengthen + +The Network seed should strengthen: + +```text +NamespaceAsScope +NamespaceNotTenantBoundary +ClusterScope +TenantBoundaryNetworkEvidence +``` + +## 7.8 Observability Model Should Add or Strengthen + +The Observability seed should strengthen: + +```text +AccessEvent +ExposureEventEvidence +AuditTrail +PostAccessReviewEvidence +SessionRecordingReference +``` + +--- + +# 8. Cross-Standard Import Matrix + +Legend: + +```text +O = owns concept +I = imports concept +R = references concept +P = profile / specialization +``` + +| Concept / Mechanism | Core | InfoSpace | Org | Gov | Task | Tag | Access | Sec | Data | DevSecOps | Net | Obs | CARING | +|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:| +| Concept ownership | O | I | I | I | I | I | I | I | I | I | I | I | I | +| Mapping | O | I | I | I | I | I | I | I | I | I | I | I | I | +| Assimilation | O | I | I | I | I | I | I | I | I | I | I | I | I | +| Actor | R | R | O | R | I | R | I | R | R | R | R | R | I | +| Subject | R | R | I | R | R | R | O | R | R | R | R | R | I/P | +| Role | R | R | O | R | R | R | I | R | R | R | R | R | P | +| AccessRole | R | R | R | R | R | R | O | R | R | R | R | R | I | +| CARINGCanonicalRole | R | R | I | R | R | R | I | R | R | R | R | R | O | +| Policy | R | R | R | O | I | R | I | I | I | I | I | I | I | +| Permission | R | R | R | R | R | R | O | R | R | R | R | R | I | +| Capability | R | R | R | R | R | R | O | R | R | R | R | R | P/O | +| ExposureMode | R | R | R | I | R | R | I | I | I | R | R | I | O | +| ExposureEvent | R | R | R | I | I | R | I | I | I | I | I | I | O | +| DeclaredAccess | R | R | R | R | R | R | O/P | I | R | R | R | R | P/O | +| EffectiveAccess | R | R | R | R | R | R | O/P | I | R | R | R | R | P/O | +| DerivedCapability | R | R | R | R | R | R | P | I | R | I | R | R | O | +| InducedAccess | R | R | R | R | R | R | P | I | R | I | R | R | O | +| Tenant | R | R | I | I | R | R | I | R | I | R | I | R | P | +| Namespace | R | R | R | R | R | R | R | R | R | R | O | R | I | +| AuditTrail | R | R | R | I | R | R | I | I | R | R | R | O/P | I | + +--- + +# 9. Kernel Boundary Tensions + +## 9.1 Role vs AccessRole vs CARINGCanonicalRole + +This is the most important boundary tension. + +Recommended distinction: + +```text +Organization Role + A pattern of responsibility, authority, participation, or behavior. + +AccessRole + A permission-bearing construct in an authorization model. + +CARINGCanonicalRole + A lifecycle responsibility posture used for access-governance analysis. +``` + +Rule: + +```text +Do not collapse these three. +``` + +## 9.2 Subject vs Actor vs Principal + +Recommended distinction: + +```text +Actor + An entity capable of action in organization or system context. + +Subject + The access-control view of an entity requesting or holding access. + +Principal + Identity-bearing subject recognized by an access-control system. +``` + +## 9.3 Plane vs Domain vs Layer + +CARING uses **Plane** as an access surface: Build, Runtime, Execution, Data, Identity, Policy, Secret, Audit, etc. + +InfoTechCanon already uses domains such as Data, Network, DevSecOps, Observability. + +Recommendation: + +```text +CARING Plane remains a CARING-owned access-governance dimension. +It may map to InfoTechCanon domains but should not replace them. +``` + +## 9.4 Exposure Mode vs Data Classification vs Security Exposure + +Recommended distinction: + +```text +ExposureMode + How much information becomes visible, usable, or extractable in an access context. + +DataClassification + Classification of data based on sensitivity, policy, or business meaning. + +Security Exposure + A security-relevant condition of reachability, discoverability, or access risk. +``` + +## 9.5 Scope vs ResourceScope vs Landscape Scope + +Recommended distinction: + +```text +CARING Scope + Access-governance boundary. + +Access ResourceScope + Authorization evaluation boundary. + +Landscape Scope + System/resource containment or operational boundary. +``` + +These may map, but should not be assumed identical. + +## 9.6 Tenant vs Namespace + +CARING’s warning that a namespace is not automatically a tenant boundary should be adopted as a kernel-wide rule. + +Recommended rule: + +```text +Namespace MAY support tenant isolation but MUST NOT be treated as a tenant boundary unless effective access, network, identity, secret, storage, policy, and controller behavior support that interpretation. +``` + +--- + +# 10. Shared Mechanisms to Extract into Core + +These sections currently appear repeatedly in seed standards and should be centralized in Core: + +```text +Mapping Model +Assimilation Hooks +Profile Format +Validation Rule Format +Conformance Levels +Repository Placement +Agent Brief Requirements +Canon Interface Card Usage +Artifact Statuses +Concept Statuses +Normative Language +Generated View Rules +Provenance Requirements +``` + +Domain standards should keep only domain-specific specializations. + +Example after refactor: + +```text +Instead of every standard defining mapping types, +Core defines mapping types. +A domain standard lists its mapping targets and domain-specific mapping examples. +``` + +--- + +# 11. First Kernel Refactoring Checklist + +## 11.1 Core Refactor + +- [ ] Move generic mapping type list to Core. +- [ ] Move assimilation stage model to Core. +- [ ] Move standard document profile to Core. +- [ ] Move generic conformance levels to Core. +- [ ] Move Canon Interface Card model to Core. +- [ ] Move agent brief model to Core. +- [ ] Move generic lifecycle statuses to Core. +- [ ] Create YAML schemas for core artifact types. + +## 11.2 Domain Standards Refactor + +For each standard: + +- [ ] Declare imports from Core. +- [ ] Declare owned concepts. +- [ ] Remove duplicated generic mechanism prose. +- [ ] Keep domain-specific mapping targets. +- [ ] Keep domain-specific profiles. +- [ ] Keep domain-specific validation rules. +- [ ] Add concept ownership references. +- [ ] Add `agent-brief.md`. +- [ ] Add `concepts/` extraction candidates. +- [ ] Add `mappings/` folder. +- [ ] Add `profiles/` folder. + +## 11.3 CARING Refactor + +- [ ] Create `InfoTechCanonCaringAccessGovernanceStandard.md`. +- [ ] Add namespace `itc-caring`. +- [ ] Create CARING concept ownership table. +- [ ] Map CARING dimensions to InfoTechCanon standards. +- [ ] Convert CARING examples into profiles or example artifacts. +- [ ] Add CARING benchmark corpus. +- [ ] Add CARING analysis output schema. +- [ ] Add CARING access descriptor schema. +- [ ] Add CARING conformance tests. + +--- + +# 12. Recommended Repository Layout + +```text +info-tech-canon/ + README.md + INTENT.md + SCOPE.md + canon.yaml + + core/ + InfoTechCanonCore.md + agent-brief.md + schemas/ + validation/ + + standards/ + information-space/ + landscape/ + organization/ + governance/ + task/ + tagging/ + access-control/ + caring/ + security/ + data/ + devsecops/ + network/ + observability/ + + patterns/ + core/ + integration/ + access-governance/ + agentic/ + production-readiness/ + + profiles/ + small-saas/ + kubernetes/ + github/ + gitlab/ + netbox/ + opentelemetry/ + caring/ + + mappings/ + external/ + archimate/ + csdm/ + skos/ + prov-o/ + dcat/ + nist-csf/ + rbac/ + abac/ + kubernetes/ + github/ + netbox/ + opentelemetry/ + slsa/ + caring/ + + assimilation/ + inbox/ + active/ + completed/ + + views/ + by-standard.md + by-concept.md + by-pattern.md + by-profile.md + by-mapping-target.md + by-status.md + dependency-graph.md + kernel-map.md + + agent/ + briefs/ + retrieval-index.md + common-mistakes.md + + examples/ + small-saas/ + kubernetes/ + agentic-workflow/ + caring-analysis/ +``` + +--- + +# 13. First Implementation Profiles + +## 13.1 Small SaaS Kernel Profile + +Purpose: + +```text +Minimal profile for a small SaaS platform moving toward production readiness. +``` + +Included standards: + +```text +Core +Information Space +Landscape +Organization +Governance +Task +Tagging +Access Control +CARING +Security +Data +DevSecOps +Network +Observability +``` + +Primary use cases: + +```text +service catalog +repository inventory +runtime inventory +basic governance +task tracking +access governance +security findings +data classification +delivery traceability +observability evidence +``` + +## 13.2 Kubernetes Production Readiness Profile + +Purpose: + +```text +Canonical profile for modeling Kubernetes-based production readiness. +``` + +Included standards: + +```text +Landscape +Organization +Governance +Access Control +CARING +Security +Data +DevSecOps +Network +Observability +``` + +Critical CARING test cases: + +```text +namespace not automatically tenant +workload creation induces service-account access +cluster-admin is compound maximum-authority profile +secret access is separate plane/exposure +CI/CD deployer is service/automation subject +``` + +## 13.3 Agentic Operations Profile + +Purpose: + +```text +Canonical profile for humans and agents collaborating in operational environments. +``` + +Included standards: + +```text +Organization +Task +Access Control +CARING +Security +DevSecOps +Observability +Governance +``` + +Critical CARING test cases: + +```text +agent capability ceiling +delegated vs induced access +agent output attribution +human supervision reference +tool access boundary +post-action review +``` + +## 13.4 Markdown Infospace Profile + +Purpose: + +```text +Canonical profile for the InfoTechCanon repository and related markdown-based infospaces. +``` + +Included standards: + +```text +Core +Information Space +Tagging +Governance +Task +DevSecOps +Observability +``` + +--- + +# 14. First Formal Assimilation Candidates + +The first formal assimilation candidates should be chosen to test different kernel mechanics. + +## 14.1 CARING Assimilation + +Reason: + +```text +Tests orthogonality, cross-standard import boundaries, specialized standard placement, +access governance, agent access, induced access, and benchmark-driven evolution. +``` + +Outputs: + +```text +CARING concept extraction +CARING-to-InfoTechCanon mapping +CARING access descriptor schema +CARING profile placement +CARING benchmark corpus +Access Control refactor proposals +Governance refactor proposals +Security refactor proposals +``` + +## 14.2 ServiceNow CSDM Assimilation + +Reason: + +```text +Tests Landscape, service, operational ownership, CMDB mapping, and external product model mapping. +``` + +## 14.3 Kubernetes Assimilation + +Reason: + +```text +Tests Landscape, Access Control, CARING, Security, DevSecOps, Network, Observability. +``` + +## 14.4 OpenTelemetry Assimilation + +Reason: + +```text +Tests Observability, Information Space retrieval, resource identity, and evidence mapping. +``` + +## 14.5 DCAT / PROV-O Assimilation + +Reason: + +```text +Tests Data, Information Space, provenance, catalog, and retrieval compatibility. +``` + +--- + +# 15. CARING as First Benchmark Corpus + +CARING explicitly proposes that standards evolve through concrete analysis challenges. This aligns strongly with InfoTechCanon assimilation. + +Recommended CARING benchmark folder: + +```text +standards/caring/benchmarks/ + lotus-domino-acl/ + kubernetes-rbac/ + github-repository-access/ + aws-iam/ + keycloak/ + linux-sudo/ + cicd-platform-permissions/ + agentic-workflow-permissions/ +``` + +Each benchmark should contain: + +```text +native-model-summary.md +native-concepts.yaml +caring-mapping.yaml +access-descriptors.yaml +declared-access-map.md +effective-access-map.md +derived-capabilities.md +induced-access-findings.md +restrictions.md +exposure-events.md +redesign-recommendations.md +open-questions.md +``` + +--- + +# 16. Kernel Validation Rules + +## 16.1 General + +```text +VAL-KERNEL-001: Every standard must declare owned concepts. + +VAL-KERNEL-002: Every cross-standard concept use should be either owned, imported, referenced, or mapped. + +VAL-KERNEL-003: Every profile must name the standards it implements. + +VAL-KERNEL-004: Every mapping must declare target body, target concept, mapping type, scope, confidence, and rationale. + +VAL-KERNEL-005: Every standard should have an agent brief. + +VAL-KERNEL-006: Every domain standard should import Core. + +VAL-KERNEL-007: Generated views must be marked as generated. + +VAL-KERNEL-008: Concepts with multiple apparent owners must create a boundary review item. +``` + +## 16.2 CARING-Specific + +```text +VAL-KERNEL-CARING-001: CARINGCanonicalRole must not be treated as Organization Role or AccessRole without mapping. + +VAL-KERNEL-CARING-002: CARING Plane must not be treated as identical to InfoTechCanon domain. + +VAL-KERNEL-CARING-003: CARING Scope must map to ResourceScope, Landscape scope, Data scope, or Governance scope explicitly. + +VAL-KERNEL-CARING-004: CARING ExposureMode must map to Data, Security, Access Control, or Governance semantics where relevant. + +VAL-KERNEL-CARING-005: CARING DerivedCapability and InducedAccess findings must map to Security and Access Control concepts. + +VAL-KERNEL-CARING-006: CARING ExposureEvents must map to Governance exception/review and Security/Observability evidence where relevant. + +VAL-KERNEL-CARING-007: CARING tenant-boundary claims must be checked against Access Control, Network, Security, Data, and Landscape models. + +VAL-KERNEL-CARING-008: CARING native role mappings must not assume that native role names mean canonical roles. +``` + +--- + +# 17. Known Open Questions + +## 17.1 Core + +```text +Should Core own Relationship as runtime graph edge, or only RelationshipDefinition? +Should generic Evidence remain in Governance or move to Core? +Should ProvenanceRecord stay in Core while Evidence stays in Governance? +Should CanonInterfaceCard be Core or Information Space? +``` + +Recommendation: + +```text +Core owns ProvenanceRecord and CanonInterfaceCard. +Governance owns Evidence as support for claims, controls, decisions, and assurance. +Information Space owns SourceReference and Citation as knowledge artifacts. +``` + +## 17.2 Access / CARING + +```text +Should DerivedCapability be owned by CARING or Access Control? +Should ExposureMode be CARING-owned or Data/Security-owned? +Should OrganizationRelation be CARING-owned or Organization-owned? +Should Plane be CARING-owned or Core-owned? +``` + +Recommendation: + +```text +CARING owns them as access-governance dimensions. +Other standards map/import as needed. +``` + +## 17.3 Architecture Gap + +A future `InfoTechCanonArchitectureModel` is likely needed. + +It should own: + +```text +ArchitectureView +ArchitectureDecision +ArchitectureConcern +Viewpoint +Component +Connector +ArchitecturePattern +SystemBoundary +RuntimeView +DeploymentView +``` + +But some of these are already partially represented in Landscape and Governance. This should wait until after the kernel map is stable. + +## 17.4 Pattern Language Gap + +A future `InfoTechCanonPatternLanguage` is needed. + +It should own the structure and evolution of pattern languages beyond the generic Pattern artifact in Core. + +--- + +# 18. Next Recommended Actions + +## 18.1 Immediate + +```text +1. Accept this Kernel Map as the first integration artifact. +2. Create the `standards/caring/` folder. +3. Convert uploaded CARING into `InfoTechCanonCaringAccessGovernanceStandard.md`. +4. Add `itc-caring` namespace. +5. Create `caring-mapping-to-kernel.md`. +6. Create `kernel-concept-ownership.yaml`. +``` + +## 18.2 Refactor Pass + +```text +1. Refactor InfoTechCanonLandscapeModel to import Core. +2. Refactor InfoTechCanonAccessControlModel to import CARING concepts where appropriate. +3. Refactor InfoTechCanonGovernanceModel to include exposure-event governance hooks. +4. Refactor InfoTechCanonSecurityModel to include induced-access findings. +5. Refactor InfoTechCanonDataModel to include exposure-mode mappings. +``` + +## 18.3 First Implementation + +```text +1. Create Small SaaS Kernel Profile. +2. Create Kubernetes Production Readiness Profile. +3. Create Agentic Operations Profile. +4. Use CARING to analyze Kubernetes RBAC as first benchmark. +``` + +--- + +# 19. Summary + +The first-generation InfoTechCanon kernel is now broad enough to support consolidation. + +The current standards cover: + +```text +canon machinery +knowledge space +landscape +organization +governance +work +tagging +access control +security +data +delivery +network +observability +``` + +The uploaded CARING standard fits best as a specialized access-governance standard: + +```text +InfoTechCanonCaringAccessGovernanceStandard +``` + +It should not be flattened into Access Control, because its orthogonal descriptor model crosses Organization, Governance, Access Control, Security, Data, DevSecOps, Network, Observability, Task, and Tagging. + +CARING is especially valuable because it provides: + +```text +orthogonal access dimensions +canonical lifecycle roles +declared vs effective access distinction +derived capability analysis +induced access analysis +tenant-boundary analysis +exposure modes +exposure events +analysis and redesign procedures +benchmark-driven evolution +``` + +This makes CARING an excellent first formal assimilation and benchmark corpus for testing whether InfoTechCanon can integrate a rich, user-originated standard without losing orthogonality. diff --git a/seeds/InfoTechCanonLandscapeModel_RC1_seed.md b/seeds/InfoTechCanonLandscapeModel_RC1_seed.md new file mode 100755 index 0000000..d0b9e5c --- /dev/null +++ b/seeds/InfoTechCanonLandscapeModel_RC1_seed.md @@ -0,0 +1,1938 @@ +# 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. diff --git a/seeds/InfoTechCanonNetworkModel_RC1_seed.md b/seeds/InfoTechCanonNetworkModel_RC1_seed.md new file mode 100755 index 0000000..5135222 --- /dev/null +++ b/seeds/InfoTechCanonNetworkModel_RC1_seed.md @@ -0,0 +1,2433 @@ +# InfoTechCanon Network Model + +**Short Name:** `ITC-NET` +**Document Status:** Seed Standard Release Candidate 1 +**Version:** RC1-seed +**Date:** 2026-05-23 +**Repository Context:** `info-tech-canon` +**Document Type:** InfoTechCanon Domain Standard +**Intended Audience:** Network architects, platform engineers, cloud engineers, security architects, SREs, DevSecOps teams, service owners, infrastructure operators, zero-trust designers, network automation engineers, knowledge-system builders, and agentic tooling. + +--- + +# 1. Purpose + +The **InfoTechCanon Network Model** defines a canonical seed model for representing networks, addressing, topology, connectivity, routing, policy, intent, reachability, flow, segmentation, exposure, and network state across physical, virtual, cloud, Kubernetes, service-mesh, hybrid, and zero-trust environments. + +It exists to prevent the network domain from being collapsed into generic infrastructure, security, or access-control models. + +This standard provides a canonical vocabulary for: + +- network domains, +- fabrics, +- sites, +- zones, +- segments, +- subnets, +- prefixes, +- addresses, +- DNS, +- devices, +- interfaces, +- links, +- circuits, +- paths, +- routes, +- route tables, +- peering, +- NAT, +- gateways, +- firewalls, +- load balancers, +- ingress, +- endpoints, +- flows, +- reachability, +- network policies, +- network intents, +- network configurations, +- network state, +- exposure, +- segmentation, +- and source-of-truth boundaries. + +--- + +# 2. Position in InfoTechCanon + +The Network Model is a **domain standard** within InfoTechCanon. + +It depends on the existing seed standards as follows: + +```text +Landscape = services, runtime resources, environments, infrastructure context. +Organization = network owners, operators, stewards, accountable teams. +Governance = network policies, controls, exceptions, evidence, reviews. +Task = network changes, incidents, remediation, review work. +Tagging = lightweight classification of network entities and policies. +Access Control = who may administer or use network resources. +Security = exposure, attack paths, segmentation, network findings. +Data = data movement, residency, data flows, data access patterns. +DevSecOps = network configuration as code, deployment, validation, evidence. +Network = addressing, topology, connectivity, routing, reachability, network policy, intent, and state. +``` + +```text +InfoTechCanon +├── InfoTechCanonCore +├── InfoTechCanonLandscapeModel +├── InfoTechCanonOrganizationModel +├── InfoTechCanonGovernanceModel +├── InfoTechCanonTaskModel +├── InfoTechCanonTaggingStandard +├── InfoTechCanonAccessControlModel +├── InfoTechCanonSecurityModel +├── InfoTechCanonDataModel +├── InfoTechCanonDevSecOpsModel +├── InfoTechCanonNetworkModel <-- this standard +├── InfoTechCanonObservabilityModel +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +--- + +# 3. Boundary with Adjacent Standards + +## 3.1 Boundary with Landscape + +The Landscape Model owns broad runtime and infrastructure context: + +```text +Environment +RuntimePlatform +RuntimeResource +ApplicationService +TechnicalService +Endpoint reference +DeploymentRecord +``` + +The Network Model owns network-specific structure and behavior: + +```text +NetworkDomain +NetworkFabric +NetworkSegment +Prefix +IPAddress +Interface +Link +Route +Path +Flow +NetworkPolicy +NetworkIntent +Exposure +Reachability +``` + +Boundary rule: + +```text +Landscape owns where systems live and how services relate. +Network owns how communication, addressing, routing, topology, policy, and reachability work. +``` + +## 3.2 Boundary with Security + +The Security Model owns: + +```text +Threat +ExposureFinding +AttackPath +SecurityFinding +Mitigation +SecurityIncident +``` + +The Network Model owns: + +```text +Exposure +Reachability +Path +Flow +NetworkPolicy +Segmentation +NetworkState +``` + +Security may analyze Network concepts to identify exposure, attack paths, and findings. + +## 3.3 Boundary with Access Control + +Access Control owns authorization semantics: + +```text +Subject +Permission +Privilege +Grant +AuthorizationDecision +AccessSession +``` + +Network owns connectivity semantics. + +Example: + +```text +Access Control determines whether a subject may administer a firewall rule. +Network determines what traffic the firewall rule permits or denies. +``` + +## 3.4 Boundary with Governance + +Governance owns policies, controls, exceptions, evidence, and reviews. + +Network owns network policy as technical traffic-control semantics while referencing governance policies as sources or constraints. + +Example: + +```text +Governance Policy: production databases must not be internet reachable. +Network Policy: deny inbound traffic to database segment except from application segment. +``` + +## 3.5 Boundary with Data + +Data owns semantic data flows, datasets, classification, residency, and processing purpose. + +Network owns technical packet/service flows and reachability paths. + +Boundary rule: + +```text +DataFlow describes movement of data meaning. +NetworkFlow describes communication between endpoints. +``` + +## 3.6 Boundary with DevSecOps + +DevSecOps owns delivery of network configuration, IaC, policy-as-code, tests, scans, and deployment records. + +Network owns the intended, declared, applied, and observed network model being delivered or changed. + +--- + +# 4. Research Basis and External Alignment + +This seed standard draws on multiple network-management and infrastructure bodies of knowledge. + +## 4.1 YANG and NETCONF/RESTCONF + +YANG provides a modeling language for network configuration data, state data, RPCs, and notifications. It is a central mapping target for network configuration and state models. + +## 4.2 Network Management Datastore Architecture + +NMDA distinguishes datastore viewpoints such as intended configuration and operational state. This strongly influences the InfoTechCanon Network State Model. + +## 4.3 IETF Network Topology Models + +RFC 8345 defines a generic YANG model for network and network topology concepts such as networks, nodes, links, and termination points. Layer-specific topology models extend this idea. + +## 4.4 Intent-Based Networking + +Intent-Based Networking clarifies the distinction between intent, policy, configuration, and network behavior. InfoTechCanon uses intent as an abstract desired network outcome, not as a synonym for policy. + +## 4.5 NetBox and Network Source of Truth + +NetBox-style source-of-truth practice emphasizes intended-state inventory, IPAM, DCIM, device/interface/cabling modeling, and automation integration. This informs the Network Inventory and Source-of-Truth patterns. + +## 4.6 Kubernetes NetworkPolicy and Cloud-Native Networking + +Kubernetes NetworkPolicy models ingress and egress traffic control for selected pods. Cloud-native networking introduces workload identity, ephemeral endpoints, service discovery, ingress controllers, network policies, service mesh, and overlay networking. + +## 4.7 Zero Trust Architecture + +Zero Trust shifts focus away from implicit trust in network location toward resource-centric protection, continuous verification, identity, context, least privilege, and policy enforcement close to resources. The Network Model must therefore support network segmentation without assuming that segment location alone establishes trust. + +## 4.8 Cloud Networking and Software-Defined Networking + +Cloud networking adds VPC/VNet, subnets, route tables, security groups, network ACLs, load balancers, private links, peering, gateways, NAT, transit networks, and managed DNS as first-class network objects. + +--- + +# 5. Seed Standard Design Stance + +This standard is a **seed standard**, not a vendor-specific network schema. + +It shall: + +1. define canonical network semantics, +2. distinguish inventory, addressing, topology, routing, policy, intent, flow, reachability, exposure, configuration, and state, +3. support physical, virtual, cloud, Kubernetes, service-mesh, and hybrid networks, +4. support intended, declared, applied, observed, historical, and assessed network state, +5. support network source-of-truth integration, +6. support network policy and intent without collapsing them, +7. support security exposure and zero-trust analysis, +8. map to external standards and tools without becoming subordinate to them, +9. remain markdown-first and agent-retrievable, +10. and support future assimilation of network standards, products, and operational practices. + +--- + +# 6. Scope + +## 6.1 In Scope + +This standard covers canonical representation of: + +- network domains, +- fabrics, +- sites, +- regions, +- zones, +- network segments, +- subnets, +- prefixes, +- IP addresses, +- DNS zones, +- DNS records, +- VLANs, +- VRFs, +- overlays, +- underlays, +- devices, +- routers, +- switches, +- firewalls, +- load balancers, +- gateways, +- WAFs, +- proxies, +- interfaces, +- ports, +- links, +- cables as references, +- circuits, +- paths, +- route tables, +- routes, +- BGP/peering references, +- NAT, +- service endpoints, +- ingress, +- egress, +- network flows, +- observed flows, +- reachability, +- exposure, +- network policy, +- firewall rules, +- ACLs, +- security groups, +- Kubernetes NetworkPolicies, +- service mesh policies, +- zero-trust network access references, +- network intent, +- network configuration, +- and network state. + +## 6.2 Out of Scope + +This standard does not fully define: + +- all packet formats, +- every routing protocol detail, +- full network-device configuration syntax, +- physical cabling/DCIM in complete detail, +- complete telecom resource modeling, +- complete SD-WAN vendor models, +- all firewall vendor rule models, +- full Kubernetes CNI implementation, +- all service mesh internals, +- all network telemetry metrics, +- or detailed network security incident response. + +Those may be mapped, assimilated, profiled, or handled by adjacent standards. + +--- + +# 7. 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 defined provisionally here but open to later refinement. +- **EXTRACT** marks a concept that may later move to a more specialized standard. + +--- + +# 8. Core Principles + +## 8.1 Network Is More Than Devices + +The network includes topology, addressing, routing, policy, reachability, flows, exposure, intent, and state. + +## 8.2 Addressing Is Not Topology + +An IP prefix or subnet is not the same thing as a physical, virtual, or logical topology. + +## 8.3 Policy Is Not Intent + +Intent describes desired outcomes. + +Policy expresses formal allowed, denied, required, or constrained behavior. + +Configuration implements policy or intent. + +Observed state shows what is actually happening. + +## 8.4 Declared State Is Not Observed State + +The model SHALL distinguish intended, declared, applied, observed, historical, and assessed network state. + +## 8.5 Reachability Is First-Class + +Whether one endpoint can reach another endpoint is a modelable fact or claim, not merely an inference hidden inside configuration. + +## 8.6 Exposure Is First-Class + +A reachable or discoverable surface matters even when no vulnerability is known. + +## 8.7 Source of Truth Must Be Explicit + +Profiles SHOULD declare source-of-truth boundaries for inventory, intended configuration, applied configuration, observed state, topology, and flows. + +## 8.8 Zero Trust Changes Network Assumptions + +Network segment membership alone SHOULD NOT be treated as sufficient trust. + +Resource, identity, policy, context, and access-control semantics may be needed. + +## 8.9 External Standards Are Mapped, Not Obeyed + +The Network Model MAY map to YANG, IETF topology models, NetBox, Kubernetes NetworkPolicy, cloud provider network models, firewall models, and zero-trust frameworks. + +It MUST NOT subordinate its internal semantics to any single external model. + +--- + +# 9. Canonical Seed Metadata + +Every network artifact SHOULD support structured metadata. + +Recommended front matter: + +```yaml +--- +id: itc-net:NetworkSegment +type: concept +standard: InfoTechCanonNetworkModel +standard_version: RC1-seed +status: candidate +canonical_owner: InfoTechCanonNetworkModel +preferred_label: Network Segment +related: + - itc-net:Subnet + - itc-net:NetworkZone + - itc-net:NetworkPolicy + - itc-sec:Exposure +mappings: + - itc-map:network-segment-to-netbox-vlan-prefix +--- +``` + +Recommended artifact statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +Recommended concept statuses: + +```text +proposed +experimental +candidate +canonical +deprecated +retired +``` + +--- + +# 10. Root Network Taxonomy + +```text +NetworkEntity +├── NetworkScopeEntity +│ ├── NetworkDomain +│ ├── NetworkFabric +│ ├── NetworkSite +│ ├── NetworkRegion +│ ├── NetworkZone +│ ├── TrustZoneReference +│ └── NetworkTenant +├── AddressingEntity +│ ├── AddressFamily +│ ├── Prefix +│ ├── Subnet +│ ├── IPAddress +│ ├── IPAllocation +│ ├── DNSZone +│ ├── DNSRecord +│ ├── Hostname +│ └── ServiceName +├── TopologyEntity +│ ├── NetworkNode +│ ├── NetworkDevice +│ ├── Router +│ ├── Switch +│ ├── Firewall +│ ├── Gateway +│ ├── LoadBalancer +│ ├── Proxy +│ ├── Interface +│ ├── Port +│ ├── Link +│ ├── Circuit +│ ├── Path +│ └── TerminationPoint +├── SegmentationEntity +│ ├── NetworkSegment +│ ├── VLAN +│ ├── VRF +│ ├── OverlayNetwork +│ ├── UnderlayNetwork +│ ├── SecurityZone +│ └── Microsegment +├── RoutingConnectivityEntity +│ ├── RouteTable +│ ├── Route +│ ├── NextHop +│ ├── Peering +│ ├── TransitGatewayReference +│ ├── NAT +│ ├── PrivateLinkReference +│ └── ConnectivityService +├── EndpointEntity +│ ├── Endpoint +│ ├── ServiceEndpoint +│ ├── IngressEndpoint +│ ├── EgressEndpoint +│ ├── PublicEndpoint +│ ├── PrivateEndpoint +│ ├── WorkloadEndpoint +│ └── ManagementEndpoint +├── PolicyIntentEntity +│ ├── NetworkIntent +│ ├── NetworkPolicy +│ ├── FirewallRule +│ ├── ACL +│ ├── SecurityGroup +│ ├── NetworkACL +│ ├── KubernetesNetworkPolicy +│ ├── ServiceMeshPolicy +│ └── TrafficPolicy +├── FlowReachabilityEntity +│ ├── NetworkFlow +│ ├── ObservedFlow +│ ├── AllowedFlow +│ ├── DeniedFlow +│ ├── ReachabilityClaim +│ ├── ReachabilityTest +│ ├── Exposure +│ └── AttackSurfaceReference +└── NetworkStateEntity + ├── NetworkConfiguration + ├── IntendedNetworkState + ├── DeclaredNetworkState + ├── AppliedNetworkState + ├── ObservedNetworkState + ├── HistoricalNetworkState + ├── AssessedNetworkState + ├── Drift + └── ReconciliationResult +``` + +--- + +# 11. Core Concepts + +## 11.1 NetworkEntity + +A **NetworkEntity** is any identifiable concept used to represent network structure, addressing, topology, connectivity, routing, policy, intent, reachability, flow, exposure, configuration, or state. + +Recommended attributes: + +```yaml +id: +entity_type: +canonical_name: +display_name: +lifecycle_state: +source_system: +created_at: +updated_at: +``` + +Optional attributes: + +```yaml +owner: +steward: +network_domain: +environment: +source_confidence: +valid_from: +valid_to: +tags: +external_references: +``` + +--- + +## 11.2 NetworkDomain + +A **NetworkDomain** is a bounded network scope with shared management, policy, addressing, routing, topology, or trust assumptions. + +Examples: + +```text +enterprise WAN +datacenter network +cloud VPC/VNet +Kubernetes cluster network +service mesh +tenant network +management network +partner network +``` + +--- + +## 11.3 NetworkFabric + +A **NetworkFabric** is a coordinated network substrate providing connectivity across nodes, devices, or workloads. + +Examples: + +```text +datacenter fabric +cloud fabric +SD-WAN fabric +service mesh fabric +Kubernetes overlay +``` + +--- + +## 11.4 NetworkSite + +A **NetworkSite** is a physical or logical site relevant to network deployment. + +Examples: + +```text +datacenter +office +edge location +cloud region site +branch +campus +``` + +--- + +## 11.5 NetworkRegion + +A **NetworkRegion** is a geographic, cloud, or provider region relevant to network placement, routing, residency, or operations. + +--- + +## 11.6 NetworkZone + +A **NetworkZone** is a logical or physical zone with shared policy, trust, exposure, routing, or segmentation assumptions. + +--- + +## 11.7 TrustZoneReference + +A **TrustZoneReference** is a reference to a trust or security zone concept. + +Security owns trust evaluation. Network owns the network zone and segmentation structure. + +--- + +## 11.8 NetworkTenant + +A **NetworkTenant** is a tenant-specific network scope. + +Examples: + +```text +customer tenant VPC +namespace-scoped network +project network +organization network +``` + +--- + +## 11.9 AddressFamily + +An **AddressFamily** identifies an addressing family. + +Examples: + +```text +IPv4 +IPv6 +MAC +DNS +URI +service identity +``` + +--- + +## 11.10 Prefix + +A **Prefix** is an address range. + +Examples: + +```text +10.0.0.0/24 +2001:db8::/32 +``` + +--- + +## 11.11 Subnet + +A **Subnet** is a logical subdivision of an address space, usually associated with routing, placement, and policy. + +Canonical rule: + +```text +Subnet SHOULD NOT be treated as identical to SecurityZone. +``` + +--- + +## 11.12 IPAddress + +An **IPAddress** is an address assigned, reserved, observed, or available within an address family and prefix. + +--- + +## 11.13 IPAllocation + +An **IPAllocation** is the assignment or reservation of an IP address or prefix to an entity. + +--- + +## 11.14 DNSZone + +A **DNSZone** is an administrative namespace for DNS records. + +--- + +## 11.15 DNSRecord + +A **DNSRecord** maps a name to an address, alias, service, or other DNS data. + +--- + +## 11.16 Hostname + +A **Hostname** is a network name assigned to a host, endpoint, or service. + +--- + +## 11.17 ServiceName + +A **ServiceName** is a name used to discover or address a service. + +--- + +## 11.18 NetworkNode + +A **NetworkNode** is an entity participating in a network topology. + +Examples: + +```text +router +switch +firewall +host +virtual appliance +gateway +workload +service-mesh proxy +cloud network object +``` + +--- + +## 11.19 NetworkDevice + +A **NetworkDevice** is a physical or virtual device primarily responsible for network functions. + +--- + +## 11.20 Router + +A **Router** is a network node that forwards traffic between networks based on routing information. + +--- + +## 11.21 Switch + +A **Switch** is a network node that forwards traffic within a layer-2 domain or switching fabric. + +--- + +## 11.22 Firewall + +A **Firewall** is a network node or policy enforcement function controlling traffic according to rules or policy. + +--- + +## 11.23 Gateway + +A **Gateway** is a network node or service that connects networks, protocols, zones, or domains. + +Examples: + +```text +internet gateway +NAT gateway +API gateway +transit gateway +VPN gateway +service mesh gateway +``` + +--- + +## 11.24 LoadBalancer + +A **LoadBalancer** distributes traffic across backend endpoints or services. + +--- + +## 11.25 Proxy + +A **Proxy** intermediates network communication. + +Examples: + +```text +forward proxy +reverse proxy +service mesh sidecar +egress proxy +identity-aware proxy +``` + +--- + +## 11.26 Interface + +An **Interface** is a physical, virtual, or logical network attachment point of a node. + +--- + +## 11.27 Port + +A **Port** is a physical or logical interface endpoint or protocol-level transport port, depending on profile. + +Profiles MUST distinguish device port from transport port where both occur. + +--- + +## 11.28 Link + +A **Link** is a direct or modeled connection between termination points, interfaces, nodes, or segments. + +--- + +## 11.29 Circuit + +A **Circuit** is a provider or transport connectivity service between sites, networks, or endpoints. + +--- + +## 11.30 Path + +A **Path** is a sequence of nodes, links, hops, segments, or policies through which traffic may or does travel. + +--- + +## 11.31 TerminationPoint + +A **TerminationPoint** is a point on a network node where links terminate. + +This concept maps naturally to IETF topology models. + +--- + +## 11.32 NetworkSegment + +A **NetworkSegment** is a bounded logical or physical portion of a network with shared connectivity or policy assumptions. + +Examples: + +```text +VLAN +subnet +microsegment +service mesh scope +security group domain +namespace network +``` + +--- + +## 11.33 VLAN + +A **VLAN** is a layer-2 segmentation construct. + +--- + +## 11.34 VRF + +A **VRF** is a routing table or routing context allowing multiple routing domains to coexist. + +--- + +## 11.35 OverlayNetwork + +An **OverlayNetwork** is a virtual network built over another network. + +--- + +## 11.36 UnderlayNetwork + +An **UnderlayNetwork** is the lower-level network providing connectivity for an overlay. + +--- + +## 11.37 SecurityZone + +A **SecurityZone** is a zone defined by security policy, exposure, control, or trust assumptions. + +Security owns security posture; Network owns segmentation mechanics. + +--- + +## 11.38 Microsegment + +A **Microsegment** is a small policy-enforced segment, often based on workload, identity, label, or service context. + +--- + +## 11.39 RouteTable + +A **RouteTable** is a set of routes used to determine forwarding or reachability. + +--- + +## 11.40 Route + +A **Route** is a forwarding rule mapping destination prefixes or conditions to next hops or actions. + +--- + +## 11.41 NextHop + +A **NextHop** is the next network node, gateway, interface, or target for a route. + +--- + +## 11.42 Peering + +**Peering** is a connectivity relationship between networks or routing domains. + +--- + +## 11.43 NAT + +**NAT** is address or port translation between network scopes. + +--- + +## 11.44 ConnectivityService + +A **ConnectivityService** is a service that provides connectivity. + +Examples: + +```text +VPN +private link +transit network +leased line +SD-WAN service +service mesh connectivity +``` + +--- + +## 11.45 Endpoint + +An **Endpoint** is an addressable or reachable network surface for a resource, service, workload, or device. + +--- + +## 11.46 ServiceEndpoint + +A **ServiceEndpoint** is an endpoint representing a service. + +--- + +## 11.47 IngressEndpoint + +An **IngressEndpoint** is an endpoint through which traffic enters a scope. + +--- + +## 11.48 EgressEndpoint + +An **EgressEndpoint** is an endpoint through which traffic leaves a scope. + +--- + +## 11.49 PublicEndpoint + +A **PublicEndpoint** is reachable from a public or external network scope. + +Public does not necessarily mean unauthenticated. + +--- + +## 11.50 PrivateEndpoint + +A **PrivateEndpoint** is reachable only from defined private or internal network scopes. + +Private does not automatically mean trusted. + +--- + +## 11.51 WorkloadEndpoint + +A **WorkloadEndpoint** is an endpoint associated with a workload, pod, container, VM, function, or service instance. + +--- + +## 11.52 ManagementEndpoint + +A **ManagementEndpoint** is an endpoint used for administration, configuration, monitoring, or maintenance. + +Management endpoints SHOULD be treated as sensitive. + +--- + +## 11.53 NetworkIntent + +A **NetworkIntent** is a declarative desired outcome for network behavior or properties, without specifying all implementation details. + +Examples: + +```text +Production databases must not be reachable from the internet. +Service A may call Service B over HTTPS. +All management endpoints require private administrative access. +EU tenant traffic must remain in EU regions. +``` + +Canonical rule: + +```text +NetworkIntent MUST NOT be treated as identical to NetworkPolicy or NetworkConfiguration. +``` + +--- + +## 11.54 NetworkPolicy + +A **NetworkPolicy** is a formal statement of allowed, denied, required, or constrained network behavior. + +Examples: + +```text +allow ingress from frontend to backend on TCP 443 +deny egress from database subnet to internet +allow pod selector app=api to connect to pod selector app=db on port 5432 +``` + +--- + +## 11.55 FirewallRule + +A **FirewallRule** is a traffic-control rule implemented by a firewall or firewall-like enforcement point. + +--- + +## 11.56 ACL + +An **ACL** is an access-control list controlling traffic or resource access. + +In the Network Model, ACL refers to network traffic control unless mapped otherwise. + +--- + +## 11.57 SecurityGroup + +A **SecurityGroup** is a cloud or platform traffic-control construct associated with resources or interfaces. + +--- + +## 11.58 NetworkACL + +A **NetworkACL** is a network-level access-control list, often associated with subnets or network boundaries. + +--- + +## 11.59 KubernetesNetworkPolicy + +A **KubernetesNetworkPolicy** is a Kubernetes policy controlling ingress and/or egress traffic for selected pods. + +--- + +## 11.60 ServiceMeshPolicy + +A **ServiceMeshPolicy** is a policy controlling service-to-service traffic, often involving identity, mTLS, routing, authorization, or telemetry. + +--- + +## 11.61 TrafficPolicy + +A **TrafficPolicy** controls routing, splitting, retry, timeout, failover, mirroring, or other traffic-management behavior. + +--- + +## 11.62 NetworkFlow + +A **NetworkFlow** is a modeled communication relation from source to destination using protocol, port, service, or application context. + +Recommended attributes: + +```yaml +source: +destination: +protocol: +port: +direction: +purpose: +state_context: +``` + +--- + +## 11.63 ObservedFlow + +An **ObservedFlow** is a flow detected from telemetry, logs, traces, packet data, flow records, or runtime observation. + +--- + +## 11.64 AllowedFlow + +An **AllowedFlow** is a flow permitted by policy or configuration. + +--- + +## 11.65 DeniedFlow + +A **DeniedFlow** is a flow denied by policy, configuration, or enforcement. + +--- + +## 11.66 ReachabilityClaim + +A **ReachabilityClaim** is an assertion that one entity can or cannot reach another entity under defined conditions. + +Reachability claims SHOULD include state context and evidence where possible. + +--- + +## 11.67 ReachabilityTest + +A **ReachabilityTest** is an execution or analysis used to determine reachability. + +Examples: + +```text +ping +TCP connect +synthetic transaction +path analysis +firewall simulation +cloud reachability analyzer +service mesh test +``` + +--- + +## 11.68 Exposure + +**Exposure** is a condition where an endpoint, service, network path, or resource is reachable, discoverable, or accessible from a relevant source scope. + +Exposure can be intended, unintended, public, private, partner-facing, management-only, or internal. + +--- + +## 11.69 AttackSurfaceReference + +An **AttackSurfaceReference** points to security analysis of exposed network surfaces. + +Security owns attack surface and attack path analysis; Network owns exposure and reachability facts. + +--- + +## 11.70 NetworkConfiguration + +A **NetworkConfiguration** is a declared, applied, or observed set of network settings. + +--- + +## 11.71 IntendedNetworkState + +**IntendedNetworkState** is the network state intended by architecture, design, policy, intent, or source of truth. + +--- + +## 11.72 DeclaredNetworkState + +**DeclaredNetworkState** is network state declared in configuration, IaC, manifests, controller input, or device configuration sources. + +--- + +## 11.73 AppliedNetworkState + +**AppliedNetworkState** is network state accepted and applied by a network device, controller, cloud control plane, Kubernetes CNI, firewall, or service mesh. + +--- + +## 11.74 ObservedNetworkState + +**ObservedNetworkState** is network state inferred or measured from runtime observation. + +--- + +## 11.75 HistoricalNetworkState + +**HistoricalNetworkState** is network state that was true or asserted at a past time. + +--- + +## 11.76 AssessedNetworkState + +**AssessedNetworkState** is derived from analysis, verification, risk assessment, exposure analysis, or compliance evaluation. + +--- + +## 11.77 Drift + +**Drift** is divergence between intended, declared, applied, observed, or assessed state. + +--- + +## 11.78 ReconciliationResult + +A **ReconciliationResult** records the result of comparing and reconciling different state views. + +--- + +# 12. Core Relationship Vocabulary + +Recommended root relationship types: + +```text +contains +part_of +assigned_to +allocated_to +resolves_to +routes_to +forwards_to +connected_to +terminates_at +attached_to +belongs_to +peered_with +translated_by +exposes +reachable_from +reachable_to +permits +denies +requires +implements +realizes +configured_by +applied_to +observed_as +drifts_from +verified_by +evidenced_by +maps_to +``` + +Relationship records SHOULD support: + +```yaml +id: +relationship_type: +source_entity: +target_entity: +scope: +state_context: +valid_from: +valid_to: +source_system: +confidence: +evidence: +rationale: +``` + +--- + +# 13. Network State Model + +## 13.1 State Contexts + +Required network state contexts: + +```text +intended +declared +applied +observed +historical +assessed +``` + +## 13.2 Configuration States + +```text +draft +declared +validated +applied +partially_applied +failed +rolled_back +superseded +retired +``` + +## 13.3 Reachability States + +```text +unknown +intended_allowed +intended_denied +declared_allowed +declared_denied +observed_allowed +observed_denied +conflicting +indeterminate +``` + +## 13.4 Exposure States + +```text +unknown +not_exposed +internal_exposed +partner_exposed +public_exposed +management_exposed +unintended_exposure +accepted_exposure +mitigated_exposure +``` + +## 13.5 Drift States + +```text +no_drift +declared_vs_applied_drift +intended_vs_declared_drift +applied_vs_observed_drift +policy_vs_observed_drift +unresolved_drift +accepted_drift +``` + +--- + +# 14. Network Patterns + +## 14.1 Pattern: Intent-Policy-Configuration-State Split + +**Context:** Network automation or governance requires clarity about what should happen and what is happening. + +**Problem:** Teams confuse intent, policy, configuration, and observed state. + +**Solution:** + +```text +NetworkIntent + -> NetworkPolicy + -> NetworkConfiguration + -> AppliedNetworkState + -> ObservedNetworkState + -> AssessedNetworkState +``` + +--- + +## 14.2 Pattern: Source-of-Truth Boundary + +**Context:** Multiple tools hold network data. + +**Problem:** Inventory, configuration, telemetry, and policy tools disagree. + +**Solution:** Declare source-of-truth boundaries. + +Example: + +```text +NetBox owns intended IPAM/DCIM inventory. +Git owns declared network configuration. +Cloud control plane owns applied cloud network state. +Flow logs own observed flows. +Reachability analyzer owns assessed reachability. +``` + +--- + +## 14.3 Pattern: Addressing Is Not Security + +**Context:** Private IP ranges or internal subnets are treated as trusted. + +**Problem:** Address space does not establish trust. + +**Solution:** Model subnet, security zone, access policy, identity, and exposure separately. + +--- + +## 14.4 Pattern: Endpoint Exposure Trace + +**Context:** A service is reachable from somewhere. + +**Problem:** Teams cannot explain why exposure exists. + +**Solution:** + +```text +ServiceEndpoint + -> IPAddress / DNSRecord + -> LoadBalancer / Ingress + -> Route / SecurityGroup / FirewallRule + -> NetworkPath + -> Exposure + -> SecurityFinding or AcceptedExposure +``` + +--- + +## 14.5 Pattern: Workload Flow to Policy + +**Context:** Workloads need to communicate. + +**Problem:** Policies are written without observed traffic or intended service relationships. + +**Solution:** + +```text +ApplicationService dependency + -> Intended NetworkFlow + -> NetworkPolicy + -> ObservedFlow + -> ReachabilityTest + -> Drift or Verification +``` + +--- + +## 14.6 Pattern: Management Plane Isolation + +**Context:** Management interfaces are highly sensitive. + +**Problem:** Management endpoints are accidentally reachable from broad scopes. + +**Solution:** Mark ManagementEndpoint explicitly and apply stricter policy, access-control, monitoring, and exposure validation. + +--- + +## 14.7 Pattern: Network Drift Reconciliation + +**Context:** Declared configuration and observed network behavior diverge. + +**Problem:** Teams cannot know whether the source of truth, controller, device, or observation is wrong. + +**Solution:** Compare intended, declared, applied, and observed state and create ReconciliationResult with evidence and owner. + +--- + +## 14.8 Pattern: Reachability as Evidence + +**Context:** Compliance or security review requires proof that traffic is blocked or allowed. + +**Problem:** Configuration alone is not enough evidence. + +**Solution:** Use ReachabilityTest and ObservedFlow evidence to support allowed/denied claims. + +--- + +## 14.9 Pattern: Zero Trust Overlay + +**Context:** Network location is insufficient for security. + +**Problem:** Teams rely on internal network segments for trust. + +**Solution:** Combine NetworkPolicy, Access Control, identity, resource context, endpoint exposure, and continuous verification. + +--- + +# 15. Network Profiles + +## 15.1 Profile Format + +A Network Profile SHALL declare: + +```yaml +id: +profile_name: +status: +implements: + - InfoTechCanonNetworkModel +target_context: +included_concepts: +required_relationships: +required_metadata: +state_model: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +--- + +## 15.2 Seed Profile: Small SaaS Network Profile + +Purpose: + +```text +Provide a minimal network model for a small SaaS platform moving toward production readiness. +``` + +Included concepts: + +```text +NetworkDomain +NetworkZone +Subnet +Prefix +IPAddress +DNSRecord +Endpoint +PublicEndpoint +PrivateEndpoint +IngressEndpoint +EgressEndpoint +LoadBalancer +NetworkPolicy +SecurityGroup +RouteTable +Route +Exposure +ReachabilityClaim +ObservedFlow +``` + +Required relationships: + +```text +Endpoint assigned_to IPAddress +DNSRecord resolves_to Endpoint +Endpoint part_of NetworkZone +SecurityGroup permits NetworkFlow +SecurityGroup denies NetworkFlow +RouteTable routes_to NextHop +PublicEndpoint exposes Service +ReachabilityClaim evidenced_by ReachabilityTest +``` + +--- + +## 15.3 Seed Profile: NetBox Source-of-Truth Profile + +Purpose: + +```text +Map NetBox-style IPAM/DCIM/source-of-truth concepts into InfoTechCanon Network. +``` + +Example mappings: + +```text +Site -> NetworkSite +Region -> NetworkRegion +Tenant -> NetworkTenant +Device -> NetworkDevice +Interface -> Interface +Cable -> Link / PhysicalLinkReference +Prefix -> Prefix +IPAddress -> IPAddress +VLAN -> VLAN / NetworkSegment +VRF -> VRF +Circuit -> Circuit +Provider Network -> ConnectivityService +``` + +Known deviations: + +```text +NetBox represents intended source-of-truth state, not necessarily observed runtime state. +NetBox does not directly enforce network behavior. +Observed flows and applied device state require additional sources. +``` + +--- + +## 15.4 Seed Profile: Kubernetes Network Profile + +Purpose: + +```text +Represent Kubernetes networking concepts and policies. +``` + +Example mappings: + +```text +Cluster -> NetworkDomain / RuntimePlatformReference +Namespace -> NetworkZone / ResourceScope +Pod IP -> IPAddress +Service -> ServiceEndpoint +Ingress -> IngressEndpoint / PublicEndpoint or PrivateEndpoint +NetworkPolicy -> KubernetesNetworkPolicy +Pod selector -> EndpointSelector +Namespace selector -> ScopeSelector +Ingress rule -> AllowedFlow +Egress rule -> AllowedFlow +``` + +Known deviations: + +```text +Kubernetes NetworkPolicy support depends on the CNI provider. +A Kubernetes Service is not always equivalent to an external endpoint. +Pod IPs are often ephemeral. +``` + +--- + +## 15.5 Seed Profile: Cloud Network Profile + +Purpose: + +```text +Represent cloud VPC/VNet networking across providers. +``` + +Included concepts: + +```text +NetworkDomain +VPCReference +VNetReference +Subnet +RouteTable +Route +SecurityGroup +NetworkACL +InternetGatewayReference +NAT +LoadBalancer +PrivateEndpoint +Peering +TransitGatewayReference +DNSZone +PublicEndpoint +Exposure +``` + +Mapping targets: + +```text +AWS VPC +Azure VNet +Google Cloud VPC +Cloudflare network services +``` + +--- + +## 15.6 Seed Profile: Service Mesh Network Profile + +Purpose: + +```text +Represent service-to-service communication, mesh gateways, traffic policies, and mTLS-aware networking. +``` + +Included concepts: + +```text +ServiceMesh +Proxy +WorkloadEndpoint +ServiceEndpoint +TrafficPolicy +ServiceMeshPolicy +IngressGateway +EgressGateway +AllowedFlow +ObservedFlow +ReachabilityClaim +``` + +Mapping targets: + +```text +Istio +Linkerd +Consul Connect +Envoy +Gateway API +``` + +--- + +## 15.7 Seed Profile: Zero Trust Network Profile + +Purpose: + +```text +Represent resource-centric network protection with identity, context, and continuous verification. +``` + +Included concepts: + +```text +ProtectedResourceReference +NetworkIntent +NetworkPolicy +Endpoint +Exposure +AccessControlReference +IdentityContextReference +DeviceContextReference +ReachabilityClaim +PolicyEnforcementPointReference +``` + +Required relationships: + +```text +NetworkIntent protects ProtectedResourceReference +AccessControlReference constrains Reachability +NetworkPolicy permits NetworkFlow +ReachabilityClaim evidenced_by TestOrObservation +Exposure assessed_by SecurityModel +``` + +--- + +## 15.8 Seed Profile: Network-as-Code Profile + +Purpose: + +```text +Represent network configuration delivered through Git, IaC, controllers, and automation. +``` + +Included concepts: + +```text +NetworkConfiguration +DeclaredNetworkState +PipelineReference +ChangeRequestReference +AppliedNetworkState +Drift +ReconciliationResult +ValidationEvidence +``` + +Mapping targets: + +```text +Terraform +Ansible +Pulumi +Crossplane +Kubernetes manifests +vendor controllers +``` + +--- + +# 16. Mapping Model for the Network Standard + +Mappings relate InfoTechCanon network concepts to external standards, tools, and products. + +## 16.1 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +regulatoryReference +toolEquivalent +``` + +## 16.2 Mapping Record + +Example: + +```yaml +id: itc-map:network-topology-to-rfc8345 +source_concept: itc-net:NetworkTopology +target_body: IETF RFC 8345 +target_version: "2018" +target_concept: network / network-topology +mapping_type: closeMatch +scope: + - generic topology modeling +not_valid_for: + - all IPAM/DCIM inventory + - all security policy semantics +rationale: > + RFC 8345 provides a generic YANG topology model with networks, nodes, + links, and termination points. InfoTechCanon extends the semantic context + to include intent, policy, exposure, reachability, and source-of-truth boundaries. +confidence: high +status: candidate +owner: InfoTechCanonNetworkModel +``` + +## 16.3 Seed Mapping Targets + +The Network Model SHOULD maintain mappings to: + +```text +YANG / RFC 7950 +NMDA / RFC 8342 +Network topology / RFC 8345 +Intent-Based Networking / RFC 9315 +NetBox IPAM/DCIM +Kubernetes NetworkPolicy +Kubernetes Gateway API +AWS VPC +Azure VNet +Google Cloud VPC +Cloudflare network services +Terraform provider network resources +Ansible network modules +Cisco NSO concepts +OpenConfig YANG models +BGP / routing model references +Istio / Envoy / service mesh concepts +NIST Zero Trust Architecture +``` + +--- + +# 17. Assimilation Hooks + +The Network Model SHALL be able to receive new network standards, product models, cloud schemas, and operational practices through the InfoTechCanon assimilation process. + +## 17.1 Assimilation Triggers + +Assimilation may be triggered by: + +```text +new network source-of-truth tool +new cloud networking model +new network configuration standard +new firewall policy model +new service mesh model +new Kubernetes networking feature +new zero-trust network pattern +new network automation framework +new reachability analysis product +new recurring network classification conflict +``` + +## 17.2 Network Assimilation Output + +A network assimilation SHOULD produce: + +```text +source summary +extracted network concepts +concept comparison matrix +gap list +conflict list +mapping file +candidate new concepts +candidate relationship changes +candidate pattern changes +candidate profile changes +open questions +``` + +## 17.3 Recommended First Assimilation Candidates + +```text +NetBox data model +RFC 8345 network topology +RFC 8342 NMDA +RFC 9315 intent-based networking +Kubernetes NetworkPolicy +Kubernetes Gateway API +AWS VPC +Azure VNet +Google Cloud VPC +Istio traffic and authorization policy +OpenConfig YANG models +NIST SP 800-207 Zero Trust Architecture +``` + +--- + +# 18. Integration with Other InfoTechCanon Standards + +## 18.1 Landscape Model + +Network connects to Landscape through: + +```text +Environment +RuntimePlatform +Workload +Service +Endpoint +DataStore +DeploymentRecord +TechnicalService +``` + +## 18.2 Organization Model + +Network imports organization concepts for: + +```text +network owner +network steward +operator +responsible team +approver +incident responder +``` + +## 18.3 Governance Model + +Network imports governance concepts for: + +```text +network policy source +control objective +exception +evidence +review +approval +change decision +``` + +## 18.4 Task Model + +Network creates or references tasks such as: + +```text +network change task +firewall review task +reachability investigation +drift remediation task +exposure remediation task +incident task +``` + +## 18.5 Tagging Standard + +Network uses tags for: + +```text +environment +zone +segment +owner +exposure level +criticality +network domain +policy class +``` + +Tags must not replace network entities, policies, or relationships. + +## 18.6 Access Control Model + +Network imports access concepts for: + +```text +network administration permission +management endpoint access +zero-trust access decision +policy enforcement point +``` + +## 18.7 Security Model + +Security imports network concepts for: + +```text +exposure +attack path +reachability +network segmentation +observed flow +management endpoint +public endpoint +``` + +## 18.8 Data Model + +Data imports network concepts for: + +```text +data flow transport +data residency path +data egress +cross-border transfer evidence +``` + +## 18.9 DevSecOps Model + +DevSecOps imports network concepts for: + +```text +network configuration as code +policy as code +network validation +deployment of network changes +drift detection +``` + +## 18.10 Observability Model + +Observability should later import or map: + +```text +flow logs +packet telemetry +DNS logs +network metrics +reachability tests +latency +loss +error rate +``` + +--- + +# 19. Canon Interface Card Usage + +Subsystems that implement or produce network knowledge SHOULD publish a Canon Interface Card. + +Example: + +```yaml +subsystem: netbox-importer +implements: + - InfoTechCanonNetworkModel + - NetBoxSourceOfTruthProfile +produces: + - NetworkSite + - NetworkDevice + - Interface + - Prefix + - IPAddress + - VLAN + - VRF + - Circuit +consumes: + - Team + - Environment +relations: + - IPAddress assigned_to Interface + - Prefix part_of NetworkDomain + - Interface connected_to Interface +source_of_truth: + intended_ipam: NetBox + intended_dci_inventory: NetBox +known_deviations: + - does not represent observed flows + - does not guarantee applied device configuration +``` + +--- + +# 20. Retrieval Requirements + +The Network Model is designed for markdown-based infospaces. + +## 20.1 Required Retrieval Properties + +Every major concept SHOULD provide: + +- stable heading, +- stable identifier, +- short definition, +- longer explanation, +- examples, +- distinction notes, +- relationship examples, +- mapping hooks, +- profile references, +- and common mistakes. + +## 20.2 Agent Brief + +A mature Network Model SHOULD include an `agent-brief.md` file with: + +```text +purpose +scope +owned concepts +imported concepts +core distinctions +do / do not rules +relationship patterns +minimal examples +common mistakes +profile list +mapping list +``` + +## 20.3 Indexes + +The network information space SHOULD provide indexes by: + +```text +concept +relationship +network domain +addressing +topology +segment +policy +route +endpoint +flow +exposure +state context +profile +pattern +mapping target +status +source system +``` + +--- + +# 21. Conformance Levels + +## 21.1 Reference-Conformant + +A document or system is reference-conformant if it uses Network Model terminology consistently but does not implement structured metadata or validation rules. + +## 21.2 Metadata-Conformant + +A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types. + +## 21.3 Inventory-Conformant + +A system is inventory-conformant if it represents network domains, sites, devices, interfaces, prefixes, IP addresses, and segments. + +## 21.4 Topology-Conformant + +A system is topology-conformant if it represents nodes, interfaces, links, paths, and termination points. + +## 21.5 Policy-Conformant + +A system is policy-conformant if it represents network policies, firewall rules, security groups, ACLs, or equivalent traffic-control constructs. + +## 21.6 State-Conformant + +A system is state-conformant if it distinguishes intended, declared, applied, observed, historical, and assessed network state. + +## 21.7 Reachability-Conformant + +A system is reachability-conformant if it represents reachability claims, tests, observed flows, allowed flows, denied flows, and evidence. + +## 21.8 Profile-Conformant + +A system is profile-conformant if it implements a declared Network Profile and passes its validation rules. + +## 21.9 Assimilation-Conformant + +A system or repository is assimilation-conformant if it can accept external network concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes. + +--- + +# 22. Validation Rules + +Initial validation rules: + +```text +VAL-NET-001: NetworkIntent, NetworkPolicy, NetworkConfiguration, and ObservedNetworkState SHOULD be modeled as distinct concepts. + +VAL-NET-002: Prefix, Subnet, VLAN, VRF, NetworkSegment, and SecurityZone SHOULD NOT be used interchangeably without a profile mapping. + +VAL-NET-003: IPAddress SHOULD reference Prefix or allocation scope where available. + +VAL-NET-004: DNSRecord SHOULD reference the endpoint, address, or service name it resolves to where available. + +VAL-NET-005: Interface SHOULD reference its parent node or device. + +VAL-NET-006: Link SHOULD connect termination points, interfaces, or nodes. + +VAL-NET-007: Route SHOULD declare destination and next hop or action where available. + +VAL-NET-008: NetworkPolicy SHOULD declare subject/source, destination, action, protocol/port/service, and direction where applicable. + +VAL-NET-009: KubernetesNetworkPolicy SHOULD distinguish ingress and egress semantics. + +VAL-NET-010: ReachabilityClaim SHOULD declare source, destination, protocol/service context, state context, and evidence where available. + +VAL-NET-011: Exposure SHOULD declare source scope, target endpoint, and exposure type where available. + +VAL-NET-012: PublicEndpoint SHOULD NOT imply unauthenticated access. + +VAL-NET-013: PrivateEndpoint SHOULD NOT imply trusted access. + +VAL-NET-014: ManagementEndpoint SHOULD be classified as sensitive unless explicitly justified otherwise. + +VAL-NET-015: Network drift SHOULD identify which state views diverge. + +VAL-NET-016: Source-of-truth assumptions SHOULD be explicit in every mature profile. + +VAL-NET-017: Tags MUST NOT replace network policy, topology, addressing, or reachability relationships. + +VAL-NET-018: Imported external network concepts SHOULD be represented through mapping records rather than silently reused. + +VAL-NET-019: Profiles MUST NOT redefine canonical concepts. They may constrain them. + +VAL-NET-020: Network security analysis SHOULD reference Security Model concepts rather than embedding full security semantics here. +``` + +--- + +# 23. Anti-Patterns + +## 23.1 Subnet Equals Trust + +Treating subnet membership as proof of trust. + +## 23.2 Private Equals Safe + +Assuming private endpoints are safe without access control, policy, monitoring, or context. + +## 23.3 Policy Equals Intent + +Using low-level rules as if they explain the desired outcome. + +## 23.4 Configuration Equals Reality + +Assuming declared configuration describes actual network behavior. + +## 23.5 Topology Without State + +Modeling links and devices without knowing intended, applied, or observed state. + +## 23.6 Firewall Rule Graveyard + +Accumulating rules without owner, purpose, evidence, review, or expiry. + +## 23.7 Source-of-Truth Confusion + +Letting NetBox, cloud APIs, devices, Git, and telemetry all claim authority over the same facts without boundaries. + +## 23.8 Public Exposure by Accident + +Publishing endpoints without explicit exposure classification or review. + +## 23.9 Flow Logs Without Model + +Collecting observed flows without linking them to services, policies, endpoints, and reachability claims. + +## 23.10 Tool-Native Capture + +Letting a cloud provider, firewall vendor, or Kubernetes CNI define the internal network model. + +--- + +# 24. Initial Repository Placement + +Recommended repository layout: + +```text +info-tech-canon/ + standards/ + network/ + InfoTechCanonNetworkModel.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +Seed files: + +```text +standards/network/InfoTechCanonNetworkModel.md +standards/network/agent-brief.md +standards/network/concepts/network-domain.md +standards/network/concepts/prefix.md +standards/network/concepts/ip-address.md +standards/network/concepts/network-segment.md +standards/network/concepts/endpoint.md +standards/network/concepts/network-policy.md +standards/network/concepts/network-intent.md +standards/network/concepts/reachability-claim.md +standards/network/concepts/exposure.md +standards/network/patterns/intent-policy-configuration-state-split.md +standards/network/patterns/source-of-truth-boundary.md +standards/network/patterns/endpoint-exposure-trace.md +standards/network/patterns/network-drift-reconciliation.md +standards/network/profiles/small-saas-network-profile.md +standards/network/profiles/netbox-source-of-truth-profile.md +standards/network/profiles/kubernetes-network-profile.md +standards/network/profiles/cloud-network-profile.md +standards/network/profiles/zero-trust-network-profile.md +standards/network/mappings/yang.yaml +standards/network/mappings/nmda.yaml +standards/network/mappings/rfc8345-topology.yaml +standards/network/mappings/netbox.yaml +standards/network/mappings/kubernetes-networkpolicy.yaml +``` + +--- + +# 25. Roadmap + +## Phase 1: Seed Stabilization + +- Establish this standard as `InfoTechCanonNetworkModel`. +- Add seed concepts, relationship vocabulary, patterns, and profiles. +- Define validation rules. +- Align with Landscape, Security, Access Control, Governance, Data, DevSecOps, Task, and Tagging. + +## Phase 2: First Assimilations + +Recommended first assimilations: + +```text +NetBox data model +RFC 7950 YANG +RFC 8342 NMDA +RFC 8345 network topology +RFC 9315 intent-based networking +Kubernetes NetworkPolicy +Kubernetes Gateway API +AWS VPC +Azure VNet +Google Cloud VPC +Istio / Envoy service mesh networking +NIST SP 800-207 Zero Trust Architecture +``` + +## Phase 3: Profile Maturation + +- Mature Small SaaS Network Profile. +- Mature NetBox Source-of-Truth Profile. +- Mature Kubernetes Network Profile. +- Mature Cloud Network Profile. +- Mature Service Mesh Network Profile. +- Mature Zero Trust Network Profile. +- Mature Network-as-Code Profile. + +## Phase 4: Tooling Integration + +- Generate concept indexes. +- Generate agent brief. +- Create machine-readable YAML/JSON exports. +- Add validation scripts. +- Integrate NetBox, cloud APIs, Kubernetes APIs, network-policy repositories, flow logs, reachability tests, and security posture tools. + +## Phase 5: Network Intelligence Loop + +- Connect intended network state to declared configuration. +- Connect declared configuration to applied state. +- Connect applied state to observed flows. +- Connect observed flows to reachability claims. +- Connect exposure to security findings. +- Connect drift to remediation tasks. +- Connect policies to governance evidence. +- Connect topology to landscape service dependencies. + +--- + +# 26. Summary + +The InfoTechCanon Network Model is the seed standard for representing network addressing, topology, connectivity, routing, policy, intent, reachability, exposure, segmentation, and state. + +Its most important commitments are: + +```text +Separate addressing, topology, routing, policy, intent, configuration, state, flow, reachability, and exposure. + +Treat intended, declared, applied, observed, historical, and assessed network state as distinct. + +Support physical, virtual, cloud, Kubernetes, service-mesh, hybrid, and zero-trust network contexts. + +Use source-of-truth boundaries to prevent tool conflicts. + +Model reachability and exposure as first-class concepts. + +Map to YANG, NMDA, IETF topology models, NetBox, Kubernetes NetworkPolicy, cloud networking, +service meshes, and Zero Trust without surrendering internal semantic autonomy. + +Use profiles to make the model practical for SaaS systems, NetBox, Kubernetes, cloud networks, +service mesh, zero-trust design, and network-as-code workflows. +``` + +This makes the Network Model a core seed for production readiness, security posture, cloud-native architecture, reachability analysis, network automation, and interoperable infrastructure knowledge. diff --git a/seeds/InfoTechCanonObservabilityModel_RC1_seed.md b/seeds/InfoTechCanonObservabilityModel_RC1_seed.md new file mode 100755 index 0000000..4d08450 --- /dev/null +++ b/seeds/InfoTechCanonObservabilityModel_RC1_seed.md @@ -0,0 +1,2272 @@ +# InfoTechCanon Observability Model + +**Short Name:** `ITC-OBS` +**Document Status:** Seed Standard Release Candidate 1 +**Version:** RC1-seed +**Date:** 2026-05-23 +**Repository Context:** `info-tech-canon` +**Document Type:** InfoTechCanon Domain Standard +**Intended Audience:** SREs, platform engineers, DevSecOps teams, service owners, observability engineers, incident responders, network operators, security analysts, product owners, governance designers, knowledge-system builders, and agentic tooling. + +--- + +# 1. Purpose + +The **InfoTechCanon Observability Model** defines a canonical seed model for representing telemetry, signals, events, logs, metrics, traces, profiles, health, service levels, alerts, incidents as observed phenomena, dashboards, runbooks, investigations, and operational evidence. + +It exists to make runtime understanding interoperable across systems, services, platforms, networks, security, delivery pipelines, data products, and agentic operations. + +This standard provides a canonical vocabulary for: + +- telemetry sources, +- resources, +- signals, +- metrics, +- logs, +- events, +- traces, +- spans, +- profiles, +- exemplars, +- attributes, +- dimensions, +- correlation context, +- service level indicators, +- service level objectives, +- error budgets, +- health states, +- alerts, +- notifications, +- incidents, +- investigations, +- dashboards, +- runbooks, +- observability evidence, +- and feedback loops. + +--- + +# 2. Position in InfoTechCanon + +The Observability Model is a **domain standard** within InfoTechCanon. + +It depends on the existing seed standards as follows: + +```text +Landscape = services, runtime resources, environments, endpoints, workloads. +Organization = owners, on-call actors, responders, teams, accountable roles. +Governance = policies, controls, evidence, reviews, assurance, obligations. +Task = incident work, remediation work, investigation, follow-up tasks. +Tagging = lightweight classification of signals, alerts, incidents, dashboards. +Access Control = access to telemetry, dashboards, logs, admin actions, incident tools. +Security = security signals, detections, alerts, incidents, forensic evidence. +Data = telemetry as data, retention, classification, quality, lineage. +DevSecOps = deployment events, delivery metrics, verification, change failures. +Network = flow logs, reachability tests, network metrics, DNS logs, latency. +Observability = signals, telemetry, correlation, health, SLOs, alerts, operational evidence. +``` + +```text +InfoTechCanon +├── InfoTechCanonCore +├── InfoTechCanonLandscapeModel +├── InfoTechCanonOrganizationModel +├── InfoTechCanonGovernanceModel +├── InfoTechCanonTaskModel +├── InfoTechCanonTaggingStandard +├── InfoTechCanonAccessControlModel +├── InfoTechCanonSecurityModel +├── InfoTechCanonDataModel +├── InfoTechCanonDevSecOpsModel +├── InfoTechCanonNetworkModel +├── InfoTechCanonObservabilityModel <-- this standard +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +--- + +# 3. Boundary with Adjacent Standards + +## 3.1 Boundary with Landscape + +The Landscape Model owns the entities being observed: + +```text +ApplicationService +TechnicalService +RuntimeWorkload +Environment +Endpoint +NetworkEntity +DataStore +DeploymentRecord +``` + +The Observability Model owns telemetry and signals about those entities: + +```text +Metric +LogRecord +Trace +Span +Event +Profile +Alert +HealthState +SLI +SLO +Dashboard +IncidentSignal +``` + +Boundary rule: + +```text +Landscape owns what exists. +Observability owns what is observed, measured, correlated, alerted, and evidenced. +``` + +## 3.2 Boundary with Security + +The Security Model owns security interpretation: + +```text +SecurityFinding +Detection +SecurityIncident +Threat +AttackPath +SecurityEvidence +``` + +Observability owns telemetry substrate and operational signals. + +Example: + +```text +LogRecord may be evidence for SecurityFinding. +SecurityDetection may be derived from ObservabilitySignal. +SecurityIncident may reference Alert, Trace, LogRecord, or Event. +``` + +## 3.3 Boundary with Governance + +Governance owns policies, controls, evidence, reviews, assurance, and compliance claims. + +Observability provides evidence and indicators. + +Example: + +```text +SLOEvidence supports ServiceReview. +Metric supports ControlResult. +AlertPolicy implements Governance Policy. +``` + +## 3.4 Boundary with Task + +Task owns work semantics. + +Observability creates or references tasks: + +```text +Alert creates IncidentTask +Incident creates RemediationTask +Investigation creates FollowUpTask +SLOBurn creates ReliabilityTask +``` + +## 3.5 Boundary with DevSecOps + +DevSecOps owns delivery events and deployment records. + +Observability owns runtime signals used to verify deployments and measure change impact. + +Example: + +```text +DeploymentRecord produces DeploymentEvent +DeploymentHealthSignal verifies DeploymentRecord +ChangeFailure detected_by ObservabilitySignal +``` + +## 3.6 Boundary with Data + +Data owns dataset, classification, lineage, quality, and retention semantics. + +Observability telemetry may itself be data, but Observability owns telemetry-specific semantics. + +Example: + +```text +LogDataset classified_as Restricted +MetricStream has_retention RetentionRuleReference +TraceSample derived_from RuntimeWorkload +``` + +--- + +# 4. Research Basis and External Alignment + +This seed standard draws on several mature observability and operations bodies of knowledge. + +## 4.1 OpenTelemetry + +OpenTelemetry provides a broad observability framework covering traces, metrics, logs, baggage, resources, semantic conventions, instrumentation, collection, and export. Its semantic conventions define common attributes that give meaning to telemetry across systems. + +## 4.2 SRE and Service Level Objectives + +SRE practice distinguishes Service Level Indicators, Service Level Objectives, Service Level Agreements, and error budgets. It emphasizes that SLOs should measure user-relevant reliability and guide operational decision-making. + +## 4.3 Prometheus and OpenMetrics + +Prometheus and OpenMetrics influence metric naming, metric exposition, labels, time series, counters, gauges, histograms, summaries, and scraping/pull-based metric collection. + +## 4.4 CloudEvents + +CloudEvents standardizes common event metadata for interoperability across services, platforms, and systems. It is a strong mapping target for event structure and routing metadata. + +## 4.5 IT Operations and Incident Management + +IT operations practice distinguishes alerts, incidents, problems, changes, runbooks, on-call, escalation, resolution, and post-incident review. The Observability Model provides signal semantics while Task and Governance own work and decision semantics. + +## 4.6 AIOps and Event Correlation + +AIOps practice emphasizes correlation, anomaly detection, event deduplication, root-cause analysis, topology-aware alerting, and automated remediation. These are advanced profiles rather than mandatory core concepts. + +--- + +# 5. Seed Standard Design Stance + +This standard is a **seed standard**, not a vendor-specific observability schema. + +It shall: + +1. define canonical observability semantics, +2. distinguish telemetry, signal, event, log, metric, trace, span, profile, alert, and incident, +3. support OpenTelemetry alignment without being limited to it, +4. support SLOs, SLIs, and error budgets, +5. support correlation across services, runtime, network, security, data, and delivery, +6. support operational evidence and feedback loops, +7. support human and agentic operations, +8. map to external standards and tools without becoming subordinate to them, +9. remain markdown-first and agent-retrievable, +10. and support future assimilation of observability tools, standards, and practices. + +--- + +# 6. Scope + +## 6.1 In Scope + +This standard covers canonical representation of: + +- telemetry, +- telemetry sources, +- observed resources, +- observability signals, +- metrics, +- time series, +- metric points, +- metric instruments, +- logs, +- log records, +- events, +- event envelopes, +- traces, +- spans, +- span links, +- trace context, +- profiles, +- exemplars, +- attributes, +- dimensions, +- labels, +- correlation context, +- service-level indicators, +- service-level objectives, +- service-level agreements as references, +- error budgets, +- burn rates, +- health states, +- alert rules, +- alerts, +- notifications, +- alert routes, +- incidents as observed operational objects, +- investigations, +- dashboards, +- runbooks, +- telemetry pipelines, +- collectors, +- exporters, +- sampling, +- retention, +- and observability evidence. + +## 6.2 Out of Scope + +This standard does not fully define: + +- all monitoring tool schemas, +- all incident-management process details, +- all SRE organizational practice, +- complete AIOps algorithms, +- all logging formats, +- all SIEM detection content, +- full OpenTelemetry SDK implementation, +- all Prometheus query semantics, +- complete data-retention law, +- complete security incident-response methodology, +- or every vendor-specific telemetry backend. + +Those may be mapped, assimilated, profiled, or handled by adjacent standards. + +--- + +# 7. 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 defined provisionally here but open to later refinement. +- **EXTRACT** marks a concept that may later move to a more specialized standard. + +--- + +# 8. Core Principles + +## 8.1 Observability Is More Than Monitoring + +Monitoring checks known conditions. + +Observability supports understanding system behavior, including unknown or emergent failure modes, through signals and correlation. + +## 8.2 Telemetry Is Not Insight + +Raw telemetry becomes useful through context, correlation, aggregation, interpretation, and action. + +## 8.3 Signal Is Not Incident + +A signal, alert, or event may indicate a possible problem. + +An incident is an operationally relevant situation requiring response. + +## 8.4 Alert Is Not Evidence by Itself + +An alert indicates that a rule fired or condition was detected. + +Evidence should include the underlying signals, query, thresholds, state, and context. + +## 8.5 Metrics, Logs, Traces, Events, and Profiles Are Distinct + +Each signal type has different strengths and should not be collapsed into one generic “event” concept. + +## 8.6 Service Levels Must Be Explicit + +SLIs, SLOs, and error budgets SHOULD be modeled explicitly when reliability is important. + +## 8.7 Correlation Requires Identity + +Telemetry SHOULD be linked to canonical landscape entities, deployment records, network endpoints, data resources, or security entities where possible. + +## 8.8 Observability Must Support Feedback + +Observability should feed tasks, incidents, governance reviews, deployment verification, security detection, reliability improvement, and standard evolution. + +## 8.9 External Standards Are Mapped, Not Obeyed + +The Observability Model MAY map to OpenTelemetry, Prometheus, OpenMetrics, CloudEvents, SRE SLO concepts, ITIL incident practices, and vendor schemas. + +It MUST NOT subordinate its internal semantics to any single external model. + +--- + +# 9. Canonical Seed Metadata + +Every observability artifact SHOULD support structured metadata. + +Recommended front matter: + +```yaml +--- +id: itc-obs:Metric +type: concept +standard: InfoTechCanonObservabilityModel +standard_version: RC1-seed +status: candidate +canonical_owner: InfoTechCanonObservabilityModel +preferred_label: Metric +related: + - itc-obs:TimeSeries + - itc-obs:SLI + - itc-obs:AlertRule +mappings: + - itc-map:metric-to-opentelemetry-metric +--- +``` + +Recommended artifact statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +Recommended concept statuses: + +```text +proposed +experimental +candidate +canonical +deprecated +retired +``` + +--- + +# 10. Root Observability Taxonomy + +```text +ObservabilityEntity +├── TelemetryEntity +│ ├── Telemetry +│ ├── TelemetrySource +│ ├── ObservedResource +│ ├── ResourceAttribute +│ ├── Signal +│ ├── SignalSource +│ └── TelemetryPipeline +├── MetricEntity +│ ├── Metric +│ ├── MetricInstrument +│ ├── TimeSeries +│ ├── MetricPoint +│ ├── Counter +│ ├── Gauge +│ ├── Histogram +│ ├── Summary +│ └── Exemplar +├── LogEntity +│ ├── Log +│ ├── LogRecord +│ ├── LogStream +│ ├── LogLevel +│ ├── LogContext +│ └── StructuredLogField +├── TraceEntity +│ ├── Trace +│ ├── Span +│ ├── SpanEvent +│ ├── SpanLink +│ ├── TraceContext +│ ├── Baggage +│ └── TraceSample +├── EventEntity +│ ├── Event +│ ├── EventEnvelope +│ ├── EventSource +│ ├── EventType +│ ├── EventConsumer +│ └── EventCorrelationKey +├── ProfileEntity +│ ├── Profile +│ ├── ProfilingSample +│ ├── ResourceProfile +│ └── PerformanceProfile +├── ReliabilityEntity +│ ├── SLI +│ ├── SLO +│ ├── SLAReference +│ ├── ErrorBudget +│ ├── BurnRate +│ ├── HealthState +│ └── AvailabilityWindow +├── AlertingEntity +│ ├── AlertRule +│ ├── Alert +│ ├── Notification +│ ├── AlertRoute +│ ├── AlertSuppression +│ ├── AlertCorrelation +│ └── EscalationReference +├── OperationsEntity +│ ├── ObservedIncident +│ ├── Investigation +│ ├── Timeline +│ ├── Runbook +│ ├── Dashboard +│ ├── OperationalView +│ └── PostIncidentObservation +└── EvidenceEntity + ├── ObservabilityEvidence + ├── Query + ├── QueryResult + ├── Snapshot + ├── Annotation + ├── Correlation + └── RootCauseHypothesis +``` + +--- + +# 11. Core Concepts + +## 11.1 ObservabilityEntity + +An **ObservabilityEntity** is any identifiable concept used to represent telemetry, signals, correlation, health, service levels, alerts, incidents as observed phenomena, dashboards, runbooks, or operational evidence. + +Recommended attributes: + +```yaml +id: +entity_type: +canonical_name: +display_name: +lifecycle_state: +source_system: +created_at: +updated_at: +``` + +Optional attributes: + +```yaml +owner: +steward: +observed_resource: +service: +environment: +source_confidence: +valid_from: +valid_to: +tags: +external_references: +``` + +--- + +## 11.2 Telemetry + +**Telemetry** is machine-generated or manually recorded operational data about system behavior, state, performance, events, or activity. + +Examples: + +```text +metric sample +log record +trace span +event +profile sample +flow record +health check result +``` + +--- + +## 11.3 TelemetrySource + +A **TelemetrySource** is a system, component, agent, collector, service, device, pipeline, or actor that emits or provides telemetry. + +--- + +## 11.4 ObservedResource + +An **ObservedResource** is the entity about which telemetry is emitted or collected. + +Observed resources SHOULD map to Landscape, Network, Data, Security, or DevSecOps entities where possible. + +--- + +## 11.5 ResourceAttribute + +A **ResourceAttribute** is an attribute describing an observed resource. + +Examples: + +```text +service.name +service.version +deployment.environment +host.name +cloud.region +k8s.cluster.name +container.image.name +``` + +--- + +## 11.6 Signal + +A **Signal** is an interpretable unit or stream of observability data. + +Signal types include: + +```text +metric +log +trace +event +profile +alert +health check +synthetic result +``` + +--- + +## 11.7 SignalSource + +A **SignalSource** is the origin of a signal. + +--- + +## 11.8 TelemetryPipeline + +A **TelemetryPipeline** is a flow that collects, processes, transforms, samples, enriches, routes, stores, or exports telemetry. + +--- + +## 11.9 Metric + +A **Metric** is a measurement of a system, service, resource, or process over time. + +Metrics may be used for alerting, dashboards, SLOs, capacity planning, anomaly detection, and evidence. + +--- + +## 11.10 MetricInstrument + +A **MetricInstrument** defines the kind of measurement instrument. + +Seed instrument types: + +```text +counter +gauge +histogram +summary +up_down_counter +observable_gauge +``` + +--- + +## 11.11 TimeSeries + +A **TimeSeries** is a sequence of metric points over time for a metric and a set of dimensions or labels. + +--- + +## 11.12 MetricPoint + +A **MetricPoint** is a single measurement value at a time. + +--- + +## 11.13 Counter + +A **Counter** is a monotonically increasing measurement of occurrences or accumulated quantity. + +--- + +## 11.14 Gauge + +A **Gauge** is a measurement that can go up or down. + +--- + +## 11.15 Histogram + +A **Histogram** is a distribution of measurements across buckets or ranges. + +--- + +## 11.16 Summary + +A **Summary** is a metric representation of observations including quantiles or summary statistics. + +--- + +## 11.17 Exemplar + +An **Exemplar** is a representative sample connecting an aggregate metric point to a trace, log, or other detailed signal. + +--- + +## 11.18 Log + +A **Log** is a stream or collection of timestamped records describing events, state, actions, or messages. + +--- + +## 11.19 LogRecord + +A **LogRecord** is a single log entry. + +Recommended attributes: + +```yaml +timestamp: +severity: +message: +body: +resource: +trace_id: +span_id: +attributes: +source: +``` + +--- + +## 11.20 LogStream + +A **LogStream** is a sequence of log records from a source or resource. + +--- + +## 11.21 LogLevel + +A **LogLevel** is a severity or importance category for log records. + +Examples: + +```text +trace +debug +info +warn +error +fatal +``` + +--- + +## 11.22 LogContext + +**LogContext** is contextual metadata attached to log records. + +Examples: + +```text +request id +trace id +user id reference +tenant id +deployment version +environment +component +``` + +--- + +## 11.23 Trace + +A **Trace** is a representation of a request, transaction, workflow, or operation as it moves through a distributed system. + +--- + +## 11.24 Span + +A **Span** is a single timed operation within a trace. + +Recommended attributes: + +```yaml +trace_id: +span_id: +parent_span_id: +name: +kind: +start_time: +end_time: +status: +attributes: +events: +links: +``` + +--- + +## 11.25 SpanEvent + +A **SpanEvent** is a timestamped event attached to a span. + +--- + +## 11.26 SpanLink + +A **SpanLink** connects a span to another span or trace context. + +--- + +## 11.27 TraceContext + +**TraceContext** is propagation metadata that links operations across process, service, or network boundaries. + +--- + +## 11.28 Baggage + +**Baggage** is contextual metadata propagated across process boundaries. + +Baggage SHOULD be governed carefully when it may contain sensitive data. + +--- + +## 11.29 TraceSample + +A **TraceSample** is a selected trace or subset of trace data retained or analyzed. + +--- + +## 11.30 Event + +An **Event** is a record of an occurrence and its context. + +Events may be operational, domain, security, deployment, infrastructure, or business events. + +--- + +## 11.31 EventEnvelope + +An **EventEnvelope** is structured metadata around event data. + +CloudEvents is a primary mapping target. + +--- + +## 11.32 EventSource + +An **EventSource** is the producer or origin of an event. + +--- + +## 11.33 EventType + +An **EventType** classifies the kind of occurrence represented by an event. + +--- + +## 11.34 EventConsumer + +An **EventConsumer** is an actor, system, service, or pipeline that consumes events. + +--- + +## 11.35 EventCorrelationKey + +An **EventCorrelationKey** links events to related traces, logs, requests, incidents, deployments, or resources. + +--- + +## 11.36 Profile + +A **Profile** is sampled performance or resource-use data. + +This concept is observability-specific and distinct from InfoTechCanon application profiles. + +--- + +## 11.37 ProfilingSample + +A **ProfilingSample** is one sample of profiling data. + +--- + +## 11.38 ResourceProfile + +A **ResourceProfile** describes resource use over time or sampled execution. + +Examples: + +```text +CPU profile +memory profile +allocation profile +lock profile +I/O profile +``` + +--- + +## 11.39 PerformanceProfile + +A **PerformanceProfile** describes performance characteristics of a system, component, or operation. + +--- + +## 11.40 SLI + +A **Service Level Indicator** is a quantitative measure of a service level. + +Examples: + +```text +availability +latency +error rate +throughput +correctness +freshness +durability +``` + +--- + +## 11.41 SLO + +A **Service Level Objective** is a target value or range for an SLI over a defined measurement window. + +Recommended attributes: + +```yaml +service: +sli: +target: +window: +scope: +owner: +evidence_source: +``` + +--- + +## 11.42 SLAReference + +An **SLAReference** points to a contractual or formal service-level agreement. + +Governance owns contractual obligation semantics. Observability owns measured service-level signals. + +--- + +## 11.43 ErrorBudget + +An **ErrorBudget** is the allowed amount of unreliability implied by an SLO over a measurement window. + +--- + +## 11.44 BurnRate + +**BurnRate** is the rate at which an error budget is being consumed. + +--- + +## 11.45 HealthState + +**HealthState** is an assessed operational state of a resource, service, dependency, or system. + +Seed health states: + +```text +unknown +healthy +degraded +unhealthy +down +recovering +maintenance +``` + +--- + +## 11.46 AvailabilityWindow + +An **AvailabilityWindow** is the time period over which availability or service level is measured. + +--- + +## 11.47 AlertRule + +An **AlertRule** defines conditions under which an alert is created. + +Recommended attributes: + +```yaml +query: +condition: +threshold: +window: +severity: +for_duration: +labels: +annotations: +owner: +runbook: +``` + +--- + +## 11.48 Alert + +An **Alert** is an instance of an alert rule firing or resolving. + +Seed alert states: + +```text +pending +firing +acknowledged +suppressed +resolved +expired +``` + +--- + +## 11.49 Notification + +A **Notification** is a message sent to humans, agents, or systems about an alert, incident, or operational state. + +--- + +## 11.50 AlertRoute + +An **AlertRoute** defines how alerts are routed to responders, teams, tools, or escalation paths. + +--- + +## 11.51 AlertSuppression + +**AlertSuppression** is a rule or state that suppresses notifications for known, duplicate, maintenance, or intentionally ignored alert conditions. + +--- + +## 11.52 AlertCorrelation + +**AlertCorrelation** groups related alerts or signals. + +--- + +## 11.53 EscalationReference + +An **EscalationReference** points to Organization, Task, or Governance concepts defining who should respond and how escalation works. + +--- + +## 11.54 ObservedIncident + +An **ObservedIncident** is an operationally significant situation inferred or declared from observability signals. + +Task and ITSM systems may own incident work records. Observability owns the signal-derived incident view. + +--- + +## 11.55 Investigation + +An **Investigation** is analysis of signals, alerts, telemetry, incidents, or hypotheses to understand cause, scope, impact, and remediation. + +--- + +## 11.56 Timeline + +A **Timeline** is an ordered sequence of events, signals, decisions, actions, and observations. + +--- + +## 11.57 Runbook + +A **Runbook** is an operational procedure used to investigate, respond, recover, or verify a condition. + +--- + +## 11.58 Dashboard + +A **Dashboard** is a visual or structured view of observability data. + +--- + +## 11.59 OperationalView + +An **OperationalView** is a purpose-specific view of system state, health, risk, or performance. + +--- + +## 11.60 PostIncidentObservation + +A **PostIncidentObservation** is a signal, fact, lesson, or finding captured after an incident. + +--- + +## 11.61 ObservabilityEvidence + +**ObservabilityEvidence** is telemetry, query output, screenshot, dashboard state, trace, log, metric, or event used to support a claim. + +--- + +## 11.62 Query + +A **Query** is an expression used to retrieve or calculate observability data. + +Examples: + +```text +PromQL query +LogQL query +SQL query +trace search +SIEM query +dashboard panel query +``` + +--- + +## 11.63 QueryResult + +A **QueryResult** is the result of executing a query. + +--- + +## 11.64 Snapshot + +A **Snapshot** is a captured state of telemetry, dashboard, trace, log, metric, or query result at a time. + +--- + +## 11.65 Annotation + +An **Annotation** is a human, agent, or system-added note attached to telemetry, dashboard, timeline, incident, deployment, or event. + +--- + +## 11.66 Correlation + +A **Correlation** is a relationship linking signals, resources, events, deployments, incidents, or hypotheses. + +--- + +## 11.67 RootCauseHypothesis + +A **RootCauseHypothesis** is a candidate explanation for an observed issue. + +Canonical rule: + +```text +RootCauseHypothesis SHOULD remain distinguishable from verified cause. +``` + +--- + +# 12. Core Relationship Vocabulary + +Recommended root relationship types: + +```text +emitted_by +observes +measures +describes +correlates_with +derived_from +generated_by +triggered_by +alerts_on +routes_to +acknowledged_by +suppressed_by +resolves +affects +indicates +supports +evidences +verifies +invalidates +samples +aggregates +annotates +links_to +maps_to +``` + +Relationship records SHOULD support: + +```yaml +id: +relationship_type: +source_entity: +target_entity: +scope: +time_window: +state_context: +valid_from: +valid_to: +source_system: +confidence: +evidence: +rationale: +``` + +--- + +# 13. Observability State Models + +## 13.1 Signal States + +```text +unknown +emitting +missing +delayed +partial +degraded +invalid +stale +``` + +## 13.2 Alert States + +```text +pending +firing +acknowledged +suppressed +resolved +expired +``` + +## 13.3 Incident Observation States + +```text +suspected +confirmed +investigating +mitigating +recovering +resolved +post_review +closed +``` + +## 13.4 Health States + +```text +unknown +healthy +degraded +unhealthy +down +recovering +maintenance +``` + +## 13.5 SLO States + +```text +not_measured +within_budget +burning_fast +at_risk +violated +paused +retired +``` + +## 13.6 Telemetry Pipeline States + +```text +configured +active +degraded +dropping_data +stalled +misconfigured +retired +``` + +--- + +# 14. Observability Patterns + +## 14.1 Pattern: Resource-Linked Telemetry + +**Context:** Telemetry is collected from many systems. + +**Problem:** Signals are hard to interpret if they cannot be linked to canonical resources. + +**Solution:** Attach telemetry to ObservedResource references mapped to Landscape, Network, DevSecOps, Security, or Data entities. + +--- + +## 14.2 Pattern: Signal-to-Alert-to-Task + +**Context:** A condition needs human or agent response. + +**Problem:** Alerts fire but do not become accountable work. + +**Solution:** + +```text +Signal + -> AlertRule + -> Alert + -> ObservedIncident or Task + -> Investigation + -> RemediationTask + -> VerificationEvidence +``` + +--- + +## 14.3 Pattern: SLO as Reliability Contract + +**Context:** Service reliability must be operationally meaningful. + +**Problem:** Teams alert on low-level metrics that do not represent user experience. + +**Solution:** Define SLIs and SLOs for user-meaningful service behavior and use error budgets to guide action. + +--- + +## 14.4 Pattern: Deployment Health Verification + +**Context:** A deployment has completed. + +**Problem:** Successful deployment command does not prove healthy service behavior. + +**Solution:** Link DeploymentRecord to DeploymentHealthSignal, SLO state, traces, logs, metrics, and verification evidence. + +--- + +## 14.5 Pattern: Correlated Timeline + +**Context:** Incidents require understanding what happened. + +**Problem:** Logs, alerts, deployments, changes, and network events are scattered. + +**Solution:** Build Timeline from correlated events, alerts, traces, deployment records, annotations, and task actions. + +--- + +## 14.6 Pattern: Alert with Runbook + +**Context:** An alert requires response. + +**Problem:** Responders waste time discovering what the alert means. + +**Solution:** AlertRule SHOULD reference owner, runbook, dashboard, likely causes, and escalation path. + +--- + +## 14.7 Pattern: Metric with Exemplar + +**Context:** Aggregate metrics show a problem. + +**Problem:** Aggregates hide individual requests or traces. + +**Solution:** Link MetricPoint or histogram bucket to trace/log exemplar. + +--- + +## 14.8 Pattern: Observability as Governance Evidence + +**Context:** Governance requires proof that controls or SLOs are operating. + +**Problem:** Compliance claims rely on manual screenshots or weak assertions. + +**Solution:** Use query results, snapshots, dashboards, and telemetry evidence as structured ObservabilityEvidence. + +--- + +## 14.9 Pattern: Missing Signal as Signal + +**Context:** A telemetry source goes silent. + +**Problem:** Systems only alert on bad values, not missing data. + +**Solution:** Model missing, stale, or delayed telemetry as signal states and potential alerts. + +--- + +# 15. Observability Profiles + +## 15.1 Profile Format + +An Observability Profile SHALL declare: + +```yaml +id: +profile_name: +status: +implements: + - InfoTechCanonObservabilityModel +target_context: +included_concepts: +required_relationships: +required_metadata: +state_model: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +--- + +## 15.2 Seed Profile: Small SaaS Observability Profile + +Purpose: + +```text +Provide a minimal observability model for a small SaaS platform moving toward production readiness. +``` + +Included concepts: + +```text +ObservedResource +Metric +LogRecord +Trace +Span +Event +AlertRule +Alert +Dashboard +Runbook +SLI +SLO +HealthState +ObservedIncident +ObservabilityEvidence +``` + +Required relationships: + +```text +Metric emitted_by ObservedResource +LogRecord emitted_by ObservedResource +Trace observes Service +Alert triggered_by AlertRule +Alert affects Service +SLO measures Service +Dashboard displays Metric +Runbook supports Alert +ObservabilityEvidence supports Investigation +``` + +--- + +## 15.3 Seed Profile: OpenTelemetry Profile + +Purpose: + +```text +Map OpenTelemetry resources, traces, metrics, logs, attributes, baggage, and semantic conventions into InfoTechCanon. +``` + +Example mappings: + +```text +Resource -> ObservedResource +Resource attributes -> ResourceAttribute +Metric -> Metric +LogRecord -> LogRecord +Trace -> Trace +Span -> Span +Span event -> SpanEvent +Span link -> SpanLink +Baggage -> Baggage +Semantic conventions -> Mapping / Attribute vocabulary +Collector -> TelemetryPipeline component +Exporter -> TelemetryPipeline component +``` + +--- + +## 15.4 Seed Profile: Prometheus / OpenMetrics Profile + +Purpose: + +```text +Represent metrics, labels, time series, scrape targets, alert rules, and query results. +``` + +Example mappings: + +```text +metric name -> Metric +labels -> dimensions / attributes +sample -> MetricPoint +time series -> TimeSeries +PromQL -> Query +recording rule -> DerivedMetric / Query +alerting rule -> AlertRule +target -> TelemetrySource / ObservedResource +``` + +--- + +## 15.5 Seed Profile: CloudEvents Profile + +Purpose: + +```text +Represent event metadata and event envelopes. +``` + +Example mappings: + +```text +id -> Event id +source -> EventSource +type -> EventType +specversion -> EventEnvelope version +subject -> Event subject +time -> Event timestamp +datacontenttype -> Event data content type +data -> Event data +``` + +--- + +## 15.6 Seed Profile: SRE Reliability Profile + +Purpose: + +```text +Represent SLIs, SLOs, error budgets, burn rates, and reliability decisions. +``` + +Included concepts: + +```text +SLI +SLO +ErrorBudget +BurnRate +AvailabilityWindow +AlertRule +ReliabilityReview +ServiceHealthState +ErrorBudgetPolicyReference +``` + +Required relationships: + +```text +SLO applies_to Service +SLI measures Service +ErrorBudget derived_from SLO +BurnRate measures ErrorBudgetConsumption +AlertRule alerts_on BurnRate +ReliabilityReview reviews SLOState +``` + +--- + +## 15.7 Seed Profile: Incident Observability Profile + +Purpose: + +```text +Represent telemetry, alerts, timelines, dashboards, and evidence for incident response. +``` + +Included concepts: + +```text +Alert +ObservedIncident +Timeline +Investigation +Dashboard +Runbook +Annotation +RootCauseHypothesis +ObservabilityEvidence +PostIncidentObservation +``` + +--- + +## 15.8 Seed Profile: Network Observability Profile + +Purpose: + +```text +Represent network metrics, flow logs, reachability tests, DNS logs, and latency signals. +``` + +Included concepts: + +```text +NetworkMetric +ObservedFlowSignal +DNSLogRecord +ReachabilityTestResult +LatencyMetric +PacketLossMetric +EndpointHealthSignal +``` + +Mapping targets: + +```text +NetFlow/IPFIX +VPC Flow Logs +Kubernetes CNI telemetry +service mesh telemetry +DNS logs +synthetic probes +``` + +--- + +## 15.9 Seed Profile: Security Observability Profile + +Purpose: + +```text +Represent observability signals used for security detection, investigation, and evidence. +``` + +Included concepts: + +```text +SecuritySignal +SecurityLogRecord +DetectionEvent +Alert +TraceEvidence +AccessSessionLog +AuditLogReference +SecurityEvidence +``` + +Security interpretation remains owned by the Security Model. + +--- + +# 16. Mapping Model for the Observability Standard + +Mappings relate InfoTechCanon observability concepts to external standards, tools, and products. + +## 16.1 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +regulatoryReference +toolEquivalent +``` + +## 16.2 Mapping Record + +Example: + +```yaml +id: itc-map:span-to-opentelemetry-span +source_concept: itc-obs:Span +target_body: OpenTelemetry +target_version: "current" +target_concept: Span +mapping_type: closeMatch +scope: + - distributed tracing +not_valid_for: + - all event or log semantics +rationale: > + OpenTelemetry Span is the primary mapping target for timed operations in traces. + InfoTechCanon keeps Span as a canonical concept to allow mappings to other tracing systems. +confidence: high +status: candidate +owner: InfoTechCanonObservabilityModel +``` + +## 16.3 Seed Mapping Targets + +The Observability Model SHOULD maintain mappings to: + +```text +OpenTelemetry +OpenTelemetry Semantic Conventions +Prometheus +OpenMetrics / Prometheus exposition format +CloudEvents +W3C Trace Context +Google SRE SLI/SLO/Error Budget concepts +Grafana dashboards and alerting +Prometheus Alertmanager +Loki / LogQL +Jaeger +Tempo +Elastic Observability +Datadog +New Relic +Splunk +OpenSearch +ITIL incident concepts +NetFlow / IPFIX +VPC Flow Logs +Kubernetes events and metrics +service mesh telemetry +``` + +--- + +# 17. Assimilation Hooks + +The Observability Model SHALL be able to receive new observability standards, tool models, telemetry schemas, incident practices, and operational patterns through the InfoTechCanon assimilation process. + +## 17.1 Assimilation Triggers + +Assimilation may be triggered by: + +```text +new telemetry standard +new observability backend +new incident-management tool +new SLO practice +new dashboard model +new alerting model +new tracing model +new logging schema +new AIOps product +new runtime verification practice +new recurring signal classification conflict +``` + +## 17.2 Observability Assimilation Output + +An observability assimilation SHOULD produce: + +```text +source summary +extracted observability concepts +concept comparison matrix +gap list +conflict list +mapping file +candidate new concepts +candidate relationship changes +candidate pattern changes +candidate profile changes +open questions +``` + +## 17.3 Recommended First Assimilation Candidates + +```text +OpenTelemetry specification and semantic conventions +Prometheus / OpenMetrics +CloudEvents +W3C Trace Context +Google SRE SLO chapters +Grafana dashboard and alerting models +Prometheus Alertmanager +Kubernetes events and metrics +VPC Flow Logs / NetFlow / IPFIX +ITIL incident management concepts +``` + +--- + +# 18. Integration with Other InfoTechCanon Standards + +## 18.1 Landscape Model + +Observability links signals to: + +```text +ApplicationService +TechnicalService +RuntimeWorkload +Environment +Endpoint +DataStore +DeploymentRecord +NetworkEntity +``` + +## 18.2 Organization Model + +Observability imports organization concepts for: + +```text +service owner +on-call responder +team +escalation target +runbook owner +incident commander +``` + +## 18.3 Governance Model + +Observability imports governance concepts for: + +```text +evidence +control result +review +assurance +policy +SLA obligation +audit evidence +``` + +## 18.4 Task Model + +Observability creates or references: + +```text +incident task +investigation task +remediation task +follow-up task +reliability improvement task +``` + +## 18.5 Tagging Standard + +Observability uses tags for: + +```text +service +environment +severity +signal type +dashboard category +incident category +team +``` + +Tags must not replace ObservedResource, AlertRule, SLO, or Evidence records. + +## 18.6 Access Control Model + +Observability imports access concepts for: + +```text +dashboard access +log access +trace access +incident tool access +telemetry pipeline access +sensitive telemetry access +``` + +## 18.7 Security Model + +Security imports observability concepts for: + +```text +security signal +detection evidence +security alert +audit log +trace evidence +incident timeline +``` + +## 18.8 Data Model + +Data imports observability concepts when telemetry is treated as a dataset and for data freshness, quality, and lineage signals. + +## 18.9 DevSecOps Model + +DevSecOps imports observability concepts for: + +```text +deployment verification +change failure detection +delivery metric +runtime feedback +SLO impact +``` + +## 18.10 Network Model + +Network imports observability concepts for: + +```text +flow logs +reachability test results +latency +packet loss +DNS logs +endpoint health +``` + +--- + +# 19. Canon Interface Card Usage + +Subsystems that implement or produce observability knowledge SHOULD publish a Canon Interface Card. + +Example: + +```yaml +subsystem: prometheus-importer +implements: + - InfoTechCanonObservabilityModel + - PrometheusOpenMetricsProfile +produces: + - Metric + - TimeSeries + - MetricPoint + - AlertRule + - Alert + - QueryResult +consumes: + - ObservedResource + - Service + - Environment +relations: + - Metric emitted_by ObservedResource + - Alert triggered_by AlertRule + - Alert affects Service +source_of_truth: + metric_samples: Prometheus + alert_rule_state: Prometheus +known_deviations: + - resource identity depends on labels + - long-term retention may be external +``` + +--- + +# 20. Retrieval Requirements + +The Observability Model is designed for markdown-based infospaces. + +## 20.1 Required Retrieval Properties + +Every major concept SHOULD provide: + +- stable heading, +- stable identifier, +- short definition, +- longer explanation, +- examples, +- distinction notes, +- relationship examples, +- mapping hooks, +- profile references, +- and common mistakes. + +## 20.2 Agent Brief + +A mature Observability Model SHOULD include an `agent-brief.md` file with: + +```text +purpose +scope +owned concepts +imported concepts +core distinctions +do / do not rules +relationship patterns +minimal examples +common mistakes +profile list +mapping list +``` + +## 20.3 Indexes + +The observability information space SHOULD provide indexes by: + +```text +concept +relationship +signal type +metric +log +trace +event +resource +service +alert +SLO +dashboard +incident +profile +pattern +mapping target +status +source system +``` + +--- + +# 21. Conformance Levels + +## 21.1 Reference-Conformant + +A document or system is reference-conformant if it uses Observability Model terminology consistently but does not implement structured metadata or validation rules. + +## 21.2 Metadata-Conformant + +A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types. + +## 21.3 Signal-Conformant + +A system is signal-conformant if it distinguishes metrics, logs, traces, events, profiles, alerts, and health signals. + +## 21.4 Resource-Correlated + +A system is resource-correlated if observability signals can be linked to observed resources and canonical landscape entities. + +## 21.5 SLO-Conformant + +A system is SLO-conformant if it represents SLIs, SLOs, error budgets, burn rates, and measurement windows. + +## 21.6 Evidence-Conformant + +A system is evidence-conformant if observability claims, incidents, alerts, and service-level states can be linked to evidence. + +## 21.7 Profile-Conformant + +A system is profile-conformant if it implements a declared Observability Profile and passes its validation rules. + +## 21.8 Assimilation-Conformant + +A system or repository is assimilation-conformant if it can accept external observability concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes. + +--- + +# 22. Validation Rules + +Initial validation rules: + +```text +VAL-OBS-001: Metric, LogRecord, Trace, Span, Event, Profile, Alert, and Incident SHOULD be modeled as distinct concepts. + +VAL-OBS-002: Telemetry SHOULD reference an ObservedResource where possible. + +VAL-OBS-003: ObservedResource SHOULD map to a Landscape, Network, Data, Security, or DevSecOps entity where possible. + +VAL-OBS-004: Metric SHOULD declare unit, instrument type, source, and dimensions where available. + +VAL-OBS-005: TimeSeries SHOULD distinguish metric identity from labels/dimensions. + +VAL-OBS-006: LogRecord SHOULD include timestamp, severity, source, and body where available. + +VAL-OBS-007: Span SHOULD include trace id, span id, timing, name, status, and parent/link references where available. + +VAL-OBS-008: Event SHOULD distinguish event data from event context metadata. + +VAL-OBS-009: Alert SHOULD reference AlertRule or source condition where available. + +VAL-OBS-010: AlertRule SHOULD reference query or condition, threshold, time window, owner, and runbook where applicable. + +VAL-OBS-011: SLO SHOULD reference SLI, target, measurement window, service, and evidence source. + +VAL-OBS-012: ErrorBudget SHOULD derive from an SLO. + +VAL-OBS-013: Dashboard SHOULD NOT be treated as evidence unless a Snapshot or QueryResult is captured. + +VAL-OBS-014: Incident SHOULD NOT be inferred solely from one alert unless profile permits it. + +VAL-OBS-015: RootCauseHypothesis SHOULD remain distinguishable from verified cause. + +VAL-OBS-016: Missing, stale, or delayed telemetry SHOULD be representable as signal state. + +VAL-OBS-017: Tags MUST NOT replace resource identity, SLO definitions, alert rules, or evidence. + +VAL-OBS-018: Imported external observability concepts SHOULD be represented through mapping records rather than silently reused. + +VAL-OBS-019: Profiles MUST NOT redefine canonical concepts. They may constrain them. + +VAL-OBS-020: Telemetry containing sensitive data SHOULD reference Data, Security, Access Control, or Governance constraints where relevant. +``` + +--- + +# 23. Anti-Patterns + +## 23.1 Dashboard as Truth + +Treating a dashboard view as evidence without preserving query, time window, data source, or snapshot. + +## 23.2 Alert Equals Incident + +Treating every alert as an incident. + +## 23.3 Metric Soup + +Collecting many metrics without ownership, resource identity, interpretation, or action path. + +## 23.4 Logs Without Context + +Logging messages that cannot be correlated to service, request, trace, tenant, deployment, or resource. + +## 23.5 Traces Without Boundaries + +Tracing calls without linking them to service ownership, deployment version, or runtime resource. + +## 23.6 SLO Theater + +Creating SLOs that do not reflect user experience or guide operational decisions. + +## 23.7 Alert Without Runbook + +Creating alerts without ownership, runbook, dashboard, or response expectation. + +## 23.8 Missing Signal Blindness + +Failing to alert when telemetry stops arriving. + +## 23.9 Tool-Native Capture + +Letting one observability backend define the internal observability model. + +## 23.10 Telemetry Without Governance + +Collecting sensitive logs, traces, or profiles without classification, retention, access control, or privacy consideration. + +--- + +# 24. Initial Repository Placement + +Recommended repository layout: + +```text +info-tech-canon/ + standards/ + observability/ + InfoTechCanonObservabilityModel.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +Seed files: + +```text +standards/observability/InfoTechCanonObservabilityModel.md +standards/observability/agent-brief.md +standards/observability/concepts/telemetry.md +standards/observability/concepts/metric.md +standards/observability/concepts/log-record.md +standards/observability/concepts/trace.md +standards/observability/concepts/span.md +standards/observability/concepts/event.md +standards/observability/concepts/sli.md +standards/observability/concepts/slo.md +standards/observability/concepts/alert.md +standards/observability/concepts/observability-evidence.md +standards/observability/patterns/resource-linked-telemetry.md +standards/observability/patterns/signal-to-alert-to-task.md +standards/observability/patterns/slo-as-reliability-contract.md +standards/observability/patterns/deployment-health-verification.md +standards/observability/profiles/small-saas-observability-profile.md +standards/observability/profiles/opentelemetry-profile.md +standards/observability/profiles/prometheus-openmetrics-profile.md +standards/observability/profiles/sre-reliability-profile.md +standards/observability/mappings/opentelemetry.yaml +standards/observability/mappings/prometheus-openmetrics.yaml +standards/observability/mappings/cloudevents.yaml +standards/observability/mappings/sre-slo.yaml +``` + +--- + +# 25. Roadmap + +## Phase 1: Seed Stabilization + +- Establish this standard as `InfoTechCanonObservabilityModel`. +- Add seed concepts, relationship vocabulary, patterns, and profiles. +- Define validation rules. +- Align with Landscape, Network, DevSecOps, Security, Data, Governance, Task, Access Control, and Tagging. + +## Phase 2: First Assimilations + +Recommended first assimilations: + +```text +OpenTelemetry specification and semantic conventions +Prometheus / OpenMetrics +CloudEvents +W3C Trace Context +Google SRE SLO chapters +Grafana dashboard and alerting model +Prometheus Alertmanager +Kubernetes events and metrics +VPC Flow Logs / NetFlow / IPFIX +ITIL incident management concepts +``` + +## Phase 3: Profile Maturation + +- Mature Small SaaS Observability Profile. +- Mature OpenTelemetry Profile. +- Mature Prometheus / OpenMetrics Profile. +- Mature CloudEvents Profile. +- Mature SRE Reliability Profile. +- Mature Incident Observability Profile. +- Mature Network Observability Profile. +- Mature Security Observability Profile. + +## Phase 4: Tooling Integration + +- Generate concept indexes. +- Generate agent brief. +- Create machine-readable YAML/JSON exports. +- Add validation scripts. +- Integrate telemetry pipelines, metrics, logs, traces, dashboards, alerts, incident tools, and service catalogs. + +## Phase 5: Operational Intelligence Loop + +- Connect telemetry to canonical resources. +- Connect alerts to tasks and incidents. +- Connect SLOs to governance and service ownership. +- Connect deployment records to runtime health signals. +- Connect security detections to security incidents. +- Connect network flows to reachability and exposure. +- Connect post-incident observations to improvements and standard evolution. + +--- + +# 26. Summary + +The InfoTechCanon Observability Model is the seed standard for representing telemetry, signals, metrics, logs, traces, events, profiles, alerts, SLOs, health, incidents as observed phenomena, and operational evidence. + +Its most important commitments are: + +```text +Separate telemetry, signal, metric, log, trace, span, event, profile, alert, and incident. + +Link signals to canonical resources and landscape entities. + +Treat SLOs, SLIs, error budgets, burn rates, and health states as first-class reliability concepts. + +Use observability evidence to support governance, security, delivery, incident response, and operational review. + +Map to OpenTelemetry, Prometheus/OpenMetrics, CloudEvents, SRE practices, and observability tools +without surrendering internal semantic autonomy. + +Use profiles to make the model practical for SaaS systems, OpenTelemetry, Prometheus, +SRE reliability, incident response, network observability, and security observability. +``` + +This makes the Observability Model a core seed for runtime intelligence, production readiness, SRE practice, incident response, deployment verification, security detection, and agent-supported operations. diff --git a/seeds/InfoTechCanonOrganizationModel_RC1_seed.md b/seeds/InfoTechCanonOrganizationModel_RC1_seed.md new file mode 100755 index 0000000..a7a59bc --- /dev/null +++ b/seeds/InfoTechCanonOrganizationModel_RC1_seed.md @@ -0,0 +1,1750 @@ +# InfoTechCanon Organization Model + +**Short Name:** `ITC-ORG` +**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:** Organization designers, enterprise architects, platform builders, governance designers, product owners, service owners, HR/people-ops modelers, project/program managers, security architects, knowledge-system builders, standards authors, and agentic tooling. + +--- + +# 1. Purpose + +The **InfoTechCanon Organization Model** defines a canonical seed model for representing organizations, organizational units, actors, memberships, roles, authority, responsibility, accountability, teams, operating structures, collaboration structures, and organizational viability patterns. + +It exists to support the broader **InfoTechCanon** goal of building interoperable information-processing systems without forcing rigid organizational assumptions into every subsystem. + +This standard provides: + +- a canonical vocabulary for organizational structures, +- a distinction between persons, actors, roles, positions, groups, teams, units, and organizations, +- a responsibility and authority model, +- a membership and assignment model, +- support for formal, informal, matrix, product, project, and networked organizations, +- interfaces to governance, landscape, task, tagging, access-control, service, and security models, +- mapping hooks to external standards and frameworks, +- seed patterns for practical organization modeling, +- profile hooks for implementation contexts, +- and retrieval-friendly structure for humans, agents, and markdown-based infospaces. + +--- + +# 2. Position in InfoTechCanon + +The Organization Model is a **domain standard** within InfoTechCanon. + +It should become the canonical owner of organizational concepts that are currently only referenced by the Landscape Model. + +```text +InfoTechCanon +├── InfoTechCanonCore +├── InfoTechCanonOrganizationModel <-- this standard +├── InfoTechCanonGovernanceModel <-- close dependency / sibling standard +├── InfoTechCanonLandscapeModel <-- imports organization references +├── InfoTechCanonTaskModel <-- imports actors, assignments, accountability +├── InfoTechCanonAccessControlModel <-- imports actor, role, principal distinctions +├── InfoTechCanonTaggingStandard +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +## 2.1 Boundary with Governance + +The Organization Model owns: + +```text +Actor +Person +Organization +OrganizationalUnit +Team +Group +Role +Position +Membership +Assignment +Responsibility +Authority +Accountability +ReportingLine +CoordinationMechanism +OperatingUnit +``` + +The Governance Model should own: + +```text +Policy +Rule +Control +Decision +Risk +Obligation +Exception +Evidence +ComplianceRequirement +Audit +GovernanceProcess +``` + +The boundary rule is: + +```text +Organization defines who can act, where they belong, and what authority or responsibility they carry. + +Governance defines which rules, decisions, controls, obligations, and evidence structures constrain or direct action. +``` + +--- + +# 3. Research Basis and External Alignment + +This seed standard draws on several bodies of prior work. + +## 3.1 W3C Organization Ontology + +The W3C Organization Ontology provides a reusable ontology for organizational structures, including organizations, organizational units, posts, roles, membership, reporting, and classification. It is a strong source for linked-data-friendly modeling of organizational structure. + +Relevant external concepts: + +```text +Organization +OrganizationalUnit +FormalOrganization +OrganizationalCollaboration +Post +Role +Membership +reportsTo +memberOf +``` + +## 3.2 Enterprise Modeling Standards + +Enterprise modeling standards such as ISO 19439 and ISO 19440 emphasize enterprise constructs, processes, resources, and human tasks. They support the idea that organizational models must interoperate with process, resource, and capability models rather than exist only as HR charts. + +## 3.3 Business Motivation and Governance Models + +The OMG Business Motivation Model treats organization units, assets, business processes, and business rules as important references, while making clear that detailed organization structure is outside its own scope. This supports the InfoTechCanon separation between organization modeling and governance/motivation modeling. + +## 3.4 Viable System Model + +Stafford Beer’s Viable System Model provides a cybernetic view of organization: operational units, coordination, control, intelligence/adaptation, and policy/identity functions recur at multiple levels. This is useful as a pattern layer rather than a mandatory structure. + +## 3.5 Project and Matrix Organization Literature + +Project management practice distinguishes functional, matrix, projectized, and composite structures. This is important because real organizations rarely follow a single hierarchy. The Organization Model must support multiple simultaneous authority, reporting, allocation, and accountability relations. + +## 3.6 IT Service Management and Governance Practice + +ITIL, COBIT, COSO, ISO 9001, and similar frameworks emphasize roles, responsibilities, authorities, controls, accountability, governance structures, and process ownership. The Organization Model should provide the structural substrate for these models while not owning their full governance semantics. + +## 3.7 Human Capital Reporting + +ISO 30414 and related human-capital reporting practice highlight workforce composition, skills, productivity, leadership, succession, culture, and workforce metrics. These are not all core organizational structure concepts, but they provide important future mapping and assimilation targets. + +--- + +# 4. Seed Standard Design Stance + +This standard is a **seed standard**, not a final complete theory of organizations. + +A seed standard shall: + +1. define enough canonical concepts to support practical system integration, +2. avoid pretending that organization theory is complete or simple, +3. preserve orthogonality with governance, access control, task management, and landscape modeling, +4. support formal and informal structures, +5. support recursive and matrix structures, +6. support human and non-human actors, +7. expose mapping hooks to existing standards, +8. enable practical subsystem interface declarations, +9. and remain suitable for markdown-first knowledge spaces and agent retrieval. + +--- + +# 5. Scope + +## 5.1 In Scope + +This standard covers canonical representation of: + +- organizations, +- organizational units, +- teams, +- groups, +- persons, +- actors, +- agents, +- roles, +- positions, +- posts, +- membership, +- assignment, +- reporting lines, +- responsibility, +- accountability, +- authority, +- delegation, +- stewardship, +- ownership, +- operating units, +- collaboration structures, +- project/product/value-stream structures, +- matrix organization relationships, +- organizational capabilities, +- coordination mechanisms, +- viability functions, +- and organization-facing interface concepts for other InfoTechCanon standards. + +## 5.2 Out of Scope + +This standard does not fully define: + +- legal corporate structures in jurisdiction-specific detail, +- employment law, +- compensation and payroll, +- full HR management, +- performance management, +- psychological safety, +- labor relations, +- social responsibility, +- diversity reporting, +- full governance and compliance models, +- full access-control semantics, +- full project management methodology, +- or all organizational design theory. + +Those may be mapped, assimilated, profiled, or handled by adjacent standards. + +--- + +# 6. 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 defined provisionally here but open to later refinement. +- **EXTRACT** marks a concept that may later move to a more specialized standard. + +--- + +# 7. Core Principles + +## 7.1 Person, Actor, Role, and Position Are Distinct + +The model SHALL distinguish: + +```text +Person +Actor +Agent +Role +Position +Assignment +Membership +``` + +A person is not a role. +A role is not a person. +A position is not a role. +An assignment is not permanent identity. +A membership is not necessarily authority. + +## 7.2 Organization Is More Than Hierarchy + +The model SHALL support hierarchical, matrix, networked, projectized, product-oriented, functional, and informal organizational structures. + +## 7.3 Authority and Responsibility Are First-Class + +Authority, responsibility, and accountability SHALL be modeled explicitly when relevant. + +They MUST NOT be hidden as free-text comments on people or teams. + +## 7.4 Multiple Structures May Coexist + +An actor MAY participate in multiple organizational structures at the same time. + +Example: + +```text +A person may belong to a functional department, +work in a product team, +serve as incident commander, +hold a security role, +and be accountable for a service. +``` + +## 7.5 Organization Models Must Support Time + +Memberships, assignments, reporting lines, responsibilities, and authorities SHOULD carry validity intervals. + +## 7.6 Organization Models Must Support Source and Confidence + +When organizational data is imported from HR systems, identity systems, service catalogs, CMDBs, Git repositories, project tools, or manual documents, its source and confidence SHOULD be recorded. + +## 7.7 Governance Uses Organization but Does Not Replace It + +Governance models need organizational structures, but policies and controls are not the same thing as organizational roles or responsibilities. + +## 7.8 Access Control Uses Roles but Does Not Own All Roles + +Access-control roles, organizational roles, job roles, governance roles, and task roles may overlap but are not identical. + +The Organization Model owns the generic role concept. The Access Control Model should own permission-bearing access roles and entitlements. + +--- + +# 8. Canonical Seed Metadata + +Every organization artifact SHOULD support structured metadata. + +Recommended front matter: + +```yaml +--- +id: itc-org:Team +type: concept +standard: InfoTechCanonOrganizationModel +standard_version: RC1-seed +status: candidate +canonical_owner: InfoTechCanonOrganizationModel +preferred_label: Team +related: + - itc-org:Organization + - itc-org:Role + - itc-org:Membership + - itc-org:Responsibility +mappings: + - itc-map:team-to-w3c-org-organizational-unit +--- +``` + +Recommended artifact statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +Recommended concept statuses: + +```text +proposed +experimental +candidate +canonical +deprecated +retired +``` + +--- + +# 9. Root Organization Taxonomy + +```text +OrganizationEntity +├── ActorEntity +│ ├── Person +│ ├── Agent +│ ├── HumanActor +│ ├── NonHumanActor +│ └── CollectiveActor +├── StructureEntity +│ ├── Organization +│ ├── OrganizationalUnit +│ ├── Team +│ ├── Group +│ ├── Committee +│ ├── Community +│ ├── Network +│ └── Collaboration +├── RoleEntity +│ ├── Role +│ ├── OrganizationalRole +│ ├── JobRole +│ ├── FunctionalRole +│ ├── GovernanceRole +│ ├── ServiceRole +│ ├── ProjectRole +│ └── AccessRoleReference +├── PositionEntity +│ ├── Position +│ ├── Post +│ └── Seat +├── RelationshipEntity +│ ├── Membership +│ ├── Assignment +│ ├── ReportingLine +│ ├── Delegation +│ ├── Responsibility +│ ├── Accountability +│ ├── Authority +│ └── Consultation +├── CapabilityEntity +│ ├── OrganizationalCapability +│ ├── Skill +│ ├── Competence +│ ├── Capacity +│ └── Availability +└── ViabilityEntity + ├── OperatingUnit + ├── CoordinationFunction + ├── ControlFunction + ├── IntelligenceFunction + ├── PolicyFunction + └── RecursiveOrganizationUnit +``` + +--- + +# 10. Core Concepts + +## 10.1 OrganizationEntity + +An **OrganizationEntity** is any identifiable organizational concept relevant to people, actors, structures, roles, authority, responsibility, coordination, or organizational capability. + +Recommended attributes: + +```yaml +id: +entity_type: +canonical_name: +display_name: +lifecycle_state: +source_system: +created_at: +updated_at: +``` + +Optional attributes: + +```yaml +owner: +steward: +classification: +source_confidence: +valid_from: +valid_to: +tags: +external_references: +``` + +--- + +## 10.2 Actor + +An **Actor** is an entity capable of participating in action, responsibility, communication, decision, work, or authority relationships. + +Subtypes: + +```text +HumanActor +NonHumanActor +CollectiveActor +``` + +An actor may be: + +```text +Person +Team +Organization +ServiceAccount +AI Agent +System +Committee +ExternalPartner +``` + +### Canonical Rule + +Actor is a functional modeling concept. + +It MUST NOT be treated as synonymous with Person. + +--- + +## 10.3 Person + +A **Person** is a human individual represented in the organization model. + +A person may have: + +```text +memberships +assignments +roles +positions +responsibilities +authorities +skills +availability +identity references +``` + +The model SHOULD avoid storing unnecessary sensitive personal data unless a concrete profile requires it. + +--- + +## 10.4 Agent + +An **Agent** is a non-human actor that can act in a system context. + +Examples: + +```text +software agent +AI agent +automation bot +service account +operational daemon +workflow executor +``` + +Agent concepts are important because InfoTechCanon must support human-agent organizations. + +--- + +## 10.5 CollectiveActor + +A **CollectiveActor** is a group-like actor that can be assigned responsibility or authority. + +Examples: + +```text +team +committee +organization +external supplier +community +working group +``` + +--- + +## 10.6 Organization + +An **Organization** is a structured collective actor with identity, purpose, boundaries, and some capacity for coordinated action. + +An organization may be: + +```text +company +non-profit +public body +open-source foundation +department-like autonomous unit +project organization +temporary venture +network organization +``` + +Recommended attributes: + +```yaml +legal_name: +short_name: +organization_type: +purpose: +boundary_description: +jurisdiction: +lifecycle_state: +``` + +--- + +## 10.7 OrganizationalUnit + +An **OrganizationalUnit** is a subdivision of an organization. + +Examples: + +```text +division +department +business unit +chapter +tribe +cost center +regional unit +product area +``` + +Organizational units usually imply structural membership and some form of management or accountability. + +--- + +## 10.8 Team + +A **Team** is a collective actor organized around shared work, responsibility, service, product, capability, or mission. + +A team may or may not be a formal organizational unit. + +Canonical distinction: + +```text +OrganizationalUnit + structural subdivision of an organization + +Team + working collective with shared responsibility + +Group + collection of actors, often for classification, communication, access, or convenience +``` + +--- + +## 10.9 Group + +A **Group** is a collection of actors. + +Groups MAY be used for: + +```text +communication +access control +classification +mailing lists +work coordination +interest communities +``` + +A group does not automatically imply shared responsibility, shared management, or organizational authority. + +--- + +## 10.10 Role + +A **Role** is an expected pattern of responsibility, authority, behavior, participation, or capability that can be assigned to an actor. + +Subtypes: + +```text +OrganizationalRole +JobRole +FunctionalRole +GovernanceRole +ServiceRole +ProjectRole +TaskRole +AccessRoleReference +``` + +### Canonical Rule + +A role describes a type of participation or responsibility. + +A role SHALL NOT be used as a substitute for a person, position, permission set, or team unless a profile explicitly declares that simplification. + +--- + +## 10.11 Position + +A **Position** is an organizationally defined slot that may be occupied by a person or actor. + +Examples: + +```text +Chief Technology Officer +Head of Product +Team Lead Backend +Security Officer +Data Protection Officer +``` + +A position may imply roles, responsibilities, authority, and reporting lines. + +--- + +## 10.12 Post + +A **Post** is a position-like place in an organization that exists independently of the current holder. + +This term is useful when mapping to W3C ORG. + +--- + +## 10.13 Membership + +A **Membership** is a relationship that connects an actor to a group, team, organizational unit, or organization. + +Recommended attributes: + +```yaml +member: +organization_entity: +membership_type: +valid_from: +valid_to: +source_system: +confidence: +``` + +Membership does not necessarily imply authority. + +--- + +## 10.14 Assignment + +An **Assignment** is a relationship that assigns an actor to a role, position, responsibility, task, service, project, or scope. + +Examples: + +```text +Person assigned_to Role +Team assigned_to Service +Person assigned_to Position +Agent assigned_to AutomationTask +Team assigned_to IncidentResponseDuty +``` + +Assignment should usually be time-bounded. + +--- + +## 10.15 Responsibility + +A **Responsibility** is an obligation or expected duty assigned to an actor for a scope. + +Examples: + +```text +responsible for operating a service +responsible for reviewing pull requests +responsible for maintaining a dataset +responsible for incident response +``` + +Responsibility does not necessarily imply final decision authority. + +--- + +## 10.16 Accountability + +**Accountability** is the condition of being answerable for the outcome of a responsibility, decision, service, control, or obligation. + +Canonical rule: + +```text +A scope SHOULD have clear accountability when failure has meaningful consequences. +``` + +Profiles MAY require exactly one accountable actor per scope, but the core model does not mandate this universally because real organizations may have shared or layered accountability. + +--- + +## 10.17 Authority + +**Authority** is the recognized right to make decisions, allocate resources, approve changes, enforce rules, or direct action within a scope. + +Subtypes: + +```text +DecisionAuthority +ApprovalAuthority +BudgetAuthority +OperationalAuthority +TechnicalAuthority +PolicyAuthority +EmergencyAuthority +``` + +Authority SHOULD be scoped. + +--- + +## 10.18 Delegation + +**Delegation** is a relationship in which an actor transfers or grants responsibility or authority to another actor within defined limits. + +Recommended attributes: + +```yaml +delegator: +delegate: +delegated_scope: +delegated_authority: +valid_from: +valid_to: +revocable: +constraints: +``` + +--- + +## 10.19 ReportingLine + +A **ReportingLine** is a relationship indicating managerial, functional, project, product, operational, or governance reporting. + +Subtypes: + +```text +managerial_reports_to +functional_reports_to +project_reports_to +product_reports_to +governance_reports_to +operational_reports_to +escalates_to +``` + +Canonical rule: + +```text +ReportingLine MUST specify its type when more than one reporting logic exists. +``` + +--- + +## 10.20 Ownership + +**Ownership** is a strong responsibility relationship connecting an actor to an entity whose lifecycle, quality, continuity, or outcome the actor is expected to care for. + +Ownership is often used by landscape, service, data, product, and governance models. + +Subtypes: + +```text +ServiceOwnership +ProductOwnership +DataOwnership +TechnicalOwnership +ProcessOwnership +ControlOwnership +RiskOwnership +``` + +Ownership SHOULD be mapped to responsibility and accountability but is not identical to legal ownership. + +--- + +## 10.21 Stewardship + +**Stewardship** is a responsibility for care, quality, maintenance, interpretation, or proper use of an entity. + +Stewardship is often less absolute than ownership. + +Examples: + +```text +data steward +standard steward +service catalog steward +architecture steward +community steward +``` + +--- + +## 10.22 OrganizationalCapability + +An **OrganizationalCapability** is the capacity of an organization or organizational part to reliably perform a class of work or produce a kind of outcome. + +Examples: + +```text +software delivery +incident response +customer support +security monitoring +product discovery +regulatory reporting +``` + +This concept should align with strategy and landscape capability modeling. + +--- + +## 10.23 Skill and Competence + +A **Skill** is an ability that can be possessed by a person or agent. + +A **Competence** is a demonstrated or recognized ability to perform in a domain or role. + +These concepts are seed concepts and may later be refined in a human-capital or capability standard. + +--- + +## 10.24 Capacity and Availability + +**Capacity** is the amount of work or responsibility an actor or group can realistically absorb in a time or context. + +**Availability** is the degree to which an actor is accessible for assignment, decision, support, or communication. + +These are important for task, project, service, and incident models. + +--- + +# 11. Core Relationship Vocabulary + +Recommended root relationship types: + +```text +member_of +has_member +assigned_to +plays_role +occupies_position +reports_to +delegates_to +responsible_for +accountable_for +has_authority_over +owns +stewards +consulted_by +informed_by +supports +coordinates_with +collaborates_with +escalates_to +represents +external_to +part_of +composes +``` + +Relationship records SHOULD support: + +```yaml +id: +relationship_type: +source_actor_or_entity: +target_actor_or_entity: +scope: +valid_from: +valid_to: +source_system: +confidence: +evidence: +``` + +--- + +# 12. Organizational Structure Patterns + +## 12.1 Pattern: Person-Role-Assignment Split + +**Context:** Systems often store people, roles, and assignments as one field. + +**Problem:** A person may change roles; a role may be held by many people; a position may exist without a current person; an assignment may be temporary. + +**Solution:** Model Person, Role, Position, Membership, and Assignment separately. + +**Result:** Better history, delegation, access modeling, accountability, and integration with HR, IAM, service ownership, and task systems. + +--- + +## 12.2 Pattern: Owner-Steward-Operator + +**Context:** Services, datasets, standards, systems, and controls need clear responsibility. + +**Problem:** “Owner” is often overloaded. + +**Solution:** Distinguish: + +```text +Owner + accountable for lifecycle and outcome. + +Steward + responsible for quality, interpretation, and care. + +Operator + responsible for running or executing operational activity. +``` + +**Used Concepts:** + +```text +Ownership +Stewardship +Responsibility +Accountability +Authority +Team +Role +``` + +--- + +## 12.3 Pattern: Matrix Without Confusion + +**Context:** A person belongs to a functional department but works in a product or project team. + +**Problem:** One hierarchy cannot represent both skill development and delivery accountability. + +**Solution:** Model multiple relationship types: + +```text +functional_reports_to +project_reports_to +product_reports_to +member_of +assigned_to +accountable_for +``` + +**Result:** The model can represent functional, matrix, projectized, and product-aligned structures. + +--- + +## 12.4 Pattern: Recursive Viability + +**Context:** Organizations need autonomy and coordination at multiple scales. + +**Problem:** Centralized control does not scale, but uncontrolled autonomy fragments the organization. + +**Solution:** Model operating units as recursively viable units with patterns for: + +```text +operation +coordination +control +intelligence +policy +``` + +**Note:** This pattern is inspired by the Viable System Model but does not require every organization to implement VSM terminology directly. + +--- + +## 12.5 Pattern: Role is Not Permission + +**Context:** Systems often confuse organizational roles with access-control roles. + +**Problem:** A role such as “Product Owner” is not the same as a permission set in an IAM system. + +**Solution:** Model organizational roles separately from access entitlements. + +Access-control standards may map roles to permissions, but should not own generic organizational role semantics. + +--- + +## 12.6 Pattern: Temporary Organization + +**Context:** Projects, incident response teams, ventures, and task forces form temporarily. + +**Problem:** Formal org charts cannot represent temporary collaboration structures well. + +**Solution:** Model temporary organizations or collaborations with explicit validity intervals, purpose, members, authority, and dissolution conditions. + +--- + +## 12.7 Pattern: Accountability Scope + +**Context:** People ask “who owns this?” but the answer depends on scope. + +**Problem:** Ownership without scope creates confusion. + +**Solution:** Every ownership or accountability relationship SHOULD declare its scope. + +Examples: + +```text +service lifecycle +runtime operation +budget +security posture +data quality +architectural coherence +customer outcome +``` + +--- + +# 13. Organization Profiles + +## 13.1 Profile Format + +An Organization Profile SHALL declare: + +```yaml +id: +profile_name: +status: +implements: + - InfoTechCanonOrganizationModel +target_context: +included_concepts: +required_relationships: +required_metadata: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +--- + +## 13.2 Seed Profile: Small SaaS Organization Profile + +Purpose: + +```text +Provide a minimal organization model for a small SaaS platform or product company. +``` + +Included concepts: + +```text +Organization +Team +Person +Agent +Role +Membership +Assignment +Responsibility +Accountability +Authority +Ownership +Stewardship +ReportingLine +``` + +Required relationships: + +```text +Person member_of Team +Team owns Service +Team operates RuntimePlatform +Person plays_role Role +Role responsible_for Scope +Team accountable_for Service +Agent assigned_to AutomationScope +``` + +--- + +## 13.3 Seed Profile: Service Ownership Profile + +Purpose: + +```text +Define the minimum organization structure required to connect teams and people to services in the Landscape Model. +``` + +Included concepts: + +```text +Team +Person +Role +ServiceOwner +TechnicalOwner +Operator +SupportGroup +Ownership +Responsibility +Escalation +``` + +Required relationships: + +```text +ApplicationService owned_by Team +TechnicalService operated_by Team +Person plays_role ServiceOwner +ServiceOwner accountable_for Service +SupportGroup supports Service +Incident escalates_to SupportGroup +``` + +--- + +## 13.4 Seed Profile: Human-Agent Organization Profile + +Purpose: + +```text +Support systems where humans and AI/software agents collaborate as actors. +``` + +Included concepts: + +```text +Person +Agent +Team +Role +Assignment +Authority +Delegation +Responsibility +Supervision +AuditReference +``` + +Required relationships: + +```text +Agent assigned_to TaskScope +Agent operates_under Authority +Person supervises Agent +Agent emits AuditEvent +Person accountable_for AgentScope +``` + +--- + +## 13.5 Seed Profile: Matrix Project Organization Profile + +Purpose: + +```text +Support organizations where people report functionally while being assigned to projects, products, or programs. +``` + +Included concepts: + +```text +Person +FunctionalUnit +ProjectTeam +ProductTeam +ProjectRole +FunctionalRole +ReportingLine +Assignment +Capacity +Availability +``` + +Required relationships: + +```text +Person member_of FunctionalUnit +Person assigned_to ProjectTeam +Person functional_reports_to Manager +Person project_reports_to ProjectLead +ProjectTeam accountable_for Deliverable +FunctionalUnit responsible_for SkillDevelopment +``` + +--- + +# 14. Mapping Model for the Organization Standard + +Mappings relate InfoTechCanon organization concepts to external standards, frameworks, products, and regulations. + +## 14.1 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +regulatoryReference +``` + +## 14.2 Mapping Record + +Example: + +```yaml +id: itc-map:org-team-to-w3c-org-organizational-unit +source_concept: itc-org:Team +target_body: W3C Organization Ontology +target_version: "2014 Recommendation" +target_concept: org:OrganizationalUnit +mapping_type: closeMatch +scope: + - structural or working groups represented as organizational units +not_valid_for: + - informal chat groups + - access-control-only groups +rationale: > + Teams may often be represented as organizational units in linked data, + but InfoTechCanon distinguishes teams from formal organizational units. +confidence: medium +status: candidate +owner: InfoTechCanonOrganizationModel +``` + +## 14.3 Seed Mapping Targets + +The Organization Model SHOULD maintain mappings to: + +```text +W3C Organization Ontology +OMG Commons Organizations +ArchiMate organization and actor concepts +OMG Business Motivation Model references +ISO 19439 / ISO 19440 enterprise modeling constructs +ISO 9001 roles, responsibilities, and authorities +ISO 30414 human capital reporting concepts +ISO 26000 stakeholder and social responsibility concepts +ITIL roles and service organization concepts +COBIT organizational structures and governance components +PMBOK organizational structures and responsibility assignment concepts +RACI / RASCI responsibility assignment models +HRIS / IAM / directory service models +``` + +--- + +# 15. Assimilation Hooks + +The Organization Model SHALL be able to receive new bodies of organizational knowledge through the InfoTechCanon assimilation process. + +## 15.1 Assimilation Triggers + +Assimilation may be triggered by: + +```text +new organization theory +new HR standard +new governance framework +new ITSM practice +new project-management model +new company operating model +new legal structure +new identity or access model +new collaboration tooling model +new agentic organization pattern +``` + +## 15.2 Organization Assimilation Output + +An organization assimilation SHOULD produce: + +```text +source summary +extracted organization concepts +concept comparison matrix +gap list +conflict list +mapping file +candidate new concepts +candidate relationship changes +candidate pattern changes +candidate profile changes +open questions +``` + +## 15.3 Recommended First Assimilation Candidates + +```text +W3C Organization Ontology +ArchiMate organization-related concepts +PMBOK organizational structures and RACI +ITIL role and practice ownership concepts +COBIT governance components and organizational structures +ISO 9001 roles, responsibilities, and authorities +VSM organizational viability patterns +ISO 30414 human capital reporting +``` + +--- + +# 16. Integration with Other InfoTechCanon Standards + +## 16.1 Landscape Model + +Landscape imports organization concepts for: + +```text +service ownership +support groups +runtime operation +technical stewardship +incident escalation +data ownership +system accountability +``` + +## 16.2 Governance Model + +Governance imports organization concepts for: + +```text +policy ownership +control ownership +decision authority +risk ownership +audit accountability +exception approval +``` + +## 16.3 Task Model + +Task imports organization concepts for: + +```text +assignee +requester +responsible actor +accountable actor +reviewer +approver +team ownership +capacity +availability +``` + +## 16.4 Access Control Model + +Access Control imports organization concepts for: + +```text +person +agent +group +role reference +membership +authority +delegation +``` + +But Access Control owns: + +```text +permission +entitlement +credential +access policy +authorization decision +privilege +``` + +## 16.5 Tagging Standard + +Tagging imports organization concepts for tags such as: + +```text +team +owner +stakeholder +business-unit +responsibility-area +``` + +--- + +# 17. Canon Interface Card Usage + +Subsystems that implement or produce organization knowledge SHOULD publish a Canon Interface Card. + +Example: + +```yaml +subsystem: user-engine +implements: + - InfoTechCanonOrganizationModel + - HumanAgentOrganizationProfile +produces: + - Person + - Agent + - Group + - Membership + - RoleAssignment +consumes: + - Organization + - Team + - Policy +relations: + - Person member_of Team + - Person plays_role Role + - Agent assigned_to AutomationScope +source_of_truth: + person_identity: user-engine + group_membership: user-engine +known_deviations: + - does not model employment contracts + - does not model compensation +``` + +--- + +# 18. Retrieval Requirements + +The Organization Model is designed for markdown-based infospaces. + +## 18.1 Required Retrieval Properties + +Every major concept SHOULD provide: + +- stable heading, +- stable identifier, +- short definition, +- longer explanation, +- examples, +- distinction notes, +- relationship examples, +- mapping hooks, +- profile references, +- and common mistakes. + +## 18.2 Agent Brief + +A mature Organization Model SHOULD include an `agent-brief.md` file with: + +```text +purpose +scope +owned concepts +imported concepts +core distinctions +do / do not rules +relationship patterns +minimal examples +common mistakes +profile list +mapping list +``` + +## 18.3 Indexes + +The organization information space SHOULD provide indexes by: + +```text +concept +relationship +role type +actor type +profile +pattern +mapping target +status +source system +``` + +--- + +# 19. Conformance Levels + +## 19.1 Reference-Conformant + +A document or system is reference-conformant if it uses Organization Model terminology consistently but does not implement structured metadata or validation rules. + +## 19.2 Metadata-Conformant + +A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types. + +## 19.3 Relationship-Conformant + +A system is relationship-conformant if it represents memberships, assignments, responsibilities, accountabilities, authorities, and reporting lines as explicit relationships. + +## 19.4 Temporal-Conformant + +A system is temporal-conformant if memberships, assignments, roles, responsibilities, and reporting lines can carry validity intervals. + +## 19.5 Profile-Conformant + +A system is profile-conformant if it implements a declared Organization Profile and passes its validation rules. + +## 19.6 Assimilation-Conformant + +A system or repository is assimilation-conformant if it can accept external organization concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes. + +--- + +# 20. Validation Rules + +Initial validation rules: + +```text +VAL-ORG-001: Person, Role, Position, Membership, and Assignment SHOULD be modeled as distinct concepts. + +VAL-ORG-002: A Role MUST NOT be treated as identical to an access-control permission set unless declared by an Access Control profile. + +VAL-ORG-003: A Group MUST NOT imply shared responsibility unless a Responsibility relationship is present. + +VAL-ORG-004: Membership MUST NOT imply authority unless an Authority or Assignment relationship is present. + +VAL-ORG-005: ReportingLine SHOULD specify its type when more than one reporting logic exists. + +VAL-ORG-006: Responsibility SHOULD declare a scope. + +VAL-ORG-007: Accountability SHOULD declare a scope and accountable actor. + +VAL-ORG-008: Authority SHOULD declare its scope and limits. + +VAL-ORG-009: Time-bounded assignments SHOULD include valid_from and valid_to when available. + +VAL-ORG-010: Imported external concepts SHOULD be represented through mapping records rather than silently reused. + +VAL-ORG-011: Profiles MUST NOT redefine canonical concepts. They may constrain them. + +VAL-ORG-012: Human and non-human actors SHOULD be distinguishable in systems that include automation or AI agents. + +VAL-ORG-013: Sensitive personal data SHOULD NOT be included unless required by a declared profile and justified purpose. + +VAL-ORG-014: Organization references used by other standards SHOULD resolve to Organization Model concepts or declared mappings. +``` + +--- + +# 21. Anti-Patterns + +## 21.1 Person Equals Role + +Treating a named person as if they were the role itself. + +## 21.2 Group Equals Team + +Treating every collection of people as a team with shared responsibility. + +## 21.3 Membership Equals Authority + +Assuming membership in a group grants decision power. + +## 21.4 Org Chart as Organization + +Treating the formal reporting hierarchy as the complete organization. + +## 21.5 Hidden Matrix + +Using only one reporting line while project, product, functional, and operational structures coexist. + +## 21.6 Owner Means Everything + +Using “owner” for every kind of responsibility, accountability, stewardship, operation, and approval. + +## 21.7 Access Role Leakage + +Letting IAM permission roles define organizational semantics. + +## 21.8 Eternal Assignment + +Failing to model time-bound roles, project assignments, temporary teams, or delegated authority. + +## 21.9 Human-Only Organization + +Ignoring software agents, AI agents, service accounts, and automation actors in modern organizations. + +--- + +# 22. Initial Repository Placement + +Recommended repository layout: + +```text +info-tech-canon/ + standards/ + organization/ + InfoTechCanonOrganizationModel.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +Seed files: + +```text +standards/organization/InfoTechCanonOrganizationModel.md +standards/organization/agent-brief.md +standards/organization/concepts/actor.md +standards/organization/concepts/person.md +standards/organization/concepts/role.md +standards/organization/concepts/team.md +standards/organization/concepts/responsibility.md +standards/organization/concepts/authority.md +standards/organization/patterns/person-role-assignment-split.md +standards/organization/patterns/owner-steward-operator.md +standards/organization/patterns/matrix-without-confusion.md +standards/organization/profiles/small-saas-organization-profile.md +standards/organization/profiles/service-ownership-profile.md +standards/organization/profiles/human-agent-organization-profile.md +standards/organization/mappings/w3c-org.yaml +standards/organization/mappings/archimate.yaml +standards/organization/mappings/raci.yaml +``` + +--- + +# 23. Roadmap + +## Phase 1: Seed Stabilization + +- Establish this standard as `InfoTechCanonOrganizationModel`. +- Extract organization concepts from the Landscape Model. +- Add seed concepts, relationship vocabulary, patterns, and profiles. +- Define validation rules. + +## Phase 2: Core Alignment + +- Align with `InfoTechCanonCore` once defined. +- Move generic mapping, profile, pattern, provenance, and conformance mechanics into Core. +- Keep only organization-specific applications here. + +## Phase 3: Governance Boundary + +- Create or align with `InfoTechCanonGovernanceModel`. +- Move policies, controls, risks, obligations, evidence, and decision governance to Governance. +- Keep actor, authority, accountability, and responsibility concepts here. + +## Phase 4: First Assimilations + +Recommended first assimilations: + +```text +W3C Organization Ontology +RACI / responsibility assignment models +ArchiMate organization-related concepts +ITIL role concepts +VSM viability functions +COBIT governance components +ISO 9001 clause 5.3 concepts +``` + +## Phase 5: Tooling Integration + +- Generate concept indexes. +- Generate agent brief. +- Create machine-readable YAML/JSON exports. +- Add validation scripts. +- Use in `user-engine`, `landscape`, `task`, `access-control`, and governance-related repositories. + +--- + +# 24. Summary + +The InfoTechCanon Organization Model is the seed standard for modeling organizational reality across the InfoTechCanon information space. + +Its most important commitments are: + +```text +Separate person, actor, role, position, membership, assignment, +responsibility, accountability, authority, and ownership. + +Model organization as a network of formal and informal structures, +not merely as a hierarchy. + +Support matrix, project, product, functional, temporary, and human-agent organizations. + +Keep governance, access control, task management, and landscape modeling +orthogonal but interoperable. + +Use mappings and assimilation to stay connected to external standards +without surrendering internal semantic autonomy. +``` + +This makes the Organization Model a practical structural foundation for interoperable systems, service ownership, task assignment, governance, access control, agent collaboration, and future organizational intelligence. diff --git a/seeds/InfoTechCanonSecurityModel_RC1_seed.md b/seeds/InfoTechCanonSecurityModel_RC1_seed.md new file mode 100755 index 0000000..29c85a4 --- /dev/null +++ b/seeds/InfoTechCanonSecurityModel_RC1_seed.md @@ -0,0 +1,2234 @@ +# InfoTechCanon Security Model + +**Short Name:** `ITC-SEC` +**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:** Security architects, platform engineers, DevSecOps teams, service owners, risk managers, governance designers, incident responders, vulnerability managers, detection engineers, software assurance teams, access-control designers, knowledge-system builders, and agentic tooling. + +--- + +# 1. Purpose + +The **InfoTechCanon Security Model** defines a canonical seed model for representing cybersecurity posture, threats, weaknesses, vulnerabilities, exposures, findings, attack paths, mitigations, detections, incidents, response, recovery, and security assurance across information-processing systems. + +It exists to connect security knowledge to the rest of InfoTechCanon without duplicating governance, access control, landscape, organization, task, or tagging semantics. + +This standard provides: + +- a canonical vocabulary for security entities, +- a distinction between threat, weakness, vulnerability, exposure, finding, risk, incident, and control, +- security-specific mappings to external frameworks and taxonomies, +- support for vulnerability management and threat-informed defense, +- support for detection, response, and recovery, +- support for software and platform security posture, +- support for security findings and remediation tasks, +- support for attack-path and exposure modeling, +- support for security evidence and assurance, +- profile hooks for concrete implementation contexts, +- and retrieval-friendly structure for humans, agents, and markdown-based infospaces. + +--- + +# 2. Position in InfoTechCanon + +The Security Model is a **domain standard** within InfoTechCanon. + +It depends on the existing seed standards as follows: + +```text +Landscape = systems, services, resources, data, endpoints, runtime, networks. +Organization = actors, owners, responders, teams, responsibilities. +Governance = policies, controls, control objectives, risk, exception, evidence. +Task = remediation, investigation, response, review, and hardening work. +Tagging = classification of findings, assets, vulnerabilities, and evidence. +Access Control = authorization, permissions, privileges, grants, decisions, and sessions. +Security = threats, weaknesses, vulnerabilities, exposure, attack paths, + incidents, detection, response, recovery, and posture. +``` + +```text +InfoTechCanon +├── InfoTechCanonCore +├── InfoTechCanonLandscapeModel +├── InfoTechCanonOrganizationModel +├── InfoTechCanonGovernanceModel +├── InfoTechCanonTaskModel +├── InfoTechCanonTaggingStandard +├── InfoTechCanonAccessControlModel +├── InfoTechCanonSecurityModel <-- this standard +├── InfoTechCanonDataModel +├── InfoTechCanonDevSecOpsModel +├── InfoTechCanonNetworkModel +├── InfoTechCanonObservabilityModel +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +--- + +# 3. Boundary with Adjacent Standards + +## 3.1 Boundary with Governance + +The Governance Model owns: + +```text +Policy +Rule +ControlObjective +Control +Risk +Exception +Evidence +Audit +Assurance +ComplianceRequirement +Decision +Approval +Review +``` + +The Security Model owns: + +```text +Threat +ThreatActor +AttackTechnique +Weakness +Vulnerability +Exposure +SecurityFinding +SecurityIncident +AttackPath +Mitigation +Detection +SecuritySignal +SecurityPosture +SecurityAssuranceSignal +``` + +Boundary rule: + +```text +Governance defines the rule, control, risk, exception, evidence, and assurance structure. +Security defines the adversarial, defensive, vulnerability, incident, detection, and posture semantics. +``` + +## 3.2 Boundary with Access Control + +The Access Control Model owns: + +```text +Subject +Principal +Permission +Privilege +Entitlement +Grant +AuthorizationDecision +AccessSession +AccessReview +BreakGlassAccess +AgentAccess +``` + +The Security Model may analyze these as security-relevant. + +Examples: + +```text +ExcessAccess is an AccessFinding and may also be a SecurityFinding. +PrivilegeEscalationPath is a Security AttackPath involving AccessControl entities. +CredentialMisuse is a SecurityIncident involving AccessSession and CredentialReference. +``` + +## 3.3 Boundary with Landscape + +The Landscape Model owns: + +```text +Service +ApplicationService +SoftwareComponent +Repository +Artifact +RuntimeResource +NetworkEndpoint +Dataset +Environment +NetworkPath +ObservabilitySignal +``` + +Security applies to those entities. + +Examples: + +```text +Vulnerability affects Artifact +Exposure affects Endpoint +AttackPath traverses NetworkPath +SecurityIncident affects Service +Mitigation applies_to RuntimeResource +``` + +## 3.4 Boundary with Task + +The Task Model owns work semantics. + +Security creates or references tasks such as: + +```text +RemediationTask +IncidentTask +InvestigationTask +HardeningTask +ReviewTask +ApprovalTask +SecurityExceptionTask +``` + +## 3.5 Boundary with DevSecOps + +The DevSecOps Model should own delivery pipeline, build, release, artifact, SBOM, attestation, and deployment semantics. + +The Security Model owns security interpretation of those entities. + +Examples: + +```text +SCAFinding affects Artifact +SBOMEvidence supports VulnerabilityAssessment +PolicyGate enforces SecurityControlImplementation +UnsignedArtifact is SecurityFinding +``` + +--- + +# 4. Research Basis and External Alignment + +This seed standard draws on multiple security knowledge bodies. + +## 4.1 NIST Cybersecurity Framework 2.0 + +NIST CSF 2.0 organizes cybersecurity outcomes into six high-level functions: Govern, Identify, Protect, Detect, Respond, and Recover. The Security Model uses these as a useful security lifecycle mapping target while leaving general governance semantics to the Governance Model. + +## 4.2 MITRE ATT&CK + +MITRE ATT&CK is a knowledge base of adversary tactics and techniques based on real-world observations. It is a strong mapping target for threat-informed defense, detection coverage, adversary behavior, attack techniques, and mitigations. + +## 4.3 CVE, CWE, CVSS, and EPSS + +CVE provides common identifiers for publicly known information-security vulnerabilities. CWE provides common software and hardware weakness types. CVSS communicates vulnerability characteristics and severity, while EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days. + +The Security Model must distinguish: + +```text +Weakness -> class of flaw or error pattern. +Vulnerability -> specific exploitable flaw or exposure. +Severity -> technical impact characteristics. +Exploit likelihood -> probability or evidence of exploitation. +Risk -> context-specific uncertainty or exposure relative to objectives. +``` + +## 4.4 OWASP ASVS and SAMM + +OWASP ASVS provides a basis for testing web application technical security controls and secure development requirements. OWASP SAMM provides an open framework for formulating and improving a software security strategy. These are important mapping and assimilation targets for application security and software assurance. + +## 4.5 Security Operations and Incident Response + +Security operations practice distinguishes signals, detections, alerts, incidents, investigations, containment, eradication, recovery, lessons learned, and evidence. + +## 4.6 Attack Graphs and Exposure Management + +Modern exposure management and attack-path analysis combine vulnerabilities, misconfigurations, identity permissions, network reachability, data sensitivity, and runtime context to prioritize security work. + +--- + +# 5. Seed Standard Design Stance + +This standard is a **seed standard**, not a full security program manual. + +It shall: + +1. define canonical security semantics, +2. distinguish security from governance and access control, +3. support vulnerability, weakness, exposure, finding, and risk separation, +4. support threat-informed defense and attack-path modeling, +5. support detection, incident, response, and recovery concepts, +6. support software, platform, cloud, network, identity, data, and operational security, +7. support human and agentic security contexts, +8. map to external taxonomies without becoming subordinate to them, +9. remain markdown-first and agent-retrievable, +10. and support future assimilation of security standards, frameworks, products, and research. + +--- + +# 6. Scope + +## 6.1 In Scope + +This standard covers canonical representation of: + +- security posture, +- security domains, +- assets as security-relevant landscape references, +- threat actors, +- threat events, +- attack techniques, +- attack patterns, +- attack paths, +- weaknesses, +- vulnerabilities, +- exposures, +- misconfigurations, +- security findings, +- security signals, +- detections, +- alerts, +- incidents, +- investigations, +- containment, +- eradication, +- recovery, +- mitigations, +- compensating security measures, +- exploitability, +- severity, +- exploit likelihood, +- asset criticality reference, +- security impact, +- blast radius, +- security evidence, +- security assurance signals, +- security exceptions as governance references, +- remediation references, +- and security mappings. + +## 6.2 Out of Scope + +This standard does not fully define: + +- general governance policy and control theory, +- full legal and regulatory compliance, +- complete access-control implementation, +- complete incident-response playbooks, +- complete malware analysis, +- full cryptographic protocol design, +- detailed secure coding standards, +- complete cloud provider security models, +- complete SIEM query languages, +- or all security product schemas. + +Those may be mapped, assimilated, profiled, or handled by adjacent standards. + +--- + +# 7. 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 defined provisionally here but open to later refinement. +- **EXTRACT** marks a concept that may later move to a more specialized standard. + +--- + +# 8. Core Principles + +## 8.1 Security Is Contextual + +A vulnerability, exposure, or finding becomes important through context: + +```text +affected asset +reachable path +exploitability +data sensitivity +privilege +business criticality +active exploitation +compensating controls +``` + +## 8.2 Vulnerability Is Not Risk + +A vulnerability is a flaw or exposure that may be exploitable. + +Risk is uncertainty or exposure relative to objectives and context. + +## 8.3 Weakness Is Not Vulnerability + +A weakness is a class of design, implementation, configuration, or hardware flaw. + +A vulnerability is a specific instance that may be exploited. + +## 8.4 Finding Is Not Always Vulnerability + +A finding may indicate: + +```text +vulnerability +misconfiguration +policy violation +weak control +suspicious activity +excess access +exposed service +missing evidence +``` + +## 8.5 Exposure Is First-Class + +A system may be at risk not only because it has a CVE, but because an asset is reachable, discoverable, misconfigured, overprivileged, or connected to sensitive data. + +## 8.6 Detection and Response Are Part of Posture + +Security posture includes not only prevention, but also detection, response, recovery, and assurance. + +## 8.7 Security Claims Need Evidence + +Important security claims SHOULD reference evidence, source, timestamp, confidence, and scope. + +## 8.8 External Taxonomies Are Mapped, Not Obeyed + +The Security Model MAY map to NIST CSF, MITRE ATT&CK, CVE, CWE, CVSS, EPSS, OWASP, ISO 27001, CIS, cloud provider controls, and product schemas. + +It MUST NOT subordinate its internal semantics to any single external framework. + +--- + +# 9. Canonical Seed Metadata + +Every security artifact SHOULD support structured metadata. + +Recommended front matter: + +```yaml +--- +id: itc-sec:Vulnerability +type: concept +standard: InfoTechCanonSecurityModel +standard_version: RC1-seed +status: candidate +canonical_owner: InfoTechCanonSecurityModel +preferred_label: Vulnerability +related: + - itc-sec:Weakness + - itc-sec:Exposure + - itc-sec:SecurityFinding + - itc-gov:Risk +mappings: + - itc-map:vulnerability-to-cve +--- +``` + +Recommended artifact statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +Recommended concept statuses: + +```text +proposed +experimental +candidate +canonical +deprecated +retired +``` + +--- + +# 10. Root Security Taxonomy + +```text +SecurityEntity +├── SecurityScopeEntity +│ ├── SecurityDomain +│ ├── SecurityBoundary +│ ├── SecurityZoneReference +│ ├── ProtectedAssetReference +│ └── SecurityPosture +├── ThreatEntity +│ ├── Threat +│ ├── ThreatActor +│ ├── ThreatEvent +│ ├── AttackTechnique +│ ├── AttackPattern +│ ├── Tactic +│ ├── CampaignReference +│ └── AdversaryCapability +├── WeaknessVulnerabilityEntity +│ ├── Weakness +│ ├── Vulnerability +│ ├── Exposure +│ ├── Misconfiguration +│ ├── Exploit +│ ├── Exploitability +│ ├── Severity +│ └── ExploitLikelihood +├── FindingEntity +│ ├── SecurityFinding +│ ├── VulnerabilityFinding +│ ├── MisconfigurationFinding +│ ├── ExposureFinding +│ ├── IdentityFinding +│ ├── DataSecurityFinding +│ ├── SupplyChainFinding +│ └── ControlWeaknessFinding +├── AttackPathEntity +│ ├── AttackPath +│ ├── AttackStep +│ ├── AttackPrecondition +│ ├── AttackImpact +│ ├── BlastRadius +│ └── ChokePoint +├── DefenseEntity +│ ├── Mitigation +│ ├── SecurityMeasure +│ ├── HardeningMeasure +│ ├── CompensatingMeasure +│ ├── DetectionRule +│ ├── DetectionCoverage +│ └── SecurityControlImplementationReference +├── DetectionResponseEntity +│ ├── SecuritySignal +│ ├── Detection +│ ├── Alert +│ ├── SecurityIncident +│ ├── Investigation +│ ├── Containment +│ ├── Eradication +│ ├── Recovery +│ └── LessonLearned +└── AssuranceEntity + ├── SecurityEvidence + ├── SecurityAssessment + ├── PenTestFinding + ├── SecurityReview + ├── SecurityExceptionReference + ├── SecurityAttestation + └── SecurityPostureScore +``` + +--- + +# 11. Core Concepts + +## 11.1 SecurityEntity + +A **SecurityEntity** is any identifiable concept used to represent security posture, adversarial behavior, defensive measures, vulnerabilities, incidents, findings, exposure, detection, response, or assurance. + +Recommended attributes: + +```yaml +id: +entity_type: +canonical_name: +display_name: +lifecycle_state: +source_system: +created_at: +updated_at: +``` + +Optional attributes: + +```yaml +owner: +steward: +security_domain: +affected_scope: +source_confidence: +valid_from: +valid_to: +tags: +external_references: +``` + +--- + +## 11.2 SecurityDomain + +A **SecurityDomain** is a scoped area of security concern. + +Examples: + +```text +application security +cloud security +identity security +data security +network security +endpoint security +supply-chain security +platform security +operational security +physical security +AI/agent security +``` + +--- + +## 11.3 SecurityBoundary + +A **SecurityBoundary** is a boundary across which trust, control, responsibility, policy, or exposure changes. + +Examples: + +```text +tenant boundary +network zone boundary +trust boundary +identity domain boundary +runtime namespace boundary +data classification boundary +external integration boundary +``` + +--- + +## 11.4 ProtectedAssetReference + +A **ProtectedAssetReference** points to a Landscape entity that requires security consideration. + +Examples: + +```text +service +repository +artifact +workload +endpoint +dataset +secret +identity +network segment +pipeline +environment +``` + +--- + +## 11.5 SecurityPosture + +**SecurityPosture** is the assessed security condition of an asset, service, domain, environment, or organization. + +Posture may derive from: + +```text +open findings +control effectiveness +exposure +vulnerability state +attack-path analysis +incident history +security reviews +patch state +detection coverage +access posture +configuration state +``` + +--- + +## 11.6 Threat + +A **Threat** is a potential cause of unwanted security impact. + +Threat may arise from: + +```text +adversary +accident +misuse +system failure +supply-chain dependency +insider +automation error +environmental condition +``` + +--- + +## 11.7 ThreatActor + +A **ThreatActor** is an actor or group that may intentionally cause security harm. + +Examples: + +```text +criminal group +state-sponsored actor +malicious insider +opportunistic attacker +hacktivist +automated botnet +``` + +--- + +## 11.8 ThreatEvent + +A **ThreatEvent** is an occurrence or attempted occurrence of adversarial or harmful activity. + +--- + +## 11.9 Tactic + +A **Tactic** is an adversary goal or phase of attack behavior. + +This concept maps naturally to MITRE ATT&CK tactics. + +--- + +## 11.10 AttackTechnique + +An **AttackTechnique** is a method used to achieve an adversary tactic or security objective. + +This concept maps naturally to MITRE ATT&CK techniques. + +--- + +## 11.11 AttackPattern + +An **AttackPattern** is a reusable pattern describing how an attack may be carried out. + +This may map to CAPEC, ATT&CK, or internal threat models. + +--- + +## 11.12 Weakness + +A **Weakness** is a class of flaw or error pattern in design, implementation, configuration, process, hardware, or architecture. + +Examples: + +```text +improper input validation +missing authentication +hardcoded credentials +insecure default configuration +insufficient logging +excess privilege +``` + +This concept maps to CWE where appropriate. + +--- + +## 11.13 Vulnerability + +A **Vulnerability** is a specific weakness, flaw, or exposure that may be exploited to violate security expectations. + +Vulnerability records may reference: + +```text +CVE +affected artifact +affected version +affected configuration +severity +exploitability +exploit evidence +fix version +workaround +``` + +--- + +## 11.14 Exposure + +An **Exposure** is a condition that increases the possibility of discovery, access, exploitation, data compromise, or impact. + +Examples: + +```text +publicly reachable endpoint +open management port +exposed secret +overly broad network path +internet-facing vulnerable service +excessive identity privilege +public storage bucket +``` + +Exposure may exist without a CVE. + +--- + +## 11.15 Misconfiguration + +A **Misconfiguration** is a configuration state that violates security expectation, policy, baseline, or safe design. + +--- + +## 11.16 Exploit + +An **Exploit** is code, technique, procedure, or method that uses a vulnerability, weakness, or exposure to cause security impact. + +--- + +## 11.17 Exploitability + +**Exploitability** is the practical ability to exploit a vulnerability or weakness in context. + +Exploitability may depend on: + +```text +network reachability +authentication requirement +privileges required +user interaction +known exploit availability +configuration +runtime condition +environment +``` + +--- + +## 11.18 Severity + +**Severity** is a measure of technical or potential impact characteristics. + +Severity is not the same as risk. + +--- + +## 11.19 ExploitLikelihood + +**ExploitLikelihood** is the estimated probability or plausibility that a vulnerability or exposure will be exploited. + +This concept may map to EPSS or internal threat intelligence. + +--- + +## 11.20 SecurityFinding + +A **SecurityFinding** is an observed security-relevant issue, weakness, vulnerability, misconfiguration, exposure, violation, detection result, or assessment result. + +Recommended attributes: + +```yaml +finding_type: +affected_entity: +severity: +confidence: +source: +first_seen: +last_seen: +status: +evidence: +recommended_action: +``` + +--- + +## 11.21 VulnerabilityFinding + +A **VulnerabilityFinding** is a finding that reports a vulnerability affecting an asset, artifact, dependency, configuration, or service. + +--- + +## 11.22 MisconfigurationFinding + +A **MisconfigurationFinding** is a finding that reports a security-relevant configuration problem. + +--- + +## 11.23 ExposureFinding + +An **ExposureFinding** is a finding that reports a reachable, discoverable, overexposed, or inappropriately public asset or path. + +--- + +## 11.24 IdentityFinding + +An **IdentityFinding** is a finding involving accounts, permissions, privileges, credentials, service accounts, sessions, or identity relationships. + +Examples: + +```text +stale access +orphaned account +excess privilege +unused admin role +credential exposed +weak MFA coverage +privilege escalation path +``` + +--- + +## 11.25 DataSecurityFinding + +A **DataSecurityFinding** is a finding involving sensitive data, classification, residency, retention, leakage, access, or processing exposure. + +--- + +## 11.26 SupplyChainFinding + +A **SupplyChainFinding** is a finding involving dependencies, packages, artifacts, repositories, pipelines, SBOMs, provenance, signatures, build systems, or external suppliers. + +--- + +## 11.27 AttackPath + +An **AttackPath** is a sequence of conditions, relationships, weaknesses, privileges, exposures, and actions that could allow an attacker to reach a target or cause impact. + +--- + +## 11.28 AttackStep + +An **AttackStep** is one step in an attack path. + +Examples: + +```text +phish user +obtain token +access repository +modify workflow +build malicious artifact +deploy to production +exfiltrate data +``` + +--- + +## 11.29 AttackPrecondition + +An **AttackPrecondition** is a condition required for an attack step or path. + +Examples: + +```text +network reachability +valid credentials +missing MFA +vulnerable package version +public endpoint +write access to repository +``` + +--- + +## 11.30 AttackImpact + +**AttackImpact** is the security consequence of a successful attack. + +Examples: + +```text +data exfiltration +service disruption +privilege escalation +code execution +persistence +lateral movement +integrity loss +supply-chain compromise +``` + +--- + +## 11.31 BlastRadius + +**BlastRadius** is the scope of assets, services, users, tenants, data, or obligations potentially affected by a security event or attack path. + +--- + +## 11.32 ChokePoint + +A **ChokePoint** is a point in an attack path where mitigation, monitoring, segmentation, control, or detection can significantly reduce attack feasibility or impact. + +--- + +## 11.33 Mitigation + +A **Mitigation** is an action, control, configuration, patch, design change, detection, process, or compensating measure that reduces security risk, exposure, exploitability, likelihood, or impact. + +--- + +## 11.34 SecurityMeasure + +A **SecurityMeasure** is a defensive measure used to protect, detect, respond, or recover. + +Security measures may implement Governance controls. + +--- + +## 11.35 HardeningMeasure + +A **HardeningMeasure** is a security measure that reduces attack surface or strengthens configuration. + +--- + +## 11.36 CompensatingMeasure + +A **CompensatingMeasure** is a security measure used when a preferred control or mitigation is unavailable, delayed, or waived. + +--- + +## 11.37 DetectionRule + +A **DetectionRule** is logic intended to detect suspicious, malicious, noncompliant, or security-relevant behavior. + +--- + +## 11.38 DetectionCoverage + +**DetectionCoverage** describes which threats, techniques, assets, or attack paths are covered by detection rules, telemetry, or monitoring. + +--- + +## 11.39 SecuritySignal + +A **SecuritySignal** is a telemetry-derived or assessment-derived signal relevant to security. + +Examples: + +```text +suspicious login +unexpected network connection +new vulnerable dependency +privilege change +malware detection +policy violation +secret exposure +``` + +--- + +## 11.40 Detection + +A **Detection** is a recognized security signal or correlation that may indicate a threat, weakness, violation, or incident. + +--- + +## 11.41 Alert + +An **Alert** is a notification generated by detection or monitoring logic that may require triage. + +--- + +## 11.42 SecurityIncident + +A **SecurityIncident** is an event or set of events that has compromised, or may compromise, confidentiality, integrity, availability, safety, privacy, trust, or compliance. + +--- + +## 11.43 Investigation + +An **Investigation** is work performed to determine the nature, scope, cause, impact, and response needs of a security signal, alert, finding, or incident. + +--- + +## 11.44 Containment + +**Containment** is action taken to limit the spread, persistence, or impact of an active or suspected security incident. + +--- + +## 11.45 Eradication + +**Eradication** is action taken to remove the cause, mechanism, malware, persistence, account compromise, or vulnerability enabling an incident. + +--- + +## 11.46 Recovery + +**Recovery** is action taken to restore safe, trusted, and acceptable operation after a security incident. + +--- + +## 11.47 LessonLearned + +A **LessonLearned** is knowledge extracted from a security incident, finding, test, audit, or failure. + +Lessons may create governance changes, tasks, controls, detections, or standards updates. + +--- + +## 11.48 SecurityEvidence + +**SecurityEvidence** is evidence supporting a security finding, assessment, incident, detection, mitigation, review, or assurance claim. + +Examples: + +```text +scan result +log event +trace +packet capture +screenshot +SBOM +attestation +configuration snapshot +forensic image reference +signed review +``` + +--- + +## 11.49 SecurityAssessment + +A **SecurityAssessment** is an evaluation of security posture, controls, architecture, code, configuration, exposure, or operation. + +--- + +## 11.50 PenTestFinding + +A **PenTestFinding** is a security finding produced by penetration testing or adversarial simulation. + +--- + +## 11.51 SecurityReview + +A **SecurityReview** is a review of design, code, configuration, architecture, policy, release, access, data, or operational practice from a security perspective. + +--- + +## 11.52 SecurityPostureScore + +A **SecurityPostureScore** is a derived metric summarizing security posture for a scope. + +Canonical rule: + +```text +SecurityPostureScore SHOULD be traceable to underlying findings, controls, +evidence, risk assumptions, and weighting model. +``` + +--- + +# 12. Core Relationship Vocabulary + +Recommended root relationship types: + +```text +affects +exposes +weakens +exploits +targets +threatens +uses_technique +maps_to_tactic +causes +enables +requires_precondition +traverses +leads_to +mitigates +detects +protects +contains +eradicates +recovers +evidenced_by +generated_by +reported_by +triaged_by +assigned_to +remediated_by +accepted_by +waived_by +compensated_by +maps_to +``` + +Relationship records SHOULD support: + +```yaml +id: +relationship_type: +source_entity: +target_entity: +scope: +valid_from: +valid_to: +source_system: +confidence: +evidence: +rationale: +``` + +--- + +# 13. Security State Models + +## 13.1 Finding States + +```text +new +triaged +confirmed +false_positive +accepted +remediation_planned +remediation_in_progress +mitigated +remediated +verified +closed +reopened +``` + +## 13.2 Vulnerability States + +```text +identified +affected +not_affected +under_investigation +fix_available +workaround_available +patched +mitigated +accepted +closed +``` + +## 13.3 Incident States + +```text +detected +triaged +investigating +contained +eradication_in_progress +recovery_in_progress +recovered +post_incident_review +closed +``` + +## 13.4 Detection States + +```text +candidate +active +tuning +suppressed +deprecated +retired +``` + +## 13.5 Mitigation States + +```text +proposed +approved +implemented +partially_implemented +validated +ineffective +superseded +retired +``` + +--- + +# 14. Security Patterns + +## 14.1 Pattern: Finding-to-Remediation Trace + +**Context:** Security tools produce findings. + +**Problem:** Findings do not automatically become resolved security improvements. + +**Solution:** + +```text +SecurityFinding + -> Risk / Severity / Exploitability Assessment + -> RemediationTask + -> Mitigation + -> Evidence + -> Verification + -> Closure +``` + +--- + +## 14.2 Pattern: Vulnerability Context Enrichment + +**Context:** A scanner reports a CVE. + +**Problem:** CVE severity alone is not enough to prioritize remediation. + +**Solution:** Enrich vulnerability findings with: + +```text +affected asset +runtime use +internet exposure +known exploit +EPSS or exploit likelihood +business criticality +data sensitivity +reachable path +compensating controls +fix availability +``` + +--- + +## 14.3 Pattern: Exposure Without CVE + +**Context:** A system is exposed or misconfigured but has no known CVE. + +**Problem:** Vulnerability-only programs miss security-relevant exposure. + +**Solution:** Model ExposureFinding and MisconfigurationFinding separately from VulnerabilityFinding. + +--- + +## 14.4 Pattern: Attack Path to Choke Point + +**Context:** Many findings exist, and not all can be fixed immediately. + +**Problem:** Remediation priority is unclear. + +**Solution:** Model attack paths and identify choke points where mitigation reduces multiple paths or large blast radius. + +--- + +## 14.5 Pattern: Detection Coverage Map + +**Context:** A team wants threat-informed defense. + +**Problem:** Detections are not linked to adversary techniques or protected assets. + +**Solution:** Map DetectionRules to AttackTechniques, SecuritySignals, and ProtectedAssetReferences. + +--- + +## 14.6 Pattern: Security Exception with Compensating Measure + +**Context:** A finding or control gap cannot be fixed immediately. + +**Problem:** Informal acceptance hides risk. + +**Solution:** Use Governance Exception with explicit security context, compensating measure, expiry, review, and evidence. + +--- + +## 14.7 Pattern: Incident-to-Lesson Loop + +**Context:** An incident is resolved. + +**Problem:** The same failure pattern recurs. + +**Solution:** + +```text +SecurityIncident + -> Investigation + -> Root Cause / Contributing Conditions + -> LessonLearned + -> Governance Change / Security Measure / Task / Detection +``` + +--- + +## 14.8 Pattern: Supply Chain Finding Trace + +**Context:** A dependency, build, artifact, or provenance issue is discovered. + +**Problem:** Security teams cannot connect the issue to runtime impact. + +**Solution:** + +```text +SupplyChainFinding + -> Dependency / Artifact / SBOM + -> DeploymentRecord + -> RuntimeWorkload + -> Service + -> RemediationTask +``` + +--- + +## 14.9 Pattern: Identity Exposure Path + +**Context:** Permissions, credentials, and relationships create security exposure. + +**Problem:** Identity risk is invisible when access data is isolated. + +**Solution:** Combine Access Control entities with Security attack path and finding concepts. + +--- + +# 15. Security Profiles + +## 15.1 Profile Format + +A Security Profile SHALL declare: + +```yaml +id: +profile_name: +status: +implements: + - InfoTechCanonSecurityModel +target_context: +included_concepts: +required_relationships: +required_metadata: +state_model: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +--- + +## 15.2 Seed Profile: Small SaaS Security Profile + +Purpose: + +```text +Provide a minimal security model for a small SaaS platform moving toward production readiness. +``` + +Included concepts: + +```text +SecurityDomain +ProtectedAssetReference +SecurityFinding +VulnerabilityFinding +MisconfigurationFinding +ExposureFinding +Mitigation +SecurityIncident +SecurityEvidence +SecurityReview +SecurityPosture +``` + +Required relationships: + +```text +SecurityFinding affects ProtectedAssetReference +VulnerabilityFinding maps_to CVE where available +MisconfigurationFinding violates SecurityExpectation +ExposureFinding exposes Endpoint +Mitigation mitigates SecurityFinding +SecurityIncident affects Service +SecurityEvidence evidences SecurityFinding +RemediationTask remediates SecurityFinding +``` + +--- + +## 15.3 Seed Profile: Vulnerability Management Profile + +Purpose: + +```text +Represent vulnerability findings from scanners, advisories, SBOM analysis, and runtime context. +``` + +Included concepts: + +```text +Vulnerability +Weakness +VulnerabilityFinding +AffectedComponent +Severity +ExploitLikelihood +Exploitability +FixVersion +Workaround +Mitigation +RemediationTask +VerificationEvidence +``` + +Required relationships: + +```text +VulnerabilityFinding affects Artifact +Vulnerability maps_to CVE +Weakness maps_to CWE +Severity maps_to CVSS +ExploitLikelihood maps_to EPSS +RemediationTask fixes VulnerabilityFinding +Evidence verifies Remediation +``` + +--- + +## 15.4 Seed Profile: Threat-Informed Defense Profile + +Purpose: + +```text +Map adversary tactics, techniques, detections, and mitigations. +``` + +Included concepts: + +```text +ThreatActor +Tactic +AttackTechnique +DetectionRule +DetectionCoverage +Mitigation +SecuritySignal +Alert +Investigation +``` + +Required relationships: + +```text +ThreatActor uses_technique AttackTechnique +AttackTechnique maps_to Tactic +DetectionRule detects AttackTechnique +Mitigation mitigates AttackTechnique +Alert generated_by DetectionRule +Investigation investigates Alert +``` + +--- + +## 15.5 Seed Profile: Application Security Profile + +Purpose: + +```text +Represent application security requirements, findings, reviews, and assurance. +``` + +Included concepts: + +```text +ApplicationSecurityRequirementReference +SecurityReview +CodeSecurityFinding +DependencyFinding +AuthenticationFinding +AuthorizationFinding +InputValidationFinding +DataProtectionFinding +SecurityTestEvidence +``` + +Mapping targets: + +```text +OWASP ASVS +OWASP Top 10 +OWASP SAMM +CWE +SAST / DAST / SCA tool schemas +``` + +--- + +## 15.6 Seed Profile: Supply Chain Security Profile + +Purpose: + +```text +Represent security posture across dependencies, builds, artifacts, SBOMs, provenance, signatures, and deployments. +``` + +Included concepts: + +```text +SupplyChainFinding +DependencyFinding +ArtifactFinding +ProvenanceFinding +SignatureFinding +SBOMEvidence +AttestationEvidence +BuildSystemExposure +RepositoryExposure +``` + +Required relationships: + +```text +SupplyChainFinding affects Artifact +SupplyChainFinding evidenced_by SBOM +Artifact deployed_to RuntimeWorkload +RuntimeWorkload part_of Service +Mitigation applies_to Pipeline +``` + +--- + +## 15.7 Seed Profile: Identity Security Profile + +Purpose: + +```text +Represent identity and access related security findings and attack paths. +``` + +Included concepts: + +```text +IdentityFinding +CredentialExposure +ExcessPrivilegeFinding +OrphanedAccountFinding +StaleAccessFinding +PrivilegeEscalationPath +AgentAccessFinding +``` + +Required relationships: + +```text +IdentityFinding affects Principal +CredentialExposure exposes CredentialReference +PrivilegeEscalationPath traverses AccessGrant +ExcessPrivilegeFinding remediated_by AccessRemediationTask +``` + +--- + +## 15.8 Seed Profile: Security Incident Response Profile + +Purpose: + +```text +Represent security incident lifecycle and response work. +``` + +Included concepts: + +```text +SecuritySignal +Detection +Alert +SecurityIncident +Investigation +Containment +Eradication +Recovery +LessonLearned +IncidentEvidence +PostIncidentReview +``` + +Required relationships: + +```text +Alert triggers Investigation +Investigation confirms SecurityIncident +Containment contains SecurityIncident +Eradication eradicates Cause +Recovery restores Service +LessonLearned creates Task +PostIncidentReview reviews SecurityIncident +``` + +--- + +# 16. Mapping Model for the Security Standard + +Mappings relate InfoTechCanon security concepts to external standards, frameworks, taxonomies, and products. + +## 16.1 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +regulatoryReference +toolEquivalent +``` + +## 16.2 Mapping Record + +Example: + +```yaml +id: itc-map:vulnerability-to-cve +source_concept: itc-sec:Vulnerability +target_body: CVE +target_version: "current" +target_concept: CVE Record / CVE Identifier +mapping_type: closeMatch +scope: + - publicly known vulnerabilities and exposures +not_valid_for: + - internal-only misconfigurations + - generic weakness classes + - findings without public vulnerability identifier +rationale: > + CVE identifies publicly known vulnerabilities and exposures, while InfoTechCanon + Vulnerability also covers internally identified vulnerabilities that may not have a CVE. +confidence: high +status: candidate +owner: InfoTechCanonSecurityModel +``` + +## 16.3 Seed Mapping Targets + +The Security Model SHOULD maintain mappings to: + +```text +NIST CSF 2.0 +MITRE ATT&CK +MITRE CAPEC +CVE +CWE +CVSS v4.0 +EPSS +CISA KEV +OWASP ASVS +OWASP SAMM +OWASP Top 10 +ISO/IEC 27001 / 27002 +CIS Controls +CSA Cloud Controls Matrix +SLSA +SPDX / CycloneDX security and vulnerability data +OpenSSF Scorecard +OSV +GitHub Security Advisories +SIEM / detection rule formats +Cloud security posture management schemas +Container and Kubernetes security benchmarks +``` + +--- + +# 17. Assimilation Hooks + +The Security Model SHALL be able to receive new security standards, frameworks, tools, products, and research through the InfoTechCanon assimilation process. + +## 17.1 Assimilation Triggers + +Assimilation may be triggered by: + +```text +new security framework +new vulnerability taxonomy +new threat intelligence source +new scanner schema +new incident-response model +new application-security standard +new supply-chain security standard +new cloud security benchmark +new security product integration +new recurring security classification conflict +``` + +## 17.2 Security Assimilation Output + +A security assimilation SHOULD produce: + +```text +source summary +extracted security concepts +concept comparison matrix +gap list +conflict list +mapping file +candidate new concepts +candidate relationship changes +candidate pattern changes +candidate profile changes +open questions +``` + +## 17.3 Recommended First Assimilation Candidates + +```text +NIST CSF 2.0 +MITRE ATT&CK +CVE / CWE / CVSS / EPSS +OWASP ASVS +OWASP SAMM +CIS Controls +ISO/IEC 27001 Annex A +SLSA +OpenSSF Scorecard +Kubernetes CIS Benchmark +``` + +--- + +# 18. Integration with Other InfoTechCanon Standards + +## 18.1 Governance Model + +Security imports governance concepts for: + +```text +policy +control objective +control +risk +exception +evidence +assurance +review +audit +compliance requirement +``` + +## 18.2 Access Control Model + +Security imports access concepts for: + +```text +principal +permission +privilege +grant +access session +access review +authorization decision +break-glass access +agent access +``` + +## 18.3 Landscape Model + +Security applies to landscape concepts such as: + +```text +service +repository +artifact +pipeline +runtime resource +endpoint +network path +dataset +environment +platform +tenant +``` + +## 18.4 Task Model + +Security creates or references tasks such as: + +```text +remediation task +incident task +investigation task +security review task +hardening task +verification task +``` + +## 18.5 Tagging Standard + +Security uses tags for: + +```text +severity +security domain +finding type +threat technique +exposure type +remediation priority +assurance status +``` + +Tags must not replace findings, risks, controls, or evidence. + +## 18.6 DevSecOps Model + +Security imports DevSecOps concepts for: + +```text +repository +commit +pipeline run +artifact +SBOM +attestation +release +deployment +policy gate +``` + +--- + +# 19. Canon Interface Card Usage + +Subsystems that implement or produce security knowledge SHOULD publish a Canon Interface Card. + +Example: + +```yaml +subsystem: vulnerability-scanner-importer +implements: + - InfoTechCanonSecurityModel + - VulnerabilityManagementProfile +produces: + - VulnerabilityFinding + - Severity + - Exploitability + - SecurityEvidence +consumes: + - Artifact + - RuntimeWorkload + - Repository + - SBOM +relations: + - VulnerabilityFinding affects Artifact + - VulnerabilityFinding maps_to CVE + - RemediationTask fixes VulnerabilityFinding +source_of_truth: + scanner_results: scanner +known_deviations: + - exploit likelihood is not provided by scanner + - runtime reachability must be enriched from landscape model +``` + +--- + +# 20. Retrieval Requirements + +The Security Model is designed for markdown-based infospaces. + +## 20.1 Required Retrieval Properties + +Every major concept SHOULD provide: + +- stable heading, +- stable identifier, +- short definition, +- longer explanation, +- examples, +- distinction notes, +- relationship examples, +- mapping hooks, +- profile references, +- and common mistakes. + +## 20.2 Agent Brief + +A mature Security Model SHOULD include an `agent-brief.md` file with: + +```text +purpose +scope +owned concepts +imported concepts +core distinctions +do / do not rules +relationship patterns +minimal examples +common mistakes +profile list +mapping list +``` + +## 20.3 Indexes + +The security information space SHOULD provide indexes by: + +```text +concept +relationship +security domain +finding type +threat technique +vulnerability identifier +weakness identifier +affected asset +mitigation +incident state +profile +pattern +mapping target +status +source system +``` + +--- + +# 21. Conformance Levels + +## 21.1 Reference-Conformant + +A document or system is reference-conformant if it uses Security Model terminology consistently but does not implement structured metadata or validation rules. + +## 21.2 Metadata-Conformant + +A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types. + +## 21.3 Relationship-Conformant + +A system is relationship-conformant if it represents findings, vulnerabilities, exposures, mitigations, attack paths, incidents, detections, and evidence as explicit relationships. + +## 21.4 Evidence-Conformant + +A system is evidence-conformant if security claims, findings, incident states, and mitigations can be linked to evidence. + +## 21.5 Context-Conformant + +A system is context-conformant if security prioritization can reference affected assets, exposure, exploitability, criticality, compensating controls, and remediation state. + +## 21.6 Profile-Conformant + +A system is profile-conformant if it implements a declared Security Profile and passes its validation rules. + +## 21.7 Assimilation-Conformant + +A system or repository is assimilation-conformant if it can accept external security concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes. + +--- + +# 22. Validation Rules + +Initial validation rules: + +```text +VAL-SEC-001: Weakness, Vulnerability, Exposure, Finding, and Risk SHOULD be modeled as distinct concepts. + +VAL-SEC-002: VulnerabilityFinding SHOULD identify affected asset, source, severity or equivalent rating, confidence, and status when available. + +VAL-SEC-003: CVE identifiers SHOULD be modeled as external mappings or references, not as the internal definition of Vulnerability. + +VAL-SEC-004: CWE identifiers SHOULD map to Weakness, not Vulnerability. + +VAL-SEC-005: CVSS or equivalent severity SHOULD NOT be treated as contextual risk without enrichment. + +VAL-SEC-006: ExploitLikelihood SHOULD be modeled separately from Severity. + +VAL-SEC-007: ExposureFinding SHOULD be allowed even when no CVE exists. + +VAL-SEC-008: SecurityFinding SHOULD reference evidence or source system. + +VAL-SEC-009: SecurityFinding SHOULD reference affected Landscape entity where possible. + +VAL-SEC-010: RemediationTask SHOULD reference the finding or condition it remediates. + +VAL-SEC-011: Security exceptions SHOULD reference Governance Exception or Waiver concepts. + +VAL-SEC-012: AttackPath SHOULD include at least one affected asset, precondition, or attack step. + +VAL-SEC-013: DetectionRule SHOULD reference the signal, technique, asset, or condition it is intended to detect. + +VAL-SEC-014: SecurityIncident SHOULD reference affected service, asset, or scope when known. + +VAL-SEC-015: SecurityPostureScore SHOULD be traceable to underlying evidence, findings, controls, or assumptions. + +VAL-SEC-016: Imported external security concepts SHOULD be represented through mapping records rather than silently reused. + +VAL-SEC-017: Profiles MUST NOT redefine canonical concepts. They may constrain them. + +VAL-SEC-018: Tags MUST NOT replace security findings, risks, controls, or evidence. +``` + +--- + +# 23. Anti-Patterns + +## 23.1 CVE Equals Risk + +Treating a CVE score as complete risk without considering context. + +## 23.2 Scanner Output as Truth + +Assuming tool findings are complete, correct, and context-aware without evidence, confidence, or validation. + +## 23.3 Finding Without Asset + +Recording findings that cannot be connected to affected systems, artifacts, services, or data. + +## 23.4 Severity as Priority + +Using severity alone for remediation priority. + +## 23.5 Vulnerability-Only Security + +Ignoring exposure, misconfiguration, identity risk, detection gaps, and attack paths. + +## 23.6 Permanent Risk Acceptance + +Accepting security risk without scope, rationale, authority, compensating measure, expiry, or review. + +## 23.7 Detection Without Coverage + +Creating detection rules without mapping them to assets, techniques, signals, or threats. + +## 23.8 Incident Without Lessons + +Closing incidents without lessons learned, remediation, governance updates, or detection improvements. + +## 23.9 Security Tags as Findings + +Using labels such as `security` or `critical` without actual finding, risk, or evidence records. + +## 23.10 Framework Subordination + +Bending the internal model around one framework, scanner, or vendor schema. + +--- + +# 24. Initial Repository Placement + +Recommended repository layout: + +```text +info-tech-canon/ + standards/ + security/ + InfoTechCanonSecurityModel.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +Seed files: + +```text +standards/security/InfoTechCanonSecurityModel.md +standards/security/agent-brief.md +standards/security/concepts/threat.md +standards/security/concepts/weakness.md +standards/security/concepts/vulnerability.md +standards/security/concepts/exposure.md +standards/security/concepts/security-finding.md +standards/security/concepts/attack-path.md +standards/security/concepts/mitigation.md +standards/security/concepts/security-incident.md +standards/security/patterns/finding-to-remediation-trace.md +standards/security/patterns/vulnerability-context-enrichment.md +standards/security/patterns/attack-path-to-choke-point.md +standards/security/profiles/small-saas-security-profile.md +standards/security/profiles/vulnerability-management-profile.md +standards/security/profiles/threat-informed-defense-profile.md +standards/security/profiles/supply-chain-security-profile.md +standards/security/mappings/nist-csf.yaml +standards/security/mappings/mitre-attack.yaml +standards/security/mappings/cve-cwe-cvss-epss.yaml +standards/security/mappings/owasp.yaml +``` + +--- + +# 25. Roadmap + +## Phase 1: Seed Stabilization + +- Establish this standard as `InfoTechCanonSecurityModel`. +- Add seed concepts, relationship vocabulary, patterns, and profiles. +- Define validation rules. +- Align with Governance, Access Control, Landscape, Task, and Tagging. + +## Phase 2: First Assimilations + +Recommended first assimilations: + +```text +NIST CSF 2.0 +MITRE ATT&CK +CVE / CWE / CVSS / EPSS +OWASP ASVS +OWASP SAMM +CIS Controls +ISO/IEC 27001 Annex A +SLSA +OpenSSF Scorecard +Kubernetes CIS Benchmark +``` + +## Phase 3: Profile Maturation + +- Mature Small SaaS Security Profile. +- Mature Vulnerability Management Profile. +- Mature Threat-Informed Defense Profile. +- Mature Application Security Profile. +- Mature Supply Chain Security Profile. +- Mature Identity Security Profile. +- Mature Incident Response Profile. + +## Phase 4: Tooling Integration + +- Generate concept indexes. +- Generate agent brief. +- Create machine-readable YAML/JSON exports. +- Add validation scripts. +- Integrate scanner results, SBOMs, runtime context, access reviews, observability, and task systems. + +## Phase 5: Security Intelligence Loop + +- Connect findings to remediation tasks. +- Connect incidents to lessons learned. +- Connect attack paths to landscape graph. +- Connect security posture to governance risk and assurance. +- Connect detection coverage to threat techniques and observability signals. + +--- + +# 26. Summary + +The InfoTechCanon Security Model is the seed standard for representing cybersecurity posture, threat, vulnerability, exposure, finding, attack path, detection, incident, response, recovery, mitigation, and assurance semantics. + +Its most important commitments are: + +```text +Separate weakness, vulnerability, exposure, finding, risk, and incident. + +Treat security context as essential for prioritization. + +Model attack paths and exposure, not only CVEs. + +Link findings to affected assets, evidence, remediation, mitigation, and verification. + +Map to NIST CSF, MITRE ATT&CK, CVE, CWE, CVSS, EPSS, OWASP, and other frameworks +without surrendering internal semantic autonomy. + +Import governance, access-control, task, tagging, and landscape concepts +instead of redefining them. + +Use profiles to make the model practical for vulnerability management, +threat-informed defense, application security, supply-chain security, +identity security, and incident response. +``` + +This makes the Security Model a core seed for production readiness, security posture management, DevSecOps assurance, incident response, risk-informed prioritization, and agent-supported security operations. diff --git a/seeds/InfoTechCanonTaggingStandard_RC1_seed.md b/seeds/InfoTechCanonTaggingStandard_RC1_seed.md new file mode 100755 index 0000000..8ca2ad8 --- /dev/null +++ b/seeds/InfoTechCanonTaggingStandard_RC1_seed.md @@ -0,0 +1,2037 @@ +# InfoTechCanon Tagging Standard + +**Short Name:** `ITC-TAG` +**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:** Repository maintainers, project managers, product owners, platform builders, DevSecOps teams, issue-tracker administrators, knowledge-system builders, taxonomy maintainers, standards authors, automation designers, and AI agents. + +--- + +# 1. Purpose + +The **InfoTechCanon Tagging Standard** defines a canonical seed model for creating, governing, mapping, validating, and using tags across InfoTechCanon-compatible systems. + +It exists to make tags useful without allowing them to become an uncontrolled substitute for real models, fields, relationships, workflow states, ownership, or governance artifacts. + +This standard provides: + +- a canonical vocabulary for tags and tag schemes, +- rules for tag identity, structure, naming, lifecycle, and ownership, +- a distinction between tags, labels, categories, fields, states, types, relationships, and controlled concepts, +- mechanisms for tag profiles, +- mechanisms for mapping tags to external tools and vocabularies, +- task-oriented tag dimensions, +- guidance for repository and issue-tracker labels, +- validation rules, +- anti-patterns, +- and retrieval-friendly structure for humans, agents, and markdown-based infospaces. + +--- + +# 2. Position in InfoTechCanon + +The Tagging Standard is a **domain standard** within InfoTechCanon. + +It should become the canonical owner of tagging mechanics and tag governance. + +It imports task semantics from the Task Model and must not redefine them. + +```text +InfoTechCanon +├── InfoTechCanonCore +├── InfoTechCanonLandscapeModel +├── InfoTechCanonOrganizationModel +├── InfoTechCanonGovernanceModel +├── InfoTechCanonTaskModel +├── InfoTechCanonTaggingStandard <-- this standard +├── InfoTechCanonAccessControlModel +├── InfoTechCanonSecurityModel +├── InfoTechCanonDataModel +├── InfoTechCanonDevSecOpsModel +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +The dependency chain is: + +```text +Task defines what work is. +Tagging defines how work and other entities are classified, filtered, and signaled. +``` + +--- + +# 3. Boundary with Adjacent Standards + +## 3.1 Boundary with Task + +The Task Model owns: + +```text +WorkItem +Option +Task +Action +NextAction +Step +Move +Experiment +WorkflowState +Commitment +Priority +Urgency +Importance +Blocker +Dependency +Outcome +AcceptanceCriteria +DefinitionOfDone +``` + +The Tagging Standard owns: + +```text +Tag +TagScheme +TagNamespace +TagCategory +TagValue +TagAssignment +TagProfile +TagAlias +TagMapping +TagLifecycle +TagValidationRule +``` + +Boundary rule: + +```text +Task semantics belong to the Task Model. +Tags may reference, encode, summarize, or filter task semantics, +but they do not define them. +``` + +## 3.2 Boundary with Organization + +Organization owns actors, roles, teams, ownership, membership, responsibility, authority, and accountability. + +Tags may reference organizational categories, but should not replace organization relationships. + +Example: + +```text +Good: + Team owns Service + Task assigned_to Person + Tag: team/platform + +Bad: + Only tag "team-platform" exists and no ownership or assignment relation exists. +``` + +## 3.3 Boundary with Governance + +Governance owns policies, controls, risks, obligations, decisions, approvals, exceptions, and evidence. + +Tags may identify governance-relevant work or artifacts, but should not replace policy/control/evidence records. + +## 3.4 Boundary with Landscape + +Landscape owns services, repositories, artifacts, runtime resources, networks, data stores, and systems. + +Tags may classify landscape entities, but should not replace first-class landscape relationships. + +## 3.5 Boundary with Access Control + +Tags may support access policy implementation in some systems, but the Access Control Model owns permissions, entitlements, authorization decisions, credentials, and privileges. + +Canonical rule: + +```text +A tag MUST NOT be treated as an access-control entitlement unless an access-control profile explicitly defines that behavior. +``` + +--- + +# 4. Research Basis and External Alignment + +This seed standard draws on multiple bodies of tagging and classification practice. + +## 4.1 Knowledge Organization and SKOS + +SKOS provides a strong model for concept schemes, preferred labels, alternative labels, broader/narrower relations, related relations, and mapping relations such as exact, close, broad, narrow, and related matches. + +InfoTechCanon does not need to become SKOS, but it should borrow the distinction between: + +```text +concept +label +scheme +broader/narrower relation +related relation +mapping relation +``` + +## 4.2 Controlled Vocabularies and Taxonomies + +Controlled vocabulary practice contributes the idea that uncontrolled labels become ambiguous and inconsistent unless terms have definitions, owners, scope, synonyms, and lifecycle states. + +## 4.3 Folksonomies and Collaborative Tagging + +Folksonomy practice shows that flexible user-created tags are valuable for discovery and emergence but become noisy without consolidation, aliases, namespaces, and stewardship. + +## 4.4 GitHub Labels + +GitHub labels are widely used to classify issues, pull requests, and discussions. GitHub provides default labels in repositories and allows organizations to manage default labels. This makes GitHub labels a practical mapping target for task and repository profiles. + +## 4.5 Jira Labels, Components, Versions, and Custom Fields + +Jira distinguishes labels from other categorization mechanisms such as components, versions, and custom fields. Labels are flexible, but components and versions may be better suited for stable structure, ownership, releases, and product areas. + +This distinction is critical for InfoTechCanon: tags should not swallow concepts that deserve first-class structure. + +## 4.6 Kubernetes Labels + +Kubernetes uses labels as key-value pairs attached to objects and supports selectors over labels. Kubernetes recommended labels such as application name, instance, version, component, part-of, and managed-by demonstrate how labeling conventions support interoperability and automation. + +## 4.7 Hashtags and Lightweight Social Tagging + +Hashtag practice contributes the idea that tags can be lightweight, emergent, user-facing signals. However, hashtags are usually weakly governed and therefore need transformation before becoming canonical tags. + +--- + +# 5. Seed Standard Design Stance + +This standard is a **seed standard**, not a final complete theory of classification. + +It shall: + +1. define enough canonical concepts for useful tagging across InfoTechCanon systems, +2. distinguish tags from canonical concepts, fields, states, types, and relationships, +3. support both controlled and emergent tags, +4. support scoped tag schemes and namespaces, +5. support mappings to external labels and vocabularies, +6. support validation and linting, +7. prevent tag soup, +8. support task, repository, DevSecOps, landscape, and knowledge-space use cases, +9. remain markdown-first and agent-retrievable, +10. and support future assimilation of tagging systems, taxonomies, and label conventions. + +--- + +# 6. Scope + +## 6.1 In Scope + +This standard covers canonical representation of: + +- tags, +- labels, +- tag schemes, +- tag namespaces, +- tag categories, +- tag keys, +- tag values, +- tag aliases, +- tag assignments, +- controlled tags, +- emergent tags, +- deprecated tags, +- tag mappings, +- tag profiles, +- tag validation rules, +- tag ownership, +- tag lifecycle, +- tag descriptions, +- tag color hints, +- tag visibility, +- tag selectors, +- tag-derived views, +- task-tag dimensions, +- repository labels, +- and markdown-front-matter tagging. + +## 6.2 Out of Scope + +This standard does not fully define: + +- task semantics, +- project management methodology, +- organization roles and ownership, +- governance policy and control models, +- access-control semantics, +- all taxonomy theory, +- full ontology modeling, +- full search-ranking behavior, +- all UI conventions for labels, +- or every tool-specific label system. + +Those may be mapped, assimilated, profiled, or handled by adjacent standards. + +--- + +# 7. 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 defined provisionally here but open to later refinement. +- **EXTRACT** marks a concept that may later move to a more specialized standard. + +--- + +# 8. Core Principles + +## 8.1 Tags Are Lightweight Classifiers + +A tag is a lightweight classifier attached to an entity. + +Tags are useful for filtering, grouping, search, routing, signaling, automation, and retrieval. + +## 8.2 Tags Are Not a Substitute for Models + +A tag MUST NOT replace a first-class concept, field, relationship, workflow state, ownership record, policy, or control when that structure is required for correctness. + +## 8.3 Tags Need Scope + +Every tag SHOULD belong to a tag scheme, namespace, profile, repository, or other defined scope. + +## 8.4 Tags Need Meaning + +A canonical tag SHOULD have a definition or at least a description. + +## 8.5 Tags Need Ownership + +A tag scheme SHOULD have an owner or steward. + +## 8.6 Tags May Be Controlled or Emergent + +The model SHALL support both governed controlled tags and emergent user-created tags. + +## 8.7 Tags Should Be Mappable + +Tags SHOULD be mappable to external labels, controlled vocabulary terms, issue-tracker labels, Kubernetes labels, taxonomy concepts, or InfoTechCanon concepts. + +## 8.8 Tag Syntax Is Not Tag Semantics + +The string `priority/high` does not define what priority means. + +Semantics come from the TagDefinition, imported standard concept, or profile. + +## 8.9 Profiles Make Tags Practical + +Concrete tag sets SHOULD be expressed as Tag Profiles. + +Examples: + +```text +GitHub Issue Tag Profile +Repository Label Profile +Task Tag Profile +DevSecOps Finding Tag Profile +Knowledge Space Tag Profile +Kubernetes Label Mapping Profile +``` + +--- + +# 9. Canonical Seed Metadata + +Every tag artifact SHOULD support structured metadata. + +Recommended front matter: + +```yaml +--- +id: itc-tag:Tag +type: concept +standard: InfoTechCanonTaggingStandard +standard_version: RC1-seed +status: candidate +canonical_owner: InfoTechCanonTaggingStandard +preferred_label: Tag +related: + - itc-tag:TagScheme + - itc-tag:TagAssignment + - itc-tag:TagProfile +mappings: + - itc-map:tag-to-skos-concept +--- +``` + +Recommended tag definition metadata: + +```yaml +id: +tag_key: +display_name: +description: +scheme: +namespace: +category: +status: +owner: +allowed_values: +applies_to: +source: +aliases: +mappings: +created_at: +updated_at: +``` + +Recommended artifact statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +Recommended tag statuses: + +```text +proposed +experimental +active +deprecated +superseded +blocked +retired +``` + +--- + +# 10. Root Tagging Taxonomy + +```text +TaggingEntity +├── TagDefinitionEntity +│ ├── Tag +│ ├── Label +│ ├── TagKey +│ ├── TagValue +│ ├── TagCategory +│ ├── TagNamespace +│ ├── TagScheme +│ ├── TagSet +│ └── TagProfile +├── TagUsageEntity +│ ├── TagAssignment +│ ├── TagSelector +│ ├── TagQuery +│ ├── TagView +│ ├── TagRule +│ └── TagPolicyReference +├── TagGovernanceEntity +│ ├── TagOwner +│ ├── TagSteward +│ ├── TagLifecycle +│ ├── TagAlias +│ ├── TagDeprecation +│ ├── TagReplacement +│ └── TagValidationRule +├── TagMappingEntity +│ ├── TagMapping +│ ├── ExternalLabelMapping +│ ├── ConceptMapping +│ ├── VocabularyMapping +│ └── ToolMapping +└── TagQualityEntity + ├── TagConflict + ├── TagDuplicate + ├── TagAmbiguity + ├── TagDrift + ├── UntaggedEntity + └── OverTaggedEntity +``` + +--- + +# 11. Core Concepts + +## 11.1 TaggingEntity + +A **TaggingEntity** is any identifiable concept used to define, assign, govern, map, validate, or analyze tags. + +Recommended attributes: + +```yaml +id: +entity_type: +canonical_name: +display_name: +lifecycle_state: +source_system: +created_at: +updated_at: +``` + +Optional attributes: + +```yaml +owner: +steward: +scheme: +namespace: +source_confidence: +valid_from: +valid_to: +external_references: +``` + +--- + +## 11.2 Tag + +A **Tag** is a lightweight classifier assigned to an entity. + +A tag may be represented as: + +```text +simple string +key-value pair +namespace/key +namespace/category/value +URI-linked concept +tool-specific label +markdown front-matter value +``` + +Canonical rule: + +```text +A canonical tag SHOULD have a TagDefinition. +``` + +--- + +## 11.3 Label + +A **Label** is a display-oriented or tool-specific representation of a tag. + +A label may include: + +```text +name +description +color +visibility +tool-specific identifier +``` + +Canonical rule: + +```text +Label is often a tool representation. Tag is the canonical classification concept. +``` + +--- + +## 11.4 TagDefinition + +A **TagDefinition** defines the meaning, scope, allowed use, ownership, and lifecycle of a tag. + +Recommended attributes: + +```yaml +tag_key: +display_name: +description: +scheme: +namespace: +category: +status: +owner: +applies_to: +examples: +anti_examples: +aliases: +mappings: +``` + +--- + +## 11.5 TagScheme + +A **TagScheme** is a coherent set of tag definitions governed together. + +Examples: + +```text +Task Tag Scheme +Repository Label Scheme +DevSecOps Finding Tag Scheme +Knowledge Space Tag Scheme +Kubernetes Label Mapping Scheme +``` + +--- + +## 11.6 TagNamespace + +A **TagNamespace** is a scope prefix used to prevent collisions and signal ownership or domain. + +Examples: + +```text +task/ +status/ +type/ +risk/ +area/ +team/ +repo/ +gov/ +sec/ +data/ +landscape/ +``` + +Recommended syntax: + +```text +namespace/key +namespace/key=value +namespace/category/value +``` + +Profiles may select one syntax. + +--- + +## 11.7 TagCategory + +A **TagCategory** groups tags by semantic dimension. + +Examples: + +```text +work-type +workflow-state +domain +scope +priority +urgency +risk +complexity +area +component +team +governance +security +data +source +lifecycle +``` + +Canonical rule: + +```text +TagCategory helps structure a tag scheme but is not itself necessarily a tag. +``` + +--- + +## 11.8 TagKey + +A **TagKey** is the key part of a key-value tag. + +Examples: + +```text +priority +type +status +area +component +team +risk +``` + +--- + +## 11.9 TagValue + +A **TagValue** is the value part of a key-value tag. + +Examples: + +```text +high +bug +blocked +frontend +platform +security +``` + +--- + +## 11.10 TagSet + +A **TagSet** is a selected set of tags used together for a scope. + +Examples: + +```text +default labels for a repository +task classification tags for a team +security finding labels +knowledge-base topic tags +``` + +--- + +## 11.11 TagProfile + +A **TagProfile** is a constrained tag scheme for a concrete implementation context. + +A profile defines: + +```text +allowed tags +required tags +forbidden tags +naming rules +mapping rules +validation rules +target tools +``` + +--- + +## 11.12 TagAssignment + +A **TagAssignment** is the relationship by which a tag is attached to an entity. + +Recommended attributes: + +```yaml +tag: +target_entity: +assigned_by: +assigned_at: +source_system: +confidence: +reason: +valid_from: +valid_to: +``` + +Canonical rule: + +```text +For mature systems, tag assignment SHOULD be distinguishable from tag definition. +``` + +--- + +## 11.13 TagSelector + +A **TagSelector** is a query or rule used to select entities based on tags. + +Examples: + +```text +all tasks tagged priority/high +all Kubernetes objects with app.kubernetes.io/part-of=billing +all documents tagged domain/governance +``` + +--- + +## 11.14 TagQuery + +A **TagQuery** is a query over tags. + +A tag query may support: + +```text +AND +OR +NOT +namespace filtering +category filtering +key-value filtering +broader/narrower expansion +alias expansion +``` + +--- + +## 11.15 TagView + +A **TagView** is a view generated or filtered by tags. + +Examples: + +```text +security work queue +blocked work view +governance remediation dashboard +repository issue board +knowledge space topic index +``` + +--- + +## 11.16 TagRule + +A **TagRule** is a rule constraining tag assignment or interpretation. + +Examples: + +```text +Only one priority tag may be assigned. +Every issue must have exactly one work-type tag. +Deprecated tags must not be assigned to new items. +A security finding must have a severity tag. +``` + +--- + +## 11.17 TagAlias + +A **TagAlias** is an alternative name for a tag. + +Aliases may exist for: + +```text +renaming +migration +tool-specific terms +synonyms +legacy labels +language variants +``` + +--- + +## 11.18 TagMapping + +A **TagMapping** maps a tag to another tag, external label, controlled vocabulary concept, InfoTechCanon concept, or tool-specific value. + +Mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +toolEquivalent +deprecatedReplacement +``` + +--- + +## 11.19 ControlledTag + +A **ControlledTag** is a tag governed by a TagScheme with defined meaning and allowed use. + +--- + +## 11.20 EmergentTag + +An **EmergentTag** is a user- or system-created tag that has not yet been reviewed, normalized, or accepted into a controlled scheme. + +Emergent tags are useful for discovery but should be reviewed if they become common. + +--- + +## 11.21 DeprecatedTag + +A **DeprecatedTag** is a tag that should no longer be used for new assignments. + +A deprecated tag SHOULD reference its replacement when one exists. + +--- + +## 11.22 TagConflict + +A **TagConflict** occurs when assigned tags contradict each other or violate a tag rule. + +Examples: + +```text +priority/high and priority/low assigned together +status/done and status/blocked assigned together +type/bug and type/feature assigned when the profile allows only one work type +``` + +--- + +## 11.23 TagDrift + +**TagDrift** occurs when a tag's actual use diverges from its definition. + +--- + +## 11.24 OverTaggedEntity + +An **OverTaggedEntity** is an entity with excessive, redundant, contradictory, or low-value tags. + +--- + +## 11.25 UntaggedEntity + +An **UntaggedEntity** is an entity missing tags required or expected by a profile. + +--- + +# 12. Recommended Tag Syntax + +InfoTechCanon does not require one syntax everywhere. + +However, profiles SHOULD choose one of the following forms. + +## 12.1 Slash Syntax + +```text +category/value +``` + +Examples: + +```text +type/bug +priority/high +area/frontend +risk/security +``` + +## 12.2 Key-Value Syntax + +```text +key=value +``` + +Examples: + +```text +type=bug +priority=high +area=frontend +risk=security +``` + +## 12.3 Namespace Key-Value Syntax + +```text +namespace/key=value +``` + +Examples: + +```text +task/type=bug +task/priority=high +landscape/component=frontend +gov/risk=security +``` + +## 12.4 Tool-Native Syntax + +Some tools only support flat labels. + +Example mappings: + +```text +task/type=bug -> type: bug +priority/high -> priority: high +gov/risk=security -> risk: security +``` + +Canonical rule: + +```text +Flat labels SHOULD be mapped to structured canonical tags when possible. +``` + +--- + +# 13. Recommended Tag Categories + +## 13.1 Universal Categories + +```text +type +status +domain +scope +area +component +team +owner +lifecycle +source +risk +priority +urgency +importance +complexity +confidence +``` + +## 13.2 Task Categories + +```text +work-type +workflow-state +commitment-state +actionability +reachability +blocker-type +dependency-type +review-state +outcome-state +``` + +## 13.3 Governance Categories + +```text +policy +control +risk +compliance +exception +evidence +review +approval +audit +``` + +## 13.4 Landscape Categories + +```text +service +application +repository +runtime +network +data +environment +platform +component +``` + +## 13.5 Security Categories + +```text +security-domain +severity +vulnerability +threat +control-gap +exposure +confidentiality +integrity +availability +``` + +## 13.6 Knowledge Space Categories + +```text +topic +concept +standard +pattern +profile +mapping +assimilation +status +maturity +``` + +--- + +# 14. Core Relationship Vocabulary + +Recommended root relationship types: + +```text +assigned_to +applies_to +belongs_to_scheme +belongs_to_namespace +belongs_to_category +aliases +replaces +deprecated_by +maps_to +conflicts_with +requires +forbids +implies +broader_than +narrower_than +related_to +selected_by +generated_by +validated_by +``` + +Relationship records SHOULD support: + +```yaml +id: +relationship_type: +source_tag_or_entity: +target_tag_or_entity: +scope: +valid_from: +valid_to: +source_system: +confidence: +evidence: +rationale: +``` + +--- + +# 15. Tag Lifecycle Model + +## 15.1 Tag Definition Lifecycle + +```text +proposed +experimental +active +deprecated +superseded +retired +blocked +``` + +## 15.2 Tag Assignment Lifecycle + +```text +suggested +assigned +confirmed +inferred +rejected +expired +removed +``` + +## 15.3 Tag Scheme Lifecycle + +```text +draft +candidate +active +maintenance +deprecated +retired +``` + +--- + +# 16. Tagging Patterns + +## 16.1 Pattern: Controlled Core, Emergent Edge + +**Context:** Teams need both consistency and flexibility. + +**Problem:** Fully controlled tags prevent discovery; fully emergent tags become noisy. + +**Solution:** Use a controlled core tag scheme and allow emergent tags at the edge. Review emergent tags periodically for promotion, aliasing, or cleanup. + +--- + +## 16.2 Pattern: Tag Profile Not Local Chaos + +**Context:** A team needs a local tag set. + +**Problem:** Local tags drift away from canonical meaning. + +**Solution:** Define a TagProfile that constrains canonical tags for the local context. + +--- + +## 16.3 Pattern: Tag is Signal, Field is Fact + +**Context:** Teams use tags to store structured data. + +**Problem:** Tags become unreliable substitutes for fields and relationships. + +**Solution:** Use tags for lightweight classification and signals. Use fields or relationships for facts that require correctness. + +Examples: + +```text +Good tag: + risk/security + +Better relationship: + Finding affects Artifact + +Good tag: + team/platform + +Better relationship: + Team owns Service +``` + +--- + +## 16.4 Pattern: One Dimension, One Category + +**Context:** Tags encode multiple dimensions at once. + +**Problem:** Tags such as `urgent-security-bug-backend` are hard to query and govern. + +**Solution:** Split dimensions: + +```text +priority/high +risk/security +type/bug +area/backend +``` + +--- + +## 16.5 Pattern: Alias Before Migration + +**Context:** A tag must be renamed. + +**Problem:** Renaming breaks queries, dashboards, and automation. + +**Solution:** Create TagAlias and TagReplacement records before migrating assignments. + +--- + +## 16.6 Pattern: Default Repository Label Set + +**Context:** New repositories need consistent labels. + +**Problem:** Each repository invents incompatible labels. + +**Solution:** Define a repository label profile and generate tool-specific labels from it. + +--- + +## 16.7 Pattern: Tag Quality Review + +**Context:** Tags accumulate over time. + +**Problem:** Duplicate, stale, ambiguous, and contradictory tags reduce usefulness. + +**Solution:** Run periodic tag quality reviews for: + +```text +unused tags +duplicate tags +ambiguous tags +deprecated tags +conflicting tags +over-tagged entities +missing required tags +``` + +--- + +## 16.8 Pattern: Semantic Tag Mapping + +**Context:** External tools use labels that do not match canonical tags. + +**Problem:** Integrations either lose meaning or force external terms into the canon. + +**Solution:** Map external labels to canonical tags with mapping type, scope, confidence, and rationale. + +--- + +# 17. Tag Profiles + +## 17.1 Profile Format + +A Tag Profile SHALL declare: + +```yaml +id: +profile_name: +status: +implements: + - InfoTechCanonTaggingStandard +target_context: +included_schemes: +allowed_tags: +required_tags: +forbidden_tags: +exclusive_categories: +multi_value_categories: +naming_rules: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +--- + +## 17.2 Seed Profile: Canonical Task Tag Profile + +Purpose: + +```text +Provide a controlled tag scheme for tasks and work items, +importing semantics from InfoTechCanonTaskModel. +``` + +Recommended categories: + +```text +work-type +workflow-state +commitment-state +actionability +reachability +priority +urgency +importance +risk +area +component +team +review-state +outcome-state +``` + +Example tags: + +```text +work-type/bug +work-type/feature +work-type/review +work-type/remediation +workflow-state/blocked +workflow-state/in-review +commitment-state/committed +actionability/needs-clarification +reachability/not-reachable +priority/high +risk/security +area/frontend +component/api +``` + +Rules: + +```text +Only one work-type tag SHOULD be assigned unless profile allows multiple. +Only one commitment-state tag SHOULD be assigned. +Workflow-state tags SHOULD map to Task Model WorkflowState. +Priority tags SHOULD NOT encode urgency or importance unless profile explicitly permits it. +``` + +--- + +## 17.3 Seed Profile: GitHub Issue Label Profile + +Purpose: + +```text +Map canonical task and repository tags to GitHub labels. +``` + +Example mappings: + +```text +work-type/bug -> type: bug +work-type/feature -> type: feature +work-type/documentation -> type: docs +priority/high -> priority: high +workflow-state/blocked -> status: blocked +actionability/needs-info -> status: needs-info +risk/security -> risk: security +good-first-issue -> contribution/good-first +help-wanted -> contribution/help-wanted +``` + +Known deviations: + +```text +GitHub labels are flat strings. +GitHub labels can carry colors and descriptions. +GitHub labels do not enforce canonical exclusivity by default. +``` + +--- + +## 17.4 Seed Profile: Repository Label Profile + +Purpose: + +```text +Provide a default label set for code repositories. +``` + +Recommended dimensions: + +```text +type +area +priority +status +risk +contribution +maintenance +release +documentation +``` + +Example labels: + +```text +type: bug +type: feature +type: docs +type: refactor +type: test +area: ci +area: api +area: ui +area: security +status: blocked +status: needs-info +status: in-review +priority: high +risk: security +contribution: good-first +contribution: help-wanted +maintenance: dependencies +``` + +--- + +## 17.5 Seed Profile: Knowledge Space Tag Profile + +Purpose: + +```text +Tag markdown infospaces for retrieval, navigation, and agent use. +``` + +Recommended categories: + +```text +artifact-type +standard +domain +concept-status +maturity +mapping-target +profile +pattern +assimilation-status +``` + +Example tags: + +```text +artifact-type/concept +artifact-type/pattern +artifact-type/mapping +standard/task +standard/governance +domain/devsecops +concept-status/candidate +maturity/seed +mapping-target/skos +assimilation-status/in-progress +``` + +--- + +## 17.6 Seed Profile: Kubernetes Label Mapping Profile + +Purpose: + +```text +Map Kubernetes recommended labels to InfoTechCanon landscape and tagging concepts. +``` + +Example mappings: + +```text +app.kubernetes.io/name -> landscape/application-name +app.kubernetes.io/instance -> landscape/application-instance +app.kubernetes.io/version -> landscape/application-version +app.kubernetes.io/component -> landscape/component +app.kubernetes.io/part-of -> landscape/part-of-application +app.kubernetes.io/managed-by -> landscape/managed-by +``` + +Known deviations: + +```text +Kubernetes labels are key-value metadata and may also be used by selectors. +Selector labels have operational consequences and should be governed carefully. +``` + +--- + +# 18. Mapping Model for the Tagging Standard + +Mappings relate InfoTechCanon tags to external labels, vocabularies, schemes, tools, and standards. + +## 18.1 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +toolEquivalent +deprecatedReplacement +``` + +## 18.2 Mapping Record + +Example: + +```yaml +id: itc-map:tag-priority-high-to-github-label +source_tag: itc-tag:priority/high +target_body: GitHub Issues +target_version: "2026" +target_label: "priority: high" +mapping_type: toolEquivalent +scope: + - repository issue labeling +not_valid_for: + - scheduling guarantees + - urgency semantics +rationale: > + The GitHub label carries the canonical priority/high tag into a flat label system. + It does not imply deadline or escalation unless a task profile defines that behavior. +confidence: high +status: candidate +owner: InfoTechCanonTaggingStandard +``` + +## 18.3 Seed Mapping Targets + +The Tagging Standard SHOULD maintain mappings to: + +```text +SKOS +GitHub Labels +GitHub default repository labels +Jira labels +Jira components +Jira versions +Azure DevOps tags +GitLab labels +Kubernetes labels and selectors +Docker / OCI image labels +OpenTelemetry resource attributes +Markdown front matter tags +Hashtags +Confluence labels +Notion tags +Obsidian tags +Zettelkasten / knowledge management tags +``` + +--- + +# 19. Assimilation Hooks + +The Tagging Standard SHALL be able to receive new tagging, labeling, taxonomy, and classification systems through the InfoTechCanon assimilation process. + +## 19.1 Assimilation Triggers + +Assimilation may be triggered by: + +```text +new issue-tracker label model +new repository label convention +new taxonomy or vocabulary standard +new markdown knowledge-base tagging pattern +new Kubernetes label convention +new security finding label set +new team-specific tag scheme +new recurring tag conflict +new label automation need +``` + +## 19.2 Tagging Assimilation Output + +A tagging assimilation SHOULD produce: + +```text +source summary +extracted tags and categories +concept comparison matrix +gap list +conflict list +mapping file +candidate new tags +candidate aliases +candidate deprecations +candidate validation rules +candidate profile changes +open questions +``` + +## 19.3 Recommended First Assimilation Candidates + +```text +Existing task-tagging draft +GitHub default labels +GitHub Issues label practices +Jira labels/components/versions +Kubernetes recommended labels +SKOS concept scheme practice +Obsidian / markdown front matter tag conventions +DevSecOps finding label conventions +``` + +--- + +# 20. Integration with Other InfoTechCanon Standards + +## 20.1 Task Model + +Tagging imports task concepts for: + +```text +work type +workflow state +commitment state +actionability +reachability +priority +urgency +importance +blocker type +review state +outcome state +``` + +## 20.2 Organization Model + +Tagging references organization concepts for: + +```text +team +owner +steward +actor +responsibility area +``` + +But tags should not replace organization relationships. + +## 20.3 Governance Model + +Tagging references governance concepts for: + +```text +policy +risk +control +exception +evidence +approval +review +audit +compliance +``` + +But tags should not replace governance records. + +## 20.4 Landscape Model + +Tagging references landscape concepts for: + +```text +service +application +component +repository +runtime +network +data +environment +platform +``` + +But tags should not replace landscape relationships. + +## 20.5 Access Control Model + +Tagging may be used as an input to access-control logic only through explicit access-control profiles. + +## 20.6 DevSecOps Model + +Tagging supports classification of: + +```text +findings +artifacts +repositories +pipeline runs +deployment records +release work +security reviews +``` + +--- + +# 21. Canon Interface Card Usage + +Subsystems that implement or produce tag knowledge SHOULD publish a Canon Interface Card. + +Example: + +```yaml +subsystem: github-label-sync +implements: + - InfoTechCanonTaggingStandard + - GitHubIssueLabelProfile +produces: + - Label + - TagAssignment + - TagMapping +consumes: + - TagDefinition + - TagProfile + - Repository +relations: + - Label maps_to Tag + - TagAssignment applies_to Issue +source_of_truth: + canonical_label_definitions: info-tech-canon + assigned_issue_labels: GitHub +known_deviations: + - GitHub labels are flat strings + - exclusivity rules require external validation +``` + +--- + +# 22. Retrieval Requirements + +The Tagging Standard is designed for markdown-based infospaces. + +## 22.1 Required Retrieval Properties + +Every major tag or tag concept SHOULD provide: + +- stable heading, +- stable identifier, +- short definition, +- longer explanation, +- examples, +- anti-examples, +- relationship examples, +- mapping hooks, +- profile references, +- and common mistakes. + +## 22.2 Agent Brief + +A mature Tagging Standard SHOULD include an `agent-brief.md` file with: + +```text +purpose +scope +owned concepts +imported concepts +core distinctions +do / do not rules +recommended tag categories +syntax conventions +profile list +mapping list +common mistakes +minimal examples +``` + +## 22.3 Indexes + +The tagging information space SHOULD provide indexes by: + +```text +tag +category +namespace +scheme +profile +mapping target +status +owner +source system +deprecated tag +alias +validation rule +``` + +--- + +# 23. Conformance Levels + +## 23.1 Reference-Conformant + +A document or system is reference-conformant if it uses Tagging Standard terminology consistently but does not implement structured metadata or validation rules. + +## 23.2 Metadata-Conformant + +A system is metadata-conformant if it uses stable identifiers, tag definitions, lifecycle states, source metadata, and mapping metadata. + +## 23.3 Scheme-Conformant + +A system is scheme-conformant if tags belong to declared tag schemes or namespaces. + +## 23.4 Profile-Conformant + +A system is profile-conformant if it implements a declared Tag Profile and passes its validation rules. + +## 23.5 Mapping-Conformant + +A system is mapping-conformant if it maps external labels and tool-specific tags to canonical tags with mapping type, scope, confidence, and rationale. + +## 23.6 Quality-Conformant + +A system is quality-conformant if it can detect or report duplicate tags, deprecated tags, missing required tags, tag conflicts, and tag drift. + +## 23.7 Assimilation-Conformant + +A system or repository is assimilation-conformant if it can accept external tag systems through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, aliases, deprecations, and proposed changes. + +--- + +# 24. Validation Rules + +Initial validation rules: + +```text +VAL-TAG-001: A canonical tag SHOULD have a TagDefinition. + +VAL-TAG-002: A TagDefinition SHOULD declare scheme, namespace or category, status, owner or steward, description, and applies_to scope. + +VAL-TAG-003: Tags SHOULD NOT replace first-class fields or relationships required by another InfoTechCanon standard. + +VAL-TAG-004: A TagAssignment SHOULD identify the target entity and source system. + +VAL-TAG-005: Flat tool labels SHOULD be mapped to structured canonical tags where possible. + +VAL-TAG-006: Deprecated tags SHOULD NOT be assigned to new entities. + +VAL-TAG-007: Deprecated tags SHOULD reference a replacement or rationale when available. + +VAL-TAG-008: Exclusive tag categories SHOULD define whether one or many values are allowed. + +VAL-TAG-009: A profile SHOULD define required, allowed, and forbidden tags. + +VAL-TAG-010: A profile MUST NOT redefine task, organization, governance, or landscape semantics. + +VAL-TAG-011: Tag aliases SHOULD be used for synonym handling instead of creating duplicate active tags. + +VAL-TAG-012: Tag mappings SHOULD declare mapping type, scope, target system, confidence, and rationale. + +VAL-TAG-013: Tags used by automation SHOULD be controlled or explicitly marked as trusted inputs. + +VAL-TAG-014: Tags used by selectors with operational consequences SHOULD be treated as governed metadata. + +VAL-TAG-015: Priority tags SHOULD NOT imply urgency, deadline, or escalation unless a profile explicitly defines that behavior. + +VAL-TAG-016: Status tags SHOULD map to workflow states or declare why they are only informal signals. + +VAL-TAG-017: Team tags SHOULD NOT replace ownership or assignment relationships. + +VAL-TAG-018: Security tags SHOULD NOT replace security findings, controls, or risk records. + +VAL-TAG-019: Governance tags SHOULD NOT replace policies, controls, evidence, decisions, or exceptions. + +VAL-TAG-020: Tag schemes SHOULD be reviewed periodically for drift, duplication, and unused tags. +``` + +--- + +# 25. Anti-Patterns + +## 25.1 Tag Soup + +Too many tags without scheme, ownership, definition, or cleanup. + +## 25.2 Label as Data Model + +Using labels to encode facts that should be fields or relationships. + +## 25.3 Priority as Everything + +Using priority tags to encode urgency, importance, stakeholder pressure, risk, due date, and value simultaneously. + +## 25.4 Team Tag as Ownership + +Using `team/platform` without an actual ownership relationship. + +## 25.5 Status Tag as Workflow + +Using status tags when a system needs real workflow state and transitions. + +## 25.6 Eternal Deprecated Label + +Deprecating a tag without replacement, migration, or cleanup. + +## 25.7 Flat Label Collision + +Using the same flat label to mean different things in different repositories. + +## 25.8 Automation on Uncontrolled Tags + +Letting automation act on user-created tags without governance. + +## 25.9 Tagging Everything + +Adding tags even when they do not improve retrieval, routing, filtering, governance, or automation. + +## 25.10 Tool-Native Lock-In + +Letting GitHub, Jira, Kubernetes, or another tool define the internal tag model. + +--- + +# 26. Initial Repository Placement + +Recommended repository layout: + +```text +info-tech-canon/ + standards/ + tagging/ + InfoTechCanonTaggingStandard.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +Seed files: + +```text +standards/tagging/InfoTechCanonTaggingStandard.md +standards/tagging/agent-brief.md +standards/tagging/concepts/tag.md +standards/tagging/concepts/tag-scheme.md +standards/tagging/concepts/tag-profile.md +standards/tagging/concepts/tag-assignment.md +standards/tagging/concepts/tag-mapping.md +standards/tagging/patterns/controlled-core-emergent-edge.md +standards/tagging/patterns/tag-is-signal-field-is-fact.md +standards/tagging/patterns/one-dimension-one-category.md +standards/tagging/profiles/canonical-task-tag-profile.md +standards/tagging/profiles/github-issue-label-profile.md +standards/tagging/profiles/repository-label-profile.md +standards/tagging/profiles/knowledge-space-tag-profile.md +standards/tagging/mappings/skos.yaml +standards/tagging/mappings/github-labels.yaml +standards/tagging/mappings/jira-labels.yaml +standards/tagging/mappings/kubernetes-labels.yaml +``` + +--- + +# 27. Roadmap + +## Phase 1: Seed Stabilization + +- Establish this standard as `InfoTechCanonTaggingStandard`. +- Align with Task Model concepts. +- Define canonical tag categories and initial profiles. +- Define validation rules. +- Create repository label profile. + +## Phase 2: Existing Draft Assimilation + +- Assimilate the existing Canonical Task Tagging draft. +- Extract useful tag categories. +- Map draft labels to canonical tags. +- Identify gaps, conflicts, aliases, and deprecated names. + +## Phase 3: Tool Mappings + +Recommended first mappings: + +```text +GitHub Labels +Jira Labels / Components / Versions +Kubernetes Recommended Labels +Markdown front matter tags +SKOS +``` + +## Phase 4: Automation + +- Generate GitHub label sets from tag profiles. +- Validate labels in repositories. +- Detect duplicate and deprecated labels. +- Generate markdown indexes by tag. +- Support agent retrieval by tag scheme. + +## Phase 5: Quality and Governance + +- Add tag quality reports. +- Add tag drift detection. +- Add tag review workflows. +- Add profile conformance checks. + +--- + +# 28. Summary + +The InfoTechCanon Tagging Standard is the seed standard for making tags useful, governed, mappable, and automation-friendly without allowing them to replace stronger canonical models. + +Its most important commitments are: + +```text +Separate tags from canonical concepts, fields, states, relationships, and policies. + +Use tags as lightweight classifiers and signals. + +Use TagDefinitions, TagSchemes, TagProfiles, and TagMappings for governance. + +Import task semantics from the Task Model. + +Map external labels instead of surrendering to tool-native terminology. + +Support controlled core tags and emergent edge tags. + +Use profiles to make tagging practical in GitHub, Jira, Kubernetes, +markdown infospaces, repositories, and agent workflows. +``` + +This makes the Tagging Standard the fifth foundational seed of InfoTechCanon and a key mechanism for retrieval, filtering, automation, issue organization, repository consistency, and knowledge-space navigation. diff --git a/seeds/InfoTechCanonTaskModel_RC1_seed.md b/seeds/InfoTechCanonTaskModel_RC1_seed.md new file mode 100755 index 0000000..021c50f --- /dev/null +++ b/seeds/InfoTechCanonTaskModel_RC1_seed.md @@ -0,0 +1,2100 @@ +# InfoTechCanon Task Model + +**Short Name:** `ITC-TASK` +**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:** Product owners, project managers, platform builders, agentic tooling designers, developers, service owners, governance designers, task-system maintainers, issue-tracker administrators, personal-organization system designers, knowledge-system builders, standards authors, and AI agents. + +--- + +# 1. Purpose + +The **InfoTechCanon Task Model** defines a canonical seed model for representing work, possible work, committed work, actionable steps, issues, requests, incidents, experiments, reviews, approvals, remediation, progress, blockers, dependencies, outcomes, and execution state. + +It exists to support interoperable information-processing systems where humans and agents need to coordinate work without forcing every workflow into the same tool, methodology, board, or project-management doctrine. + +This standard provides: + +- a canonical vocabulary for work items, +- a distinction between options, tasks, actions, steps, moves, and experiments, +- a commitment model, +- a readiness and actionability model, +- a decomposition and dependency model, +- a workflow state model, +- interfaces to organization, governance, landscape, tagging, DevSecOps, access-control, and service models, +- mapping hooks to external tools and methodologies, +- seed patterns for practical task modeling, +- profile hooks for concrete implementation contexts, +- and retrieval-friendly structure for humans, agents, and markdown-based infospaces. + +--- + +# 2. Position in InfoTechCanon + +The Task Model is a **domain standard** within InfoTechCanon. + +It should become the canonical owner of work semantics that should not be hidden inside tagging, project management tools, issue trackers, or governance models. + +```text +InfoTechCanon +├── InfoTechCanonCore +├── InfoTechCanonLandscapeModel +├── InfoTechCanonOrganizationModel +├── InfoTechCanonGovernanceModel +├── InfoTechCanonTaskModel <-- this standard +├── InfoTechCanonTaggingStandard <-- should import task concepts +├── InfoTechCanonAccessControlModel +├── InfoTechCanonSecurityModel +├── InfoTechCanonDevSecOpsModel +├── InfoTechCanonPatternLanguage +└── Application Profiles +``` + +The foundational dependency chain is: + +```text +Landscape = what exists and what work may apply to. +Organization = who acts, owns, is assigned, and is accountable. +Governance = which rules, decisions, risks, and obligations create or constrain work. +Task = what work exists, whether it is committed, and how it progresses. +Tagging = how work and other entities are classified and filtered. +``` + +--- + +# 3. Boundary with Adjacent Standards + +## 3.1 Boundary with Organization + +The Organization Model owns: + +```text +Actor +Person +Agent +Team +Role +Membership +Assignment +Responsibility +Authority +Accountability +Capacity +Availability +``` + +The Task Model owns: + +```text +WorkItem +Option +Task +Action +NextAction +Step +Move +Experiment +Issue +Request +BacklogItem +Blocker +Dependency +Commitment +TaskState +WorkOutcome +AcceptanceCriteria +DefinitionOfDone +``` + +Boundary rule: + +```text +Organization defines who can act and carry responsibility. +Task defines what work exists and how it becomes actionable, committed, executed, blocked, completed, or abandoned. +``` + +## 3.2 Boundary with Governance + +The Governance Model owns: + +```text +Policy +Rule +Decision +Approval +Review +Risk +Control +Exception +Evidence +Obligation +Requirement +``` + +The Task Model may reference these when work is created by or constrained by governance. + +Examples: + +```text +Obligation creates Task +Finding creates RemediationTask +ApprovalTask satisfies GovernanceReview +ExceptionRequest is governed_by Policy +RiskTreatment creates Task +``` + +## 3.3 Boundary with Landscape + +The Landscape Model owns services, software systems, artifacts, deployments, runtime resources, network entities, data objects, and observability signals. + +The Task Model can attach work to those entities. + +Examples: + +```text +Task affects ApplicationService +IncidentTask affects RuntimeResource +ChangeTask changes DeploymentRecord +RemediationTask fixes Finding +Experiment explores ArchitectureDecision +``` + +## 3.4 Boundary with Tagging + +The Tagging Standard should own tag syntax, tag categories, tag governance, tag composition, and tag validation. + +The Task Model owns the semantics of work items that tags may classify. + +Boundary rule: + +```text +Task status, commitment, actionability, dependency, and outcome semantics belong here. +Tagging may encode or reference them, but should not define them. +``` + +--- + +# 4. Research Basis and External Alignment + +This seed standard draws on multiple bodies of work knowledge. + +## 4.1 Project Management and Work Breakdown Structures + +Project-management practice distinguishes deliverables, work packages, activities, schedules, dependencies, responsibilities, milestones, and acceptance. Work Breakdown Structures emphasize decomposition of total project scope into manageable parts, while allowing context-specific levels of detail. + +## 4.2 Agile, Scrum, and Product Backlogs + +Scrum distinguishes product backlog, sprint backlog, sprint goal, product backlog items, increments, and commitments. The Task Model should map to these concepts without becoming Scrum-specific. + +## 4.3 Kanban and Flow-Based Work Management + +Kanban emphasizes visualizing work, managing flow, limiting work in progress, making policies explicit, and improving collaboratively. The Task Model should support flow states, WIP, blockers, pull readiness, and classes of service without requiring a board. + +## 4.4 Getting Things Done and Personal Work Systems + +GTD-style personal organization emphasizes capture, clarification, projects, contexts, and next actions. The Task Model uses the distinction between not-yet-actionable material, options, tasks, and next actions. + +## 4.5 IT Service Management + +ITSM practice distinguishes incidents, service requests, problems, changes, tasks, approvals, and remediation. The Task Model should support these as task types or profiles while leaving service definitions to Landscape and governance decisions to Governance. + +## 4.6 Software Issue Tracking + +Tools such as GitHub Issues, Jira, Azure DevOps, and GitLab provide practical work item types: issue, bug, story, task, epic, subtask, milestone, label, project, dependency, pull request, and status. These are mapping and profile targets, not the internal foundation. + +## 4.7 Complex Work and Adaptive Action + +Some work is predictable and decomposable; other work is exploratory, uncertain, emergent, and path-dependent. The Task Model should distinguish direct execution from exploration and experimentation. + +--- + +# 5. Seed Standard Design Stance + +This standard is a **seed standard**, not a final complete theory of work. + +It shall: + +1. define enough canonical concepts to support practical work coordination, +2. distinguish possible work from committed work, +3. distinguish planned progress from actual action, +4. support human and agent work, +5. support personal, team, project, product, operational, service, and governance work, +6. support predictable and exploratory work, +7. avoid being captured by any one tool such as Jira, GitHub Issues, or Azure DevOps, +8. expose mapping hooks to external methodologies and products, +9. provide profile hooks for implementation contexts, +10. remain markdown-first and agent-retrievable, +11. and support future assimilation of task, project, issue, and workflow models. + +--- + +# 6. Scope + +## 6.1 In Scope + +This standard covers canonical representation of: + +- work items, +- options, +- tasks, +- actions, +- next actions, +- steps, +- moves, +- experiments, +- explorations, +- issues, +- requests, +- incidents as work items, +- problem-investigation work, +- change work, +- remediation work, +- review and approval work, +- backlog items, +- stories, +- bugs, +- epics as mapped/profiled concepts, +- decomposition, +- dependencies, +- blockers, +- prerequisites, +- commitment, +- due dates, +- readiness, +- actionability, +- reachability, +- effort, +- estimates, +- progress, +- workflow state, +- priority, +- urgency, +- importance, +- value, +- risk, +- outcome, +- acceptance criteria, +- definition of done, +- assignment references, +- and task evidence. + +## 6.2 Out of Scope + +This standard does not fully define: + +- all project management methodology, +- all agile or Scrum practice, +- all Kanban practice, +- all ITIL practice, +- all personal productivity practice, +- detailed scheduling algorithms, +- portfolio management, +- resource management, +- financial project accounting, +- HR performance management, +- detailed access control, +- or all tag syntax and tag governance. + +Those may be mapped, assimilated, profiled, or handled by adjacent standards. + +--- + +# 7. 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 defined provisionally here but open to later refinement. +- **EXTRACT** marks a concept that may later move to a more specialized standard. + +--- + +# 8. Core Principles + +## 8.1 Work Is Broader Than Task + +A task is a committed kind of work item. + +The Task Model SHALL distinguish general work items from tasks. + +## 8.2 Option Is Not Task + +An option is possible work without commitment. + +A task is committed work with an expectation of action, outcome, or consequence. + +## 8.3 Action Is Not Task + +A task represents intended or committed work. + +An action is the actual doing or executable unit of progress. + +## 8.4 Next Action Matters + +When a work item is not directly executable, the model SHOULD support extraction of a next action. + +## 8.5 Commitment Is First-Class + +Commitment SHOULD be explicit. + +A work item may be captured, considered, planned, committed, delegated, blocked, completed, abandoned, or converted. + +## 8.6 Actionability and Reachability Are Distinct + +A work item may be actionable in principle but not reachable because no actor with sufficient skill, willingness, authority, tools, or time is available. + +## 8.7 Decomposition Is Contextual + +Work may be decomposed into smaller work items, but decomposition depth is context-dependent. + +## 8.8 Workflow State Is Not Semantic Type + +A bug, story, incident, or request is a type of work item. + +Open, in progress, blocked, and done are states. + +The model MUST NOT confuse work type with workflow state. + +## 8.9 External Tools Are Mapped, Not Obeyed + +The Task Model MAY map to GitHub Issues, Jira, Azure DevOps, GitLab, Scrum, Kanban, ITIL, PMBOK, GTD, or similar systems. + +It MUST NOT subordinate its internal semantics to any single tool or methodology. + +--- + +# 9. Canonical Seed Metadata + +Every task artifact SHOULD support structured metadata. + +Recommended front matter: + +```yaml +--- +id: itc-task:Task +type: concept +standard: InfoTechCanonTaskModel +standard_version: RC1-seed +status: candidate +canonical_owner: InfoTechCanonTaskModel +preferred_label: Task +related: + - itc-task:WorkItem + - itc-task:Option + - itc-task:Action + - itc-task:Commitment +mappings: + - itc-map:task-to-github-issue + - itc-map:task-to-jira-task +--- +``` + +Recommended artifact statuses: + +```text +idea +draft +candidate +release-candidate +adopted +stable +deprecated +retired +``` + +Recommended concept statuses: + +```text +proposed +experimental +candidate +canonical +deprecated +retired +``` + +--- + +# 10. Root Task Taxonomy + +```text +TaskEntity +├── WorkEntity +│ ├── WorkItem +│ ├── Option +│ ├── Task +│ ├── Action +│ ├── NextAction +│ ├── Step +│ ├── Move +│ ├── Exploration +│ └── Experiment +├── WorkTypeEntity +│ ├── Request +│ ├── Issue +│ ├── Bug +│ ├── Story +│ ├── Feature +│ ├── Epic +│ ├── IncidentTask +│ ├── ProblemTask +│ ├── ChangeTask +│ ├── ReviewTask +│ ├── ApprovalTask +│ ├── RemediationTask +│ └── DecisionTask +├── WorkStructureEntity +│ ├── Backlog +│ ├── WorkPackage +│ ├── Milestone +│ ├── Sprint +│ ├── Iteration +│ ├── Project +│ ├── ProgramReference +│ └── PortfolioReference +├── WorkRelationEntity +│ ├── Dependency +│ ├── Blocker +│ ├── Prerequisite +│ ├── ParentChildRelation +│ ├── DuplicateRelation +│ ├── RelatedWorkRelation +│ └── FollowUpRelation +├── CommitmentEntity +│ ├── Commitment +│ ├── AssignmentReference +│ ├── DueDate +│ ├── Deadline +│ ├── Promise +│ ├── Escalation +│ └── WaitingFor +├── FlowEntity +│ ├── Workflow +│ ├── WorkflowState +│ ├── Transition +│ ├── WIPLimit +│ ├── Queue +│ ├── PullSignal +│ └── ThroughputMeasure +├── EvaluationEntity +│ ├── Priority +│ ├── Urgency +│ ├── Importance +│ ├── Value +│ ├── Risk +│ ├── EffortEstimate +│ ├── CostEstimate +│ ├── Confidence +│ └── Complexity +└── CompletionEntity + ├── Outcome + ├── Deliverable + ├── AcceptanceCriteria + ├── DefinitionOfReady + ├── DefinitionOfDone + ├── CompletionEvidence + └── Result +``` + +--- + +# 11. Core Concepts + +## 11.1 TaskEntity + +A **TaskEntity** is any identifiable concept used to represent work, possible work, committed work, actual action, flow, progress, outcome, or work-related relationship. + +Recommended attributes: + +```yaml +id: +entity_type: +canonical_name: +display_name: +lifecycle_state: +source_system: +created_at: +updated_at: +``` + +Optional attributes: + +```yaml +owner: +assignee: +requester: +accountable_actor: +governance_scope: +affected_landscape_entity: +source_confidence: +valid_from: +valid_to: +tags: +external_references: +``` + +--- + +## 11.2 WorkItem + +A **WorkItem** is the root concept for an identifiable unit of possible, planned, committed, or actual work. + +A work item may represent: + +```text +idea +option +task +issue +request +bug +story +incident +change +review +approval +experiment +remediation +``` + +Canonical rule: + +```text +All tasks are work items, but not all work items are tasks. +``` + +--- + +## 11.3 Option + +An **Option** is possible intended work without commitment. + +An option may be captured because it might become useful, valuable, necessary, or interesting. + +Examples: + +```text +try a new library +explore a business model +write an article +refactor a module someday +investigate a potential standard +``` + +Canonical rule: + +```text +An option SHOULD NOT be treated as overdue merely because it exists. +``` + +--- + +## 11.4 Task + +A **Task** is a committed work item with an expectation of action, outcome, responsibility, or consequence. + +A task may be self-committed, assigned, delegated, required by governance, requested by another actor, or created by a system. + +A task SHOULD have: + +```text +description +commitment state +responsible or assigned actor reference +desired outcome or acceptance criteria +status +``` + +--- + +## 11.5 Action + +An **Action** is the actual doing of work. + +Actions may be recorded as events, steps, or evidence of progress. + +Examples: + +```text +send email +run script +call customer +deploy artifact +review pull request +write standard section +``` + +--- + +## 11.6 NextAction + +A **NextAction** is the next concrete action that can move a work item forward. + +A next action SHOULD be: + +```text +clear +specific +physically or digitally executable +small enough to start +linked to a context or actor +``` + +Canonical rule: + +```text +A work item that is not actionable SHOULD be clarified until a next action can be identified, or reclassified as an option, exploration, or blocked item. +``` + +--- + +## 11.7 Step + +A **Step** is a planned unit of progress in a relatively clear or decomposable path. + +Steps are useful when the problem is sufficiently understood. + +--- + +## 11.8 Move + +A **Move** is an action or step taken in a complex, uncertain, or adaptive context where progress changes the situation and may reveal new options. + +Moves are useful when planning cannot fully determine the path. + +--- + +## 11.9 Exploration + +An **Exploration** is a work item whose primary purpose is to reduce uncertainty, discover options, clarify a problem, or understand a domain. + +Exploration may produce: + +```text +knowledge +questions +options +experiments +tasks +decisions +``` + +--- + +## 11.10 Experiment + +An **Experiment** is a structured action intended to learn from a controlled or bounded intervention. + +Recommended attributes: + +```yaml +hypothesis: +expected_signal: +safe_to_fail: +timebox: +success_indicator: +learning_result: +``` + +--- + +## 11.11 Request + +A **Request** is a work item initiated by an actor asking another actor, team, service, or system to do something. + +Requests may become tasks, options, tickets, service requests, change requests, or rejected items. + +--- + +## 11.12 Issue + +An **Issue** is a work item that captures something needing attention, discussion, decision, correction, or tracking. + +Issue is a broad external-tool-friendly concept. + +--- + +## 11.13 Bug + +A **Bug** is a work item representing a defect, error, malfunction, or unwanted behavior. + +A bug SHOULD reference the affected system, observed behavior, expected behavior, reproduction information, and severity when known. + +--- + +## 11.14 Story + +A **Story** is a user- or stakeholder-oriented work item that describes desired value or behavior. + +A story SHOULD reference: + +```text +beneficiary +desired capability +value or reason +acceptance criteria +``` + +--- + +## 11.15 Feature + +A **Feature** is a coherent capability or behavior that delivers value to users, systems, or stakeholders. + +A feature may be decomposed into stories, tasks, experiments, or implementation steps. + +--- + +## 11.16 Epic + +An **Epic** is a large work item or goal that is expected to be decomposed into smaller work items. + +Epic is often a profile-specific concept used by issue trackers and agile tools. + +--- + +## 11.17 IncidentTask + +An **IncidentTask** is work triggered by an incident or service degradation. + +It SHOULD reference the affected service, urgency, impact, workaround, and resolution state. + +--- + +## 11.18 ProblemTask + +A **ProblemTask** is work intended to investigate or eliminate the underlying cause of incidents or recurring issues. + +--- + +## 11.19 ChangeTask + +A **ChangeTask** is work intended to alter a system, service, configuration, process, artifact, or environment. + +Change tasks may require governance approval depending on profile. + +--- + +## 11.20 ReviewTask + +A **ReviewTask** is work intended to examine an artifact, proposal, decision, control, design, code change, document, or result. + +--- + +## 11.21 ApprovalTask + +An **ApprovalTask** is work requiring an authorized actor to approve or reject something. + +Approval semantics are owned by Governance; the Task Model owns the work representation of the approval action. + +--- + +## 11.22 RemediationTask + +A **RemediationTask** is work intended to correct a finding, risk condition, defect, compliance gap, vulnerability, or nonconformity. + +--- + +## 11.23 DecisionTask + +A **DecisionTask** is work required to reach, record, or escalate a decision. + +Decision semantics are owned by Governance; the Task Model owns the work representation. + +--- + +## 11.24 Backlog + +A **Backlog** is an ordered or unordered collection of work items that may be selected, refined, prioritized, committed, or executed. + +Backlogs may exist for: + +```text +product +project +team +service +personal system +incident response +technical debt +governance remediation +``` + +--- + +## 11.25 WorkPackage + +A **WorkPackage** is a larger bounded unit of work that may be decomposed into tasks, activities, deliverables, or sub-work items. + +WorkPackage is useful for project-management mappings. + +--- + +## 11.26 Milestone + +A **Milestone** is a significant point, target, event, or grouping marker used to track progress. + +A milestone is not itself necessarily a task. + +--- + +## 11.27 Commitment + +A **Commitment** is a declared expectation that a work item will be acted upon, completed, decided, reviewed, or otherwise progressed. + +Commitment may be created by: + +```text +self-commitment +assignment +delegation +acceptance of request +governance obligation +contract +due date +sprint selection +incident response duty +``` + +--- + +## 11.28 AssignmentReference + +An **AssignmentReference** links a work item to an actor or organizational entity expected to act. + +The organization semantics of actor and assignment are owned by Organization. + +--- + +## 11.29 DueDate and Deadline + +A **DueDate** is a target date or time by which work is expected. + +A **Deadline** is a stricter boundary where missing it has consequence. + +Canonical rule: + +```text +A date on an option SHOULD NOT be interpreted as a deadline unless commitment semantics are present. +``` + +--- + +## 11.30 WaitingFor + +**WaitingFor** is a state or relationship indicating that progress depends on another actor, event, decision, input, or condition. + +--- + +## 11.31 Dependency + +A **Dependency** is a relationship where one work item requires another work item, condition, artifact, decision, or resource. + +Dependency types: + +```text +finish_to_start +start_to_start +external_dependency +information_dependency +decision_dependency +resource_dependency +technical_dependency +governance_dependency +``` + +--- + +## 11.32 Blocker + +A **Blocker** is an active impediment preventing progress. + +A blocker may be caused by: + +```text +missing information +unavailable actor +unresolved decision +access limitation +technical fault +policy constraint +resource shortage +unclear scope +``` + +--- + +## 11.33 Readiness + +**Readiness** indicates whether a work item is sufficiently clear, scoped, authorized, resourced, and unblocked to start. + +--- + +## 11.34 Actionability + +**Actionability** indicates whether a work item has enough clarity and feasible next action to be acted upon. + +Actionability depends on: + +```text +clarity +scope +context +required resources +known next action +risk of failed attempt +``` + +--- + +## 11.35 Reachability + +**Reachability** indicates whether an actionable work item can actually be reached by an available actor with sufficient skill, willingness, authority, tools, access, and time. + +Canonical rule: + +```text +A work item may be actionable but not reachable. +``` + +--- + +## 11.36 Priority + +**Priority** is an ordering signal used to choose between work items. + +Priority SHOULD NOT be used as a substitute for urgency, importance, value, risk, or commitment. + +--- + +## 11.37 Urgency + +**Urgency** indicates time sensitivity. + +--- + +## 11.38 Importance + +**Importance** indicates significance relative to goals, values, strategy, obligations, or consequences. + +--- + +## 11.39 Value + +**Value** indicates expected benefit or contribution to goals. + +Value may be economic, operational, strategic, learning-oriented, safety-related, compliance-related, or emotional. + +--- + +## 11.40 EffortEstimate + +An **EffortEstimate** is an estimate of work required. + +Effort may be represented as time, story points, t-shirt size, Joules, cost, complexity, or another profile-defined unit. + +--- + +## 11.41 Complexity + +**Complexity** indicates uncertainty, interdependence, emergence, or difficulty of predicting outcomes. + +Complexity SHOULD influence whether work is modeled as step, move, exploration, or experiment. + +--- + +## 11.42 Workflow + +A **Workflow** is a set of states and transitions used to manage work progress. + +The Task Model provides generic workflow concepts. Profiles define concrete workflows. + +--- + +## 11.43 WorkflowState + +A **WorkflowState** is a state in a workflow. + +Seed states: + +```text +captured +clarifying +option +ready +committed +planned +in_progress +waiting +blocked +in_review +approved +done +rejected +abandoned +converted +``` + +--- + +## 11.44 Transition + +A **Transition** is a movement from one workflow state to another. + +Transitions SHOULD have criteria when used in mature workflows. + +--- + +## 11.45 WIPLimit + +A **WIPLimit** is a limit on the number of work items allowed in a workflow state, lane, person, team, class of service, or context. + +--- + +## 11.46 Outcome + +An **Outcome** is the result or intended result of a work item. + +A task without an outcome may still be valid, but unclear outcomes reduce actionability. + +--- + +## 11.47 Deliverable + +A **Deliverable** is a tangible or verifiable output of work. + +--- + +## 11.48 AcceptanceCriteria + +**AcceptanceCriteria** define conditions that must be met for a work item to be accepted. + +--- + +## 11.49 DefinitionOfReady + +A **DefinitionOfReady** defines the conditions under which a work item may be started or selected. + +--- + +## 11.50 DefinitionOfDone + +A **DefinitionOfDone** defines the conditions under which a work item may be considered complete. + +--- + +## 11.51 CompletionEvidence + +**CompletionEvidence** is information supporting that work was completed. + +Examples: + +```text +merged pull request +deployment record +test result +signed approval +written document +customer confirmation +monitoring signal +``` + +--- + +# 12. Core Relationship Vocabulary + +Recommended root relationship types: + +```text +contains +part_of +decomposes_into +depends_on +blocks +blocked_by +duplicates +relates_to +follows_up +created_by +requested_by +assigned_to +owned_by +accountable_to +committed_by +accepted_by +rejected_by +approved_by +reviewed_by +affects +changes +fixes +mitigates +satisfies +implements +produces +consumes +evidenced_by +converted_to +promoted_to +derived_from +scheduled_for +waiting_for +``` + +Relationship records SHOULD support: + +```yaml +id: +relationship_type: +source_work_item: +target_entity: +scope: +valid_from: +valid_to: +source_system: +confidence: +evidence: +rationale: +``` + +--- + +# 13. Task State Model + +## 13.1 Work Item Lifecycle States + +```text +captured +triaged +clarifying +option +ready +committed +planned +in_progress +waiting +blocked +in_review +approved +done +rejected +abandoned +converted +``` + +## 13.2 Commitment States + +```text +uncommitted +self_committed +assigned +accepted +delegated +scheduled +obligated +withdrawn +completed +``` + +## 13.3 Actionability States + +```text +unclear +needs_clarification +actionable +needs_decomposition +needs_decision +needs_resource +blocked +reachable +not_reachable +``` + +## 13.4 Outcome States + +```text +undefined +defined +partially_met +met +not_met +superseded +no_longer_relevant +``` + +## 13.5 Review States + +```text +not_required +review_required +in_review +changes_requested +approved +rejected +``` + +--- + +# 14. Task Patterns + +## 14.1 Pattern: Capture Without Commitment + +**Context:** Ideas, possibilities, obligations, and requests arrive faster than they can be evaluated. + +**Problem:** Treating every captured item as a task creates false pressure and overload. + +**Solution:** Capture work as a WorkItem or Option first. Promote to Task only when commitment exists. + +**Result:** The system can hold possibility without pretending everything is equally urgent. + +--- + +## 14.2 Pattern: Option-to-Task Promotion + +**Context:** An option becomes relevant, valuable, or necessary. + +**Problem:** Work systems often lack a clear transition from “could do” to “will do.” + +**Solution:** Promote Option to Task by adding: + +```text +commitment +responsible actor or owner +desired outcome +readiness or next action +priority or reason +``` + +--- + +## 14.3 Pattern: Next Action Extraction + +**Context:** A task is too vague to execute. + +**Problem:** Actors avoid or defer unclear work. + +**Solution:** Extract the smallest concrete next action that can move the work forward. + +--- + +## 14.4 Pattern: Step vs Move + +**Context:** Some work is predictable and decomposable; some is complex and uncertain. + +**Problem:** Forcing complex work into rigid steps creates false confidence. + +**Solution:** Use `Step` for clear progress in known paths and `Move` for adaptive action in uncertain situations. + +--- + +## 14.5 Pattern: Experiment for Learning + +**Context:** The best next action is unknown. + +**Problem:** Planning becomes speculation. + +**Solution:** Create a bounded Experiment with hypothesis, expected signal, safety boundary, and learning result. + +--- + +## 14.6 Pattern: Blocker as First-Class Entity + +**Context:** Work stops. + +**Problem:** Blocked status alone does not reveal what must change. + +**Solution:** Model blockers explicitly with cause, owner, required resolution, and affected work. + +--- + +## 14.7 Pattern: Commitment Boundary + +**Context:** An item has a due date, assignee, or request. + +**Problem:** Teams misinterpret metadata as commitment. + +**Solution:** Model commitment explicitly and distinguish due date, assignment, request, and obligation. + +--- + +## 14.8 Pattern: Definition Before Execution + +**Context:** Teams start work before it is clear. + +**Problem:** Execution reveals missing scope, criteria, or authority too late. + +**Solution:** Use DefinitionOfReady for starting and DefinitionOfDone for completion. + +--- + +## 14.9 Pattern: Work Item as Integration Handle + +**Context:** A change touches landscape, governance, security, and code. + +**Problem:** Work is fragmented across tools. + +**Solution:** Use WorkItem as the integration handle linking service, repo, artifact, policy, decision, evidence, and actor references. + +--- + +# 15. Task Profiles + +## 15.1 Profile Format + +A Task Profile SHALL declare: + +```yaml +id: +profile_name: +status: +implements: + - InfoTechCanonTaskModel +target_context: +included_concepts: +required_relationships: +required_metadata: +workflow_states: +source_of_truth_rules: +mapping_files: +validation_rules: +examples: +known_deviations: +``` + +--- + +## 15.2 Seed Profile: Personal Task and Option Profile + +Purpose: + +```text +Support personal organization with options, tasks, next actions, waiting-for, and lightweight completion. +``` + +Included concepts: + +```text +WorkItem +Option +Task +NextAction +ProjectReference +WaitingFor +DueDate +Context +Actionability +Reachability +Outcome +``` + +Required relationships: + +```text +Task has_next_action NextAction +Task waiting_for ActorOrCondition +Option promoted_to Task +Task part_of ProjectReference +``` + +--- + +## 15.3 Seed Profile: GitHub Issues Task Profile + +Purpose: + +```text +Map GitHub Issues into InfoTechCanon task concepts. +``` + +Example mappings: + +```text +Issue -> WorkItem / Issue +Sub-issue -> Child WorkItem +Task list item -> Task / Subtask +Assignee -> AssignmentReference +Label -> TagReference +Milestone -> Milestone +Project field Status -> WorkflowState +Issue type -> WorkType +Linked pull request -> CompletionEvidence / RelatedWork +``` + +--- + +## 15.4 Seed Profile: Jira Work Item Profile + +Purpose: + +```text +Map Jira work items into InfoTechCanon task concepts. +``` + +Example mappings: + +```text +Epic -> Epic +Story -> Story +Task -> Task +Bug -> Bug +Sub-task -> Child Task +Issue status -> WorkflowState +Assignee -> AssignmentReference +Fix version -> ReleaseReference +Sprint -> Sprint / Iteration +Priority -> Priority +``` + +--- + +## 15.5 Seed Profile: DevSecOps Work Profile + +Purpose: + +```text +Represent work associated with software delivery, security findings, reviews, approvals, releases, and remediation. +``` + +Included concepts: + +```text +Bug +Story +Task +ReviewTask +ApprovalTask +RemediationTask +ChangeTask +FindingReference +PullRequestReference +DeploymentReference +CompletionEvidence +``` + +Required relationships: + +```text +RemediationTask fixes Finding +ReviewTask reviews PullRequest +ApprovalTask approves Release +ChangeTask changes RuntimeResource +Task produces Artifact +CompletionEvidence evidences Task +``` + +--- + +## 15.6 Seed Profile: ITSM Work Profile + +Purpose: + +```text +Represent incidents, service requests, problems, changes, approvals, and remediation tasks. +``` + +Included concepts: + +```text +IncidentTask +Request +ProblemTask +ChangeTask +ApprovalTask +RemediationTask +ServiceReference +Impact +Urgency +Priority +Workaround +Resolution +``` + +Required relationships: + +```text +IncidentTask affects Service +ProblemTask investigates IncidentTask +ChangeTask changes LandscapeEntity +ApprovalTask approves ChangeTask +RemediationTask fixes ProblemTask +``` + +--- + +## 15.7 Seed Profile: Agentic Work Profile + +Purpose: + +```text +Support human-agent collaboration and agent-executable work. +``` + +Included concepts: + +```text +Task +Action +NextAction +AgentAssignment +CapabilityRequirement +AuthorityRequirement +ToolRequirement +ExecutionEvidence +HumanReview +SafetyBoundary +``` + +Required relationships: + +```text +Task assigned_to Agent +Task requires Capability +Task requires Authority +Action uses Tool +ExecutionEvidence evidences Action +HumanReview reviews AgentOutput +``` + +--- + +# 16. Mapping Model for the Task Standard + +Mappings relate InfoTechCanon task concepts to external standards, methods, products, and regulations. + +## 16.1 Mapping Types + +Recommended mapping types: + +```text +exactMatch +closeMatch +broadMatch +narrowMatch +relatedMatch +conflictMatch +gapMatch +derivedFrom +regulatoryReference +``` + +## 16.2 Mapping Record + +Example: + +```yaml +id: itc-map:task-to-jira-task +source_concept: itc-task:Task +target_body: Jira Cloud +target_version: "2026" +target_concept: Task work type +mapping_type: closeMatch +scope: + - generic work tracking +not_valid_for: + - commitment semantics + - next-action modeling + - governance obligations +rationale: > + Jira's Task work type is a practical representation of generic work, + but InfoTechCanon Task includes explicit commitment, actionability, + reachability, and outcome semantics that may not be represented in Jira by default. +confidence: medium +status: candidate +owner: InfoTechCanonTaskModel +``` + +## 16.3 Seed Mapping Targets + +The Task Model SHOULD maintain mappings to: + +```text +PMBOK / PMI work breakdown and activity concepts +ISO 21502 project management guidance +Scrum Guide +Kanban Guide +Getting Things Done +ITIL incident, request, problem, and change concepts +GitHub Issues +GitHub Projects +Jira work types +Azure DevOps work item types +GitLab Issues +Linear issues +Trello cards +Asana tasks +RACI / responsibility assignment models +DevSecOps pipeline tasks and gates +``` + +--- + +# 17. Assimilation Hooks + +The Task Model SHALL be able to receive new task, work, project, issue, workflow, and productivity bodies of knowledge through the InfoTechCanon assimilation process. + +## 17.1 Assimilation Triggers + +Assimilation may be triggered by: + +```text +new issue-tracker model +new project-management standard +new agile practice +new personal productivity method +new ITSM process model +new workflow automation tool +new agentic work system +new coding-agent execution pattern +new recurring work classification conflict +``` + +## 17.2 Task Assimilation Output + +A task assimilation SHOULD produce: + +```text +source summary +extracted task concepts +concept comparison matrix +gap list +conflict list +mapping file +candidate new concepts +candidate relationship changes +candidate pattern changes +candidate profile changes +open questions +``` + +## 17.3 Recommended First Assimilation Candidates + +```text +GitHub Issues and Projects +Jira work types and workflows +Scrum Guide +Official Kanban Guide +GTD +ITIL incident/request/problem/change concepts +PMI WBS / PMBOK work concepts +Azure DevOps work item types +``` + +--- + +# 18. Integration with Other InfoTechCanon Standards + +## 18.1 Organization Model + +Task imports organization concepts for: + +```text +assignee +owner +accountable actor +requester +reviewer +approver +team +capacity +availability +authority +responsibility +``` + +## 18.2 Governance Model + +Task imports governance concepts for: + +```text +obligation +decision +approval +review +exception +risk +control +finding +evidence +requirement +``` + +## 18.3 Landscape Model + +Task applies to landscape concepts such as: + +```text +BusinessService +ApplicationService +SoftwareComponent +Repository +Artifact +Pipeline +RuntimeResource +NetworkEndpoint +Dataset +Environment +``` + +## 18.4 Tagging Standard + +Tagging imports task concepts for: + +```text +work type +workflow state +priority +status +domain +scope +risk +blocked state +commitment state +``` + +## 18.5 DevSecOps Model + +DevSecOps imports task concepts for: + +```text +bug +review task +approval task +remediation task +change task +release task +pipeline action +``` + +--- + +# 19. Canon Interface Card Usage + +Subsystems that implement or produce task knowledge SHOULD publish a Canon Interface Card. + +Example: + +```yaml +subsystem: github-issues-importer +implements: + - InfoTechCanonTaskModel + - GitHubIssuesTaskProfile +produces: + - Issue + - Task + - WorkItem + - Milestone + - WorkflowState + - AssignmentReference +consumes: + - Person + - Team + - Repository +relations: + - Issue assigned_to Person + - Issue scheduled_for Milestone + - Issue relates_to PullRequest +source_of_truth: + issue_body: GitHub + issue_status: GitHub Projects +known_deviations: + - commitment semantics are inferred unless explicit fields exist + - next actions may be embedded in issue body text +``` + +--- + +# 20. Retrieval Requirements + +The Task Model is designed for markdown-based infospaces. + +## 20.1 Required Retrieval Properties + +Every major concept SHOULD provide: + +- stable heading, +- stable identifier, +- short definition, +- longer explanation, +- examples, +- distinction notes, +- relationship examples, +- mapping hooks, +- profile references, +- and common mistakes. + +## 20.2 Agent Brief + +A mature Task Model SHOULD include an `agent-brief.md` file with: + +```text +purpose +scope +owned concepts +imported concepts +core distinctions +do / do not rules +relationship patterns +minimal examples +common mistakes +profile list +mapping list +``` + +## 20.3 Indexes + +The task information space SHOULD provide indexes by: + +```text +concept +relationship +work type +workflow state +commitment state +profile +pattern +mapping target +status +source system +``` + +--- + +# 21. Conformance Levels + +## 21.1 Reference-Conformant + +A document or system is reference-conformant if it uses Task Model terminology consistently but does not implement structured metadata or validation rules. + +## 21.2 Metadata-Conformant + +A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types. + +## 21.3 Relationship-Conformant + +A system is relationship-conformant if it represents decomposition, dependencies, blockers, assignment references, commitments, and evidence as explicit relationships. + +## 21.4 Actionability-Conformant + +A system is actionability-conformant if it distinguishes options, tasks, next actions, blockers, readiness, actionability, and reachability. + +## 21.5 Profile-Conformant + +A system is profile-conformant if it implements a declared Task Profile and passes its validation rules. + +## 21.6 Assimilation-Conformant + +A system or repository is assimilation-conformant if it can accept external task/work concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes. + +--- + +# 22. Validation Rules + +Initial validation rules: + +```text +VAL-TASK-001: Option and Task SHOULD be modeled as distinct concepts. + +VAL-TASK-002: A Task SHOULD declare or imply a Commitment. + +VAL-TASK-003: A Task SHOULD have a desired Outcome, AcceptanceCriteria, or DefinitionOfDone unless intentionally exploratory. + +VAL-TASK-004: A WorkItem that is unclear SHOULD be marked as needs_clarification or converted to Exploration. + +VAL-TASK-005: A WorkItem that cannot be started SHOULD identify a NextAction, Blocker, Dependency, or WaitingFor relation. + +VAL-TASK-006: AssignmentReference SHOULD resolve to an Organization Model actor or declared external identity mapping. + +VAL-TASK-007: DueDate SHOULD NOT be treated as Deadline unless consequence semantics are declared. + +VAL-TASK-008: Priority SHOULD NOT be used as a substitute for Urgency, Importance, Value, or Risk. + +VAL-TASK-009: WorkflowState MUST NOT be treated as WorkType. + +VAL-TASK-010: A Blocker SHOULD declare cause, owner or resolver, and affected work item. + +VAL-TASK-011: A RemediationTask SHOULD reference the Finding, Risk, Bug, Nonconformity, or Issue it remediates. + +VAL-TASK-012: A ReviewTask or ApprovalTask SHOULD reference the artifact, decision, release, change, or request being reviewed or approved. + +VAL-TASK-013: Profiles MUST NOT redefine canonical concepts. They may constrain them. + +VAL-TASK-014: Imported external task concepts SHOULD be represented through mapping records rather than silently reused. + +VAL-TASK-015: Agent-executable tasks SHOULD declare capability, authority, tool, and safety requirements where relevant. + +VAL-TASK-016: CompletionEvidence SHOULD reference the work item or outcome it supports. +``` + +--- + +# 23. Anti-Patterns + +## 23.1 Everything Is a Task + +Treating every idea, option, request, obligation, issue, and action as the same kind of task. + +## 23.2 Metadata as Commitment + +Assuming an assignee, due date, label, or board column automatically means commitment. + +## 23.3 Priority Soup + +Using priority to encode urgency, importance, value, risk, stakeholder pressure, and due dates all at once. + +## 23.4 Vague Task + +Creating tasks such as “fix system” or “think about architecture” without next action, outcome, or clarification state. + +## 23.5 Blocked Without Blocker + +Marking a task blocked without modeling what blocks it and what would unblock it. + +## 23.6 Tool-Captured Semantics + +Letting Jira, GitHub, or another tool define the internal task model. + +## 23.7 Status as Type + +Using workflow states such as “in review” or “blocked” as if they were task types. + +## 23.8 Action Without Outcome + +Recording activity without knowing what result it should produce. + +## 23.9 Exploration Pretending to Be Delivery + +Treating uncertain learning work as if it were straightforward execution. + +## 23.10 Agent Task Without Authority + +Assigning work to an agent without declaring capability, authority, tool access, or review boundary. + +--- + +# 24. Initial Repository Placement + +Recommended repository layout: + +```text +info-tech-canon/ + standards/ + task/ + InfoTechCanonTaskModel.md + agent-brief.md + concepts/ + relationships/ + patterns/ + profiles/ + mappings/ + assimilation/ + examples/ + validation/ +``` + +Seed files: + +```text +standards/task/InfoTechCanonTaskModel.md +standards/task/agent-brief.md +standards/task/concepts/work-item.md +standards/task/concepts/option.md +standards/task/concepts/task.md +standards/task/concepts/action.md +standards/task/concepts/next-action.md +standards/task/concepts/blocker.md +standards/task/concepts/commitment.md +standards/task/concepts/workflow-state.md +standards/task/patterns/capture-without-commitment.md +standards/task/patterns/option-to-task-promotion.md +standards/task/patterns/next-action-extraction.md +standards/task/patterns/step-vs-move.md +standards/task/profiles/personal-task-option-profile.md +standards/task/profiles/github-issues-task-profile.md +standards/task/profiles/jira-work-item-profile.md +standards/task/profiles/agentic-work-profile.md +standards/task/mappings/github-issues.yaml +standards/task/mappings/jira.yaml +standards/task/mappings/scrum.yaml +standards/task/mappings/kanban.yaml +``` + +--- + +# 25. Roadmap + +## Phase 1: Seed Stabilization + +- Establish this standard as `InfoTechCanonTaskModel`. +- Add seed concepts, relationship vocabulary, patterns, and profiles. +- Define validation rules. +- Align with Organization, Governance, and Landscape. + +## Phase 2: Tagging Dependency + +- Create or refactor `InfoTechCanonTaggingStandard`. +- Ensure tagging imports task semantics instead of defining them. +- Define task tag profiles based on work type, state, domain, priority, risk, commitment, and blocker semantics. + +## Phase 3: First Assimilations + +Recommended first assimilations: + +```text +GitHub Issues +Jira work types and workflows +Scrum Guide +Official Kanban Guide +GTD +ITIL incident/request/problem/change concepts +PMI WBS / PMBOK concepts +``` + +## Phase 4: Tooling Integration + +- Generate concept indexes. +- Generate agent brief. +- Create machine-readable YAML/JSON exports. +- Add validation scripts. +- Use in task CLI, project tooling, issue importers, agentic coding workflows, and markdown infobase workflows. + +## Phase 5: Agentic Work Maturity + +- Mature the Agentic Work Profile. +- Add tool-use requirements. +- Add authority and review constraints. +- Connect execution evidence to Governance and Landscape models. + +--- + +# 26. Summary + +The InfoTechCanon Task Model is the seed standard for representing possible work, committed work, actionable progress, and work execution across humans, agents, tools, repositories, services, and governance systems. + +Its most important commitments are: + +```text +Separate option, task, action, next action, step, move, exploration, and experiment. + +Make commitment explicit. + +Make actionability and reachability explicit. + +Separate work type from workflow state. + +Use task work items as integration handles across organization, governance, +landscape, DevSecOps, security, and tagging. + +Use mappings and assimilation to stay connected to external tools and methods +without surrendering internal semantic autonomy. + +Use profiles to make the model practical in GitHub, Jira, ITSM, personal, +DevSecOps, and agentic work contexts. +``` + +This makes the Task Model the fourth foundational seed of InfoTechCanon and the necessary precursor to a clean Canonical Tagging Standard. diff --git a/spec/RepositoryTreeManifest.md b/spec/RepositoryTreeManifest.md new file mode 100644 index 0000000..b2d9094 --- /dev/null +++ b/spec/RepositoryTreeManifest.md @@ -0,0 +1,181 @@ +# Repository Tree Manifest + +This manifest describes the intended seed layout for the `info-tech-canon` repository. + +```text +info-tech-canon/ + README.md + INTENT.md + SCOPE.md + canon.yaml + + kernel/ + InfoTechCanonCore.md + InfoTechCanonKernelMap.md + agent-brief.md + schemas/ + validation/ + + models/ + information-space/ + InfoTechCanonInformationSpaceModel.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + landscape/ + InfoTechCanonLandscapeModel.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + organization/ + InfoTechCanonOrganizationModel.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + governance/ + InfoTechCanonGovernanceModel.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + task/ + InfoTechCanonTaskModel.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + access-control/ + InfoTechCanonAccessControlModel.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + security/ + InfoTechCanonSecurityModel.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + data/ + InfoTechCanonDataModel.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + devsecops/ + InfoTechCanonDevSecOpsModel.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + network/ + InfoTechCanonNetworkModel.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + observability/ + InfoTechCanonObservabilityModel.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + + standards/ + tagging/ + InfoTechCanonTaggingStandard.md + agent-brief.md + concepts/ + profiles/ + mappings/ + validation/ + caring/ + InfoTechCanonCaringAccessGovernanceStandard.md + agent-brief.md + concepts/ + profiles/ + mappings/ + benchmarks/ + examples/ + validation/ + + profiles/ + small-saas/ + kubernetes-production-readiness/ + agentic-operations/ + markdown-infospace/ + + patterns/ + core/ + integration/ + production-readiness/ + agentic/ + access-governance/ + + mappings/ + external/ + archimate/ + csdm/ + skos/ + prov-o/ + dcat/ + nist-csf/ + rbac/ + kubernetes/ + github/ + opentelemetry/ + slsa/ + + assimilation/ + inbox/ + active/ + completed/ + templates/ + + schemas/ + concept.schema.yaml + standard.schema.yaml + mapping.schema.yaml + profile.schema.yaml + assimilation.schema.yaml + interface-card.schema.yaml + agent-brief.schema.yaml + + views/ + kernel-overview.md + by-standard.md + by-concept.md + by-pattern.md + by-profile.md + by-mapping-target.md + refactoring-checklist.md + + agent/ + global-agent-brief.md + retrieval-index.md + common-mistakes.md + + examples/ + small-saas/ + kubernetes/ + caring-analysis/ + agentic-workflow/ + + validation/ + README.md + core-validation-rules.yaml +``` diff --git a/spec/agent_global-agent-brief.md b/spec/agent_global-agent-brief.md new file mode 100644 index 0000000..6098674 --- /dev/null +++ b/spec/agent_global-agent-brief.md @@ -0,0 +1,156 @@ +# Global Agent Brief: InfoTechCanon + +## Purpose + +InfoTechCanon is a markdown-first canon for building interoperable, adaptable, and extensible information-processing systems. + +Use it as a semantic reference layer when creating or modifying repositories, standards, schemas, profiles, mappings, integration artifacts, and agent workflows. + +--- + +## Core Rule + +```text +Do not invent local semantics when a canonical concept exists. +Import, map, profile, or extend explicitly. +``` + +--- + +## Repository Classification + +```text +Kernel + Defines how the canon works. + +Models + Define broad domain structures. + +Standards + Define cross-cutting conventions or named analytical/design frameworks. + +Profiles + Constrain standards and models for concrete use cases. + +Patterns + Explain recurring practical solutions. + +Mappings + Relate InfoTechCanon concepts to external standards, products, or frameworks. + +Assimilation + Analyzes external knowledge and produces mappings, gaps, conflicts, and proposed changes. +``` + +--- + +## Current Kernel + +```text +InfoTechCanonCore +InfoTechCanonKernelMap +``` + +--- + +## Current Models + +```text +Information Space +Landscape +Organization +Governance +Task +Access Control +Security +Data +DevSecOps +Network +Observability +``` + +--- + +## Current Standards + +```text +Tagging +CARING Access Governance +``` + +--- + +## Do + +- Use canonical names where available. +- Preserve concept ownership. +- Add mappings instead of forcing external terminology. +- Use profiles instead of local forks. +- Keep domain boundaries explicit. +- Record open questions. +- Add provenance and rationale for important changes. +- Prefer structured front matter in Markdown artifacts. +- Keep agent briefs aligned with full standards. +- Treat CARING as a specialized standard, not a simple profile. + +--- + +## Do Not + +- Do not redefine concepts owned by another standard. +- Do not collapse organization roles, access roles, and CARING canonical roles. +- Do not treat tags as a substitute for fields, relationships, policies, or evidence. +- Do not treat external standards as internal authorities. +- Do not treat generated views as canonical source. +- Do not hide mappings in prose. +- Do not accept duplicated concept definitions without a boundary review. + +--- + +## Common Distinctions + +```text +Actor != Subject != Principal + +Organization Role != AccessRole != CARING Canonical Role + +Policy != Control != Evidence + +Option != Task != Action + +Dataset != DataStore + +Artifact != Deployment != Release + +Network Intent != Network Policy != Network Configuration != Observed State + +Alert != Incident + +Tag != Field != Relationship +``` + +--- + +## CARING Reminder + +CARING analyzes access through orthogonal dimensions: + +```text +Subject +Organization Relation +Canonical Role +Scope +Plane +Capability +Exposure Mode +Condition +Lifecycle State +Restriction +Exposure Event +Declared Access +Effective Access +Derived Capability +Induced Access +``` + +Use CARING especially for access-governance analysis, role decomposition, tenant-boundary review, agent access, service-account access, and induced capability analysis. diff --git a/spec/views_kernel-overview.md b/spec/views_kernel-overview.md new file mode 100644 index 0000000..4230820 --- /dev/null +++ b/spec/views_kernel-overview.md @@ -0,0 +1,115 @@ +# Kernel Overview + +## First-Generation Kernel + +The current InfoTechCanon kernel is composed of: + +```text +Kernel: + InfoTechCanonCore + InfoTechCanonKernelMap + +Models: + InfoTechCanonInformationSpaceModel + InfoTechCanonLandscapeModel + InfoTechCanonOrganizationModel + InfoTechCanonGovernanceModel + InfoTechCanonTaskModel + InfoTechCanonAccessControlModel + InfoTechCanonSecurityModel + InfoTechCanonDataModel + InfoTechCanonDevSecOpsModel + InfoTechCanonNetworkModel + InfoTechCanonObservabilityModel + +Standards: + InfoTechCanonTaggingStandard + InfoTechCanonCaringAccessGovernanceStandard +``` + +--- + +## Compact Mental Model + +```text +Core + how the canon works + +Information Space + how canon knowledge is stored, linked, retrieved, and reused + +Landscape + what exists + +Organization + who acts + +Governance + how action is directed, constrained, reviewed, and evidenced + +Task + what work exists and how it progresses + +Tagging + how entities are lightly classified + +Access Control + who/what may do which action on which resource under which conditions + +CARING + how access governance is analyzed orthogonally across lifecycle, planes, scope, exposure, and effective access + +Security + what threatens, weakens, exposes, detects, mitigates, and responds + +Data + what data means, how it is structured, classified, traced, and contracted + +DevSecOps + how source changes become artifacts, releases, deployments, and evidence + +Network + how communication, reachability, addressing, routing, policy, and exposure work + +Observability + how runtime reality becomes signals, evidence, alerts, health, and feedback +``` + +--- + +## Primary Kernel Rule + +```text +Generic mechanisms belong in Core. +Domain meaning belongs in Models. +Named analytical/design frameworks belong in Standards. +Concrete implementation constraints belong in Profiles. +``` + +--- + +## CARING Position + +CARING is a specialized access-governance standard. It should live under: + +```text +standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md +``` + +It should import from: + +```text +Core +Organization +Governance +Access Control +Security +Data +DevSecOps +Network +Observability +Task +Tagging +``` + +It should not be flattened into Access Control because it owns a distinctive orthogonal descriptor model. diff --git a/spec/views_refactoring-checklist.md b/spec/views_refactoring-checklist.md new file mode 100644 index 0000000..59e209f --- /dev/null +++ b/spec/views_refactoring-checklist.md @@ -0,0 +1,101 @@ +# Refactoring Checklist + +## Goal + +Move repeated generic mechanisms out of individual seed standards and into `InfoTechCanonCore`, while keeping domain-specific meaning in each model or standard. + +--- + +## 1. Core Mechanisms to Centralize + +- [ ] Mapping types +- [ ] Mapping record structure +- [ ] Assimilation process +- [ ] Assimilation workspace structure +- [ ] Profile format +- [ ] Pattern format +- [ ] Validation rule format +- [ ] Conformance levels +- [ ] Lifecycle statuses +- [ ] Artifact statuses +- [ ] Concept statuses +- [ ] Agent brief format +- [ ] Canon Interface Card format +- [ ] Repository layout conventions +- [ ] Machine-readable schema conventions + +--- + +## 2. Per-Standard Refactor Checklist + +For every model or standard: + +- [ ] Declare import of `InfoTechCanonCore` +- [ ] Declare canonical owner namespace +- [ ] Declare owned concepts +- [ ] Declare imported concepts +- [ ] Remove duplicated generic mapping type definitions +- [ ] Remove duplicated generic assimilation process definitions +- [ ] Keep domain-specific mapping targets +- [ ] Keep domain-specific assimilation candidates +- [ ] Keep domain-specific profiles +- [ ] Keep domain-specific validation rules +- [ ] Keep domain-specific anti-patterns +- [ ] Add or update `agent-brief.md` +- [ ] Add concept extraction candidates +- [ ] Add profile extraction candidates +- [ ] Add mapping extraction candidates + +--- + +## 3. CARING Refactor Checklist + +- [ ] Place CARING under `standards/caring/` +- [ ] Use file name `InfoTechCanonCaringAccessGovernanceStandard.md` +- [ ] Add namespace `itc-caring` +- [ ] Add Canon metadata preface +- [ ] Declare imports from Core, Organization, Governance, Access Control, Security, Data, DevSecOps, Network, Observability, Task, and Tagging +- [ ] Declare CARING-owned concepts +- [ ] Preserve CARING canonical role taxonomy +- [ ] Preserve CARING access descriptor model +- [ ] Preserve declared/effective access distinction +- [ ] Preserve derived and induced capability analysis +- [ ] Add CARING benchmark directory +- [ ] Create CARING access descriptor schema +- [ ] Create CARING mapping-to-kernel document +- [ ] Create CARING agent brief + +--- + +## 4. First Schemas to Create + +- [ ] `concept.schema.yaml` +- [ ] `standard.schema.yaml` +- [ ] `mapping.schema.yaml` +- [ ] `profile.schema.yaml` +- [ ] `assimilation.schema.yaml` +- [ ] `interface-card.schema.yaml` +- [ ] `agent-brief.schema.yaml` +- [ ] `caring-access-descriptor.schema.yaml` + +--- + +## 5. First Generated Views + +- [ ] `views/by-standard.md` +- [ ] `views/by-concept.md` +- [ ] `views/by-profile.md` +- [ ] `views/by-mapping-target.md` +- [ ] `views/dependency-graph.md` +- [ ] `views/kernel-overview.md` + +--- + +## 6. First Assimilation Workspaces + +- [ ] CARING +- [ ] Kubernetes RBAC +- [ ] ServiceNow CSDM +- [ ] OpenTelemetry +- [ ] DCAT / PROV-O +- [ ] SLSA / in-toto diff --git a/wiki/ProductRequirementsDocument.md b/wiki/ProductRequirementsDocument.md new file mode 100644 index 0000000..10f54f5 --- /dev/null +++ b/wiki/ProductRequirementsDocument.md @@ -0,0 +1,952 @@ +# Product Requirements Document: InfoTechCanon + +**Document Status:** Draft 1 +**Product Name:** InfoTechCanon +**Working Repository Name:** `infotech-canon` +**Primary Product Type:** Markdown-first standards, knowledge, and interoperability framework +**Date:** 2026-05-22 +**Owner:** Bernd Worsch + +--- + +# 1. Definition + +A **Product Requirements Document (PRD)** is a structured document that defines the intended purpose, users, value proposition, scope, requirements, constraints, risks, and success criteria for a product or product-like system. + +It explains **what should be built and why**, without prescribing all implementation details. A PRD serves as a shared reference for stakeholders, designers, developers, architects, reviewers, and agents involved in planning, implementation, validation, and evolution of the product. + +--- + +# 2. Context + +The InfoTechCanon is intended to become an evolving reference system for building interoperable information-processing systems. + +The user is developing multiple tools, repositories, standards, and platform components around markdown-first knowledge management, agentic software development, DevSecOps, IT landscape modeling, governance, access control, task management, tagging, and information processing. These efforts require a shared semantic foundation to reduce contradiction, overlap, and integration friction while preserving adaptability and extensibility. + +Recent work includes the first release candidate of a canonical IT landscape model, currently evolving toward the **InfoTechCanonLandscapeModel**. The user now wants to refactor this and related standards into a broader, interconnected, orthogonal standards system called **InfoTechCanon**. + +The InfoTechCanon should not merely be a static collection of documents. It should become a **versioned, markdown-first, machine-readable, human-usable, agent-retrievable body of knowledge** that can guide system design and integration across a growing ecosystem of tools and services. + +--- + +# 3. Product Vision + +**InfoTechCanon provides an evolving semantic reference system for building interoperable, adaptable, and extensible information-processing systems.** + +It enables standards, models, concepts, patterns, profiles, mappings, and assimilation processes to evolve coherently while remaining useful for humans, agents, and software tools. + +The InfoTechCanon should serve as a practical foundation for: + +- designing compatible subsystems, +- reducing semantic drift across repositories, +- integrating tools and services through declared semantic contracts, +- mapping internal concepts to external standards and regulations, +- assimilating new bodies of knowledge, +- enabling efficient retrieval and reuse by agents and humans, +- and guiding the construction of markdown-based infospaces and knowledge-processing systems. + +--- + +# 4. Product Purpose + +The purpose of InfoTechCanon is to provide a **canonical reference layer** for information technology and information-processing systems. + +It should allow the user and future collaborators to answer questions such as: + +- What does this concept mean in our system landscape? +- Which standard owns this concept? +- Which external standards or regulations does it map to? +- Which subsystem produces or consumes this concept? +- Which patterns describe how this concept is used in practice? +- Which profiles constrain this concept for a specific implementation context? +- What happens when a new external standard, regulation, product model, or body of knowledge appears? +- How can agents retrieve the right knowledge efficiently and use it without inventing contradictory models? + +--- + +# 5. Primary Utility + +The primary utility of InfoTechCanon is to turn **integration by interpretation** into **integration by declared semantic contract**. + +Instead of each repository, subsystem, or agent inventing its own terminology and assumptions, InfoTechCanon provides: + +- stable canonical concepts, +- explicit concept ownership, +- standard structures, +- reusable pattern languages, +- application profiles, +- mapping artifacts, +- assimilation workflows, +- retrieval-optimized markdown infospaces, +- and conformance rules. + +This enables systems to “snap together” more easily while still allowing the standards to evolve. + +--- + +# 6. Intended Users + +## 6.1 Primary Users + +### System Architect + +Uses InfoTechCanon to design interoperable subsystems, clarify domain boundaries, and reduce overlap between standards, services, repositories, and models. + +### Repository Maintainer + +Uses InfoTechCanon to declare which concepts a repository owns, produces, consumes, or implements. + +### Agentic Coding Assistant + +Retrieves relevant standards, terms, profiles, and patterns to generate compatible code, documentation, schemas, mappings, and integration artifacts. + +### Standards Author + +Creates and refactors InfoTechCanon standards, concept definitions, mapping files, profiles, and pattern-language documents. + +### Platform Builder + +Uses InfoTechCanon as the semantic reference layer for services such as markitect-tool, kontextual-engine, shard-wiki, llm-connect, phase-memory, user-engine, landscape tools, and task-management tools. + +--- + +## 6.2 Secondary Users + +### Governance / Compliance Reviewer + +Uses mappings and assimilation reports to understand how internal concepts relate to external regulations, frameworks, and audit requirements. + +### Product Owner + +Uses the canon to align product requirements, service boundaries, task models, and system responsibilities. + +### Developer + +Uses profiles, interface cards, and validation rules to implement systems that remain compatible with the broader ecosystem. + +### Knowledge Curator + +Maintains the markdown infospace, indexes, concept pages, backlinks, and retrieval structures. + +--- + +# 7. Core Product Principles + +## 7.1 Canonical Autonomy + +InfoTechCanon may map to external standards, but it must not be subordinated to them. + +External standards, regulations, and product models influence the canon through mappings and assimilation, not by directly defining internal semantics. + +## 7.2 Orthogonality + +Each standard should own a distinct set of primary concerns. Standards may import concepts from other standards but should not redefine them. + +A concept may be used by many standards but should have exactly one canonical owner. + +## 7.3 Network Before Tree + +Hierarchy is useful for abstraction and navigation, but InfoTechCanon is fundamentally an interconnected network of terms, standards, patterns, profiles, mappings, and relationships. + +## 7.4 Pattern-Language Orientation + +The canon should not only define concepts. It should also provide practical reusable patterns inspired by pattern-language thinking. + +A pattern describes a recurring problem, relevant forces, a reusable solution, consequences, related concepts, and implementation guidance. + +## 7.5 Markdown-First, Machine-Readable + +Canon artifacts should be written as human-readable Markdown with structured metadata that enables indexing, validation, retrieval, transformation, and agent use. + +## 7.6 Assimilation Instead of Blind Adoption + +When a new standard, regulation, model, or body of knowledge appears, InfoTechCanon should run an assimilation process to extract concepts, compare them to internal concepts, identify gaps and conflicts, propose changes, and publish mappings. + +## 7.7 Retrieval as a First-Class Requirement + +The canon must be efficiently retrievable and reusable by both humans and agents. + +Documentation, metadata, summaries, indexes, stable identifiers, front matter, and chunking strategies should be designed accordingly. + +## 7.8 Evolution With Traceability + +The canon must evolve without losing provenance, compatibility information, or historical reasoning. + +Changes should preserve why a concept exists, what influenced it, what it replaced, and how it maps externally. + +--- + +# 8. Product Scope + +## 8.1 In Scope + +The InfoTechCanon product includes: + +- a core meta-standard for defining all other standards, +- canonical concept and relationship models, +- standard document structures, +- concept ownership rules, +- mapping mechanisms to external standards and regulations, +- assimilation workflow definitions, +- pattern-language structures, +- application profile structures, +- retrieval and reuse conventions, +- machine-readable metadata schemas, +- repository layout conventions, +- conformance levels, +- validation rules, +- and initial domain standards. + +Initial domain standards may include: + +- InfoTechCanonCore, +- InfoTechCanonLandscapeModel, +- InfoTechCanonOrganizationModel, +- InfoTechCanonGovernanceModel, +- InfoTechCanonTaskModel, +- InfoTechCanonTaggingStandard, +- InfoTechCanonAccessControlModel, +- InfoTechCanonPatternLanguage. + +--- + +## 8.2 Out of Scope + +The initial product does not include: + +- a complete implementation of every domain standard, +- full legal or regulatory compliance certification, +- a replacement for external standards such as ArchiMate, CSDM, ITIL, PMBOK, ISO, NIST, YANG, SPDX, or CycloneDX, +- a mandatory enterprise-wide data model that all systems must implement fully, +- a graphical modeling tool, +- a complete ontology editor, +- a fully automated standards governance board, +- or a guarantee that all external standards can be mapped without ambiguity. + +--- + +# 9. Product Architecture + +## 9.1 Conceptual Product Structure + +InfoTechCanon should consist of four major layers: + +```text +InfoTechCanon +├── Canon Core +├── Domain Standards +├── Pattern Languages +└── Application Profiles +``` + +## 9.2 Canon Core + +The Canon Core defines the rules for the entire standards system. + +It should include: + +- canon artifact model, +- concept model, +- relationship model, +- concept ownership model, +- standard structure, +- mapping model, +- assimilation model, +- pattern model, +- profile model, +- retrieval model, +- provenance model, +- versioning model, +- conformance model, +- and repository layout conventions. + +## 9.3 Domain Standards + +Domain standards define canonical concepts for sufficiently independent domains. + +Initial candidates: + +```text +InfoTechCanonCore +InfoTechCanonLandscapeModel +InfoTechCanonOrganizationModel +InfoTechCanonGovernanceModel +InfoTechCanonTaskModel +InfoTechCanonTaggingStandard +InfoTechCanonAccessControlModel +InfoTechCanonServiceModel +InfoTechCanonSoftwareModel +InfoTechCanonDevSecOpsModel +InfoTechCanonNetworkModel +InfoTechCanonSecurityModel +InfoTechCanonObservabilityModel +InfoTechCanonDataModel +``` + +Not all of these need to be created immediately. Some may begin as sections, profiles, or extraction candidates. + +## 9.4 Pattern Languages + +Pattern languages describe recurring practical solutions using canonical concepts. + +Example pattern families: + +- landscape patterns, +- governance patterns, +- task patterns, +- tagging patterns, +- integration patterns, +- security patterns, +- DevSecOps patterns, +- retrieval patterns, +- assimilation patterns. + +## 9.5 Application Profiles + +Application profiles constrain the canon for concrete use cases. + +Examples: + +- KubernetesLandscapeProfile, +- GitHubIssuesTaskTaggingProfile, +- ServiceNowCSDMMappingProfile, +- NetBoxNetworkSourceOfTruthProfile, +- BackstageSoftwareCatalogProfile, +- SmallSaaSDevSecOpsProfile, +- EnterpriseSaaSComplianceProfile. + +--- + +# 10. Functional Requirements + +## 10.1 Canon Artifact Management + +### REQ-CANON-001: Canon Artifact Types + +The system shall define canonical artifact types including: + +- Standard, +- Concept, +- Relationship, +- Pattern, +- Profile, +- Mapping, +- Assimilation Report, +- Conformance Rule, +- Validation Rule, +- Interface Card, +- Example, +- Decision Record. + +### REQ-CANON-002: Stable Identifiers + +Each canon artifact shall have a stable identifier. + +Identifiers should be suitable for human reference, machine processing, linking, and retrieval. + +### REQ-CANON-003: Structured Metadata + +Each canon artifact shall support structured metadata, preferably through Markdown front matter. + +Metadata should include at least: + +- id, +- title, +- artifact type, +- status, +- version, +- canonical owner, +- imported standards, +- related artifacts, +- source references, +- provenance, +- and lifecycle state. + +--- + +## 10.2 Concept Ownership + +### REQ-CONCEPT-001: Single Canonical Owner + +Each canonical concept shall have exactly one owning standard. + +### REQ-CONCEPT-002: Concept Reuse Through Imports + +Standards shall reuse concepts from other standards by import or reference, not by redefinition. + +### REQ-CONCEPT-003: Concept Status + +Each concept shall have a lifecycle status. + +Recommended statuses: + +- proposed, +- experimental, +- candidate, +- canonical, +- deprecated, +- retired. + +### REQ-CONCEPT-004: Concept Disambiguation + +Concept definitions should include “do not confuse with” notes where ambiguity is likely. + +--- + +## 10.3 Mapping + +### REQ-MAP-001: External Mapping Support + +The canon shall support explicit mappings between InfoTechCanon concepts and external standards, regulations, product models, frameworks, and bodies of knowledge. + +### REQ-MAP-002: Mapping Types + +Mappings shall support at least the following mapping types: + +- exactMatch, +- closeMatch, +- broadMatch, +- narrowMatch, +- relatedMatch, +- conflictMatch, +- gapMatch, +- derivedFrom, +- regulatoryReference. + +### REQ-MAP-003: Scoped Mappings + +Each mapping shall declare its scope and known limits. + +### REQ-MAP-004: Versioned Mappings + +Each mapping to an external body of knowledge shall specify the target body and target version where known. + +### REQ-MAP-005: Mapping Rationale + +Each non-trivial mapping shall include a rationale explaining why the mapping exists and how it should be interpreted. + +### REQ-MAP-006: Mapping Lifecycle + +Mappings shall have lifecycle statuses such as: + +- proposed, +- reviewed, +- candidate, +- accepted, +- deprecated, +- superseded, +- rejected. + +--- + +## 10.4 Assimilation + +### REQ-ASSIM-001: Assimilation Candidate + +The canon shall support an assimilation candidate artifact for external bodies of knowledge. + +### REQ-ASSIM-002: Assimilation Process + +The assimilation process shall include: + +1. intake, +2. scoping, +3. concept extraction, +4. concept comparison, +5. gap and conflict analysis, +6. canon impact proposal, +7. mapping and publication. + +### REQ-ASSIM-003: Assimilation Outputs + +Each completed assimilation should produce: + +- assimilation report, +- source summary, +- extracted concepts, +- comparison matrix, +- mappings, +- proposed changes, +- open questions, +- deferred items. + +### REQ-ASSIM-004: Assimilation Does Not Automatically Mutate Canon + +Assimilation shall produce change proposals, mappings, and recommendations. Canon changes require explicit acceptance. + +### REQ-ASSIM-005: Gap and Conflict Capture + +Assimilation shall explicitly capture gaps, conflicts, overlaps, ambiguities, and potential refactoring opportunities. + +--- + +## 10.5 Pattern Language + +### REQ-PATTERN-001: Pattern Format + +The canon shall define a reusable pattern format including: + +- name, +- aliases, +- context, +- problem, +- forces, +- solution, +- resulting context, +- used concepts, +- related patterns, +- known variants, +- failure modes, +- examples, +- implementation notes. + +### REQ-PATTERN-002: Pattern References + +Standards and profiles shall be able to reference patterns. + +### REQ-PATTERN-003: Pattern Families + +Patterns should be organized into pattern families such as governance, integration, task, landscape, security, and DevSecOps patterns. + +--- + +## 10.6 Application Profiles + +### REQ-PROFILE-001: Profile Definition + +The canon shall support application profiles that constrain canon concepts for specific implementation contexts. + +### REQ-PROFILE-002: Profile Content + +A profile shall define: + +- used standards, +- included concepts, +- required relationships, +- required metadata, +- constraints, +- validation rules, +- examples, +- supported integrations, +- known deviations. + +### REQ-PROFILE-003: Profile Conformance + +A subsystem may declare conformance to a profile. + +--- + +## 10.7 Interface Cards + +### REQ-IFC-001: Canon Interface Card + +The canon shall define a Canon Interface Card format for subsystems. + +A Canon Interface Card shall describe: + +- subsystem name, +- implemented standards, +- implemented profiles, +- owned concepts, +- produced concepts, +- consumed concepts, +- accepted relationships, +- emitted events, +- required identifiers, +- mapping rules, +- validation rules, +- known deviations. + +### REQ-IFC-002: Subsystem Integration + +Subsystems should use Canon Interface Cards to declare how they snap into the larger InfoTechCanon ecosystem. + +--- + +## 10.8 Retrieval and Reuse + +### REQ-RET-001: Markdown-First Retrieval + +The canon shall be stored in Markdown files that are structured for both human readability and machine retrieval. + +### REQ-RET-002: Agent Briefs + +Each standard should provide an agent-oriented brief containing: + +- purpose, +- scope, +- owned concepts, +- imported concepts, +- canonical patterns, +- do / do not guidance, +- common mistakes, +- minimal examples. + +### REQ-RET-003: Indexes + +The canon shall provide indexes by: + +- standard, +- concept, +- pattern, +- profile, +- mapping, +- external standard, +- status, +- domain, +- use path. + +### REQ-RET-004: Chunking Support + +Markdown artifacts should be written in a way that supports reliable retrieval chunks with stable headings and identifiers. + +### REQ-RET-005: Machine-Readable Exports + +The canon should support machine-readable exports such as YAML, JSON, JSON-LD, RDF, or graph representations. + +--- + +## 10.9 Provenance + +### REQ-PROV-001: Provenance Metadata + +Each significant canon artifact shall support provenance metadata. + +### REQ-PROV-002: Source Traceability + +The canon shall record which sources, assimilations, decisions, or prior concepts influenced a concept, mapping, profile, or pattern. + +### REQ-PROV-003: Change Traceability + +The canon shall record supersession, deprecation, replacement, and compatibility information. + +--- + +## 10.10 Versioning and Compatibility + +### REQ-VER-001: Versioned Standards + +Each standard shall have a version and status. + +Recommended statuses: + +- idea, +- draft, +- candidate, +- release-candidate, +- adopted, +- stable, +- deprecated, +- retired. + +### REQ-VER-002: Change Classification + +Changes shall be classified as: + +- patch, +- minor, +- major, +- fork. + +### REQ-VER-003: Compatibility Notes + +Major semantic changes shall include compatibility and migration notes. + +--- + +# 11. Non-Functional Requirements + +## 11.1 Usability + +The canon must remain readable and useful to humans without requiring specialized ontology tooling. + +## 11.2 Agent Usability + +The canon must provide concise, structured, retrievable artifacts that help agents produce compatible outputs. + +## 11.3 Extensibility + +The canon must allow new standards, profiles, mappings, and patterns to be added without destabilizing existing work. + +## 11.4 Traceability + +The canon must preserve provenance, source references, change history, and mapping rationale. + +## 11.5 Modularity + +Standards should be modular and orthogonal. Subsystems should be able to implement only relevant profiles. + +## 11.6 Interoperability + +The canon should support integration with markdown infospaces, graph tools, validation tools, documentation generators, agentic coding systems, and service APIs. + +## 11.7 Low Friction + +The initial implementation should be simple enough to maintain manually in Markdown while enabling progressive automation. + +--- + +# 12. Suggested Repository Structure + +```text +infotech-canon/ + README.md + INTENT.md + SCOPE.md + canon.yaml + + core/ + InfoTechCanonCore.md + terms/ + relations/ + patterns/ + profiles/ + conformance/ + + standards/ + organization/ + governance/ + landscape/ + task/ + tagging/ + access-control/ + security/ + devsecops/ + network/ + observability/ + data/ + + patterns/ + integration/ + governance/ + landscape/ + task/ + security/ + retrieval/ + + profiles/ + github-issues-task-profile/ + kubernetes-landscape-profile/ + service-now-csdm-profile/ + netbox-network-profile/ + backstage-software-catalog-profile/ + + mappings/ + external/ + archimate/ + csdm/ + nist-csf/ + itil/ + pmbok/ + yang/ + backstage/ + spdx/ + cyclonedx/ + + assimilation/ + inbox/ + active/ + completed/ + + schemas/ + concept.schema.yaml + standard.schema.yaml + mapping.schema.yaml + pattern.schema.yaml + profile.schema.yaml + assimilation.schema.yaml + interface-card.schema.yaml + + views/ + by-domain.md + by-concept.md + by-pattern.md + by-profile.md + by-external-standard.md + by-status.md + use-paths.md + + agent/ + briefs/ + retrieval-index.md + common-mistakes.md +``` + +--- + +# 13. Success Criteria + +## 13.1 Initial Success Criteria + +The first release is successful if: + +- InfoTechCanonCore exists as a coherent standard. +- InfoTechCanonLandscapeModel is refactored to import core concepts. +- At least one mapping file exists for an external standard. +- At least one assimilation report exists. +- At least one application profile exists. +- At least one Canon Interface Card exists. +- The repository can be navigated by humans through Markdown. +- The repository can be indexed and retrieved by agents. +- Concept ownership can be validated manually or by script. + +## 13.2 Medium-Term Success Criteria + +The project is successful at the next maturity stage if: + +- multiple repositories declare implemented standards and profiles, +- agents use the canon to generate more consistent artifacts, +- new external standards can be assimilated through a repeatable process, +- mappings are versioned and maintained, +- domain standards remain orthogonal with limited overlap, +- and the canon becomes a practical reference point for system design. + +## 13.3 Long-Term Success Criteria + +The project is successful long-term if: + +- InfoTechCanon becomes the semantic substrate for the user’s information-processing systems, +- markdown infobase tools and services use it as a core driving use case, +- subsystems can be integrated through declared semantic contracts, +- standards evolve without uncontrolled contradiction, +- and humans and agents can reliably retrieve, reuse, and extend the body of knowledge. + +--- + +# 14. Risks and Mitigations + +## 14.1 Risk: Over-Abstraction + +The canon may become too abstract to guide real implementation. + +**Mitigation:** Require examples, profiles, patterns, and interface cards for important concepts. + +## 14.2 Risk: Excessive Scope + +The canon may attempt to cover too many domains at once. + +**Mitigation:** Start with InfoTechCanonCore, LandscapeModel, OrganizationModel, GovernanceModel, TaskModel, and TaggingStandard. Treat additional domains as candidates. + +## 14.3 Risk: Semantic Drift + +Different standards may redefine similar concepts. + +**Mitigation:** Enforce single canonical owner per concept and require imports for reuse. + +## 14.4 Risk: External Standard Pressure + +External standards may distort internal concepts. + +**Mitigation:** Use mappings and assimilation reports instead of direct adoption. + +## 14.5 Risk: Poor Retrieval Quality + +Agents may retrieve irrelevant or outdated content. + +**Mitigation:** Use stable IDs, front matter, summaries, indexes, lifecycle states, and agent briefs. + +## 14.6 Risk: Manual Maintenance Burden + +Maintaining mappings, concepts, profiles, and indexes may become expensive. + +**Mitigation:** Start markdown-first, then progressively automate validation, index generation, mapping checks, and retrieval exports. + +## 14.7 Risk: Contradictions Between Standards + +As standards grow, contradictions may emerge. + +**Mitigation:** Add overlap reviews, concept ownership checks, conflict reports, and periodic canon refactoring cycles. + +--- + +# 15. Open Questions + +1. Should InfoTechCanonCore be a single document initially or split immediately into core modules? +2. Which external standard should be assimilated first as a test case? +3. Should the first application profile target GitHub Issues, Kubernetes, ServiceNow CSDM, or a user-owned repository? +4. Which schema language should be used first for machine-readable artifacts: YAML Schema, JSON Schema, JSON-LD, RDF/OWL, or a simpler custom convention? +5. Should pattern documents live globally or inside domain standards first? +6. How strict should conformance validation be in the first release? +7. Should InfoTechCanon use namespace prefixes such as `itc-core`, `itc-landscape`, `itc-task`, and `itc-gov` from the beginning? + +--- + +# 16. Initial Roadmap + +## Phase 1: Foundation + +- Create `InfoTechCanonCore.md`. +- Define artifact types, concept ownership, mapping model, assimilation model, profile model, pattern format, retrieval model, and versioning. +- Create initial repository structure. +- Define naming and identifier conventions. + +## Phase 2: Refactor Existing Work + +- Rename and refactor `CILM_Standard_RC1.md` into `InfoTechCanonLandscapeModel_RC1.md`. +- Extract organization and governance assumptions into candidate standards. +- Create initial imports between standards. + +## Phase 3: First Mapping and Assimilation + +- Select one external standard for assimilation. +- Produce an assimilation report. +- Produce mappings. +- Propose canon changes. + +## Phase 4: First Application Profile + +- Define a concrete profile, such as `GitHubIssuesTaskTaggingProfile` or `KubernetesLandscapeProfile`. +- Add validation rules. +- Add example artifacts. + +## Phase 5: Agent and Tool Integration + +- Create agent briefs. +- Create machine-readable indexes. +- Integrate with markdown infobase tooling. +- Test retrieval with real agentic coding and documentation workflows. + +## Phase 6: Subsystem Integration + +- Define Canon Interface Cards for selected repositories or services. +- Use the canon to guide integration between tools such as markitect-tool, kontextual-engine, shard-wiki, user-engine, landscape tooling, and task tooling. + +--- + +# 17. Acceptance Criteria for First Deliverable + +The first deliverable should be accepted if it includes: + +- a clear InfoTechCanon product definition, +- a coherent product scope, +- a description of the canon architecture, +- mapping requirements, +- assimilation requirements, +- retrieval requirements, +- pattern and profile requirements, +- initial repository structure, +- risks and mitigations, +- open questions, +- and an actionable roadmap. + +--- + +# 18. Summary + +InfoTechCanon is intended to become an evolving, markdown-first, machine-readable, human-usable reference system for interoperable information-processing systems. + +Its distinctive mechanisms are: + +```text +Mapping keeps the canon externally legible. +Assimilation keeps the canon intellectually alive. +Retrieval keeps the canon operationally useful. +Patterns keep the canon practical. +Profiles keep the canon implementable. +Concept ownership keeps the canon orthogonal. +``` + +The product should begin with a strong core meta-standard and then grow through domain standards, mappings, assimilation reports, profiles, patterns, and subsystem interface cards. + +The ultimate goal is to make InfoTechCanon a living semantic substrate for building adaptable systems that remain compatible without becoming rigid. +