36 KiB
Executable File
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.
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.
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:
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:
- provide enough common structure to align all seed standards,
- avoid over-formalizing before actual use reveals needs,
- preserve markdown-first authoring,
- support machine-readable extraction,
- support agent retrieval and reasoning,
- support external mappings without external subordination,
- support assimilation as a repeatable knowledge-ingestion process,
- support explicit evolution and compatibility management,
- support orthogonality between standards,
- 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
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:
standard document
concept page
pattern document
profile document
mapping file
assimilation report
validation rule
agent brief
schema
example
decision record
Recommended attributes:
id:
type:
title:
status:
version:
canonical_owner:
created_at:
updated_at:
source_system:
Optional attributes:
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:
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:
id:
preferred_label:
definition:
canonical_owner:
status:
broader:
narrower:
related:
do_not_confuse_with:
mappings:
examples:
anti_examples:
Canonical rule:
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:
id:
relationship_type:
definition:
domain:
range:
directionality:
inverse:
cardinality:
canonical_owner:
examples:
Examples:
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:
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:
id:
profile_name:
status:
implements:
target_context:
included_concepts:
required_relationships:
required_metadata:
constraints:
validation_rules:
mapping_files:
examples:
known_deviations:
Canonical rule:
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:
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:
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:
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:
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:
stable
unique within namespace
human-readable where practical
machine-parseable
version-aware where needed
Recommended form:
namespace:local-name
Examples:
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:
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:
idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired
10.2 Concept Statuses
Recommended concept statuses:
proposed
experimental
candidate
canonical
deprecated
retired
10.3 Artifact Statuses
Recommended artifact statuses:
raw
captured
draft
reviewed
candidate
canonical
deprecated
superseded
archived
10.4 Review States
Recommended review states:
not_reviewed
under_review
reviewed
changes_requested
approved
rejected
needs_revalidation
10.5 Compatibility States
Recommended compatibility states:
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:
concept: itc-org:Team
canonical_owner: InfoTechCanonOrganizationModel
11.2 Use by Other Standards
Other standards MAY use the concept through imports or references.
Example:
uses:
- itc-org:Team
used_for:
- service ownership
- task assignment
- access review accountability
11.3 Ownership Rule
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:
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:
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
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:
exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference
toolEquivalent
deprecatedReplacement
13.3 Mapping Record
A Mapping SHOULD declare:
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:
low
medium
high
verified
contested
13.5 Mapping Statuses
Recommended mapping statuses:
proposed
reviewed
candidate
accepted
deprecated
superseded
rejected
13.6 Mapping Rule
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:
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:
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
id:
source_body:
source_version:
source_type:
reason:
requested_by:
status:
scope:
owner:
14.5 Assimilation Outputs
A completed assimilation SHOULD produce:
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:
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
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:
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:
core
information-space
landscape
organization
governance
task
tagging
access-control
security
data
devsecops
network
observability
integration
agentic
15.4 Pattern Rule
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:
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:
tool profile
domain profile
implementation profile
integration profile
repository profile
agent profile
compliance profile
runtime profile
16.4 Profile Rule
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:
id:
description:
applies_to:
severity:
check_type:
rationale:
examples:
17.2 Severity
Recommended severity values:
info
warning
error
critical
17.3 Check Types
Recommended check types:
structural
semantic
reference_integrity
metadata
mapping
profile
conformance
quality
security
retrieval
17.4 ValidationResult
A ValidationResult records the outcome of applying a rule.
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:
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:
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:
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
Important canon changes SHOULD preserve provenance and rationale.
21. Repository Model
21.1 Recommended Top-Level Repository Structure
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
standards/<domain>/
InfoTechCanon<Domain>Model.md
agent-brief.md
concepts/
relationships/
patterns/
profiles/
mappings/
assimilation/
examples/
validation/
21.3 Core Directory Structure
core/
InfoTechCanonCore.md
concepts/
relationships/
patterns/
profiles/
mappings/
schemas/
validation/
21.4 Generated Views
Generated views SHOULD be marked as generated.
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:
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:
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:
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:
agent-brief.md
23.2 Agent Retrieval Requirements
Agent-facing artifacts SHOULD support:
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:
source context
generated artifact
rationale
review expectation
human approval requirement if needed
23.4 Agent Rule
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
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:
repository integration
service integration
agent onboarding
tool mapping
source-of-truth declaration
schema boundary declaration
knowledge ownership
24.4 Rule
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:
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:
id
preferred label
definition
canonical owner
status
examples
non-examples
related concepts
mappings
validation notes
27.3 Minimal Mapping Profile
A mapping SHOULD include:
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:
source summary
extracted concepts
comparison matrix
gaps
conflicts
mappings
proposed changes
open questions
27.5 Minimal Agent Brief Profile
An agent brief SHOULD include:
purpose
scope
owned concepts
imported concepts
do / do not rules
common mistakes
minimal examples
validation hints
28. Core Validation Rules
Initial validation rules:
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:
info-tech-canon/
core/
InfoTechCanonCore.md
agent-brief.md
concepts/
relationships/
patterns/
profiles/
mappings/
schemas/
validation/
Seed files:
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:
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:
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:
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.