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