generated from coulomb/repo-seed
157 lines
3.0 KiB
Markdown
157 lines
3.0 KiB
Markdown
# 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.
|