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