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