# 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/<domain>/
  InfoTechCanon<Domain>Model.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.