Initial seeding of models, standards

This commit is contained in:
2026-05-23 00:55:01 +02:00
parent 3c3ce327ac
commit 1ed7198ce3
24 changed files with 37176 additions and 0 deletions

View File

@@ -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
```

View File

@@ -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.

View File

@@ -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.

View File

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