tegwick
dc74164fff
The layer model is now published as net-kingdom/canon/standards/security-layer-model_v0.1.md (proposed) and ratified by gate-house GH-DEC-2026-001. The note previously said the standard was not yet written. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
123 lines
5.5 KiB
Markdown
123 lines
5.5 KiB
Markdown
# INTENT
|
|
|
|
> **NetKingdom layering review — 2026-08-28.** This repository's role was reviewed
|
|
> against the NetKingdom IT-security layer model: **Taxonomy → Tooling → Engines →
|
|
> Staff**, layered by determinism and by the kind of artifact each layer produces.
|
|
> Findings and the argument behind them:
|
|
> `gate-house/history/2026-08-28-security-layer-model-and-gate-house-recut.md`.
|
|
> The model is `net-kingdom/canon/standards/security-layer-model_v0.1.md` (proposed),
|
|
> ratified by `gate-house/decisions/decisions.md` GH-DEC-2026-001.
|
|
>
|
|
> The layer rule that binds every repository: **Staff never touches tooling
|
|
> directly. It acts only through engine APIs.**
|
|
>
|
|
> **This repository is Taxonomy — cross-cutting, ecosystem-wide.** Clarify the split with net-kingdom canon: info-tech-canon owns cross-cutting semantic contracts and terminology for the whole ecosystem; NetKingdom-specific security architecture — including the layer model — is net-kingdom canon's. No change of role, only an explicit boundary so the two canons are not read as competing.
|
|
>
|
|
> *This note records what should change. The body below is not yet adapted.*
|
|
|
|
## Purpose
|
|
|
|
This repository exists to develop and maintain **InfoTechCanon**: an evolving, markdown-first reference system for building interoperable, adaptable, and extensible information-processing systems.
|
|
|
|
InfoTechCanon provides a shared semantic foundation for standards, concepts, patterns, profiles, mappings, and assimilation processes used across software, infrastructure, governance, DevSecOps, task management, knowledge systems, and related domains.
|
|
|
|
---
|
|
|
|
## Primary Utility
|
|
|
|
InfoTechCanon helps turn **integration by interpretation** into **integration by declared semantic contract**.
|
|
|
|
It provides:
|
|
|
|
- canonical concepts with clear ownership,
|
|
- orthogonal standards that can import but not redefine each other,
|
|
- mappings to external standards, regulations, frameworks, and product models,
|
|
- assimilation processes for incorporating new bodies of knowledge,
|
|
- reusable pattern-language structures,
|
|
- application profiles for concrete implementation contexts,
|
|
- retrieval-friendly markdown artifacts for humans, agents, and tools,
|
|
- and guidance for making independently developed subsystems easier to connect.
|
|
|
|
---
|
|
|
|
## Intended Users
|
|
|
|
This repository is intended for:
|
|
|
|
- architects designing interoperable information-processing systems,
|
|
- standards authors defining reusable domain models,
|
|
- repository maintainers declaring semantic boundaries and interfaces,
|
|
- developers implementing compatible subsystems,
|
|
- agents retrieving structured reference knowledge,
|
|
- governance and compliance reviewers mapping internal concepts to external obligations,
|
|
- and tool builders working on markdown-based infospaces, knowledge engines, and agentic development workflows.
|
|
|
|
---
|
|
|
|
## Strategic Role
|
|
|
|
InfoTechCanon acts as a **semantic operating layer** for a growing ecosystem of repositories, services, agents, and documentation spaces.
|
|
|
|
It should support projects that need to remain adaptable while still sharing a common vocabulary and integration logic.
|
|
|
|
The repository is expected to become a reference point for related tools and systems, including markdown infobases, canonical landscape models, task and tagging standards, governance models, access-control models, and subsystem interface declarations.
|
|
|
|
---
|
|
|
|
## Design Stance
|
|
|
|
InfoTechCanon is:
|
|
|
|
- **markdown-first** but machine-readable,
|
|
- **network-shaped** rather than purely hierarchical,
|
|
- **pattern-oriented** rather than merely taxonomic,
|
|
- **externally mappable** without being externally constrained,
|
|
- **evolutionary** without becoming arbitrary,
|
|
- **orthogonal** without becoming isolated,
|
|
- and **practical** enough to guide real subsystem integration.
|
|
|
|
External standards influence InfoTechCanon through mappings and assimilation. They do not define its internal semantics directly.
|
|
|
|
---
|
|
|
|
## Core Commitments
|
|
|
|
InfoTechCanon commits to the following principles:
|
|
|
|
1. Every canonical concept should have a clear owner.
|
|
2. Standards should import concepts instead of redefining them.
|
|
3. Mappings to external bodies of knowledge should be explicit, versioned, scoped, and justified.
|
|
4. Assimilation should turn new knowledge into gaps, conflicts, mappings, and improvement proposals.
|
|
5. Patterns should explain how concepts are combined in recurring practical situations.
|
|
6. Profiles should constrain standards for concrete implementation contexts.
|
|
7. Canon artifacts should be useful to both humans and agents.
|
|
8. Evolution should preserve provenance, compatibility information, and rationale.
|
|
|
|
---
|
|
|
|
## Non-Goals
|
|
|
|
This repository does not aim to replace external standards such as ArchiMate, CSDM, ITIL, PMBOK, NIST, YANG, SPDX, CycloneDX, or similar bodies of knowledge.
|
|
|
|
It also does not aim to define one mandatory enterprise data model that every system must fully implement.
|
|
|
|
Instead, InfoTechCanon provides a coherent internal reference system that can map to external standards, assimilate useful knowledge from them, and support practical interoperability across independently evolving systems.
|
|
|
|
---
|
|
|
|
## Direction of Travel
|
|
|
|
The repository should initially establish:
|
|
|
|
- `InfoTechCanonCore`,
|
|
- a refactored `InfoTechCanonLandscapeModel`,
|
|
- early organization and governance model extraction points,
|
|
- a mapping model,
|
|
- an assimilation model,
|
|
- a pattern format,
|
|
- a profile format,
|
|
- retrieval conventions,
|
|
- and example subsystem interface declarations.
|
|
|
|
Over time, the repository should grow into a living canon that supports human reasoning, agentic workflows, validation, documentation generation, knowledge retrieval, and practical system integration.
|
|
|